This page outlines conflated TCP market data group processing.

Session Attributes

The conflated TCP Market Data Group uses the FIX and SBE protocol to establish and manage bi-directional sessions. A MDP TCP session is defined as a bi-directional message stream between two parties. A session will be maintained by default on a weekly basis and represented with a Universally Unique ID (UUID), which is recommended to the current timestamp. A client system can Negotiate and Terminate multiple times intra-day or at the end of each day, with the same UUID, or Negotiate the new session with a new UUID. 

BrokerTec Session Access Model 

The same MDP TCP Sessions can be used for U.S. markets, U.S. Treasury Actives, and U.S. Repo. The same MDP TCP Sessions can be used for EU markets, EU Repo and EGBs. The following table outlines the session access model for BrokerTec.

EBS Session Access Model

The following table outlines the conflated TCP session market access model for the EBS Market on CME Globex.

Packet Structure

The encoded FIX transmission for the CME MDP Conflated TCP market data group is sent in a packet structured. The following diagram shows the structure of an SBE-encoded message for the conflated TCP market data group:

The following table outlines the packet concepts in the diagram above:

Conflated MDP TCP - Initialization and Unbinding

Conflated MDP TCP uses the FIX protocol via Simple Binary Encoding (SBE) to establish and manage bi-directional sessions. A session is defined as a bi-directional stream of ordered messages between two parties. Conflated MDP TCP accepts one connection per session ID.

For more information regarding encoding and decoding SBE messages consult the MDP 3.0 - Simple Binary Encoding topic.

TCP MDP Session Messages

TCP MDP session messages are summarized as follows. 

Universally Unique Identifier (UUID)

Each session established at the start of the week, intra-day, or at the beginning of each trading day is represented with a unique UUID value set by the customer as a 64-bit value. CME Group recommends using the system timestamp, which represents the number of microseconds since the epoch (Jan 1, 1970) as the timestamp. 

Session Security

The customer will authenticate a TCP MDP session by digitally signing the Negotiate message using a hashed message authentication code (HMAC). In general, the customer interaction with CME will be as follows:

1. Customer logs into the CME Self Service Portal using 2-factor authentication over a secure channel (HTTPS).

2. CME generates a pair of cryptographically random keys—an Access Key and a Secret Key—for the customer. The keys are provided to the customer and also securely stored in a secure vault with CME.

3. Customer connects to MDP TCP and sends a digitally signed Negotiate message. The digital signature is generated using a hashed message authentication code (HMAC) based on the contents of the message and the Secret Key and is included in the Negotiate message sent to CME.

4. CME processes the Negotiate message and calculates the digital signature using the same HMAC-based process, and compares the calculated signature with the signature provided on the customer's Negotiate message. If the signatures match, the Negotiate message is authentic and validates that the sender has the Secret Key.

The details of calculating the digital signature are described below.

Steps to Sign a Login Request to MDP TCP

1. Create the canonical Negotiate message

2. Create Signature Using the Secret Key and Canonical FIX Message  

3. Populate Signature in the Credentials Field

Step 1 - Create the Canonical FIX Message

Concatenate these fields into a single String delimited by the newline character (ie. '\n');

The required fields in Negotiate message are:

• RequestTimestamp

• UUID

• SessionID

• FirmID

Step 2 - Create Signature Using the Secret Key and Canonical FIX Message 

The signature is a hash (digest) of the canonical message created in Step 1 using the Secret Key provided by CME. 

The Secret Key downloaded from Request Center is Base64 URL Encoded. Customers must decode the secret key first.

Example of Creating Signature Using HMAC SHA256 in Java 8+

The HMAC signature is populated in a fixed length string field (i.e. String32Req) since SHA-256 signature is always 32 bytes.

Encoding options for SHA-256 (256 bits long):

• Base64URL encoding FIX ASCII: 6 bits per char = CHAR(44)including padding character

• Hex: 4 bits per char = CHAR(64)

  • HEX example → 617633EFEF2F98DCA32DD3BD8407122B9B375CF4BC076930F24C1F7A0F930094

• Binary: 8 bits per byte = BINARY(32)

  • Binary example → byte array:[97, 118, 51, -17, -17, 47, -104, -36, -93, 45, -45, -67, -124, 7, 18, 43, -101, 55, 92, -12, -68, 7, 105, 48, -14, 76, 31, 122, 15, -109, 0, -108]

Signature calculation in Java:

Step 3 - Populate Signature in the Credentials Field

Populate the Signature from Step 2 into the HMACSignature field.

Session Negotiation

An MDP TCP session connection is initiated by the customer using a Negotiation message. The UUID must be sent in the Negotiation message and that ID is used for the lifetime of the session. Negotiation is provided as a mechanism used for the customer to declare what ID they will be using. There is no concept of resetting a session. Instead of starting over a session, a new session is negotiated with a new UUID.

The following required string fields cannot contain empty bytes:

• HMACSignature

• AccessKeyID

• Session

• Firm

• UUID

The following field will be checked for boundary conditions:

• RequestTimestamp
  
  

The customer should send a Negotiate message to the exchange and await acknowledgment.

• When Negotiate message from customer is accepted by CME, then CME will return a Negotiation Response.

• When Negotiate message from customer is rejected by CME, then CME will return a Negotiation Reject.

• If no response is forthcoming from the exchange after two 30 second heartbeat intervals have lapsed then Negotiation can be retried or out-of-band inquiry may be made to determine application readiness.

• If a client system sends a message before a connection has been authenticated and an acknowledgment has sent, the client system will receive a Terminate message from the gateway.

