...

• NORMAL - All risk limits are maintained. No additional restrictions.
• DEESCALATION - Trader only able to submit submit orders which may reduce position, or cancels.
• LOCKED - Trader only able to submit cancels.
• UNPLUGGED - TCP sessions terminated.

Order Risk Model

Currency Pair Positions

...

Reflector implements an "Order Risk model", not an "Order model". The difference is that only the attributes of an order that has risk implications are modeled.

For taker orders, this means that open orders and fills are separate entities. A given open taker order has exactly 3 possible states: nonexistent, live, and dead. The order is live from the outbound NewOrderSingle until an inbound ExecReport confirms its death. The fills that the open order accumulates have 3 possible states too: nonexistent, filled, and rolled back.

For makers, the inbound order itself is assumed to carry no risk. It is the outbound ExecReport that is being examined for risk. We model that as a fill that can potentially be rolled back; because most maker venues do not ack on accept, and rejects are rather rare.

Daily Settlement Limit

DSL is supported by Reflector, however it shoudl be noted that DSL is primarily a passive post-trade metric - as discussed in the following subsections.

Precision versus Correctness

DSL demands precision on a metric that is inherently ambiguous before an order executes: settlement date. There are three potential sources of truth with regard to settlement date on a spot order:

• Trader - irrelevant in this context.
• Venue  - silent on a NewOrderSingle, because it is the recipient.
• Reflector - must determine settlement dates using Copp-Clark. But, what happens when the venue confirms a fill with a settlement date different to Reflector's?

Implications:

• Reflector could conform the settlement date to the venue's value, but this essentially means that we have no daily limit.
• Reflector could stick with its original determination, but would then be vulnerable to rollovers.

False Precision & Perverse Incentives

Even if the precision described in the previous section can be captured correctly, the effort to do so may be in vain.

A trader wishing to load up on risk while evading DSL can simply make sure to spread his orders between different settlement days. Even a trader who is fully compliant in spirit will be incentivized to take on riskier bets with longer settlement terms in the event that his near term position is approaching its DSL limit.

In other words, DSL encourages in practice precisely the kind of behavior it purports to curtail in principle.

Ordering

DSL is weakly ordered. Given two DSL positions, it is not possible in all cases to determine if one position is "more risky", "less risky", or "equally risky" as the other in terms of DSL. This matters a lot when a trader is put in any sort of "deleveraging mode", where only risk decreasing trades are allowed. Since we cannot determine which DSL is "worse" than another, we actually must also run something else to arbitrate, and when the arbitrating metric allows through a trade in deleveraging mode, it must be allowed to bypass DSL even if its limits are bust. DSL is therefore a rule that attempts to preempt extreme situations that actually must be discarded in precisely some of these extreme situations it is charged upon preventing.

Performance

Implementing DSL requires us to multiply the memory required to store a position by 2N, where N is the average number of unsettled date buckets per pool of risk. This effect multiplies with other storage-multiplying features, such as counterparty position and multi-location. Worse yet, we cannot precompute all the dates; which means that we need additional synchronization during runtime to make sure that the web server read the correct memory locations. These factors have a direct impact for a real-time application.