Messages are comprised of elements, which may be non-repeating or repeating. Elements contain Attributes which define the trade characteristics.
Use this search bar to search topics within the CME ClearPort API.
- Repeating Elements are indicated by "(repeating)" in the gray highlighted Element definition row.
- Some Elements, such as Instrument (Instrmt), have a large number of attributes, and are therefore allocated their own page.
- The first defined Element level on any specification page is considered the highest level for that page. Elements may have sub-elements on the same page, as indicated by an arrow (→) preceding the field name.
- A sub-element one level down contains an arrow preceding it in the field name, for example:
→ Sender ID
Elements two levels down will have two preceding arrows:
→→ Leg Underlying Product Code
- The highest level on any page will not be preceded by an arrow, though it may still be a sub-element. For example, Instrument is a sub-element of Trade Capture Report Message, but because it is the highest level for that page, the Field Names will not be preceded by an arrow.
Each FIXML Attribute corresponds to a FIX tag. It possesses a Field Name, intended to be human readable, and a FIXML Attribute Name which is the abbreviated name that appears in the FIXML messages.
Each attribute is defined by the following properties:
The descriptive name associated with the FIXML Attribute Name.
FIXML Attribute Name
The abbreviated name that appears in FIXML messages.
Data types are the same as defined by the FIX Protocol.
Required / Present for Security Type
Required / Present for Asset Class
Required / Present for Outright or Spread
For inbound messages, indicates whether the attribute is required for a specific Security Type, Asset Class, or Outright or Spread. For outbound messages, indicates whether the field is always present in messages CME ClearPort sends for a specific Security Type, Asset Class, or Outright or Spread.
If the field is blank, the attribute is not required on inbound messages, or will not always be present on outbound messages.
A list of enumerated values supported by the field, where defined.
Required FIXML Element Attributes
The following attributes must be included on the FIXML element of each message sent to the API.
FIX Version Number
Indicates the version of FIX being used (including Service Pack).
Schema Release Date
Indicates the release date of the FIXML Schema.
FIXML Extension Version
Indicates the FIX Extension version.
Custom Application Version
Indicates the Custom Application version.
Batch Container (HTTP Only)
Depending on the selection criteria, Security Definition Requests and Trade Capture Report Requests submitted over HTTP may result in multiple TrdCaptRpt messages. The CME ClearPort API handles these types of responses to HTTP clients by encapsulating a single Header plus all repeating messages within FIXML Batch tags.
Every FIXML Message contains a Standard Header, as follows:
Standard Header for non-Allocation Request and Submissions
This attribute identifies the party or the Submitter of the message. The value is assigned by CME.
This attribute qualifies the Sender. The user ID assigned to the sender must be provided.
This attribute identifies the receiver of the message. This must be set to CME.
Standard Header for Allocation Request and Submissions
R – Required
O - Optional
|Sender ID||This attribute identifies the party or the Submitter of the message. The value is assigned by CME.||ABC||/FIXML/AllocInstrctn/Hdr/@SID||R|
|Sender Qualifier||This attribute qualifies the Sender. The user ID assigned to the sender must be provided if it is assigned. (This is optional)||User123||/FIXML/AllocInstrctn/Hdr/@SSub||R|
|Target ID||This attribute identifies the receiver of the message. This must be set to CME.||CME||/FIXML/AllocInstrctn/Hdr/@TID||R|
|Target Qualifier||This qualifies the receiver of the message. This will be set to CME now.||CME||/FIXML/AllocInstrctn/Hdr/@TSub||O|
Standard Header for non-Allocation Responses
This attribute identifies the party or the Submitter of the message. This is set to CME.
This attribute qualifies the Sender. For messages sent by the CME ClearPort API this is set to CPAPI.
This attribute identifies the receiver of the message. This could be a Broker or Platform or any other valid Trading entity. This value is pre-assigned by CME.
Standard Header for Allocation Responses
P – Always Present
|Sender ID||This attribute identifies the party or the Submitter of the message. The value is set to CME.||CME||/FIXML/AllocRpt/Hdr/@SID||P|
|Sender Qualifier||This attribute qualifies the Sender. For messages sent by the ClearPort API this is set to CPAPI.||CME||/FIXML/AllocRpt/Hdr/@SSub||P|
This attribute identifies the receiver of the message. This could be a Broker or Platform or any other valid Trading entity.
This value is pre-assigned by CME.
|Target Qualifier||This qualifies the receiver of the message. This will be set to a ClearPort UserID of the Sender if it was provided on the inbound.||CME||/FIXML/AllocRpt/Hdr/@TSub||P|
Responses to malformed messages use the FIXML Business Message Reject (located under Application Level Messages- Infrastructure in the FIX Specification). Malformed messages sent over MQ, including messages sent with an invalid Sender Comp ID (SID) and/or Target Comp ID (TID), do not receive a response.
The following actions can result in a Business Message Reject response:
- If the Header information is incorrect.
- If the message type is not recognized or supported.
- If a component of a recognized message is missing.
|Message Type||FIXML Abbreviation||Description|
|User Request||UserReq||Sent by the submitter while establishing a session using HTTP as a transport. The message is used to login, logoff or change a password.|
|User Response||UserRsp||Sent by the CME ClearPort API in response to a CME ClearPort API - User Request message. This communicates the status of the User Request.|
|Trade Capture Report - Inbound||TrdCaptRpt||Used to report a new trade into CME ClearPort or to modify, cancel, or void a previously submitted trade.|
|Trade Capture Report Acknowledgment - Outbound||TrdCaptRptAck||Sent by CME ClearPort in response to a submitted Trade Capture Report message. The message table describes the usages of attributes by asset classes. Certain attributes may not be available in HTTP acknowledgments.|
|Trade Capture Report - Outbound||TrdCaptRpt|
Used by CME ClearPort to report the status of the trade.
|Trade Capture Report Request - Inbound||TrdCaptRptReq||Sent to a submitter of the trade using HTTP as a transport to request for the status of trade. This is because submitters using HTTP cannot receive unsolicited messages published by the API.|
|Trade Capture Report Request Acknowledgement - Outbound||TrdCaptRptReqAck||Sent to a submitter in response to a Trade Capture Report Request that was not processed.|
|Business Reject||BizMsgRej||Sent in response to a malformed message that could not be processed by CME ClearPort but parse correctly and do not have session-level rule violations.|
|Allocation Instruction - Inbound||AllocInstrctn||Sent by platforms on behalf of allocation agents (like asset managers and brokers) or the clearing firm (standby FCM) to allocate a cleared bunched order. They also send this message to resubmit or cancel an allocation.|
Sent by CME Clearing to the submitter (platform or clearing firm) to report on the current state of an allocation.
For example, CME Clearing sends an Allocation Report to notify that an allocation is in a pending clear state or has been cleared or rejected.
|Allocation Instruction Ack - Outbound||AllocInstrctnAck||Sent by CME Clearing to reject any instruction submitted by a platform or clearing firm when it cannot process the instruction.|