Venues and datasets

CME Globex MDP 3.0

The CME Group Market Data Platform (MDP) 3.0 disseminates event-based bid, ask, trade, and statistical data for CME Group markets (CME, CBOT, NYMEX, and COMEX).

Databento's coverage for CME starts in May 2017, when MDP 3.0 introduced full granularity for every order event (MBOFD) in addition to providing aggregated depth at a limited number of price levels (MBP).

Databento's data is based on the MBOFD data coverage; we do not normalize CME's incremental MBP messages. CME makes the details of their specification available on their website here.

Timestamps

CME MDP 3.0 messages received by Databento will generally include two timestamps with nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

More details about our timestamps are available in our timestamping guide.

MBO normalization

F_LAST flag in MBO

When interpreting MBO data, the F_LAST flag (0x80, 128) is used to mark the last record in a single event for each instrument_id. This flag is based on CME's "End of event" flag in tag 5799-MatchEventIndicator. However, CME only sets this flag on one single message, even if the event spanned multiple instruments. Instead, we set the F_LAST flag on the last record for each instrument, so that the data can be interpreted consistently with any subset of instruments. Records with action None may carry F_LAST.

Across all of Databento's feeds, it is important to use the F_LAST flag when calculating the best bid and offer, like our MBP-1 schema. Between records without the F_LAST flag, the book is in the process of updating, and the apparent best bid and offer may have already been traded.

This is accounted for when we construct our other schemas, such as MBP-1 and Trades. Outside of MBO, this flag can be ignored.

Order events

Records in the MBO schema with Add, Modify, and Cancel actions are normalized from Market Data Incremental Refresh - MBOFD, and records with Trade and Fill actions are normalized from Market Data Incremental Refresh - Trade Summary messages, and records with the cleaR action are normalized from Market Data Incremental Refresh - Channel Reset messages.

Trade events

The MBO schema includes detailed information about both sides of the trade by normalizing Market Data Incremental Refresh - Trade Summary messages from CME into Trade and Fill actions. The MBP-n and trades schemas include Trade records, but do not include Fill detail records.

Each CME MDP 3.0 Market Data Incremental Refresh - Trade Summary message from CME contains two repeating groups: a set of trade summaries, followed by a set of order ID entries. Each trade summary in the message is normalized into one Trade record. If there is a defined aggressor for the trade, its corresponding order ID entry from the second set is used to populate the order_id field. This commonly happens when an incoming order partially executes, leaving the remaining quantity to rest on the book.

Following each Trade record, the remaining (passive) order ID entries are normalized into Fill records. These records correspond to resting orders in the order book, but do not modify the orders.

If the aggressing order existed on the book, then a Fill record will be emitted for it. This can happen if a resting order was modified to cross the book. If the aggressing order did not already exist on the book then its Fill record is suppressed, however its order ID is still reported in the Trade record as described above.

Side

Implied trades may not have an aggressing side set. These trades will normalized with side set to None.

Order Priority

Although Databento does not expose tag 37707-MDOrderPriority in the MBO schema, first in, first out priority (FIFO) can be determined from message order. Messages for a single instrument_id are never reordered, even if they have the same timestamps. Our daily MBO snapshots also preserve FIFO order priority.

CME MBO snapshot

At the beginning of the weekly trading session, CME publishes a MBO order snapshot. This snapshot contains any orders that persisted from the previous trading session, such as Good 'Till Cancelled orders. The event timestamp (ts_event) for these orders corresponds to the time the snapshot is generated by CME. It does not reflect the original time the order was entered or last modified.

These orders are not published by CME in priority order. As Databento does not expose tag 37707-MDOrderPriority, if these MBO records were published by Databento in the same order they were sent from CME, it would not be possible to determine the correct order priority. In order to publish the records in priority order, Databento buffers the orders from the first CME event of the trading session, per instrument.

Once the End of Event is reached, Databento sorts the records in priority order and then publishes them.

Therefore, the order priority is correctly reflected by the order of publishing.

The ts_recv for these records will be set to the ts_recv of the final record of the event. As the records have been slightly delayed and the ts_recv of the initial records may not match the original ts_recv, the flag F_BAD_TS_RECV is set on these records.

The F_SNAPSHOT flag is also set on these records to indicate that they are from the CME snapshot.

Weekly Sessions

Although CME pauses trading daily, the market follows a weekly session structure with most instruments accepting orders from Sunday night to Friday night (local time). To make it easier to work with historical MBO data, Databento includes an order book snapshot at 00:00:00 UTC each weekday (Monday-Friday).

Before the trading session begins, or during the daily pause, it is normal for order books to be locked or crossed: CME will accept orders but won't execute any trades until the opening uncrossing.

Details about the trading hours and sessions for each product group are available on the Trading hours page of CME's website.

Statistics normalization

Databento normalizes the following daily statistics from Market Data Incremental Refresh - Daily Statistics:

• Settlement price
• Cleared volume
• Open interest
• Fixing price

The exact times these statistics are published will vary. Cleared volume and open interest statistics will normally publish on the following UTC date, unless they are for Friday's session, in which case they will be published on the following Sunday.

Databento normalizes the following session statistics from Market Data Incremental Refresh - Session Statistics:

• Opening and indicative opening price
• Trading session high and low price
• Trading session highest bid and lowest offer

These statistics are published throughout the trading session as the values change.

Reference timestamp (ts_ref)

CME includes tag 5796-TradingReferenceDate, the trading session date, with daily statistics. This field is normalized to ts_ref as a nanosecond-precision UNIX timestamp for consistency with other timestamps. Because the source only has date precision, users should avoid localizing ts_ref to their time zone.

Multiple records for the same date

CME often publishes multiple messages for the same trading session date (indicated by ts_ref) and daily statistic. The initial messages indicate preliminary values, and the final message for the trading session date indicates the final value. The final message is always the most accurate and the one you should use, when available.

Stat flags

Settlement price statistics normalize the bit field tag 731-SettlPriceType to the stat_flags field.

The CME documentation on settlement prices expands on the meaning of each flag value.

Symbology

Databento normalizes the asset field from tag 6937-Asset of the Market Data Security Definition message. The asset field is used when requesting data with parent symbology.

Databento normalizes the raw_symbol field from tag 55-Symbol of the Security Definition message. This symbol contains the product code, followed by the month code, followed by the year. Previously, this field would only contain a 1-digit year, e.g. ESZ3 for the E-mini S&P 500 December 2023 contract. In some recently listed contracts, CME has begun using a 2-digit year, e.g. NGN25 for the Henry Hub Natural Gas July 2025 contract.

Spreads and combos

In addition to futures and options on futures, this dataset also contains data for both exchange-listed spreads and user-defined spreads (UDS).

Spreads and combinations consisting only of futures (such as exchange-listed calendar spreads) are considered part of the futures parent symbols. For example, ESH4-ESZ4 is a calendar spread contained in ES.FUT. These spreads can have negative prices.

Spreads and combinations containing options (such as butterfly or covered spreads) are considered part of the option parent symbols. For example, UD:1V: VT 2533938 is a vertical option spread contained in ES.OPT.

The CME documentation on spreads and combinations contains an exhaustive list of the different spread types. The instrument_class field in the definition schema can be used to identify spread instruments generically. The SecuritySubType field in the exchange documentation is normalized to the secsubtype field in the definition schema and can be used to identify the exchange-specific spread type.

To identify the parent symbol of strategies and user-defined spreads, the asset field in the definition schema should be used.

Status normalization

Status records are normalized from Market Data Security Status messages. A single status message from CME may the update status of all instruments in a group, all instruments in a group and asset, or an individual instrument. To support requesting data for individual instruments, Databento normalizes all these messages into instrument-level status messages. When requesting status schema data for multiple instruments in the same group, there will be status records that are identical minus the instrument_id.

The state fields of the status schema: is_trading, is_quoting, and is_short_sell_restricted are based solely on the status updates from CME. Group-level status updates generate a status record for each instrument with a definition, regardless of activation or expiration, as a result, before activation the status state fields may be incorrect.

