Page tree
Skip to end of metadata
Go to start of metadata

Subject to applicable regulatory approvals, CME Group will integrate EBS products onto CME Globex and disseminate market data over the CME Market Data Platform (MDP). The integration will impact the following markets:  

  • FX Spot
  • Precious Metal Spot
  • eFix Matching
  • OFF SEF NDF
  • ON SEF NDF

This document provides an overview of the CME Market Data Platform (MDP) concepts with which clients must be familiar to process CME Globex EBS Market market data.

See also: CME Globex EBS Market - Market Data Message Specification.

Contents

Revision History

DateDescription
October 12, 2021Updated diagram for Example 2
September 15, 2021Update all instances of ftp.cmegroup.com to cmegroup.com/ftp.
August 4, 2021Added "Trade Embargo Processing for ON-SEF NDF Instruments" topic.
July 13, 2021

"Getting Started with CME Globex Market Data Processing" - Added note to CME Globex MDP Messaging Concept category description.

"Multiple Updates for Multiple Instruments" - Updated diagram

July 1, 2021"EBS Credit Screened Book Example with Market Best" - Changed "bid" to "sell."
May 10, 2021Removed efix messaging for EBS Ultra New York, EBS Ultra London and EBS Ultra Russian Ruble.
May 4, 2021Added SFTP information to FTP topic.
April 30, 2021

"Instrument States" - Removed Reserved row.

"Instrument Security Status Message (35=f) Tag Usage" - Removed Reserved column.

April 23, 2021

"Credit Screened Market Data Book Management Processing" - Updated first paragraph.

"Trade Summary Message" - Changed 4th column in table from "CME MDP Conflated UDP" to "CME MDP Conflated TCP."

March 4, 2021"FTP Site Information" - Changed SBeFIX Matching to SBEFIX for directory locations.
March 1, 2021
  • Added "Channel Guide" section.
  • Updated and clarified "EBS Book Managementsection.
  • Replaced "Publish FX Value Date on Market Data and Trades Scenario" with "Trade and Value Date Processing Example."
December 11, 2020
  • Session Access Model added
  • Improved book management processing section
  • Added Trade Session List for Trade and Value Date Processing 
  • Updated future topics
  • Minor corrections and clarifications 
December 3, 2020Initial publication.

Key Events and Dates

The full New Release and Production launch schedule is available at EBS Market on CME Globex Launch Schedule.

EBS on CME Globex Market Data Services Overview

The following is an overview of market data services to be offered for EBS Market on CME Globex.

Market

Market Data Group Option(s)

Channel ID

Description
EBS Market New York CME MDP Conflated UDP - EBS Ultra New York528
  • 5 millisecond conflated messaging
  • Up to 10-Deep Market By Price (MBP)
    • Not Credit Screened
  • Trade Summary Messages
  • UDP Multicast Connectivity 
  • Simple Binary Encoding (SBE)
  • eFix Matching security definition and security status messages are not available
CME MDP Conflated TCP - Credit Screened New York532
  • 50 millisecond conflated messaging
  • 5-Deep Market By Price (MBP)
  • Credit screened - client systems will only receive price levels where there is tradable quantity 
  • Trade Summary Messages
  • EBS Best prices - top bid and ask offers available to all client systems
  • TCP Connectivity 
  • Simple Binary Encoding (SBE)
  • eFix Matching provides security definition and security status messages only
EBS Market LondonCME MDP Conflated UDP - EBS Ultra London529
  • 5 millisecond conflated messaging
  • Up to 10-Deep Market By Price (MBP)
    • Not Credit Screened
  • Trade Summary Messages
  • UDP Multicast Connectivity 
  • Simple Binary Encoding (SBE)
  • eFix Matching security definition and security status messages are not available
CME MDP Conflated TCP - Credit Screened London533
  • 50 millisecond conflated messaging
  • 5-Deep Market By Price (MBP)
  • Trade Summary Messages
  • Credit screened - client systems will only receive price levels where there is tradeable quantity
  • EBS Best prices - top bid and ask offers available to all client systems
  • TCP Connectivity 
  • Simple Binary Encoding (SBE)
  • eFix Matching is security definition and security status only
CME MDP Conflated TCP - EBS Ultra Russian Ruble538
  • 5 millisecond conflated messaging
  • Up to 10-Deep Market By Price (MBP)
    • Not Credit Screened
  • Trade Summary Messages
  • TCP Connectivity 
  • Simple Binary Encoding (SBE)
  • eFix Matching security definition and security status messages are not available
EBS Market OFF SEF NDF LondonCME MDP Conflated UDP - EBS Ultra OFF SEF NDF530
  • 100 millisecond conflated messaging
  • 5-Deep Market By Price (MBP)
    • Not Credit Screened
  • Trade Summary Messages
  • UDP Multicast Connectivity 
  • Simple Binary Encoding (SBE)
CME MDP Conflated TCP - Credit Screened OFF SEF NDF534
  • 100 millisecond conflated messaging
  • 3-Deep Market By Price (MBP)
  • Credit screened - client systems will only receive price levels where there is tradeable quantity
  • Trade Summary Messages
  • EBS Best prices - top bid and ask offers available to all client systems
  • TCP Connectivity 
  • Simple Binary Encoding (SBE)
EBS Market ON SEF NDF LondonCME MDP Conflated UDP - EBS Ultra ON SEF NDF531
  • 100 millisecond conflated messaging
  • 5-Deep Market By Price (MBP)
    • Not Credit Screened
  • Trade Summary Messages
  • Embargo Rule to delay trades
  • UDP Multicast Connectivity 
  • Simple Binary Encoding (SBE)
CME MDP Conflated TCP - Credit Screened ON SEF NDF535
  • 100 millisecond conflated messaging
  • 3-Deep Market By Price (MBP)
  • Trade Summary Messages
  • Credit screened - client systems will only receive price levels where there is tradeable quantity
  • EBS Best prices - top bid and ask offers available to all client systems
  • Embargo Rule to delay trades
  • TCP Connectivity 
  • Simple Binary Encoding (SBE)

Getting Started with CME Globex Market Data Processing 

This section provides an overview of current CME Globex market data technology processing concepts that will be used for EBS Market on CME Globex. If you are new to CME Globex or wish to better understand how your current CME Globex system aligns with upcoming EBS functionality, CME Group recommends starting here.

CategoryCME Globex Concepts & LinksCME MDP Conflated UDP Support?CME MDP Conflated TCP Support?Notes
Message Encoding

MDP 3.0 - Simple Binary Encoding

YesYes
CME Globex MDP Messaging Concepts

MDP 3.0 - Event Based Market Data Messaging

YesYes

Additional examples of event processing for conflated feeds can be found in Conflated Market Data Processing.

Trade Summary

MDP 3.0 - Trade Summary

YesYesAdditional examples of Trade Summary messages for conflated feeds can be found in Conflated Market Data Processing.   
Book Management

