Identifying an Execution as an event, not as a message.

, ,
1

Imported from previous forum

2

In FIX 4.2 The ExecId[17] and ExecRefId[19] tags refer to the execution message, and not the execution itself, i.e. if a trade generates two different execution messages, they need to have different values for ExecId[17] regardless of the fact they were part of the same execution.

In Fix 4.4 the tag SecondaryExecID[527] seem to suggest that precise use, for an ID generated by the execution system or the matching engine itself.

If the intent is to send to the trader the ID for the transaction, rather than the ID of the messages generated by the transaction, is SecondaryExecID[527] the best match?

Thanks

-C

3

SecondaryExecID is not intended for multiple ID from the same “hop” in the chain. It is more for a buy side to sell side to exhcnage communication where the sell side issues the ExecID to the buy side and also reports back the ExecID issued by the exchange to the sell side.

However, the issue you raise is a very important one and related to the alignment of transactions between the matching engine and the interface. It was already discussed a while ago (http://fixprotocol.org/documents/3005/EEWG%20Recommended%20Best%20Practices%20-%20Phase%201%20V1.0.pdf, Chapter 3.3, page 25) and led to the addition of the FillsGrp in FIX 5. It has a FillExecID (1363) which allows you to report multiple executions within a single ExecutionReport message.

An extension to this concept is now being proposed by a Gap Analysis submitted by the equity options exchange ISE (http://fixprotocol.org/documents/5302/FIX%20Protocol%20Gap%20Analysis%20ISE%20Order%20Handling%20Extensions%20v03.doc) to bundle different event types (not only executions) into a new OrdEventGrp with an OrdEventExecID. A matchinig engine might receive a new stop order, trigger it, partially execute it a few times and finally lock the remainder to a market maker due to best execution regulations. All these events might occur within a single matching engine transaction and so far, there is no way in FIX to convey this atomicity on the interface level. Sending multiple ExecutionReports give the receiver the false impression that there are intermediate results upon which his algo is able to act.

Again, the possibility to align transaction models between the core system and the interface is key to high speed exchange systems. FIX has covered the main gap with FIX 5 already and is now further enhancing this concept. These changes are driven by the performance requirements of exchanges.

FIX 4.x versions are just not designed for high speed transactions and should only be used for order routing scenarios where performance is not key.

Regards,
Hanno.

In FIX 4.2 The ExecId[17] and ExecRefId[19] tags refer to the execution message, and not the execution itself, i.e. if a trade generates two different execution messages, they need to have different values for ExecId[17] regardless of the fact they were part of the same execution.

In Fix 4.4 the tag SecondaryExecID[527] seem to suggest that precise use, for an ID generated by the execution system or the matching engine itself.

If the intent is to send to the trader the ID for the transaction, rather than the ID of the messages generated by the transaction, is SecondaryExecID[527] the best match?

Thanks

-C