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

Trade Submission for Match - Successful Match

CME ClearPort can successfully match two single-sided trades by two different submitters using either transport:

Trade Submitted Using MQ

CME Hosted Automatic Credit Check Model Flow

This scenario illustrates submitting two single-sided trades using MQ as a transport by two different submitters, and CME ClearPort successfully matching the trades. The trade is submitted to be credit checked using the CME Hosted Automatic Credit Check Model.

Open

1. The submitter sends a single-sided Trade Capture Report Message by using a TransTyp of New (0), RptTyp of Submit(0) and can optionally specify their own Trade Id (SrcTrdID).

2. The trade is validated and CME ClearPort sends a Trade Capture Report Acknowledgment with a TransTyp of New (0), RptTyp of Submit (0), a TrdAckStat of Accepted (0) and a CME ClearPort assigned Trade ID (TrdID) for the side if the trade is valid. The TrdRptStat is set to Unmatched (100).

3. CME ClearPort tries to match when the second submitter sends a single-sided trade for the opposite side. This is sent and acknowledged as in steps 1 and 2 above.

4. If CME ClearPort finds a match, the trade is matched and CME ClearPort sends a single-sided Trade Capture Report message to both sides with these values:

5. If credit checked by CME ClearPort - TransTyp of Replace (2), RptTyp of Notification (101) and a TrdRptStat of Accepted (1). 
   See additional information on Post Match Flows.

CME Hosted and Explicit Claim Model Flow

Open

1. The submitter sends a single-sided Trade Capture Report Message by using a TransTyp of New (0), RptTyp of Submit(0) and can optionally specify their own Trade Id (SrcTrdID).

2. The trade is validated and CME ClearPort sends a Trade Capture Report Acknowledgment with a TransTyp of New (0), RptTyp of Submit (0), a TrdAckStat of Accepted (0) and a CME ClearPort assigned Trade ID (TrdID) for the side if the trade is valid. The TrdRptStat is set to Unmatched (100).

3. CME ClearPort tries to match when the second submitter sends a single-sided trade for the opposite side. This is sent and acknowledged as in steps 1 and 2 above.

4. If CME ClearPort finds a match, the trade is matched and CME ClearPort sends a single-sided Trade Capture Report message to both sides with these values:

5. If the trade  - a TransTyp of Replace (2), RptTyp of Notification (101) and a TrdRptStat of Pending Clear (101).

Trade Submitted Using HTTP

This scenario illustrates submitting two single-sided trades using HTTP as a transport by two different submitters, and CME ClearPort successfully matching the trades. CME Clearport does not notify the submitters of matching trades. Instead, the submitter must request for a trade status.

This flow is initiated when a submitter sends a single-sided trade using HTTP as a transport.

1. The submitter sends a single-sided Trade Capture Report Message by using a TransTyp of New (0), RptTyp of Submit (0) and can optionally specify their own Trade Id (SrcTrdID).

2. The trade is validated and CME ClearPort sends a Trade Capture Report Acknowledgment with a TransTyp of New (0), RptTyp of Submit (0), a TrdAckStat of Accepted (0) and a CME ClearPort assigned Trade ID (TrdID) for the side if the trade is valid. The TrdRptStat is set to Received, not yet Processed (4).

3. CME ClearPort tries to match when the second submitter sends a single-sided trade for the opposite side.

4. If CME ClearPort finds a match, the trade is matched by CME ClearPort. CME ClearPort does not send a Pending Clear notification to the submitters.

5. Both submitters must  send a request for the trade status by sending a Trade Capture Report Request with ReqTyp of Matched Trades (1) and specifying the Single-sided Trade Id (TrdID) assigned by CME ClearPort for the side.

6. CME ClearPort then returns a single-sided Trade Capture Report message to the requestor with a TransTyp of New (0), RptTyp of Notification (0), and a TrdRptStat of Pending Clear (101) if the trade is going to be explicitly claimed. The report also contains a CME ClearPort assigned Execution ID (ExecID). 

See a sample flow.

Submission with Allocations

This message flow is similar to Successful Match - Trade Submitted Using MQ or Successful Match - Trade Submitted Using HTTP where single-sided trades are submitted for match into CME ClearPort. The variation is specifying allocations with the trade. Based on the asset class, one or both sides can specify allocations. Submitted allocation accounts will be validated. CME ClearPort may also check the risk limit for the allocation account if the allocations do not need to be claimed by the clearing firms.

Trade Submission for Match - Exception Flows

Trade Rejected by CME ClearPort

This scenario illustrates submitting two single-sided trades using MQ or HTTP as a transport by two different submitters, and CME ClearPort rejecting one of the trade submissions.

1. The submitter sends a single-sided Trade Capture Report Message with a TransTyp of New, RptTyp of Submit and can optionally specifytheir own Trade Id (SrcTrdID).

