Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This page describes supported CME STP functions: 

Table of Contents

Use this search bar to search topics within the

Portfolio Manager API

CME STP.

This page describes supported Portfolio Manager API message types:

Table of Contents
 
Page Tree Search
rootPage

Portfolio Manager API

CME STP


Related Content


Children Display
pageCME STP - Supported Functions



Trade Capture Report and Notifications

Related Content
Children Display
pageCLIMP:Portfolio Manager API

The PM API CME STP supports the following information in Trade Capture Report messages:

Allocation Notifications (single
Info

Single trade allocations are treated as group allocations, where the group has just one trade

)Allocation Release/ Reversal Notifications

.

    1. Trade marked / unmarked for allocation
    2. Offset and Onset trades when an allocation is claimed
    3. Offset and Onset trades when an allocation is released / reversed
    4. MOS (Mutual Offset System) allocations, allowing foreign exchanges to allocate to a CME Firm and vice versa, are treated like normal allocations.
  • Spread and Leg level messages
  • Change of Trading Firm. When the Trading Firm is changed on the transaction, the PM API  CME STP sends a Cancel Notification to the previous Trading Firm and a New Trade Notification is sent to the new Trading Firm. See the message flow for this function. 
  • MOS Allocations - the Mutual Offset System allows foreign exchanges to allocate to a CME Firm and vice versa.

Subscriptions and Queries

Retrieve The 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 
Subscriptions continue
  • continue to send trade messages to the user
as long as this information becomes available
  • on an ongoing basis; there is no end date time.

Multiexcerpt include
MultiExcerptNameSTP Query
nopaneltrue
PageWithExcerptCME STP

CME STP supports subscription or query requests for a specific Party Role (Inter-Dealer Broker, Asset Manager, Trading Firm). Separate subscription or query requests must be submitted for each Party Role to obtain complete information.

Continuing a Subscription or Query

The PM When responding to a successful Subscription Request, the API sends a token to a user for as long as information is available for the subscription or query. The subscription or query response continues as long as the user returns the token to the API.

Sending a subscription or query response without the token results in the  API returning a complete set of unfiltered trade messages.

See the message flow for this function. 

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 token if it is a new subscription or query; all continuations of existing subscriptions or queries must include a token.

API InputAPI Output

Subscription / Query

Request for all Data

Request: FIXML Trade Capture Report Request


Successful Subscription

Response for all data

/ Query Response: FIXML Trade Capture Report


Subscription
Error Response – Inappropriate Permission

Subscription/Query Request with Filters

Successful Subscription Response with Filtered Messages

Subscription Error Response – Inappropriate Permission

Subscription/Query Continuation with TokenSubscription Response with Token
/ Query Error Response: FIXML Trade Capture Report Request Ack

Tokens

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.

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

Use ONLY the following parameters to filter the query and/ or subscription results. Omitting, changing, or adding filter criteria may cause undesired results. 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. The time should include an offset, e.g. 2013-10-22T11:00:00-05:00 represents October 22, 2013 11:00 AM local time, where local time has an offset of -5 hours from UTC.

ParameterUsage / DescriptionXPathNotes

Party ID and Role

(R) <<Broker