Matching Algorithms

CME implements various matching algorithms across its universe of products, with FIFO being the most common.

Specific details on the different algorithms can be found on the Supported Matching Algorithms page on the CME website.

MDP 2 data

On 2017-05-21, CME introduced full granularity for every order event (MBOFD). Data prior to this date is based on the MDP 2, level-aggregated FIX protocol. This leads to some differences in the data.

Timestamps

MDP 2 data is sourced from FIX flat files. Because of this, capture timestamps (commonly available as ts_recv) are not available. The ts_recv field on all MDP 2 data is set to the same value as ts_event.

Because of this, all records on MDP 2 data have the F_BAD_TS_RECV flag set. This is normal and expected.

Nanosecond-resolution timestamps have been introduced by CME on 2015-11-20. Timestamps prior to that date are limited to millisecond resolution.

MBO format

MDP 2 data predates the introduction of full-depth MBO by CME. Because of this, the MBO schema is not available. The highest granularity schema available for MDP 2 data is MBP-10.

Status schema

There's significantly less status data prior to 2015, this is expected. Before November 2015, status changes from the normal trading schedule did not result in a status message.

Cboe BYX Depth

Cboe BYX disseminates full depth-of-book data for their exchange through their Pitch Feed, which Databento receives over UDP multicast in our NY4 data center.

The Multicast Depth of Book (Pitch) Specification is available as a PDF from Cboe's website.

Info

The Databento team is currently working on this article.

Timestamps

Cboe messages received by Databento will generally include one timestamp with nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

More details about our timestamps are available in our timestamping guide.

Statistics

Databento provides Opening Price and Closing Price statistics, normalized from the Auction Summary message. These statistics have the auction uncrossing price and quantity for the respective event.

Imbalance normalization

Cboe BYX provides information about opening and closing cross imbalances in their Imbalance message. Databento normalizes each message into a record in the imbalance schema.

Cboe BYZ Depth

Cboe BYZ disseminates full depth-of-book data for their exchange through their Pitch Feed, which Databento receives over UDP multicast in our NY4 data center.

The Multicast Depth of Book (Pitch) Specification is available as a PDF from Cboe's website.

Info

The Databento team is currently working on this article.

Timestamps

Cboe messages received by Databento will generally include one timestamp with nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

More details about our timestamps are available in our timestamping guide.

Statistics

Databento provides Opening Price and Closing Price statistics, normalized from the Auction Summary message. These statistics have the auction uncrossing price and quantity for the respective event.

Imbalance normalization

Cboe BYX provides information about opening and closing cross imbalances in their Imbalance message. Databento normalizes each message into a record in the imbalance schema.

Cboe EDGA Depth

Cboe EDGA disseminates full depth-of-book data for their exchange through their Pitch Feed, which Databento receives over UDP multicast in our NY4 data center.

The Multicast Depth of Book (Pitch) Specification is available as a PDF from Cboe's website.

Info

The Databento team is currently working on this article.

Timestamps

Cboe messages received by Databento will generally include one timestamp with nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

More details about our timestamps are available in our timestamping guide.

Cboe EDGX Depth

Cboe EDGX disseminates full depth-of-book data for their exchange through their Pitch Feed, which Databento receives over UDP multicast in our NY4 data center.

The Multicast Depth of Book (Pitch) Specification is available as a PDF from Cboe's website.

Info

The Databento team is currently working on this article.

Timestamps

Cboe messages received by Databento will generally include one timestamp with nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

More details about our timestamps are available in our timestamping guide.

Flags

For Cboe EDGX Depth, the F_PUBLISHER_SPECIFIC flag is used in the MBO schema to indicate Retail Priority Orders (RPOs). MBO messages with action A will have the F_PUBLISHER_SPECIFIC flag set if the order is an RPO. This flag will not repeat on subsequent modifications or cancellations.

Retail Priority changes the order allocation priority model on EDGX to price-retail priority-time priority. Thus, Retail Priority Orders will have priority ahead of all other available interest at a price level.

Databento US Equities Basic

Info

Databento Equities Basic was deprecated on January 13, 2025. Its datasets are now offered individually through our Databento US Equities Service. Existing users can access the legacy DBEQ.BASIC feed until March 1, 2025.

Databento US Equities Basic is a bundle of proprietary market data feeds from three US equities exchanges: NYSE Texas, NYSE National, and IEX.

Details for each underlying dataset are available on the following pages:

• NYSE Texas Pillar
• NYSE National Trades and BBO
• IEX TOPS

Venues

Databento US Equities bundles include data from multiple venues. The publisher_id field on every record can be used to identify the venue associated with the event. The values corresponding to these IDs are available through the metadata.list_publishers endpoint.

See also

Examples - US equity options volume by venue

Symbology

The constituent feeds of Databento US Equities use different symbol suffixes and different numerical IDs to refer to instruments. This page on ticker symbol conventions from Nasdaq outlines the four most common suffix patterns used for US equities, with the "Nasdaq Integrated Platform Suffix" being the most common, and the "CMS Suffix" used by NYSE-owned feeds such as NYSE Texas.

Databento US Equities bundles standardize on using the "Nasdaq Integrated Platform Suffix" for the raw symbol, regardless of which suffix is originally used by the venue. However, in the definition schema, the raw_symbol field will be based on the original value from the venue.

Additionally, Databento US Equities bundles use internally-assigned instrument IDs. These IDs are assigned strictly from the raw symbol string; they do not take into account corporate actions like renames, relistings, or mergers. The upstream-publisher-assigned instrument IDs are available in the raw_instrument_id field of the definition schema.

Databento US Equities Mini

Databento US Equities Mini is a derived top-of-book dataset, sourced from the proprietary market data feeds of both alternative trading systems (ATS) and RegNMS venues.

Schemas

The following schemas are available for this dataset: MBP-1, BBO, TBBO, Trades, OHLCV-1s, OHLCV-1m, OHLCV-1h, OHLCV-1d, and Definitions.

Aggregated BBO

Databento US Equities Mini is an aggregated dataset, quotes are not provided for the individual component venues. A single aggregated BBO is printed for each instrument.

To provide this aggregated BBO, Databento calculates the best bid and best ask prices across the component venues of the feed, adding together all quantity (including odd lots) at the price of the BBO regardless of venue. We do not aggregate the order counts across the component venues, so bid_ct_00 and ask_ct_00 will always be 0.

Venues

To qualify as a derived dataset, trade and BBO data are anonymized from the original venues' data.

Due to this, the publisher_id of a trade does not identify the original venue of the trade, and will always have the value EQUS.MINI.EQUS. The sequence field is set to 0 on all messages.

Aggregated OHLCV

The OHLCV schemas for Databento US Equities Mini aggregate prices and volume across all the component venues. A single aggregated OHLCV message is printed per instrument, per interval.

Timestamps

Messages received by Databento from component venues will generally include two timestamps with nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

The ts_in_delta field is not populated for this dataset and will always be set to 0.

More details about our timestamps are available in our timestamping guide.

Databento US Equities Summary

Nasdaq disseminates consolidated volume and end-of-day statistics via their Nasdaq NLS+ feed. Databento receives these over UDP multicast in our NY4 data center.

PDF specifications are available on Nasdaq's website for the NLS+ feed.

Schemas

Databento normalizes the consolidated volume provided by the Nasdaq NLS+ feed on every trade into the statistics schema. This volume is consolidated across all US exchanges.

Databento normalizes the end-of-day summary provided by the Nasdaq NLS+ feed into the ohlcv-1d schema.

No other schemas are available on this dataset.

Timestamps

Nasdaq NLS+ messages received by Databento have at most one timestamp, which has nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

The extra field ts_in_delta does not convey any additional information for this dataset, and is equivalent to ts_recv - ts_event.

More details about our timestamps are available in our timestamping guide.

End-of-day Summary

Nasdaq NLS+ disseminates an end-of-day summary via their API at three different times:

