Risk Management

Warning

THE IMPLEMENTATION DESCRIBED HERE IS A PROTOTYPE AND LIKELY TO CHANGE.

An external risk management service must operate as a drop-copy client to the gateway.

The communication protocol allows for the service to be “slow” without compromising accuracy: the gateway will perform a local per-symbol approximation based on events happening after the last received risk limit.

By leveraging the gateway sequence number it’s possible to approximate current position accurately.

The goal is to implement a very fast and accurate limit check at the gateway level.

Important

It is very important to appreciate that fast and accurate limit checking is important in this context.

• Gateways are low-latency: we can not allow expensive risk checking.

• Gateways must accurately take into acocunt fills and current risk exposure (working orders) in order to validate new order requests against limits.

Inconsistencies can not be allowed since it would only create confusion and difficulties when implementing fully automated processing.

Requirements

• Risk management capabilities must be opt-in

  • Zero latency impact when not needed

• Lowest possible impact on latency

  • Only allow lookups and simple localized operations

• Current positions should be monitored

• Risk exposure (working orders) should be monitored

• Risk exposure must increase already when a request is being sent

• Risk exposure can decrease when a request is confirmed or an update is received

Constraints

• Only local, per-symbol, risk management is supported

  • Global risk must be managed by an external service

• Drop-copy must process updates sequentially

  • Risk limit updates are associated with a sequence number

• Risk limits are only validated for new requests

  • The gateway is not responsible for canceling working orders

How?

Drop-Copy Client

• Receives all order and trade updates from the gateway

• Persists trades to a database solution

• Publishes current positions and risk limits to the gateway

• Other “admin” tasks such as

  • risk limits configuration

  • trade corrections, e.g. re-allocation or adding non-recorded trades

Risk Limits

Grouped by

• Account, or

• User, or

• Strategy (NEW)

An update contains (for each of long and short)

• Current position

• Current position limit

• Current risk exposure limit

The update is associated with a gateway sequence number such that the gateway can update a proxy for current positions.

Positions

Positions are updated with every fill seen by the gateway.

Note

The gateway may not always be allowed to net long/short positions. There can be different reasons for this, including settlement risk, omnibus accounting, etc.

The gateway keeps the history of fills against a sequence number.

When the gateway receives a risk limit update, it can

• remove all fills prior to the received sequence number, and

• add any fills seen after the received sequence number.

This effectively factors out any synchronization issues and allows an external risk management service to be “slow”.

Position Limits

These limits are validated against current positions.

A new order request may fail if

• current position > position limit

Risk Exposure Limits

These limits are validated against current positions AND any risk exposure from working orders.

A new order request may fail if

• (current position + sum of risk exposure from working orders) > risk exposure limit

Risk Exposure

• CreateOrder and ModifyOrder (when quantity is increased) will increase risk exposure

  Note

  Risk exposure is increased when the request is sent

• OrderUpdate may decrease risk exposure

  • fills

  • reject

  • cancel

  • modify (to decrease quantity)

Warning

Timeout is a special case for which we don’t have a good solution.

Risk exposure is not decreased when timeout has been detected. However, there is currently no proper way to reset this if the order action request was truly lost.

Implementation

Risk Exposure

Two new fields, risk_exposure and risk_exposure_change, have been added to both OrderAck and OrderUpdate.

The reason for adding these fields to OrderAck has to do with the risk exposure potentially increasing already at the time when an order action request is forwarded to the exchange.

Any other change to risk exposure is updated with OrderUpdate, e.g. accept/reject and trades.

Note

This allows any consumer of OrderAck and OrderUpdate to compute available risk limits on a conservative basis.

Warning

Depending on the context, OrderAck may not always have access to any cached order details. For these cases, risk_exposure will be NaN.

Risk Limits

Examples

Simple

Create order, partial fill, cancel order.

Event	Type	Origin	Status	Remaining	Traded	Exposure	Change
OrderAck	Create	Gateway	Forwarded		0	10	10
OrderAck	Create	Exchange	Accepted		0	10	NaN
OrderUpdate			Working	10	0	10	NaN
OrderUpdate			Working	8	2	8	-2
OrderAck	Cancel	Gateway	Forwarded		2	8	NaN
OrderAck	Cancel	Exchange	Accepted		2	8	NaN
OrderUpdate			Canceled	8 (*)	2	0	-8

Complex

TODO: Create order, partial fill, modify order, reject, modify order, partial fill, completed.

Current Issues

• How to manage rounding errors

• Grouping by strategy requires API changes