Market-By-Order Versus Market-By-Price Feeds
An exchange can publish its book two different ways — as aggregated totals per price level, or as a stream of individual order events. The choice changes what a recipient can reconstruct and how much bandwidth the feed needs.
Prerequisites: Level 1, Level 2 And Level 3 Market Data
An exchange's matching engine knows the exact state of every resting order, but it has to choose how to broadcast that state to thousands of subscribers many times a second, and the choice of representation matters a lot downstream. Market-by-price (MBP) publishes the book as a list of price levels, each with an aggregated total size — "99.98: 500 shares total" — with no information about how many individual orders make up that 500 or in what order they arrived. Market-by-order (MBO) instead publishes every individual order as a distinct, identified entity — "Order #4471 at 99.98 for 200 shares," "Order #4483 at 99.98 for 150 shares" — and every add, modify, and cancel is broadcast as an event referencing that specific order ID.
The tradeoff is bandwidth and complexity versus information. MBP updates are compact: a busy price level with a hundred orders behind it still only needs one message when its aggregate size changes. MBO has to send a separate message for every one of those hundred orders' individual state changes, which on a busy day at a liquid name can be an enormous multiple of the MBP message count — but MBO is the only feed type from which a recipient can reconstruct exact queue position (who's ahead of whom at a price), because MBP has already thrown that information away by aggregating.
Worked example. At 99.98, three orders rest: #101 (200 shares, first), #102 (150 shares, second), #103 (150 shares, third), totaling 500. Order #101 is fully filled by an incoming trade. An MBP feed sends one update: "99.98: size now 300" — a subscriber has no way to know whether it was #101, #102, or #103 that got (partially or fully) filled, or some combination, just that the aggregate dropped by 200. An MBO feed sends an explicit event: "Order #101: filled, 0 remaining" — a subscriber who was tracking their own resting order #102 or #103 now knows precisely that the order ahead of them (#101) is gone, and their own queue position has improved by exactly 200 shares, something the MBP feed alone could never tell them with certainty when multiple orders are present at that level.
What this means in practice
Firms whose edge depends on exact queue position — most market makers and latency-sensitive strategies — subscribe to and process MBO feeds and reconstruct the full order book, including their own position within each queue, in memory. Firms whose strategies operate on slower signals or don't need queue-level precision often use MBP feeds, which are cheaper to process and require far less network and CPU capacity for the same instrument coverage. Some venues only publish MBP for retail/vendor distribution and reserve MBO for direct, paid co-located connections.
MBP aggregates by price level and is compact but discards order identity; MBO publishes every individual order event and is the only feed type that lets a recipient reconstruct exact queue position, at a much higher message rate.
Reconstructing a correct book from an MBO feed requires processing every message in the exact sequence the exchange sent it — a single dropped or reordered message desynchronizes the local book from the exchange's true state, silently, until a periodic snapshot or gap-detection mechanism catches it. This is a common source of subtle production bugs in feed handlers, and is a much smaller risk on an MBP feed where each message is self-contained.
See Level 1, Level 2 And Level 3 Market Data for how this distinction maps onto the commonly used Level 1/2/3 terminology, and C++ for Low-Latency Trading for the engineering demands of processing MBO feeds at line rate.
Practice in interviews
Further reading
- CME Group, MDP 3.0 Market Data Handbook