# Cancel/Replace and in-flight modifications **URL:** \ **Category:** General Q&A\ **Tags:** general-qa, xid\_168352, imported\ **Created:** [August 18, 2006, 1:39pm UTC](https://forum.fixtrading.org/t/cancel-replace-and-in-flight-modifications/5548 "2006-08-18T13:39:07Z")\ **Posts on this page:** 6\ **Page:** 1
**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:** [August 18, 2006, 1:39pm UTC](https://forum.fixtrading.org/t/cancel-replace-and-in-flight-modifications/5548/1 "2006-08-18T13:39:07Z")
Imported from previous forum ---
**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:** [August 18, 2006, 1:39pm UTC](https://forum.fixtrading.org/t/cancel-replace-and-in-flight-modifications/5548/2 "2006-08-18T13:39:07Z")
[original email was from Bernt Sandén - [bernt.sanden@om.com](mailto:bernt.sanden@om.com) ] Hi, In an exchange environment order modifications can be done from FIX or via a proprietary protocol. The same member can have one session for FIX and another session for the proprietary protocol. The following problem can arise (We use FIX 4.2): 1. An order is entered via FIX, Price=55 and OrdQty=100 2. The order is changed via the proprietary protocol to 56. 3. An Execution Report drop copy is sent to the FIX client to notify the price change from the proprietary protocol. 4. While the Execution Report is in-flight an order cancel/replace request is sent from the FIX session to modify the volume to 110. The FIX client use the same value for all fields as in the original order except for the volume, that is Price=55 and OrdQty=110. The intention here was to only change the volume, but as the state of the order changed prior to the order cancel/replace and these changes passed each other on the line the price will be changed from 56 to 55 and the OrdQty will be changed to 110. This was definitely not what the FIX client expected to happen. We use FIX 4.2 so we cannot use tag 586 OrigOrdModTime to protect us from in flight modifications. I would prefer if the FIX client explictly can specify which fields to modify. This could be achieved by only sending those fields that are to be changed and not send every field as in the original order. In this case only send OrdQty=110 and skip the price tag. The scenario above is likely to happen in the exchange world so I would like to hear of any possible solution for this problem. In our propriatery protocol the API-client can specify exactly which fields to modify. ---
**Author:** ![jorgthonnes](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.fixtrading.org/jorgthonnes/32/196_2.png) [@jorgthonnes](https://forum.fixtrading.org/u/jorgthonnes)\ **Post date:** [August 18, 2006, 1:57pm UTC](https://forum.fixtrading.org/t/cancel-replace-and-in-flight-modifications/5548/3 "2006-08-18T13:57:27Z")
Hi Bernt, > In an exchange environment order modifications can be done from FIX or > via a proprietary protocol. The same member can have one session for > FIX and another session for the proprietary protocol. > > The following problem can arise (We use FIX 4.2): > > 1. An order is entered via FIX, Price=55 and OrdQty=100 > 2. The order is changed via the proprietary protocol to 56. > 3. An Execution Report drop copy is sent to the FIX client to notify > the price change from the proprietary protocol. Which OrdStatus/ExecType do you use in the drop-copy? > 1. While the Execution Report is in-flight an order cancel/replace > request is sent from the FIX session to modify the volume to 110. > The FIX client use the same value for all fields as in the original > order except for the volume, that is Price=55 and OrdQty=110. > > The intention here was to only change the volume, but as the state of > the order changed prior to the order cancel/replace and these changes > passed each other on the line the price will be changed from 56 to 55 > and the OrdQty will be changed to 110. This was definitely not what > the FIX client expected to happen. Indeed. But the chaining of ClOrdID should prevent this error: NewOrderSingle(ClOrdID\_A) OrderCancelReplaceRequest(ClOrdID\_B,ClOrdID\_A) OrderCancelReplaceRequest(ClOrdID\_C,ClOrdID\_B) … E.g., in your scenario, over the proprietary protocol to equivalent of OrderCancelReplaceRequest(ClOrdID\_C1,ClOrdID\_B) has been sent. The FIX side does not get the ExecReport with the new ClOrdID, so it also sents something like OrderCancelReplaceRequest(ClOrdID\_C2,ClOrdID\_B) This should be rejected since the ClOrdID\_B has already replaced by ClOrdID\_C1. The FIX message to be sent is OrderCancelReject, I am not sure about CxlRejReason: 0 = Too late to cancel 3 = Order already in Pending Cancel or Pending Replace status In this way, the FIX client can be sure to use the newest order state and there is no need to specify the fields to change. IMHO, the keypoint is that the proprietary protocol takes part in the chaining somehow. Cheers, Jörg > We use FIX 4.2 so we cannot use tag 586 OrigOrdModTime to protect us > from in flight modifications. > > I would prefer if the FIX client explictly can specify which fields to > modify. This could be achieved by only sending those fields that are to > be changed and not send every field as in the original order. In this > case only send OrdQty=110 and skip the price tag. > > The scenario above is likely to happen in the exchange world so I would > like to hear of any possible solution for this problem. > > In our propriatery protocol the API-client can specify exactly which > fields to modify. ---
**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:** [August 18, 2006, 3:46pm UTC](https://forum.fixtrading.org/t/cancel-replace-and-in-flight-modifications/5548/4 "2006-08-18T15:46:30Z")
[original email was from Bernt Sandén - [bernt.sanden@om.com](mailto:bernt.sanden@om.com) ] \> Hi Bernt, > > In an exchange environment order modifications can be done from FIX or > > via a proprietary protocol. The same member can have one session for > > FIX and another session for the proprietary protocol. > > > > The following problem can arise (We use FIX 4.2): > > > > 1. An order is entered via FIX, Price=55 and OrdQty=100 > > 2. The order is changed via the proprietary protocol to 56. > > 3. An Execution Report drop copy is sent to the FIX client to notify > > the price change from the proprietary protocol. > > Which OrdStatus/ExecType do you use in the drop-copy? > We use OrdStatus=New ExecType=Replaced > > > 1. While the Execution Report is in-flight an order cancel/replace > > request is sent from the FIX session to modify the volume to 110. > > The FIX client use the same value for all fields as in the original > > order except for the volume, that is Price=55 and OrdQty=110. > > > > The intention here was to only change the volume, but as the state of > > the order changed prior to the order cancel/replace and these changes > > passed each other on the line the price will be changed from 56 to 55 > > and the OrdQty will be changed to 110. This was definitely not what > > the FIX client expected to happen. > > Indeed. But the chaining of ClOrdID should prevent this error: > > NewOrderSingle(ClOrdID\_A) OrderCancelReplaceRequest(ClOrdID\_B,ClOrdID\_A) > OrderCancelReplaceRequest(ClOrdID\_C,ClOrdID\_B) … > > E.g., in your scenario, over the proprietary protocol to equivalent of > > OrderCancelReplaceRequest(ClOrdID\_C1,ClOrdID\_B) > > has been sent. The FIX side does not get the ExecReport with the new > ClOrdID, so it also sents something like > > OrderCancelReplaceRequest(ClOrdID\_C2,ClOrdID\_B) > > This should be rejected since the ClOrdID\_B has already replaced by > ClOrdID\_C1. The FIX message to be sent is OrderCancelReject, I am not > sure about CxlRejReason: > > = Too late to cancel 3 = Order already in Pending Cancel or Pending > Replace status > > In this way, the FIX client can be sure to use the newest order state > and there is no need to specify the fields to change. > > IMHO, the keypoint is that the proprietary protocol takes part in the > chaining somehow. > > Cheers, Jörg > > > We use FIX 4.2 so we cannot use tag 586 OrigOrdModTime to protect us > > from in flight modifications. > > > > I would prefer if the FIX client explictly can specify which fields to > > modify. This could be achieved by only sending those fields that are > > to be changed and not send every field as in the original order. In > > this case only send OrdQty=110 and skip the price tag. > > > > The scenario above is likely to happen in the exchange world so I > > would like to hear of any possible solution for this problem. > > > > In our propriatery protocol the API-client can specify exactly which > > fields to modify. Well the proprietary protocol does not take part in the chaining so the update from the propriatery protocol will look like an unsolicited cancel/replace from market operations (Scenario D20 in the FIX 4,2 spec). So it would look like: 1. New Order Single (ClientOrdid\_A) “Initial order from FIX client” 2. Execution Report (ClientOrdid\_A, ExecType=New, OrdStatus=New) “ER of initial order” 3. Execution Report (ClientOrdId\_A, ExecType=Replaced, OrdStatus=New) “ER of replace from propriatery protocol” 4. Cancel/Replace (OrigClOrdid\_A, ClientOrdid\_B) Update from FIX client ---
**Author:** ![jorgthonnes](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.fixtrading.org/jorgthonnes/32/196_2.png) [@jorgthonnes](https://forum.fixtrading.org/u/jorgthonnes)\ **Post date:** [August 18, 2006, 3:53pm UTC](https://forum.fixtrading.org/t/cancel-replace-and-in-flight-modifications/5548/5 "2006-08-18T15:53:46Z")
[…] > > > 1. An Execution Report drop copy is sent to the FIX client to > > > notify the price change from the proprietary protocol. > > > > Which OrdStatus/ExecType do you use in the drop-copy? > > We use OrdStatus=New ExecType=Replaced According to scenario D20, FIX 4.2, you are referring to below this should be ExecType=Restated since this is unsolicited. We are using Restated in our system, but I was not completely sure whether this correct. Thanks for the pointer 🙂 > > > 1. While the Execution Report is in-flight an order cancel/replace > > > request is sent from the FIX session to modify the volume to 110. > > > The FIX client use the same value for all fields as in the > > > original order except for the volume, that is Price=55 and > > > OrdQty=110. > > > > > > The intention here was to only change the volume, but as the state > > > of the order changed prior to the order cancel/replace and these > > > changes passed each other on the line the price will be changed from > > > 56 to 55 and the OrdQty will be changed to 110. This was definitely > > > not what the FIX client expected to happen. > > > > Indeed. But the chaining of ClOrdID should prevent this error: > > > > NewOrderSingle(ClOrdID\_A) > > OrderCancelReplaceRequest(ClOrdID\_B,ClOrdID\_A) > > OrderCancelReplaceRequest(ClOrdID\_C,ClOrdID\_B) … > > > > E.g., in your scenario, over the proprietary protocol to equivalent of > > > > OrderCancelReplaceRequest(ClOrdID\_C1,ClOrdID\_B) > > > > has been sent. The FIX side does not get the ExecReport with the new > > ClOrdID, so it also sents something like > > > > OrderCancelReplaceRequest(ClOrdID\_C2,ClOrdID\_B) > > > > This should be rejected since the ClOrdID\_B has already replaced by > > ClOrdID\_C1. The FIX message to be sent is OrderCancelReject, I am not > > sure about CxlRejReason: > > > > = Too late to cancel 3 = Order already in Pending Cancel or Pending > > Replace status > > > > In this way, the FIX client can be sure to use the newest order state > > and there is no need to specify the fields to change. > > > > IMHO, the keypoint is that the proprietary protocol takes part in the > > chaining somehow. > > > > Cheers, Jörg > > > > > We use FIX 4.2 so we cannot use tag 586 OrigOrdModTime to protect us > > > from in flight modifications. > > > > > > I would prefer if the FIX client explictly can specify which fields > > > to modify. This could be achieved by only sending those fields that > > > are to be changed and not send every field as in the original order. > > > In this case only send OrdQty=110 and skip the price tag. > > > > > > The scenario above is likely to happen in the exchange world so I > > > would like to hear of any possible solution for this problem. > > > > > > In our propriatery protocol the API-client can specify exactly which > > > fields to modify. > > Well the proprietary protocol does not take part in the chaining so > the update from the propriatery protocol will look like an > unsolicited cancel/replace from market operations (Scenario D20 in > the FIX 4,2 spec). > > So it would look like: > > 1. New Order Single (ClientOrdid\_A) “Initial order from FIX client” > 2. Execution Report (ClientOrdid\_A, ExecType=New, OrdStatus=New) “ER of > initial order” > 3. Execution Report (ClientOrdId\_A, ExecType=Replaced, OrdStatus=New) > “ER of replace from propriatery protocol” > 4. Cancel/Replace (OrigClOrdid\_A, ClientOrdid\_B) Update from FIX client Is it an option for you to change/extend the proprietary protocol on the server side? This may be easier than changing the FIX spec. Cheers, Jörg ---
**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:** [August 18, 2006, 4:18pm UTC](https://forum.fixtrading.org/t/cancel-replace-and-in-flight-modifications/5548/6 "2006-08-18T16:18:50Z")
[original email was from Bernt Sandén - [bernt.sanden@om.com](mailto:bernt.sanden@om.com) ] \> […] > > > > 1. An Execution Report drop copy is sent to the FIX client to > > > > notify the price change from the proprietary protocol. > > > > > > Which OrdStatus/ExecType do you use in the drop-copy? > > > We use OrdStatus=New ExecType=Replaced > > According to scenario D20, FIX 4.2, you are referring to below this > should be ExecType=Restated since this is unsolicited. > > We are using Restated in our system, but I was not completely sure > whether this correct. Thanks for the pointer 🙂 > Sorry I was wrong, we use restated here. > > > > > 1. While the Execution Report is in-flight an order cancel/replace > > > > request is sent from the FIX session to modify the volume to > > > > 110. The FIX client use the same value for all fields as in the > > > > original order except for the volume, that is Price=55 and > > > > OrdQty=110. > > > > > > > > The intention here was to only change the volume, but as the state > > > > of the order changed prior to the order cancel/replace and these > > > > changes passed each other on the line the price will be changed > > > > from 56 to 55 and the OrdQty will be changed to 110. This was > > > > definitely not what the FIX client expected to happen. > > > > > > Indeed. But the chaining of ClOrdID should prevent this error: > > > > > > NewOrderSingle(ClOrdID\_A) > > > OrderCancelReplaceRequest(ClOrdID\_B,ClOrdID\_A) > > > OrderCancelReplaceRequest(ClOrdID\_C,ClOrdID\_B) … > > > > > > E.g., in your scenario, over the proprietary protocol to equivalent > > > of > > > > > > OrderCancelReplaceRequest(ClOrdID\_C1,ClOrdID\_B) > > > > > > has been sent. The FIX side does not get the ExecReport with the new > > > ClOrdID, so it also sents something like > > > > > > OrderCancelReplaceRequest(ClOrdID\_C2,ClOrdID\_B) > > > > > > This should be rejected since the ClOrdID\_B has already replaced by > > > ClOrdID\_C1. The FIX message to be sent is OrderCancelReject, I am > > > not sure about CxlRejReason: > > > > > > = Too late to cancel 3 = Order already in Pending Cancel or Pending > > > Replace status > > > > > > In this way, the FIX client can be sure to use the newest order > > > state and there is no need to specify the fields to change. > > > > > > IMHO, the keypoint is that the proprietary protocol takes part in > > > the chaining somehow. > > > > > > Cheers, Jörg > > > > > > > We use FIX 4.2 so we cannot use tag 586 OrigOrdModTime to protect > > > > us from in flight modifications. > > > > > > > > I would prefer if the FIX client explictly can specify which > > > > fields to modify. This could be achieved by only sending those > > > > fields that are to be changed and not send every field as in the > > > > original order. In this case only send OrdQty=110 and skip the > > > > price tag. > > > > > > > > The scenario above is likely to happen in the exchange world so I > > > > would like to hear of any possible solution for this problem. > > > > > > > > In our propriatery protocol the API-client can specify exactly > > > > which fields to modify. > > > > Well the proprietary protocol does not take part in the chaining so > > the update from the propriatery protocol will look like an > > unsolicited cancel/replace from market operations (Scenario D20 in > > the FIX 4,2 spec). > > > > So it would look like: > > > > 1. New Order Single (ClientOrdid\_A) “Initial order from FIX client” > > 2. Execution Report (ClientOrdid\_A, ExecType=New, OrdStatus=New) “ER > > of initial order” > > 3. Execution Report (ClientOrdId\_A, ExecType=Replaced, OrdStatus=New) > > “ER of replace from propriatery protocol” > > 4. Cancel/Replace (OrigClOrdid\_A, ClientOrdid\_B) Update from FIX > > client > > Is it an option for you to change/extend the proprietary protocol on the > server side? This may be easier than changing the FIX spec. > > Cheers, Jörg Well, the proprietary protocol is used by a number of participants and it might have great impact to change it. Thanks anyway for good comments. Best Regards, Bernt