Heartbeat

The client system must send a heartbeat within the heartbeat interval of 30 seconds via template SubscriberHeartbeat210. The Conflated MDP TCP Gateway will send a heartbeat via template AdminHeartbeat12 if there is no market activity. Client systems not sending a heartbeat after two heartbeat intervals will be disconnected.

Unbinding 

Termination

The Terminate message is used to signal that the sender is going to disconnect the TCP socket connection. The Terminate message initiates the termination of a FIX session. Once a FIX connection has been terminated, Subscription requests and book states are reset.

Conflated MDP TCP - Request Messages

The following section outlines request message market data functionality provided by CME Globex. Once the client system has established a FIX session, client systems may send request messages.   Subscription requests only apply to their respective channels. 

TCP MDP Request Messages and Response Messages

Conflated MDP TCP payload messages are summarized as follows. 

Client System to CME Globex Request Messages

Request messages allow Conflated TCP client systems to recover and to subscribe to instruments or security groups. Specific request message ordering is not required. Client systems are required to be in Negotiated status before any requests are processed, otherwise the connection is Terminated. Subscription requests and book states are reset at session disconnection. Therefore, subscriptions and books must be rebuilt must be reestablished after TCP reconnection and successful Negotiation.  Message responses to request messages maintain the original tag 60-TransactTime of when the message was initially sent.  

Security List Request Message (tag 35-MsgType=x)

The Security List Request message (tag 35-MsgType=x) is a request message that allows client systems to recover all security definition (tag 35-MsgType=d) messages and to subscribe to any subsequent updates to security definition messages. All Security List Request messages must include a unique ID in tag 262-MDReqID. The MDReqID is used to identify the response message. On Conflated TCP market data groups, expired instruments will be removed after the market close.

The Subscription Request Type (tag 263-SubscriptionReqType) indicates the type of response expected:

• Snapshot (tag 263-SubscriptionReqType=0) - Provides a current list of security definition (tag 35-MsgType=d) messages offered on the channel

• Snapshot and updates (tag 263-SubscriptionReqType=1) - Provides a current list of security definition (tag 35-MsgType=d) messages offered on the respective channel and a subscription to subsequent security definition updates

• Unsubscribe (tag 263-SubscriptionReqType=2) - Unsubscribes previous subscription.

Requests can be made at the security group (tag 1151-SecurityGroup) level or the instrument (tag 48-SecurityID) level. The security repeating group (tag 37022-NoSecurityGroups) should be equal to zero when a subscription is requested for all groups on the segment or individual Security IDs. The instrument repeating group (tag 146-NoRelatedSym) is the number of instruments requested. When NoSecurityGroups is greater than zero, the NoRelatedSym should be zero. If both NoSecurityGroup and NoRelatedSym are equal to zero then the request will be for all entitled groups. 

After sending a Snapshot (tag 263-SubscriptionReqType=0) or Snapshot and updates (tag 263-SubscriptionReqType=1) message, the gateway will mark the End of Event (bit 7 equal to 1 via tag 5799-MatchEventIndicator) on the last message. After the End of Event is received, client systems may expect to receive heartbeats or further messaging related to the subscription.  For Security List Requests, the original 60-LastUpdateTime denotes when the instrument added or an update was last sent.

Example Security List Request Message (tag 35-MsgType=x)

Security Status Request Message (tag 35-MsgType=g)

The Security Status Request message (tag 35-MsgType=g) allows client systems to recover all security status (tag 35-MsgType=f) messages and to subscribe to any subsequent updates to security status messages. All Security Status Request messages must include a unique ID in tag 262-MDReqID. The MDReqID is used to identify the response message. 

The Subscription Request Type (tag 263-SubscriptionReqType) indicates the type of response expected:

• Snapshot (tag 263-SubscriptionReqType=0) - Provides a current list of security status messages (tag 35-MsgType=f) offered on the channel

• Snapshot and updates (tag 263-SubscriptionReqType=1) - Provides a current list of security status messages (tag 35-MsgType=f) offered on the channel and a subscription to subsequent security status updates

• Unsubscribe (tag 263-SubscriptionReqType=2) - Unsubscribes previous subscription.

Requests can be made at the security group (tag 1151-SecurityGroup) level or the instrument (tag 48-SecurityID) level. The security repeating group (tag 37022-NoSecurityGroups) should be equal to zero when a subscription is requested for all groups on the segment or individual Security IDs. The instrument repeating group (tag 146-NoRelatedSym) is the number of security status messages requested. When NoSecurityGroups is greater than zero, the NoRelatedSym should be zero. If both NoSecurityGroup and NoRelatedSym are equal to zero then the request will be for all entitled groups.  

After sending a Snapshot (tag 263-SubscriptionReqType=0) or Snapshot and updates (tag 263-SubscriptionReqType=1) message, the gateway will mark the End of Event (bit 7 equal to 1 via tag 5799-MatchEventIndicator) on the last message. After the End of Event is received, client systems may expect to receive heartbeats or further messaging related to the subscription.

Example Security Status Request Message (tag 35-MsgType=g)

Market Data Request Message (tag 35-MsgType=V)

The Market Data Request message (tag 35-MsgType=V) is a request message that allows client systems to recover the current state of Market By Price (MBP) books in the Snapshot Full Refresh message (tag 35-MsgType=W) and subscribe to all subsequent messages applicable to the session. The Snapshot Refresh Message is sent via SBE template SnapshotRefreshTopOrders59.