NexusFi: Find Your Edge


Home Menu

 





MDP 3.0, is CME migrating to a new data comm protocol?


Discussion in Brokers

Updated
      Top Posters
    1. looks_one Big Mike with 17 posts (34 thanks)
    2. looks_two artemiso with 6 posts (2 thanks)
    3. looks_3 LukeGeniol with 6 posts (1 thanks)
    4. looks_4 Malthus with 5 posts (18 thanks)
      Best Posters
    1. looks_one SierraChart with 13.5 thanks per post
    2. looks_two aslan with 7 thanks per post
    3. looks_3 trendwaves with 3.6 thanks per post
    4. looks_4 Big Mike with 2 thanks per post
    1. trending_up 46,135 views
    2. thumb_up 193 thanks given
    3. group 50 followers
    1. forum 86 posts
    2. attach_file 0 attachments




 
Search this Thread

MDP 3.0, is CME migrating to a new data comm protocol?

  #71 (permalink)
 
trendwaves's Avatar
 trendwaves 
Florida
Market Wizard
 
Experience: Advanced
Platform: NinjaTrader 8
Trading: ES, NQ, CL
Posts: 703 since Dec 2012
Thanks Given: 2,898
Thanks Received: 2,525


DionysusToast View Post
understood...

"It is my understanding MDP 3.0 is generating a single trade report for each individual aggressor trade that executes" - it's this specifically that I am interested in.

I haven't seen any documentation that states that this is the case. IQFeed seem to think it's collating trades by time.

So I'm wondering which documentation lead you to your understanding.

I start here ... https://www.cmegroup.com/confluence/display/EPICSANDBOX/MDP+3.0+-+Trade+Summary


Quoting 
Trade Summary Data Overview

The Market Data Incremental Refresh (35=X) message includes a Trade Summary message which indicates the quantity and optional inclusion of the anonymous, CME Globex-assigned order identifier.

Trade Summary Data Sequence

The Trade Summary data is the first type of message sent on the market data feed for a trade.

A Trade Summary message represents a distinct match comprised of all orders that traded together as the result of a single aggressing order, elected stop order, mass quote, or a market state event.

In my prior comments I used the term "trade report" to represent what MDP 3.0 is calling the "Trade Summary message". As Aslan points out, this message can be a single UDP packet or multiple packets in the case where a single agressor order exceeds the boundary of a single packet ...


Quoting 
A single Trade Summary message can be split across multiple packets if the total number of related entries cannot be fit in a single UDP packet.

So in my mind, this tells me each unique aggressor order triggers a Trade Summary message, where the message can be one or more UDP packets as needed. For my needs and desires, I can stop here and simply use the aggressor trade information and drop the details, and in so doing should match up roughly with your "reconstructed tape".

In reading the DTN thread, it sounds like DTN wants to break apart the Trade Summary message back into the details of all the filled limit orders, those 1, 2, 5, 21 ... lot fills used to offset the single initiating aggressor order. I also noticed DTN is using the term "bundled" in reference to the Trade Summary message itself. This goes directly to my initial concern, as I stated previously, I have no use for or desire to see that detail, the value in the tape, for me, is in the aggressor order itself. I suppose in an ideal world, data providers would pass through all of the information contained in the Trade Summary message, including the true aggressor order, and let platforms like Jigsaw or NinjaTrader develop proprietary solutions for traders to use and manipulate all of the information it contains. One trader might need the fine details, another like myself, wants the initiating aggressor side trade information. I don't view one as better than the other, as they are the two parts needed to accurately and fully depict both sides of the same market event. With that said, i recognize the reality that as each data provider picks a side, the other side loses information. I am just hoping at least one data provider will pick my side... I take comfort in recognizing the cheapest and easiest solution is to transmit the single initiating aggressor order and drop the details. (The DTN thread certainly confirms that).

Be Patient and Trade Smart
Visit my NexusFi Trade Journal Reply With Quote

Can you help answer these questions
from other members on NexusFi?
Exit Strategy
NinjaTrader
The space time continuum and the dynamics of a financial …
Emini and Emicro Index
Ninja Mobile Trader VPS (ninjamobiletrader.com)
Trading Reviews and Vendors
Deepmoney LLM
Elite Quantitative GenAI/LLM
Futures True Range Report
The Elite Circle
 
  #72 (permalink)
 
