Use this search bar to search topics within the CME ClearPort API.
This CME ClearPort Trade Submission API includes descriptions of supporting functions, workflows, message flows, and interfaces to allow firms and other authorized users to submit trades for matching and clearing of OTC trades.
This API is defined in FIXML using FIX 5.0 SP2 with custom CME extensions. Please refer to the message specification for details. Additional information on FIXML post trade messages is available after logging into the FIX Protocol site. This site assumes that users have a basic understanding of XML and some familiarity with trade reporting models.
Trade Submission Models
CME ClearPort supports multiple trade submission models for participants to submit outright and spread trades into CME ClearPort so they can be cleared by CME Clearing:Single-Side Trade Submission - Submit single-sided trades so they can be matched in CME ClearPort and subsequently cleared by CME Clearing. Trade sides match when both participants have submitted their sides. If a match occurs, the resulting matched trade will then be eligible for clearing and the CME Front End Clearing System (FEC) notifies the designated clearing firms of a cleared trade, or in the case where the trade requires explicit claim in FEC by each clearing firm, a trade that is Pending Clear. When a clearing firm claims, FEC notifies the submitter of the claim status automatically if the submitter used WebSphere MQ as their method of transport. Submitters using Secure HTTP as their method of transport must continually request trade status.
Dual-Sided Trade Submission - Submit affirmed (matched, dual-sided) trades so they can be cleared by CME Clearing. In this model, CME ClearPort credit checks affirmed trades, or if required, clearing firms explicitly claim the trades pending clear. If the trade requires credit check in CME ClearPort then the entire trade clears immediately once it passes. If the trade requires explicit claim in FEC each clearing firm must accept their side for the entire trade to clear, and there is the potential for the trade to be partially cleared if the trade was allocated out to multiple customer accounts.
Once successfully submitted, you can view trade status using the CME ClearPort GUI or query the status using the API. The API automatically communicates any change in trade status if WebSphere MQ is used as the method of transport to submit trades. The API supports a status request query for submitters that use Secure HTTP as their method of transport.
Submitting AllocationsPre-Clear Allocations: In this allocation model, allocations can be submitted at the time of trade submission. Allocations can be submitted for both the single sided and dual sided allocation model. In a single sided submission model, the allocations will be processed only after the trade is matched (affirmed) by ClearPort. All the allocations can be submitted in a single trade with multiple allocation blocks. As each allocation is claimed and cleared, the submitter is notified. Alternatively, allocations can be broken up and submitted as multiple trades by referencing the block trade and each allocated trade is cleared as a unique trade.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).
Submitting Allocation Instructions
CME ClearPort API allows authorized participants to submit one or more allocation instructions into CME ClearPort API to allocate a previously cleared bunched order.
- Voids are not supported for allocation instructions.
- Cancels are supported for IRS products only.
- CME Clearing will continue to leverage the trade workflow for clearing firm interactions. Please refer to the clearing firm trade management API document.
- CME will continue to support the current bunched order workflow, where the allocations contain the full trade details by leveraging the trade submission workflow.
Risk Limit Check Models
CME Hosted Automatic Credit Check ModelIn this risk check model, clearing members are required to set risk limits in CME Account Manager and have CME perform risk checks on their behalf. The asset classes that support this workflow are futures, energy and other commodities swaps.
CME Hosted / Explicit Claim ModelIn this risk check model, clearing members can choose to 1) set risk limits in CME Account Manager 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 Manager. The ability to choose the risk check method at an account level in CME Account Manager is available for Credit Default Swaps, Interest Rate Swaps, and OTC FX asset classes.
Broker Fees for Brokered Trades
This functionality enables Brokers to enter broker fees in CME ClearPort API. These brokered trades, including commissions data, flow through the platform for retrieval in CME STP, enabling Clearing Firms to see the broker fees on their trade capture reports. Detailed information on broker fee retrieval in CME STP is available here.
Certification is mandatory for CME ClearPort API customers who wish to add Broker fees onto their trades.
The following are not supported:
- Broker fees on Credit Default Swaps
- Updates to single-side trades. Only Matched trades can have fees updated, and fees cannot be updated on trades that have not cleared.
- When two single-sided trades are submitted and subsequently matched, only fees associated with the matched trade may be updated. The matched trade will be available via the CME ClearPort Trade Capture Report (Status report).
Where accounts are allocated on only one side of the trade, the broker can only submit broker fees at the side level (RptSide). The same Basis, Rt, Ccy; and an enriched UOM and UOMCcy will be reported on CME STP at the Side/Leg level for each allocation. The resulting trades in CME STP will contain the same broker commission for each Allocation. .
- Acknowledgment, Negative Acknowledgment, and Status (Trade Capture Report) messages WILL NOT contain any CommData block at Allocation level; the fees will be displayed at side (RptSide) level only.
If a CommData Block from the original message is missing on the Trade update message, the commission will be removed from the trade. This applies to Outrights and Spreads. For example, if a CommData Block on a particular leg is not provided then the system will treat this as a cancellation of the fees on that leg.
Spread Trades: When submitting broker commission on a spread trade, a CommData/@LegRefID must be provided, and for every CommData/@LegRefID, a corresponding TrdLeg/@LegNo must also be included.If either condition is not met, the commission will be ignored; however, the trade will be processed.
Modes of Connectivity
The CME ClearPort Trade Submission API supports the following connectivity modes:
IBM WebSphere MQ
Customers have the option of connecting over a secure network via IBM Websphere MQ to submit messages through a remote queue and having message responses pushed to their local queue. WebSphere MQ clients do not require user authentication since MQ is a secure method of transport.
Clients implementing MQ can also refer to Connectivity Options.
Customers have the option of connecting using HTTPS via the Internet, Lease Line, and/or VPN. HTTP v.2.0 access supports both session-less and session-based user authentication.
Session-less - Clients must embed their exchange-assigned CME ClearPort API client username and password in the standard HTTP header of each message for authentication. Represent the username and password pair with a separating colon (Username:Password), then convert to the string to base64.
- Session-based- Clients must utilize the FIXML Application-level User Request Messages.
The API validates customer connections through session-based HTTP using a valid username and password. Responses are sent back to acknowledge a successful login or to convey a logon error. The User Request and User Response messages are used for the user connection messaging. Connections persist using cookies. The (JSESSIONID) cookie must be maintained in communications to and from the API to ensure session connectivity.
Customers must connect over a secure network via IBM Websphere MQ to submit and receive Allocation Instruction messages. WebSphere MQ clients do not require user authentication since MQ is a secure method of transport.
CME Group Login-Managed IDs
Customers must create a CME Group Login profile and API ID(s) for self-management of profile and security information. After creating an ID, contact Enterprise Application & System Entitlements (EASE) to entitle the IDs for New Release, Certification, and Production environments. CME ClearPort API passwords managed through CME Group Login will not expire. Legacy API IDs cannot be used with these new URLs:
|Environment||HTTPS URL Type||URL|
The CME ClearPort API supports the following clients:
This client includes the proprietary trading system of a single brokerage firm representing both the buyer and the seller in an off-exchange transaction. In this case, the client submits one dual-sided trade message for each transaction. That is, the trade message must contain specific account (Account ID and Clearing Member) and trader information for each side.
The client could potentially represent only one principal (the buyer or the seller) if the off-exchange transaction involves a product that supports single-sided trade entry. In this case, the client would submit one single-sided trade message. That is, the trade message contains only account information for the side they represent. The opposite trader and/or firm must still be specified, so CME ClearPort® can notify them that before the trade can clear, the alleged trade must be claimed through the CME ClearPort® GUI or they must submit their matching side.
|Asset Management Firms|
This client includes the proprietary trading system of a single firm representing either the buy side or the sell side in an off-exchange transaction. In this case, the client submits one single-sided or dual-sided trade message. The trade message contains only account information for the side(s) they represent. The opposite trader and/or firm must be specified on a single-sided trade so CME ClearPort® can notify them that before the trade can clear, the alleged trade must be claimed through the CME ClearPort® GUI or they must submit their matching side.
|Active Trading Firms||This client includes the proprietary trading system of a single firm who is the buyer or the seller in an off-exchange transaction. In this case, the client submits one single-sided or dual-sided trade message. The trade message contains only account information for their side(s). The opposite trader and/or firm must be specified on a single-sided trade so CME ClearPort® can notify them that before the trade can clear, the alleged trade must be claimed through the CME ClearPort® GUI or they must submit their matching side.|
Platforms include a proprietary trading system with the ability to submit trades for any number of subscribing brokerage firms, asset management firms, and active trading firms. The platform may:
Other Supported Functions
In addition to Single and Dual-side Trade submission, CME ClearPort API supports these major functions:
|Submit Allocations||Allows submitters to specify allocations as part of new trade submission. Each allocation requires an allocation quantity with each specified account. A trade that is allocated must be fully allocated. For CDS, CME ClearPort manages and reports the status of each allocation an individual basis. For non-CDS all accounts must be valid and pass credit check or the entire trade will fail.|
|Cancel an Unmatched Trade||Allows the submitter of a single-sided trade to cancel it if unmatched.|
|Withdraw a Pending Clear Trade|
Allows the submitter of a dual-sided CDS trade to cancel it while in the ”Pending Clearing” state. If two single-sided CDS trades match and were submitted by the same api user, then this trade could also be withdrawn while in the “Pending Clear” state. In either case the new status of the trade will be ”Void” in the ClearPort GUI, and “Cancelled” as per the Trade Report Status in the ClearPort API message.
|Reject an Alleged Trade|
Allows the counterparty to reject an alleged trade. To determine what’s been alleged, the alleged counterparty can request a list of all alleged trades via a specific type of Trade Status Request.
|Trade Status Request||Allows the submitter to request the status of a trade by specifying a trade identifier. It also supports the submitter specifying search criteria in the request which could result in a list of trades. For example a submitter can request a list of cleared trades, unmatched trades, or trades that have been alleged to the submitter by other trading parties.|
|Void a Cleared Trade||Allows the submitter to void a cleared trade top day. CME ClearPort informs the submitter of the void and notifies the clearing firms of the bust. Trades submitted using a single-sided trade submission model cannot be voided thru the API. The submitter must contact the GCC to void these trades.|
Supported Functions Bunched Order Allocation Instructions
Allocating a cleared bunched trade
Instruction to allocate a cleared bunched trade to one or more accounts / funds.
Pending clear notification
Notifying the submitter (platform / clearing firm) of the pending status of allocation(s).
Cleared Allocation notification
Notifies the platform / clearing Firm of a cleared allocation in cleared status.
Instruction to cancel a previously submitted allocation which is still pending clearing.
Notifying the submitter (platform / clearing Firm) of the cancellation of allocation(s).