Scenario F.1.a from the Order State Changes page (https://www.fixtrading.org/online-specification/order-state-changes/) implies that rejections resulting from a duplicate ClOrdID should include information from the original order. I.e. OrdStatus, OrderQty, CumQty & LeavesQty provided in the example rejection are taken from the previous order, not the rejected order.
This approach seems to be based upon the assumption that the two orders are related. Is it acceptable to use values from the rejected order instead?
@rwodonnell2022 what is the rationale for not providing the details of the existing order? Are there technical reasons?
Not technical as such, but the systems receiving the rejection in my case do not handle them correctly given the FIX definition. In the implementation I am working on, we populate the various quantity tags from the existing order, but also instrument identifier tags such as Symbol, SecurityID and SecurityIDSource. Given there is not necessarily any relationship between the existing and new order (except the ClOrdID!), the recipient is confused by the rejection content which may refer to an entirely different instrument.
I suppose the proper way to handle this is for the receiving system to handle OrdRejReason=6 as a special case.
The scenario was created a long time and probably assumed that the order submitter would rather like to know the details of the duplicate order (also because he already has the details of the submitted order). It is a serious error if a ClOrdID value is used more than once for new orders. It may be due to multiple sessions issuing ClOrdID values and getting out of sync. The assumption is always that the submitter is entitled to see the order details of the existing order. Hence the scope of uniqueness for a given ClOrdID is typically not global but within a single session or all sessions of a participant.
You should define in your Rules of Engagement that you are echoing the rejected order and do not retrieve details from the existing order. The recipient of the rejection then has to look for that order on his side. I do not see this as a violation of FIX compliance.
Thank you!
Just to add to what @hanno.klein said, that scenario was part of the FIX Order Matrix since at least FIX 4.1. Back in the 1990s order IDs tend to be much less sophisticated where the uniqueness is only for the particular session and most of us implementing FIX back then didn’t really embed a date-time to the ClOrdID, at most a date. The scenario was an attempt to document what to do if the ClOrdID was inadvertently duplicated.
I would venture to say that today, ClOrdID and OrderID should use some sort of algorithm that ensures uniqueness, many now use some sort of date-time embedded in the ID algorithm or a GUID - this would significantly minimize the possibility of ClOrdID duplicating.
1 Like