LukeGeniol's Avatar
 LukeGeniol 
Italy (IT) Italy
 
Experience: Advanced
Platform: ATAS, R|Trader, NT8
Broker: Rithmic
Trading: CL, Brent, GC, TF
Frequency: Daily
Duration: Minutes
Posts: 1,499 since Apr 2010
Thanks Given: 408
Thanks Received: 985

I do not know if the new transmission protocol of the CME is better or worse, but IMHO the raw tick, meant as each single trade, is the better date to have, regardless of the time's granularity. One after can always aggregating them with the appropriate tools.

Take your Pips, go out and Live.
Luke.
Reply With Quote
  #73 (permalink)
mpxtreme
New York
 
Posts: 52 since Dec 2013
Thanks Given: 2
Thanks Received: 45


1. a 500 lot trade being reported as a 500 lot trade on T&S (pre 2009 and MDP 3.0)

2. a 500 lot trade being reported as 500 1 lot trades on T&S (2009 to Oct 2015)


I know which I'd prefer ;-)

Be aware that if your are trading through NinjaTrader brokerage with Rithmic data, Rithmic are still using the current protocol.
But if you fill your NinjaTrader charts with historical data...it's being filled with CQG/Continuum data which have moved to MDP 3.0 for both live and historical data.
Therefore in this set up if you initiate a historical data download intra day...your data will change and so will your signals.

Ouch!

mpx

Reply With Quote
  #74 (permalink)
 
Zefi's Avatar
 Zefi 
Mount Martha, Victoria, Australia
 
Experience: None
Platform: Acme VP & MP, Jigsaw
Trading: FESX FGBL
Posts: 230 since Dec 2014
Thanks Given: 128
Thanks Received: 259

Will this MDP 3.0 change affect any of the print activity of the DOM or will it only be apparent on the time&sales?

Perhaps Peter from Jigsaw could kindly chime in on this one:

Just to give you a scenario.
Pre the MDP 3.0 change, A continual refreshing iceberg order is hit by a large amount of one lots that are likely to be a larger bundled trade. (The machine gun action some label it).

Now after this change will this type of action cease on CME products as the larger trade is now bundled?

How about Eurex? Any news whether they are likely to follow suit?


I wanted to chime in here that will probably be a newbie question but may shed some slight for other confused DOM traders.

Saying that I may be completely muddled on this situation!

Z

Follow me on Twitter Reply With Quote
  #75 (permalink)
 
trendwaves's Avatar
 trendwaves 
Florida
Market Wizard
 
Experience: Advanced
Platform: NinjaTrader 8
Trading: ES, NQ, CL
Posts: 703 since Dec 2012
Thanks Given: 2,898
Thanks Received: 2,525


Zefi View Post
Will this MDP 3.0 change affect any of the print activity of the DOM or will it only be apparent on the time&sales?


Pre the MDP 3.0 change, A continual refreshing iceberg order is hit by a large amount of one lots that are likely to be a larger bundled trade. (The machine gun action some label it).

Now after this change will this type of action cease on CME products as the larger trade is now bundled?

The answer to that question depends on exactly how your data provider chooses to report trades after they switch over to MDP 3.0.

Scenario 1: If your data provider, such as CQG/Continuum transmits the aggregated trade, then yes the "large amount of one lots" will no longer show up as "machine gun action" , and very well may show up as a single 600 lot trade print hitting the bid or ask.

Scenario 2: On the other hand, if your data provider, such as DTN is indicating they are considering doing, breaks apart the Trade Summary message back into all of the one lot fills from the order book then you will see no difference compared to pre-MDP 3.0. Your "machine gun action" will remain intact. But keep in mind, this 'price action' might lead you to think oh it's an iceberg being refreshed! , where it is simply just one or two large block "600 lot" market orders being filled by a large quantity of one lot limit orders in the book (as scenario 1 shows).

