CME STP FIXML - Message Flows for BrokerTec Trades

This page describes the sequence and flow of information (showing key FIXML fields) between the User and the CME STP. 

Subscription

This flow shows the User requesting a subscription to CME STP and the API response.

• After sending a subscription request to the API with @ReqTyp = 1, the User receives a token along with zero or more Trade Capture Report messages inside a FIXML batch, e.g. /FIXML/Batch/TrdCaptRpt

• The User must return the token with the next Trade Capture Report Request to continue to receive trade information without duplication or loss, along with @ReqTyp = 3. 

•  

  • If the token is not sent back, the API considers this an error, and responds with the Trade Capture Report Request Ack message.

  • A new token is issued for each subscription or query request.

• Upon receipt of the previous response, submit a new subscription response no sooner than 3 seconds later.

• If no new data is available since the user's last query, the API will send the user an empty batch with a token.

Query

This flow shows the user querying CME STP and the API response.

After sending a query to the API with @ReqTyp = 1, the user receives zero or more Trade Capture Report messages inside a FIXML batch, e.g. /FIXML/Batch/TrdCaptRpt, as follows:

• If no trades match the query parameters, the API sends an empty FIXML batch and no token.

• If all trades that match the query parameters can be sent inside one FIXML batch, the API will do so, and will not send a token.

• If more trades match the query parameters than can be sent inside one FIXML batch, the API sends some of the messages inside a FIXML batch, and includes a token for continuing the query.

In the latter case, to continue a query, the user must return the token with the next Trade Capture Report Request, along with @ReqTyp = 3. If the token is not sent back, the API considers this an error, and responds with the Trade Capture Report Request Ack Message. The User must send the last received token, as this enables the API to send the query results without duplication or loss. A follow up query may be performed immediately, with no need to wait 3 seconds. This process can continue, with the API sending a token and the user returning the token on the next Trade Capture Report Request, along with @ReqTyp = 3, until no more trades are available that match the query parameters. When the API sends the last batch of trades, it will not send a token. The absence of a token indicates that the results are complete, and the user should not continue sending Trade Capture Report Request messages for this query.

Spreads

The following 2 flows show the different types of spread level information that a user can request and consume.

The first flow shows the user requesting Spread level trades (@MLegRptTyp = 3). The API then responds with Outrights (@MLegRptTyp = 1) as well as Spread level messages (@MLegRptTyp = 3). @TrdSubTyp indicates whether the message is a Differential (7) or Spread (8). @DiffPx carries the Spread or Differential price (e.g. 0.01). This trade has multiple legs, each identified in by the /FIXML/Batch/TrdCaptRpt/TrdLeg component. The full list of TrdLeg FIXML fields returned by the API, is available in the FIXML Message Specification. The field @StrategyLinkID can be used to link legs of a strategy with the multi-leg spread messages. Although in this example, legs are not sent, they can be sent in the case of allocations of spreads.

The next flow showS the user requesting Leg level trades (@MLegRptTyp = 2). The API then responds with Outrights (@MLegRptTyp = 1) as well as Leg level messages (@MLegRptTyp = 2). The trades do not have multiple legs, therefore /FIXML/Batch/TrdCaptRpt/TrdLeg is not present. The field @StrategyLinkID can be used to link legs of a strategy together.

Collateral Processing