ClOrdID [11] value in trade capture reports

, ,
1

Imported from previous forum

2

Trade Capture Reports most likely will be generated with delays, hence my view is that the Trade Capture Report should carry the value in client order ID the same as in the associated execution report. This would make both messages consistent.

Scenario:
C -> Order 11=a1
C <- ExecutionReport 11=a1, 17=b1
C <- ExecutionReport Trade 11=a1
C -> CancelReplace 41=a1, 11=a2
C <- ExecutionReport Replaced 11=a2, 41=a1
…
C -> Cancel request 41=a2, 11=a3
C <- ExecutionReport Cancelled 11=a3, 41=a2
…
C <- TradeCaptureReport 11=a1 for 17=b1

An alternative is to use the latest client order ID, however, this adds a level of complexity in ensuring several systems (trading and back office) are in synch.

Should we clarify in the next service pack?

3

Ammended scenario:
Scenario:
C -> Order 11=a1
C <- ExecutionReport New 11=a1
C <- ExecutionReport Trade 11=a1, 17=b1
C -> CancelReplace 41=a1, 11=a2
C <- ExecutionReport Replaced 11=a2, 41=a1
…
C -> Cancel request 41=a2, 11=a3
C <- ExecutionReport Cancelled 11=a3, 41=a2
…
C <- TradeCaptureReport 11=a1 for 17=b1

4

What about using a venue assigned unique identifier that doesn’t change like Tag 37 (OrderID)?

The Trade Capture Report needs to carry the following references

  1. ExecID [17] to point to the Execution Report Trade;
  2. OrdID [37] to point to the exchange / broker associated ID - from client’s prospective this is possibly a chain of order ammendments;
  3. ClOrdID [11] as the associated order has been submitted electronically.

Honoring the ClOrdId [11] an providing the matching the value with the original execution report has advantage of

  1. unambiguously pointing to the appropriate link in the chain of ammendments made by client.
  2. avoids race conditions in synchronizing back office sub-system with real-time trading / matching engine. Depending on the time Trade Capture Report is issued (if the client order is still alive) the current value in tag 11 may refer to any link in the chain and not necessarily be the last in the lifetime of the order. More over, the matching engine may be in he process of handling Cancel Replace request.
5

The incentive is to come up with the best practice in regards to usage of ClOrdID [11] in trade Capture Reports.

The issue is described above, where there are at leat two approaches for populating ClOrdID in Trade Capture Reports.

  1. Refer to ClOrdID [11] value in the matching Execution Reports
  2. Refer to the current ClOrdID [11]

Each have pros and cons, as already outlined.

Note. The issue is unrelated to usage of OrdId [37], which is a valid reference. However, for all transactions related orders submitted electronically ClOrdId [11] must be provided - this is a principle that is used in trading. I will argue that this is a valid requirement in post trading.

6

I have a very clear view on this issue. The field ClOrdID has two meanings on the order handling side (order entry/modification/deletion and execution report). It is a message (request) identifier as well as an entity identifier.

It no longer has both meanings when used on a TCR where it can only be used as an entity identifier pointing to the entity that was traded. This can only be the value carried in the Execution Report at the time of the match and not a new ClOrdID value assigned to the order due to modification requests submitted after the match.

Clearly, ClOrdID is inferior to OrderID when linking trades back to orders as the latter may theoretically also change but is typically kept stable during the lifetime of the order.

Regards,
Hanno.

The incentive is to come up with the best practice in regards to usage of ClOrdID [11] in trade Capture Reports.

The issue is described above, where there are at leat two approaches for populating ClOrdID in Trade Capture Reports.

  1. Refer to ClOrdID [11] value in the matching Execution Reports
  2. Refer to the current ClOrdID [11]

Each have pros and cons, as already outlined.

Note. The issue is unrelated to usage of OrdId [37], which is a valid reference. However, for all transactions related orders submitted electronically ClOrdId [11] must be provided - this is a principle that is used in trading. I will argue that this is a valid requirement in post trading.