Message Routing Details

Message Routing Details – One Firm-to-One Firm (point-to-point)

The following table provides examples regarding the use of SenderCompID(49), TargetCompID(56), DeliverToCompID(128), and OnBehalfOfCompID(115) when using a single point-to-point FIX session between two firms. Assumption (A=sellside, B =buyside):

SenderCompID OnBehalfOfCompID TargetCompID DeliverToCompID
A to B directly A B
B to A directly B A

Message Routing Details – Third Party Message Routing

The FIX Session Protocol supports the ability for a single FIX session to represent multiple counterpaties. This can be in a 1-to-many, many-to-1, or 1-to-1 fashion. In addition, some third parties may be connected to other third parties effectively forming a “chain” of “hops” between the original message initiator and the final message receiver. The SenderCompID(49), OnBehalfOfCompID(115), TargetCompID(56), and DeliverToCompID(128) fields are used for routing purposes.

When a third party sends a message on behalf of another firm (using OnBehalfOfCompID(115)), that third party may optionally add their details to the <NoHops> repeating group. This repeating group builds a “history” of third parties through which the original message was re-transmitted. The <NoHops> repeating group is NOT used to facilitate routing, rather it provides an audit trail of third party involvement to the receiver of a message. An audit trail of intermediary involvement may be a requirement of some regulatory bodies or counterparties. When a third party forwards a message on to the next hop (may be the end point or another third party), that third party can add its hop details to the <NoHops> repeating group (i.e. its SenderCompID(49) as HopCompID(628), its SendingTime as HopSendingTime(629), and the received message’s MsgSeqNum(34) or some other reference as HopRefID(630)).

Note that if OnBehalfOfCompID(115) or DeliverToCompID(128) message source identification/routing is used for a FIX session, then it must be used on all Application messages transmitted via that session accordingly (Reject the message if not).

The following table provides examples regarding the use of SenderCompID(49), TargetCompID(56), DeliverToCompID(128), and OnBehalfOfCompID(115) when using a single FIX session to represent multiple firms. Assumption (A=sellside, B and C=buyside, Q=third party):

SenderCompID OnBehalfOfCompID TargetCompID DeliverToCompID HopCompID HopSendingTime
Send from A to B via Q
1) A sends to Q A Q B
2) Q sends to B Q A B Q A’s SendingTime
B responds to A via Q
1) B sends to Q B Q A
2) Q sends to A Q B A Q B’s SendingTime
Send from A to B *AND* C via Q
1) A sends to Q A Q B
2) Q sends to B Q A B Q A’s SendingTime
3) A sends to Q A Q C
4) Q sends to C Q A C Q A’s SendingTime
B *AND* C send to A via Q
1) B sends to Q B Q A
2) Q sends to A Q B A Q B’s SendingTime
3) С sends to Q С Q A
4) Q sends to A Q C A Q C’s SendingTime

Note that some fields (e.g. ClOrdID on a New Order Single) must be unique for all orders on a given FIX session. Thus when using OnBehalfOfCompID(115) (or DeliverToCompID(128)) addressing, a recommended approach is to prepend OnBehalfOfCompID(115) (or DeliverToCompID(128)) to the original value. Thus if A sends Q ClOrdID value of "123", then Q could specify ClOrdID of "A-123" when sending the message to C to ensure uniqueness.