Dane MBO a MBP w arkuszu zleceń: różnice i zastosowanie

Dane typu MBO (market by order) oraz MBP (market by price) to zasadnicza różnica ukryta pod jedną, niepozorną nazwą. Dwóch różnych dostawców może oferować produkt określany jako „Level 2”: MBP (market by price) przesyła całkowitą wielkość zleceń oczekujących na każdym poziomie cenowym, podczas gdy MBO (market by order) przesyła każde pojedyncze zlecenie jako osobne zdarzenie z unikalnym identyfikatorem. Pierwszy typ to podsumowanie arkusza; drugi to rejestr, na podstawie którego arkusz jest budowany, a jego obsługa wymaga o rzędy wielkości większego pasma przesyłowego.

Co faktycznie zawierają dane arkusza zleceń MBP i MBO

MBP, czyli market by price, to zagregowana głębokość rynku. Każda aktualizacja wskazuje stronę, poziom cenowy, całkowitą widoczną wielkość zleceń na tym poziomie, a czasem także liczbę zleceń, które się na nią składają. Produkt sprzedawany jako MBP-10 dostarcza dziesięć najlepszych poziomów cenowych po każdej ze stron, tworząc arkusz widoczny w platformach transakcyjnych oraz wykresy głębokości rynku.

MBO, czyli market by order, to strumień zdarzeń. Każdy komunikat dotyczy jednego zlecenia: jego identyfikatora, strony, ceny, widocznej wielkości oraz informacji o tym, co się z nim stało. Nic nie jest wstępnie agregowane. Jeśli na tym samym poziomie cenowym oczekuje czterdzieści zleceń, czterdzieści osobnych komunikatów wprowadza je do systemu, a użytkownik musi przechowywać wszystkie czterdzieści w pamięci, aby znać sumaryczną wielkość na tym poziomie.

Nasz przewodnik po danych rynkowych Level 1 i Level 2 wyjaśnia, co oznaczają te kategorie w relacjach z brokerem. MBO i MBP to precyzyjne nazwy tego, co znajduje się wewnątrz „pudełka”, gdy dostawca mówi o „Level 2”, dlatego warto pytać o konkretny schemat danych.

Działania na zleceniach w strumieniu MBO

Strumień MBO to taksonomia działań stosowanych wobec identyfikatorów zleceń. Cztery z nich generują większość ruchu:

• Add (dodanie): nowe zlecenie trafia do arkusza po określonej cenie z nowym identyfikatorem.
• Modify (modyfikacja): istniejący identyfikator zmienia cenę lub wielkość. Zwiększenie wielkości lub zmiana ceny przesuwa zlecenie na koniec kolejki na nowym poziomie; zmniejszenie wielkości zazwyczaj pozwala zachować dotychczasową pozycję.
• Cancel (anulowanie): identyfikator znika z arkusza, w całości lub w części.
• Trade lub fill (transakcja lub realizacja): agresywne zlecenie realizuje się wobec jednego lub kilku oczekujących identyfikatorów, zmniejszając ich wielkość lub usuwając je z arkusza.

MBP nie zawiera żadnego z tych elementów. Aktualizacja MBP to stwierdzenie dotyczące poziomu: dana cena ma teraz taką a taką wielkość. Niezależnie od tego, czy wielkość ta zniknęła wskutek anulowania, czy realizacji, aktualizacja wygląda identycznie. Poniższy panel pokazuje to ograniczenie na najwęższym możliwym arkuszu, czyli skonsolidowanym szczycie arkusza (top of book), z jednym poziomem cenowym na stronę, co w tym nazewnictwie odpowiada MBP-1.

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)

W ciągu tego pół godziny 17.6% komunikatów zmieniło cenę najlepszego kupna (bid), 17.4% dodało wielkość przy niezmienionej cenie bid, 12% usunęło wielkość przy niezmienionej cenie bid, a 53% pozostawiło cenę bid bez zmian, podczas gdy druga strona arkusza uległa zmianie. Każda grupa to zbiorcze stwierdzenie o poziomie cenowym. Żaden komunikat nie wskazuje identyfikatora zlecenia i żadne obliczenia nie pozwolą odzyskać brakującego identyfikatora.