MDP 3.0 - Market by Price - Multiple Depth Book

YesYesThe 37705-NoOrderIDEntries repeating group is not used in the MDIncrementalRefreshBookLongQty64
template. Implied functionality is not supported for EBS markets. 
Recovery




MDP 3.0 - Recovery

YesNo

EBS Market does not support Market by Order (MBO) books. Therefore, MBO recovery concepts can be ignored in the MDP 3.0 - Recovery document.

MDP 3.0 - Instrument Recovery

YesNo

MDP 3.0 - TCP Recovery

YesNo

MDP 3.0 - Channel Reset

YesYesSee Example 6 - Market Data Channel Reset with Conflation in the Conflated Market Data Processing section for a conflated example.
MDP 3.0 - Incremental Feed ArbitrationYesNo

Future Topics

The following topics will be added to this document in the future. Refer to the Revision History on this page for updates. This list is subject to change.

Future Topics

Market Recovery and Instrument Definition Rates for UDP Market Data Groups

Testing and Certification

Certification via Autocert+ is required for all client systems that will support EBS MDP on CME Globex.  

CME Globex Test Environments

CME Group offers the following CME Globex test environments:

The New Release test environment allows product and new functionality testing prior to release in production. Use the New Release environment to perform:

  • New product testing
  • Development testing on new functionality
  • Certification testing on new functionality

The Certification test environment mirrors current production functionality. Use this environment to:

  • Certify a client system for core functionality
  • Perform maintenance testing
  • Perform development testing for new features in production-like conditions

EBS MDP will first launch in the New Release environment. Once EBS MDP functionality is launched in production, EBS MDP will be launched in the Certification environment.

MDP Dissemination 

The CME Group Market Data Platform (MDP) disseminates bid, ask and trade data for CME Group markets and also provides recovery and supporting services for market data processing.

Market Data Groups

Market data is organized by Market Data Group, which is a configuration of MDP channels providing all market data required to support markets for a given product or set of products. EBS on CME Globex will have one of the following Market Data Groups:

CME MDP Conflated User Datagram Protocol (UDP)

The CME MDP Conflated Multicast UDP market data group supports conflated UDP feed processing over UDP multicast in Simple Binary Encoding (SBE).

conflation MDP UDP EBS

CME MDP Conflated Transmission Control Protocol (TCP)

CME MDP Conflated TCP market data group supports 50-millisecond conflated over TCP unicast in Simple Binary Encoding (SBE). Each Conflated TCP channel market data group has separate I/P and ports, therefore session activity will only apply to their respective channels.

CME MDP Conflated II

CME MDP Component Overview

This section provides an overview of MDP components. 

UDP Incremental Feed

Feed A and Feed B disseminate UDP CME Group incremental market data using encoded packets containing the following FIX market data message types:

  • Security Definition (tag 35-MsgType=d)
  • Market Data Security Status (tag 35-MsgType=f)
  • Market Data Incremental Refresh (tag 35-MsgType=X)

All packets are sent through both UDP Feed A and UDP Feed B applicable Market Data Groups. This redundancy minimizes the chance of message loss due to UDP. 

UDP Feed A and UDP Feed B should be used for arbitration.

UDP Market Recovery Feeds

Market Recovery is a UDP feed used to disseminate CME Group market data snapshots for all books having activity since the beginning of the week. Market Recovery Feed B functions as a backup in the event that Feed A becomes inoperative. The following new Market Recovery Feeds are supported for EBS on CME Globex:

  • MBP Market Recovery - for market data groups that support Market By Price (MBP)

Each packet on these feeds can contain more than one Snapshot message; each message represents a market state snapshot of a given instrument. Snapshots are replayed at a constant flow of configurable packets per second.

Expired instruments will be removed from the Market Recovery feed after a configurable timeout period.

CME Group strongly recommends that the Market Recovery feeds be used for recovery purposes only. Once client systems have retrieved recovery data, client systems should stop listening to the Market Recovery feeds.

UDP Instrument Definition Feed

Instrument Definition (UDP) Feeds replay CME Group instrument definitions for late joiners and mid-week recovery.

Each packet on this feed can contain more than one Security Definition (35=d) message, with each message representing the properties of a given instrument. Instrument definitions are replayed at a constant, configurable rate (in packets per second).  

Expired instruments are removed from the Instrument Definition feeds after a configurable time period. Instrument Definition (UDP) Feed B functions as a backup in the event that Feed A becomes inoperative.

TCP Message Recovery

The TCP historical replay component allows client systems to request a replay a set of packets already published on the UDP Incremental Market Data Channel. The request identifies the start and end packet sequence numbers to be replayed. The request uses the Market Data - Request (tag 35-MsgType=V) message.

This type of request is sent through a new TCP connection established by the client. The responses are sent by CME Group through this same connection and the connection is then closed by CME Group once the resend is complete. Replay is limited to a maximum of 2000 packets. Data from within the last 24 hours can be requested.

TCP message recovery is only recommended for small scale recovery. 

TCP MDP Gateway

The TCP MDP Gateway disseminates CME Group market data using TCP encoded packets.

UDP MDP - System Startup

This section provides an overview of the startup procedure on CME Globex for all UDP MDP feeds, including the CME MDP Conflated UDP and CME MDP Conflated TCP market data groups.

Startup Prior to Open

For a startup prior to the weekly market open, all EBS Market market data including instrument definitions, price limits and banding will be disseminated through the Incremental UDP Feed A and Feed B. Book updates include bid/ask/trade. 

For startup prior to open, follow the process below to ensure that all necessary market data is received:

  1. Download the configuration files and schema files from the ftp site. Refer to the FTP and SFTP Site Information section for more information.
  2. Listen to the Incremental feed for incremental market data and start normal processing.
Market Data Security Definition (tag 35-MsgType=d) messages disseminated during the Sunday startup period will include the value for tag 980-SecurityUpdateAction=A (Add). The “Add” value will be present on all Security Definition messages whether or not they were present during the previous week’s trading session.

Late Joiner Startup

For a late joiner startup, follow the process below to ensure that all necessary market data is received:

  1. Download the configuration files and schema files from the ftp site. Refer to the FTP and SFTP Site Information for more additional details.
  2. Listen to the Instrument Definition feed. Refer to MDP 3.0 - Instrument Recovery for more information.
  3. Listen to the Incremental feed for incremental market data. Begin the natural refresh process and begin queuing messages.

    The incremental market data may complete a natural refresh (liquid instruments only) that would construct the current, correct state of a book. Refer to MDP 3.0 - Market by Price - Book Recovery Methods for Concurrent Processing for more information
  4. Listen to the Market Recovery feed for the latest Snapshot (35=W) messages. 

    Use the latest Snapshot (35=W) message to verify that the book was correctly created via natural refresh and to retrieve the latest statistics. When the latest snapshots are received, the value for tag 369-LastMsgSeqNumProcessed in the Market Recovery for UDP snapshot (35=W) message matches the latest packet sequence number from the Incremental feed.

    If the book for an instrument was not completely constructed using natural refresh, then apply the Snapshot (35=W) message. Discard queued packets from the Incremental feed until the packet sequence number has the same value as tag 369-LastMsgSeqNumProcessed in the Snapshot (35=W) message. The discarded packets contain information that was already included in the Snapshot (35=W) message.

    Information for instruments included for the first time in the latest Incremental feed packet (with a packet sequence number equal to tag 369-LastMsgSeqNumProcessed in the Snapshot (35=W) message) may not be in the latest Snapshot (35=W) message. Apply the latest Incremental feed packet to obtain this information.

  5. Stop listening to the Market Recovery and Instrument Definition feeds.
  6. Start normal processing.

