CancelReplaceRequest received when previous not yet processed.. what to do?

, ,
1

Imported from previous forum

2

Hello,

I’m writing a sell side FIX 4.2 app. as a wrapper for our proprietary API. My question is about cancel/replace requests all for the same order.

When I receive a cancel/replace request with, let’s say, ClOrdID=100 I put it in a queue. When a second cancel/replace arrives with OrigClOrdID=100 and ClOrdID=101 before the one with ClOrdID=100 is out of the queue I do not insert this second modification request in the queue but instead overwrite the item with ClOrdID=100 in the queue.

My question is how many execution reports must I send in this case? I am pretty sure I must send one or more of them for both ClOrdID=100 and ClOrdID=101, but what details should be in the answer on ClOrdID=100? How must I tell my API user that 101 caught up on 100?

Or should I reject the one with ClOrdID=101 because i have not processed ClOrdID=100 yet?

Any help is greatly appreciated.

Gunnar
Amsterdam

3

[ original email was from Greg Wood - greg.wood@credit-suisse.com ]
Hi Gunnar,

Appendix D of the 4.2 spec details this scenario (“chaining” of replace requests). D16 details how you should handle the scenario of accepting a new request while a previous request is being processed, with the exact messages you need to send for each CliOrdID. D17 details the scenario of rejecting a new request while the previous request is being processed.

You have the option of choosing which approach to take with your implementation, and you should make sure that you detail which approach is used within your rules of engagement with your counterparts.

From my perspective it is better (i.e less risky) to reject a new request on an already pending transaction. By rejecting a request until you are ready to process a new one you avoid having a build up of messages (takes up memory) that you need to process sequentially when an earlier transaction is cleared. If you experience latency in your environment, causing a delay in returning an ack for a previous request, then you may potentially process a request that was subsequently amended or cancelled due to a fast market.

Buy-sides tend to prefer scenario D16, sell-sides tend to prefer scenario D17.

Regards,

  • Greg

Hello,

I’m writing a sell side FIX 4.2 app. as a wrapper for our proprietary API. My question is about cancel/replace requests all for the same order.

When I receive a cancel/replace request with, let’s say, ClOrdID=100 I put it in a queue. When a second cancel/replace arrives with OrigClOrdID=100 and ClOrdID=101 before the one with ClOrdID=100 is out of the queue I do not insert this second modification request in the queue but instead overwrite the item with ClOrdID=100 in the queue.

My question is how many execution reports must I send in this case? I am pretty sure I must send one or more of them for both ClOrdID=100 and ClOrdID=101, but what details should be in the answer on ClOrdID=100? How must I tell my API user that 101 caught up on 100?

Or should I reject the one with ClOrdID=101 because i have not processed ClOrdID=100 yet?

Any help is greatly appreciated.

Gunnar
Amsterdam

4

Hello Greg,

Thanks very much for the swift answer! I was already afraid that I have too choose between D16/D17. I was only hoping there was another scenario possible as well i.e. that the state transition matrices did not cover all. Because I really would like to send the second received cancel/replace to the exchange and reject the first (even though I sent a pending replace on it already), because after all both are still in my memory and none of them were sent out to the exchange. But I understand now that this is not covered by FIX 42. (Actually seems not really buy side friendly).

I agree with you that my best choice is to reject the second request (D17 scenario), because if you queue them all up all sorts of extra checks and handling needs to be built.

Thanks again!
Gunnar

Hi Gunnar,

Appendix D of the 4.2 spec details this scenario (“chaining” of replace requests). D16 details how you should handle the scenario of accepting a new request while a previous request is being processed, with the exact messages you need to send for each CliOrdID. D17 details the scenario of rejecting a new request while the previous request is being processed.

You have the option of choosing which approach to take with your implementation, and you should make sure that you detail which approach is used within your rules of engagement with your counterparts.

From my perspective it is better (i.e less risky) to reject a new request on an already pending transaction. By rejecting a request until you are ready to process a new one you avoid having a build up of messages (takes up memory) that you need to process sequentially when an earlier transaction is cleared. If you experience latency in your environment, causing a delay in returning an ack for a previous request, then you may potentially process a request that was subsequently amended or cancelled due to a fast market.

Buy-sides tend to prefer scenario D16, sell-sides tend to prefer scenario D17.

Regards,

  • Greg

Hello,

I’m writing a sell side FIX 4.2 app. as a wrapper for our proprietary API. My question is about cancel/replace requests all for the same order.

When I receive a cancel/replace request with, let’s say, ClOrdID=100 I put it in a queue. When a second cancel/replace arrives with OrigClOrdID=100 and ClOrdID=101 before the one with ClOrdID=100 is out of the queue I do not insert this second modification request in the queue but instead overwrite the item with ClOrdID=100 in the queue.

