Strasmore Research
Deep Dives · Matt ConnorBy Matt Connor ·

Pagkakaiba ng MBO at MBP order book data

Alamin ang pagkakaiba ng MBO at MBP order book data. Inilalarawan nito ang message-by-order event streams kumpara sa aggregated depth per price level at ang gastos nito.

Ang MBO at MBP order book data ay isang malaking pagkakaiba na nakatago sa likod ng isang maliit na label. Maaaring magbenta ang dalawang vendor ng produktong tinatawag nilang "Level 2": ang MBP (market by price) ay nagpapadala ng kabuuang laki (size) na nakapila sa bawat price level, habang ang MBO (market by order) ay nagpapadala ng bawat indibidwal na order bilang sarili nitong event na may kaakibat na ID. Ang isa ay buod ng book; ang isa naman ay ang ledger kung saan binubuo ang book, at nangangailangan ito ng mas malaking volume ng trapiko upang maipadala.

Ano ang aktwal na nilalaman ng MBP at MBO order book data

Ang MBP, o market by price, ay pinagsama-samang depth. Ang bawat update ay nagtatakda ng side, price level, kabuuang laki na nakapila roon, at kung minsan ay ang bilang ng mga order sa likod nito. Ang produktong ibinebenta bilang MBP-10 ay nagbibigay sa iyo ng sampung pinakamagandang price level sa bawat side, ang ladder sa isang trading platform, at ang staircase sa bawat depth chart.

Ang MBO, o market by order, ay isang event stream. Ang bawat mensahe ay tumutukoy sa isang order: ang ID nito, side, presyo, laki, at kung ano ang nangyari rito. Walang pre-aggregation. Kung may apatnapung order sa parehong presyo, apatnapung magkakahiwalay na mensahe ang maglalagay sa kanila roon, at kailangan mong hawakan ang lahat ng apatnapu sa memory upang malaman ang kabuuan ng level na iyon.

Ang aming gabay sa Level 1 vs Level 2 market data ay sumasaklaw sa kahulugan ng mga retail tier label sa isang broker. Ang MBO at MBP ang mga tiyak na pangalan para sa kung ano ang nasa loob ng box kapag sinabi ng isang vendor na "Level 2", at ang schema name ang dapat mong itanong.

Ang mga message action na dala ng MBO feed

Ang MBO feed ay isang klasipikasyon ng mga aksyon na inilalapat sa mga order ID. Apat ang may pinakamalaking bahagi ng trapiko:

  • Add: isang bagong order ang sumasali sa book sa isang presyo na may bagong ID.
  • Modify: ang isang umiiral na ID ay nagbabago ng presyo o laki. Ang pagpapalaki ng size o paglipat ng presyo ay nagpapadala sa order sa dulo ng pila sa bagong level; ang pagbabawas ng size ay karaniwang nagpapanatili sa pwesto nito.
  • Cancel: ang isang ID ay umaalis sa book, nang buo o bahagi lamang.
  • Trade o fill: ang isang aggressive order ay nag-e-execute laban sa isa o higit pang resting ID, na nagpapaliit o nag-aalis sa mga ito.

Walang ganitong bokabularyo ang MBP. Ang update sa MBP ay isang pahayag tungkol sa isang level: ang presyong ito ay may ganito kalaking size ngayon. Kung ang size ay nawala dahil sa cancel o dahil sa fill, magkamukha lang ang update. Ipinapakita ng panel sa ibaba ang limitasyong iyon sa pinakamanipis na book, ang consolidated top of book, isang price level bawat side at MBP-1 sa ganitong pagpapangalan.

QueryMga pagbabago sa pagitan ng magkakasunod na top-of-book messages (AAPL, 10:00 hanggang 10:30 a.m. ET, June 16, 2026)
Ang eksaktong SQL sa likod ng bawat numero
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)
Run this yourself

Sa loob ng kalahating oras na iyon, 17.6% ng mga mensahe ang naglipat ng best bid sa ibang presyo, 17.4% ang nagdagdag ng size sa hindi nagbabagong bid, 12% ang nagbawas ng size sa hindi nagbabagong bid, at 53% ang nag-iwan sa bid habang ang kabilang side naman ang gumalaw. Ang bawat grupo ay isang netong pahayag tungkol sa isang price level. Wala sa mga ito ang nagpapangalan ng order, at walang arithmetic ang makakabawi sa ID na nawawala.

Ano ang kayang sagutin at hindi kayang sagutin ng bawat schema

