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.
| Flag | Presence | Field | Type |
|---|---|---|---|
| COMP_ID | Required | SenderCompID[49] | STRING |
| SUB_ID | Optional | SenderSubID[50] | STRING |
| PASSWORD | Optional | Password[554] | STRING |
| NEW_PASSWORD | Optional | NewPassword[925] | STRING |
Password Translation
Password translation is an optional feature where the trader is not provided the venue's FIX logon password. Instead, the trader is provisioned a different password of the same length. On logon, Reflector checks for the fake password. Upon matching, it overwrites the fake password with the real password.
UserRequest[BE]
EBS & Reuters utilize a session-in-session scheme where the inner session must be logged onto using the UserRequest[BE] message. In practice, almost everyone uses the same credentials for the outer and inner sessions. Reflector requires that this be the case, and performs password translation again on the UserRequest[BE] message. Refer below for more details.
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.
| Flag | Presence | Field | Type |
|---|---|---|---|
| COMP_ID | Required | SenderCompID[49] | STRING |
| SUB_ID | Optional | SenderSubID[50] | STRING |
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:
| Message Name | MsgType[35] | Action |
|---|---|---|
| Logon | A | Drop session - outbound risk message with risk implications is banned. |
| NewOrderSingle | D | Drop session - outbound risk message with risk implications is banned. |
| QuoteResponse | AJ | Drop session - outbound risk message with risk implications is banned. |
| NewOrderList | E | Drop session - outbound risk message with risk implications is banned. |
| NewOrderMultileg | AB | Drop session - outbound risk message with risk implications is banned. |
| ExecutionReport | 8 | Drop session - outbound risk message with risk implications is banned. |
| ExecutionAcknowledgement | BN | Drop session - outbound risk message with risk implications is banned. |
| Logout | 5 | Change session type:
|
| everything else | Change new password:
|
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
Outbound
NewOrderSingle[D], QuoteResponse[AJ], & OrderCancelReplaceRequest[G]
OrderMassActionRequest[CA]
Inbound
ExecutionReport[8] & TradeCaptureReport[AE]
OrderMassCancelReport[r] & OrderCancelReject[9]
Reject[3] & BusinessMessageReject[j]
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
Overview
Content Tools