1. Once at approximately 16:30 ET
2. Once at approximately 17:20 ET
3. Once at approximately 20:10 ET

Each of those summaries reflects the summary at the publishing time.

Databento only provides the last summary (from 20:10 ET) on the ohlcv-1d schema, which includes the total post-market volume, published as a single OHLCV-1d message per date. This can lead to discrepancies when comparing against other data sources that use the other earlier summaries.

The first two preliminary summaries are disseminated by Databento under the statistics schema. The stat_flags field is set to 1 for the first summary and 2 for the second summary.

Eurex Exchange

Eurex Exchange disseminates full depth-of-book data for their exchange through their EOBI (Enhanced Order Book Interface) Feed, which Databento receives over UDP multicast in our FR2 data center.

The latest EOBI Specification is available from Eurex website.

Trading hours

The regular trading hours for Eurex are:

• 08:00 CET to 17:30 CET (European hours)
• 17:30 CET to 22:00 CET (U.S. hours)

The extended trading hours for Eurex are:

• 01:00 CET to 08:00 CET (Asian hours)

Extended (Asian) trading hours only include a subset of instruments, including European indices, interest rate futures, and cryptocurrency futures.

Timestamps

Eurex EOBI messages received by Databento include multiple timestamps with nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server. More details about our timestamps are available in our timestamping guide.

EOBI RequestTime field is not available for the off-market trades (EOBI message TES Trade Report), manual and auction trades (EOBI message Trade Report), and cross request (EOBI message Cross Request). Thus ts_event is populated with TransactTime field, which corresponds to the time when the transaction was processed by the exchange's matching engine.

The ts_event for passive trade messages (EOBI messages Partial Order Execution and Full Order Execution) is populated with the RequestTime from the aggressive order.

Definition normalization

Definition records are sourced daily from Reference Data Interface snapshot. Definition records for intra-day instruments are sourced from EOBI incremental feed.

Symbology

Raw symbols are sourced from SecurityDesc string field. The semantics varying according to the type of instrument (secsubtype in the normalized message). The table below describes each instrument type, based on the venue's documentation.

The acronyms from the table above correspond to:

• SM: Settlement method (CS for cash, PS for Physical).
• ES: Exercise style (EU for European, AM for American).
• VN: Version number of an option. The version changes as a result of corporate events.
• IST: Standard strategy type for complex instrument, as detailed in the Trading parameters document.
• SEQ-NO: Unique sequence number of 6 characters per product.
• QSF: Quantity scaling factor of scaled simple instruments.
• YYYYMMDD: Contract date.
• MONYY: Contract month-year.
• YYMMDD: Creation date.
• O, N, V, D, F: Identify different strategy types.
• I: Identify inter-product spreads instruments.
• T: Identify strip instruments.
• C: Identify commodity strip instruments .

Expirations

Eurex only provides date-granularity expiration data in MaturityDate field from the reference data. As a result, the expiration field in the definition schema will always be at UTC midnight, even when the instrument expires during or after the trading day.

Eurex also provides the MaturityMonthYear field in the reference data, which corresponds to the instrument expiration month, and may be in a different month than the MaturityDate field. The MaturityMonthYear field is mapped to the fields maturity_year and maturity_month in the definition schema (maturity_day is not populated).

Statistics normalization

Databento provides the following statistics:

• Opening price: Published on the instrument's first trade (or in the end of the day if no trade occurs).
• Trading session high price: Published at the end of the day.
• Trading session low price: Published at the end of the day.
• Close price: Published at the end of the day.
• Cleared volume: Published at the end of the day.
• Settlement price: Published during the day, as soon as they are available. Different products have different schedules.
• Adjusted Open Interest : Published daily around 13:30:00 CET.

The end-of-day statistics are published around 20:00:00 CET, when the session transitions into a closed state. Some instruments might have end-of-day statistics on a different schedule.

Manual trades do not affect price statistics.

Stat flags

Settlement price statistics normalize the field tag 731-SettlPriceType to the stat_flags field.

Off-market trades

Trades reported in TES Trade Report and in Trade Report (with MatchType equal to ManualTradeEntry) EOBI messages are considered off-market.

Off-market trades have their publisher_id set to XEUR.EOBI.XOFF to distinguish them from on-exchange trades, which have their publisher_id set to XEUR.EOBI.XEUR.

This distinction is also reflected on the OHLCV schemas - if an interval contains both on-market and off-market trades for an instrument, two OHLCV messages will be published for that instrument on that interval, one with XEUR.EOBI.XEUR as the publisher_id and one with XEUR.EOBI.XOFF.

Order Identifier

EOBI does not provide an order identifier (order_id) field. Instead, it relies on two fields to uniquely identify an order of a given instrument: TrdRegTSTimePriority (priority timestamp) and Side.

Databento normalizes the order_id field in MBO schema by combining both priority timestamp and side. To extract the priority timestamp from the order_id, the most-significant bit can be masked, as below:

priority_timestamp = order_id & 0x7FFFFFFFFFFFFFFF

European Energy Exchange

European Energy Exchange (EEX) disseminates full depth-of-book data for their exchange through their EOBI (Enhanced Order Book Interface) feed, which Databento receives over UDP multicast in our FR2 data center. The XEEE.EOBI dataset does not disseminate data for EEX spot market, only for derivatives market.

The latest EOBI Specification is available from Eurex website.

Trading hours

The base trading hours on the EEX derivatives take place on weekdays from 08:00:00 CET to 17:00:00 CET. These trading hours can vary depending on the type of market.

EEX Japanese power futures trading hours are from 16:00 JST to 18:00 JST (08:00 CET to 10:00 CET).

EEX provides holiday calendars across different market types.

Timestamps

EEX EOBI messages received by Databento include multiple timestamps with nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server. More details about our timestamps are available in our timestamping guide.

EOBI RequestTime field is not available for the off-market trades (EOBI message TES Trade Report), manual and auction trades (EOBI message Trade Report), and cross request (EOBI message Cross Request). Thus ts_event is populated with TransactTime field, which corresponds to the time when the transaction was processed by the exchange's matching engine.

The ts_event for passive trade messages (EOBI messages Partial Order Execution and Full Order Execution) is populated with the RequestTime from the aggressive order.

Definition normalization

Definition records are sourced daily from Reference Data Interface snapshot. Definition records for intra-day instruments are sourced from EOBI incremental feed.

Symbology

Raw symbols are sourced from SecurityDesc string field. The semantics varying according to the type of instrument (secsubtype in the normalized message). The table below describes each instrument type, based on the venue's documentation.

The acronyms from the table above correspond to:

• SM: Settlement method (CS for cash, PS for Physical).
• ES: Exercise style (EU for European, AM for American).
• VN: Version number of an option. The version changes as a result of corporate events.
• IST: Standard strategy type for complex instrument, as detailed in the Trading parameters document.
• SEQ-NO: Unique sequence number of 6 characters per product.
• QSF: Quantity scaling factor of scaled simple instruments.
• YYYYMMDD: Contract date.
• MONYY: Contract month-year.
• YYMMDD: Creation date.
• O, N, V, D, F: Identify different strategy types.
• I: Identify inter-product spreads instruments.
• T: Identify strip instruments.
• C: Identify commodity strip instruments .

Expirations

EEX only provides date-granularity expiration data in MaturityDate field from the reference data. As a result, the expiration field in the definition schema will always be at UTC midnight, even when the instrument expires during or after the trading day.

EEX also provides the MaturityMonthYear field in the reference data, which corresponds to the instrument expiration month, and may be in a different month than the MaturityDate field. The MaturityMonthYear field is mapped to the fields maturity_year and maturity_month in the definition schema (maturity_day is not populated).

Statistics normalization

Databento provides the following statistics:

• Opening price: Published on the instrument's first trade (or in the end of the day if no trade occurs).
• Trading session high price: Published at the end of the day.
• Trading session low price: Published at the end of the day.
• Close price: Published at the end of the day.
• Cleared volume: Published at the end of the day.
• Final Settlement price: Published daily around 19:25:00 CET.
• Open Interest : Published daily around 21:10:00 CET.

