Imported from previous forum
The EMEA/GTC Global Technical Committee met on October 18th, 2007 and reviewed the EEWG Phase 1 Gap Analysis Proposal. The specification now enters into a 30 day public comment period in which public review and feedback is encouraged. Once the Public Comment period closes, the Global Technical Committee will meet to review public comments before final approval.
Please post feedback, comments, and questions as replies to this discussion thread.
A link to the EEWG Phase 1 Gap Analysis proposal can be found at
http://fixprotocol.org/documents/3668/
The Public Comment Period closes on November 19th, 2007
[ original email was from Ainhoa Dewisme - ainhoa.dewisme@reuters.com ]
Hello,
I have a question on ClOrdID, OrderID and OrigClOrdID. One of the changes reads as follows:
• The ClOrdID (11) and OrderID (37) fields are redefined as conditionally required in outbound messages related to an order that did not include a ClOrdID
• The OrderID (37) and OrigClOrdID (41) are redefined as conditionally required in all messages that can be related to an order that was not entered with a ClOrdID.
If the ECN does not perform uniqueness of client order ids and a client places 2 orders with the same ClOrdID:
what is the expected behaviour if the client application sends a cancelation providing OrigClOrID (the duplicate ClOrdID) and without providing the OrderID?
Should the client receive one or two Execution Reports?
Ainhoa
The EMEA/GTC Global Technical Committee met on October 18th, 2007 and
reviewed the EEWG Phase 1 Gap Analysis Proposal. The specification now
enters into a 30 day public comment period in which public review and
feedback is encouraged. Once the Public Comment period closes, the
Global Technical Committee will meet to review public comments before
final approval.Please post feedback, comments, and questions as replies to this
discussion thread.A link to the EEWG Phase 1 Gap Analysis proposal can be found at
http://fixprotocol.org/documents/3668/
The Public Comment Period closes on November 19th, 2007
[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
Ainhoa,
If you allow duplicate ClOrdIDs from a single FIX Session and do support the submittal of updates and cancels without an OrderID you are not following the FIX design rules and need to describe your own rules. It is not a practice that the Global Exchanges and Market Committee recognizes.
That being said, there are also other ways to identify one of the orders, e.g. through the OrderQty which is mandatory in the Order Cancel request. However, many exchanges do not recognize that as an identification parameter for a cancelation.
Regards
Rikard
Hello,
I have a question on ClOrdID, OrderID and OrigClOrdID. One of the
changes reads as follows:• The ClOrdID (11) and OrderID (37) fields are redefined as
conditionally required in outbound messages related to an order that did
not include a ClOrdID • The OrderID (37) and OrigClOrdID (41) are
redefined as conditionally required in all messages that can be related
to an order that was not entered with a ClOrdID.If the ECN does not perform uniqueness of client order ids and a client
places 2 orders with the same ClOrdID:what is the expected behaviour if the client application sends a
cancelation providing OrigClOrID (the duplicate ClOrdID) and without
providing the OrderID?Should the client receive one or two Execution Reports?
Ainhoa
The EMEA/GTC Global Technical Committee met on October 18th, 2007 and
reviewed the EEWG Phase 1 Gap Analysis Proposal. The specification now
enters into a 30 day public comment period in which public review and
feedback is encouraged. Once the Public Comment period closes, the
Global Technical Committee will meet to review public comments before
final approval.Please post feedback, comments, and questions as replies to this
discussion thread.A link to the EEWG Phase 1 Gap Analysis proposal can be found at
http://fixprotocol.org/documents/3668/
The Public Comment Period closes on November 19th, 2007
[ original email was from Ainhoa Dewisme - ainhoa.dewisme@reuters.com ]
Hello Rikard,
Thank you very much for your reply.
It is not that I would allow duplicate ClOrdIDs but that customers may (by error) submit 2 orders with the same ClOrdID.
In the EEWG recommended best practices document, it states:
-
Do not check ClOrdIDs and treat duplicates as separate entities (this is understood)
-
OrderID is not mandatory for cancelations.(this is what I understand from current FIX 5.0 specification)
Hence the situation I previously described would still follow the FIX specification and would be a possible real case scenario. Apologies if I have misunderstood your reply or the documents.
Regards
Ainhoa
[ original email was from Rikard Hedberg - rikard.hedberg@omxgroup.com ]
Ainhoa
OK, I see. The Best Practices of the EEWG (now the Global Exchanges and Markets Committee), ment to recognize the fact that marketplaces generally issue their own OrderID and often do not support ClOrdID. It is a fact that many exchanges do not follow the existing FIX standard regarding ClOrdID. As checking ClOrdID contributes to overhead, they do not care about it at all or limit the validation to orders that are still active, sometimes even for the relevant book only (i.e. consider uniqueness per sending FIX Session + ClOrdId + Security).
However, you do need the unique ClOrdID to support immediate actions on a new order - i.e. before the ack with the OrderID comes back (regretting sending it e.g.). As FIX (using FIX Transport) is asynchronous, this may be a new situation for a marketplace who previously had synchronous connection and thereby didn’t have that problem earlier. The best practices tries to recognize that case too.
I think resonable support for ClOrdIDs is relevant for exchanges. I’m also sure that many exchanges will require clients to cater for the uniqueness they need and then provide the additional behavorial rules they find relevant (e.g. your initial question).
Regards
Rikard
Hello Rikard,
Thank you very much for your reply.
It is not that I would allow duplicate ClOrdIDs but that customers may
(by error) submit 2 orders with the same ClOrdID.In the EEWG recommended best practices document, it states:
Do not check ClOrdIDs and treat duplicates as separate entities (this
is understood)OrderID is not mandatory for cancelations.(this is what I understand
from current FIX 5.0 specification)Hence the situation I previously described would still follow the FIX
specification and would be a possible real case scenario. Apologies if I
have misunderstood your reply or the documents.Regards
Ainhoa
[ original email was from Ainhoa Dewisme - ainhoa.dewisme@reuters.com ]
Rikard,
Thanks a lot for your help. It is clear now 
Ainhoa