Overview

Reflector contains a monolithic FIX message parser which interprets sequences of bytes and translates them into possible order actions.

It is compatible with all current FIX protocol versions without needing to differentiate them. It handles all current FIX venues (except RBS RFQ) while rarely differentiating them. It performs deserialization, field parsing, order action interpretation, and constraint/error checking all in one go. It preserves all field locations, so that it can write back to arbitrary fields later if necessary. Since this is a real time application, Reflector does all this without touching the heap.

Every Session Type except DATA requires inspection by the FIX Parser: LOGON, PASS_TKR, PASS_MKR, TAKER, MAKER, & COPY.

The messages within each SessionType are separated further by their direction of transit:

• Outbound messages are requests, since the whole objective of this mechanism is to constrain the trader under the weight of risk limits.
• Inbound messages are updates, as the venue is, by definition, a source of truth.

Discipline

Reflector is only allowed to alter the semantics of outbound FIX messages.

When it alters them, it always alters in the direction of voiding an order action (TAKER), voiding an execution (MAKER), or changing passwords (LOGON, PASS_TKR, PASS_MKR). Reflector shall never change the identity of a quote, order, or execution. On inbound FIX messages, the only fields that Reflector is allowed to alter are Text[58] and Checksum[10]. This is predicated on the assumption that text fields have no semantics.

Parser behaviour necessarily varies depending on the 

Session Type

Logon

Outbound

On the outbound direction of a session in logon state, the only allowed messages are Logon[A] and Logout[5]. Logon[A] messages are inspected. Logout[5] messages are ignored. If any other message is received, the result is session termination. On an outbound Logon[A] message, a credential is deduced and looked up using the ordered triple { ExchangeCode, COMP_ID, SUB_ID }.

If a credential is not found, or if the credential is disabled, or if any risk pools containing the credential is in a UNPLUGGED state, or if password translation is enabled and password match failed, then the session is terminated. Otherwise, the message passes through.

Inbound

On the inbound direction of a session in logon state, the only allowed messages are Logon[A] and Logout[5]. Logon[A] messages are inspected. Logout[5] messages are ignored. If any other message is received, the result is session termination.

On an inbound Logon[A] message, a credential is deduced and looked up using the ordered triple { ExchangeCode, COMP_ID, SUB_ID }. If a credential is not found, or if the credential is disabled, or if any risk pools containing the credential is in a UNPLUGGED state, the session is terminated. Otherwise, the message passes through, and the session is bound to the credential, inheriting its SessionType.

Password Change

Outbound

EBS & Reuters have a unique password changing process whereby traders must log in to change passwords with a UserRequest[BE] message. The SessionTypes PASS_TKR & PASS_MKR handle this contingency for PBs who do not wish for their clients to know the real logon passwords:

Inbound

Inbound messages on tcp sessions in password changing mode are completely unscreened with one exception: on detection of Logon[A] message, the stream terminates immediately.

Taker

On an outbound taker stream, potential order actions are inspected.

Outbound

NewOrderSingle[D], QuoteResponse[AJ], & OrderCancelReplaceRequest[G]

Processing Sequence

On an outbound risk-carrying Taker message, the parser acts as if the following events occur in sequence:

1. Attributes are read in.
2. Venue-specific patches are applied.
3. Unsupported features: If any of the following conditions hold, the order action will be blocked. Unless specified, the stated reason for rejection will be serialized as (Z_UNSUPPORTED):
   1. If OrdType[40] has value FOREX_SWAP[G]
   2. If any of these fields are present: Price2[640], OrderQty2[192], SettlDate2[193], AllocAccount[79]
   3. If Symbol[55] (SecurityID[48] in LMAX44) did not resolve to a valid currency pair (Z_PRODUCT_UNKNOWN)
   4. If NoLegs[555] is present and contains any nonzero value