Settlement price and open interest are only provided for options and futures outrights that had any trades during the day. Settlement price and open interest are not provided for Freight Futures and Options.

Most end-of-day statistics are published around 18:45:00 CET, when the session transitions into a closed state. Some instruments have end-of-day statistics on a different schedule, such as the Japanese power futures.

Manual trades do not affect price statistics.

Off-market trades

Trades reported in TES Trade Report and in Trade Report (with MatchType equal to ManualTradeEntry) EOBI messages are considered off-market.

Off-market trades have their publisher_id set to XEEE.EOBI.XOFF to distinguish them from on-exchange trades, which have their publisher_id set to XEEE.EOBI.XEEE.

This distinction is also reflected on the OHLCV schemas - if an interval contains both on-market and off-market trades for an instrument, two OHLCV messages will be published for that instrument on that interval, one with XEEE.EOBI.XEEE as the publisher_id and one with XEEE.EOBI.XOFF.

Order Identifier

EOBI does not provide an order identifier (order_id) field. Instead, it relies on two fields to uniquely identify an order of a given instrument: TrdRegTSTimePriority (priority timestamp) and Side.

Databento normalizes the order_id field in MBO schema by combining both priority timestamp and side. To extract the priority timestamp from the order_id, the most-significant bit can be masked, as below:

priority_timestamp = order_id & 0x7FFFFFFFFFFFFFFF

ICE Endex iMpact

ICE disseminates FOD (full order depth), MBP (market by price), TOB (top-of-book) and market statistics data for futures, spot contracts and options on futures via their iMpact feed, which Databento receives over UDP multicast in our Aurora DC3 data center.

For futures and spot, ICE publishes both FOD and MBP-5. Databento only normalizes the FOD messages. For options, ICE publishes MBP-10, MBP-5 and top-of-book. Databento only normalizes the MBP-10 messages.

This means that for options, only the top 10 levels of the book are available even in the MBO schema. For futures the full market is shown.

Timestamps

ICE iMpact messages received by Databento will generally include two timestamps with microsecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

ICE provides microsecond granularity timestamps along with sub-microsecond sequence numbers for ordering that are normalized as nanosecond timestamps for consistency in ordering with other datasets.

More details about our timestamps are available in our timestamping guide.

Matching Engine Location

ICE Endex has matching engines both in Chicago and Basildon. Databento captures the data for both matching engines in our Aurora DC3 location.

MBO normalization

For options, the ICE iMpact feed only includes market-by-price, which matches Databento's MBP-10 schema. We do not offer these messages in our MBO schema. They are only available on MBP-10 and other downstream schemas.

Each ICE "Trade Message" is normalized into a single MBO record with the Trade action, and the message's "TradeID" field is used as the order_id. ICE does not disseminate information about the passive side of the trade. The corresponding Fill record will have side equal to N and the same order_id value as the Trade record.

When ICE does not specify the aggressing side, Trade records will have side equal to N.

System priced legs

A system priced leg is the result of a trade in the outright spread. These trades, as published by the exchange, can have prices that are 10% or more off from the best bid and offer. ICE recommends that the price of these trades isn't counted towards market statistics.

Databento normalizes system priced legs as a Trade record with side equal to N and an UNDEF_PRICE (0x7fffffffffffffff, 9223372036854775808) value for the price.

These trades are counted towards OHLCV volume, but not towards the open, high, low or close values. This means that OHLCV messages can have some (or even all) price values as UNDEF_PRICE.

Off-market trades

Trades marked by the exchange as off-market have their publisher_id set to NDEX.IMPACT.XOFF to distinguish them from on-exchange trades.

This distinction is also reflected on the OHLCV schemas - if an interval contains both on-market and off-market trades for an instrument, two OHLCV messages will be published for that instrument on that interval, one with NDEX.IMPACT.NDEX as the publisher_id and one with NDEX.IMPACT.XOFF.

Statistics

Stat flags

The IsOfficial field in the ICE iMpact Settlement Price Message and IsSettlePriceOfficial in the Market Snapshot Message are normalized to the first (least-significant) bit of stat_flags where the bit is set if IsOfficial is Y. This is consistent with the behavior for CME Globex MDP 3.0.

Symbology

ICE uses separate symbology for outrights and strategies.

Outrights

For outrights — individual futures and options — raw symbols are sourced from ContractSymbol field. If ContractSymbolExtra is present, it's appended to the ContractSymbol.

Outright contract symbols are composed of several parts indicating different aspects of the instrument. For example, the Dutch TTF Natural Gas August 2024 futures contract's symbol is TFM FMQ0024!. This can be broken down as follows:

Options begin with their underlying future's symbol followed by an underscore (_) and the option block. Using the Dutch TTF Natural Gas August 2024 87.00 call TFO FMQ0024_OMCE0000045002072624 as an example, the option block breaks down as:

Refer to ICE's Instrument Naming Convention document for a full explanation of the format of contract symbols. Because each dataset has a separate symbology namespace, Databento omits the MIC code from the fully-qualified symbol in ICE's examples.

Spots

Endex spots have neither a ContractSymbol nor a StrategySymbol, instead raw symbols are sourced from MarketDesc.

Strategies

For spreads and strategies where ICE does not define a ContractSymbol, raw symbols are sourced from `StrategySymbol``.

Strategy symbols are composed of several parts, however, due to the use of numeric identifiers, strategy raw symbols are harder to interpret than those for outrights. The Dutch TTF Natural Gas year calendar strip TFO 800 108281469 can be broken down as follows:

Definitions

• MarketTypeId is normalized to market_segment_id
• MICCode is normalized to exchange when it is provided: only for futures and future strategies

Expirations

ICE only provides date-granularity expiration data in OptionsExpirationDate and ScreenLastTrade fields. As a result, the expiration field in the definition schema will always be at UTC midnight, even when the option expires during or after the trading day.

ICE Europe Commodities iMpact

ICE disseminates FOD (full order depth), MBP (market by price), TOB (top-of-book) and market statistics data for futures and options on futures via their iMpact feed, which Databento receives over UDP multicast in our Aurora DC3 data center.

For futures, ICE publishes both FOD and MBP-5. Databento only normalizes the FOD messages. For options, ICE publishes MBP-10, MBP-5 and top-of-book. Databento only normalizes the MBP-10 messages.

This means that for options, only the top 10 levels of the book are available even in the MBO schema. For futures the full market is shown.

Timestamps

ICE iMpact messages received by Databento will generally include two timestamps with microsecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

ICE provides microsecond granularity timestamps along with sub-microsecond sequence numbers for ordering that are normalized as nanosecond timestamps for consistency in ordering with other datasets.

More details about our timestamps are available in our timestamping guide.

Matching Engine Location

ICE Europe Commodities has matching engines both in Chicago and Basildon. Currently, the products offered by Databento all trade in the ICE silo, located in 350 E Cermak, Chicago. Databento captures the data in our Aurora DC3 location.

MBO normalization

For options, the ICE iMpact feed only includes market-by-price, which matches Databento's MBP-10 schema. We do not offer these messages in our MBO schema. They are only available on MBP-10 and other downstream schemas.

Each ICE "Trade Message" is normalized into a single MBO record with the Trade action, and the message's "TradeID" field is used as the order_id. ICE does not disseminate information about the passive side of the trade. The corresponding Fill record will have side equal to N and the same order_id value as the Trade record.

When ICE does not specify the aggressing side, Trade records will have side equal to N.

System priced legs

A system priced leg is the result of a trade in the outright spread. These trades, as published by the exchange, can have prices that are 10% or more off from the best bid and offer. ICE recommends that the price of these trades isn't counted towards market statistics.

Databento normalizes system priced legs as a Trade record with side equal to N and an UNDEF_PRICE (0x7fffffffffffffff, 9223372036854775808) value for the price.

These trades are counted towards OHLCV volume, but not towards the open, high, low or close values. This means that OHLCV messages can have some (or even all) price values as UNDEF_PRICE.

Off-market trades

Trades marked by the exchange as off-market have their publisher_id set to IFEU.IMPACT.XOFF to distinguish them from on-exchange trades.

This distinction is also reflected on the OHLCV schemas - if an interval contains both on-market and off-market trades for an instrument, two OHLCV messages will be published for that instrument on that interval, one with IFEU.IMPACT.IFEU as the publisher_id and one with IFEU.IMPACT.XOFF.

Statistics

Stat flags

The IsOfficial field in the ICE iMpact Settlement Price Message and IsSettlePriceOfficial in the Market Snapshot Message are normalized to the first (least-significant) bit of stat_flags where the bit is set if IsOfficial is Y. This is consistent with the behavior for CME Globex MDP 3.0.

Symbology

ICE uses separate symbology for outrights and strategies.

Outrights

For outrights — individual futures and options — raw symbols are sourced from ContractSymbol field. If ContractSymbolExtra is present, it's appended to the ContractSymbol.

Outright contract symbols are composed of several parts indicating different aspects of the instrument. For example, the Brent August 2024 futures contract's symbol is BRN FMQ0024!. This can be broken down as follows:

Options begin with their underlying future's symbol followed by an underscore (_) and the option block. Using the Brent August 2024 87.00 call BRN FMQ0024_OMCA0000087002062524 as an example, the option block breaks down as:

Refer to ICE's Instrument Naming Convention document for a full explanation of the format of contract symbols. Because each dataset has a separate symbology namespace, Databento omits the MIC code from the fully-qualified symbol in ICE's examples.

Strategies

For spreads and strategies where ICE does not define a ContractSymbol, raw symbols are sourced from `StrategySymbol``.

