Page tree
Skip to end of metadata
Go to start of metadata

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

This page describes workflows associated with dual sided trades submitted for clearing that were automatically rejected by CME DCO due to credit failure or explicitly rejected by clearing firms. The flows are defined by the risk limit check model used to credit check these trades. The variation in workflows based on the transport used for submitting these trades is also described here:

 

 

CME Hosted Automatic Credit Check Model - Trade Rejected

In this risk check model, clearing members are required to set risk limits in CME Account Management Service and have CME perform risk checks on their behalf.  The asset classes that support this workflow are futures, energy and other commodities swaps.

This scenario illustrates submitting a dual-sided trade to CME ClearPort using MQ as a transport to be cleared at CME DCO.  Both the clearing members have setup risk limits in CME. CME ClearPort does the credit check and one of the sides fails credit. The trade can be submitted using either transport. 

Trade Submission Using MQ

This scenario illustrates submitting a dual-sided trade to CME ClearPort using MQ as a transport to be cleared at CME DCO. The steps include:

  • CME ClearPort validates the trade for product, account, credit and other trade information.
  • The trade passes all Product and Account validations but fails Credit.  
  • The trade is rejected for clearing and the submitter receives a negative Acknowledgement.

Trade Submission Using HTTP

The credit check is done asynchronously. The clear trade notification is not sent automatically.

This scenario illustrates submitting a dual-sided trade to CME ClearPort using HTTP as a transport to be cleared at CME DCO. The steps include:

  • CME ClearPort validates the trade for product, account and other trade information.
  • The trade passes product and account validation and the submitter receives a positive acknowledgement.
  • CME ClearPort then validates the trade for credit. This is an asynchronous process. The trade 
  • The submitter may send a request for status of the trade.
  • CME ClearPort reports the rejected status of the trade.

Trade Submission with Allocations

This scenario illustrates submitting a dual-sided trade to CME ClearPort using MQ or HTTP as a transport by a platform. In this model, where ClearPort performs the credit check, all accounts must validate and pass the credit check or the entire trade is rejected. 

CME Hosted / Explicit Claim Model (Choice) - Trade Rejected

In this risk check model, clearing members can choose to 1) set risk limits in CME Account Management Service and have CME perform risk checks on their behalf or 2) perform their own credit checks and explicitly accept and reject trades in FEC. The risk check method can be configured at the account level during account registration in CME Account Management Service. The ability to choose the risk check method at an account level in CME Account Management Service is available for Interest Rate Swaps, and OTC FX asset classes.

Explicit Claim by Both Sides - One Side Explicitly Rejects 

In this scenario, the clearing firms of both sides perform their own credit checks and explicitly accept or reject trades. 

Trade Submitted Using MQ

In this use case, a submitter sends a dual-sided affirmed trade to be claimed by clearing firms into CME ClearPort using MQ as a transport. The trade goes into the clearing member claim workflow.

  • CME ClearPort receives a dual-sided trade: It acknowledges the receipt of the trade back to the submitter if the trade is valid and notifies the clearing firms of the pending clear trade.
  • One of the clearing firm claims: The submitter receives a claim notification that provides the submitter, visibility into the clearing process.  
  • The clearing firm of the other side explicitly rejects the trade. 
  • At this point the trade is considered to be rejected and CME ClearPort sends a rejected trade notification to the submitter.

CME Hosted Credit Check by Both sides - One Side Fails Credit

In this scenario, the clearing firms of both sides have setup risk limits at CME  had have CME perform the credit check. 

Trade Submitted Using MQ 

A submitter sends a dual-sided affirmed trade to be claimed by clearing firms into CME ClearPort using MQ as a transport to be cleared at CME DCO.

  • CME ClearPort does the account and Product validations.
  • Credit check is done for the side that has their risk limits set at CME . 
  • The Credit check fails: At this point the trade is considered to be rejected and CME ClearPort sends negative Ack back to the submitter.

 

For http trade submission flow is similar to the the clearing member explicit claim workflow. Refer to Clearing member Explicit claim workflow for http.

CME Hosted Credit Check by One Side and Explicit Reject by Other 

In this use case, a submitter sends a dual-sided affirmed trade to be claimed by clearing firms into CME ClearPort using MQ as a transport to be cleared at CME DCO. 

  • CME ClearPort receives a dual-sided trade and validates the trade for product, account and credit. Credit check is done for the side that has their risk limits set at CME.
  • CME ClearPort sends a positive acknowledgement if the trade passes  all validations including credit.
  • An auto claim notification is sent to the submitter for the side that passes credit at CME.
  • The clearing firm of the other side explicitly rejects the trade. 
  • At this point the trade is considered to be rejected and CME ClearPort sends a rejected trade notification to the submitter.