My question is how many execution reports must I send in this case? I am pretty sure I must send one or more of them for both ClOrdID=100 and ClOrdID=101, but what details should be in the answer on ClOrdID=100? How must I tell my API user that 101 caught up on 100?

Or should I reject the one with ClOrdID=101 because i have not processed ClOrdID=100 yet?

Any help is greatly appreciated.

Gunnar
Amsterdam

5

A similar case but I cannot find it in the Order State Change scenarios in the specs. Appendix D.

I can have a NewOrderSingle still in my queue when already a CancelReplaceRequest enters my app. I guess I can use an adaption of D17 in this case and reject the CancelReplaceRequest with reason ‘New still pending’.

Anyone know if this is a correct way to handle this?

Thanks,
Gunnar

Hello Greg,

Thanks very much for the swift answer! I was already afraid that I have too choose between D16/D17. I was only hoping there was another scenario possible as well i.e. that the state transition matrices did not cover all. Because I really would like to send the second received cancel/replace to the exchange and reject the first (even though I sent a pending replace on it already), because after all both are still in my memory and none of them were sent out to the exchange. But I understand now that this is not covered by FIX 42. (Actually seems not really buy side friendly).

I agree with you that my best choice is to reject the second request (D17 scenario), because if you queue them all up all sorts of extra checks and handling needs to be built.

Thanks again!
Gunnar

Hi Gunnar,

Appendix D of the 4.2 spec details this scenario (“chaining” of replace requests). D16 details how you should handle the scenario of accepting a new request while a previous request is being processed, with the exact messages you need to send for each CliOrdID. D17 details the scenario of rejecting a new request while the previous request is being processed.

You have the option of choosing which approach to take with your implementation, and you should make sure that you detail which approach is used within your rules of engagement with your counterparts.

From my perspective it is better (i.e less risky) to reject a new request on an already pending transaction. By rejecting a request until you are ready to process a new one you avoid having a build up of messages (takes up memory) that you need to process sequentially when an earlier transaction is cleared. If you experience latency in your environment, causing a delay in returning an ack for a previous request, then you may potentially process a request that was subsequently amended or cancelled due to a fast market.

Buy-sides tend to prefer scenario D16, sell-sides tend to prefer scenario D17.

Regards,

  • Greg

Hello,

I’m writing a sell side FIX 4.2 app. as a wrapper for our proprietary API. My question is about cancel/replace requests all for the same order.

When I receive a cancel/replace request with, let’s say, ClOrdID=100 I put it in a queue. When a second cancel/replace arrives with OrigClOrdID=100 and ClOrdID=101 before the one with ClOrdID=100 is out of the queue I do not insert this second modification request in the queue but instead overwrite the item with ClOrdID=100 in the queue.

My question is how many execution reports must I send in this case? I am pretty sure I must send one or more of them for both ClOrdID=100 and ClOrdID=101, but what details should be in the answer on ClOrdID=100? How must I tell my API user that 101 caught up on 100?

Or should I reject the one with ClOrdID=101 because i have not processed ClOrdID=100 yet?

Any help is greatly appreciated.

Gunnar
Amsterdam

6

[ original email was from Greg Wood - greg.wood@credit-suisse.com ]
For the record, we take the same approach for pending new (39=A, not usually sent as a message unless requested), pending replace (39=E) and pending cancel (39=6).

Cheers,

  • Greg

A similar case but I cannot find it in the Order State Change scenarios in the specs. Appendix D.

I can have a NewOrderSingle still in my queue when already a CancelReplaceRequest enters my app. I guess I can use an adaption of D17 in this case and reject the CancelReplaceRequest with reason ‘New still pending’.

Anyone know if this is a correct way to handle this?

Thanks,
Gunnar

Hello Greg,

Thanks very much for the swift answer! I was already afraid that I have too choose between D16/D17. I was only hoping there was another scenario possible as well i.e. that the state transition matrices did not cover all. Because I really would like to send the second received cancel/replace to the exchange and reject the first (even though I sent a pending replace on it already), because after all both are still in my memory and none of them were sent out to the exchange. But I understand now that this is not covered by FIX 42. (Actually seems not really buy side friendly).

I agree with you that my best choice is to reject the second request (D17 scenario), because if you queue them all up all sorts of extra checks and handling needs to be built.

Thanks again!
Gunnar

Hi Gunnar,

Appendix D of the 4.2 spec details this scenario (“chaining” of replace requests). D16 details how you should handle the scenario of accepting a new request while a previous request is being processed, with the exact messages you need to send for each CliOrdID. D17 details the scenario of rejecting a new request while the previous request is being processed.