Strategy symbols are composed of several parts, however, due to the use of numeric identifiers, strategy raw symbols are harder to interpret than those for outrights. The Brent options iron condor BRN 40 30775617 can be broken down as follows:

Databento MBO snapshot

ICE Europe Commodities iMpact daily trading hours cross 00:00:00 UTC. To make it easier to work with historical MBO data, Databento includes an order book snapshot at 00:00:00 UTC each weekday (Monday-Friday).

Definitions

• MarketTypeId is normalized to market_segment_id
• MICCode is normalized to exchange when it is provided: only for futures and future strategies

Expirations

ICE only provides date-granularity expiration data in OptionsExpirationDate and ScreenLastTrade fields. As a result, the expiration field in the definition schema will always be at UTC midnight, even when the option expires during or after the trading day.

ICE Europe Financials iMpact

ICE disseminates FOD (full order depth), MBP (market by price), TOB (top-of-book) and market statistics data for futures and options on futures via their iMpact feed, which Databento receives over UDP multicast in our Aurora DC3 data center.

For futures, ICE publishes both FOD and MBP-5. Databento only normalizes the FOD messages. For options, ICE publishes MBP-10, MBP-5 and top-of-book. Databento only normalizes the MBP-10 messages.

This means that for options, only the top 10 levels of the book are available even in the MBO schema. For futures the full market is shown.

Timestamps

ICE iMpact messages received by Databento will generally include two timestamps with microsecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

ICE provides microsecond granularity timestamps along with sub-microsecond sequence numbers for ordering that are normalized as nanosecond timestamps for consistency in ordering with other datasets.

More details about our timestamps are available in our timestamping guide.

Matching Engine Location

ICE Europe Financials has matching engines both in Chicago and Basildon. Currently, the products offered by Databento all trade in the ICE silo, located in 350 E Cermak, Chicago. Databento captures the data in our Aurora DC3 location.

MBO normalization

For options, the ICE iMpact feed only includes market-by-price, which matches Databento's MBP-10 schema. We do not offer these messages in our MBO schema. They are only available on MBP-10 and other downstream schemas.

Each ICE "Trade Message" is normalized into a single MBO record with the Trade action, and the message's "TradeID" field is used as the order_id. ICE does not disseminate information about the passive side of the trade. The corresponding Fill record will have side equal to N and the same order_id value as the Trade record.

When ICE does not specify the aggressing side, Trade records will have side equal to N.

System priced legs

A system priced leg is the result of a trade in the outright spread. These trades, as published by the exchange, can have prices that are 10% or more off from the best bid and offer. ICE recommends that the price of these trades isn't counted towards market statistics.

Databento normalizes system priced legs as a Trade record with side equal to N and an UNDEF_PRICE (0x7fffffffffffffff, 9223372036854775808) value for the price.

These trades are counted towards OHLCV volume, but not towards the open, high, low or close values. This means that OHLCV messages can have some (or even all) price values as UNDEF_PRICE.

Off-market trades

Trades marked by the exchange as off-market have their publisher_id set to IFLL.IMPACT.XOFF to distinguish them from on-exchange trades.

This distinction is also reflected on the OHLCV schemas - if an interval contains both on-market and off-market trades for an instrument, two OHLCV messages will be published for that instrument on that interval, one with IFLL.IMPACT.IFLL as the publisher_id and one with IFLL.IMPACT.XOFF.

Statistics

Stat flags

The IsOfficial field in the ICE iMpact Settlement Price Message and IsSettlePriceOfficial in the Market Snapshot Message are normalized to the first (least-significant) bit of stat_flags where the bit is set if IsOfficial is Y. This is consistent with the behavior for CME Globex MDP 3.0.

Symbology

ICE uses separate symbology for outrights and strategies.

Outrights

For outrights — individual futures and options — raw symbols are sourced from ContractSymbol field. If ContractSymbolExtra is present, it's appended to the ContractSymbol.

Outright contract symbols are composed of several parts indicating different aspects of the instrument. For example, the Three Month Euribor June 2025 futures contract's symbol is I FMM0025!. This can be broken down as follows:

Options begin with their underlying future's symbol followed by an underscore (_) and the option block. Using the Three Month Euribor June 2025 87.00 call I FMM0025_OMCA0009793754061625 as an example, the option block breaks down as:

Refer to ICE's Instrument Naming Convention document for a full explanation of the format of contract symbols. Because each dataset has a separate symbology namespace, Databento omits the MIC code from the fully-qualified symbol in ICE's examples.

Strategies