Heartbeats

At Sunday startup, CME Globex sends Heartbeat (tag 35-MsgType=0) messages at a predefined 30-second interval on the UDP Market Recovery and Instrument Definition feeds until the beginning of recovery data transmission. Once the UDP Market Recovery and Instrument Definition feeds start sending recovery data, CME Globex no longer sends Heartbeat messages.

CME MDP Conflated TCP - System Startup

This section provides an overview of the startup procedure on CME Globex for the CME MDP TCP feed.

Early and Late Joiner Startup

For a startup prior to the weekly market open and for a late joiner startup, to obtain all entitled data and subsequent updates, it is recommended clients send the following three requests in order with the request type equal to Snapshot and Updates (tag 263-SubscriptionReqType=1):

  1. Security List Request Message (35-MsgType=x)
  2. Security Status Request Message (35-MsgType=g)
  3. Market Data Request Message (35-MsgType=V)

For more information regarding request messages see Conflated MDP TCP - Request Messages.

Market Data Support Services

Market data services provide the external data required to process CME Group market data.

EBS MDP Services II


Support Services 

There are five MDP services available for EBS Market on CME Globex: Core Globex SBE Schema, Global TCP Recovery SBE Schema for UDP, TCP Session Management SBE Schema, Market Data Configuration for UDP MDP and CME Reference Data API. An FTP / SFTP site is used to store the schema files and configuration files for all environments.

Service

Description

Core Globex SBE Schema 

MDP is a template-based SBE protocol wherein a given message is interpreted by means of its corresponding template. Each message contains a unique Schema ID that references the template to use to interpret the message. The core CME Globex SBE schema is used across all market data groups.

The current CME Globex schema will be re-branded "Core Globex SBE Schema" to differentiate it from the new schema offerings outlined below.

Global TCP Recovery SBE Schema for UDP

A Global TCP Recovery SBE Schema for UDP is an SBE schema dissemination service that provides a method for client systems to process TCP Recovery for UDP system administration messages for UDP market data groups.

TCP Session Management SBE Schema

An SBE schema for client systems to receive CME Group session management templates for the CME MDP Conflated TCP market data group.  

UDP Market Data Configuration

The Market Data Configuration Service allows clients systems to receive the list of all market data channel configurations (multicast IP and product groups) for UDP market data groups. Although Multicast IPs will not change mid-week, additional products will be added throughout the week. Therefore, CME Group recommends client systems process this file daily.

CME Reference Data API 

Additional product and instrument referential data can be obtained via CME Reference Data API. CME Globex tag 48-SecurityID maps to the Reference Data API instrument field globexSecurityId.

FTP and SFTP Site Information

CME Group  provides an FTP (cmegroup.com/ftp) and SFTP (sftpng.cmegroup.com) site to disseminate MDP SBE schemas and market data configuration information. This FTP/SFTP site contains the Schema and Configuration files for all events.  CME Group recommends clients use SFTP over FTP to access configuration files.

Information applies as follows in the table:

  • Environment - specific environment (i.e., Certification, New Release, Production)
  • Service - Core Globex SBE Schema, Global TCP Recovery SBE Schema for UDP, TCP Session Management SBE Schema, UDP Market Data Configuration
  • FTP/SFTP Site - address of the site
  • Directory Location - identifies directory
  • Client System Update Schedule - client systems should download updates according to schedule specified
EnvironmentServiceFTP/SFTP SiteSFTP User Name

SFTP Password

Directory LocationClient System Update Schedule

Certification

Core Globex SBE Schema 

cmegroup.com/ftp or sftpng.cmegroup.com

cmeconfig










