Product roadmap

CME has "LimitsBanding" messages which provide updates during the weekly session to high & low limit prices for instruments. These are currently excluded from normalization, with the high_limit_price and low_limit_price in our definitions schema being provided by the instrument definition messages, where CME says "This value is indicative only and may not reflect the actual real-time low limit price." The price band limits may either be added as new records in the statistics schema, or as an update to the definitions schema. Internal tracking: D-3303

For ICE US futures including US softs and financials, such as cocoa, cotton, sugar, frozen orange juice, canola, world cotton, US grains, precious metals, MSCI indices, all currency pairs, and US Dollar Index. This was previously tied to this ticket for ICE Futures Europe and ICE Endex. However, we've decided to release ICE Futures Europe and Endex first separately from ICE US.

Currently, n and v continuous symbology is supported in historical data but not live data. Live data only supports c (calendar-based) continuous symbology, which is less useful.

This feature tracks a potential backfill of our CME Globex back to Jan 2009. Note that there will be some limitations: Prior to May 2017, CME Globex used a legacy FIX/FAST format with at most 10 levels of depth, millisecond resolution timestamps, and no high-granularity match/send timestamps.We will source the data from CME directly, but they do not have pcaps going back to 2009. This means that we'll not have a separate ts_recv timestamp.We will need to consider how to handle the dataset naming, as "CME Globex MDP 3.0" will not be appropriate.

All orders plus last look quotes from 35 major banks and non-bank LPs, on one of the largest FX venues.

To extend support to browser-based applications.

It would be helpful if OPRA trade conditions were included in the normalized schemas. This is useful information that's currently lost during normalization. Also include the "message type" of each last sale message.

Currently, to fully process MBO data in Live starting in the middle of the session, the client needs to replay data from the start of the session (i.e. with start=0) or merging previously-recorded data. Our Historical API partially addresses this problem by including snapshots for CME at UTC midnight (00:00:00Z), since CME has weekly sessions starting Sunday afternoon. Our Live API should have a way of specifying to start with a snapshot, then continue with incremental updates. The client-side implementation should not need to merge/arbitrate between different sources or carefully pick a start time. (Though, set the F_SNAPSHOT flag so that the client can distinguish the synthetic snapshot messages from incremental updates.) This is distinct from other snapshot methods mentioned "Provide snapshots for historical and live data" which may be implemented separately. See also: Allow live API clients to request for MBO snapshot recovery

https://www.epexspot.com/en

This feature would allow the user to request trading calendar information (such as trading session start/end times) via our API. This is especially useful when considering trading sessions that can span multiple UTC dates (and hence the possibility of having multiple trading sessions within a single day)

Currently, indices are indirectly supported through tradable index instruments on CME futures, ETFs, etc. and we don't provide the index values (non-tradable) themselves. This may be sourced from a feed like the Cboe Global Indices Feed or NYSE Global Index Feed.

Full depth of book feed for Cboe Futures Exchange (CFE). CFE contains volatility futures and corporate bond index futures, such as VIX futures (VX, VXM).

Currently, equities is supported via individual prop feeds of each venue. While NASDAQ is sufficient for getting NBBO for most of the time, some users prefer something that will be more in line with actual NBBO from SIPs. This feature request tracks 3 possible modes of consolidation for both historical and live data: Databento server-side consolidation of multiple proprietary feeds Consolidated data from proprietary feed like Nasdaq Basic in lieu of SIP Consolidated data from CTA/UTP SIPs We plan on implementing 1-2 of these three options.

For options, including in the CME and OPRA datasets, the existing MBP-1 schema can have significant record volume despite the instruments being extremely illiquid. In practice, there are several orders of magnitude more MBP-1 records than trades, which is unwieldy to work with. We're introducing a new schema to resolve this. BBO on interval (bbo-1s, bbo-1m) will provide the last best bid, best offer, and sale at 1-second or 1-minute intervals. This is different from BBO on trade (tbbo), which is a subset of our MBP-1 schema and provides every trade event alongside the BBO immediately before the effect of each trade. The main distinction is that TBBO is captured in trade space, while BBO is captured in time space. Learn more in our MBP-1 vs. TBBO vs. BBO schemas guide. Update: The BBO schema will be supported for all symbols on all datasets, not only options. This description focuses on options as that's where the benefit would be maximized (since options have much larger order-to-trade ratios). We'll roll this out for CME first, followed by equities and ICE, and then OPRA.

This client library makes all our historical and live features easier to integrate in C# on Windows, Linux, and Mac OS. C# is currently already supported through our HTTP API and Raw TCP protocol, which are both language-agnostic.