Imported from previous forum
[ original email was from John Prewett - jprewett@lavatrading.com ]
I am ashamed to admit that I am being unsure of ClOrdID usage when canceling an order that is in a pending replace state.
Here is a scenario:
->NewOrderSingle(ClOrdID=A)
<-ExecReport(OrdStatus=New; ClOrdID=A)
<-ReplaceRequest(ClOrdID=B; OrigClOrdID=A)
<-CancelRequest(ClOrdID=C; OrigClOrdID=A)
My first question:
Is the CancelRequest bad? I would have expected the CancelRequest to have OrigClOrdID=B. But officially, order A is still alive and so it might be appropriate to try and cancel it.
Now let’s move onto the second issue, which presumes the CancelRequest is acceptable (which I may say I would disagree with).
If the CancelRequest is accepted and the ReplaceRequest is completed first, how do you respond to the CancelRequest?
Example:
->NewOrderSingle(ClOrdID=A)
<-ExecReport(ExecType=New; ClOrdID=A)
<-ReplaceRequest(ClOrdID=B; OrigClOrdID=A)
<-CancelRequest(ClOrdID=C; OrigClOrdID=A)
->ExecReport(ExecType=Replaced; ClOrdID=B; OrigClOrdID=A)
->ExecReport(ExecType=Canceled; ClOrdID=C; OrigClOrdID=?)
Should the final ExecReport indicate OrigClOrdID=A, matching the CancelRequest? If so, surely that would be bad as order A is definitely no longer live.
Should the final ExecReport indicate OrigClOrdID=B? If so, this wouldn’t match the CancelRequest.
I appreciate light being shed upon this darkness.
JohnP
[ original email was from John Prewett - jprewett@lavatrading.com ]
Doh!
Arrows in wrong directions.
Please assume correct directions of arrows based upon message type.
Thanks.
John,
Interesting problem but very common to systems that can make decisions faster then counter parties can respond with the current state of an order.
My guess is that the system generating the order has knowledge that the order is in a replace pending state. I also think that the system must make an assumption that the cancel replace will be processed before the cancel request. So in my opinion the cancel request should attempt to cancel the replaced order 11=B.
I would expect that trying to cancel the original order (11=A) would result in a TLTC reject unless the counter party has some chaining of orders.
To be safe the system could send two cancel requests (probably not well received by the counter party) and normally expect one reject.
Jim
I am ashamed to admit that I am being unsure of ClOrdID usage
when canceling an order that is in a pending replace state. Here
is a scenario:->NewOrderSingle(ClOrdID=A) <-ExecReport(OrdStatus=New; ClOrdID=A) ←
ReplaceRequest(ClOrdID=B; OrigClOrdID=A) <-CancelRequest(ClOrdID=C;
OrigClOrdID=A)My first question: Is the CancelRequest bad? I would have expected the
CancelRequest to have OrigClOrdID=B. But officially, order A is still
alive and so it might be appropriate to try and cancel it.Now let’s move onto the second issue, which presumes the CancelRequest
is acceptable (which I may say I would disagree with). If the
CancelRequest is accepted and the ReplaceRequest is completed first, how
do you respond to the CancelRequest? Example: -NewOrderSingle(ClOrdID=A) <-ExecReport(ExecType=New; ClOrdID=A) ←
ReplaceRequest(ClOrdID=B; OrigClOrdID=A) <-CancelRequest(ClOrdID=C;
OrigClOrdID=A) ->ExecReport(ExecType=Replaced; ClOrdID=B; OrigClOrdID=A)
->ExecReport(ExecType=Canceled; ClOrdID=C; OrigClOrdID=?)Should the final ExecReport indicate OrigClOrdID=A, matching the
CancelRequest? If so, surely that would be bad as order A is definitely
no longer live. Should the final ExecReport indicate OrigClOrdID=B? If
so, this wouldn’t match the CancelRequest.I appreciate light being shed upon this darkness.
JohnP
John,
quick answer on OrigClOrdID.
The spec says “ClOrdID(11) of the previous non rejected order (NOT the initial order of the day) when canceling or replacing an order.” My interpretation of this is that you can only determine whether an order transaction (new, replace, cancel) was rejected or not when you have received an answer (ExecutionReport). In your case this has not happened yet, i.e. B has not been confirmed yet. This would suggest that you cannot use it.
However, the scenarios in Volume 4 suggest differently. If you look at D.2.x you will see that the two requests issued prior to receiving ERs use (Y,X) and (Z,Y). This is the “optimistic” approach I guess. D.2.c shows what to do when things go wrong. The second ER returns (Z,X) and not (Z,Y) because at this point Y has been rejected and X is the last valid ClOrdID. This would answer your second question. If B does not get rejected, the last ER should return B and not A.
So it seems that the sender and receiver both use their “personal” view, possibly being different. The sender progresses from X to Y to Z without knowing whether they will be accepted. The receiver always returns the last one he accepted.
Regards,
Hanno.
I am ashamed to admit that I am being unsure of ClOrdID usage
when canceling an order that is in a pending replace state. Here
is a scenario:->NewOrderSingle(ClOrdID=A) <-ExecReport(OrdStatus=New; ClOrdID=A) ←
ReplaceRequest(ClOrdID=B; OrigClOrdID=A) <-CancelRequest(ClOrdID=C;
OrigClOrdID=A)My first question: Is the CancelRequest bad? I would have expected the
CancelRequest to have OrigClOrdID=B. But officially, order A is still
alive and so it might be appropriate to try and cancel it.Now let’s move onto the second issue, which presumes the CancelRequest
is acceptable (which I may say I would disagree with). If the
CancelRequest is accepted and the ReplaceRequest is completed first, how
do you respond to the CancelRequest? Example: -NewOrderSingle(ClOrdID=A) <-ExecReport(ExecType=New; ClOrdID=A) ←
ReplaceRequest(ClOrdID=B; OrigClOrdID=A) <-CancelRequest(ClOrdID=C;
OrigClOrdID=A) ->ExecReport(ExecType=Replaced; ClOrdID=B; OrigClOrdID=A)
->ExecReport(ExecType=Canceled; ClOrdID=C; OrigClOrdID=?)Should the final ExecReport indicate OrigClOrdID=A, matching the
CancelRequest? If so, surely that would be bad as order A is definitely
no longer live. Should the final ExecReport indicate OrigClOrdID=B? If
so, this wouldn’t match the CancelRequest.I appreciate light being shed upon this darkness.
JohnP
[ original email was from Joseph Horowitz - jhorowitz@aegisoft.com ]
John,
The trader is clearly trying to cancel their order so sending a TLTC, while accurate, wouldn’t necessarily be in the spirit of what the trader wants.
I would humbly suggest that any cancel within the order chain should cancel the currently active open order (last order) in the chain.
Sending a TLTC and an Async-Out on the last order would be OK, but the trading system may alert the trader that his cancel was rejected since the TLTC was received 1st.
Sending an Out response to the last order should be enough to clear the whole chain, since the Replace-Ack message sent prior already indicates that the original order is now done.
Here is the msg sequence I think makes the most sense:
Order A->
<- Order Ack
Replace B ->
Cancel A ->
<- Replace Ack B (this means that ‘A’ is now done, Lava has not seen the cancel yet)
<- Async UR Out, B (the spirit of what the trader wanted)
<- Cancel Ack, A is Out (just for cleanliness)
My 2 cents.
Thanks!
-Joey