G3t(0nnect3d











/SBEFIX/Cert/Templates

Sunday prior to market open

Global TCP Recovery SBE Schema for UDP/SBEFIX/Cert/GlobalTCPRecovery/Templates/Sunday prior to market open
TCP Session Management SBE Schema/SBEFIX/Cert/SessionManagement/Templates/Sunday prior to market open

CME MDP Conflated UDP - EBS Ultra New York

/SBEFIX/Cert/Configuration/UltraNY/

daily

CME MDP Conflated UDP - EBS Ultra London/SBEFIX/Cert/Configuration/UltraLondon/daily
CME MDP Conflated UDP - EBS Ultra OFF SEF NDF/SBEFIX/Cert/Configuration/UltraOff/daily
CME MDP Conflated UDP - EBS Ultra ON SEF NDF/SBEFIX/Cert/Configuration/UltraOn/daily

Certification Autocert+

Core Globex SBE Schema 

/SBEFIX/CertAutoCertPlus/Templates

Sunday prior to market open

Global TCP Recovery SBE Schema for UDP/SBEFIX/CertAutoCertPlus/GlobalTCPRecovery/Templates/Sunday prior to market open

TCP Session Management SBE Schema

/SBEFIX/CertAutoCertPlus/SessionManagement/Templates/

daily

CME MDP Conflated UDP - EBS Ultra New York

/SBEFIX/CertAutoCertPlus/Configuration/UltraNY/daily
CME MDP Conflated UDP - EBS Ultra London/SBEFIX/CertAutoCertPlus/Configuration/UltraLondon/daily
CME MDP Conflated UDP - EBS Ultra OFF SEF NDF/SBEFIX/CertAutoCertPlus/Configuration/UltraOff/daily
CME MDP Conflated UDP - EBS Ultra ON SEF NDF/SBEFIX/CertAutoCertPlus/Configuration/UltraOn/Sunday prior to market open

New Release

Core Globex SBE Schema 

/SBEFIX/NRCert/Templates

Sunday prior to market open

Global TCP Recovery SBE Schema for UDP/SBEFIX/NRCert/GlobalTCPRecovery/Templates/Sunday prior to market open
TCP Session Management SBE Schema/SBEFIX/NRCert/SessionManagement/Templates/Sunday prior to market open

CME MDP Conflated UDP - EBS Ultra New York

/SBEFIX/NRCert/Configuration/UltraNY/

daily

CME MDP Conflated UDP - EBS Ultra London/SBEFIX/NRCert/Configuration/UltraLondon/daily
CME MDP Conflated UDP - EBS Ultra OFF SEF NDF/SBEFIX/NRCert/Configuration/UltraOff/daily
CME MDP Conflated UDP - EBS Ultra ON SEF NDF/SBEFIX/NRCert/Configuration/UltraOn/daily

New Release Autocert+

Core Globex SBE Schema 

/SBEFIX/NRAutoCertPlus/Templates

Sunday prior to market open

Global TCP Recovery SBE Schema for UDP/SBEFIX/NRAutoCertPlus/GlobalTCPRecovery/Templates/Sunday prior to market open
TCP Session Management SBE Schema/SBEFIX/NRAutoCertPlus/SessionManagement/Templates/Sunday prior to market open

CME MDP Conflated UDP - EBS Ultra New York

/SBEFIX/NRAutoCertPlus/Configuration/UltraNY/

daily

CME MDP Conflated UDP - EBS Ultra London/SBEFIX/NRAutoCertPlus/Configuration/UltraLondon/daily
CME MDP Conflated UDP - EBS Ultra OFF SEF NDF/SBEFIX/NRAutoCertPlus/Configuration/UltraOff/daily
CME MDP Conflated UDP - EBS Ultra ON SEF NDF/SBEFIX/NRAutoCertPlus/Configuration/UltraOn/daily

Production

Core Globex SBE Schema 

/SBEFIX/Production/Templates

Sunday prior to market open

Global TCP Recovery SBE Schema for UDP/SBEFIX/Production/GlobalTCPRecovery/Templates/Sunday prior to market open
TCP Session Management SBE Schema/SBEFIX/Production/SessionManagement/Templates/Sunday prior to market open

CME MDP Conflated UDP - EBS Ultra New York

/SBEFIX/Production/Configuration/UltraNY/

daily

CME MDP Conflated UDP - EBS Ultra London/SBEFIX/Production/Configuration/UltraLondon/daily
CME MDP Conflated UDP - EBS Ultra OFF SEF NDF/SBEFIX/Production/Configuration/UltraOff/daily
CME MDP Conflated UDP - EBS Ultra ON SEF NDF/SBEFIX/Production/Configuration/UltraOn/daily

Channel Guide

The following is an overview of market data channel to be offered for EBS Market on CME Globex.

Market

Market Data Group Option(s)

Channel ID

Market Segment ID

(tag 1300-MarketSegmentID)

EBS Market New York CME MDP Conflated UDP - EBS Ultra New York52836
CME MDP Conflated TCP - Credit Screened New York53236
EBS Market LondonCME MDP Conflated UDP - EBS Ultra London52938
CME MDP Conflated TCP - Credit Screened London53338
CME MDP Conflated TCP - EBS Ultra Russian Ruble53838
EBS Market OFF SEF NDF LondonCME MDP Conflated UDP - EBS Ultra OFF SEF NDF53038
CME MDP Conflated TCP - Credit Screened OFF SEF NDF53438
EBS Market ON SEF NDF LondonCME MDP Conflated UDP - EBS Ultra ON SEF NDF53138
CME MDP Conflated TCP - Credit Screened ON SEF NDF53538

Simple Binary Encoding Schema Overview

The following section outlines key concepts for MDP 3.0 - Simple Binary Encoding schema processing. For tag-level messaging details see the CME Globex EBS Market - Market Data Message Specification.  

Core CME Globex SBE Schema Overview

With the launch of EBS on CME Globex, the core Simple Binary Encoding (SBE) schema will be updated to version 12 to support new functionality. All CME Globex MDP Groups, including current CME Globex futures and options channels, will share the same schema. No existing templates in the current schema version 9 for existing markets will be decommissioned with the upcoming version 12 SBE schema launch. 

New fields on existing templates will utilize appended template extension. The new version 12 SBE schema is named templates_FixBinary_v12.xml and is currently available in the New Release templates FTP directory. The core CME Globex SBE Schema supports SBE version 1.0 release candidate 2.

The following table outlines the Core Globex SBE Schema template mapping for market data groups:  

Market Data GroupChannel TypeCurrent Supported Templates

CME MDP Conflated UDP



Incremental UDP
  • ChannelReset4
  • AdminHeartbeat12
  • MDInstrumentDefinitionFX63
  • SecurityStatus30
  • MDIncrementalRefreshBookLongQty64
  • MDIncrementalRefreshTradeSummaryLongQty65
  • MDIncrementalRefreshLimitsBanding50
MDP Market Recovery UDP
  • AdminHeartbeat12
  • SnapshotFullRefreshLongQty69
Instrument Replay UDP
  • AdminHeartbeat12
  • MDInstrumentDefinitionFX63
TCP Recovery for UDP
  • ChannelReset4
  • AdminHeartbeat12
  • MDInstrumentDefinitionFX63
  • SecurityStatus30
  • MDIncrementalRefreshBookLongQty64
  • MDIncrementalRefreshTradeSummaryLongQty65
  • MDIncrementalRefreshLimitsBanding50
  • AdminLogin408
  • AdminLogout409
  • AdminHeartbeat410
CME MDP Conflated TCP
  • ChannelReset4
  • AdminHeartbeat12
  • MDInstrumentDefinitionFX63
  • SecurityStatus30
  • MDIncrementalRefreshBookLongQty64
  • MDIncrementalRefreshTradeSummaryLongQty65
  • MDIncrementalRefreshLimitsBanding50
  • SnapshotFullRefreshTCPLongQty68

TCP Session Management SBE Schema Overview

The TCP Session Management SBE Schema will be exclusively used for the MDP TCP Gateway market data group. The TCP Session Management Schema is SBE release version 1.0 candidate 4, however the schema is compatible with SBE release version 1.0 candidate 2 systems. The new SBE schema is named mdpsessionmgmt.xml and is currently available in the New Release templates FTP directory

Global TCP Recovery SBE Schema for UDP Overview

EBS on CME Globex will utilize a new separate SBE schema dedicated for TCP recovery for UDP systems. Global TCP Recovery SBE Schema supports SBE release version 1.0 candidate 2At a later date, additional CME Group SBE channels will support the global TCP recovery schema. The new SBE schema is named tcprecovery.xml and is currently available in the Global TCP templates directory.

EBS Book Management

EBS book management provides client systems up to 10 Market by Price (MBP) book price levels. MBP disseminates an aggregate book with summarized order quantities and order counts at a given price level for an instrument. Maximum book depth for an instrument is indicated by tag 264-MarketDepth in the Security Definition (tag 35-MsgType=d) message. For more information regarding MBP book management messages see Market by Price (MBP). Additionally, the EBS Conflated TCP Market Data Groups provides Market Best, which provides the current EBS top of book price and quantity for a given instrument regardless of credit screened consideration.

Credit Screened Market Data Book Management Processing

EBS Market on CME Globex supports credit screened market data. Credit screened market data provides client systems price levels where there is applicable credit. The CME Globex book quantity (270-MDEntryPx) provided in credit screened market data may be a higher value than the tradeable quantity available for firms. Consequently, client systems may not be able to fill all order quantity available in the book updates. Credited screened market data books apply to the following market data groups:

Market Data Group

Channel ID

CME MDP Conflated TCP - Credit Screened New York532
CME MDP Conflated TCP - Credit Screened London533
CME MDP Conflated TCP - Credit Screened OFF SEF NDF534
CME MDP Conflated TCP - Credit Screened ON SEF NDF535

Market Best

The EBS Best provides the current EBS top of book price and quantity for a given instrument regardless of credit screened considerations. EBS Market market data provides top-of-book MBP messaging regardless of bilateral credit for conflated TCP market data groups. Market best is sent before MBP books within event. CME Group maintains the bid and ask top-of-book view with the following data block:

  • MarketBestOffer - (tag 269-MDEntryType=w)

  • MarketBestBid - (tag 269-MDEntryType=x)

EBS Credit Screened Book Example with Market Best

The following section includes a bilateral credit screened book management example with market best for a Conflated TCP Market Data Group. Bilateral product trading relationships are managed internally by CME Group across eligible firms and eligible products.

The following table shows an example of credit across firms:


Firm A

Firm B

Firm C

Firm DFirm E
Firm Acredit availablecredit availablecredit unavailablecredit availablecredit unavailable
Firm Bcredit availablecredit availablecredit availablecredit availablecredit available
Firm Ccredit availablecredit availablecredit availablecredit availablecredit available
Firm Dcredit availablecredit availablecredit unavailablecredit availablecredit available


Additionally, assume the following sell side book internally on the CME Globex engine:

Priority

SELL Quantity

SELL Book Price

Firm

13001.90E

2

2001.90C
3

100

1.91

B

6

300

1.92

D
7

500

1.92

C


Resulting Sell Side Books for Firm A

The following books are generated for firm A. The MBP book filters orders where credit is unavailable. Market best is the top price regardless of credit.

MBP Book

MBP Book Priority 

Total SELL Quantity (271-MDEntrySize)

SELL Book Price (270-MDEntryPx)

11001.91
23001.92


Market Best

Book Priority

Total SELL Quantity (270-MDEntryPx)

SELL Book Price (271-MDEntrySize)

Number of Orders (346-NumberofOrders)
15001.902

Book Management Tag Usage Summary

This section provides a tag processing overview for the book processing message for EBS Market on CME Globex for credit screened MDP, credit screened Market Best and unscreened MBP. The Market Data Incremental Refresh (tag 35-MsgType=X) below utilizes template MDIncrementalRefreshBookLongQty64.

Tag

Field Name

Unscreened - MBP

Credit Screened - Tradeable MBP Book


Credit Screened - Market Best

Description

270MDEntryPxPrice

Price where there is credit

PriceMarket Data entry price
271MDEntrySizeTotal Qty

Tradeable quantity with firms with credit

Total QtyAggregate booked qty at price level, notional
48SecurityIDSecurityIDSecurityIDSecurityIDSecurityID
83RptSeq0 (zero on conflated TCP)0 (zero on conflated TCP )0 (zero on conflated TCP)Market Data entry sequence number per instrument update
346NumberOfOrders

Total number of orders

null

null

In Book entry - aggregate number of orders at given price level
1023MDPriceLevel1 to many

1 to many

always 1

Aggregate book level

279MDUpdateAction

0 - add

1- update

2- delete

0 - add

1- update

2- delete

5 - overlayMarket Data update action
269MDEntryType

0 - bid

1 - offer

0 - bid

1 - offer

x - Market Best Bid

w - Market Best Offer

Market Data entry type
Repeating Group
37705NoOrderIDEntries0000


Market and Instrument States

The following Security Status messages (tag 35-MsgType=f) via SBE template SecurityStatus30 will be supported for EBS on CME Globex. CME Globex security messages can send updates for all instruments within a group via tag 1151-SecurityGroup or for a single instrument via 48-SecurityID.

Group States

Group StateDescription
OpenStart of continuous trading phase. Order matching begins.

Trade Date Roll (while Open)

Event that moves Trade Date for the group.

Statistics are being reset.

PauseInterruption of continuous trading and the period during which only order cancellation is allowed and order matching is not allowed.
Close Not-FinalNot final close for the date. This state allows a mid-session close with the expectation of another open.
Close-FinalFinal close for the session. GFS orders are eliminated.

Group Security Status Message (35=f) Tag Usage

The following table outlines tag usage for a group level (tag 1151-SecurityGroup) security status update. 

TagOpen

Trade Date Roll

(while Open)

PauseClose Not-FinalClose-Final

60-TransactTime

X

X

X

X

X

75-TradeDate

X

X

X

X

X

1151-SecurityGroup

X

X

X

X

X

6937-Asset

-

-

-

-

-

48-SecurityID

-

-

-

-

-

326-SecurityTradingStatus

17 = Ready to trade

17 = Ready to trade

2 = Trading halt

18 = Not available for trading

4 = Close

327-HaltReason

0 (schedule)

1 (GCC)

7 = Trade Date Roll

0 (schedule)

1 (GCC)

0 (schedule)

1 (GCC)

0 (schedule)

1 (GCC)

1174-SecurityTradingEvent

0 (no event)

4 (reset stats)


4 (reset stats)

0 (no event)


0 (no event)

0 (no event)


Instrument States

Instrument StateDescription
Open

Instrument returns to group Open state after being Reserved, Forbidden or Paused.

Instrument Open status is also sent at the time of pre-listed Instrument activation mid-week.

PauseInterruption of continuous trading. Only order cancellation is allowed. Order modification and matching are not allowed.
Close

Order matching is not allowed.

Incoming orders are rejected along with cancel requests.

Instrument Security Status Message (35=f) Tag Usage

The following table outlines tag usage for an instrument level (tag 48-SecurityID) security status update.  

Tag

Open

Pause

Close (Forbidden)

60-TransactTime

X

X

X

75-TradeDate

X

X

X

1151-SecurityGroup---
6937-Asset---

48-SecurityID

X

X

X

326-SecurityTradingStatus

17 (Open)

2 (Trading Halt)

18 (Not Available for Trading)

327-HaltReason

1 (Surveillance Intervention)

2 (Market event)

3 (Activation)



1 (Surveillance Intervention)

1 (Surveillance Intervention)

4 (expiration)

1174-SecurityTradingEvent

0 (No Event)

0 (No Event)

0 (No Event)

Trade Summary Message

This section provides a tag processing overview for the Trade Summary message for EBS Market on CME Globex.

Tag

FIX Name

CME MDP Conflated UDP

CME MDP Conflated TCP

Description
60TransactTimeXXStart of event processing time in number of nanoseconds since Unix epoch
5799MatchEventIndicatorXXBitmap field of eight Boolean type indicators reflecting the end of updates for a given Globex event
Repeating Group 1
268NoMDEntriesXXNumber of Trade Summary entries
270MDEntryPxXXTrade price
271MDEntrySizeSet to 0Set to 0Value always set to zero.
48SecurityIDXXSecurity ID as defined by CME
83RptSeqXXSequence number per instrument update
346NumberOfOrdersSet to 0Set to 0Value always set to zero.
5797AggressorSide

X

X

Indicates which side is the aggressor or if there is no aggressor

1- bid aggressor

2 - ask aggressor

279MDUpdateAction

X

X

Market Data update action

0 - new trade

1- modified trade

2 - deleted trade

269MDEntryType22Market Data entry type
37711MDTradeEntryID

X

XMarket Data Trade entry ID
Repeating Group 2
37705NoOrderIDEntriesSet to 0Set to 0Number of OrderID entries. This repeating group is not used for EBS Market and the value is always set to zero.  
37OrderID--Unique order identifier as assigned by the exchange
32LastQty--Quantity bought or sold on this last fill

Conflated Market Data Processing

This section outlines functionality for the CME MDP Conflated UDP and CME MDP Conflated TCP market data groups for EBS Market. Conflated market data combines multiple updates within an interval into a single event. Supported conflated market data messages will be configured with a conflation interval value which is set at the market segment level (tag 1300-MarketSegmentID in the Security Definition tag 35-MsgType=d) message. Messages that are not conflated will subsequently flush any queued conflated messages. The interval is reset once MDP messages are published. 

The following table outlines which messages are subject to market data conflation for EBS Market:

Message

EBS Conflated?

Trade Summary

Yes

Market by price book updates (MBP)

Yes

Security Definitions

No

Security Status

No

Limits and Banding

No

Channel Reset

No

The trade summary will use the real-time tag 60-TransactTime; all other conflated messages will use the last event tag 60-TransactTime. Non-conflated messages will use a real-time tag 60-TransactTime. Order entry on CME Globex is not subject to conflation.

Unless otherwise noted, the following examples assume an empty book and 50 ms conflation interval. Additionally, for the examples below, message performance is for illustrative purposes only. Actual production message performance on CME Globex will differ.  

Example 1 - Multiple Updates for Single Instrument

The following example illustrates conflation for a single instrument with multiple updates set to a 50 millisecond conflation interval. 

ConflationEBSingleUpdateIns1

Example 2 - Multiple Updates for Multiple Instruments

The following example illustrates conflation with multiple updates and multiple instruments within a 50 millisecond conflation interval.


conflationmulti3a

Example 3 - Event Exceeds Conflation Interval

In this example, for a single instrument, a market data event exceeds the 50 millisecond conflation interval. When the conflation interval is exceeded due to additional processing, CME MDP 3.0 does not publish messages until the event is complete.

ConflationPastInterval_1

Example 4 - No Messages within Configured Interval

In this example, there is no activity within the configured 50 millisecond interval. Therefore, MDP 3.0 resets the conflation interval to 50 and waits to publish the next market event.

NoMsgConflationInterval

Example 5 - Non-Conflated Message Flush

In this example, a non-conflated Security Status (tag 35-MsgType=f) message is triggered, which causes the conflated data to be sent earlier.

  conflationPassThru

Example 6 - Market Data Channel Reset with Conflation

Conflated EBS Market market data feeds support Market Data Channel Reset (tag 269-MDEntryType=J). Market Data MDP 3.0 - Channel Reset provides a process for synchronizing order books and trade session statistics in the unlikely event of a CME Group component failure. In this scenario, order books on the channel may be corrupted. During a conflation channel reset, Market by Price (MBP) messages will be sent down the incremental feed real-time.

The following diagram shows an example of a Market Data Channel Reset and Recovery for a channel with 2 instruments.

conflationChannelReset_1

Trade and Value Date Processing 

EBS Market provides the Trade Session List for trade and value date processing. The Trading Session group (tag 386-NoTradingSessions) in the Security Definition (35=d) on Sunday will list all valid trade dates (75-TradeDate) and corresponding value dates (64-SettlDate) for that calendar week. The Security Definition trading session list supports mid-week updates to allow for unscheduled changes or updates to the list and republish the security definition.  Mid-week Security Definition updates are denoted via tag 980-SecurityUpdateAction=M. The trade date roll occurs when the the Security Status message (35=f) denotes 327-HaltReason=7. Client systems should reset statistics when the trade date roll security status message is received. For eFix instruments, the instrument is not available for trading if the the trade date is unavailable.

Group Security Status Message (35=f) Tag Usage

The following table outlines tag usage for a group level (tag 1151-SecurityGroup) security status update for a trade date roll. 

Tag

Trade Date Roll

(while Open)

60-TransactTime

X

75-TradeDate

X

1151-SecurityGroup

X

6937-Asset

-

48-SecurityID

-

326-SecurityTradingStatus

17= Ready to trade

327-HaltReason

7 = Trade Date Roll

1174-SecurityTradingEvent

4 (reset stats)

MDP FIX Syntax for Security Definition (35=d) Trade Session List Processing

The following trade list processing values map to the MDInstrumentDefinitionFX63 template.

TagFIX NameTypeDescription
Repeating Group
386NoTradingSessionsNuminGroupNumber of scheduled Trading Dates
75TradeDateLocalMktDateTrade Date
64SettlDateLocalMktDateSettle (Value) Date corresponding to Trade Date
541MaturityDateLocalMktDateFor Spot instruments will not contain the value. For NDFs, the fixing (valuation) date of the NDF. For Fixed Date NDFs Value Date and Maturity Date remain constant for all Trade Dates
455SecurityAltIDString12ISIN value as provided by ANNA, Association of National Numbering Agencies. This field is populated for MTF-Regulated NDFs and is unique for each Settle Date
456SecurityAltIDSourceSecurityAltIDSourceISINIdentifies class or source of the SecurityAltID (455) value

Trade and Value Date Processing Example

In this example, there is a Trading Session List update Mid-Week for the current trade date list. On Sunday, May 31, 2020, a trading session list has been published for EUR/USD in a Security Definition (35=d) message with the following information:

TagFIX NameValueNotes
Repeating Group
386NoTradingSessions5
75TradeDateJune 01 2020 (Monday)
64SettlDate (Value Date)June 03 2020 (Wednesday)
75TradeDateJune 02 2020 (Tuesday)
64SettlDate (Value Date)

June 04 2020 (Thursday)


75TradeDateJune 03 2020 (Wednesday)
64SettlDate (Value Date)June 05 2020 (Friday)
75TradeDateJune 04 2020 (Thursday)
64SettlDate (Value Date)June 08 2020 (Monday)
75TradeDateJune 05 2020 (Friday)
64SettlDate (Value Date)June 09 2020 (Tuesday)


Next, on Monday, June 01, 2020 at 1PM CST a holiday is declared for a EUR/USD on Wednesday (June 03. 2020). Consequently, the EUR/USD trade session list is republished (tag 980-SecurityUpdateAction=M) with the following information:

TagFIX NameValueNotes
Repeating Group
386NoTradingSessions5
75TradeDateJune 01 2020 (Monday)
64SettlDate (Value Date)June 04 2020 (Thursday)Updated from Wednesday to Thursday.
75TradeDateJune 02 2020 (Tuesday)
64SettlDate (Value Date)

June 05 2020 (Friday)

Updated from Thursday to Friday.
75TradeDateJune 03 2020 (Wednesday)
64SettlDate (Value Date)June 05 2020 (Friday)
75TradeDateJune 04 2020 (Thursday)
64SettlDate (Value Date)June 08 2020 (Monday)
75TradeDateJune 05 2020 (Friday)
64SettlDate (Value Date)June 09 2020 (Tuesday)


Consequently, after the Security Definition (35=d) message value date update, the following is true:

  • For Trade Date Monday, June 1:
    • All trades occurring before 1PM have a Value Date of Wednesday, June 3.

    • All trades occurring at/after 1PM have a Value Date of Thursday, June 4.

  • For Trade Date Tuesday, June 2, all trades have a Value Date of Friday, June 5.

  • For Trade Date Wednesday, June 3, all trades have a Value Date of Friday, June 5.

Trade Embargo Processing for ON-SEF NDF Instruments

On-SEF NDF instruments implement an embargo rule for trade messaging (tag MDEntryType-269=2). The embargo sends trade information during a conflation interval at a minimum of 400 milliseconds (subject to change) after the trade occurs. Trade cancels and trade adjustments are also subject to the embargo delay. Trades subject to the embargo rule are not flushed for non-conflated messages. On-SEF instruments can be determined via the EBS Reference Data API Migration product attribute onSef. For embargo trades, tag 5799-MatchEventIndicator values keep the pre-embargo value. 

The trade embargo is currently set to 400 milliseconds in the New Release environment. The value may be reduced in the future. Any trade embargo timing update will be communicated via the EBS integration notice.

Example 1 - Trade Update for Instrument

In the example below, a trade and book update occur for an On-SEF NDF instrument. The trade message is sent after the 4th conflation interval due to the trade embargo rule.

EBS_conflation_trade_embargo

Example 2 - Multiple Updates for an Instrument

In the example below, a trade and book update occur for an On-SEF NDF instrument. A second book update occurs and is sent before the initial trade update. The trade message is sent after the 4th conflation interval due to the trade embargo rule.

EBS_conflation_trade_embargo_multi

Example 3 - Non-Conflated Message Flush

In this example, a non-conflated pass through Security Status (tag 35-MsgType=f) message is sent. Consequently, all conflated messages are flushed except the trade update due to the embargo rule.

EBS_conflation_TE_passthru

Conflated TCP Market Data Group 

CME Group will offer a CME MDP Conflated TCP market data group for EBS Market.

The Conflated TCP Market Data Group schema will utilize appended template extension. With template extension, a template is extended as an appended extension, client systems can choose to continue processing the prior template version or process the new data with the new schema version.

Packet Structure

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

ConflatedTCPPacketStructure

 

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

Packet Header

(14 bytes)

Message Header

(10 bytes)

SBE Message

(Variable Length)

Encoding Type: 2 bytes

  • CME SBE Version 1.0 Little-endian: 0xCAFE
  • Identifier of the encoding used in the message payload
  • Only available for the CME MDP Conflated TCP market data group.  

Message Size: 2 bytes

  • Overall message size including headers to support framing

Customer to CME Globex Messages

Examples:

  • Negotiation Message
  • Termination Message
  • Market Data Request Message

Sequence: 4 bytes

  • Packet sequence number.
  • A unique sequence number given to each packet sent.
  • Each channel will have its own separate set of sequence numbers that will increment sequentially with each packet and reset weekly.

Block Length: 2 bytes

  • The total space reserved for the root level of the message

CME Globex to Customer Messages

Examples:

  • Negotiation Response
  • Negotiation Reject
  • Incremental Refresh Book Update (35=X)
  • Security Definition (35=d)

Sending Time: 8 bytes

  • UTC Time of message transmission by the Gateway.
  • UTC Timestamps are sent in number of nanoseconds since Unix epoch synced to a master clock to microsecond accuracy.

TemplateID: 2 bytes

  • Message SBE Template Identifier


SchemaID: 2 bytes

  • Identifier of the SBE Message Schema that contains the Template


Version: 2 bytes

  • Version of the SBE Message Schema in which the message is defined


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 does not support session layer re-transmit request functionality.   

TCP MDP Session Messages

TCP MDP session messages are summarized below. 

StageMessage NameTemplate NameFrom | ToPurpose
InitializationNegotiateNegotiate200Client System to CME GlobexInitiates connection
Negotiation ResponseNegotiationResponse202 CME Globex to Client SystemAccepts connection
Negotiation RejectNegotiationReject201 CME Globex to Client SystemRejects connection
UnbindingTerminateTerminate203Client System to CME GlobexDisconnect connection
CME Globex to Client System

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 Group 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 following fields are required in the Negotiate message:

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

Create the Signature using MAC algorithm HMAC SHA256. It should be encoded as a byte array.

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 client system should send a Negotiate message to the exchange and await acknowledgement.

  • When the Negotiate message sent by the  is accepted by CME, then CME will return a Negotiation Response.
  • When the Negotiate message sent by the 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 the Negotiation can be sent again or an 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 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. If a client system does not send a heartbeat after two heartbeat intervals, it 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 TCP Session Access Model

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

CME MDP Conflated TCP

Example Session IDCredit Screens New York (532)Credit Screened London (533)EBS Ultra Russian Ruble - Non Credit Screened (538)Credit Screened OFF SEF NDF (534)Credit Screened ON SEF NDF (535)
AB - credit screened sessionYesYesNoYesYes
YZ - non-credit screened sessionNoNoYesNoNo

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, it 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. 

Message Name

FIX Tags

Template Name

From | To

Purpose

Security List Request Message35-MsgType=xSecurityListRequest208Client System to CME GlobexAllows late joiners to recover all instruments or to recover any new / updates to instruments that may have been missed in the event of a lost connection.
Security Status Request Message35-MsgType=gSecurityStatusRequest209Client System to CME Globex

Allows joiners to recover market status messages or to recover any new / updates to market status that may have been missed in the event of a lost connection.

Market Data Request Message35-MsgType=VMarketDataRequest205Client System to CME GlobexSent by client systems to recover the current state via the Market Data Snapshot Recovery Message (35=W) and receive all subsequent message type updates for the subscribed instruments or all entitled groups

Request Acknowledgment 

35-MsgType=VRequestAck206 CME Globex to Client SystemIndicates whether a client system request was fully or partially acknowledged.

Request Reject

tag 35-MsgType=Y

RequestReject207 CME Globex to Client SystemSent to client systems as a reply to any type of request that is fully rejected.  

Client System to CME Globex Request Messages

Request messages allow Conflated TCP client systems to recover and to subscribe to instruments or all entitled data. 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 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 instrument (tag 48-SecurityID) level. The instrument repeating group (tag 146-NoRelatedSym) is the number of instruments requested.  The security repeating group (tag 37022-NoSecurityGroups) is not applicable to EBS Market and should always be set to zero. If both NoSecurityGroup and NoRelatedSym are equal to zero then the request will be for all entitled products

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 was added or an update was last sent.

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

FIX Name

Tag Value
262MDReqID679
263SubscriptionReqType1 (Snapshot and updates)
Repeating Group 1 (NoSecurityGroups=0)
Repeating Group 2 (NoRelatedSym=4)
48SecurityID30027
48SecurityID141645
48SecurityID228219
48SecurityID467123
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 instrument (tag 48-SecurityID) level. The instrument repeating group (tag 146-NoRelatedSym) is the number of instruments requested.  The security repeating group (tag 37022-NoSecurityGroups) is not applicable to EBS Market and should always be set to zero. If both NoSecurityGroup and NoRelatedSym are equal to zero then the request will be for all entitled data

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)
Tag

