Imported from previous forum
[ original email was from John Prewett - jprewett@lavatrading.com ]
In FIX.4.4 ExecutionReport, we are now positively overwhelmed with IDs:
- ClOrdID(11)
- ExecID(17)
- ExecRefID(19)
- OrderID(37)
- OrigClOrdID(41)
- SecondaryClOrdID(526)
- SecondaryExecID(527)
- SecondaryOrderID(198)
- ClOrdLinkID(583)
- 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?
[ original email was from John Greenan - john.greenan@alignment-systems.com ]
I’d like to add a couple of points to the ideas raised. First, I agree that walking a tree (find order A, then find the order id that it replaces, then find that replaced order, find the order id it replaces…and so on) to find the complete history of an order is an unwelcome chore when supporting FIX.
By adding a repeating group of every order id this would be helpful in that you can immediately get to the nth order by looking for the nth member of the repeating group.
I’d modify this proposal slightly by adding in a new datatype of uniqueidentifier which would then be used in as for the order id. The benefit of this is that by having genuinely unique order ids across sessions, clients, engines, days (whatever) the process of searching databases and log files for order ids would be much simpler. The order id would then be generated using a standard tool (such as CoCreateGuid in the windows OLE32.DLL).
This would make order ids not human readable (such as 32EEAEE2F42248de85E71185926C9E0B) but genuinely unique, without requiring any centralisation of order id assignment.
For more about how/what a guid is have a look at www.dsps.net/uuid.html or http://hegel.ittc.ukans.edu/topics/internet/internet-drafts/draft-l/draft-leach-uuids-guids-01.txt
[ original email was from John Prewett - jprewett@lavatrading.com ]
It’s not difficult to create a guaranteed unique OrderID and this is a perfectly good solution for a multi-hop order that is simply passed along intact.
What it doesn’t solve is the issue where an order (call it the grandparent) arrives at a hop and is split into several lesser orders (call them parent orders) that are sent to identical or different destinations, where they are received and split again (call these child orders) which are then sent to their final execution venues.
Order splitting is becoming more and more common. My original suggestion attempts to handle tracking issues with multi-hop orders that may have been split multiple times.
[ original email was from John Greenan - john.greenan@alignment-systems.com ]
Hi,
I can see the point that relying on others not to make a mistake is a mistake, but already we rely on counterparties to generate unique order ids per day?
To generate a GUID is trivial - there’s a windows API call to generate one (I’m working in a windows shop at the minute, and I cannot remember the unix command, but there is one), so it really does not add risk.
Regards,
John
> I do like the idea about the Globally Unique Identifiers as order ids. But in order to accomplish this, every engine would have to ensure that it is generating that identifier properly. The only problem is the executing party will have no easy way of determining the fact that this identifier is in fact globally unique. Relying on other ppl not to committ mistakes is in itself a mistake.
>
> Kashif Awan,
> kashif.awan@kolachi.net.
> Manager Electronic Connectivity,
> Kolachi Advanced Technologies.
> www.kolachi.com.
>
>
> > I’d like to add a couple of points to the ideas raised. First, I agree that walking a tree (find order A, then find the order id that it replaces, then find that replaced order, find the order id it replaces…and so on) to find the complete history of an order is an unwelcome chore when supporting FIX.
> >
> > By adding a repeating group of every order id this would be helpful in that you can immediately get to the nth order by looking for the nth member of the repeating group.
> >
> > I’d modify this proposal slightly by adding in a new datatype of uniqueidentifier which would then be used in as for the order id. The benefit of this is that by having genuinely unique order ids across sessions, clients, engines, days (whatever) the process of searching databases and log files for order ids would be much simpler. The order id would then be generated using a standard tool (such as CoCreateGuid in the windows OLE32.DLL).
> >
> >
> > This would make order ids not human readable (such as 32EEAEE2F42248de85E71185926C9E0B) but genuinely unique, without requiring any centralisation of order id assignment.
> >
> > For more about how/what a guid is have a look at www.dsps.net/uuid.html or http://hegel.ittc.ukans.edu/topics/internet/internet-drafts/draft-l/draft-leach-uuids-guids-01.txt
> >
> >
> >
>
[ original email was from Shalom Reich - shalom.reich@gs.com ]
I think the key statement to the problem you are describing is:
>
> With order routing systems becoming ever more multi-layered, …
I think these problems exist because many of the processes we are now using originated in a time when physical delivery was the norm and the industry was trying to reduce the (often painful) process of frequent delivery (especially as trading volumes rose). I believe that is the only reason why we need to know about the order as it routed further and further from us.
Contrast this approach with the one I encountered when working on ATM cash machine systems. When the customer sticks his/her card in an ATM that doesn’t belong to the card issuing bank, the link back to the bank may be quite complex - the ATM machine owner bank, a network that the ATM bank belongs to, a clearing network (which may also provide FX services), the network to wich the card issuing bank is connected and (finally) the card issuing bank. Yet the standard approach in this industry is that each pair of parties to a transaction reconcile with one another. This means that the ATM owning bank only needs to know that any card issued by XXX bank should just be routed to my network. The network, in turn, just needs to know that when a card issued by XXX bank arrives forward the transaction to the clearing network etc. etc. If there is any problem with the transaction, each party just deals with its neighbors - the parties that were originally involved in the transaction (from its point of view).
If our industry worked the same way, we would only need to deal with a) our instructing party (the people who told us to do the trade) and b) the executing party (whoever we either did the trade with or who did the trade on our behalf). Again, for settlement we would ONLY deal with the same two parties. This way, we do not need to worry that the executing party actually did half the order against its own account and the other half on the floor of the exchange. We are insulted from these details. The only one who needs to worry about these details is the party that actually split the order - and that is something internal to its own systs/environment.
A bit of a long post . . . 
Comments?
Shalom Reich