Na jakie pytania odpowiada każdy ze schematów

MBP-10 odpowiada na pytania typu „ile wielkości tam było”: kształt arkusza, nierównowaga arkusza, płynność w pobliżu ceny środkowej, sam wykres głębokości. Do tego wystarczą zagregowane poziomy.

MBO odpowiada na pytania typu „co stało się z tym konkretnym zleceniem”: ile wielkości znajdowało się przed Twoim zleceniem w momencie jego złożenia, jak długo zlecenia pozostają w arkuszu przed anulowaniem oraz jakie jest prawdopodobieństwo, że pasywne zlecenie na najlepszym poziomie zostanie zrealizowane, zanim cena się zmieni. Te wartości nie istnieją w formie zagregowanej, a sumowanie zleceń do poziomu całkowitego niszczy sekwencję, która je definiowała.

Pozycja w kolejce to najlepszy przykład; ma ona znaczenie tylko w modelu price-time priority versus pro-rata matching, gdzie kolejność napływu zleceń decyduje o pierwszeństwie realizacji. O istotności tego faktu decyduje wielkość transakcji (print): poziom jest wypełniany przez wiele małych realizacji, a nie jedną dużą.

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)

Transakcje poniżej 100 akcji (odd lot) stanowiły 92.3% wszystkich transakcji w tym oknie, a największy segment, 1000 or more shares, stanowił 0.1%. Jeśli strumień danych przesyła taką wielkość na poziom wyświetlający 4000 akcji, zlecenie, które dołączyło do kolejki jako ostatnie, może przetrwać dziesiątki realizacji bez wykonania. MBP pokazuje 4000. MBO pokazuje kolejkę.

Żaden ze schematów nie pokazuje ukrytej wielkości. Zlecenie typu iceberg wyświetla tylko niewielką część, a po jej realizacji odświeża się z nowym identyfikatorem, więc rezerwa nigdy nie pojawia się w żadnym komunikacie.

Odtwarzanie arkusza z danych MBO jako maszyna stanów

Strumień MBP podaje gotową odpowiedź. Strumień MBO dostarcza dane wejściowe i wymaga precyzji:

1. Zacznij od migawki (snapshot) lub od pustego arkusza i komunikatu o wyczyszczeniu (clear) z giełdy.
2. Zastosuj każde dodanie, modyfikację, anulowanie i realizację w ścisłej kolejności, używając identyfikatora zlecenia jako klucza.
3. Utrzymuj drugi indeks według poziomów cenowych, ponieważ to z niego korzysta Twoja strategia.
4. Monitoruj numery sekwencyjne i synchronizuj dane z nową migawką, gdy tylko wystąpi brak w sekwencji.

Tryb awarii jest cichy. Jeśli pominiesz jedno anulowanie, w Twoim arkuszu pozostanie „zlecenie widmo”, zawyżając wielkość na danym poziomie, bez wygenerowania żadnego błędu. MBP degraduje się znacznie łagodniej: każda aktualizacja nadpisuje sumę poziomu, więc błędna wartość zostanie skorygowana w ciągu kilku komunikatów.

MBO działa również tylko na bezpośrednich strumieniach z giełd, jeden arkusz na giełdę, co oznacza konieczność obsługi i łączenia kilku z nich. Skonsolidowana taśma (consolidated tape) jest z założenia podsumowaniem, co opisano w SIP versus direct exchange feeds.

Koszt dodatkowych szczegółów w paśmie przesyłowym