2. The trade is validated by CME ClearPort and, if the trade fails validation for product, account or any other trade details, CME ClearPort sends a Trade Capture Report Acknowledgment with aTrdAckStat of Rejected.

Unsuccessful Match - Trades Pending

This scenario illustrates both sides have submitting a single-sided trade using MQ or HTTP without a match occuring.

This flow is initiated when submitters send single-sided trades.

1. Each submitter sends a single-sided Trade Capture Report Message with a TransTyp of New, RptTyp of Submit and can optionally specify their own Trade Id (SrcTrdID).

2. The trade is validated and CME ClearPort sends a Trade Capture Report Acknowledgment with a TransTyp of New (0), a TrdAckStat of Accepted (0) and a CME ClearPort assigned Trade ID (TrdID) for the side if the trade is valid.

3. CME ClearPort tries to match when the second submitter submit a single-sided trade for the opposite side.

4. If CME ClearPort does not find a match, the trade is in an Unmatched status in CME ClearPort.

Trades Rejected by Counterparty

This scenario illustrates one side submitting a single-sided trade using MQ or HTTP. The other side sends a request for alleged trades and rejects the alleged trade.

This flow is typically initiated once a submitter receives alleged trades after sending a request for alleged trades by a counterparty. The submitter can then send a message to reject the trade. The steps are:

1. Submitter 1 rejects an alleged trade by submitting a Trade Capture Report Message with a TransTyp of New (0) and an RptTyp of Decline (3). The TrdID assigned by CME ClearPort is specified in this Trade Capture Report message.

2. The API responds back with a Trade Capture Report Acknowledgment message with a TransTyp of New (0), a TrdAckStat of Accepted (0) if the message was accepted by CME ClearPort, a RptTyp of Decline (3), and a TrdRptStat of Cancelled (1).

3. The API notifies the opposite side (counterparty), e.g. Submitter 2, of the reject with a Trade Capture Report message with a RptTyp of Decline (3), a TrdRptStat of Rejected (1) and Reject Text indicating the alleged trade was rejected by the opposite party.

Trade Cancelled Before Match

This scenario illustrates one side submitting a single-sided trade using MQ or HTTP. The submitter cancels the trade before the trade is matched.

In this scenario, a single-sided trade is submitted can be cancelled by a submitter before the trade is matched.

1. The Submitter sends a Trade Capture Report message with a TransTyp of Cancel (1) and a RptTyp of Submit (0). The TrdID assigned by CME ClearPort is specified in the cancellation request.

2. The API responds back with a Trade Capture Report Acknowledgment message with a TransTyp of Cancel (1), a TrdAckStat of Accepted (0) if the message was accepted by CME ClearPort, a RptTyp of Submit (0) and a TrdRptStat of Cancelled (2).

See a sample flow.

Trade Status Requests

Request for Alleged Trades

This flow can be initiated at any time. In this scenario, one of the party to the trade sends a request for all the trades where the requester  is the counterparty (all trades alleged to the requester).

1. A participant submits a Trade Capture Report Request message with a ReqTyp of Alleged (4) trades and a request for all trades that are alleged to them for a specified Trade Date

2. CME ClearPort sends a Trade Capture Report Message with a TransTyp of New (0), a RptTyp of Alleged (1), and a TrdRptStat of Unmatched (100).

Request for Unmatched Trades

A submitter can send a request at any time for all the trades that are unmatched and require submission from the opposite party. This flow is the same when the request is submitted using MQ or HTTP.

1. A participant or platform sends a Trade Capture Report Request message with a ReqTyp of Unmatched (2) and a Trade Date requesting all trades that are not matched.

2. CME ClearPort sends a Trade Capture Report Message with a TransTyp of New (0) and a TrdRptStat of Unmatched (100).

3. CME ClearPort sends a single or multiple Trade Capture Report Messages.
   If the request is made through HTTP, multiple Trade Capture Report messages can be returned within a Batch container.

Request Processed Successfully

1. A participant or platform sends a Trade Capture Report Request message with a ReqTyp of Unmatched (2) and a Trade Date requesting all trades that are not matched.

2. CME ClearPort sends a Trade Capture Report Message with a TransTyp of New (0) and a TrdRptStat of Unmatched (100).

3. CME ClearPort sends a single or multiple Trade Capture Report Messages.

4. If the request is made through HTTP, multiple Trade Capture Report messages can be returned within a Batch container.

Request Rejected

1. A submitter sends a Trade Capture Report Request message with a ReqTyp of Unmatched (2) and a Trade Date requesting all trades that are not matched.

2. The request was not valid. CME ClearPort sends a Trade Capture Report Request Acknowledgment Message with a ReqStat of Rejected (1) and a ReqRslt of Invalid Request.