FIXML Message Flows - Trade Submission for Clearing

Use this search bar to search topics within the CME ClearPort API.

 

This page describes FIXML message flows associated with clearing a trade and the messages sent to submitters for the various use cases. The messages flows detail both single-sided and dual-sided submissions.

 

 



One of the restrictions in the clearing firm claim model is that only one side can submit pre-clear allocations. The other side cannot allocate. The trade will be rejected if the dual-sided trade is submitted with allocations on both sides.

Trade Clearing Submission and Response

The following message flows are triggered by the API when a dual sided trade is submitted into CME ClearPort for clearing using MQ or HTTP. The trade is accepted for clearing and the trade goes into the explicit claim workflow. A Pending clear notification is sent to the submitter if the trade passes all validations including credit for the sides that  have set their risk limits at CME.   

Trade Submitted for Clearing Using MQ - Trade Accepted for Clearing

In this scenario, the trade is submitted using MQ as a transport.

A submitter sends a dual-sided Trade Capture Report message with 

  • TransTyp of New (0) and

  • RptTyp of Submit (0).

The API acknowledges the receipt of the message by sending a Trade Capture Report Acknowledgment message with:

  • TransTyp of New (0)

  • RptTyp of Submit (0)

  • TrdAckStat of Accepted (0)

  • TrdRptStat of Pending Clear (101).

The Acknowledgment message contains a CME ClearPort assigned ExecID for the deal.

MQ Acks have calculated money amounts for the deal if it is relevant for the asset class.

Trade Submitted for Clearing Using HTTP - Trade Accepted for Clearing

In this scenario, the trade is submitted using HTTP as a transport.

 

A submitter sends a dual-sided Trade Capture Report message with:

  • TransTyp of New (0) and

  • RptTyp of Submit (0).

The API acknowledges the receipt of the message by sending a Trade Capture Report Acknowledgment message with:

  • TransTyp of New (0)

  • RptTyp of Submit (0)

  • TrdAckStat of Received Not Yet Processed (0)

The money amounts are not calculated in an HTTP ack. 

The following message flows are triggered by the API when a dual sided trade is submitted into CME ClearPort for clearing using MQ or HTTP. The trade is rejected by the API because it failed one or more validations. The trade is validated for product, account and credit for sides that have their risk limits set at CME.

Trade Submission for Clearing - Trade Not Accepted for Clearing

In this scenario an un-allocated trade is submitted for clearing using MQ as the transport.

A submitter submits a dual-sided Trade Capture Report message with:

  • TransTyp of New (0) and 

  • RptTyp of Submit (0)

CME ClearPort validates the message for product, trade and account information. If the trade fails any validation, CME ClearPort sends a dual-sided Trade Capture Report Acknowledgment message with a 

  • TransTyp of New (0), 

  • RptTyp of Submit (0), 

  • TrdAckStat of Rejected (1), 

  • TrdRptStat of Rejected (1), 

  • Reject Reason (RejRsn) 

  • Reject Text (RejTxt).

Trade Submission for Clearing - Allocated trade Not Accepted for Clearing

In this scenario an allocated trade is submitted for clearing using MQ as the transport. The trade can be rejected for clearing if:

  • the trade fails Product validations or

  • the trade fails account validations or

  • If the risk limits are set at CME from one or more accounts

    • If the non-allocating side fails risk limit at CME or

    • All of the allocating sides fail risk limit at CME

CME ClearPort sends a dual-sided Trade Capture Report Acknowledgment message with a 

  • TransTyp of New (0), 

  • RptTyp of Submit (0), 

  • TrdAckStat of Rejected (1), 

  • TrdRptStat of Rejected (1), 

  • Reject Reason (RejRsn) 

  • Reject Text (RejTxt).

CME Hosted / Explicit Claim Model -  Acceptance Notifications 

The following message flows are triggered by the API when a dual-side / matched trade is submitted into CME ClearPort for clearing using MQ as Transport and follows the "CME Hosted / Explict Claim" Model. 

Trade Accept Notification 

