e.g. Shares outstanding, short interest, market capitalization, P/E ratio etc.
Data for: Copenhagen Stock Exchange (Nasdaq Copenhagen) Stockholm Stock Exchange (Nasdaq Stockholm) Helsinki Stock Exchange (Nasdaq Helsinki) Iceland Stock Exchange (Nasdaq Iceland) Tallinn Stock Exchange (Nasdaq Baltic) Riga Stock Exchange (Nasdaq Baltic) Vilnius Stock Exchange (Nasdaq Baltic)
This data is not provided for all index underlyings instruments in the OPRA dataset. Having this data simplifies calculation of implied volatility for options on indices.
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.
Hello, I'd really like high quality equities data for european exchanges like xetra, so I created this feature request. Maybe others are interested in that as well. Even EOD would be nice as a start. Kind regards,
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.
Dividends, stock splits, mergers, ticker changes, adjusted EOD historical prices.
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)
Support Parquet as a form of encoding, aside from dbn, CSV and JSON.
Documentation for how to construct an order book from our MBO data; managing state from the incremental events, and the meaning and handling of events for each action type. Related to: https://roadmap.databento.com/b/n0o5prm6/feature-ideas/example-order-book-implementation-in-python and https://roadmap.databento.com/b/n0o5prm6/feature-ideas/example-order-book-implementation-in-c
Data for Eurex, including all schemas (MBO, MBP, ohlcv, etc.).
Ability to get raw data payloads and historical PCAPs, as opposed to normalized data that is currently available. For example, on CME, there are shortcomings with normalized data: Normalized data schemas do not provide MDOrderPriority, which can be useful for LMM markets or make it easier to handle order quantity down-modifies. Normalized data schemas do not show full message tree of trade summary messages, making it harder and slower to associate passive-side changes after an aggressing trade is reported. This issue arises because of the asynchronous nature of CME's trade reporting vs order update publication; order updates get published after the trade summary. Currently, a user has to use ts_event to associate trade and the depleted orders. This is especially inconvenient if multiple passive orders are on the other side of a large aggressing order. On other venues, there are other message fields that our normalized format will fail to capture. The main challenge with providing PCAPs and raw data is that it is bandwidth-intensive. Furthermore, the message sizes vary, which throws off our pricing, search, filtering, and merging routine. This will introduce some asymmetry to our API design. A solution to this will likely be in the form of separate endpoint(s) on the historical side, and only be released after we've provided customer VMs.
Currently it's not possible to detect from the existing schemas when an instrument goes in and out of auction, or when trading is halted. Making a trading phase/trading status schema would enable users to detect these events.
Currently, this is described as WIP on our documentation. Related to: https://roadmap.databento.com/b/n0o5prm6/feature-ideas/order-book-management-guide-and-documentation and https://roadmap.databento.com/b/n0o5prm6/feature-ideas/example-order-book-implementation-in-c
To extend support to browser-based applications.