Skip to end of banner
Go to start of banner

Conceptual Message Flows - Single Sided Trade Submission - Trade Rejected

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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

This page describes workflows associated with single sided trades submitted for clearing that were automatically rejected by CME DCO due to credit failure or explicitly rejected by clearing firms after the trade was matched in CME ClearPort. 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.

 

 

Pre-Match Flow - Trade Rejected by CME ClearPort

In this scenario, a single-sided trade is submitted using MQ or HTTP as a transport by a submitter, and CME ClearPort rejects the trade because one of the sides failed Risk Limit Check (credit failure).

Trade Submission Using MQ

This scenario illustrates submitting a single sided trade to CME ClearPort  to be matched (affirmed) and cleared at CME DCO. The clearing member has setup risk limits in CME. CME ClearPort does the credit check and the single sided trade fails credit. The trade can be submitted using MQ. 

This scenario illustrates submitting a single-sided trade to CME ClearPort using MQ as a transport to be matched and 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 both the submitters receives a Trade Reject notification .

Trade Submission Using HTTP

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

  • 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.

CME Hosted Automatic Credit Check Model - Post Match - 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 section describes all the clearing rejected workflows after a match has occurred in CME ClearPort. Based on the risk limit check model and the transport used for submitting trades the workflows may vary.

Trade Submission Using MQ

This scenario illustrates submitting a single sided trade to CME ClearPort  to be matched (affirmed) and cleared at CME DCO. The clearing member has setup risk limits in CME. CME ClearPort does the credit check and the single sided trade fails credit. The trade can be submitted using MQ. 

This scenario illustrates submitting a single-sided trade to CME ClearPort using MQ as a transport to be matched and 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 both the submitters receives a Trade Reject notification .

Trade Submission Using HTTP

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

  • 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) - Post Match - Trade Rejected

Macro lookup error: excerpt "CME hosted and Explicit Claim Model" was not found on page "CME ClearPort API" (with ID 47090958) in space "EPICSANDBOX".

If you're experiencing issues please see our Troubleshooting Guide.

Explicit Claim by Both Sides - One Side Explicitly Rejects 

Trade Submitted Using MQ
In this scenario, two single sided trades have been submitted into CME ClearPort from two different submitters for matching and clearing using MQ as a transport. Once the trade is matched in CME ClearPort, both the platforms are notified of the trades which are in pending clearing state. The trade goes into the clearing member claim workflow.
  • One of the clearing firm claims: Claim notification is sent to the submitter of the trade side.
  • An opposite claim notification is sent to the other side to provide visibility into the claim 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 submitters.

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

Trade Submitted Using MQ 

In this scenario, two single sided trades have been submitted into CME ClearPort from two different submitters for matching and clearing using MQ as a transport. Once the trade is matched in CME ClearPort, both the platforms are notified of the trades which are in pending clearing state. The clearing firms are notified of the alleged trade. The trade is credit checked at CME.

 

  • CME ClearPort does the account and Product validations.
  • CME does the credit check for both sides: 
  • One side fails credit. At this point the trade is considered to be rejected and CME ClearPort sends a rejected trade notification to the submitters.

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, one of the the clearing member performs its own credit check and explicitly accept or reject trades and the other clearing member has setup risk limits at CME.

Trade Submitted Using MQ

In this scenario, two single sided trades have been submitted into CME ClearPort from two different submitters for matching and clearing using MQ as a transport. Once the trade is matched in CME ClearPort, both the platforms are notified of the trades which are in pending clearing state. The clearing firms are notified of the alleged trade. 

  • CME ClearPort sends a pending clearing notification after the trade match.
  • Credit check is done for the side that has their risk limits set at CME.
  • An auto claim notification is sent to the submitter for the side that passes credit at CME.
  • An opposite claim notification is sent to the other side to provide visibility into the claim 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 submitters.

 

Trade Submission with Allocations (Pre-Clear) 

 

In this scenario, The Asset Manager (AM) and Executing Broker (EB) have agreed to a deal and each submits a single-sided trade to CME ClearPort from its respective system. The submitters use MQ as a transport to submit trades. The EB submits its side of the block trade. The AM then submits its side which includes two customer allocations, Alloc1 for 60MM and Alloc2 for 40MM. When both sides of the trade are received, CME ClearPort matches and sends match notifications with a trade status of Pending clear to both the submitters. The respective clearing firms are notified. The steps are:

 

  • When a clearing firm claims one allocation, claim notifications and opposite claim notifications are sent to the respective submitters.
  •  When the clearing firm of the EB claims both trades alleged to it, the submitters are notified of the claim.
  • At this point, one of the allocations is cleared. The submitters are notified of the cleared trade for the first allocation.
  • When the clearing member rejects the second allocation, the submitters are notified of the rejected allocation.

Note: The final state of the trade is cleared with reject.

 

Note

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 UTI). 

Step 1 - Block Trade Cleared

This scenario two single sided block trades have been submitted into CME ClearPort with a Client on one side and an executing broker (EB) on the other side using MQ as a transport from two different submitters for matching and clearing using MQ as a transport. In this scenario, the clearing firms of both sides (Asset Manager and Executing Dealer) have setup risk limits at CME  had have CME perform the credit check.  The steps include:

  • CME does the credit check for both sides: The submitter receives auto-claim notification(s) (similar to a claim notification from a clearing firm)  to indicate the trade has been risk checked and has passed credit.
  • An opposite claim notification is sent to the other side to provide visibility into the claim process.
  • If both sides pass credit, the trade is considered cleared and CME ClearPort sends a cleared trade notification to  both the submitters.


 

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