This flow is initiated when a side of a trade has passed the CME Hosted credit check or is explicitly claimed by the clearing firm in Front End Clearing (FEC).

Dual Sided Trade submission



Single Sided trade Submission



A trade accept notification is sent to the submitter using a single-sided Trade Capture Report message (one ReportSide) containing the information of the side claiming, with:

  • TransTyp of Replace (2)

  • RptTyp of Accept (0)

  • TrdRptStat of Pending Clear (101). 

The opposite side submitter (in the case of two matched single-sides) will receive an opposite accept notification. This notification is optionally available to the submitter for the dual-sided submission. 

The message is using a single-sided Trade Capture Report message containing the information of the opposite side accepting, with:

  • TransTyp of Replace (2)

  • RptTyp of Opposite Accept (102)

  • TrdRptStat of Pending Clear (101).

The trade is now partially accepted if the other side must claim, and has not yet done so. If the other side has already been claimed or has passed credit, the second claim notification will be suppressed and the submitter will receive a clear trade notification.

Allocation Accept Notification

This flow is initiated when an account of trade with allocations has passed the CME Hosted credit check or is explicitly claimed by the clearing firm in Front End Clearing (FEC).

Dual Sided Trade Submission

Single Sided Trade Submission

An allocation acceptance notification is sent to the submitter using a single-sided Trade Capture Report message with:

  • TransTyp of Replace (2)

  • RptTyp of Accept (0). 

  • TrdRptStat is Pending Clear (101) or Partially Clear (102)

  • Stat of Claimed (1) on the Alloc Block. 

The ExecID and the Allocation ID associated with the allocation is echoed back. The accept notifications also include quantity buckets (Qty blocks) to indicate claimed quantities, as well as those still pending claim.

The opposite side submitter (in the case of two matched single-sides) will receive an opposite accept notification. This notification is optionally available to the submitter for the dual-sided submission.

The message is using a single-sided Trade Capture Report message containing the information of the opposite side accepting, with:

  • TransTyp of Replace (2)

  • RptTyp of Opposite Accept (102). 

  • TrdRptStat is Pending Clear (101) or Partially Clear (102)

The Status of the allocation (Stat) reflects the submitter's status of his allocation.

CME Hosted / Explicit Claim Model -  Rejection Notifications 

Trade Reject Notification 

This flow is initiated when a side of a trade has failed the CME Hosted credit check or is explicitly declined by the clearing firm in Front End Clearing (FEC).

Dual Sided Trade Submission

Single Sided trade Submission

A trade reject notification is sent to the submitter using a dual-sided Trade Capture Report message (one ReportSide) containing the information of the side rejecting, with:

  • TransTyp of Replace (2)

  • RptTyp of Reject(3)

  • TrdRptStat of Rejected (1). 

The API sends a trade opposite side rejected notification to the opposite side using a single-sided (contains only one ReportSide) using a Trade Capture Report message with:

  • TransTyp of Replace (2)

  • RptTyp of Reject(3)00

  • TrdRptStat of Rejected (1). 

The trade is now in a Rejected Status.

Allocation Reject Notification

This flow is initiated when an account of trade with allocations has failed the CME Hosted credit check or is explicitly declined by the clearing firm in Front End Clearing (FEC).

Dual Sided Submission

 

Single Sided Submission

An allocation reject notification is sent to the submitter using a single-sided Trade Capture Report message with:

  • TransTyp of Replace (2)

  • RptTyp of Reject (3). 

  • Stat of Rejected (3) to the Allocation, in the corresponding alloc block.

  • TrdRptStat of Partially Cleared (102) or Pending Clear (101) or 

  • TrdRptStat 

    • Rejected (1) is sent if all the allocations were rejected or 

    • Cleared with Rejects (103) if some of the allocations were accepted and cleared and this is the last allocation in the group.

    • Partially Cleared (102) if some of the allocations were accepted and cleared earlier and this is not the last allocation in the group.

    • Pending Clear (101) if no allocations have cleared so far.

The ExecID and the Allocation ID associated with the allocation are echoed back.

