This section describes all the FIXML messages specifications for the messages used by the CME ClearPort API. This includes messages related to user authentication, trade submission and confirmation reporting, messages to request for trade status and acknowledgment.

Messages are comprised of elements, which may be non-repeating or repeating. Elements contain Attributes which define the trade characteristics.

FIXML is the XML representation of FIX messages, and uses the FIX data dictionary and business logic.

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

See the following topics on this page:

1 Elements
2 Attributes
- 2.1 Attribute Terminology
- 2.2 Required FIXML Element Attributes
3 Batch Container (HTTP Only)
4 Standard Header
5 Malformed Messages
6 Message Specification

Related Content

Related Content

Elements

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.

Attributes

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.

Attribute Terminology

Each attribute is defined by the following properties:

Property	Description

Property	Description
Field Name	The descriptive name associated with the FIXML Attribute Name.
FIXML Attribute Name	The abbreviated name that appears in FIXML messages.
Data Type	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.
Supported Values	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.

Field	Description	Valid Value	XPath

Field	Description	Valid Value	XPath
FIX Version Number	Indicates the version of FIX being used (including Service Pack).	5.0 SP2	/FIXML/@v
Schema Release Date	Indicates the release date of the FIXML Schema.	20090815	/FIXML/@s
FIXML Extension Version	Indicates the FIX Extension version.	109	/FIXML/@xv
Custom Application Version	Indicates the Custom Application version.	CME.0001	/FIXML/@cv

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.

Standard Header

Every FIXML Message contains a Standard Header, as follows:

Standard Header for non-Allocation Request and Submissions

Field	Description	Valid Value	XPath

Field	Description	Valid Value	XPath
Sender ID	This attribute identifies the party or the Submitter of the message. The value is assigned by CME.	SENDER	/FIXML/TrdCaptRpt/Hdr/@SID
Sender Qualifier	This attribute qualifies the Sender. The user ID assigned to the sender must be provided.	User123	/FIXML/TrdCaptRpt/Hdr/@SSub
Target ID	This attribute identifies the receiver of the message. This must be set to CME.	CME	/FIXML/TrdCaptRpt/Hdr/@TID

Standard Header for Allocation Request and Submissions

R – Required

O - Optional

Field	Description	Example	XPath	On Submission

Field	Description	Example	XPath	On Submission
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

Field	Description	Valid Value	XPath

Field	Description	Valid Value	XPath
Sender ID	This attribute identifies the party or the Submitter of the message. This is set to CME.	CME	/FIXML/TrdCaptRpt/Hdr/@SID
Sender Qualifier	This attribute qualifies the Sender. For messages sent by the CME ClearPort API this is set to CPAPI.	CPAPI	/FIXML/TrdCaptRpt/Hdr/@SSub
Target ID	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	/FIXML/TrdCaptRpt/Hdr/@TID

Standard Header for Allocation Responses

P – Always Present

Field	Description	Example	XPath	On Submission

Field	Description	Example	XPath	On Submission
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
Target ID	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.	230	/FIXML/AllocRpt/Hdr/@TID	P
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

Malformed Messages

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 Specification

Message Type	FIXML Abbreviation	Description

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. This message is sent in response to Trade Capture Report Requests sent by submitters using HTTP. Sent in response to events like, claim, reject, clear etc. These are unsolicited messages sent to submitters using MQ as a transport.
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 Acknowledgment - 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.
Allocation Report - Outbound	AllocRpt	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.

CME Group Client Systems Wiki

CME ClearPort API - FIXML Message Specification