FIX Name

Tag Value
262MDReqID8
263SubscriptionReqType0 (Snapshot)
Repeating Group 1 (NoSecurityGroups=0)
Repeating Group 2 (NoRelatedSym=3)
48SecurityID9201
48SecurityID368213
48SecurityID577121
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 SnapshotFullRefreshTCPLongQty68.  

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 Snapshot Full Refresh (tag 35-MsgType=W) messages for instruments offered on the respective channel.  
  • Snapshot and updates (tag 263-SubscriptionReqType=1) - Provides a current list of Snapshot Full Refresh (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 instrument (tag 48-SecurityID) level. The instrument repeating group (tag 146-NoRelatedSym) is the number of instruments requested. The security repeating group (tag 37022-NoSecurityGroups) is not applicable to EBS Market and should always be set to zero. If both NoSecurityGroup and NoRelatedSym are equal to zero then the request will be for all entitled data

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.

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

FIX Name

Tag Value
262MDReqID7
263SubscriptionReqType2 (Unsubscribe)
Repeating Group 1 (NoSecurityGroups=0)
Repeating Group 2 (NoRelatedSym=0)

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):

  • FullAck (tag 37720-MDReqIDStatus=0) Requested subscription scope is fully acknowledged.  
  • PartialAck (tag 37720-MDReqIDStatus=1) Requested subscription scope is partially acknowledged. Partial Acks are due to the client system session not being entitled to the requested data for the applicable channel.

