Apama Capital Markets Foundation Documentation : Capital Markets Foundation : Order Management : Risk Firewall : Configuring risk firewall instances : Configuring risk firewall behavior for rejected orders
Configuring risk firewall behavior for rejected orders
When an order comes into a risk firewall, each rule class instance is queried to determine whether the order complies with that rule class instance. But even when the query responses indicate that an order would be rejected, it is the setting of the rejection mode configuration parameter that determines risk firewall behavior.
There are several ways in which the rule instance query responses can indicate whether the order should be approved or rejected.
*If the CONFIG_FAST_FAIL_MODE configuration parameter is enabled, an order is considered rejected as soon as there is a single query response that indicates that the order does not comply with a rule class instance. Subsequent rule class instances are not evaluated. This is the default behavior.
*If the CONFIG_FAST_FAIL_MODE configuration parameter is not enabled, an order is still considered rejected as soon as there is a single query response that indicates that the order does not comply with a rule class instance. However, subsequent rule class instances are still evaluated for their query responses. This is less efficient, but provides a comprehensive response across all rule class instance queries.
*If the CONFIG_FAST_FAIL_MODE configuration parameter is not enabled then the risk firewall must receive a response from all rule class instances before the time specified by the CONFIG_TIMEOUT_DURATION configuration parameter has elapsed. The default time period is 5 seconds. This ensures that the state of an order is not blocked by unresponsive rule class instances. If the timeout period is reached and not all query responses have been received then the order would be rejected as a result of the query request timing out.
If an order is considered to be rejected, what the risk firewall does next depends on its rejection mode setting. The configuration parameter CONFIG_REJECTION_MODE can have one of the following values:
CONFIG_REJECTION_MODE Setting
Behavior when an order would be rejected
CONFIG_REJECTION_MODE_HARD
The order is rejected. The risk firewall sends an OrderUpdate event that contains the rejection details back to the risk firewall order sender that submitted the order. The risk firewall passes only approved orders to a risk firewall order receiver. This is the default behavior.
CONFIG_REJECTION_MODE_SOFT
The order is pended. The risk firewall sends an OrderUpdate event that contains the rejection details back to the risk firewall order sender that submitted the order. The application can allow a dealer to do any one of the following:
*Amend the order to be correct and re-submit it to the risk firewall for evaluation. Note that your cannot send a new order with the same order Id. You must always amend the existing, pending order.
*Cancel the order.
*Leave the order as is and allow it to bypass the risk firewall. Again, the RiskFirewall.overrideSoftReject() action does this.
Soft rejection mode uses a configurable timeout (CONFIG_SOFT_REJECTION_DURATION) to ensure that orders are not pended for indefinite periods of time. Once this timeout period has expired the order is rejected. The default timeout period is 60 seconds.
CONFIG_REJECTION_MODE_MONITOR
The order is passed forward to a risk firewall order receiver instance as though it had been approved. Set this mode when you want to monitor the orders being evaluated by the risk firewall. When MONITOR mode is set, you should also execute RiskFirewall.addQueryResponseCallback() to add a callback that will provide the rejection information.
When the CONFIG_REJECT_BY_DEFAULT configuration parameter is enabled (the default) the risk firewall rejects an order if it does not match any rule class instances. The risk firewall treats this rejection according to its rejection mode setting. If soft rejection is enabled then the order is pended. However, amendments to the order would also be rejected until the application adds a suitable rule class instance or corrects the original order details.
Note:  
By default, approval from the risk firewall requires an order to match at least one instance of every registered rule class.
Copyright © 2013-2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback