This topic describes the common and core rules of engagement for CME STP FIXML, which are applicable to all markets and venues of CME Group.

Use this search bar to search topics within CME STP FIXML Core:


Related Content

Related Content


Customers can connect to CME STP FIXML API via the following options:

  • New Release Connectivity (Internet Only)

To access CME STP FIXML API over the internet, customers must connect to the following URLs via HTTPS:

  • Production Connectivity

This URL uses certificates signed by a trusted CA and customers do not need to install additional certificates.

Clients must create a Domain Name Service (DNS) record in their systems to associate the DNS name and following IPs to access the STP services or they will receive certificate errors:


Access Type


IP Address

Access Type


IP Address

Internet access

All Products

CDN Leased lines and Site to Site VPN

All Products

CME Glink, CME EConnect, CME LNet, CME Globex Hubs

Futures and Options

CME GLink, CME EConnect, CME Globex Hubs, CME Globex Hub – Aurora and CME LNet


Disaster Recovery Considerations

During a disaster recovery (DR) event clients will automatically be directed to the DR instance of CME STP. Clients do not need to make any connectivity changes.

See CME Group connectivity options.

Development Considerations

HTTP Usage

Users will send Subscription and Query Requests to the API by invoking the HTTP POST method to a URL of the form https://{{Path}}/cmestp/query where CME will assign{{Path}} and communicate it to the user. The content of the POST method is the XML for the Trade Capture Report Request message. The API will respond with a FIXML Batch in case of success, or a Trade Capture Report Request Ack or Business Message Reject in case of an error.

HTTP requests can generate the following error responses:





400 (Bad Request)

In cases of malformed requests, where the API cannot parse valid FIXML, the API will send a Business Message Reject message as the response payload. Otherwise, should the trade fail validation rules, the API will send a Trade Capture Report Request Ack message.

500 (Server Error)

Used when the user request is valid, but the API is experiencing an internal error and cannot process the request at this time. The API will send a Trade Capture Report Request Ack message as the response payload.

Connections to the API utilize HTTPS to provide security. Users will transmit a username and password, assigned by CME, via HTTP Basic authentication. Users must also send this username in the Hdr/@SSub field, and must send a CME assigned firm identifier in Hdr/@SID as well. CME maintains a list of entitlements and will enforce these entitlements when validating query or subscription requests.

The API utilizes the custom HTTP header x-cme-token which users must pass as a Request Header in their HTTP POST method calls to the API when requesting the continuation of a Subscription or Query. The API may return a token in the x-cme-token custom HTTP Response Header, as well as within the FIXML message itself.
CME Group recommends that customer systems have the ability to handle a token length of up to 1500 bytes.

Malformed Messages

Responses to malformed messages use the FIXML Business Message Reject (located under Application Level Messages - Infrastructure in the FIX Specification).
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.

Establishing and Maintaining FIXML Session

  • Interaction with the API is session-less.

  • Username and password is required for each HTTP request.

  • CME STP FIMXL service will send a token in response to valid subscription requests and valid query requests where the response requires multiple pages.

  • Continue the subscription or request the next page of the query by sending CME STP this token on subsequent requests.

  • Both customers and CME STP will use the x-cme-token custom HTTP Request Header to transmit this token.

  • Authentication is required in the header of the HTTP request and should be in format of “username:password” converted to base 64.

FIXML Message Elements and Attributes

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

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

Required FIXML Element Attributes

The following attributes must be included on the FIXML element of each message sent to the CME STP, and will appear on all FIXML messages sent by the API.

FIXML Element


Valid Value

FIXML Element


Valid Value

FIX Version Number

Indicates the version of FIX being used (including Service Pack).

5.0 SP2


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.



Standard Header

All FIXML messages or Batch containers must include a Standard Header with the following four required fields. The following table indicates fields sent on messages from the user to the API. When responding to the user, the API will swap Hdr/@SID with Hdr/@TID, and Hdr/@SSub with Hdr/@TSub



Valid Value



Valid Value

Sender Comp ID

Indicates the sender of the message. Generally a firm level identifier.

Assigned by CME


Target Comp ID

Indicates the recipient of the message. This value is always CME for inbound messages.



Sender Sub ID

Indicates the sender entity. This value must match the username sent via HTTP Basic authentication, and must be in all uppercase letters.

Assigned by CME


Target Sub ID

Indicates the recipient entity. This value is  always STP for inbound messages.



Batch Container

CME STP returns trades (FIXML Trade Capture Report messages) to HTTP clients by encapsulating a single Standard Header followed by zero or more Trade Capture Report messages within the /FIXML/Batch element. The Trade Capture Report messages themselves will not contain Hdr elements. CME STP may send an empty Batch, containing a Hdr but no TrdCaptRpt messages, either because a Query returned no results, or because no new activity occurred for a Subscription. However, in the case of an empty batch for a Subscription, the user must still extract the token and use it in subsequent requests.

A batch can return a maximum of 250 Trade Capture Report messages.  

Example FIXML Batch
<?xml version="1.0" encoding="UTF-8"?> <FIXML v="5.0 SP2" s="20090815" xv="109" cv="CME.0001"> <Batch> <Hdr SID="CME" TID="RYAN" SSub="STP" TSub="RYAN123"/> <TrdCaptRpt ...> ... </TrdCaptRpt> <TrdCaptRpt ...> ... </TrdCaptRpt> <TrdCaptRpt ...> ... </TrdCaptRpt> ... </Batch> </FIXML>

Subscription and Query requests (FIXML Trade Capture Report Request messages) sent by the user to the API. as well as Application level error messages (FIXML Trade Capture Report Request Ack messages) sent by the API to the user, will not use the Batch container. The FIXML element will contain the the element for the message directly. The application level message itself will contain the Standard Header, e.g. /FIXML/TrdCaptRptReq/Hdr

Trade Queries and Subscriptions


Users requiring a continuous record of all trading activity may continue a subscription from one business day to the next. The user ceases sending HTTP requests and, on the next business day, continues the subscription with an HTTP request using the last token received on the previous day. This method ensures that the API will send the user any trading activity that occurred during the time period that the user made no HTTP requests. 

Alternately, users may begin a new subscription each day, specifying a Start Time encompassing any time the user did not send HTTP requests following the end of the prior business day's subscription. Users should exercise caution with this method to ensure they do not miss trading activity by sending too narrow a time window, and that they do not process duplicate trades should the window overlap trades already received on the prior business day.

If the user begins a new subscription and does not send a Start Time, the subscription will begin at the present time and include no past trading activity. This method may result in missed trades should any trading occur after the user ceased sending HTTP requests on the prior business day and before the user initiated the new subscription.

Entitlement will not be available for instrument attributes and that customers may use the existing instrument attributes for filtering or filter on the client side.

Data Retrieval

CME STP supports data retrieval using subscriptions and queries: 

  • Queries return trade messages only up to the date and time that the query request was received by the API.  

  • Subscriptions continue to send trade messages to the user on an ongoing basis; there is no end date time.

Continuing a Subscription or Query

When responding to a successful Subscription Request, the API sends a token to the user so that the user may continue the subscription.

When responding to a successful Query Request, the API sends a token if the results of the query are incomplete (for example, more data is available).

  • Upon receiving a successful response, submit a new Subscription request no sooner than three seconds later, which requires making another HTTP call that contains the token. 

  • For a Query, the user may make another HTTP call containing the token immediately

CME STP will only accept a subscription or query request without a token if it is a new subscription or query; all continuations of existing subscriptions or queries must include a token.

API Input

API Output

API Input

API Output

Subscription / Query Request: FIXML Trade Capture Report Request


Successful Subscription / Query Response: FIXML Trade Capture Report

Subscription / Query Error Response: FIXML Trade Capture Report Request Ack


API input messages continuing prior Subscription or Query Requests must send the token in the custom x-cme-token HTTP header. API output messages will contain the token in the x-cme-token HTTP header.

Each successful response from the API may return a different token. The user must send that new token in the next continued Subscription or Query Request.
CME Group recommends that customer systems have the ability to handle a token length of up to 1500 bytes.

Identifiers and Modes

The user must supply a unique identifier with each query in /FIXML/TrdCaptRptReq/@ReqID which the API will echo back in /FIXML/Batch/TrdCaptRpt/@ReqID for successful requests, and in /FIXML/TrdCaptRptReqAck/@ReqID in case of errors. This enables the user to match the request with the resulting messages. When continuing a Subscription or a Request, the user may reuse the original @ReqID or may send a new identifier. The API will respond with with the @ReqID sent on the request.

The user must indicate in /FIXML/TrdCaptRptReq/@SubReqTyp whether the message is a Subscription or a Query. The user must also indicate via /FIXML/TrdCaptRptReq/@ReqTyp whether this is a new Subscription or Query, or a continuation of a prior Subscription or Query.

Subscription and Query Parameters

Following general parameters are used to filter the query and / or subscription results. Omitting, changing, or adding filter criteria may cause undesired results. Additional parameters as applicable to specific products and/or venues are noted in their specific sections. Every continuation of a Subscription or Query must contain all of the filter criteria of the original subscription or query. Times below, e.g. Start Time and End Time, use the XML xs:dateTime syntax in ISO 8601 format. Time should be entered in UTC Timestamp format.


Usage / Description


Usage / Description

Party ID and Role

(e.g. Trading Firm, Asset Manager, Broker)

Required  /

Multiple Parties allowed, and each Party ID must be in a separate Pty element.



Trade Date



Clearing Business Date



Venue (Input Source)






Product Type









Trade ID



Secondary Trade ID



Client Order ID



Spread Type



Start Time

Optional on Requests

Required on Queries


End Time

Not Allowed on Requests

Optional on Queries


How was your Client Systems Wiki Experience? Submit Feedback

Copyright © 2024 CME Group Inc. All rights reserved.