Replace request processing received when another replace is pending, which is rejected afterwards

, ,
1

Imported from previous forum

2

[ original email was from ketan shah - ketashah@exchange.ml.com ]
This question is variation of
"D16-One Cancel/replace request is issued followed immediately by another-broker processes sequentially"
in Appedix D "Order State Change Metrices" of FIX version 4.2 Specification Dated "March, 1 2000".

Order is created with ClOrdID "X".

Client sends cancel/replace(Y, X) request. This request is forwarded to exchange(or another system) which does not talk FIX protocol.

Before exchange replies to previous request, client sends another cancel/replace(Z, Y) request.

This request is locally queued.

(If exchange accepts ClOrdID change from X->Y, order’s clOrdID becomes “Y” and second request can be forwarded to exhange as shown in D16.)

However, if exchange REJECTS cancel/replace(Y, X) request, order’s clOrdID becomes “X”. At this stage what can be done to the queued request ?

A. Reject the queued request with OrderCancelReject(Z, Y).

B. Forward the request to exchange/system.
If exchange rejects this change, we can send OrderCancelReject(Z, Y).
However if exchange accepts this change,
B.1. Send ExecutionReport(Z, Y) (Is this valid since clOrdID "Y" itself was rejected and current clOrdID is "X"?)
B.2. Send ExecutionReport(Z, X) (Client asked for Y->Z, but we are reporting X->Z ?)

If the Y->Z is order cancel request instead of replace/cancel, User might want to cancel request immediately, can we forward cancel request to exchange/system even before exchange/system sends reply for X->Y request ?)

I would appreciate your thoughts/comments.
Thanks

Ketan Shah
ketashah@exchange.ml.com

3

Add to this the possibility that cancel/replace (Z, X) could arrive while cancel/replace (Y, X) is pending. Perhaps that could be failed immediately because the client is supposed to use Y instead of X, but as the original poster mentions Y may be rejected anyhow, reverting the order back to X. Also, I think that sending the cancel in immediately (rather than processing them sequentially) might be required for certain business scenarios, so the protocol should accommodate that possibility.

> This question is variation of
> “D16-One Cancel/replace request is issued followed immediately by another-broker processes sequentially”
> in Appedix D “Order State Change Metrices” of FIX version 4.2 Specification Dated “March, 1 2000”.
>
> Order is created with ClOrdID “X”.
>
> Client sends cancel/replace(Y, X) request. This request is forwarded to exchange(or another system) which does not talk FIX protocol.
>
> Before exchange replies to previous request, client sends another cancel/replace(Z, Y) request.
>
> This request is locally queued.
>
> (If exchange accepts ClOrdID change from X->Y, order’s clOrdID becomes “Y” and second request can be forwarded to exhange as shown in D16.)
>
> However, if exchange REJECTS cancel/replace(Y, X) request, order’s clOrdID becomes “X”. At this stage what can be done to the queued request ?
>
> A. Reject the queued request with OrderCancelReject(Z, Y).
>
> B. Forward the request to exchange/system.
> If exchange rejects this change, we can send OrderCancelReject(Z, Y).
> However if exchange accepts this change,
> B.1. Send ExecutionReport(Z, Y) (Is this valid since clOrdID “Y” itself was rejected and current clOrdID is “X”?)
> B.2. Send ExecutionReport(Z, X) (Client asked for Y->Z, but we are reporting X->Z ?)
>
> If the Y->Z is order cancel request instead of replace/cancel, User might want to cancel request immediately, can we forward cancel request to exchange/system even before exchange/system sends reply for X->Y request ?)
>
> I would appreciate your thoughts/comments.
> Thanks
>
> Ketan Shah
> ketashah@exchange.ml.com
>