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.
Â
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).
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:
Â
CME ClearPort assigned ExecID
Submitter assigned ExecID2
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.