CME ClearPort API - FIXML Message Specification

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

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.



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

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.




How was your Client Systems Wiki Experience? Submit Feedback

Copyright © 2024 CME Group Inc. All rights reserved.