Asynchronous Cancels in FIX 4.2

, ,
1

Imported from previous forum

2

Hi All,

Can someone suggest can FIX 4.2 support Asynchronous Cancels like when a HF client sends a Cancel Request 35=F before the Execution Report.

Will it be a good idea to persist the New Order Single or simply delay the ExecReport to maintain chance of an Async Cancel message to come in ?

Please advise.

Thanks in advance!

3

Cancel / Cancel-Replace of an order can be sent before receiving any Execution reports because as per FIXProtocol Tag 37 OrderID assigned by sell side is not a required field. Sell side firms which do not want to support HF Clients / Asynchronous Cancels make their assigned OrderId Tag 37 to be required field on Cancel / Calcel-Replace as per their rules of engagement. They don’t understand that HF Clients are not playing a fun game submitting orders and then asynch cancels on it to see flashing colors on their trading blotters - its not disco lights.

Delaying Execution report serves no purpose. Also when an Execution has occured, then sending it across to its destination would be the right thing to do. Unless you are able to modify the execution based on a Cancel / Cancel-Replace. Modifying an execution which occured on the exechange is a violation of securities trading laws.

A totally different case would be the client has asked for throttling the execution reports, Refer : http://fixprotocol.org/discuss/read/66b92936.

Hi All,

Can someone suggest can FIX 4.2 support Asynchronous Cancels like when a HF client sends a Cancel Request 35=F before the Execution Report.

Will it be a good idea to persist the New Order Single or simply delay the ExecReport to maintain chance of an Async Cancel message to come in ?

Please advise.

Thanks in advance!