For spreads and strategies where ICE does not define a ContractSymbol, raw symbols are sourced from `StrategySymbol``.

Strategy symbols are composed of several parts, however, due to the use of numeric identifiers, strategy raw symbols are harder to interpret than those for outrights. The Three Month Euribor options call spread I 6 20284553 can be broken down as follows:

Databento MBO snapshot

ICE Europe Financials iMpact daily trading hours cross 00:00:00 UTC. To make it easier to work with historical MBO data, Databento includes an order book snapshot at 00:00:00 UTC each weekday (Monday-Friday).

Definitions

• MarketTypeId is normalized to market_segment_id
• MICCode is normalized to exchange when it is provided: only for futures and future strategies

Expirations

ICE only provides date-granularity expiration data in OptionsExpirationDate and ScreenLastTrade fields. As a result, the expiration field in the definition schema will always be at UTC midnight, even when the option expires during or after the trading day.

ICE Futures US iMpact

ICE disseminates FOD (full order depth), MBP (market by price), TOB (top-of-book) and market statistics data for futures and options on futures via their iMpact feed, which Databento receives over UDP multicast in our Aurora DC3 data center.

For futures, ICE publishes both FOD and MBP-5. Databento only normalizes the FOD messages. For options, ICE publishes MBP-10, MBP-5 and top-of-book. Databento only normalizes the MBP-10 messages.

This means that for options, only the top 10 levels of the book are available even in the MBO schema. For futures the full market is shown.

Timestamps

ICE iMpact messages received by Databento will generally include two timestamps with microsecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

ICE provides microsecond granularity timestamps along with sub-microsecond sequence numbers for ordering that are normalized as nanosecond timestamps for consistency in ordering with other datasets.

More details about our timestamps are available in our timestamping guide.

MBO normalization

For options, the ICE iMpact feed only includes market-by-price, which matches Databento's MBP-10 schema. We do not offer these messages in our MBO schema. They are only available on MBP-10 and other downstream schemas.

Each ICE "Trade Message" is normalized into a single MBO record with the Trade action, and the message's "TradeID" field is used as the order_id. ICE does not disseminate information about the passive side of the trade. The corresponding Fill record will have side equal to N and the same order_id value as the Trade record.

When ICE does not specify the aggressing side, Trade records will have side equal to N.

System priced legs

A system priced leg is the result of a trade in the outright spread. These trades, as published by the exchange, can have prices that are 10% or more off from the best bid and offer. ICE recommends that the price of these trades isn't counted towards market statistics.

Databento normalizes system priced legs as a Trade record with side equal to N and an UNDEF_PRICE (0x7fffffffffffffff, 9223372036854775808) value for the price.

These trades are counted towards OHLCV volume, but not towards the open, high, low or close values. This means that OHLCV messages can have some (or even all) price values as UNDEF_PRICE.

Off-market trades

Trades marked by the exchange as off-market have their publisher_id set to IFUS.IMPACT.XOFF to distinguish them from on-exchange trades.

This distinction is also reflected on the OHLCV schemas - if an interval contains both on-market and off-market trades for an instrument, two OHLCV messages will be published for that instrument on that interval, one with IFUS.IMPACT.IFUS as the publisher_id and one with IFUS.IMPACT.XOFF.

Statistics

Stat flags

The IsOfficial field in the ICE iMpact Settlement Price Message and IsSettlePriceOfficial in the Market Snapshot Message are normalized to the first (least-significant) bit of stat_flags where the bit is set if IsOfficial is Y. This is consistent with the behavior for CME Globex MDP 3.0.

Symbology

ICE uses separate symbology for outrights and strategies.

Outrights

For outrights — individual futures and options — raw symbols are sourced from ContractSymbol field. If ContractSymbolExtra is present, it's appended to the ContractSymbol.

Outright contract symbols are composed of several parts indicating different aspects of the instrument. For example, the Sugar No. 11 July 2025 futures contract's symbol is SB FMN0025!. This can be broken down as follows:

Options begin with their underlying future's symbol followed by an underscore (_) and the option block. Using the Sugar No. 11 October 2025 _____ put SB FMV0025_OMPA0000011002091525 as an example, the option block breaks down as:

Refer to ICE's Instrument Naming Convention document for a full explanation of the format of contract symbols. Because each dataset has a separate symbology namespace, Databento omits the MIC code from the fully-qualified symbol in ICE's examples.

Strategies

For spreads and strategies where ICE does not define a ContractSymbol, raw symbols are sourced from `StrategySymbol``.

Strategy symbols are composed of several parts, however, due to the use of numeric identifiers, strategy raw symbols are harder to interpret than those for outrights. The Sugar No. 11 options diagonal put spread SB 10 30951651 can be broken down as follows:

Databento MBO snapshot

ICE Futures US iMpact daily trading hours cross 00:00:00 UTC. To make it easier to work with historical MBO data, Databento includes an order book snapshot at 00:00:00 UTC each weekday (Monday-Friday).

Definitions

• MarketTypeId is normalized to market_segment_id
• MICCode is normalized to exchange when it is provided: only for futures and future strategies

Expirations

ICE only provides date-granularity expiration data in OptionsExpirationDate and ScreenLastTrade fields. As a result, the expiration field in the definition schema will always be at UTC midnight, even when the option expires during or after the trading day.

IEX TOPS

IEX disseminates top-of-book and trade information for its US equities exchange through their IEX TOPS feed over the IEX-TP v1 protocol, which Databento receives over UDP multicast in our NY4 data center.

PDF specifications are available through IEX's website for IEX TOPS and IEX-TP v1.

Info

The Databento team is currently working on this article.

Timestamps

IEX TOPS messages received by Databento will generally include two timestamps with nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

More details about our timestamps are available in our timestamping guide.

MBO normalization

The IEX TOPS feed only includes top-of-book and trades, which matches Databento's MBP-1 schema. However, we do also offer these messages normalized into our MBO schema for consistency with other datasets with the caveat that some details are not made available by the upstream IEX TOPS feed.

Each IEX "Quote Update Message" is normalized into a pair of MBO records, as described in the conventions for top-of-book datasets.

Each IEX "Trade Report Message" is normalized into a single MBO record with the Trade action, and the message's "Trade ID" field is used as the order_id. There is no information exposed about the aggressing or passive sides of the order so side will always be set to None and no F records are emitted.

MEMX Memoir

MEMX disseminates full depth-of-book data for their exchange through their MEMOIR Depth Feed, which Databento receives over UDP multicast in our NY4 data center.

The MEMX Depth Feed Client Specifications are available from MEMX's website.

Info

The Databento team is currently working on this article.

Timestamps

MEMX messages received by Databento include one timestamp with nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server. MEMX does not include an exchange send timestamp, thus ts_in_delta field is set to 0 for all messages.

More details about our timestamps are available in our timestamping guide.

MIAX Depth of Market

MIAX disseminates full depth-of-book information for MIAX Pearl Equities through the Miax Pearl Equities Depth of Market Feed (DoM) over the MACH protocol, which Databento receives over UDP multicast in our NY4 data center.

PDF specifications are available through MIAX's website for Depth of Market and MACH.

Info

The Databento team is currently working on this article.

Timestamps

MIAX DoM messages received by Databento have at most one timestamp, which has nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

The extra field ts_in_delta does not convey any additional information for this dataset, and is equivalent to ts_recv - ts_event.

More details about our timestamps are available in our timestamping guide.

Nasdaq Basic with NLS Plus

Nasdaq disseminates top-of-book data via their QBBO feed, and last sale data via their NLS and NLS+ feeds. Databento receives these over UDP multicast in our NY4 data center. Because they come from separate feeds, BBO and trade events may be out-of-order, even within a single instrument.

PDF specifications are available on Nasdaq's website for the QBBO, NLS and NLS+ feeds.

Timestamps

Nasdaq Basic messages received by Databento have at most one timestamp, which has nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

The extra field ts_in_delta does not convey any additional information for this dataset, and is equivalent to ts_recv - ts_event.

More details about our timestamps are available in our timestamping guide.

Source feeds

Nasdaq Basic is composed of data from the Nasdaq QBBO and Nasdaq NLS+ feeds.

Venues

Nasdaq Basic contains trade data for the following venues:

• Nasdaq (XNAS)
• Nasdaq BX (XBOS)
• Nasdaq PSX (XPSX)
• FINRA/Nasdaq TRF Carteret (FINN)
• FINRA/Nasdaq TRF Chicago (FINC)

However, only quotes for Nasdaq (XNAS) are provided.

The publisher_id field on every record from Databento can be used to identify the venue associated with the event.

Because Nasdaq BX, Nasdaq PSX and the TRF facilities do not have a BBO disseminated by Nasdaq QBBO, the MBP-1, BBO and TBBO schemas are not available. Instead, the equivalent consolidated schemas are provided: CMBP-1, CBBO and TCBBO.

Normalization

There are only Add and Trade actions for Nasdaq Basic.

Trade records are normalized from NLS+ Trade Report for Non-NextShares or Long form Trade Report for Non-NextShares messages. The publisher_id field will identify the venue associated with the trade. There is no information about the side of the trade, so side will always be N.

Add records are normalized from Nasdaq QBBO Quotation Message. An A record will be published anytime the best bid or offer quote is updated. The publisher_id field will always be set to 93 (XNAS_BASIC_EQUS)

Definition normalization

Definition records are sourced from NLS+ Stock Directory messages.

Statistics normalization

Statistics records are sourced from NLS+ Trade Report for Non-NextShares messages. Databento provides the opening price and closing price statistics based on the sale condition field of these trade messages.

