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.
|
