Issues tracker
New issueSubmit issue and bug reports here. For feature requests and enhancements, use our Roadmap instead. For other issues, or if you prefer to reach us privately, contact support.
Instrument definition issues on GLBX.MDP3 from 2012-02-05 to 2012-02-10
Instrument definitions have misaligned or incorrect values for many (about 1%) of instruments from 2012-02-05 to 2012-02-10. This is an artifact of incomplete data from our backfill source (CME DataMine)βwe had to infer and reconstruct the fields as best as we could from the following week's data.
Tessa Hollinger#data-quality0
Extend Nasdaq coverage to include last hour of extended trading, when it crosses into next UTC day
During winter months, when Eastern Time is UTC-4, the last hour of Nasdaq extended trading session (7 to 8pm ET) extends into the following UTC day. This is assigned D-2127 internally.
Jack C0
Missing `ts_ref` in CME MDP2 after 2015-11-20
Statistics after 2015-11-20 appears to always be missing ts_ref. This is tracked internally as D-3941.
Carter Green#bug0
Missing SettlPriceType normalization for MDP2 CME data
CME data prior to May 2017 is missing normalization of SettlPriceType to the stat_flags field. This is tracked internally as D-3940.
Carter Green#bug0
Saturday test data shows up on CME live data
Currently our historical data discards Saturday test data on CME, however our live data gateways expose the test data because itβs useful for Databentoβs own internal monitoring to ensure that our live gateways are running properly. We plan to discard this test data in live as well to ensure point-in-time behavior. Weβll likely have to hide test data from customers. This is assigned D-2036 internally and will likely only be addressed in Q3.
Tessa Hollinger#data-quality#bug0
Leg information is not provided for composite instruments in CME and ICE
Currently, the InstrumentDefMsg provided by our definition schema does not contain the underlying leg information. Adding this is on our roadmap here. This is assigned internal ticket D-2032.
Renan Gemignani#symbology0
MDOrderPriority is not provided for CME Globex MDP 3.0
We currently leave out MDOrderPriority from our normalized MBO messages, due to 2 reasons: This behavior is CME-specific. Most other venues adopt ITCH-based behavior, where ordering is based on timestamp instead. If we supported MDOrderPriority, it would bloat the data for all of the non-CME venues. ts_event serves the same purpose as MDOrderPriority for all instruments except for interest rate options and instruments where there's a LMM. We confirmed this with CME GCC and also from practical experience of comparing simulation against live order matching. We actually recommend most users to infer MDOrderPriority from ts_event since it makes their order book implementation more reusable for other venues. Two proposed solutions were considered: Exposing raw message payloads and PCAPs. 'Supplementing' our normalized MBO data with venue-specific fields. We consider approach 2 to be inferior: If we tried incorporating other fields, we'd be replicating the venue's original structure in DBN with unnecessary indirection and copies and losing the benefit of normalization β so we might as well expose the raw message payload. For many venues, the raw data has nested message tree structures, and if we replicated it, either in Databento Binary Encoding or an unstructured encoding like JSON, we'd lose a lot of the benefits of our zero-copy binary encoding. The only limitation of approach 1 is that it's bandwidth-intensive, obviously as most venues require you to receive their raw multicast data on their extranet over a physical cross-connect. At this time, we reject approach 2 and are working towards approach 1. This is tracked on our roadmap here. This is tracked internally as D-2130.
Tessa Hollinger#http-api π#raw-api π1
Broken symbology for some BRN options on 2024-01-01 and 2024-01-02
We have identified a symbology issue with BRN options which affects the following calendar dates: 2024-01-01, 2024-01-02. This issue does not affect queries for ALL_SYMBOLS, but requests for specific options or the parent symbology BRN.OPT may fail. Addressing this issue requires regenerating the data for the IFEU.IMPACT dataset. We will resolve this issue once this is completed. This is tracked internally as D-4010.
Nicholas James Macholl#data-quality#bug#symbology0
Degraded GLBX.MDP3 data on 2024-08-09
This is tracked internally as D-4017
Carter Green#data-quality0
GLBX.MDP3 empty data for 2010-09-13, 2010-11-17, 2012-07-19, and 2017-03-13
Legacy MDP 2 data is empty on 2010-09-13, 2010-11-17, 2012-07-19, and 2017-03-13. These were regular trading days and should have data. This is tracked internally as D-3994
Carter Green#data-quality#data-gap0
GLBX.MDP3 historical data is degraded for 2024-11-08
Tracked internally as D-3847
Renan Gemignani#data-quality#data-gap0
Incorrect display factors for GLBX.MDP3 on 2012-02-05 to 2012-02-11
The GLBX.MDP3 data from 2012-02-05 to 2012-02-11 is displaying prices utilizing the wrong display factors. This leads to prices being off by a factor varying based on the instrument group.
Renan Gemignani#data-quality#bug0
Price calculator doesn't consider unlimited subscription
If a team wants to make a batch download request through the portal that would be covered (free) on their subscription plan, they should be able to submit it regardless of the self-imposed team or user budget limits. Today, the user is unable to submit a request due to the "You've exceeded your team monthly limit. Your access to data is currently blocked." error. The workaround is to raise the team budget to at least $0.01 over the current monthly usage, as reported by https://app0.databento.com/portal/billing Internal tracking: D-3895
Enda#bug0
GLBX.MDP3: MBO fill side inconsistent with original order side on some spread trades
Our CME MBO data assumes that, on a trade with a defined aggressor, there is only one order participating on the aggressor side (so if the Trade has side=A, at most one participating order will have a fill with side=A). This assumption does not hold in some cases. We have observed this behavior primarily on interest rate future spread trades. Quoting CME's documentation (https://cmegroupclientsite.atlassian.net/wiki/spaces/EPICSANDBOX/pages/46436881/MDP+3.0+-+Trade+Summary+Order+Level+Detail): "The aggressor quantity (tag 32) in the first Order Detail entry is not equal to the Summary Level fill quantity (tag 271) In this case, the aggressor joined a pool of resting orders and thereby created sufficient quantity to trigger a trade. This scenario can occur in any ratio spread where a different minimum quantity is required for each leg in order for the spread to trade. Examples include IVR and butterfly spreads. " This incorrect assumption leads to some Fill messages being reported with an incorrect side on the MBO schema. Here is an example of a such message: ts_recv,ts_event,rtype,publisher_id,instrument_id,action,side,price,size,channel_id,order_id,flags,ts_in_delta,sequence,symbol 2024-11-11T00:08:23.246556244Z,2024-11-11T00:08:23.243157109Z,160,1,42000697,T,A,110.093750000,4,19,8415051921726,0,22594,341221,ZNZ4 2024-11-11T00:08:23.246564192Z,2024-11-11T00:08:23.243157109Z,160,1,42000697,A,A,110.093750000,1,19,8415051921726,130,13621,341222,ZNZ4 2024-11-11T00:08:23.246837632Z,2024-11-11T00:08:23.243161063Z,160,1,42000697,F,B,110.093750000,1,19,8415051921726,0,17900,341225,ZNZ4 2024-11-11T00:08:23.246837632Z,2024-11-11T00:08:23.243161063Z,160,1,42000697,C,A,110.093750000,1,19,8415051921726,0,17900,341225,ZNZ4
Renan Gemignani#data-quality#bug1
Incorrect strike price for CME event contracts
This is a specific case of this other ticket: https://issues.databento.com/roadmap/incorrect-display-factor-used-for-the-strike-price-field-in-the-definition-schema-for-some-cme-options For now, use these correction factors to scale the strike price as a workaround (e.g. ECBTC's strike price needs to be multiplied by 100): EC6E 0.01 ECBTC 100.0 ECGC 10.0 ECHG 0.01 ECNG 0.1 ECO 10.0 ECSI 0.1 ECYM 100.0
Tessa Hollinger#bug0