Using TradeCaptureReportRequest to request for Trade ER

1

I believe it can use TradeCaptureReportRequest to request other side to reply TCRs to us.

However, can we use TradeCaptureReportRequest to request other side to return the Trade ExecutionReport(ExecType=Trade or Trade Cancel or Trade Correct), as well as TCRs to us?

For example,

  1. We send TradeCaptureReportRequest to other side.
  2. Other side returns TradeCaptureReportRequestAck to us.
  3. Other side then sends Trade ER, Trade Cancel ER, TCR, Trade ER, TCR, …, to us.
2

Short answer is “no”.

The TradeCaptureReportRequest is used to request for trades and the response message is TradeCaptureReport message, not the ExecutionReport(35=8).

There is no message to request for ExecutionReport(35=8) messages.

If you’re an exchange, once the order has matched and the matching engine sends the ER to report the fills based on the order matching, those fills become trades. Trades can be requested TradeCaptureReportRequest. If you’re an exchange, I’m not sure I understand the rational of why an exchange would want to request of the market participant to send back to the exchange the ERs that the exchange matching engine sent to the market participant. The exchange should have this information since they sent it.

3

Thanks Itaikit.

How about for the following scenario:

  1. We send Trade ERs to client.
  2. Client may or may not receive it.
  3. After some time
  4. Client sends TradeCaptureReportRequest to us and we reply TradeCaptureReportRequestAck to client.
  5. We then also change to Trade ERs to TCR and reply those TCR to them.
  6. What’s your view on this?
4

What would be the reason for your client not receiving it? If the session failed (say because of network glitch) there should have been a proper FIX session recovery with the ResendRequest issued for the missing msgs.

If the order was filled and communicated via ERs, and if there is a serious failure of some sort, I would argue that the exchange should just send the TCR when requested.

5

The case is that how can we just re-send the Trade ERs only message (excluding the New ER/Cancelled ER, etc) to other side? If we can use TradeCaptureReportRequest for Trade ER, it will be quite nice.

6

Not quite sure if that is what you want but your client could send an OrderStatusRequest. You should respond with an ExecutionReport.STATUS with the appropriate order state.

7

@christophjohn, thanks. OrderStatusRequest does not quite fit.

8

@robertlau If this is not about the current status of an order as per your reply to @christophjohn and you want to resend all the trade fills (i.e. all the partial fills and final fill associated with the order), then there is a different method you can consider using but this is going to be a big change to your and your clients’ implementations. As far as I know CME is using this feature and they implement such type of request over a separate channel to avoid disrupting the performance of the live trading channel (i.e. session).

As of FIX 5.0 many FIX messages (not all) has an additional component called ApplicationSequenceControl. The ExecutionReport(35=8) has this component. This component allows the exchange to supply 4 additional pieces of meta data for every ER sent: ApplID(1180), ApplSeqNum(1181), ApplLastSeqNum(1350) and ApplResendFlag(1352).

image
image1282×396 71.1 KB

Then on a separate session the client will use the ApplicationMessageRequest(35=BW) to request for retransmission of messages based on the ApplID(1180) supplied in the ER. The ERs being retransmitted will be sent back on that separate session and NOT via the original session.

To implement something like this would require your clients OMS to be changed to be able to process that ApplicationSequenceControl component’s information and store it. This is a big ask for clients.

I’ve deliberately kept this reply concise.

9

@ltaikit, a big thank-you.

I am trying to understand the ApplicationMessageRequest message - can I say:

  1. Client sends NewOrderSingle to us that results in (1) new ER; and (2) partially filled trade ER; and (3) fully filled trade ER. And we can construct and reply those ERs as below:

    • New ER with setting 1180=A, 1181=1, 1350=0 (1352 is not present)
    • Partially filled trade ER with setting 1180=B,1181=1, 1350=0 (1352 is not present)
    • Fully filled trade ER with setting 1180=B, 1181=2, 1350=1 (1352 is not present)

  2. Later (probably during, like day close or other events), client can send ApplicationMessageRequest to us with

    • 1347=0(Retransmission of application messages for the specified Applications)
    • 1355=B
    • 1433=<unique value>
    • 1182=1
    • 1183=0

  3. We then reply ApplicationMessageRequestAck, followed by the partially filled trade ER and the fully filled trade ER where the 1352 is added with value Y in the these 2 replied ERs.

(1180 ApplID / 1181 ApplSeqNum / 1350 ApplLastSeqNum / 1352 ApplResendFlag
1347 ApplReqType / 1355 RefApplID / 1433 RefApplReqID / 1182 ApplBegSeqNum /1183 ApplEndSeqNum)

10

@robertlau I leave it to @ltaikit to respond to your workflow. I just want to point out that you do not need to use Application Sequencing for all ERs if you only want to support a retransmission request for a subset of REs (in your case the (partial) fills.

A second comment on the use of ApplicationMessageReport(35=BY). This message should be sent unsolicited to the clients in two cases, using ApplReportType(1426):

  1. to indicate that there will be no more messages for the given ApplID(1180), use 1426=1
  2. to indicate that the response to the retransmission request has been completed, use 1426=3
11

@hanno.klein, thanks a lot. Good to know your comments. I will digest them.

12

The online specification also has a section on Application Sequencing.

13

@hanno.klein, thanks again. I just read the document, it is a good reference point.