4. Sanity: If any of the following conditions hold, the order action will be blocked. Unless specified, the stated reason for rejection will be serialized as (Z_NON_CONFORMING):
   1. If PossDupFlag[43] or PossResend[97] is present and has value Y
   2. If any of the required fields are missing
   3. If account resolution failed on a credential with multiple overloaded accounts set up (Z_ACCOUNT_UNKNOWN)
   4. For non-market orders, if Price[44] is missing or more than a factor of 2 outside of reference rate (Z_PRICE_RANGE)
   5. If OrderQty[38] did not contain a positive scalar amount (Z_QUANTITY_RANGE)
   6. If Currency[15] is missing on an order referencing a quote (Z_DEALT_CCY_UNKNOWN)
   7. If Currency[15] is present but did not refer to either of the currencies in the symbol (Z_DEALT_CCY_UNKNOWN)
   8. For Spot orders, if a settle date cannot be computed for the state symbol (Z_SETTLE_DATE_UNKNOWN)
   9. For non-Spot orders, if settle date computation failed sanity checks (Z_SETTLE_DATE_UNKNOWN)
   10. If Side[54] contained a value other than BUY[1] or SELL[2]
5. A speculative order state is constructed.

6. Order state is sent to the Risk Instance for assessment. On failure, order action will be blocked with whichever reason it provides.

Taker Blocking

When an outbound taker message is found to be illegal, the following taker block procedure is performed:

• The following fields, if existent, are zero-filled: OrderQty[38], OrderQty2[192], BidSize[134], OfferSize[135], BidSize2[...], OfferSize2[...], LegQty[687], LegOrderQty[685], AllocQty[80], LegAllocQty[271].
• QuoteRespType[694], if existent, will be filled with PASS[6].
• If the blocked message was a OrderCancelReplaceRequest[G], it will be changed to a OrderCancelRequest[F].
• For specific venues, if these actions are insufficient, Reflector will also fill any provided QuoteID[117] with "_".

OrderMassActionRequest[CA]

The only supported MassActionType[1373] is CANCEL[3]. All appearances of that field will be coerced to the supported value.

Inbound

On an inbound taker stream, Reflector accepts updates (including rejects) to live orders and fill notications.

Reflector models live and filled outlays separately. This means that on an ExecutionReport[8], two independent potential updates of separate records could be performed: one to update the state of the live order, another to insert a fill. No attempt is made to track which fill belongs to which order.

ExecutionReport[8] & TradeCaptureReport[AE]

A TradeCaptureReport[AE] is a pure fill update, uniquely identiable by its ExecID[17].

A ExecutionReport[8] is a potential TradeCaptureReport[AE], plus a mandatory live order state update; where the fill portion is identified by the same ExecID[17] and the live portion is identified by one or more of ClOrdID[11], OrigClOrdID[41], or QuoteRespID[693].
If Text[58] exists, and Reflector has previously blocked the identified order, then it's content will be replaced by Reflector's ErrorCode.

OrderMassCancelReport[r] & OrderCancelReject[9]

On OrderMassCancelReport[r], on every ClOrdID[11] and OrigClOrdID[41] observed, the corresponding live order is looked up and invalidated. On OrderCancelReject[9], no order actions are taken; but if fields ClOrdID[11] and Text[58] exist, and Reflector has previously blocked an order identified by ClOrdID[11], then the value of Text[58] will be replaced by Reflector's ErrorCode.

Reject[3] & BusinessMessageReject[j]

Reject[3] & BusinessMessageReject[j] are handled in the exact same way. If a corresponding live order is found when RefSeqNum[45] will be looked up, it will be invalidated. Additionally, if Reflector has previously blocked an order identified by RefSeqNum[45], then the value of Text[58], if it exists, will be replaced by Reflector's ErrorCode.

Maker

Outbound

ExecutionReport[8] & ExecutionAcknowledgement[BN]

Maker Blocking

Inbound

ExecutionReport[8] & ExecutionAcknowledgement[BN]

DontKnowTrade[Q]

OrderTimeOut[OT] & Currenex OrderTimeOut[U3]

Reject[3] & BusinessMessageReject[j]

Copy