This page outlines conflated TCP market data group processing.

...

EBS Session Access Model

The following table outlines the conflated TCP session market access model for EBS markets.

...

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.

...

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.

...

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.

...

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:

...

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

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

...

Client System to CME Globex Request Messages

...

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.

...

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.

...

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.  

All Market Data 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 SnapshotFullRefresh (tag 35-MsgType=W) messages for instruments offered on the respective channel.  
• Snapshot and updates (tag 263-SubscriptionReqType=1) - Provides a current list of SnapshotFullRefresh (tag 35-MsgType=W) messages for instruments offered on the respective channel and a subscription to all subsequent messages applicable to the session.  
• 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 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.

Snapshot Full Refresh (35=W) messages will not be sent for the instruments that have only price bands or thresholds, but have had no book activity since the beginning of the week.

...

CME Globex to Client System Response Messages

The CME Globex response messages outlined below are sent in response to Client System Request Messages.

Request Acknowledgment (tag 35-MsgType=V) Message

The Request Acknowledgment (tag 35-MsgType=V) message is sent from CME Group to the client system as a reply to any type of Request that is Fully or Partially Acknowledged. The status of the request is denoted on the Market Data Status ID (tag 37720-MDReqIDStatus):

...

Request Reject (tag 35-MsgType=Y) Message

The Request Reject (tag 35-MsgType=Y) message is sent from CME Group to the client system as a reply to any type of request that is fully rejected. The field Market Data Reject Reason (tag 281-MDReqRejReason) provides the reject reason:

• Unknown Security (tag 281-MDReqRejReason=0) - All securities requested are unknown
• Unknown Message (tag 281-MDReqRejReason=1) - Unknown or invalid message sent
• Unsupported Scope (tag 281-MDReqRejReason=2) - Unsupported scope 
• Other (tag 281-MDReqRejReason=3) - Other

The text field (tag 58-Text) provides the reason for the rejection. 

...

TCP MDP Request Message Rules 

This section summarizes request message rules for Security List Request, Security Status Request, and Market Data Request messages.  

• Requests (security, status or data) can be made at the security group (tag 1151-SecurityGroup) or the instrument (tag 48-SecurityID) level.
  • A maximum of 254 instruments is allowed per request
• If a client is entitled to security group(s) and requests all groups (NoSecurtiyGroups=0, NoRelatedSym=0), RequestIDStatus=FullAck message will be sent.
• If a client system specifies both SecurityGroup and SecurityID lists in the same message, the MDP gateway will reply only with the SecurityGroup subscriptions and MDReqIDStatus= Partial.
• If a request is made and some (but not all) of the security group or instruments are not entitled, then the MDP gateway will reply with a partial ack (MDReqIDStatus= Partial).
• Tag 262-MDReqIDStatus should be unique for the week.
• If a client system with existing entitlements makes a request for only security groups or instruments to which the customer is not entitled, then a request rejection will be sent
• If a request is made on a session with NO entitlements, the request is rejected and the session is terminated 
  
• If a client system is subscribed to a group and a new instrument is added to the same group mid-week, client systems will begin to receive real-time updates to that instrument.
• If entitlements for new security group/instruments are added mid-week, the following occurs:
  • Additional security group/instruments will be available, however the session will not send the newly entitled security group/instruments updates unless a request is sent.  

• If entitlements for new security group/instruments are reduced mid-week, then the following occurs:
  • If all entitlements are removed, the gateway will terminate the connection.
  • If the entitlements are partially removed, the gateway will stop sending data for instruments/groups that have been removed. 
• Session subscriptions will be removed either via an unsubscribe (tag 263-SubscriptionReqType=2) request message or disconnection.

• The conflated TCP gateway maintains a single subscription scope per connection and any new requested scope will be merged into already acknowledged subscription scope for the connection. A Security Group subscription will maintain priority over individual instrument subscription requests.  

Conflated MDP TCP - Mid-Week Join and Recovery

For a client system mid-week join, or in the event of a CME Group Conflated MDP TCP component failure, the client system must reestablish a TCP connection, negotiate, and re-subscribe via request messages. Subscription requests and book states are reset at session disconnection and must be reestablished upon re-connection. To ensure there are no in-flight data issues during a mid-week join or component recovery, CME recommends client systems send request messages in the following order with tag 263-SubscriptionReqType=1 (Snapshot and Updates):

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

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

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

Conflated TCP Messaging Examples

...

Example 2 - Negotiation Reject and CME Initiated Termination 

In this is example a client system attempts to log on three times before a CME Group-initiated terminate is sent due to three unsuccessful negotiation attempts. After the third invalid invalid negotiate message, the MDP Conflated TCP Gateway will not send a only respond with a terminate message. In the example, the invalid values are denoted in red.

...

Example 3 - Subscriber Heartbeat 

In this example, the client system sends a Subscriber Heartbeat ( via template SubscriberHeartbeat210) due to 30 seconds of inactivity. Then, following 60 seconds of inactivity from the client system, the session is terminated. 

Example 4 - Incomplete Negotiation and Termination

In this example, after a client system Negotiate message is sent, the client system sends an additional message before the connection is authenticated and the gateway responds with a NegotiationResponse. Consequently, the gateway sends a Terminate message and closes the connection.

...

Example 10 - Recovery 

In the unlikely event of a CME Group Conflated MDP TCP Gateway failure, client systems must reestablish a TCP connection, negotiate and re-subscribe via request messages. In this example, once a FIX connection has been terminated, Subscription requests and book states are reset.  To ensure data there are no in-flight data issues, during a recovery, CME recommends sending request messages in the following order with tag 263-SubscriptionReqType=1 (Snapshot and Updates):

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

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

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

...