Wetin be difference between MBO and MBP order data

MBO versus MBP order book data na big difference wey dey hide under one small label. Two vendors fit sell you wetin dem call "Level 2": MBP (market by price) dey send the total size wey dey for each price level, while MBO (market by order) dey send every individual order as e get e own event with e own ID. One na summary of the book; the other one na the ledger wey dem take build the book, and e dey cost plenty traffic pass to carry.

Wetin MBP and MBO order book data actually contain

MBP, market by price, na aggregated depth. Each update dey name the side, the price level, the total displayed size wey dey there, and sometimes the number of orders wey dey behind am. One product wey dem sell as MBP-10 go give you the ten best price levels for each side, the ladder for trading platform and the staircase for every depth chart.

MBO, market by order, na event stream. Each message dey name one order: e ID, side, price, displayed size, and wetin just happen to am. Nothing dey pre-aggregated. If forty orders dey for the same price, forty separate messages go put dem there, and you go hold all forty for memory to know wetin that level total be.

Our Level 1 vs Level 2 market data guide cover wetin the retail tier labels mean for broker. MBO and MBP na the correct names for wetin dey inside the box when vendor talk say "Level 2", and the schema name na the one wey you suppose ask about.

The message actions wey MBO feed dey carry

MBO feed na taxonomy of actions wey dem apply to order IDs. Four dey carry most of the traffic:

• Add: new order join the book for one price with new ID.
• Modify: existing ID change price or size. If you raise size or move price, the order go go back of the queue for the new level; if you reduce size, e normally go stay e place.
• Cancel: ID comot from the book, whether full or part.
• Trade or fill: aggressive order execute against one or more resting IDs, e go shrink or remove dem.

MBP no dey carry any of that vocabulary. MBP update na statement about level: this price now get this much size. Whether the size comot through cancel or through fill, the update go look the same. The panel wey dey down show that limit for the thinnest possible book, the consolidated top of book, one price level per side and MBP-1 for this naming.

WITH
    ordered AS
    (
        SELECT
            row_number() OVER (ORDER BY sip_timestamp, sequence_number) AS msg_index,
            bid_price,
            bid_size,
            lagInFrame(bid_price) OVER (ORDER BY sip_timestamp, sequence_number) AS prev_bid_price,
            lagInFrame(bid_size)  OVER (ORDER BY sip_timestamp, sequence_number) AS prev_bid_size
        FROM global_markets.cache_stocks_quotes
        WHERE ticker = 'AAPL'
          AND sip_timestamp >= '2026-06-16 14:00:00'
          AND sip_timestamp <  '2026-06-16 14:30:00'
          AND bid_price > 0
    ),
    classified AS
    (
        SELECT multiIf(
            bid_price != prev_bid_price, 'best bid price changed',
            bid_size  >  prev_bid_size,  'size joined at the best bid',
            bid_size  <  prev_bid_size,  'size left the best bid',
            'bid untouched, ask side updated') AS message_type
        FROM ordered
        WHERE msg_index > 1
    )
SELECT
    message_type,
    count()                                        AS message_count,
    round(100 * count() / sum(count()) OVER (), 1) AS share_pct
FROM classified
GROUP BY message_type
ORDER BY indexOf(['best bid price changed', 'size joined at the best bid', 'size left the best bid', 'bid untouched, ask side updated'], message_type)

Over that half hour, 17.6% of messages move the best bid to different price, 17.4% add size for unchanged bid, 12% remove size for unchanged bid, and 53% leave the bid alone while the other side move. Each group na net statement about price level. None dey name order, and no arithmetic fit recover the ID wey miss.

Wetin each schema fit and no fit answer

MBP-10 fit answer questions wey dem phrase as "how much size dey there": the shape of the ladder, book imbalance, liquidity wey dey near the mid, the depth chart itself. Aggregated levels na all wetin those ones need.

MBO fit answer questions wey dem phrase as "wetin happen to this order": how much size sit ahead of your own when you join, how long orders survive before dem cancel, and the probability say passive order for the touch go trade before the price move away. Those quantities no dey for aggregated form, and if you sum orders into level total, you go destroy the sequence wey define dem.

Queue position na the sharpest example, and e only get meaning under price-time priority versus pro-rata matching, where arrival order decide who trade first. Wetin make am matter na print size: level dey fill by many small executions, no be one large one.

SELECT
    multiIf(size < 100,  '1 to 99 shares',
            size < 200,  '100 to 199 shares',
            size < 500,  '200 to 499 shares',
            size < 1000, '500 to 999 shares',
            '1000 or more shares')                 AS trade_size_bucket,
    count()                                        AS trade_count,
    round(100 * count() / sum(count()) OVER (), 1) AS share_pct,
    round(avg(size))                               AS avg_shares
FROM global_markets.stocks_trades
WHERE ticker = 'AAPL'
  AND sip_timestamp >= '2026-06-16 14:00:00'
  AND sip_timestamp <  '2026-06-16 14:30:00'
  AND size > 0
GROUP BY trade_size_bucket
ORDER BY min(size)