Looking at the CQG time and sales along side the DTN time and sales we see how the iceberg is actually a very small handful of large block market orders hitting into a price level where there are perhaps thousands of one lot orders awaiting a fill. Each 600 lot market order on the CQG side triggers hundreds of one lot 'machine gun' fills on the DTN side.

Be Patient and Trade Smart
Visit my NexusFi Trade Journal Reply With Quote
Thanked by:
  #76 (permalink)
 
Zefi's Avatar
 Zefi 
Mount Martha, Victoria, Australia
 
Experience: None
Platform: Acme VP & MP, Jigsaw
Trading: FESX FGBL
Posts: 230 since Dec 2014
Thanks Given: 128
Thanks Received: 259


trendwaves View Post
The answer to that question depends on exactly how your data provider chooses to report trades after they switch over to MDP 3.0.

Scenario 1: If your data provider, such as CQG/Continuum transmits the aggregated trade, then yes the "large amount of one lots" will no longer show up as "machine gun action" , and very well may show up as a single 600 lot trade print hitting the bid or ask.

Scenario 2: On the other hand, if your data provider, such as DTN is indicating they are considering doing, breaks apart the Trade Summary message back into all of the one lot fills from the order book then you will see no difference compared to pre-MDP 3.0. Your "machine gun action" will remain intact. But keep in mind, this 'price action' might lead you to think oh it's an iceberg being refreshed! , where it is simply just one or two large block "600 lot" market orders being filled by a large quantity of one lot limit orders in the book (as scenario 1 shows).

Looking at the CQG time and sales along side the DTN time and sales we see how the iceberg is actually a very small handful of large block market orders hitting into a price level where there are perhaps thousands of one lot orders awaiting a fill. Each 600 lot market order on the CQG side triggers hundreds of one lot 'machine gun' fills on the DTN side.

Nicely put trendwaves. Makes perfect sense now.

I see how the bundled data will had an adverse effect for DOM traders monitoring order flow. The more data that is whittled down the easier it is to engage in the process and not get caught short. I guess I'll reiterate Mike's point on how Traders essentially don't take well to change. Trading has evolved exponentially since the 90's with the rise of Island/BATS etc. We simply need to adapt to the change that is always forced upon us or face extinction!

Follow me on Twitter Reply With Quote
Thanked by:
  #77 (permalink)
 
Zefi's Avatar
 Zefi 
Mount Martha, Victoria, Australia
 
Experience: None
Platform: Acme VP & MP, Jigsaw
Trading: FESX FGBL
Posts: 230 since Dec 2014
Thanks Given: 128
Thanks Received: 259

It would be worth noting to to add to this discussion that the SEC market structure meeting on May 13th created some headway on the hotly debated topic of an uncompetitive market place of HFT's skimming price and abusing the maker-taker process. This is long overdue with all the manipulative order types that have been present since inception of Reg NMS in 2007 including Direct Edge's 'hide not slide', NASDQ's MPPO etc.

It's worth noting that NYSE's Arca seems to be leading the way where the pilot rule changes will be implemented on their Pillar platform to test the new market structure.


QUOTE
The proposed priority categories would be:
 Proposed Rule 7.36P(e)(1) would specify “Priority 1 – Market Orders,” which
provides that unexecuted Market Orders would have priority over all other sameside
orders with the same working price. This proposed priority is the same as
current Exchange priority rules under which resting Market Orders have priority
over other orders at the same price.22
Circumstances when an unexecuted Market
Order would be eligible to execute against an incoming contra-side order include
when a Market Order has exhausted all interest at the NBBO and is waiting for an
NBBO update before executing again, pursuant to Rule 7.31(a), or when a Market
Order is held unexecuted because it has reached a trading collar, pursuant to Rule
7.31(a)(3)(A). In such circumstances, the unexecuted Market Order(s) would
have priority over all other resting orders at that price.
 Proposed Rule 7.36P(e)(2) would specify “Priority 2 – Display Orders.” This
proposed priority category would replace the “Display Order Process.” As
proposed, non-marketable Limit Orders with a displayed working price would
have second priority. For an order that has a display price that differs from the

22 This priority is currently specified in Rule 7.16(f)(viii).
26
working price of the order, if the working price is not displayed, the order would
not be ranked Priority 2 at the working price.
 Proposed Rule 7.36P(e)(3) would specify “Priority 3 – Non-Display Orders.”
