Key Takeaways
- MBO provides order-level rather than price-level market data, although the exact fields and event types vary by venue.
- A consumer normally maintains book state by processing messages in sequence and applying adds, changes, executions, deletions, resets, and other venue-specific events.
- MBO can support queue-position and fill-probability analysis, but exact priority reconstruction depends on the matching rules and priority information published by the venue.
- MBO is more data-intensive than MBP because it retains the lifecycle of individual displayed orders instead of one aggregate quantity per level.
- The terms Level 2 and Level 3 are not standardized. MBO is sometimes called Level 3, while some vendors classify both MBO and MBP as Level 2 depth data.
Market by Order (MBO) is a market-data model in which a venue disseminates order-level events for the orders or displayed quantities included in that feed, using venue-assigned identifiers, prices, sides, quantities, and priority information where available. Unlike Market by Price (MBP), which aggregates interest at each price level, MBO preserves order-level identity within the limits of the venue’s specification. This lets users reconstruct a more granular view of the disseminated order book and analyze queue dynamics, order lifecycles, and execution probability.
How MBO Works
An MBO feed publishes events in the sequence defined by the exchange or data provider. A simplified order lifecycle may include an add message when an order becomes displayed, a change when its quantity or attributes are modified, one or more execution messages as it trades, and a delete or cancel message when the remaining quantity leaves the book.
The feed consumer applies each event to an in-memory representation of the book. The order identifier links messages belonging to the same displayed order, while price, side, and priority fields determine where the order sits. Sequence numbers, packet recovery, and snapshot messages help the consumer detect and repair gaps.
Actual feeds are more complex than a four-event model. They may include partial and full executions, cancel-replace semantics, implied orders, auction messages, trade corrections, security-status changes, refreshes, book clears, and instrument-definition updates. Implementations must follow the technical specification for each venue rather than assume a universal schema.
MBO Versus MBP
Market by Price groups all displayed interest at the same price into an aggregate quantity and sometimes an order count. It is efficient for showing depth and price-level imbalance, but it cannot normally reveal the order-level composition of that depth.
Market by Order preserves individual displayed orders, enabling analysis of order age, cancellation, replacement, queue structure, and the behaviour of specific anonymous order identifiers. The trade-off is higher message volume, greater state-management complexity, and more demanding storage and replay requirements.
MBO identifiers are generally anonymous. Undisplayed liquidity, reserve quantity, broker internalization, and non-public matching-engine state fall outside what any public feed discloses, whether MBO or MBP.
MBO, Level 1, Level 2 and Level 3
Level 1 usually refers to top-of-book data such as the best bid, best offer, and last trade. Level 2 commonly refers to depth beyond the best prices. Some market-data taxonomies use Level 3 for individual orders, but this terminology is not consistent across venues and vendors; some providers classify both MBP and MBO under Level 2.
For technical documentation, the explicit feed model is more informative than the level number. Terms such as order-by-order, market by order, market by price, full depth, and top of book should be accompanied by the venue name and feed specification.
Queue Position and MBO
Queue position is an order’s priority relative to other resting orders at the same price. MBO can show the displayed orders or quantity ahead of a given order, though definitive priority also depends on venue-published priority fields, amendments, hidden or implied liquidity, and the venue’s allocation rules — pro-rata, size, broker, parity, and hybrid models all change how that queue actually clears. See Queue Position for the full mechanics.
Why MBO Matters for Trading
A trader deciding whether to join a price level needs to estimate how much displayed interest is ahead, how quickly that queue is trading, how often orders ahead cancel, and whether the expected fill justifies the adverse-selection risk. Aggregate depth alone cannot answer those questions.
MBO data supports fill-probability models, passive-order placement, smart order routing, execution simulation, and market-impact research. A model can estimate the probability that a newly posted order will execute within a given time based on queue ahead, recent trade rate, cancellations, spread, volatility, and imbalance.
The value of MBO is highest when order events are processed with low latency and a correct representation of venue rules. A small sequencing or normalization error can produce a book that looks plausible but generates incorrect queue and fill estimates.
Why MBO Matters for Surveillance and TCA
Surveillance teams use order-level data to investigate behaviour that’s invisible in trade-only data, including spoofing, layering, rapid cancellation, order marking, and coordinated activity. OneTick Surveillance runs typology detection for these patterns against order-level history, reconstructing what was displayed before and after an execution and whether an order was repeatedly modified or removed.
Transaction cost analysis uses MBO to measure queue dynamics, passive fill quality, opportunity cost, and the market response to order placement. It can also separate a participant’s own order changes from changes in aggregate depth created by other market participants.
MBO Data Engineering Challenges
- Sequencing and gap recovery: packet loss or out-of-order events can corrupt the reconstructed book.
- Snapshots and resets: the system must reconcile incremental updates with recovery images and trading-session boundaries, and support point-in-time reconstruction by replaying from the nearest snapshot to a target timestamp.
- Venue normalization: identifiers, event names, quantity semantics, and timestamps differ across feeds.
- Order-state correctness: partial executions, reductions, replacements, and deletes must update the correct order exactly once.
- Timestamp precision: exchange, receive, and processing timestamps answer different analytical questions.
- Data volume: order-level feeds can produce substantially more events than aggregated depth feeds.
- Corporate actions and symbology: instruments and identifiers must be mapped consistently across days and venues.
- Validation: reconstructed price-level totals should be reconciled with independent MBP or snapshot data where available.
How KDB-X Supports Market by Order Analytics
KDB-X can ingest, normalize, and analyze the high-volume event streams MBO feeds generate. Combining real-time processing with historical time-series storage lets firms reconstruct order-book activity, examine individual order lifecycles, and calculate measures such as displayed depth, order age, cancellation behaviour, and estimated queue position.
MBO feed structures and matching rules differ by venue, so implementations need to account for venue-specific message formats, sequence handling, recovery processes, and priority rules. KDB-X provides the data-management and temporal-analysis layer for that work, retaining the detailed event history research, execution analytics, and TCA require.
Reach out to our team to see how KDB-X can help with your MBO workflows.
Frequently Asked Questions
Is MBO the same as Level 3 market data?
Sometimes. Some vendors label individual-order data as Level 3; others classify MBO under Level 2 depth data. See MBO, Level 1, Level 2 and Level 3 above — the feed model and venue specification matter more than the label.
Does MBO identify the trader or firm behind an order?
Usually not. Public MBO feeds commonly use anonymous venue-assigned order identifiers rather than customer or firm identities. Entitled participants may receive private acknowledgements that help identify their own orders, while regulatory or participant-private data products may contain different information.
Can MBO show hidden or iceberg liquidity?
It shows only the information disseminated by the venue. The displayed portion of an iceberg may be visible, while reserve quantity may not be. Refresh behaviour and identifiers vary by venue and order type.
Can queue position be calculated from MBP?
MBP can support rough estimates using aggregate quantity and order counts, but it normally cannot identify the individual displayed orders ahead. MBO provides order-level information for a more precise reconstruction of displayed quantity ahead, though definitive matching priority may still depend on additional venue-specific fields and allocation rules.
Is MBO available on every exchange?
No. Availability, depth, fields, latency, and licensing differ by venue and asset class. Some exchanges provide order-by-order feeds, while others publish only aggregated depth or make order-level data available through separate products.
Can MBO be used to backtest execution strategies?
Yes, provided the data and simulator model the venue’s sequencing, matching rules, latency assumptions, and hidden-liquidity limitations. Naive replay can overstate the certainty of historical fills.
Related Terms
- Market by Price (MBP) — aggregated displayed quantity at each price level
- Order Book — the ranked set of active buy and sell interest for an instrument
