# Cascading Cancel Replacements **URL:** \ **Category:** General Q&A\ **Tags:** general-qa, xid\_168033, imported\ **Created:** [July 10, 1999, 12:42am UTC](https://forum.fixtrading.org/t/cascading-cancel-replacements/5130 "1999-07-10T00:42:00Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![nathankugel84\_x](https://avatars.discourse-cdn.com/v4/letter/n/c37758/32.png) [@nathankugel84\_x](https://forum.fixtrading.org/u/nathankugel84_x)\ **Post date:** [July 10, 1999, 12:42am UTC](https://forum.fixtrading.org/t/cascading-cancel-replacements/5130/1 "1999-07-10T00:42:00Z")
Imported from previous forum ---
**Author:** ![nathankugel84\_x](https://avatars.discourse-cdn.com/v4/letter/n/c37758/32.png) [@nathankugel84\_x](https://forum.fixtrading.org/u/nathankugel84_x)\ **Post date:** [July 10, 1999, 12:42am UTC](https://forum.fixtrading.org/t/cascading-cancel-replacements/5130/2 "1999-07-10T00:42:00Z")
When there is more than one cancel replace request for one order send by institution and the broker side has not accepted any of them, but decides to reject the first cancel replace. This means that all consecutive cancel replacements for the same order must be /are implicitly rejected and the valid information is associated with original order. In general we would return to previous valid cancel replacement valid prior to rejected one. e.g. Original Order IBM SELL 2000 Shares @ 111.50 ClientID=SE1 Execution report Accepted IBM SELL 2000 Shares @ 111.50 ClientID=SE1 OrderID=0001 Cancel Replace IBM SELL 1900 Shares @ 111.75 ClientID=SE2 OrigClientID=SE1 Cancel Replace IBM SELL 1800 Shares @ 111.80 ClientID=SE3 OrigClientID=SE2 Cancel Replace IBM SELL 1700 Shares @ 111.85 ClientID=SE4 OrigClientID=SE3 Order cancel Reject ClientID=SE3 In this case a valid information is related to cancel replace request SE2, which is not confirmed yet, and since SE3 is rejected SE4 is rejected implicitly or must be rejected as well. Any objections, thoughts? ---
**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\ **Post date:** [April 11, 2001, 4:12pm UTC](https://forum.fixtrading.org/t/cascading-cancel-replacements/5130/3 "2001-04-11T16:12:00Z")
[original email was from Raman Kannan - [asset@acm.org](mailto:asset@acm.org) ] POSSIBLE COURSE OF ACTION (my opinion or what I would do) In the example below and in my implementation of a buy side, the buy side should not legitimize SE2 until after SE2 is confirmed by the sell side. Sending a second CANCEL REPLACE (SE3) On the original order SE1 will result in more chaos. Perhaps one approach would be to disable CANCEL operation on the buy side once a cancel is issued and seek status on SE1 and/or SE2 for status update if sell side is silent. If SE2 is accepted or if se2 is rejected it is very clear how to proceed to attempt another cancel or just floor it and get on with the biz. -----------------ORIGINAL QUESTION \> When there is more than one cancel replace request for one order send by institution and the broker side has not accepted any of them, but decides to reject the first cancel replace. This means that all consecutive cancel replacements for the same order must be /are implicitly rejected and the valid information is associated with original order. In general we would return to previous valid cancel replacement valid prior to rejected one. e.g. \> \> Original Order IBM SELL 2000 Shares @ 111.50 ClientID=SE1 \> \> Execution report Accepted IBM SELL 2000 Shares @ 111.50 ClientID=SE1 OrderID=0001 \> \> Cancel Replace IBM SELL 1900 Shares @ 111.75 ClientID=SE2 OrigClientID=SE1 \> \> Cancel Replace IBM SELL 1800 Shares @ 111.80 ClientID=SE3 OrigClientID=SE2 \> \> Cancel Replace IBM SELL 1700 Shares @ 111.85 ClientID=SE4 OrigClientID=SE3 \> \> Order cancel Reject ClientID=SE3 \> \> In this case a valid information is related to cancel replace request SE2, which is not confirmed yet, and since SE3 is rejected SE4 is rejected implicitly or must be rejected as well. \> \> Any objections, thoughts? \> ---
**Author:** ![peterwhite86\_x](https://avatars.discourse-cdn.com/v4/letter/p/5f9b8f/32.png) [@peterwhite86\_x](https://forum.fixtrading.org/u/peterwhite86_x)\ **Post date:** [April 12, 2001, 1:10pm UTC](https://forum.fixtrading.org/t/cascading-cancel-replacements/5130/4 "2001-04-12T13:10:00Z")
This is definitely a problematic area. FIX 4.2 App D Example D16 shows the buy-side sending (in the notation of the example below) the second c/r with OrigClOrdID = S2. Some buy-side OMS will not allow the trader to do a cancel/replace if there is already an ‘outstanding’ cancel/replace on the order to avoid such issues occuring. Buy-side traders should be permitted to submit a cancel after an outstanding cancel/replace request since the cancel request overrides the cancel/replace request and is unambiguous in what it means. \> POSSIBLE COURSE OF ACTION (my opinion or what I would do) \> \> In the example below and in my implementation \> of a buy side, the buy side should not \> legitimize SE2 until after SE2 is confirmed \> by the sell side. \> \> Sending a second \> CANCEL REPLACE (SE3) On the original order SE1 \> will result in more chaos. \> \> Perhaps one approach would be to disable \> CANCEL operation on the buy side once a \> cancel is issued and seek status on SE1 and/or \> SE2 for status update if sell side is silent. \> \> If SE2 is accepted or if se2 is rejected \> it is very clear how to proceed to attempt \> another cancel or just floor it and get on \> with the biz. \> \> \> \> -----------------ORIGINAL QUESTION \> \> When there is more than one cancel replace request for one order send by institution and the broker side has not accepted any of them, but decides to reject the first cancel replace. This means that all consecutive cancel replacements for the same order must be /are implicitly rejected and the valid information is associated with original order. In general we would return to previous valid cancel replacement valid prior to rejected one. e.g. \> \> \> \> Original Order IBM SELL 2000 Shares @ 111.50 ClientID=SE1 \> \> \> \> Execution report Accepted IBM SELL 2000 Shares @ 111.50 ClientID=SE1 OrderID=0001 \> \> \> \> Cancel Replace IBM SELL 1900 Shares @ 111.75 ClientID=SE2 OrigClientID=SE1 \> \> \> \> Cancel Replace IBM SELL 1800 Shares @ 111.80 ClientID=SE3 OrigClientID=SE2 \> \> \> \> Cancel Replace IBM SELL 1700 Shares @ 111.85 ClientID=SE4 OrigClientID=SE3 \> \> \> \> Order cancel Reject ClientID=SE3 \> \> \> \> In this case a valid information is related to cancel replace request SE2, which is not confirmed yet, and since SE3 is rejected SE4 is rejected implicitly or must be rejected as well. \> \> \> \> Any objections, thoughts? \> \> \>