Imported from previous forum
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.
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.
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.1 (http://www.fixprotocol.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.
[ original email was from Ian Hoenisch - ihoenisch@fastesp.com ]
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:
-
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
-
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.
-
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:
- Keep an internal OrderID for yourself. This makes it easy
- 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.