Atomic EFID/EFID Group Limits

Firms can opt-in to specify that EFID Level and EFID Group Level limits (i.e., best-effort limits) be also implemented as atomic limits on every Matching Engine considering only activity on the local matching engine.

The impact of opting in to this functionality is that risk trips resulting from activity on a single Matching Engine will be notified back to firms more quickly for the single Matching Engine. The single Matching Engine risk trip will then result in risk trips on all other Matching Engines as a result of the distributed processing of the best-effort limit.

When selected, "Atomic EFID/EFID Group Limits" causes all best-effort distributed EFID Level and EFID Group Level risk limits to be implemented both as best-effort and atomic limits. The atomic versions of the best-effort limit run in the context of a single Matching Engine. As a result, instead of considering trading in all options, they consider only activity on the local Matching Engine. In scenarios where an EFID or EFID Group Level limit is tripped as a result of trading activity on a single Matching Engine, customers that have opted in to the "Atomic EFID/EFID Group Limit" functionality will experience more timely order cancellation and lockout on the single Matching Engine, which will be followed by distributed processing of the risk trip to other Matching Engines.

The reason for providing firms with the option to use this functionality is that there is a race condition that firms must be prepared for when best-effort limits are also implemented atomically on each Matching Engine. When a risk trip occurs on a single Matching Engine a firm may submit a risk reset before the same trip propagates through the distributed processing, which could result in the risk reset appearing to have not worked properly when the issue was timing. Firms that wish to avoid this complexity and that do not need atomic implementation of best-effort limits may chose not to opt in to this functionality.