Imported from previous forum
Hi all,
And a second question that has been bothering me for a while. I could not find a transition matrix for this sequence anywhere in the FIX documentation. There are plenty of them dealing with homogeneous messages but not one for OrderCancelReplace followed by a OrderCancel.
Here is the sequence and the following connectivity setup: buy-side <-> intelligent bridge <-> sell-side
in0 bridge - NewOrderSingle clOrdId (X), 100@15.67
out0 bridge - ExecutionReport NEW
in1 bridge - CancelReplace (Y,X) amended quantity to 50
in2 bridge - Cancel (Z,X)
???
I interpret this as buy-side sending an amend and then immediately wanting to cancel the entire order. Is this a valid scenario? I think it is.
What should be the responses the buy-side would expect from the bridge in these 2 situations:
a) the CancelReplace ACCEPT crosses the Cancel as bridge sends it to the downstream system
b) the downstream sell-side receives the CancelReplace and Cancel never having an opportunity to send a Pending CancelReplace. Sebsequently, it sends no CancelReplace updates to the bridge but rather an Order Cancel related messages only.
Thanks for any ideas on how to approach solving these issues particularly as they relate to clOrdId and origClOrdId or the CancelReplace and Cancel responses.
Andrzej
Hi Andrzej,
And a second question that has been bothering me for a while. I could
not find a transition matrix for this sequence anywhere in the FIX
documentation. There are plenty of them dealing with homogeneous
messages but not one for OrderCancelReplace followed by a OrderCancel.Here is the sequence and the following connectivity setup: buy-side ↔
intelligent bridge ↔ sell-sidein0 bridge - NewOrderSingle clOrdId (X), 100@15.67
out0 bridge - ExecutionReport NEW
in1 bridge - CancelReplace (Y,X) amended quantity to 50
in2 bridge - Cancel (Z,X) ???I interpret this as buy-side sending an amend and then immediately
wanting to cancel the entire order. Is this a valid scenario? I
think it is.
Have a look at the answer of Kevin English in thread “new clorderid in cxl message” in the “ECNs, Exchanges” forum. He points out that the chaining should be a bit different here:
in1 bridge - CancelReplace(Y,X)
in2 bridge - Cancel(Z,Y)
Since the sell side is aware that it changed the order by the replace, it should refer to this latest request using its ClOrdID=Y (not X).
Cheers, Jörg
Hi Andrzej,
And a second question that has been bothering me for a while. I could
not find a transition matrix for this sequence anywhere in the FIX
documentation. There are plenty of them dealing with homogeneous
messages but not one for OrderCancelReplace followed by a OrderCancel.Here is the sequence and the following connectivity setup: buy-side
↔ intelligent bridge ↔ sell-sidein0 bridge - NewOrderSingle clOrdId (X), 100@15.67 out0 bridge -
ExecutionReport NEW in1 bridge - CancelReplace (Y,X) amended quantity
to 50 in2 bridge - Cancel (Z,X) ???I interpret this as buy-side sending an amend and then immediately
wanting to cancel the entire order. Is this a valid scenario? I
think it is.Have a look at the answer of Kevin English in thread “new clorderid in
cxl message” in the “ECNs, Exchanges” forum. He points out that the
chaining should be a bit different here:in1 bridge - CancelReplace(Y,X) in2 bridge - Cancel(Z,Y)
Since the sell side is aware that it changed the order by the replace,
it should refer to this latest request using its ClOrdID=Y (not X).Cheers, Jörg
Hi Jorg,
Thanks for the suggestion, I will take a look at the thread you mentioned. If you don’t mind, I would like to elaborate on your idea though.
The buy side sent a CancelReplace (Y,X) but the bridge just passed that message on to the sell-side without any replies to the buy-side. Consequently, the buy-side does not know if their CancelReplace went through or was rejected before they decide to Cancel the entire order (X).
-
If they sent Cancel (Z,Y), the bridge would interpret it as a logical attempt to cancel the CancelReplace, no? That sequence would be a little out-of-band…
-
If they sent Cancel (Z,X) and at that moment the bridge received a CancelReplace (Y,X) accepted from sell-side, the order(X) would seize to exist and could not be referenced by the (X) in the Cancel request.
Consequently, bridge woudl reject the Cancel with “order does not exist.” -
What would happend if they send Cancel (Z,X) and the bridge still have not received any updates to the CancelReplace (Y,X) it forwarded to the sell-side and the sell-side receives the Cancel before it sends out any CancelReplace updates. Would the sell-side at this point drop the CancelReplace and overwrite it with higher priority Cancel state? This one is really vague to me.
Cheers,
Andrew
[ original email was from Kevin English - kevin.english@citigroup.com ]
Hi Andrzej,
During your recovery processing (only) I believe it is a good idea
to flag all fills as PossResend (Tag=97) as True , thereby putting
the onus on the buy-side to check the ExecID to ensure against
double counting of executions.
See below for comments on queuing of order requests.
thanks
Kevin
Hi Andrzej,
And a second question that has been bothering me for a while. I
could not find a transition matrix for this sequence anywhere in the
FIX documentation. There are plenty of them dealing with homogeneous
messages but not one for OrderCancelReplace followed by a
OrderCancel.Here is the sequence and the following connectivity setup: buy-side
↔ intelligent bridge ↔ sell-sidein0 bridge - NewOrderSingle clOrdId (X), 100@15.67 out0 bridge -
ExecutionReport NEW in1 bridge - CancelReplace (Y,X) amended
quantity to 50 in2 bridge - Cancel (Z,X) ???I interpret this as buy-side sending an amend and then immediately
wanting to cancel the entire order. Is this a valid scenario? I
think it is.Have a look at the answer of Kevin English in thread “new clorderid in
cxl message” in the “ECNs, Exchanges” forum. He points out that the
chaining should be a bit different here:in1 bridge - CancelReplace(Y,X) in2 bridge - Cancel(Z,Y)
Since the sell side is aware that it changed the order by the replace,
it should refer to this latest request using its ClOrdID=Y (not X).Cheers, Jörg
Hi Jorg,
Thanks for the suggestion, I will take a look at the thread you
mentioned. If you don’t mind, I would like to elaborate on your
idea though.The buy side sent a CancelReplace (Y,X) but the bridge just passed
that message on to the sell-side without any replies to the buy-
side. Consequently, the buy-side does not know if their
CancelReplace went through or was rejected before they decide to
Cancel the entire order (X).
- If they sent Cancel (Z,Y), the bridge would interpret it as a logical
attempt to cancel the CancelReplace, no? That sequence would be a
little out-of-band…
this is ok and it is up to the sell-side to either
a. queue up and process multiple order cancel replace requests or ultimately an order cancel request in order
i.e from buy-side perspecitive
Out: Send New Order Single (Tag 11=“A”)
In: Order Accepted (Tag 11=“A”)
Out: Send Order Cancel Replace Request (11=“B”,41=“A”)
Out: Send Order Cancel Replace Request (11=“C”,41=“B”)
Out: Send Order Cancel Replace Request (11=“D”,41=“C”)
Out: Send Order Cancel Request (11=“E”,41=“D”)
In: Replace Accepted (Tag 11=“B”,41=“A”)
In: Replace Accepted (Tag 11=“C”,41=“B”)
In: Replace Accepted (Tag 11=“D”,41=“C”)
In: Cancel Accepted (Tag 11=“E”,41=“D”)
b. reject all order requests on orders that are in a pending state
Out: Send New Order Single (Tag 11=“A”)
In: Order Accepted (Tag 11=“A”)
Out: Send Order Cancel Replace Request (11=“B”,41=“A”)
Out: Send Order Cancel Replace Request (11=“C”,41=“B”)
In: Replace Rejected (11=“C”,41=“B”)
Out: Send Order Cancel Replace Request (11=“D”,41=“B”)
In: Replace Rejected (11=“D”,41=“B”)
Out: Send Order Cancel Request (11=“E”,41=“B”)
In: Cancel Rejected (11=“E”,41=“B”)
In: Replace Accepted (11=“B”,41=“A”)
- If they sent Cancel (Z,X) and at that moment the bridge received a
CancelReplace (Y,X) accepted from sell-side, the order(X) would seize
to exist and could not be referenced by the (X) in the Cancel
request. Consequently, bridge woudl reject the Cancel with “order
does not exist.”
yes that is correct - messages have to be processed in sequence
- What would happend if they send Cancel (Z,X) and the bridge still
have not received any updates to the CancelReplace (Y,X) it forwarded
to the sell-side and the sell-side receives the Cancel before it
sends out any CancelReplace updates. Would the sell-side at this
point drop the CancelReplace and overwrite it with higher priority
Cancel state? This one is really vague to me.
All messages must be processed in sequence, there is no concept of priority . If the order cannot be cancelled because of a previous cancel replace then it is just tough on the buy side.
Cheers,
Andrew
[ original email was from Himanshu Sharma - hsharma@knighttrading.com ]
Hi Andrej,
Such race conditions are always interesting and the answer is trade-off between automated operation and manual operation.
What I suggest is:
- Under normal circumstances, if CancelReplace is under process (means previous order is PendingCancel) all further requests (Cxl, CxlReplace, etc.) on that order should be rejected. Normally CxlReplace operation is pretty fast ( less than 4-5 sec) unless sell-side is expecting ur-out from other centers-of-execution.
- When buy-side traders want to Cxl order IMMIDIATELY/URGENTLY (viz. order Qty is big or Mkt is moving) they call the sell-side trader on the phone to request a manual Cxl of the order, super-ceding all FIX transition diagrams.
HTH
Hi all,
And a second question that has been bothering me for a while. I could
not find a transition matrix for this sequence anywhere in the FIX
documentation. There are plenty of them dealing with homogeneous
messages but not one for OrderCancelReplace followed by a OrderCancel.Here is the sequence and the following connectivity setup: buy-side ↔
intelligent bridge ↔ sell-sidein0 bridge - NewOrderSingle clOrdId (X), 100@15.67 out0 bridge -
ExecutionReport NEW in1 bridge - CancelReplace (Y,X) amended quantity to
50 in2 bridge - Cancel (Z,X) ???I interpret this as buy-side sending an amend and then immediately
wanting to cancel the entire order. Is this a valid scenario? I
think it is.What should be the responses the buy-side would expect from the bridge
in these 2 situations:a) the CancelReplace ACCEPT crosses the Cancel as bridge sends it to the
downstream system
b) the downstream sell-side receives the CancelReplace and Cancel never
having an opportunity to send a Pending CancelReplace. Sebsequently,
it sends no CancelReplace updates to the bridge but rather an Order
Cancel related messages only.Thanks for any ideas on how to approach solving these issues
particularly as they relate to clOrdId and origClOrdId or the
CancelReplace and Cancel responses.Andrzej
Hello Himanshu,
I sincerely appreciate your comments. I have to admit that I agree with you 100%. The race conditions become even more dangerous in architectures where there are mutliple distributed components interacting, each operating in accordance with its own state machine, not necessarily equivalent to any other component’s state machine.
I think the trade-offs are reasonable in this case and rejecting a sebsequent cancel/cancel-replace while order is in “pending” state you do not really control should be acceptable.
Thank you for sharing your thoughts.
Andrzej
Hi Andrej,
Such race conditions are always interesting and the answer is trade-off between automated operation and manual operation.
What I suggest is:
- Under normal circumstances, if CancelReplace is under process (means
previous order is PendingCancel) all further requests (Cxl,
CxlReplace, etc.) on that order should be rejected. Normally
CxlReplace operation is pretty fast ( less than 4-5 sec) unless sell-
side is expecting ur-out from other centers-of-execution.- When buy-side traders want to Cxl order IMMIDIATELY/URGENTLY (viz.
order Qty is big or Mkt is moving) they call the sell-side trader on
the phone to request a manual Cxl of the order, super-ceding all FIX
transition diagrams. HTHHi all,
And a second question that has been bothering me for a while. I could
not find a transition matrix for this sequence anywhere in the FIX
documentation. There are plenty of them dealing with homogeneous
messages but not one for OrderCancelReplace followed by a OrderCancel.Here is the sequence and the following connectivity setup: buy-side
↔ intelligent bridge ↔ sell-sidein0 bridge - NewOrderSingle clOrdId (X), 100@15.67 out0 bridge -
ExecutionReport NEW in1 bridge - CancelReplace (Y,X) amended quantity
to 50 in2 bridge - Cancel (Z,X) ???I interpret this as buy-side sending an amend and then immediately
wanting to cancel the entire order. Is this a valid scenario? I
think it is.What should be the responses the buy-side would expect from the bridge
in these 2 situations:a) the CancelReplace ACCEPT crosses the Cancel as bridge sends it to
the downstream system
b) the downstream sell-side receives the CancelReplace and Cancel
never having an opportunity to send a Pending CancelReplace.
Sebsequently, it sends no CancelReplace updates to the bridge but
rather an Order Cancel related messages only.Thanks for any ideas on how to approach solving these issues
particularly as they relate to clOrdId and origClOrdId or the
CancelReplace and Cancel responses.Andrzej
[ original email was from Shalom Reich - shalom.reich@gs.com ]
Another approach I have seen used is to recognize that there is only ONE “owner” of the order at any moment in time. While the order is making its way to the floor, the sell-side is the “owner” for a short period of time. Once the order reaches the floor, the “owner” is the floor trader (or automated execution system).
At any point in time, the only party that can APPROVE (or reject) the request to modify or cancel the order is the “owner” - because that is the only person/system that knows the actual order status. The other systems in the chain just forward the messages between the originator and the “owner” in both directions - they cannot make decisions.
Shalom
Hi Andrej,
Such race conditions are always interesting and the answer is trade-off between automated operation and manual operation.
What I suggest is:
- Under normal circumstances, if CancelReplace is under process (means
previous order is PendingCancel) all further requests (Cxl,
CxlReplace, etc.) on that order should be rejected. Normally
CxlReplace operation is pretty fast ( less than 4-5 sec) unless sell-
side is expecting ur-out from other centers-of-execution.- When buy-side traders want to Cxl order IMMIDIATELY/URGENTLY (viz.
order Qty is big or Mkt is moving) they call the sell-side trader on
the phone to request a manual Cxl of the order, super-ceding all FIX
transition diagrams. HTH