Nasdaq TotalView-ITCH

Nasdaq disseminates full depth-of-book data for their exchange through their TotalView-ITCH feed over the MoldUDP64 protocol, which Databento receives over UDP multicast in our NY4 data center.

PDF specifications are available on Nasdaq's website for Nasdaq TotalView-ITCH and MoldUDP64.

Info

The Databento team is currently working on this article.

Timestamps

Nasdaq TotalView-ITCH messages received by Databento have at most one timestamp, which has nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

The extra field ts_in_delta does not convey any additional information for this dataset, and is equivalent to ts_recv - ts_event.

More details about our timestamps are available in our timestamping guide.

MBO normalization

Order lifecycle messages

There are seven message types in TotalView that change the state of the order book. Databento normalizes these messages to MBO records as follows:

• Add Order - No MPID Attribution: Add
• Add Order with MPID Attribution: Add, but the attribution field is not included
• Order Executed: Trade, Fill, then Cancel
• Order Executed with Price: Trade, Fill, then Cancel, but the initial Trade is omitted if the message is marked as non-printable
• Order Cancel: Cancel, with the quantity indicating the number of shares to remove from the display size
• Order Delete: Cancel, with the quantity indicating the current display size of the order
• Order Replace: Cancel with the previous order_id, followed by Add with the new order_id

All Trade records will have order_id set to 0, because Nasdaq does not provide information about the aggressor's order. Normalized records from the same TotalView message will have the same sequence.

Trade messages

TotalView also has two messages for providing execution details for match events against non-displayed orders or cross events.

Databento normalizes both Trade (Non-Cross) and Cross Trade messages is into a single MBO Trade record with side None.

Nasdaq will always send a Cross Trade message following an opening, closing, or EMC cross event for an instrument. If no shares are exchanged during a cross event, quantity will be 0 and price will be UNDEF_PRICE (0x7fffffffffffffff, 9223372036854775808).

Statistics normalization

Databento provides Opening Price, Closing Price and Uncrossing Price statistics, normalized from the Cross Trade message. These statistics have the auction uncrossing price and quantity for the respective event.

Imbalance normalization

TotalView provides information about opening and closing cross imbalances in their Net Order Imbalance Indicator (NOII) message. Databento normalizes each message into a record in the imbalance schema.

Definition normalization

Definition records are sourced from Stock Directory messages.

NYSE American Integrated

NYSE American disseminates full depth-of-book data for their exchange through their Integrated Feed, which Databento receives over UDP multicast in our NY4 data center.

The Integrated Feed Client Specification is available as a PDF from NYSE's website.

Info

The Databento team is currently working on this article.

Timestamps

NYSE American messages received by Databento will generally include two timestamps with nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

More details about our timestamps are available in our timestamping guide.

Statistics

Databento provides Opening Price, Closing Price and Uncrossing Price statistics, normalized from the Cross Trade message. These statistics have the auction uncrossing price and quantity for the respective event.

Imbalance normalization

NYSE American provides information about opening and closing cross imbalances in their Imbalance message. Databento normalizes each message into a record in the imbalance schema.

NYSE Arca Integrated

NYSE Arca disseminates full depth-of-book data for their exchange through their Integrated Feed, which Databento receives over UDP multicast in our NY4 data center.

The Integrated Feed Client Specification is available as a PDF from NYSE's website.

Info

The Databento team is currently working on this article.

Timestamps

NYSE Arca messages received by Databento will generally include two timestamps with nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

More details about our timestamps are available in our timestamping guide.

Statistics

Databento provides Opening Price, Closing Price and Uncrossing Price statistics, normalized from the Cross Trade message. These statistics have the auction uncrossing price and quantity for the respective event.

Imbalance normalization

NYSE Arca provides information about opening and closing cross imbalances in their Imbalance message. Databento normalizes each message into a record in the imbalance schema.

NYSE Texas Integrated

NYSE Texas disseminates full depth-of-book data for their exchange through their Integrated Feed, which Databento receives over UDP multicast in our NY4 data center.

The Integrated Feed Client Specification is available as a PDF from NYSE's website.

Info

The Databento team is currently working on this article.

Timestamps

NYSE Texas messages received by Databento will generally include two timestamps with nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

More details about our timestamps are available in our timestamping guide.

Imbalance normalization

NYSE Texas provides information about opening and closing cross imbalances in their Imbalance message. Databento normalizes each message into a record in the imbalance schema.

NYSE National Trades and BBO

NYSE National disseminates top-of-book and last sale data through their BBO and Trades feeds, respectively. Databento receives these over UDP multicast in our NY4 data center. Because they come from separate feeds, BBO and trade events may be out-of-order, even within a single instrument.

PDF specifications are available on NYSE's website for the BBO and Trades feeds.

Info

The Databento team is currently working on this article.

Timestamps

NYSE National messages received by Databento will generally include two timestamps with nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

More details about our timestamps are available in our timestamping guide.

MBO normalization

NYSE National Trades and BBO are sourced from two separate feeds: one for the BBO and one for trades. When combined, this level of data matches Databento's MBP-1 schema; however, unlike most other datasets, there is not a strict ordering between the events on the BBO feed and the Trades feed. We also offer these messages normalized into our MBO schema for consistency with other datasets with the caveat that some details are not made available by the upstream NYSE National feeds.

Each BBO "Quote Message (140)" is normalized into a pair of MBO records, as described in the conventions for top-of-book datasets.

Each Trades "Trade Message (220)" is normalized into a single MBO record with the Trade action, and the message's "Trade ID" field is used as the order_id. There is no information exposed about the passive side of the order, so there are no Fill records.

NYSE Integrated

NYSE disseminates full depth-of-book data for their exchange through their Integrated Feed, which Databento receives over UDP multicast in our NY4 data center.

The Integrated Feed Client Specification is available as a PDF from NYSE's website.

Info

The Databento team is currently working on this article.

Timestamps

NYSE messages received by Databento will generally include two timestamps with nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server.

More details about our timestamps are available in our timestamping guide.

Statistics

Databento provides Opening Price, Closing Price and Uncrossing Price statistics, normalized from the Cross Trade message. These statistics have the auction uncrossing price and quantity for the respective event.

Imbalance normalization

NYSE provides information about opening and closing cross imbalances in their Imbalance message. Databento normalizes each message into a record in the imbalance schema.

OPRA Pillar

OPRA disseminates top-of-book, last sale, and daily statistics data for all US equity options exchanges through their Binary Output feed, which Databento receives over UDP multicast in our NY4 data center.

The OPRA Pillar Output Specification is available as a PDF from the OPRA website.

Timestamps

OPRA messages received by Databento include at most one timestamp, which has nanosecond precision. As with all of our datasets, we also collect a ts_recv timestamp when the packet was received by our capture server. The unused ts_in_delta field is set to 0 for all messages.

More details about our timestamps are available in our timestamping guide.

Venues

OPRA includes consolidated data for 18 options venues (as of March 2025). The publisher_id field on every record from Databento can be used to identify the venue associated with a trade event.

Info

These mappings are also available programmatically through the metadata.list_publishers endpoint.

CMBP-1

Along with the 18 options venues, OPRA also publishes the OPRA consolidated BBO. This consolidated BBO is available through Databento as the CMBP-1 schema. OPRA generates this consolidated BBO based on the following criteria in this order:

• Price: Venues with the highest bid and lowest offer have overall priority. Minimum price increments must be at least 1 cent higher or lower than the previous price.
• Size: Largest size takes precedence when multiple venues submit the same bid and/or offer price. There are no initial minimum size requirements. Size increments must be 10 contracts or better than the previous size.
• Time: Earliest time takes precedence when multiple venues submit the same bid and/or offer price with the same size.

See also

More information on the OPRA consolidated BBO can be found in the OPRA BBO Guidelines FAQ

OPRA consolidated BBO records are published with a publisher_id value of 30 (OPRA_PILLAR_OPRA). These records indicate the venues containing the best bid and best offer by including their respective publisher_id in the bid_pb_00 and ask_pb_00 fields.

