Product roadmap

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.

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. Similar to: https://roadmap.databento.com/roadmap/us-equity-trade-condition-codes

Adding support for the CBOE Complex Options Order Feed, which provides detailed insights into complex order activity across CBOE markets. This includes multi-leg strategy orders, spread data, and intricate order types that are vital for understanding advanced options trading strategies. Key Features: -Real-time and historical data on multi-leg orders. -Visibility into pricing and execution of complex options strategies. -Detailed breakdowns of spread and combination order flows.

To extend support to browser-based applications.

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

We've received some requests recently for Binance data. Please upvote if this is of interest. We're still determining whether this is worth the risk.

Historical and live market news.

Add a schema for calculated metrics like options greeks, e.g. implied volatility, delta, etc.

Futures and options on futures from LME. This will be captured at LON2 colo and include both L2 (for implied pricing) and L3 feed (order-by-order). Lower granularities like OHLC, OI, settlement volume, etc. will be included as well

Original request from Juan Linares: "Great product but please add dark mode." There are two separate parts to this: Dark mode for the portal and main website (databento.com, databento.com/portal) Dark mode for the docs We can consider this only after Q1 2025 since we're doing a major rebranding of our website which is expected to finish by early April 2025. The new colors will make it easier for us to implement a dark mode.

Stocks and derivatives data from the Singapore Exchange (SGX)

Currently, Trade Busts and Trade Corrections are dropped by Databento's normalization. In the scope of this feature request, add the trade bust/corrections to the API, either as a separate schema or inline in the MBO schema (and downstream).

Hello, We work with historical GLBX.MDP3 data for equity index futures outrights, using the status, bbo-1m / cbbo-1m, definition and statistics schemas, with processing defined on ts_recv. We'd be grateful for confirmation on the points below. Where something is already documented, a pointer to the page is enough. A. Ordering of status records The GLBX.MDP3 page ("Order Priority") states that messages for a single instrument_id "are never reordered, even if they have the same timestamps". Does this apply to status records? Does it hold in historical delivery (timeseries.get_range and batch files), where records are sorted by the index timestamp ts_recv? Do ties on ts_recv keep the original received order? If so, does that order correspond to CME's message sequence (packet sequence and order within a packet), or to another documented ordering? B. Status semantics What does "~" mean in is_trading and is_quoting for GLBX.MDP3, and when is it emitted? What is the relationship between action and is_trading, and which should be treated as authoritative if they appear to disagree? Please also explain the documented meanings of action values 0 (None), 6 (New price indication) and 14 (SSR change) for GLBX.MDP3, and whether a record with one of these values can affect an instrument's trading state. The status documentation says the historical API includes "a snapshot of the last status record for each active instrument at UTC midnight". Status records have no flags field. How can a snapshot record be distinguished from an event record? What ts_recv does a status snapshot carry? Can its state ever differ from the last preceding event record for that instrument? The GLBX.MDP3 page notes that is_trading and is_quoting "may be incorrect before activation or after expiration". Over what period does this apply, and can affected records be identified? C. Quote schemas Does bbo-1m for GLBX.MDP3 include implied prices, or only the outright book? The BBO page describes bbo as "a subset of MBP-1"; the GLBX.MDP3 page says merged real-and-implied top of book is published on CMBP-1 and subsampled on CBBO-1s/1m. Precisely how do bbo-1m and cbbo-1m differ for GLBX.MDP3 (book source, interval semantics, when a record is emitted)? What is the authoritative field list for cbbo-1m, including whether it carries flags, sequence and order counts? From what date is cbbo-1m available for GLBX.MDP3? Over what period is GLBX.MDP3 sourced from MDP 2? For cbbo-1m, is ts_recv the interval end clamped to the minute boundary, and is a record omitted when nothing changes, as documented for bbo-1m? Can F_BAD_TS_RECV or F_MAYBE_BAD_BOOK be set on bbo-1m or cbbo-1m records? If so, what does each mean for an interval record? In the merged (real-and-implied) top of book, can bid and ask be locked or crossed during normal trading, outside pre-open and the daily pause? D. Other For metadata.get_dataset_condition, is the returned date a UTC calendar date? Which timestamp (ts_recv or ts_event) assigns records to it? Are there known limitations or periods of clock or ordering issues affecting status ts_recv for GLBX.MDP3, given that status records can't carry F_BAD_TS_RECV? How are truncated or partial historical responses signalled for get_range and for batch jobs? Can a request complete without error yet return less than the full requested range? Are there documented completeness indicators (for example record counts, checksums or manifest fields) that confirm a requested ts_recv range was delivered in full? Thank you.

Charge my card and restore service.

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). Keywords: Market calendar, trading holidays.