This priority category would be used in Pillar rules, rather than the “Working
Order Process.” As proposed, non-marketable Limit Orders for which the
working price is not displayed, including the reserve interest of Reserve Orders,
would have third priority.
 Proposed Rule 7.36P(e)(4) would specify “Priority 4 – Tracking Orders.” This
priority category would replace the “Tracking Order Process,” as discussed in
further detail below in connection with proposed Rule 7.37P. As proposed,
Tracking Orders would have fourth priority.
Proposed Rule 7.36P(f) would set forth that within each priority category, orders would
be ranked based on time priority.
 Proposed Rule 7.36P(f)(1) would provide that an order is assigned a working time
based on its original entry time, which is the time an order is first placed on the
NYSE Arca Book. This proposed process of assigning a working time to orders
is current functionality and is substantively the same as current references to the
“time of original order entry” found in several places in Rule 7.36. To provide
transparency in Exchange rules, the Exchange further proposes to include in
proposed Rule 7.36P(f) how the working time would be determined for orders
that are routed. As proposed:
27
o Proposed Rule 7.36P(f)(1)(A) would specify that an order that is fully
routed to an Away Market23 on arrival would not be assigned a working
time unless and until any unexecuted portion of the order returns to the
NYSE Arca Book. The Exchange notes that this is the current process for
assigning a working time to an order and proposes to include it in
Exchange rules to provide transparency regarding what is considered the
working time of an order that was fully routed on arrival.
o Proposed Rule 7.36P(f)(1)(B) would specify that for an order that is
partially routed to an Away Market on arrival, the portion that is not
routed would be assigned a working time. If any unexecuted portion of
the order returns to the NYSE Arca Book and joins any remaining resting
portion of the original order, the returned portion of the order would be
assigned the same working time as the resting portion of the order. If the
resting portion of the original order has already executed and any
unexecuted portion of the order returns to the NYSE Arca Book, the
returned portion of the order would be assigned a new working time. This
process for assigning a working time to partially routed orders is the same
as currently used by the Exchange. The Exchange proposes to include this
detail in Exchange rules to provide transparency regarding what is
considered the working time of an order.

23 The Exchange proposes Rule 1.1(ffP), which would define the term “Away Market.”
The proposed definition is based on the existing definition of “NOW Recipient,” which is
a term that the Exchange would not be using in Pillar. For Pillar, the proposed definition
of “Away Market” would reference the term “alternative trading system” instead of ECN.
28
 Proposed Rule 7.36P(f)(2) would provide that an order would be assigned a new
working time any time the working price of an order changes. This proposed rule
text would be based on the rule text in Rule 7.36(a)(3), without any substantive
differences. A change to the working price could be because of a User’s
instruction or because the order or modifier has a price that can change based on a
reference price, such as an MPL Order, which is priced based on the PBBO.
 Proposed Rule 7.36P(f)(3) would provide that an order would be assigned a new
working time if the size of the order increases and that an order would retain its
working time if the size of the order is decreased. This proposed rule text would
be based on rule text in the first and second sentences of Rule 7.36(a)(3), without
any substantive differences.
 Proposed Rule 7.36P(f)(4) would provide that an order retains its working time if
the order marking is changed from: (A) sell to sell short; (B) sell to sell short
exempt; (C) sell short to sell; (D) sell short to sell short exempt; (E) sell short
exempt to sell; and (F) sell short exempt to sell short. This rule text would use for
the Pillar trading platform rules the same rule text as in Rule 7.16(f)(viii), without
any substantive differences. The Exchange proposes to include the text from Rule
7.16(f)(viii) regarding order priority when changing order marking to Rule 7.36P
to consolidate ranking in a single rule.
Proposed Rule 7.36P(g) would specify that the Exchange would enforce ranking
restrictions applicable to specified order or modifier instructions. These order and modifier
instructions would be identified in proposed new Rules 7.31P and 7.44P, which the Exchange
will submit in a rule filing prior to implementing the Pillar trading platform.
29
In addition, the Exchange proposes a definition in Rule 1.1(aP) of NYSE Arca Book that
would be applicable to the Pillar rules. The proposed definition would differ from the current
definition of NYSE Arca Book in Rule 1.1(a) in that it would not include references to the terms
“Display Order Process,” “Working Order Process,” and “Tracking Order Process,” which as
discussed above, are terms that will not be used in Pillar. As proposed, new Rule 1.1(aP) would
provide that the term “NYSE Arca Book” refers to the NYSE Arca Marketplace’s electronic file
of orders, which contains all orders entered on the NYSE Arca Marketplace.
QUOTE