(e.g. Trading Firm, Asset Manager,

Trading Firm>>
  • Trade Date (TrdDt)
  • Venue (InptSrc)
  • Product (Instrmt.ID)
  • Product Type <<SecTyp eg. FUT, OPT, MLEG>>
  • Exchange (Exch)
  •    

    Broker)

    Required  /

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

    /FIXML/TrdCaptRptReq/Pty/@ID

    /FIXML/TrdCaptRptReq/Pty/@R


    Trade DateOptional/FIXML/TrdCaptRptReq/TrdCapDt/@TrdDt
    Clearing Business DateOptional/FIXML/TrdCaptRptReq/@BizDt
    Venue (Input Source)Optional/FIXML/TrdCaptRptReq/@InptSrc
    ProductOptional/FIXML/TrdCaptRptReq/Instrmt/@ID
    Product Type (e.g. FUT, OPT)Optional/FIXML/TrdCaptRptReq/Instrmt/@SecTyp
    ExchangeOptional/FIXML/TrdCaptRptReq/Instrmt/@Exch
    Trade IDOptional/FIXML/TrdCaptRptReq/@TrdID
    Secondary Trade IDOptional/FIXML/TrdCaptRptReq/@TrdID2
    Client Order IDOptional/FIXML/TrdCaptRptReq/@ClOrdID
    Spread TypeRequired/FIXML/TrdCaptRptReq/@MLegRptTyp


    Start Time

    Optional on Requests

    Required on Queries

    /FIXML/TrdCaptRptReq/@StartTm
    End Time

    Not Allowed on Requests

    Optional on Queries

    /FIXML/TrdCaptRptReq/@EndTmCustomers can enter an end time that is seconds before the Last Update Time (LastUpdateTm) timestamp on a revised trade (for example, a Give-up) to capture the trade in its original state.

    Subscription Usage

    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 guarantee that they do not miss trading activity by sending too narrow a time window that misses trading activity, or that they do not process any duplicate any 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.

    Allocations

    CME STP supports allocations, which means one firm "gives-up" trades to another firm. The firm that executed a trade (i.e. Executing firm) may want to "allocate" or "give-up" a trade to a different firm (i.e. Claiming firm).

    The Executing firm will receive an Offset message to indicate that the trade is being removed and the Claiming Firm will receive an Onset message to indicate the trade is now on their books.

    In addition to Offset and Onset messages, CME STP sends a notification when the trade is marked for allocation. CME STP supports allocations only at a leg (and not spread) level.

    In summary, the following are the steps for the allocation of legs of a Spread:

    • Leg marked for allocation: MLegRptTyp2 message received indicting which leg was marked for allocation sent to Executing Firm. See Mark for Allocation (Spread) in the Allocations section for details of this message
    • Allocation accepted by Claiming Firm: MLegRptTyp1 message sent to Executing and Claiming Firms. 
    • Both of the above messages will be available in CME STP when Subscription or Query filter is MLegRptTyp=3

    Reverse or Release

    An allocation is reversed or released on the following trading day.

    In the case of a reversal or release of an allocation, CME STP will report both the offset and onset trades as cancelled (@TransTyp = 1).  Parameters on the cancel will mirror those of the original offset or onset, e.g. the side of the cancel message will match the side of the respective offset or onset message.

    The Trade fields at the Trade Capture Report Level  are specific to reversals and releases.

    Correction

    Price or quantity on a trade is corrected after the trade has cleared.

    The Trade fields at the Trade Capture Report Level, Amt and RptSide message block contain fields that are specific to corrections.

    See the following message samples:

    Original Trade

    CME STP Message

    <TrdCaptRpt

    LastUpdateTm="2014-05-13T02:50:07.554-05:00"

    TxnTm="2014-05-13T02:50:07-05:00"

    MLegRptTyp="1"

    BizDt="2014-05-13"

    TrdDt="2014-05-13"

    LastPx="30.000"

    LastQty="100"

    VenuTyp="X"

    PxTyp="2"

    ExecID="6057530"

    MtchID="145F34109A42155C90"

    TrdTyp="1"

    ReqID="ABC124"

    TrdRptStat="0"

    RptTyp="101"

    TransTyp="2"

    TrdID2="145F34109A42155C94"

    TrdID="100001"

    RptID="145F34109A42155C944025007554"

    <Amt

    Ccy="USD"

    Amt="-30000000.00"

    Typ="PREM"/>

    <RptSide

    CustCpcty="2"

    InptSrc="CPC"

    ClOrdID="C6057530"

    Side="1">

    </TrdCaptRpt>




    Opposite Side of Trade Sent to Bust the Original Trade 

    CME STP Message

    Notes

    <TrdCaptRpt


    <RptSide

    Side="2"

    ClOrdID="C6057530"

    InptSrc="TES"


    CustCpcty="2">


    Opposite side of original trade


    (field value change) TES=Trade Entry System


    </TrdCaptRpt>



    Trade Sent After Correction

    CME STP Message

    Notes

    <TrdCaptRpt


    RptID="145F34109A42155CBA1035344806"

    ExecID="6057530"

    TrdID="100005"

    MtchID="145F34109A42155CB6"

    LastPx="25"

    TxnTm="2014-05-13T03:53:44-05:00"

    TrdDt="2014-05-13"

    BizDt="2014-05-13"

    TransTyp="0"


    MLegRptTyp="1"

    ReqID="ABC124"


    LastQty="300"

    LastUpdateTm="2014-05-13T03:53:44.807-05:00"

    TrdTyp="1"

    VenuTyp="X"

    PxTyp="2"

    TrdRptStat="0"

    RptTyp="101"

    TrdID2="145F34109A42155CBA"





    Price amended









    Quantity amended

    <Amt

    Typ="PREM"

    Amt="-75000000.00"

    Ccy="USD" />



    New amount


    <RptSide

    Side="1"

    ClOrdID="C6057530"

    InptSrc="CPC"


    CustCpcty="2">


    Same side as original trade




    </TrdCaptRpt>