Requests can be made at the instrument (tag 48-SecurityID) level. The instrument repeating group (tag 146-NoRelatedSym) is the number of instruments requested.  The security repeating group (tag 37022-NoSecurityGroups) is not applicable to EBS Market and should always be set to zero. If both NoSecurityGroup and NoRelatedSym are equal to zero then the request will be for all entitled data

Example Request Acknowledgment (tag 35-MsgType=V) Message
Tag

FIX Name

Tag Value
262MDReqID11
263SubscriptionReqType0 (Snapshot)
37720MDReqIDStatus1 (PartialAck)
Repeating Group 1 (NoSecurityGroups=0)
Repeating Group 2 (NoRelatedSym=4)
48SecurityID9297
48SecurityID24103
48SecurityID78157
48SecurityID100250
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. 

Example Request Acknowledgment Message (tag 35-MsgType=V)

Tag

FIX Name

Tag Value

262MDReqID3
281MDReqRejReason0
58TextEntitlement not found for requested scope
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 instrument (tag 48-SecurityID) level.
  • If a client is entitled to product(s) and requests all groups (NoSecurtiyGroups=0, NoRelatedSym=0), RequestIDStatus=FullAck message will be sent.
  • If a request is made and some (but not all) of the instruments are not entitled, then the MDP gateway will reply with a partial ack (MDReqIDStatus= Partial).
  • If a client system with existing entitlements makes a request for only 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 all market data (NoSecurityGroup and NoRelatedSym are equal to zero) on an applicable channel 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 product/instruments are added mid-week, the following occurs:
    • Additional product/instruments will be available, however the session will not send the newly entitled product/instruments updates unless a request is sent.  
  • If entitlements for new product/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 product 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 Group 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