Ang MBP-10 ay sumasagot sa mga tanong na "gaano kalaki ang size doon": ang hugis ng ladder, book imbalance, liquidity na nakapila malapit sa mid, at ang depth chart mismo. Ang mga aggregated level ay sapat na para sa mga ito.

Ang MBO ay sumasagot sa mga tanong na "ano ang nangyari sa order na ito": gaano kalaking size ang nasa unahan mo noong sumali ka, gaano katagal bago ma-cancel ang mga order, at ang probabilidad na ang isang passive order sa touch ay mag-trade bago gumalaw ang presyo. Ang mga dami na iyon ay hindi umiiral sa aggregated form, at ang pagsasama-sama ng mga order sa isang level total ay sumisira sa pagkakasunod-sunod na nagtatakda sa kanila.

Ang queue position ang pinakamalinaw na halimbawa, at may kahulugan lamang ito sa ilalim ng price-time priority versus pro-rata matching, kung saan ang pagkakasunod-sunod ng pagdating ang nagtatakda kung sino ang unang mag-te-trade. Ang nagpapahalaga rito ay ang print size: ang isang level ay napupuno ng maraming maliliit na execution, hindi ng isang malaki.

QueryTrade size mix sa parehong window (AAPL, 10:00 hanggang 10:30 a.m. ET, June 16, 2026)
Ang eksaktong SQL sa likod ng bawat numero
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)
Run this yourself

Ang mga print na mas mababa sa 100 shares, isang odd lot, ay bumuo ng 92.3% ng mga trade sa window na iyon, at ang pinakamalaking bucket na naroon, 1000 or more shares, ay bumuo ng 0.1%. I-feed ang mga print na iyon sa isang level na nagpapakita ng 4,000 shares at ang isang order na huling sumali sa pila ay maaaring dumaan sa dose-dosenang execution nang hindi nag-te-trade. Ipinapakita sa iyo ng MBP ang 4,000. Ipinapakita sa iyo ng MBO ang linya.

Walang schema ang nagpapakita ng hidden size. Ang isang iceberg order ay nagpapakita ng maliit na tip at nagre-refresh gamit ang bagong ID sa tuwing mapupuno ang tip, kaya ang reserve ay hindi kailanman lumalabas sa anumang mensahe.

Ang pagbuo muli ng book mula sa MBO ay isang state machine

Ang MBP feed ay ibinibigay na sa iyo ang sagot. Ang MBO feed ay ibinibigay sa iyo ang mga input at inaasahang magiging eksakto ka:

  1. Magsimula sa isang snapshot, o mula sa isang bakanteng book kasama ang clear message ng venue.
  2. Ilapat ang bawat add, modify, cancel, at fill sa mahigpit na pagkakasunod-sunod, na naka-key sa order ID.
  3. Panatilihin ang pangalawang index ayon sa price level, dahil iyon ang binabasa ng iyong estratehiya.
  4. Bantayan ang mga sequence number, at mag-re-sync mula sa bagong snapshot sa tuwing may nawawala.

Ang failure mode ay tahimik. Kapag nakaligtaan mo ang isang cancel, ang isang phantom order ay mananatili sa iyong book sa natitirang bahagi ng session, na nagpapalaki sa level na iyon, nang walang anumang exception na lalabas. Ang MBP ay mas maayos na nagde-degrade: ang bawat update ay muling nagtatakda ng kabuuan ng level, kaya ang isang corrupted na value ay mapapatungan sa loob ng ilang mensahe.

Ang MBO ay nabubuhay lamang sa mga direct venue feed, isang book bawat exchange, na nangangahulugang kailangang patakbuhin at pagsamahin ang ilan sa mga ito. Ang consolidated tape ay isang buod sa pamamagitan ng konstruksyon, isang paghahati na tinalakay sa SIP versus direct exchange feeds.

Ano ang gastos ng dagdag na detalye sa bandwidth

Ang bilang ng mensahe ang tapat na paraan upang presyuhan ang pagkakaiba. Ang panel sa ibaba ay binibilang ang mga consolidated top-of-book message laban sa mga aktwal na print sa parehong nakapirming kalahating oras para sa limang kilalang pangalan.

QueryTop-of-book messages laban sa prints, 10:00 hanggang 10:30 a.m. ET, June 16, 2026
Ang eksaktong SQL sa likod ng bawat numero
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
Run this yourself

