Skip to end of banner
Go to start of banner

CME ClearPort API - FIXML Message Specification

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

Version 1 Next »

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.

See the following topics on this page:

 

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:

PropertyDescription

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.

FieldDescriptionValid ValueXPath

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

FieldDescriptionValid ValueXPath

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

FieldDescriptionExampleXPathOn Submission
Sender IDThis attribute identifies the party or the Submitter of the message. The value is assigned by CME. ABC/FIXML/AllocInstrctn/Hdr/@SID R
Sender QualifierThis 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 IDThis attribute identifies the receiver of the message. This must be set to CME. CME/FIXML/AllocInstrctn/Hdr/@TID R
Target QualifierThis 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

FieldDescriptionValid ValueXPath

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

FieldDescriptionExampleXPathOn Submission
Sender IDThis attribute identifies the party or the Submitter of the message. The value is set to CME. CME/FIXML/AllocRpt/Hdr/@SID P
Sender QualifierThis 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 QualifierThis 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 TypeFIXML AbbreviationDescription
User RequestUserReqSent by the submitter while establishing a session using HTTP as a transport. The message is used to login, logoff or change a password.
User ResponseUserRspSent 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 - InboundTrdCaptRptUsed to report a new trade into CME ClearPort or to modify, cancel, or void a previously submitted trade.
Trade Capture Report Acknowledgment - OutboundTrdCaptRptAckSent 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 - OutboundTrdCaptRpt

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 - InboundTrdCaptRptReqSent 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 - OutboundTrdCaptRptReqAckSent to a submitter in response to a Trade Capture Report Request that was not processed.
Business RejectBizMsgRejSent 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 - InboundAllocInstrctnSent 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 - OutboundAllocInstrctnAckSent by CME Clearing to reject any instruction submitted by a platform or clearing firm when it cannot process the instruction.
  • No labels