new clorderid in cxl message

, ,
1

Imported from previous forum

2

[ original email was from Asim Kaleem - asimletters@yahoo.com ]
Hi,
If a ‘new’ clorderid is sent in cxl message, with tag 41 properly referencing the origclorderid, does it violate any FIX recommendation?(any fix version)
pl help, thanks.

3

Hi, If a ‘new’ clorderid is sent in cxl message, with tag 41 properly
referencing the origclorderid, does it violate any FIX
recommendation?(any fix version) pl help, thanks.

Hi Asim,

every OrderCancelRequest messages has to get a fresh, unique ClOrdID (tag 11). And the OrigClOrdID(tag 41) should refer to the ClOrdID of the initial NewOrderSingle request.

So you are perfectly fine.

Cheers, Jörg

4

[ original email was from Kevin English - kevin.english@citigroup.com ]
Hi all,

Jorg’s statement is correct if applied to a scenario as follows:
Send New Order Single (Tag 11=“ord1”)
Order Accepted
Send Order Cancel Request (Tag 11=“ord1_1” Tag 41=“ord1”)
Cancel Accepted

If however there was an accepted Order Cancel Replace Request
in the interim - the order cancel request tag 41 must
carry the tag 11 value of the Order Cancel Replace Request
NOT the tag 11 value of the Original Order. Like so:

Send New Order Single (Tag 11="ord1")
   Order Accepted
Send Order Cancel Replace Request (Tag 11="ord1_1" Tag 41="ord1")
   Replace Accepted
Send Order Cancel Request (Tag 11="ord1_2" Tag 41="ord1_1")
   Cancel Accepted

An example like this is given in Appendix D13 in the FIX 4.2 spec.

hope this helps!
cheers
Kevin

Hi, If a ‘new’ clorderid is sent in cxl message, with tag 41 properly
referencing the origclorderid, does it violate any FIX
recommendation?(any fix version) pl help, thanks.

Hi Asim,

every OrderCancelRequest messages has to get a fresh, unique ClOrdID
(tag 11). And the OrigClOrdID(tag 41) should refer to the ClOrdID of the
initial NewOrderSingle request.

So you are perfectly fine.

Cheers, Jörg