Trade records are published with the publisher_id corresponding to the venue where the trade happened.

Databento does not publish BBO records for regional quotes.

See also

Examples - US equity options volume by venue

Historical CMBP-1 requests

Due to the large quantity of data for the CMBP-1 schema, we recommend users request a batch download via batch.submit_job or the User portal.

Symbology

OPRA Pillar raw symbols are based on OCC symbology, also known as Options Symbology Initiative (OSI) symbology. These two terms are interchangeable.

In OCC symbology, every raw symbol has exactly 21 characters and is composed of four parts. Using the SPY November 17, 2023 $486.00 put option (SPY 231117P00486000) as an example, these are:

Expirations

OPRA only provides date-granularity expiration data so the expiration field in the definition schema will always be at UTC midnight even when the option expires during or after the trading day.

Data prior to 2023-02-28

Data prior to 2023-02-28 was not generated from OPRA packet captures, but from subsampled data. This leads to the following differences on the data for those dates:

• The cmbp-1, cbbo-1s and tcbbo schemas are not available. The highest granularity available for BBO data is the cbbo-1m schema.
• Due to not being generated from packet captures, the ts_recv field has the event timestamp, and F_BAD_TS_RECV is always set.
• The bid_pb_00 and ask_pb_00 fields do not contain the venue which is showing the NBBO.
• The statistics schema only has information for Open Interest, which is published on an aggregated basis.

Corporate actions

The corporate actions dataset includes coverage from 215 exchanges worldwide, 310,000+ listed and delisted securities from 85,000+ companies, categorized as 60+ event types. The dataset focuses on crucial events affecting global securities such as dividends, takeovers, mergers & acquisitions and rights issues.

Each record represents a unique corporate actions event at the listing level.

• History. From to 2018-05-01 to present.
• Coverage. Global.
• Update frequency. 4x per day.
• Listing level. All records are maintained at the listing level, which means each individual listing for a security has its own set of records.
• Delisting and relisting. The system continues to track securities even after they have been delisted. This is crucial because securities are occasionally relisted, so maintaining a continuous record prevents gaps in the time series thus avoiding ambiguity.

See also

Corporate actions field descriptions for further details.

Securities and listings

A security is a fungible, tradable financial asset listed on regulated exchanges. Each security has a primary exchange listing and may be listed on multiple secondary exchanges. The corporate actions dataset utilizes a security_id to associate these various listings.

Each public listing is identified by a unique listing_id that links together a series of point-in-time (PIT) records. The records are ordered by the event_date and ts_record timestamp.

A listing_group_id groups all listings for the same security on a specific exchange, including secondary listings such as those in different trading currencies.

Events

Corporate actions can be broadly categorized into three types of events at both the security and listing levels:

• General events. Announcements, company meetings, lawsuits/class actions, listing status changes, incorporation change, security description change, etc.
• Capital change events. Mergers, stock splits / reverse stock splits, return of capital, franking, liquidation, divestments, dividends, currency redenomination, etc.
• Exchange events. New listing, security reclassification, security swap, preferential offer, etc.

The event field categorizes the type of corporate action and is the primary field for filtering and categorizing events at a granular level. Event records can be paired with an event_id, which links associated events, such as all payment rows.

The top ten event types are listed in descending order based on their frequency of occurrence, see the EVENT enum lookup table for possible values.

Event subtypes

The event_subtype field is only used for a limited number of events which fall into distinct sub-groupings, see the EVENTSUBTYPE enum lookup table for possible values.

Security types

The top ten security types covered are listed in descending order based on their frequency of occurrence, see the SECTYPE enum lookup table for possible values.

Exchange coverage

The corporate actions dataset has coverage across 220+ exchanges worldwide.

• primary_exchange specifies the primary exchange for the security associated with the event.
• exchange field specifies the exchange for the listing and can be filtered by specifying a dataset.
• operating_mic field specifies the ISO 10383 MIC of the listing exchange associated with the event.

See the EXCHANGE enum lookup table for possible values.

Tip

The operating_mic field will match the venue from the listed publishers and the Definition schema exchange field, which is an ISO 10383 Market Identifier Code (MIC).

Listing continuity

The listing_id and security_id have continuity with changes to the underlying security in the following scenarios:

• Name changes. Issuer name changes which result in a ticker symbol change (e.g. Facebook: FB -> Meta Platforms: META).
• Mergers. Either where the company operates under a new name, or one of the original company names.
• Demergers. Either where the companies operate under new names, or one keeps the original company name.

The listing_id and security_id do NOT have continuity in the following scenarios:

• Spin-offs. When the parent company continues operating, the spun-off companies become new listings.
• Delistings. When the security is never relisted.

Point-in-time (PIT) corporate actions

The corporate_actions.get_range endpoint provides a time series of point-in-time (PIT) records for the queried symbols and events. This is ideal for research or backtesting where it’s crucial to include records as they were known at specific points in time. Note that, like other APIs, the time ranges have an exclusive end.

The Python client library offers a pit parameter to control record retention:

• If True: All historical records for each event_unique_id will be retained, preserving the complete point-in-time history.
• If False (default): The DataFrame will include only the most recent record for each event_unique_id, based on the ts_record timestamp.

Split and restructuring events

The corporate actions dataset includes normalization of several stock restructuring events, such as splits, spin-offs, and demergers, as shown in the following table:

Payment ratios

For FSPLT, DIV, and BON events, the ratio_new includes the existing holdings. As a result, some reported ratios may differ from the actual figures in official announcements.

Adjustment factors

The adjustment factors dataset covers global corporate actions capital events, spanning multiple currencies for the same event. Each record includes all necessary fields to identify the country, security, event, and adjustment factor.

Each record represents a unique capital event at the listing level.

• History. From to 2018-05-01 to present.
• Coverage. Global.
• Update frequency. Daily.

The primary use case for this dataset is to back-adjust end-of-day (EOD) per-share price data, allowing the price series to be graphed with the effects of various events (e.g., bonus issues, rights issues, consolidations) factored into earlier prices. Individual events can receive multiple updates both prior to and after the ex-date, seamlessly accounting for potentially messy corporate actions, changes, and cancellations.

All per-share series, including prices, earnings-per-share, dividends-per-share, assets-per-share, cash-flow-per-share, etc., need to be adjusted before meaningful conclusions can be drawn about growth rates and trends.

See also

Adjustment factors field descriptions for further details.

Exchange coverage

The adjustment factors dataset has coverage across 215 exchanges worldwide.

• primary_exchange specifies the primary exchange for the security associated with the adjustment factor event.
• operating_mic field specifies the ISO 10383 MIC of the listing exchange associated with the event.

See the EXCHANGE enum lookup table for possible values.

Tip

The operating_mic field will match the venue from the listed publishers and the Definition schema exchange field, which is an ISO 10383 Market Identifier Code (MIC).

Security continuity

The security_id maintains continuity in the following scenarios:

• Name changes. Issuer name changes which result in a ticker symbol change (e.g. Facebook: FB -> Meta Platforms: META).
• Mergers. Either where the company operates under a new name, or one of the original company names.
• Demergers. Either where the companies operate under new names, or one keeps the original company name.

The security_id do not have continuity in the following scenarios:

• Spin-offs. When the parent company continues operating (the spun on companies are new securities).
• Delistings. When the security is never relisted.

Timing

The first generation of pending factors for a particular ex-date will happen close of market the day before the ex-date.

Adjustment factors are provided on the ex-date of the event, except:

• When the corporate action is incomplete (missing core fields such as "Ratio New", etc.) in which case the factor will be provided as soon as the corporate action becomes complete after the ex-date.
• Or, the factor calculation requires the open price of a security that has not traded yet in which case a factor will be generated after the security trades.

Reason codes

Each record has a reason code which distinguishes between different event types.

Status codes

Included with each record is a single character status code which indicates how the adjustment should be handled.