Imported from previous forum
All,
Consider the following scenario:
Msg #1 (Party A to Party B): NewOrderSingle(ClOrdID=1…)
Msg #2 (Party B to Party A): ExecutionReport(ClOrdID=1…)
Msg #3 (Party A to Party B): OrderCancelReplaceRequest(OrigClOrdID=1, ClOrdID=2…)
Msg #4 (Party B to Party A): OrderCancelReject(OrigClOrdID=1, ClOrdID=2…)
Following the above, should Party A send a subsequent order amendments as:
Msg #5 (Party A to Party B): OrderCancelReplaceRequest(OrigClOrdID=1, ClOrdID=2…)
or
Msg #5 (Party A to Party B): OrderCancelReplaceRequest(OrigClOrdID=2, ClOrdID=3…)
I always thought it should be “OrigClOrdID=1, ClOrdID=2” as the previous amend was not accepted. However one of my clients is questioning this and I’d like to canvas the community for reassurance?
[ original email was from Marcondes Farias - mfarias@bmf.com.br ]
Hi Daniel,
actually, none of the above ![]()
You should consider the Scenario where you have
Msg #5 (Party A to Party B): OrderCancelReplaceRequest(OrigClOrdID=1, ClOrdID=3…)
This because the original order was not replaced, so you still must rely on its first ID (1). Then, as you have already sent an orderCancelReplaceRequest that was not sucessfull, you have spent a sequence (2), so now you have to use the new sequence for the ClOrdID(3).
Hope this can help.
Cheers
All,
Consider the following scenario:
Msg #1 (Party A to Party B): NewOrderSingle(ClOrdID=1…) Msg #2
(Party B to Party A): ExecutionReport(ClOrdID=1…) Msg #3 (Party A to
Party B): OrderCancelReplaceRequest(OrigClOrdID=1, ClOrdID=2…) Msg #4
(Party B to Party A): OrderCancelReject(OrigClOrdID=1, ClOrdID=2…)Following the above, should Party A send a subsequent order
amendments as:Msg #5 (Party A to Party B): OrderCancelReplaceRequest(OrigClOrdID=1,
ClOrdID=2…) or Msg #5 (Party A to Party B):
OrderCancelReplaceRequest(OrigClOrdID=2, ClOrdID=3…)I always thought it should be “OrigClOrdID=1, ClOrdID=2” as the previous
amend was not accepted. However one of my clients is questioning this
and I’d like to canvas the community for reassurance?
Daniel,
I agree with Marc on this. To elaborate further, When you generate a fresh cxl/rep req, it must contain a new unique tag 11 irrespective of previous req being accepted/rejected/pending; And for tag 41, it must generally contain the last accepted order ID for that order though not strictly as per fix.
Regards,
Sunil
Hi Daniel,
I agree with Marc too.
Msg #5 (Party A to Party B): OrderCancelReplaceRequest(OrigClOrdID=1, ClOrdID=3…)
Pls check the follwing rules:
-
The order sender (in your case is Party A) should chain client order ids on an ‘optimistic’ basis, i.e. set the OrigClOrdID <41> to the last non rejected ClOrdID <11> sent
-
The order receiver (in your case is Party B) should chain client order ids on a ‘pessimistic’ basis, i.e. set the OrigClOrdID <41> on execution reports that convey the receipt or succesful application of a cancel/replace and Order Cancel Reject <9> messages to be the last ‘accepted’ ClOrdID <11>
The protocol supports the chaining of multiple cancel/replace requests,
but it’s depend on you to support this functionality. For the simplicity, we process Amend or Cancel request one at a time (i.e., if one request is in pending state, we reject next subsequence request) and we also restrict on the field such as client can amend only the Price or OrdQty field.
Regards,
TUN
All,
Consider the following scenario:
Msg #1 (Party A to Party B): NewOrderSingle(ClOrdID=1…) Msg #2
(Party B to Party A): ExecutionReport(ClOrdID=1…) Msg #3 (Party A to
Party B): OrderCancelReplaceRequest(OrigClOrdID=1, ClOrdID=2…) Msg #4
(Party B to Party A): OrderCancelReject(OrigClOrdID=1, ClOrdID=2…)Following the above, should Party A send a subsequent order
amendments as:Msg #5 (Party A to Party B): OrderCancelReplaceRequest(OrigClOrdID=1,
ClOrdID=2…) or Msg #5 (Party A to Party B):
OrderCancelReplaceRequest(OrigClOrdID=2, ClOrdID=3…)I always thought it should be “OrigClOrdID=1, ClOrdID=2” as the previous
amend was not accepted. However one of my clients is questioning this
and I’d like to canvas the community for reassurance?