[This message was posted by Ian Hoenisch of ESP Technologies LLC <[EMAIL PROTECTED]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/dc2a57a6 - PLEASE DO NOT REPLY BY MAIL.]
Hallo Hanno, Great paper! Thanks for pointing it out. I would add, or maybe summarize, that most of the time uniqueness depends on three factors: 1. Do you use ClOrdID or OrderId as your unique identifier internal to your organization. If you do use this, then this factors into your choice. If you have a different identifier internally, then you care less about ClOrdID 2. The scope of ClOrdID can be limited to your session and your downstream destination. If the destination (Exchange or Broker) needs a unique per day, then that's what it is. If they need it unique per week, then that's what it is. 3. We have found that there is one exception to this, which is GTC, where some destinations keep orders live until they are cancelled. Usually there is a one time end of year cleanup, so the ClOrdID needs to be kept unique for the current calendar year. I would summarize the best practice is: 1. Keep an internal OrderID for yourself. This makes it easy 2. Create a unique ClOrdID per session, and define the reset based on what that destination of that particular session needs (day, week, year) That should keep you out of trouble. Sincerely, Ian > I would argue that this depends on your market model and "per day" is > more like a minimum. If you have orders that can be valid for more than > a single day, a re-use of ClOrdID after one day will cause problems. > > Another aspect is whether you want ClOrdID to be unique for a given > sender across all products. This might create an artficial bottleneck > for the receiving system so that you prefer uniqueness to be restricted > to a single orderbook (tradable entity). > > The scope of uniqueness can thus not be defined in general and might > differ across FIX usage environments. The issue has been discussed for > exchange environments in a paper compiled by the FIX Global Exchanges & > Markets Committee, chapter > 3.1.1fixprotocol.org/documents/3005/EEWG%20Recommended%20Best%20Practices%20- > %20Phase%201%20V1.0.pdf). > > Regards, Hanno. > > > > A very basic and stupid question: Within a single trading day, the > > > uniqueness of client order id (tag 11/tag41), should it be > > > maintained within a single FIX session (/sendercompID) or within > > > SenderCompID+OnBehalfOfCompID? > > > > > > Thank you for any advice. > > > > It has to be unique per FIX session (SenderCompID + TargetCompID) > > per day. [You can unsubscribe from this discussion group by sending a message to mailto:[EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
