Imported from previous forum
Hi,
I have a question regarding the following scenario (FIX 4.2):
- Consider New Order (11=xxx) has been matched.
- Fill is reported on 11=xxx
- Order 11=xxx is replaced. (11=yyy, 41=xxx)
- Exchange cancels previous fill.
My question pertains to the trade cancel sent by the exchange in this scenario :
In terms of FIX, should the trade cancel be sent out on the old client order id (11=xxx) or on the new client order id (11=yyy)?
Kind Regards,
Prateek Jain
Trade cancel will be sent with new client order id (11=yyy) since the order is replaced in your scenario.
Regards
Hi,
I have a question regarding the following scenario (FIX 4.2):
- Consider New Order (11=xxx) has been matched.
- Fill is reported on 11=xxx
- Order 11=xxx is replaced. (11=yyy, 41=xxx)
- Exchange cancels previous fill.
My question pertains to the trade cancel sent by the exchange in this scenario :
In terms of FIX, should the trade cancel be sent out on the old client order id (11=xxx) or on the new client order id (11=yyy)?
Kind Regards,
Prateek Jain
The FIX 4.2 spec page 99 is silent on ClOrdID in this case but defines other fields of the order to be the current ones, not the old ones:
“Note: Data reported in the CumQty, LeavesQty, and AvgPx fields represent the status of the order as of the time of the correction, not as of the time of the originally reported execution.”
Hence I believe 11=yyy is correct although it cannot be used to identify the old ExecutionReport that needs to be canceled. ExecRefID in the ER of the trade cancel maps to the ExecID value of the ER for the fill at the time of the original report.
The current ClOrdID value is relevant when you want to use it as entity identifier to access the order and update the quantity values with the latest ones received in the ER of the trade cancel.
The ER always gives you one or more events that happened to an order as well as the current status (attributes) of the order.
Trade cancel will be sent with new client order id (11=yyy) since the order is replaced in your scenario.
Regards
Hi,
I have a question regarding the following scenario (FIX 4.2):
- Consider New Order (11=xxx) has been matched.
- Fill is reported on 11=xxx
- Order 11=xxx is replaced. (11=yyy, 41=xxx)
- Exchange cancels previous fill.
My question pertains to the trade cancel sent by the exchange in this scenario :
In terms of FIX, should the trade cancel be sent out on the old client order id (11=xxx) or on the new client order id (11=yyy)?
Kind Regards,
Prateek Jain
Hi Prateek,
While I trust and agree with Hanno’s interpretation of the spec, I suggest you consult the documentation of whatever trading system(s) you are connected to. I’ve seen it done both ways - current order attributes and order attributes from the original fill.
The reason for the latter is that some trading systems do trade cancellations and trade editing offline from the main trading engine. Also, some FIX OMS systems will be confused if the order attributes in the trade cancel do not match the order attributes in the original fill (they will consider the trade cancel suspicious or invalid).
Also, pay attention to what those trading systems indicate will be the effect on the values in subsequent ERs for the OrderQty, FilledQty, CumulativeQty and AveragePrice fields. Some will be modified by the trade cancel/edit while others will not.
I hope that helps.
Regards,
Dennis
Hi,
I have a question regarding the following scenario (FIX 4.2):
- Consider New Order (11=xxx) has been matched.
- Fill is reported on 11=xxx
- Order 11=xxx is replaced. (11=yyy, 41=xxx)
- Exchange cancels previous fill.
My question pertains to the trade cancel sent by the exchange in this scenario :
In terms of FIX, should the trade cancel be sent out on the old client order id (11=xxx) or on the new client order id (11=yyy)?
Kind Regards,
Prateek Jain
I concur with Dennis that it can be confusing to see the current state of the order. Many will expect to see what was sent at the time of the trade, just with a different ExecType indicating that this item in the chain of executions is to be removed. The current order status is not the primary purpose of such an ER and requires additional processing to update the order and not just the execution history. Both approaches have their value and the Rules of Engagement should clearly spell out what the receiver will find in the fields. Workflow information is often missing in interface docs. The layouts themselves just do not tell you which fields are filled with which values in which scenarios. The extra documentation usually saves the customer support hotline a lot of calls 
Hi Prateek,
While I trust and agree with Hanno’s interpretation of the spec, I suggest you consult the documentation of whatever trading system(s) you are connected to. I’ve seen it done both ways - current order attributes and order attributes from the original fill.
The reason for the latter is that some trading systems do trade cancellations and trade editing offline from the main trading engine. Also, some FIX OMS systems will be confused if the order attributes in the trade cancel do not match the order attributes in the original fill (they will consider the trade cancel suspicious or invalid).
Also, pay attention to what those trading systems indicate will be the effect on the values in subsequent ERs for the OrderQty, FilledQty, CumulativeQty and AveragePrice fields. Some will be modified by the trade cancel/edit while others will not.
I hope that helps.
Regards,
Dennis
Hi,
I have a question regarding the following scenario (FIX 4.2):
- Consider New Order (11=xxx) has been matched.
- Fill is reported on 11=xxx
- Order 11=xxx is replaced. (11=yyy, 41=xxx)
- Exchange cancels previous fill.
My question pertains to the trade cancel sent by the exchange in this scenario :
In terms of FIX, should the trade cancel be sent out on the old client order id (11=xxx) or on the new client order id (11=yyy)?
Kind Regards,
Prateek Jain