https://www.sec.gov/rules/sro/nysearca/2015/34-74951.pdf

https://www.nyse.com/pillar

It seems the CME's MDP 3.0 data changes that were announced prior to this meeting could be due to foresight knowledge on the upcoming order book/execution proposed changes. However that's just my conjectured opinion.

UPDATE 2-CFTC says [AUTOLINK]CME[/AUTOLINK] directed to beef up 'spoofing' enforcement | Reuters

Also nice and timely is the case with the Flash Crash trader that every uncle Joe and aunt Millie knows about. The SEC and CME have their scape goat.

Follow me on Twitter Reply With Quote
Thanked by:
  #78 (permalink)
 
cory's Avatar
 cory 
virginia
 
Experience: Intermediate
Platform: ninja
Trading: NQ
Posts: 6,098 since Jun 2009
Thanks Given: 877
Thanks Received: 8,090


shots fired View Post
After CQG switched to the new CME protocol for tick data, I changed from a 2000 tick chart to a 763 tick chart. This occurred on May 3rd. Now this morning when I opened up my chart, it appears they are back to using the old protocol. (the 763 tick chart now has way too many candles). The 2000 tick chart of old seems to have returned. Does anyone know what is going on?

Nice, I see it too they unbunble it I guess. I will keep 6500v chart tho jus in case they mess it up again.

This just in from ninja forum
https://forum.ninjatrader.com/showthread.php?p=412654


NinjaTrader_Brandon View Post
Hello,

Please note that I have received the following information from CQG. This applies to CQG, Continuum, NinjaTrader Continuum, and how we will provide data from our historical data servers going forward.

"CQG implemented a newer version of MDP 3.0 this weekend. This applies to CME, NYMEX, and COMEX. (It is not implemented yet for CBOT.)
The version is MDP 3.0, not fix/fast.
However, we have ‘unbundled’ (given greater precision to filled trade sizes) to the extent possible. Basically this is true for outright fills. The exchange does not provide details for implied fills, so these are still ‘bundled’."


Reply With Quote
Thanked by:
  #79 (permalink)
 hobart 
charlotte nc
 
Experience: Master
Platform: Sierra Chart, TOS, Tradestation, NinjaTrader
Trading: energy
Posts: 114 since Jul 2012
Thanks Given: 81
Thanks Received: 172

CTS is has started migration over to the mdp feeds


Quoting 
Over the next few weekends CTS will move the CME market channels to the new MDP3 price feed. If you experience any unusual activity with the price feed please contact CTS support.


Reply With Quote
  #80 (permalink)
 
cunparis's Avatar
 cunparis 
Paris, France
 
Experience: Advanced
Platform: Market Delta & Ninjatrader
Trading: ES
Posts: 2,565 since Jun 2009
Thanks Given: 1,162
Thanks Received: 2,093


It seems CQG went back to unbundled data. Does anyone know if it'll stay that way? Or if we'll have a choice? It messes me up when they switch without telling anyone.

Follow me on Twitter Reply With Quote




Last Updated on May 19, 2017


© 2024 NexusFi™, s.a., All Rights Reserved.
Av Ricardo J. Alfaro, Century Tower, Panama City, Panama, Ph: +507 833-9432 (Panama and Intl), +1 888-312-3001 (USA and Canada)
All information is for educational use only and is not investment advice. There is a substantial risk of loss in trading commodity futures, stocks, options and foreign exchange products. Past performance is not indicative of future results.
About Us - Contact Us - Site Rules, Acceptable Use, and Terms and Conditions - Privacy Policy - Downloads - Top
no new posts