Use cases for TradeMatchReport(DC)

[robertlau]

It seems to me that TradeMatchReport(DC) is an enhanced TradeCaptureReport (AE) which allows to report trade with complex instruments in a single message. However, there is not much documentation about this message. May I ask the following questions:

(1) Apart from EP150, are there any other documents/recommendations for this message?

(2) FIXimate states TradeMatchReport message “is used by exchanges and ECN’s to report matched trades to central counterparties (CCPs) as an atomic event”. Would like to know if it can use TradeMatchReport for more general purposes, like the way of using TradeCaptureReport or in particular, can it allow an exchange participant to use TradeMatchReport to report a trade with multiple instruments to the exchange?

(3) Question about message flow for TradeMatchReport: I understand a valid message flow is TradeMatchReport / TradeMatchReportAck. Can it also have the following flow:
(i) Party A sends TradeMatchReport to Party B.
(ii) Party B optionally replies TradeMatchReportAck to Party A
(iii) Party B replies TradeMatchReport to Party A; Party B further sends out TradeMatchReport to Party C

And, how about this flow:
(i) Party A sends TradeMatchReport to Party B.
(ii) Party B optionally replies TradeMatchReportAck to Party A
(iii) Party B replies TradeCaptureReport to Party A; Party B further sends out TradeCaptureReport to Party C.

[gtcpm]

@robertlau thanks for the question. The TMR was originally based on requirements between trading and clearing systems to support a single message conveying all results of an atomic match event on the trading side. Unlike the TCR, it supports more than two counterparties that may have participated in the match. In the context of derivatives with complex and simple (leg) instruments matching together, the TMR supports multiple instruments.

The TMR is not intended to report independent trades across multiple instruments, i.e. it is not to be used for “batching” of trades that occur over a period of time. Let me try to answer your questions.

(1) I am not aware of additional documentation for the TMR. It could also be used for regulatory reporting to avoid the recipient having to put the complex strategies back together based on multiple TCRs using the same StrategyLinkID(1851).

(2) Exchange participants can use the TCR and the TrdInstrmtLegGrp component to report a single trade that involves different instruments on the leg level. Can you elaborate on the relationship between the instruments when you say “a trade with multiple instruments”?

(3) Clearinghouses will take the TMR from the exchange and break it down into TCRs sent to the various counterparties who are not supposed to see the other parties involved in the trade. Each counterparty gets trade(s) in a single instrument, one TCR for each instrument.

What is the business purpose of Party B “replying” to Party A with a TMR (or TCR)? Does Party B add any information that was not received from Party A?

[robertlau]

Many thanks for the reply.

In our preliminary thought, there will be two flows: (I) one-party trade reporting; and (II) two-party trade reporting.

(I) One-party trade reporting

Let’s assume two Participants 1 and 2 have come up a strategy trade with different instruments (legs) from different customers/clearing accounts. The participants want to report the strategy trade in a single message to an exchange. An example below:

Our imaginary flow is as below, what messages should be used?

(II) Two-party trade reporting

Let’s assume a participant has come up a strategy trade with different instruments (legs) from different customers/clearing accounts and those customers/clearing accounts belong to the same participant. The participant wants to report the strategy trade in a single message to an exchange. An example below:

Our imaginary flow is as below, what messages should be used?

[gtcpm]

@robertlau, please have a look at the Eurex T7 specification, Chapter 14 TES Trading. It shows how a trade involving multiple instruments and parties can be reported to the exchange with the TradeCaptureReport(35=AE) message. The message layout is not easy to read as the field ordering is optimised for SBE encoding. The key element in the TCR for your use case is the TrdInstrmtLegGrp that contains an instrument, a quantity, a price, a(n) (contra) account and a (contra) party for each leg.

[robertlau]

Many thanks for shedding light on the mapping.

We’ve checked Eurex T7 specification, and it seems for us that the TCR in T7 does not quite fit to our case.

Below is our mapping using TradeCaptureReport(AE) and TradeMatchReport(DC).

(I) For One-party trade reporting(refer to the table above)

If using AE, we try to use TrdInstrmtLegGrp to map our case. We come up with the following mapping:

Two points for the above mapping:

(1) Looks like the highlighted tags in yellow in repeating block #2, #4, #6 are redundant, which cause the mapping is not quite straightforward?

(2) It needs to corelate two repeating blocks into the same security. For example, block 1 and block 2 are having same security and price and qty and therefore these two blocks are referred to the same security. More programming logic is needed in application level.

On the otherhand, if we use TradeMatchReport(DC) for the mapping, we come up with the following:!

(II) For Two-party trade reporting(refer to the table above)

If using AE, we come up with the following mapping:

If using DC, we come up with the following:

In summary, we would like know what message we can used? (if it can use DC, what is the message flow, i.e. the reply message to participants - as my flow above). Thanks.

[robertlau]

Hi, would like to know if there is any view on our above queries? or I need to further elaborate? Thanks.