MBP vs MBO vs MBO+: Futures Market Data Types Explained

The main data types: trades, quotes, depth and bars

Start with the question you need the data to answer. Trade records describe executions. Quotes describe available prices and quantities. A depth feed adds information beyond the best prices. OHLCV bars summarize activity over an interval, but they cannot preserve every change that occurred inside it. Reference data supplies essentials such as the instrument and tick size.

Databento’s schema documentation separates top-of-book, market-depth and order-level representations, alongside trades and bars. Naming conventions differ among vendors, so use the actual fields and coverage as your guide rather than assuming every Level 2 or Level 3 package is equivalent.

Reference: Databento: market-data schemas and levels

• Level 1 / top of book: the best displayed bid and ask, with fields depending on the product.
• Level 2 / price-level depth: aggregate quantity across available price levels.
• MBO / order-level data: anonymous order records and updates supplied by the venue or provider.
• Trades / time and sales: reported executions, potentially with direction information.
• OHLCV bars: interval summaries useful for charts, not a full event history.

MBP: a price-level view of the book

Market by Price combines displayed orders at the same price into a level. This is useful for a DOM or heatmap because it tells you how much displayed quantity is available at each price in the supplied depth range. It does not, by itself, identify which individual order changed.

Consider an illustrative bid at 100.00 with three orders of 4, 7 and 9 contracts. A price-level view can show 20 contracts at that price. If it later shows 15, you know the aggregate decreased by five. You cannot infer the exact sequence of changes to the three orders solely from those two totals.

MBO: individual anonymous orders before aggregation

CME describes MBO as order-based data with anonymous identifiers and priority information, in contrast with price-level totals. Individual-order updates can support a more detailed reconstruction of displayed book composition. They do not disclose customer identities or make all hidden quantity visible.

This richer representation is useful upstream even if a terminal ultimately displays a familiar price ladder. Keeping individual changes while rebuilding the book lets the system update the affected orders first and then calculate totals. The user-facing view can remain readable while the source model retains the information needed for those updates.

Reference: CME Group: Market by Order overview

Why EdgeX uses Rithmic MBO for connected depth

The current EdgeX backend requests Rithmic depth-by-order snapshots and updates. It maintains anonymous order records, processes changes and derives price-level quantities and order counts for the terminal. Rithmic publicly lists MBO among its market-data capabilities; availability for a session still depends on the actual environment, instrument and entitlements.

The benefit is a defined reconstruction process rather than interpreting an unexplained aggregate change as a specific order event. EdgeX checks snapshot consistency, rejects invalid order changes and attempts bounded resynchronization when the book becomes inconsistent. While MBO is unavailable, the current depth path pauses rather than silently substituting a different source.

These are implementation choices that support understandable data handling. They do not prove a particular latency, universal exchange coverage or guaranteed continuity. Check the visible session status instead of assuming that a provider’s general capability means every connected account has that data.

Reference: Rithmic: market-data technology

What does MBO+ mean?

The exchange and provider references linked here define MBO; they do not establish a universal MBO+ schema. A plus label therefore needs an explicit definition from the product using it. It might describe additional processing or tools, but the name alone does not prove extra exchange fields, hidden liquidity, complete queue reconstruction or better execution.

For EdgeX, the verified distinction is MBO at the connected source and processed views in the application: reconstructed depth, DOM, Heatmap and documented order-flow measurements. Evaluate those concrete capabilities. A claim about an additional MBO+ service should identify its provider, fields, coverage and delivery behavior before it is treated as a separate data standard.

MBO at the source does not make every panel an order-level feed

The browser receives aggregated depth views, and display updates can be coalesced. Retained heatmap history is sampled depth rather than a complete replay of every order event. The current Order Flow detectors compare captured quantities and reported executions; they do not receive the individual-order identity needed to prove native iceberg ownership or remaining reserve.

This explains why the source can be MBO while an iceberg marker still says candidate. The source, transport, history and analytical view are different stages. Information available in one stage is not automatically exposed in every other stage.

Choose data by the workflow you need

For basic price context, quotes and bars may answer the question. For depth comparison, verify levels and freshness. For delta, verify execution coverage and aggression classification. For order-level research, ask whether identifiers and event updates survive the entire path into the analytical tool. More detailed source data is useful only when the relevant information reaches the task.

In EdgeX, begin with the connection and history guides below, confirm the full contract and review any unavailable or stale-data notice. That makes the MBO-based workflow useful in practice: you know where its detail helps and where aggregation requires a more cautious interpretation.

Common questions

Continue with the EdgeX product guides

These guides document the controls and data behavior used in this article.

• Set up Heatmap and Order Flow
• Understand iceberg and absorption candidates
• Market data, automatic history and stale-feed checks
• Understand your connection status