Order ID when routing through third pary

, ,
1

Imported from previous forum

2

[ original email was from Donald Mendelson - dmendelson@capital-mkts.com ]
The FIX 4.2 document is explicit about the use of SenderCompID, TargetCompID, DeliverToCompID, and OnBehalfOfCompID when routing orders through a third party, but how should ClOrdID and OrderID be used in that case?

The order originator A sets ClOrdId to his ID. Then the third party Q also assigns an order ID and forwards the order to firm B. Presumably, Q sets ClOrdID to his order ID in the message to B. The problem is that A’s order ID is now lost at firm B unless Q keeps a cross-reference and looks it up for every message.

For execution reports there is a SecondaryOrderID for an extra ID, but there doesn’t seem to be an equivalent for orders. Is there a way to forward a customer’s order ID with your own to another party?

3

[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> The FIX 4.2 document is explicit about the use of SenderCompID, TargetCompID, DeliverToCompID, and OnBehalfOfCompID when routing orders through a third party, but how should ClOrdID and OrderID be used in that case?
>
> The order originator A sets ClOrdId to his ID. Then the third party Q also assigns an order ID and forwards the order to firm B. Presumably, Q sets ClOrdID to his order ID in the message to B. The problem is that A’s order ID is now lost at firm B unless Q keeps a cross-reference and looks it up for every message.
>
> For execution reports there is a SecondaryOrderID for an extra ID, but there doesn’t seem to be an equivalent for orders. Is there a way to forward a customer’s order ID with your own to another party?

My understanding is that some of the firms doing OnBehalfOfCompID/DeliverToCompID routing are not really wanting to get involved with the application message flow and order state changes, they just effectively operate a frame switching network to route messages virtually unchanged. I.e. all they do is switch around the Sender, Target, OnBehalfOf, and DeliverTo fields.

This is a potential problem. For instance, parties A and C are sending orders to party B through party Q. Imagine the following:

A sends:
SenderCompID=A
TargetCompID=Q
DeliverToCompID=B
ClOrdID=1

C sends:
SenderCompID=C
TargetCompID=Q
DeliverToCompID=B
ClOrdID=1

This means that B receives two messages:

SenderCompID=Q
OnBehalfOfCompID=A
TargetCompID=B
ClOrdID=1

SenderCompID=Q
OnBehalfOfCompID=C
TargetCompID=B
ClOrdID=1

Note that the ClOrdIDs are identical! This likely will cause B to reject the second order.

Now I see two ways around it:

  1. Require that ClOrdID only be unique for a given OnBehalfOfCompID. I really dislike this option.

  2. Require that the central hub do some kind of mapping to keep ClOrdIDs unique from every client routing orders to the ECN/Exchange.

Now this actually isn’t that hard, and it does not require storing state. What Q can do when it receives:

SenderCompID=A
TargetCompID=Q
DeliverToCompID=B
ClOrdID=1

It sends to B:

SenderCompID=Q
OnBehalfOfCompID=A
TargetCompID=B
ClOrdID=A-1

When B responds with an Execution Report, Q will strip off the "A-". This guarantees that every ClOrdID that B sees will be unique. Even if A and C send ClOrdID=1, B will see "A-1" and "C-1".

Further, it is stateless. No state is kept on Q. So if client A calls up B asking about an order with ClOrdID=1, B will know that the order got mapped to ClOrdID=A-1 and can look it up appropriately.

This same issue applies in reverse. If A is routing orders to B and D, it is possible B and D could use the same OrderID or ExecID. Hence Q needs to make sure that A sees only unique OrderIDs and ExecIDs. And if A wishes to DK a trade, Q needs to map the appropriate fields back to B and D by stripping off the leading CompID and dash.

Now low-level message switching using OnBehalfOfCompID/DeliverToCompID isn’t the only way it can be done. Some firms operate in a service bureau capacity, where they WANT to get involved with the actual message flow, will generally re-assign IDs, and often might do value-added things like FIX to CMS or other protocol conversion. In this case, they may base routing decisions on fields like ExDestination, TargetSubID, or ExecBroker. IDs often get stamped in several places along the chain, and as you said, SecondaryOrderID is useful for those purposes. Already I know of one proposal circulating for FIX 4.3 to add a “SecondaryExecID” field so that one can report both one’s own internal ExecID as well as any ExecID assigned by an exchange. I suppose it would be a good thing to consider SecondaryClOrdID as well.

4

[ original email was from Raman Kannan - asset@acm.org ]
Perhaps, another way to handle the
<OnBehalfOfCompID/DeliverToCompID>
for the target OMS FIX protocol handling layer
to add/remove OnBehalfOfCompID/DeliverToCompID
lazily just before hitting the wire.

The business layer of OMS need not bather about FIX protocol conundrums altogether.
OMS will always think it is sending and receiving from targetcompid/sendercompid.

The FIX Protocol ID management Hanlder can
intelligently introduce this based on a
lookup.

This is how we have implemented.

Out of curiosity, why would any OMS be interested
in dealing with these other FIX routing ids?

Thank you

RK