You have the option of choosing which approach to take with your implementation, and you should make sure that you detail which approach is used within your rules of engagement with your counterparts.

From my perspective it is better (i.e less risky) to reject a new request on an already pending transaction. By rejecting a request until you are ready to process a new one you avoid having a build up of messages (takes up memory) that you need to process sequentially when an earlier transaction is cleared. If you experience latency in your environment, causing a delay in returning an ack for a previous request, then you may potentially process a request that was subsequently amended or cancelled due to a fast market.

Buy-sides tend to prefer scenario D16, sell-sides tend to prefer scenario D17.

Regards,

  • Greg

Hello,

I’m writing a sell side FIX 4.2 app. as a wrapper for our proprietary API. My question is about cancel/replace requests all for the same order.

When I receive a cancel/replace request with, let’s say, ClOrdID=100 I put it in a queue. When a second cancel/replace arrives with OrigClOrdID=100 and ClOrdID=101 before the one with ClOrdID=100 is out of the queue I do not insert this second modification request in the queue but instead overwrite the item with ClOrdID=100 in the queue.

My question is how many execution reports must I send in this case? I am pretty sure I must send one or more of them for both ClOrdID=100 and ClOrdID=101, but what details should be in the answer on ClOrdID=100? How must I tell my API user that 101 caught up on 100?

Or should I reject the one with ClOrdID=101 because i have not processed ClOrdID=100 yet?

Any help is greatly appreciated.

Gunnar
Amsterdam

7

I am also not going to send the 39=A but am going to reject the CancelReplaceRequest/CancelRequest’s when the NewOrderSingle is still in my queue.

(Again is not very buy side friendly. FIX42 more or less forces me to forward the NewOrderSingle to the exchange even though I have not sent it yet and I receive a CancelRequest for it).

Thanks for the answers!
Gunnar

For the record, we take the same approach for pending new (39=A, not usually sent as a message unless requested), pending replace (39=E) and pending cancel (39=6).

Cheers,

  • Greg

A similar case but I cannot find it in the Order State Change scenarios in the specs. Appendix D.

I can have a NewOrderSingle still in my queue when already a CancelReplaceRequest enters my app. I guess I can use an adaption of D17 in this case and reject the CancelReplaceRequest with reason ‘New still pending’.

Anyone know if this is a correct way to handle this?

Thanks,
Gunnar

Hello Greg,

Thanks very much for the swift answer! I was already afraid that I have too choose between D16/D17. I was only hoping there was another scenario possible as well i.e. that the state transition matrices did not cover all. Because I really would like to send the second received cancel/replace to the exchange and reject the first (even though I sent a pending replace on it already), because after all both are still in my memory and none of them were sent out to the exchange. But I understand now that this is not covered by FIX 42. (Actually seems not really buy side friendly).

I agree with you that my best choice is to reject the second request (D17 scenario), because if you queue them all up all sorts of extra checks and handling needs to be built.

Thanks again!
Gunnar

Hi Gunnar,

Appendix D of the 4.2 spec details this scenario (“chaining” of replace requests). D16 details how you should handle the scenario of accepting a new request while a previous request is being processed, with the exact messages you need to send for each CliOrdID. D17 details the scenario of rejecting a new request while the previous request is being processed.

You have the option of choosing which approach to take with your implementation, and you should make sure that you detail which approach is used within your rules of engagement with your counterparts.

From my perspective it is better (i.e less risky) to reject a new request on an already pending transaction. By rejecting a request until you are ready to process a new one you avoid having a build up of messages (takes up memory) that you need to process sequentially when an earlier transaction is cleared. If you experience latency in your environment, causing a delay in returning an ack for a previous request, then you may potentially process a request that was subsequently amended or cancelled due to a fast market.

Buy-sides tend to prefer scenario D16, sell-sides tend to prefer scenario D17.

Regards,

  • Greg

Hello,

I’m writing a sell side FIX 4.2 app. as a wrapper for our proprietary API. My question is about cancel/replace requests all for the same order.

When I receive a cancel/replace request with, let’s say, ClOrdID=100 I put it in a queue. When a second cancel/replace arrives with OrigClOrdID=100 and ClOrdID=101 before the one with ClOrdID=100 is out of the queue I do not insert this second modification request in the queue but instead overwrite the item with ClOrdID=100 in the queue.

My question is how many execution reports must I send in this case? I am pretty sure I must send one or more of them for both ClOrdID=100 and ClOrdID=101, but what details should be in the answer on ClOrdID=100? How must I tell my API user that 101 caught up on 100?

Or should I reject the one with ClOrdID=101 because i have not processed ClOrdID=100 yet?

Any help is greatly appreciated.

Gunnar
Amsterdam