Cancel/Replaces

, ,
1

Imported from previous forum

2

[ original email was from Terry Murtaugh - murtaugh@world.std.com ]
Having sent a cancel/replace request, how and when do I know for sure that it has been accepted? In 4.0, the order state change matrix in appendix D seems to imply that no status report execution message would be sent with a ordstatus of ‘replaced’ unless I send a a status request message. That implies that I wouldn’t know that the original order was replaced until I started receiving execution reports on the replacement order. Is that correct?

The 4.1 spec has the OrigClOrdID on the execution reports, and has the new ExecType field, and also implies in the order state change appendix that the broker will send ‘replaced’ exectype records, although I couldn’t find that stated as a rule anywhere. Is it a requirement to send a message indicating explicitly that the replace request has been accepted?

3

[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> Having sent a cancel/replace request, how and when do I know for sure that it has been accepted? In 4.0, the order state change matrix in appendix D seems to imply that no status report execution message would be sent with a ordstatus of ‘replaced’ unless I send a a status request message. That implies that I wouldn’t know that the original order was replaced until I started receiving execution reports on the replacement order. Is that correct?

What follows is excerpted from a discussion I had about my interpretation of the state changes in FIX 4.0 Cancel/Replaces. "I" = buy side, "you" = sell-side.

  1. I send you an order with ClOrdID 1, you send me an Execution, OrdStatus New, and assign it OrderID A.
  2. I send you a Cancel/Replace, with ClOrdID 2.
  3. You send me an Execution on ClOrdID 1 OrderID A with OrdStatus Pending Cxl/Replace to acknowledge that you have the cancel/replace and are acting on it.
  4. You send me an Execution on ClOrdID 2 OrderID B or A (You can change the OrderID or leave it the same) of OrdStatus New to tell me you successfully did the change.

Either after step 2 or after step 3 but before step 4 you can reject my change with a Cancel Reject on ClOrdID 2.

I would expect fills to be sent to ClOrdID 1 any time before #4, and to ClOrdID 2 after. Although I don’t think the 4.0 spec forbids it (The 4.1 spec does), I don’t think it would be nice to combine a partial fill with the first Execution on ClOrdID 2.

What happens if after Step 2 but before Step 4 I need to cancel the entire order? Although not specified, it would seem to make the most sense that I send a cancel with ClOrdID 3, OrigClOrdID 1, OrderID A, and you try to cancel whatever you can of the order, sending me partial fills on ClOrdID 1 until you send me an execution on ClOrdID 1 status Canceled. After Step 4 I just send a Cancel on ClOrdID 2 just like a normal order.

What happens if I send a change and then a full cancel, and one of the two rejects? I would hope they could be differentiated by a Cancel Reject on ClOrdID 2 in the case of a reject of the change, and ClOrdID 3 if the full cancel (submitted with ClOrdID 3) rejected.

There’s also the case where I send a full cancel (ClOrdID 3 OrigClOrdID 1) after the change, and you are accepting the change at the same time as I send the cancel on the pre-changed order. What happens then? I’m not sure.

4

[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> The 4.1 spec has the OrigClOrdID on the execution reports, and has the new ExecType field, and also implies in the order state change appendix that the broker will send ‘replaced’ exectype records, although I couldn’t find that stated as a rule anywhere. Is it a requirement to send a message indicating explicitly that the replace request has been accepted?
>

I just reviewed the 4.1 spec, and the state change matrix lists two separate messages - one pending cancel execution, and one replaced execution. I would imagine the first is an ack that the request has been received, and the second indicates it has been completed. Since they are not listed with astrisks, my interpretation is that they are both required. (Provided, obviously, that the operation was successful, otherwise you’d get a Cancel Reject.)