To ensure that order parameters fall within desired limits and comply with regulations, you create one or more risk firewalls. For each risk firewall, you register one or more rule classes, add rule class instances, unlock the risk firewall to make it available to be used, and use risk firewall order sender components to send orders into the risk firewall. The risk firewall evaluates each order against its rule class instances.

After evaluation, the risk firewall determines whether the order should be approved, pended, or rejected. This determination depends on both evaluation results and configuration parameter settings.

When an order is approved the risk firewall forwards it to an order receiver component in your application. It is up to the application to determine what to do with an approved order. For example, the application can have the order receiver forward the approved order to an order management system outside your application, or to a smart order router, or to a trading algorithm. Likewise, if an order is rejected, your application determines how to handle the order.

The risk firewall provides a framework for defining custom, pre-trade risk rules, and also provides a number of default rule classes that are ready to register with a risk firewall. The default rule classes provide a structure for determining, for example, whether an order price is above a specified ceiling, whether a trader has placed a cumulative order value beyond a particular limit, and whether the overall position for a set of orders has exceeded specified parameters. For each registered rule class, you add one or more rule instances. Each rule instance can specify different parameters and order filters. Note that for custom rule classes, the addition of at least one rule class instance is not always a requirement. See Implementing custom risk firewall rule classes.

After an order is processed by an external order management system, that system returns an order update. The risk firewall order receiver passes the order update back through the risk firewall so that it can be processed by the rule instances. This enables the rule instances to update any cumulative values they maintain. The risk firewall then sends the order update to the risk firewall order sender that originated the order. The following figure illustrates this.

NewOrder, AmendOrder, and CancelOrder events go from the OrderSender component into the risk firewall. If approved, the risk firewall sends these events to the OrderReceiver component. OrderUpdate events go from external order-processing components to the OrderReceiver, which sends the order updates into the risk firewall. The risk firewall sends any order state changes to all registered rule classes so that they can update their internal state if required. The risk firewall then sends the OrderUpdate to the OrderSender component.

You can create any number of uniquely named risk firewalls. You can use multiple contexts to implement your risk firewall architecture. You can create a risk firewall in one context and use it from one or more monitors in that context as well as use it from other contexts. The following figure illustrates this.

You must always explicitly create risk firewall instances and register rule classes. However, by default, a risk firewall is configured to persist rule class instances. Upon correlator re-start, they are automatically re-added to the risk firewall using previously set per-instance parameters. This happens regardless of whether persistence is enabled for the correlator.

Sample code for implementing a risk firewall can be found in the samples directory of your CMF installation directory. Also in that directory, is the source code for the default rule classes, which you can use as a reference for implementing custom rule classes.