Page Comparison

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

...

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

...

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.

...

This flow shows the messages sent when a clearing firm changes the account for a trade, causing the trade to transition from Firm A to B. Firm B receives the trade replaced message (@TransTyp @TransTyp = 2) even though Firm B never saw the new trade (@TransTyp @TransTyp = 0). Firms are not guaranteed to see the trade as new (@TransTyp @TransTyp = 0) and must be able to process trades first encountered as replaced (@TransTyp @TransTyp = 2).

This example also illustrates a second transition from Firm B back to Firm A. The identity (@TrdID and @TrdID2@TrdID and @TrdID2) of the trade does not change. Note that Firm A receives a trade cancelled message (@TransTyp @TransTyp = 1) followed later by a trade replaced message (@TransTyp @TransTyp = 2). Firms must be able to process this sequence of events.

...

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  @TrdSubTyp indicates whether the message is a Differential (7) or Spread (8). @DiffPx  @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 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. Spread trades (@MLegRptTyp = 3) are unsupported with product legs that are on or cleared through different Exchanges.

The next flow show 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. Spread trades (@MLegRptTyp = 2) are supported with product legs that are on are on or cleared through different Exchanges.

Anchor
Allocation Workflow Allocation Workflow

Allocation

...

CME STP allocates spreads at the leg level only, so the API does not mark spread level messages for allocation. For users requesting @MLegRptTyp = 2 (individual leg of a multi-leg security), allocation of spread legs is no different than allocation of outright trades, except that @MLegRptTyp = 2 instead of 1.

For firms requesting spread level messages, (for example,  @MLegRptTyp  @MLegRptTyp = 3), allocation behaves differently. When a clearing firm marks a leg of a spread for allocation, the API sends a message showing that individual leg as an @MLegRptTyp = 2 to the executing firm, even though the user only requested @MLegRptTyp = 3. The field @StrategyLinkID can be used to link the allocated leg to the multi-leg spread message. The offset and onset trades after the claiming firm claims the allocation are no different than before. Should a clearing firm un-mark a trade for allocation (not illustrated), the API will send a message with @MLegRptTyp = 2 showing the leg as un-marked.

...