An allocation opposite side rejected notification is sent to the other submitter of the single sided trade using a single-sided Trade Capture Report message with:

  • TransTyp of Replace (2)

  • RptTyp of Opposite Reject (103). 

  • Stat of Rejected (3) to the Allocation, in the corresponding alloc block.

  • TrdRptStat of Partially Cleared (102) or Pending Clear (101) or 

  • TrdRptStat 

  •  

    • Rejected (1) is sent if all the allocations were rejected or 

    • Cleared with Rejects (103) if some of the allocations were accepted and cleared and this is the last allocation in the group.

    • Partially Cleared (102) if some of the allocations were accepted and cleared earlier and this is not the last allocation in the group.

    • Pending Clear (101) if no allocations have cleared so far.

Clearing Notifications

This flow is initiated when CME Clearing (FEC) clears a trade or an allocation.

Trade Clearing Notification

This flow is initiated when the clearing firms of both sides of the trade have passed risk limit check  through an explicit claim by the clearing firm or using the CME Hosted Credit check. FEC notifies CME ClearPort of the cleared trade. This is a notification sent in the case of an MQ submission.

Dual Sided Submission

Single Sided Submission

A trade clear notification is sent to the submitter using a dual-sided Trade Capture Report message with 

  • TransTyp of New (0) or Replace (2)

  • RptTyp of Notification (101)

  • TrdRptStat of Accepted/Cleared (0)

Allocation Clearing Notification

This flow is initiated when the clearing firms of both sides of an allocation have passed risk limit check  through an explicit claim by the clearing firm or using the CME Hosted Credit check. FEC notifies CME ClearPort of the cleared allocationThis is a notification sent in the case of an MQ submission.

Dual Sided Submission

Single Sided Submission


The API sends an allocation cleared notification to the submitter using a dual-sided Trade Capture Report message with:

  • TransTyp of New (0) or Replace (2)

  • RptTyp of Notification (101)

  • TrdRptStat of 

    • Accepted/Cleared(0) is sent if all the allocations cleared or 

    • Cleared with Rejects (103) if some of the allocations were accepted and cleared and this is the last allocation in the group.

    • Partially Cleared (102) if some of the allocations were accepted and cleared earlier and this is not the last allocation in the group.

    • Pending Clear (101) if no allocations have cleared so far.

Trade Void Request and Response

In this scenario, the submitter sends CME ClearPort a void request for a cleared trade top day. The steps include:

  • CME ClearPort validates the void request.

  • If the void request passes all validations, the void trade is sent to Clearing, and the submitter receives a positive Acknowledgment indicating the trade status is cancelled.

 

  1. The submitter sends a Trade Capture Report message with a RptTyp of Submit (0), a TransTyp of Cancel (1), and specifies the CME ClearPort assigned Execution ID (ExecID).

  2. CME ClearPort validates the void request to make sure the ExecID specified is valid and it is a top day trade. If the trade passes validations, the API acknowledges the submitter with a dual-sided Trade Capture Report Acknowledgment message with:

  • TransTyp of Cancel (1)

  • TrdAckStat of Accepted (0)

  • TrdRptStat of Cancelled (2)

Trade Status Request

Submitters using HTTP as a transport can request the status of their executed trades at any time.

 

A TradeCaptureReportRequest message with a ReqTyp of Matched trades(1) for the specified Match Criteria is sent by the submitter requesting the status of the trades they have submitted. Trade Status can be requested by specifying:

  1.  

    1. CME ClearPort assigned ExecID

    2. Submitter assigned ExecID2

    3. TrdDt

A TradeCaptureReportRequestAck message is sent back only if the request is invalid.

If the Request is valid, the API returns one or more TradeCaptureReport messages with the current state of the trade(s).

If the request results in multiple trades, each TradeCaptureReport is published to the queue separately if the request was made over MQ. Also, each message includes the TrdCapRpt fields TotNumTrdRpts (total number of TrdCaptRpt messages included in the response) and LastRptReqed (Yes/No field indicating which message is the last of the response).




How was your Client Systems Wiki Experience? Submit Feedback

Copyright © 2024 CME Group Inc. All rights reserved.