|
General Q/A
< Previous Next >
Suggestion: mountains of IDs
John Prewett / Lava Trading
26 Apr 2004 4:56PM ET In FIX.4.4 ExecutionReport, we are now positively overwhelmed with IDs:
1. ClOrdID(11)
2. ExecID(17)
3. ExecRefID(19)
4. OrderID(37)
5. OrigClOrdID(41)
6. SecondaryClOrdID(526)
7. SecondaryExecID(527)
8. SecondaryOrderID(198)
9. ClOrdLinkID(583)
10. ListID(66)
there are quite a few more.....
With order routing systems becoming ever more multi-layered, life starts to become an ID nightmare:
A. A customer originates an order with ClOrdID A.
B. An intermediary order routing organization receives ClOrdID A and assigns it OrderID Z and then creates a child order for 50% of A and passes it to a further routing organization with ClOrdID B.
C. The next intermediary routing organization receives ClOrdID B and assigns it to OrderID Y and also creates a child order for 50% of what it received and passes it to an execution venue with ClOrdID C.
D. The execution venue receives the Order with ClOrdID C, assigns an OrderID X to it and also executes it, giving it ExecID 111.
E. The lowest intermediary routing organization receives ClOrdID C, OrderID Z ExecID 111. It assigns an ExecID 222 and passes back ClOrdID B, OrderID Y, ExecID 222.
F. The next intermediary routing organization receives ClOrdID B OrderID Y ExecID 222 and assigns an ExecID 333 and passes it back ClOrdID A, OrderID Z, ExecID 333 to the customer.
When the customer wants to track what happened to ClOrdID A, he/she has a problem. There is no ability to convey the multi-layered chains of assigned IDs in the FIX message, so the end-to-end information is lost. All the customer can do is to query the next layer down in the hierarchy and so on. Resolving a problem can take an eternity from the customer's perspective.
Maybe we should be considering a different approach whereby these IDs should be repeating fields. So there would be NumClOrdIDs and then a repeating ClOrdID field. As the message passes down the layers, each layer adds 1 to NumClOrdIDs and adds an additional ClOrdID to the end of the list. Similar action for both OrderIDs and ExecIDs. At each layer, an ID is added. In this manner, the entire layered model is available for troubleshooting purposes.
The above suggestion would properly handle multi-layered models without adding:
TertiaryClOrdID
Tertiary OrderID
TertiaryExecID
etc,.
If an intermediary organization wanted to hide the lower or upper layers, it would have to save and restore the list of IDs as necessary.
Comments?
Suggestion: mountains of IDs
John Prewett / Lava Trading 26 Apr 2004 4:56PM ET
|