CME Hosted Credit Check Fails Credit (MQ Submission)

A submitter sends a dual-sided affirmed trade to be claimed by clearing firms into CME ClearPort using MQ as a transport to be cleared at CME DCO.

  • CME ClearPort does the account and Product validations.
  • Credit check is done for the side that has their risk limits set at CME . 
  • The Credit check fails: At this point the trade is considered to be rejected and CME ClearPort sends negative Ack back to the submitter.

 

CME Hosted Credit Check Fails Credit (HTTP Submission)

A submitter sends a dual-sided affirmed trade to be claimed by clearing firms into CME ClearPort using HTTP as a transport to be cleared at CME DCO.

  • CME ClearPort does the account and Product validations.
  • If the trade passes preliminary validations, the submitter receives a positive Acknowledgement and the trade is sent to Clearing.
  • Credit check is done for the side that has their risk limits set at CME . This is an asynchronous process. The trade fails credit.
  • The submitter may send a request for status of the trade.
  • CME ClearPort reports the rejected status to the submitter.

Trade Submission with Allocations (Pre-Clear) 

This scenario illustrates submitting a dual-sided trade into CME ClearPort with an asset manager (AM) on one side and an executing broker (EB) on the other side using MQ as a transport. The AM side includes two customer allocations, Alloc1 for 60MM and Alloc2 for 40MM.  This workflow uses explicit claim by the all the clearing members. The steps include:

  • CME ClearPort receives the dual-sided trade, acknowledges the submitter, and then notifies the corresponding clearing firms.
  • When the clearing firm of Alloc2 claims, CME ClearPort sends a claim notification to the submitter.
  • The submitter receives claim notices for both[1] the trades of the EB when the clearing firm of EB claims the trades.
  • In this scenario, Alloc2 for 40M is the first to clear. CME ClearPort notifies the submitter of the partially cleared trade. The corresponding quantity buckets update to reflect the partial clear.
  •  When the clearing member of Alloc1 rejects the allocation, CME ClearPort notifies the submitter of the rejected allocation.

Note

[1] The EB's trade is split based on the number of allocations submitted by the asset manager. The final state of the trade is cleared with reject.

 

Trade Submission with Allocations (Post-Clear)

Post Clear Allocation: In this allocation model, when a bilateral trade is executed and the allocations/accounts are not known within the required reporting time frame, the trade is submitted using a temporary block/ holding account. The trade cleared in the block/holding account. Subsequently the counterparty that intended to allocate can submit allocations by allocating out of the holding account into the appropriate allocation accounts.  In this model, the participants can submit partial allocations. The allocated trade will need to reference the original block trade (using the block USI). 

Step 1 - Block Trade Cleared

This scenario illustrates submitting a dual-sided trade into CME ClearPort with a Client on one side and an executing broker (EB) on the other side using MQ as a transport. This work flow is the same as the trade submission workflow. This example illustrates it with an explicit claim workflow. The steps include:

  • CME ClearPort receives a dual-sided trade: It acknowledges the receipt of the trade back to the submitter if the trade is valid and notifies the clearing firms of the pending clear trade.
  • One of the clearing firm claims: The submitter receives a claim notification that provides the submitter, visibility into the clearing process.  
  • When the second clearing firm claims, the trade is considered cleared and CME ClearPort sends a cleared trade notification to the submitter.

 

 

Step 2

Once the trade is cleared, the client allocates the trade from the holding account to two client  accounts. The allocations  are Alloc1 for 60MM and Alloc2 for 40MM.  The trade is now between the Client and the Client accounts. This workflow uses explicit claim by the all the clearing members. The steps include:

  • CME ClearPort receives the dual-sided trade, acknowledges the submitter, and then notifies the corresponding clearing firms.
  • When the clearing firm of the 40MM allocation explicitly claims, CME ClearPort sends a claim notification to the submitter.
  • The submitter receives claim notices for both the trades of the Client (60MM and 400MM) when the clearing firm of Client claims the trades.
  • In this scenario, the 40MM alloaction is the first to clear. CME ClearPort notifies the submitter of the partially cleared trade. The corresponding quantity buckets update to reflect the partial clear.
  • When the clearing member of of the  60MM allocation rejects the allocation, CME ClearPort notifies the submitter of the rejected allocation. 

In this allocation model, the Client can partially allocate the trade. He does not have to allocate the complete cleared quantity.

 

 

  • No labels