Liczba komunikatów to uczciwy sposób na wycenę różnicy. Poniższy panel zestawia liczbę komunikatów skonsolidowanego szczytu arkusza z rzeczywistymi transakcjami w tym samym półgodzinnym oknie dla pięciu znanych spółek.

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 wygenerowało największy ruch kwotowań na transakcję, 9.6 komunikatów na każdą transakcję i 510 tysięcy komunikatów w trzydzieści minut. Rozpiętość między spółkami jest duża: na dole panelu MSFT wygenerowało 0.7 komunikatów kwotowań na transakcję, czyli mniej niż jeden komunikat na każdą transakcję. Należy pamiętać, co liczy ta kolumna: jeden poziom cenowy na stronę, na strumieniu, który już skonsolidował wszystkie giełdy w jedną najlepszą ofertę kupna i sprzedaży (BBO). Produkt o dziesięciu poziomach głębokości mnoży tę liczbę, a strumień per-order mnoży ją ponownie, ponieważ każde zlecenie za każdym poziomem na każdej giełdzie generuje własne dodanie, modyfikację i anulowanie, niezależnie od tego, czy kiedykolwiek zostanie zrealizowane. Ta sama arytmetyka pojawia się na większą skalę w the size of the options quote feed.

Którego strumienia danych potrzebuje strategia?

Większość prac opiera się na MBP-10. Wykresy głębokości, wskaźniki nierównowagi, pomiar płynności po danej cenie, modele kosztów realizacji i niemal każde pytanie badawcze dotyczące wielkości zleceń oczekujących na danym poziomie można rozstrzygnąć na podstawie zagregowanych danych, przy ułamku wolumenu komunikatów.

MBO jest wymagane, gdy odpowiedź zależy od konkretnego zlecenia: pozycji w kolejce, czasu życia zlecenia, zachowania przy anulowaniu, prawdopodobieństwa pasywnej realizacji na najlepszym poziomie. Strategia, której powodzenie zależy od tego, czy w kolejce jest 200 czy 20 000 akcji, nie może opierać się na danych zagregowanych, a za ten brak płaci się w opłatach licencyjnych, paśmie, pamięci masowej oraz kosztach inżynierii niezbędnej do utrzymania poprawnego stanu arkusza przez cały dzień.

FAQ

Jaka jest różnica między danymi rynkowymi MBO a MBP?

MBP (market by price) agreguje widoczną wielkość zleceń na każdym poziomie cenowym i wysyła jedną aktualizację na poziom. MBO (market by order) wysyła każde pojedyncze zlecenie z własnym identyfikatorem, wraz ze zdarzeniami dodania, modyfikacji, anulowania i realizacji, które go dotyczą.

Czy dane Level 2 to to samo co dane MBO?

Zazwyczaj nie. „Level 2” u brokera detalicznego prawie zawsze oznacza zagregowaną głębokość, czyli MBP z pięcioma do dwudziestu poziomami cenowymi. Nieliczni dostawcy oferują strumień per-order pod tą samą nazwą kategorii, dlatego to nazwa schematu, a nie nazwa kategorii, decyduje o tym, co faktycznie dociera do odbiorcy.

O ile większy jest strumień MBO od strumienia MBP?

O rzędy wielkości, w zależności od giełdy i symbolu. Sam skonsolidowany szczyt arkusza generował 9.6 komunikatów na transakcję dla najbardziej aktywnej spółki w powyższym panelu. Strumień per-order dodaje każde dodanie, modyfikację i anulowanie za każdym poziomem na każdej giełdzie, w tym zdecydowaną większość zleceń, które nigdy nie zostają zrealizowane.

Czy można odtworzyć arkusz MBP z danych MBO?

Tak, jest to standardowy proces: zastosuj każde zdarzenie zlecenia do arkusza kluczowanego identyfikatorem zlecenia, a następnie opublikuj sumy poziomów. Odwrotna operacja jest niemożliwa: gdy zlecenia zostaną zsumowane do poziomu całkowitego, indywidualne identyfikatory i kolejność ich napływu zostają utracone.

Każdy panel w tym miejscu zawiera dokładne zapytanie SQL, na którym bazuje. Aby przeliczyć te same komunikaty dla innego symbolu lub sesji, zadaj pytanie w prostym języku na terminalu Strasmore.