ポイント
- 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 allows users to 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.
Neither format reveals everything about market intent. MBO identifiers are generally anonymous, and undisplayed liquidity, reserve quantity, broker internalization and non-public matching-engine state may not be visible. MBO should therefore be described as an order-level view of what the venue disseminates, not a complete view of every trading instruction in the market.
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.
What Is Queue Position?
Queue position describes an order’s priority relative to other orders at the same price. In a price-time market, earlier orders generally execute before later orders, subject to the venue’s rules. MBO can show the displayed orders or displayed quantity ahead of a target order. Definitive matching priority may additionally depend on venue-published priority fields, amendments, hidden or implied liquidity and the venue’s allocation rules.
Queue reconstruction is not universally exact. Some markets use pro-rata, size, broker, parity, allocation or hybrid matching rules. Modifications may change priority. Reserve, implied or hidden liquidity may affect fills without being fully represented in the public feed. A model must therefore encode the venue’s matching algorithm and use the fields actually disseminated.
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 all of those questions.
MBO data supports fill-probability models, passive-order placement, smart order routing, execution simulation and market-impact research. For example, 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 with a correct representation of venue rules. A small sequencing or normalization error can create a book that looks plausible but produces incorrect queue and fill estimates.
Why MBO Matters for Surveillance and TCA
Surveillance teams use order-level data to investigate behaviours that are invisible in trade-only data, including spoofing, layering, rapid cancellation, order marking and coordinated activity. MBO helps reconstruct what was displayed before and after an execution and whether an order was repeatedly modified or removed.
Transaction cost analysis can use 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 users.
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.
- 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 an MBO Order Book Is Reconstructed
A typical reconstruction engine maintains a state table keyed by venue, instrument and order identifier. An add creates a new row, a change updates the relevant fields, an execution reduces displayed quantity or removes the order when fully filled, and a delete removes the remaining state. The engine also maintains price-level structures so best prices and aggregate depth can be queried efficiently.
Historical reconstruction requires the ability to reproduce state at a selected time. One method starts from a known snapshot and replays subsequent events up to the target timestamp. Another stores periodic state images to reduce replay distance. The right design depends on latency, query frequency, retention and storage constraints.
Validation is essential. Systems commonly check sequence continuity, impossible negative quantities, duplicate order IDs, deletes for missing orders, crossed-book conditions and reconciliation between order-level totals and published aggregate data.
How KDB-X Supports Market by Order Analytics
KDB-X can be used to ingest, normalize and analyze the high-volume event streams generated by Market by Order feeds. By combining real-time processing with historical time-series analysis, firms can reconstruct order-book activity, examine individual order lifecycles and calculate measures such as displayed depth, order age, cancellation behaviour and estimated queue position.
Because MBO feed structures and matching rules differ between trading venues, implementations must account for venue-specific message formats, sequence handling, recovery processes and priority rules. KDB-X provides the data-management and temporal-analysis capabilities needed to build these workflows while retaining the detailed event history required for research, execution analytics and market surveillance.
Learn more about how KDB-X helps capital-markets firms process and analyze high-volume market data.
Frequently Asked Questions
Is MBO the same as Level 3 market data?
Sometimes, but not universally. Some firms call individual-order data Level 3, while other vendors classify MBO as Level 2 depth data. The feed model and venue specification are more precise than the level 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; 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 particular products.
What happens if an MBO message is missed?
The local book can become incorrect. Consumers use sequence numbers, retransmission, recovery channels and snapshots to detect and repair gaps according to the venue’s protocol.
Why is MBO more expensive to store?
It records every disseminated order event rather than only changes to aggregate price levels. High-activity instruments can therefore generate very large event volumes and require efficient compression, partitioning and query design.
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.
- Queue position: an order’s priority relative to other orders at the same price.
- Level 1 market data: top-of-book and last-trade information.
- Depth of book: displayed interest beyond the best bid and offer.
- Matching engine: the venue system that accepts, prioritizes and executes orders.
- Order-book reconstruction: replaying market-data events to reproduce book state.