Overview

The Risk Instance keeps order and position states, maintains the credit pool hierarchy, and performs all risk checks. 

The output of the message parser consists of order actions. The risk instance determines the legality of those order actions. To accomplish this, Reflector acts as-if the following steps are taken:

1. Identity - New order requests must have new IDs. Modify requests must refer to existing and live IDs.
2. Sanity - Any checks that require validating against prior state. NOTE: The message parser actually performs most of the sanity checks because they can be done a priori.
3. Order State - A speculative order state is constructed.
4. Order Diff - A diff between the speculative order state and the previous order state is calculated.
5. Position Diff - The order state diff is transformed into a position diff.
6. Position States - For each associated risk pool, a speculative position is created with the old position and the position diff.
7. Risk Checks - For each associated risk pool, the speculative position is checked against the parameters for that pool.
8. Success - If risk checks pass, speculative order and position states are made permanent, and order allowed through.
9. Failure - If risk checks fail, order and position states are rolled back, and order action is denied.

Risk Pool Hierarchy

Definitions:

• A Group is a collection of live orders and unsettled fills that logically belong together, a pool of risk.
• Within a Group, the actualized outlays of the fills combined with the potential outlays of live orders form a Position.
• Additionally, every Group has a set of risk parameters, known as Limits, to which its Position is subject.

There are two types of Groups:

Aggregate groups contain other groups.

User groups contain credentials. Credentials are uniquely identified by the ordered triple (Venue, CompID, SubID). Users may be associated with multiple credentials per venue and over multiple venues.

In the following diagram, the BROKER and FUND nodes are aggregates. The access, command/control, and semantics surrounding them are external to the runtime, and are handled elsewhere. The only constraints that Reflector enforces on Aggregates are that they can only contain other groups and their Position is the sum of the Positions of the groups contained by them.

User groups, represented by TRADER in this diagram, contain only credentials and represent the most granular division of risk available in Reflector. Individual credential entries do not keep their own positions.

TODO DIAGRAM

Position Model

Limits

Limits may be categorized as follows:

1. Fat Finger Checks - These limits are entirely unrelated to the overall position. They either enforce properties of a single order/execution (single limit), or measure some side-channel effect (submission rate).
2. Tranched Limits - These limits encompass only some defined subset of the overall position, providing fine-grained control:
   1. Pending limit
   2. Currency-exposure limits
   3. DSL
3. Credit Limits - The following limits accumulate over the entire position, emits an ordering (required for de-escalation mode) and maps to a well known notion of risk. Every pool of risk must choose one of them as its primary measure of risk:
   1. Downside limit
   2. Upside limit
   3. Exposure
   4. Displacement
4. Daily Credit Limits - Just like credit limits, but divided by settlement date.
5. Counterparty Credit Limits - Just like credit limits, but divided by settlement counterparty.

Fat-Finger Checks

Submission Rate

Live Order Count Limit

Single Order Limit

Tranched Limits

Pending Limit

Per-Currency Exposure Limits

Currency Basket Exposure Limits

Daily Settlement Limit

Credit Limits

Net Open Position

Downside Limit

Upside Limit

Exposure Limit

Displacement Limit

Risk Modes

Order Risk Model

Currency Pair Positions

Daily Settlement Limit