Ang SPY ang may pinakamabigat na quote traffic bawat print, 9.6 na mensahe para sa bawat trade at 510 libong mensahe sa loob ng tatlumpung minuto. Malawak ang spread sa limang pangalan: sa ibaba ng panel, ang MSFT ay nagpatakbo ng 0.7 quote message bawat print, mas mababa sa isang mensahe para sa bawat trade. Tandaan kung ano ang binibilang ng column na iyon: isang price level bawat side, sa isang feed na pinagsama-sama na ang bawat venue sa isang best bid at offer. Ang produktong may sampung level ng depth ay nagpaparami nito, at ang per-order feed ay nagpaparami pa nito muli, dahil ang bawat order sa likod ng bawat level sa bawat venue ay bumubuo ng sarili nitong add, modify, at cancel, mag-trade man ito o hindi. Ang parehong arithmetic ay makikita sa mas malaking scale sa the size of the options quote feed.

Aling order book feed ang kailangan ng isang estratehiya?

Karamihan sa trabaho ay tumatakbo sa MBP-10. Ang mga depth chart, imbalance feature, pagsukat ng liquidity-at-price, execution cost model, at halos lahat ng tanong sa pananaliksik tungkol sa kung gaano kalaking size ang nakapila kung saan ay masasagot mula sa mga aggregated level, sa maliit na bahagi lamang ng volume ng mensahe.

Ang MBO ang kinakailangan kapag ang sagot ay nakadepende sa isang partikular na order: queue position, order lifetime, cancel behaviour, at passive fill probability sa touch. Ang isang estratehiya na nakadepende sa kung ito ay 200 shares o 20,000 shares ang lalim sa linya ay hindi makukuha mula sa aggregated data, at babayaran ito sa pamamagitan ng mga licence fee, bandwidth, storage, at engineering upang mapanatiling tama ang isang reconstructed book sa buong araw.

Paano binuo ang mga panel na ito
  • Ang feed sa likod ng bawat panel ay ang consolidated top of book, isang price level bawat side, kasama ang trade tape. Hindi ito depth feed at hindi per-order feed, kaya ang mga panel na ito ay naglalarawan ng argumento sa message-volume sa halip na i-sample ang MBO mismo.
  • Ang mga window ay nakapako sa isang nakaraang petsa, 10:00 hanggang 10:30 a.m. ET noong Hunyo 16, 2026, na naka-store bilang 14:00 hanggang 14:30 UTC. Ang mga nakapirming window ay nagpapanatiling stable sa mga numero sa kabila ng mga regeneration.
  • Ang classification panel ay naglalagay ng label sa bawat mensahe laban sa nauna sa pagkakasunod-sunod. Hindi nito maihihiwalay ang cancel sa fill, ang eksaktong limitasyon na inilalarawan ng post na ito.

FAQ

Ano ang pagkakaiba ng MBO at MBP market data?

Ang MBP, o market by price, ay pinagsasama-sama ang ipinapakitang size sa bawat price level at nagpapadala ng isang update bawat level. Ang MBO, o market by order, ay nagpapadala ng bawat indibidwal na order na may sariling ID, kasama ang mga add, modify, cancel, at fill event na nangyayari rito.

Ang Level 2 data ba ay kapareho ng MBO data?

Kadalasan ay hindi. Ang "Level 2" sa isang retail broker ay halos palaging nangangahulugan ng aggregated depth, kaya MBP na may lima hanggang dalawampung price level. Ang ilang vendor ay nagbebenta ng per-order feed sa ilalim ng parehong tier name, kaya ang schema name, hindi ang tier name, ang nagtatakda kung ano ang darating sa wire.

Gaano kalaki ang MBO feed kumpara sa MBP feed?

Nasa order of magnitude ang laki, depende sa venue at symbol. Ang consolidated top of book lamang ay tumakbo sa 9.6 na mensahe bawat print para sa pinaka-abalang pangalan sa panel sa itaas. Ang per-order feed ay nagdaragdag ng bawat add, modify, at cancel sa likod ng bawat level sa bawat venue, kabilang ang malaking mayorya ng mga order na hindi kailanman nag-te-trade.

Maaari bang bumuo muli ng MBP book mula sa MBO data?

Oo, at iyon ang normal na pipeline: ilapat ang bawat order event sa isang book na naka-key sa order ID, pagkatapos ay i-publish ang mga level total. Ang kabaligtaran nito ay imposible: kapag ang mga order ay pinagsama-sama na sa isang level total, ang mga indibidwal na ID at ang pagkakasunod-sunod ng pagdating ng mga ito ay wala na.


Ang bawat panel dito ay may kasamang eksaktong SQL sa ilalim nito. Upang mabilang ang parehong mga mensahe sa ibang symbol o session, itanong ang tanong sa simpleng Ingles sa Strasmore terminal.