Pre-Trade versus Post-Trade

What difference does it make? On the surface, it would appear that the main difference is the sequencing: one is before and the other is after. However, that is not terribly pertinent. The actual distinction lies in the fact that post trade risk assessment systems often operates off a dropcopy service, outside the communication channel between the trader and the venue (i.e.: the system cannot prevent the trader from submitting another order). The core differences are:

Latency

Systems on the critical path introduce latency; drop copy consumers do not.

Actionability

Systems on the critical path can see/manipulate everything; where as drop copy consumers usually can only observe fills (and in systems where they can observe potential orders, they are not in a position to stop that order before it reaches the venue).

Insight

Because of Actionability systems on the critical path can, at any point in time, assess the complete range of potential positions that the trader's order can result in; drop copy consumers do not have any idea what orders are about to be executed.

Rigor

Because of Insight, pre-trade risk limits can be enforced nearly absolutely (the exceptions include: reference rate updates, price uncertainty on market orders, rogue fills, external position adjustments, and manual risk limit adjustments); post-trade limits are inherently porous. When a post-trade risk system observes that a trader crossed a limit, it is not unreasonable to assume that the trader could be well on his way to twice that limit within the next few seconds.

Regularity

Because of Rigor, pre-trade systems do not need anything but a numeric limit. Post-trade systems, because of their essential lack of tangibility, tend to resort to measuring a plethora of alternative, unsatisfactory signals:

• Percentage utilization warnings. This is actually the most sensible item on the list. However, if this is the de facto limit, why not just use this one as the full amount?
• Order count. This metric assumes that a pound of feathers is heavier than a pound of rocks. However it is of generally perceived used as a protection against rogue algorithms.
• Filled-Only limits. One could say that the entire point of moving from post-trade to pre-trade is so that we can replace this misbegotten metric with something more relevant.
• Settlement-day-based limits. This is another category of limits conceived of in post-trade that does not translate well to pre-trade.
• Various other dead-man-switches. This bullet point highlights the fact that in a post-trade environment, the counter that keeps the position is physically separated from the mechanism that is supposed to "control" the trader.

Stability

Though the post-trade metrics required to ensure Regularity are all at best tangentially related to risk, they are often hooked up to to an extreme "risk control" instrument that can do only one thing: cut the wire. The crudeness of this  operation leads to many complications, yet it is performed because it is the only action a post-trade system can perform. The equally crude metrics that trigger it are problematic, but they are the only metrics that a post-trade system can measure. 

Pre-trade systems never have a need to perform this action.

Architecture

Reflector Runtime

Reflector’s runtime is composed of four distinct subsystems:

• Session Store - Handles handles Ethernet frames and tcp sessions. Captured raw Ethernet frames are categorized, and filtered by various blacklists and whitelists. The set of frames that belong to a single TCP instance are binned together and sorted. Several other stages of processing later, the TCP payload is presented as a range of bytes for output.
• FIX Message Parser - A monolithic FIX message parser which interprets sequences of bytes and translates them into possible order actions.
• Risk Instance - Keeps order and position states, maintains the credit pool hierarchy, and performs all risk checks.
• REST API User Guide - Runs on a dedicated thread and handles external queries, as well as command/control and position adjustments.

Database

A database provides permanence to executed fills.

Additional Material

Further detail is provided in the following page(s):

• Currencies
• Session Store
• FIX Message Parser
• Risk Instance
• Reference Rates
• Position Permanence
• Error Codes