The following section provides Conflated MDP TCP messaging examples.  

Example 1 - Successful Negotiation and Client System Initiated Termination 

In this example a client system successfully logs on and logs off.

NegotiateSuccess


Example 2 - Negotiation Reject and CME Initiated Termination 

In this 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 only respond with a terminate message. In the example, the invalid values are denoted in red.

NegotiateReject


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.

Heartbeat_Success


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 Negotiation Response. Consequently, the gateway sends a Terminate message and closes the connection.

IncompleteNegotiation

Example 5 - Request Messages

The following example provides a message workflow for all 3 request types (Security List, Security Status and Market Data Request) during a TCP mid-week startup. All requests are for Snapshot & Updates (tag 263-SubscriptionReqType=1) and are fully acknowledged (tag 37720-MDReqIDStatus=0).  Subscription requests only apply to their respective channels. 

BasicSubscription


Example 6 - Message Requests with Partial Acks

The following example provides a message workflow for all 3 request types (Security List, Security Status, and Market Data Request) with invalid tag 48-SecurityID values. All requests are for Snapshot and Updates (tag 263-SubscriptionReqType=1) and are partially acknowledged (tag 37720-MDReqIDStatus=0). In the example, the invalid values are denoted in red.

EBS_mdptcp_partial

Example 7 - Mid-Week Entitlement Change

