Imported from previous forum
Hi,
When issuing an order mass cancel request (OMCR) it is necessary to specify ‘ClOrdID’ which “must be unique amongst the ClOrdID <11> assigned to regular orders, replacement orders, cancel requests, and order mass cancel requests.”
That ‘ClOrdID’ should be sent back in ACK/NAK (order mass cancel report/order cancel reject).
The question is: what ‘ClOrdID’ and ‘OrigClOrdID’ should be used in execution reports that are sent on actual order cancellations provoked by the OMCR above? ‘ClOrdID’ from execution report should become a new identifier of a reported order (even though that order gets cancelled), and if we use the one sent in the OMCR, we end up in many orders with the same ‘ClOrdID’. To avoid that, it seems like the resulting execution reports should have ‘ClOrdID’ equal to ‘OrigClOrdID’, which in turn should be equal to the last identifier used for that order (so, that cancelled order doesn’t change identifier at all).
Unfortunately, this situation is not clear in specs.
Does anyone know the correct behaviour here?
Kind regards,
Igor
[ original email was from John Greenan - john.greenan@alignment-systems.com ]
Here’s an actual example from an anonymised production system that should answer your question…
New order list sent
11:32:59 AM 8=FIX.4.29=37435=E49=BUYSIDE56=SELLSIDE34=31852=20080121-10:32:5910=10197=N50=Buy Side Dealer66=LZM10928394=3433=169=test one68=273=211=LZR500291-167=121=3100=PA55=EDLP.PA48=EDLP.PA22=5107=EURO DISNEY54=260=20080121-10:32:5838=3200040=115=EUR59=011=LZR500293-167=221=3100=L55=BARC.L48=BARC.L22=5107=BARCLAYS54=260=20080121-10:32:5838=1600040=115=GBP59=0
Pending New Messages
11:35:26 AM 8=FIX.4.29=038235=857=Buy Side Dealer34=31949=SELLSIDE56=BUYSIDE52=20080121-10:35:26.3191=SUSPENSE66=LZM109286=011=LZR500291-112=013=114=075=2008012115=EUR17=83411052155=1.000000156=M21=320=022=5150=A31=0151=3200032=038=3200039=A37=120091173606140=1107=EURO DISNEY425=0424=32000426=048=EDLP.PA55=EDLP.PA54=259=058=Pending New63=0120=EUR60=20080121-10:35:2610=007
11:35:26 AM 8=FIX.4.29=037735=857=Buy Side Dealer34=31749=SELLSIDE56=BUYSIDE52=20080121-10:35:26.2821=SUSPENSE66=LZM109286=011=LZR500293-112=013=114=075=2008012115=GBP17=83411050155=1.000000156=M21=320=022=5150=A31=0151=1600032=038=1600039=A37=120091173613740=1107=BARCLAYS425=0424=16000426=048=BARC.L55=BARC.L54=259=058=Pending New63=0120=GBP60=20080121-10:35:2610=114
Order Acknowledgements
11:36:24 AM 8=FIX.4.29=038535=857=Buy Side Dealer34=32449=SELLSIDE56=BUYSIDE52=20080121-10:36:24.7711=SUSPENSE66=LZM109286=011=LZR500291-112=013=114=075=2008012115=EUR17=83411055155=1.000000156=M21=320=022=5150=031=0151=3200032=038=3200039=037=120091173606140=1107=EURO DISNEY425=0424=32000426=048=EDLP.PA55=EDLP.PA54=259=058=Order Accepted63=0120=EUR60=20080121-10:36:2410=013
11:36:24 AM 8=FIX.4.29=038035=857=Buy Side Dealer34=32349=SELLSIDE56=BUYSIDE52=20080121-10:36:24.7621=SUSPENSE66=LZM109286=011=LZR500293-112=013=114=075=2008012115=GBP17=83411054155=1.000000156=M21=320=022=5150=031=0151=1600032=038=1600039=037=120091173613740=1107=BARCLAYS425=0424=16000426=048=BARC.L55=BARC.L54=259=058=Order Accepted63=0120=GBP60=20080121-10:36:2410=114
List cancel message
11:37:06 AM 8=FIX.4.29=11335=K49=BUYSIDE56=SELLSIDE34=32252=20080121-10:37:0610=20297=N50=Buy Side Dealer66=LZM1092860=20080121-10:32:58
Pending cancel messages
11:37:06 AM 8=FIX.4.29=039435=857=Buy Side Dealer34=33149=SELLSIDE56=BUYSIDE52=20080121-10:37:06.6291=SUSPENSE66=LZM109286=011=LZR500291-112=013=114=075=2008012115=EUR17=83411062155=1.000000156=M21=320=022=5150=631=0151=3200032=038=3200039=637=120091173606140=1107=EURO DISNEY425=0424=32000426=048=EDLP.PA55=EDLP.PA54=259=058=Attempting to cancel…63=0120=EUR60=20080121-10:37:0610=020
11:37:06 AM 8=FIX.4.29=038935=857=Buy Side Dealer34=32949=SELLSIDE56=BUYSIDE52=20080121-10:37:06.6091=SUSPENSE66=LZM109286=011=LZR500293-112=013=114=075=2008012115=GBP17=83411060155=1.000000156=M21=320=022=5150=631=0151=1600032=038=1600039=637=120091173613740=1107=BARCLAYS425=0424=16000426=048=BARC.L55=BARC.L54=259=058=Attempting to cancel…63=0120=GBP60=20080121-10:37:0610=135
Cancel Messages
11:37:06 AM 8=FIX.4.29=038135=857=Buy Side Dealer34=33249=SELLSIDE56=BUYSIDE52=20080121-10:37:06.6931=SUSPENSE66=LZM109286=011=LZR500291-112=013=114=075=2008012115=EUR17=83411063155=1.000000156=M21=320=022=5150=431=0151=032=038=3200039=437=120091173606140=1107=EURO DISNEY425=0424=32000426=048=EDLP.PA55=EDLP.PA54=259=058=Order Canceled63=0120=EUR60=20080121-10:37:0610=069
11:37:06 AM 8=FIX.4.29=037635=857=Buy Side Dealer34=33049=SELLSIDE56=BUYSIDE52=20080121-10:37:06.6191=SUSPENSE66=LZM109286=011=LZR500293-112=013=114=075=2008012115=GBP17=83411061155=1.000000156=M21=320=022=5150=431=0151=032=038=1600039=437=120091173613740=1107=BARCLAYS425=0424=16000426=048=BARC.L55=BARC.L54=259=058=Order Canceled63=0120=GBP60=20080121-10:37:0610=173
Hi,
When issuing an order mass cancel request (OMCR) it is necessary to
specify ‘ClOrdID’ which “must be unique amongst the ClOrdID <11>
assigned to regular orders, replacement orders, cancel requests, and
order mass cancel requests.”That ‘ClOrdID’ should be sent back in ACK/NAK (order mass cancel
report/order cancel reject).The question is: what ‘ClOrdID’ and ‘OrigClOrdID’ should be used in
execution reports that are sent on actual order cancellations provoked
by the OMCR above? ‘ClOrdID’ from execution report should become a new
identifier of a reported order (even though that order gets cancelled),
and if we use the one sent in the OMCR, we end up in many orders with
the same ‘ClOrdID’. To avoid that, it seems like the resulting execution
reports should have ‘ClOrdID’ equal to ‘OrigClOrdID’, which in turn
should be equal to the last identifier used for that order (so, that
cancelled order doesn’t change identifier at all).Unfortunately, this situation is not clear in specs. Does anyone know
the correct behaviour here?Kind regards, Igor
Thanks for quick reply!
So, if some “massive” cancellation is used (OMCR 35=q, or ListCancelRequest 35=K), the resulting execution reports look like unsolicited cancellations, right? That is, they contain no OrigClOrdID, only ClOrdID, that in turn means that ClOrdID doesn’t change for actual orders in this scenario.
Hence, the answer to my question: ClOrdID from OMCR should not be used in the resulting execution reports, instead, current ClOrdID of a cancelling order should used.
Here’s an actual example from an anonymised production system that
should answer your question…
…
[ original email was from John Greenan - john.greenan@alignment-systems.com ]
You are correct - to a buy-side OMS the cancels from the sell-side look like unsolicited cancels in response to a 35=K List Cancel Request.
There is no ClOrdId on a 35=K List Cancel Request as you can see in the example I gave. The point is that the list id in tag 66 is used to reference which orders to cancel.
It’s worth noting that a considerable number of buy-side systems do not handle list trading via a 35=E, 35=K workflow and also that several big name sell sides do not handle this workflow either.
I hope that your system will support this workflow!
Thanks for quick reply!
So, if some “massive” cancellation is used (OMCR 35=q, or
ListCancelRequest 35=K), the resulting execution reports look like
unsolicited cancellations, right? That is, they contain no OrigClOrdID,
only ClOrdID, that in turn means that ClOrdID doesn’t change for actual
orders in this scenario.Hence, the answer to my question: ClOrdID from OMCR should not be used
in the resulting execution reports, instead, current ClOrdID of a
cancelling order should used.Here’s an actual example from an anonymised production system that
should answer your question… …
I have the same question, but I’m not sure if I agree with the response. I think the answer (generate unsolicted cancels) is accurate for list cancel requests, but the order mass cancel request is assigned a unique ClOrdID and treated like a new order very much like a normal order cancel request (OrderMassCancelReports are assigned an OrderID). Note, the provided sample messages are for FIX 4.2 which doesn’t even appear to support the order mass cancel request. I assume you’re implementing 4.3 or later? For mass cancelation, I would think that the pending cancel / canceled order execution reports would reference the ClOrdID of the mass cancel request (contain both a ClOrdID and OrigClOrdID). That said, I’m still confused myself since the mass cancel request doesn’t seem to behave like a normal order in a lot of other ways. It also seems like downstream clients might get confused if they start receiving numerous execution reports with the same ClOrdID, but that’s the way it reads to me.
Thanks for quick reply!
So, if some “massive” cancellation is used (OMCR 35=q, or
ListCancelRequest 35=K), the resulting execution reports look like
unsolicited cancellations, right? That is, they contain no OrigClOrdID,
only ClOrdID, that in turn means that ClOrdID doesn’t change for actual
orders in this scenario.Hence, the answer to my question: ClOrdID from OMCR should not be used
in the resulting execution reports, instead, current ClOrdID of a
cancelling order should used.Here’s an actual example from an anonymised production system that
should answer your question… …
My view is that ClOrdID is used in the OrderMassCancelRequest and OrderMassCancelReport to tie the two together, no more, no less. If you then have individual ExecutionReports (ERs) or OrderCancelRejects for each order that was successfully deleted or rejected, there is no reason to deviate from the normal behaviour after issuing individual OrderCancelRequests. This means that you should adhere to the chaining concept for ClOrdID/OrigClOrdID.
The request carries its transaction identifier (ClOrdID) as well as the entity identifier (OrigClOrdID) to say what is to be canceled. The latter does not exist for OrderMassCancelRequest as there is typically more than one entity affected and thus other fields are used to identify them.
The ER carries the identifier for the request in ClOrdID and this is the same value for all ERs resulting from an OrderMassCancelRequest. The ER also carries the entity identifier of what was actually canceled in OrigClOrdID. That is the identifier for a single order.
Hope this helps,
Hanno.
I have the same question, but I’m not sure if I agree with the response.
I think the answer (generate unsolicted cancels) is accurate for list
cancel requests, but the order mass cancel request is assigned a unique
ClOrdID and treated like a new order very much like a normal order
cancel request (OrderMassCancelReports are assigned an OrderID). Note,
the provided sample messages are for FIX 4.2 which doesn’t even appear
to support the order mass cancel request. I assume you’re implementing
4.3 or later? For mass cancelation, I would think that the pending
cancel / canceled order execution reports would reference the ClOrdID of
the mass cancel request (contain both a ClOrdID and OrigClOrdID). That
said, I’m still confused myself since the mass cancel request doesn’t
seem to behave like a normal order in a lot of other ways. It also seems
like downstream clients might get confused if they start receiving
numerous execution reports with the same ClOrdID, but that’s the way it
reads to me.Thanks for quick reply!
So, if some “massive” cancellation is used (OMCR 35=q, or
ListCancelRequest 35=K), the resulting execution reports look like
unsolicited cancellations, right? That is, they contain no
OrigClOrdID, only ClOrdID, that in turn means that ClOrdID doesn’t
change for actual orders in this scenario.Hence, the answer to my question: ClOrdID from OMCR should not be
used in the resulting execution reports, instead, current ClOrdID of a
cancelling order should used.Here’s an actual example from an anonymised production system that
should answer your question… …
My view is that ClOrdID is used in the OrderMassCancelRequest and
OrderMassCancelReport to tie the two together, no more, no less.
So, no influence on further ERs caused by this OrderMassCancelRequest?
The ER carries the identifier for the request in ClOrdID and this is the
same value for all ERs resulting from OrderMassCancelRequest.
Well, you say the opposite now?
It also seems like downstream clients might get
confused if they start receiving numerous execution reports with the
same ClOrdID, but that’s the way it reads to me.
This is what confuses me as well, and that’s actually the original question here.
At the moment I am still interpreting these ERs resulting from OrderMassCancelRequest as unsolicited ERs, as if these orders were cancelled without any request from my side (that is, the requests I haven’t provided new ClOrdIDs with, and it’s actually true, right?).
Because otherwise, if many orders have the same ClOrdID, it’s not possible to differentiate them any longer, and at first place for venue. In this case both sides become stuck in respect to such orders.
Would great to hear more opinions regarding this!
I would say that the proper behavior would be to have the ClOrdID in the ExecutionReports to be set to the OMCR ClOrdID and have the OrgClOrdID be set to the NewOrderSingle or whatever ClOrdID was responsible for the order entering the system.
Does that seem right?
My view is that ClOrdID is used in the OrderMassCancelRequest and
OrderMassCancelReport to tie the two together, no more, no less.So, no influence on further ERs caused by this OrderMassCancelRequest?
The ER carries the identifier for the request in ClOrdID and this is the
same value for all ERs resulting from OrderMassCancelRequest.Well, you say the opposite now?
It also seems like downstream clients might get
confused if they start receiving numerous execution reports with the
same ClOrdID, but that’s the way it reads to me.This is what confuses me as well, and that’s actually the original question here.
At the moment I am still interpreting these ERs resulting from OrderMassCancelRequest as unsolicited ERs, as if these orders were cancelled without any request from my side (that is, the requests I haven’t provided new ClOrdIDs with, and it’s actually true, right?).
Because otherwise, if many orders have the same ClOrdID, it’s not possible to differentiate them any longer, and at first place for venue. In this case both sides become stuck in respect to such orders.
Would great to hear more opinions regarding this!
I believe the confusion comes (once again ) from the fact that ClOrdID is overloaded in FIX as (request) message and entity identifier. The ER has a number of fields that are clearly request identifiers, e.g. OrdStatusReqID, MassStatusReqID. The field ClOrdID explains in its comment in the ER, how the message IDs of quote messages are to be used to populate ClOrdID.
Hence ClOrdID in the ER is always at least a message identifier. For OrderCancel and OrderCancelReplace it then also represents the new entity identifier which will be valid from then on, e.g. for further modifications of the order. Cancellations should lead to a terminal state of orders so that chaining is not really relevant anymore and it is debatable whether a new ClOrdID value should be assigned to a successfully deleted order. An OrderMassCancelRequest is not able to assign new ClOrdID values to each of the orders it deletes.
If the ER is triggered by a request from the recipient of the ER then he should get the request identifier together with the ER. The field ClOrdID is the one to carry the request identifier of an ER triggered by an OrderMassCancelRequest. OrigClOrdID is always an entity identifier and on an ER also always the field identifying the entity that was cancelled (via single or mass request).
An order only temporarily has ClOrdID and OrigClOrdID in the context of order chaining and during an attempt to modify order attributes. Hence you cannot send back an order’s tag 11 and 41. An order always only has one current entity identifier and a list of “used” IDs. The entity identifier is either sent back in ClOrdID (e.g. for an order status request) or in OrigClOrdID (e.g. for an order cancel/replace request). The entity identifier is switched from one value to the next whereby the new value also serves as a message identifier while the request is carried out. Failure means that the value is not switched forward but this does not invalidate the message identifier. The transaction was carried out and happened to fail and can be tracked in the logfile.
A clear separation of (request) message identifier and entity identifier is more or less available for all areas of FIX with the exception of the order where it gets tricky, especially for mass requests.
Then you’d have a whole bunch of Exec Reports carrying the same tag 11 but referring to different orders wouldn’t you, and this is going to cause problems for all existing FIX engines and FIX integrated order management systems.
The correct behaviour as far as I can see is for the OMCR and its associated ack message to have their own OMCR related tag 11, and then the individual exec reports carrying their respective order related Tag 11 tag 41 values.
I would say that the proper behavior would be to have the ClOrdID in the ExecutionReports to be set to the OMCR ClOrdID and have the OrgClOrdID be set to the NewOrderSingle or whatever ClOrdID was responsible for the order entering the system.
Does that seem right?
My view is that ClOrdID is used in the OrderMassCancelRequest and
OrderMassCancelReport to tie the two together, no more, no less.So, no influence on further ERs caused by this OrderMassCancelRequest?
The ER carries the identifier for the request in ClOrdID and this is the
same value for all ERs resulting from OrderMassCancelRequest.Well, you say the opposite now?
It also seems like downstream clients might get
confused if they start receiving numerous execution reports with the
same ClOrdID, but that’s the way it reads to me.This is what confuses me as well, and that’s actually the original question here.
At the moment I am still interpreting these ERs resulting from OrderMassCancelRequest as unsolicited ERs, as if these orders were cancelled without any request from my side (that is, the requests I haven’t provided new ClOrdIDs with, and it’s actually true, right?).
Because otherwise, if many orders have the same ClOrdID, it’s not possible to differentiate them any longer, and at first place for venue. In this case both sides become stuck in respect to such orders.
Would great to hear more opinions regarding this!