Prints wey dey below 100 shares, wey be odd lot, make up 92.3% of trades for that window, and the largest bucket wey dey, 1000 or more shares, make up 0.1%. If you feed prints of that size to level wey dey display 4,000 shares, order wey join the queue last fit sit through dozens of executions without trading. MBP show you the 4,000. MBO show you the line.

Neither schema show hidden size. Iceberg order dey display small tip and e dey refresh with new ID anytime the tip fill, so the reserve no dey ever appear for any message.

To rebuild book from MBO na state machine

MBP feed go hand you the answer. MBO feed go hand you the inputs and expect you to be exactly correct:

1. Start from snapshot, or from empty book plus the venue clear message.
2. Apply every add, modify, cancel and fill for strict sequence order, keyed by order ID.
3. Maintain second index by price level, because na wetin your strategy dey read.
4. Watch the sequence numbers, and re-sync from fresh snapshot anytime one miss.

The failure mode dey quiet. If you drop one cancel, phantom order go sit for your book for the rest of the session, e go inflate that level, and no exception go show anywhere. MBP dey degrade pass that one: each update dey restate level total, so corrupted value go overwrite within few messages.

MBO also dey live only for direct venue feeds, one book per exchange, wey mean say you go run and merge many of dem. The consolidated tape na summary by construction, split wey dem cover for SIP versus direct exchange feeds.

Wetin the extra detail cost for bandwidth

Message counts na the honest way to price the difference. The panel wey dey down count consolidated top-of-book messages against actual prints over the same pinned half hour for five household names.

WITH
    quote_load AS
    (
        SELECT ticker, count() AS quote_messages
        FROM global_markets.cache_stocks_quotes
        WHERE ticker IN ('SPY', 'AAPL', 'NVDA', 'MSFT', 'KO')
          AND sip_timestamp >= '2026-06-16 14:00:00'
          AND sip_timestamp <  '2026-06-16 14:30:00'
        GROUP BY ticker
    ),
    trade_load AS
    (
        SELECT ticker, count() AS trades
        FROM global_markets.stocks_trades
        WHERE ticker IN ('SPY', 'AAPL', 'NVDA', 'MSFT', 'KO')
          AND sip_timestamp >= '2026-06-16 14:00:00'
          AND sip_timestamp <  '2026-06-16 14:30:00'
        GROUP BY ticker
    )
SELECT
    q.ticker                              AS ticker,
    round(q.quote_messages / 1000, 1)     AS quote_messages_thousands,
    round(t.trades / 1000, 2)             AS trades_thousands,
    round(q.quote_messages / t.trades, 1) AS quotes_per_trade_ratio
FROM quote_load AS q
INNER JOIN trade_load AS t ON t.ticker = q.ticker
ORDER BY quotes_per_trade_ratio DESC

SPY carry the heaviest quote traffic per print, 9.6 messages for every trade and 510 thousand messages for thirty minutes. The spread across the five names wide: for the bottom of the panel, MSFT run 0.7 quote messages per print, wey be fewer than one message for every trade. Remember wetin that column count: one price level per side, for feed wey don already collapse every venue into single best bid and offer. Ten-level depth product go multiply am, and per-order feed go multiply am again, because each order behind each level on each venue dey generate e own add, e own modifies, and e own cancel, whether e trade or not. The same arithmetic dey show for larger scale for the size of the options quote feed.

Which order book feed strategy need?

Most of the work dey run on MBP-10. Depth charts, imbalance features, liquidity-at-price measurement, execution cost models, and nearly every research question about how much size dey rest where, you fit answer dem from aggregated levels, for fraction of the message volume.

MBO na the requirement when the answer depend on specific order: queue position, order lifetime, cancel behaviour, passive fill probability for the touch. Strategy wey dey live or die based on whether e be 200 shares or 20,000 shares deep for the line no fit get that one from aggregated data, and e go pay for that one for licence fees, bandwidth, storage, and the engineering to keep reconstructed book correct all day.

FAQ

Wetin be the difference between MBO and MBP market data?

MBP, market by price, dey aggregate displayed size for each price level and e dey send one update per level. MBO, market by order, dey send every individual order with e own ID, join with the add, modify, cancel and fill events wey happen to am.

Level 2 data be the same as MBO data?

Usually no. "Level 2" for retail broker almost always mean aggregated depth, so MBP with five to twenty price levels. Few vendors dey market per-order feed under the same tier name, so the schema name, no be the tier name, go settle wetin arrive on the wire.

How much bigger MBO feed be pass MBP feed?

Orders of magnitude, e dey vary by venue and by symbol. The consolidated top of book alone run at 9.6 messages per print for the busiest name for the panel above. Per-order feed dey add every add, modify and cancel behind every level on every venue, including the large majority of orders wey no dey ever trade.

You fit rebuild MBP book from MBO data?

Yes, and na the normal pipeline be that: apply each order event to book wey dem key by order ID, then publish the level totals. The reverse no possible: once dem sum orders into level total, the individual IDs and their arrival order don go.

Every panel here dey ship with the exact SQL wey dey under am. To count the same messages for different symbol or session, ask the question for plain English for the Strasmore terminal.