In this example, a firm's entitlements are updated mid-week. The session will not receive updates for the newly entitled group unless a request message is sent by the client system. Consequently, the client system sends a new request message to update the subscription and begins receiving data for the newly entitled instrument. In the example, the new instrument is denoted in red.

EBS Midweek Add

Example 8 - Unsubscribe Request

In this example, a client system unsubscribes from an instrument. The unsubscribed instrument is denoted in red.


This feature is supported only for customers that subscribe by a list of instruments.

Customers that subscribe without a filter should send a single unsubscribe to stop all subscriptions. Customers using instrument filter can also use Unsubscribe all.


EBS Unsub

Example 9 - Subscription Example

The following example provides a message workflow of a request subscription. Assume a session is entitled to subscribe to the following instruments:

Instrument

(Tag 48)

11111
22222
33333

In the scenario below, a client system sends a market data request for all entitled instruments (NoSecurityGroup and NoRelatedSym equal to zero). Next, the client system session unsubscribes from instrument 11111 which does not supersede the previous request for all entitled instruments. Consequently, the client system session must first unsubscribe to all instruments and then individually subscribe to instruments 22222 and 33333.

EBS Sub Overlap

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 that there are no in-flight data issues, during a recovery, CME Group recommends sending request messages in the following order with tag 263-SubscriptionReqType=1 (Snapshot and Updates):

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

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

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

UngracefulDisconnect

  • No labels