Різниця між даними книги заявок MBO та MBP
Порівняння потоків даних MBO та MBP для біржової торгівлі. Аналіз відмінностей між агрегованими рівнями цін та індивідуальними заявками, а також оцінка витрат на їх обробку.
Дані книги заявок MBO та MBP — це суттєва відмінність, що ховається за одним невеликим терміном. Два постачальники можуть продавати вам продукт під назвою «Level 2»: MBP (market by price) надсилає загальний обсяг на кожному ціновому рівні, тоді як MBO (market by order) надсилає кожну окрему заявку як подію з власним ідентифікатором. Перше — це зведення книги, друге — реєстр, на основі якого ця книга будується, і для його передачі потрібно на порядки більше трафіку.
Що насправді містять дані книги заявок MBP та MBO
MBP (market by price) — це агрегована глибина ринку. Кожне оновлення вказує сторону, ціновий рівень, загальний відображений обсяг на цьому рівні, а іноді й кількість заявок, що стоять за ним. Продукт, що продається як MBP-10, надає десять найкращих цінових рівнів з кожного боку — це «стакан» у торговій платформі та «сходинки» на будь-якому графіку глибини ринку.
MBO (market by order) — це потік подій. Кожне повідомлення стосується однієї заявки: її ідентифікатора, сторони, ціни, відображеного обсягу та того, що з нею щойно сталося. Нічого не агрегується заздалегідь. Якщо на одній ціні стоїть сорок заявок, їх туди помістили сорок окремих повідомлень, і ви повинні зберігати всі сорок у пам'яті, щоб знати загальний обсяг на цьому рівні.
Наш посібник з ринкових даних Level 1 та Level 2 пояснює, що означають ці рівні для роздрібного інвестора у брокера. MBO та MBP — це точні назви того, що знаходиться всередині «коробки», коли постачальник каже «Level 2», і саме про назву схеми варто запитувати.
Дії, які передає потік MBO
Потік MBO — це класифікація дій, що застосовуються до ідентифікаторів заявок. Чотири з них генерують більшу частину трафіку:
- Add (додавання): нова заявка потрапляє в книгу за певною ціною з новим ідентифікатором.
- Modify (зміна): існуючий ідентифікатор змінює ціну або обсяг. Збільшення обсягу або зміна ціни відправляє заявку в кінець черги на новому рівні; зменшення обсягу зазвичай дозволяє зберегти місце в черзі.
- Cancel (скасування): ідентифікатор повністю або частково залишає книгу.
- Trade або fill (виконання): агресивна заявка виконується проти однієї або кількох пасивних заявок, зменшуючи або видаляючи їх.
MBP не містить такої деталізації. Оновлення MBP — це твердження про рівень: на цій ціні тепер такий обсяг. Незалежно від того, чи зменшився обсяг через скасування, чи через виконання, оновлення виглядає однаково. На панелі нижче показано цей ліміт для максимально «тонкої» книги — консолідованого верху книги (top of book), один ціновий рівень на кожну сторону, що в цій номенклатурі відповідає MBP-1.
Точний SQL-код для кожного числа
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)За ці пів години 17.6% повідомлень змінили найкращу ціну купівлі (bid), 17.4% додали обсяг при незмінній ціні bid, 12% видалили обсяг при незмінній ціні bid, а 53% залишили bid без змін, поки інша сторона змінювалася. Кожна група — це підсумкове твердження про ціновий рівень. Жодне з них не називає заявку, і жодна арифметична операція не дозволить відновити втрачений ідентифікатор.
На які питання може і не може відповісти кожна схема
MBP-10 відповідає на питання типу «який обсяг був на рівні»: форма «стакану», дисбаланс книги, ліквідність поблизу середньої ціни, сам графік глибини ринку. Для всього цього достатньо агрегованих рівнів.
MBO відповідає на питання типу «що сталося з цією заявкою»: скільки обсягу було перед вами, коли ви приєдналися, як довго заявки існують до скасування, і яка ймовірність того, що пасивна заявка на найкращій ціні виконається до того, як ціна зміниться. Ці величини не існують в агрегованому вигляді, а підсумовування заявок у загальний обсяг рівня знищує послідовність, яка їх визначала.
Позиція в черзі — найяскравіший приклад, і вона має значення лише за умови пріоритету ціни та часу проти пропорційного виконання (pro-rata), де черговість надходження визначає, хто виконається першим. Важливим є розмір виконаних угод (print size): рівень заповнюється багатьма дрібними виконаннями, а не одним великим.
Точний SQL-код для кожного числа
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)Угоди обсягом менше 100 акцій (odd lot) склали 92.3% від усіх угод у цьому вікні, а найбільша категорія, 1000 or more shares, склала 0.1%. Якщо потік передає такий обсяг на рівень, де відображено 4 000 акцій, заявка, що стала в чергу останньою, може «простояти» через десятки виконань, так і не виконавшись. MBP показує вам 4 000. MBO показує вам чергу.
Жодна схема не показує прихований обсяг. Айсберг-заявка відображає лише невелику частину, яка оновлюється з новим ідентифікатором щоразу, коли ця частина виконується, тому резервний обсяг ніколи не з'являється в жодному повідомленні.
Відновлення книги з MBO як автомат станів
Потік MBP надає вам готову відповідь. Потік MBO надає вхідні дані й очікує, що ви будете абсолютно точними:
- Почніть зі знімка (snapshot) або з порожньої книги та повідомлення про очищення від майданчика.
- Застосовуйте кожну подію додавання, зміни, скасування та виконання в суворій послідовності, використовуючи ідентифікатор заявки як ключ.
- Підтримуйте другий індекс за ціновими рівнями, оскільки саме його зчитує ваша стратегія.
- Слідкуйте за номерами послідовності та виконуйте повторну синхронізацію зі свіжого знімка, якщо якесь повідомлення пропущено.
Режим відмови тут непомітний. Якщо ви пропустите одне скасування, «фантомна» заявка залишиться у вашій книзі до кінця сесії, завищуючи обсяг на цьому рівні, і жодна помилка не буде згенерована. MBP деградує набагато м'якше: кожне оновлення перезаписує загальний обсяг рівня, тому пошкоджене значення буде виправлено протягом кількох повідомлень.
MBO також існує лише у прямих потоках від майданчиків, по одній книзі на кожну біржу, що означає необхідність запуску та об'єднання кількох таких потоків. Консолідована стрічка (consolidated tape) за своєю структурою є зведенням, деталі якого розкриті у SIP проти прямих біржових потоків.
Скільки коштує додаткова деталізація в смузі пропускання
Кількість повідомлень — це чесний спосіб оцінити різницю. На панелі нижче підраховано кількість повідомлень консолідованого верху книги (top-of-book) порівняно з фактичними угодами за той самий фіксований півгодинний інтервал для п'яти відомих компаній.
Точний SQL-код для кожного числа
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 DESCSPY мав найвищий трафік котирувань на одну угоду: 9.6 повідомлень на кожну угоду та 510 тисяч повідомлень за тридцять хвилин. Розкид між п'ятьма назвами великий: внизу панелі MSFT мав 0.7 повідомлень котирувань на угоду — менше одного повідомлення на кожну угоду. Пам'ятайте, що рахує цей стовпець: один ціновий рівень на сторону в потоці, який уже об'єднав усі майданчики в єдину найкращу ціну купівлі та продажу. Продукт з глибиною у десять рівнів множить це значення, а потік на рівні заявок множить його ще більше, оскільки кожна заявка за кожним рівнем на кожному майданчику генерує власне додавання, зміну та скасування, незалежно від того, чи буде вона виконана. Та сама арифметика проявляється у більшому масштабі в обсязі потоку котирувань опціонів.
Який потік книги заявок потрібен стратегії?
Більшість завдань виконується на MBP-10. Графіки глибини, показники дисбалансу, вимірювання ліквідності за ціною, моделі вартості виконання та майже всі дослідницькі питання про те, який обсяг де стояв, можна вирішити за допомогою агрегованих рівнів при значно меншому обсязі повідомлень.
MBO необхідний, коли відповідь залежить від конкретної заявки: позиція в черзі, час життя заявки, поведінка при скасуванні, ймовірність пасивного виконання на найкращій ціні. Стратегія, успіх якої залежить від того, чи стоїть вона на 200 акцій чи на 20 000 акцій у черзі, не може отримати ці дані з агрегованої інформації, і вона платить за це ліцензійними зборами, смугою пропускання, сховищем та інженерними витратами на підтримку коректності відновленої книги протягом дня.
Як були побудовані ці панелі
- Потік, що лежить в основі кожної панелі, — це консолідований верх книги, один ціновий рівень на сторону, плюс стрічка угод. Це не потік глибини ринку і не потік на рівні заявок, тому ці панелі ілюструють аргумент про обсяг повідомлень, а не самі дані MBO.
- Часові вікна зафіксовані на минулій даті: з 10:00 до 10:30 за часом ET 16 червня 2026 року, що відповідає 14:00–14:30 UTC. Фіксовані вікна забезпечують стабільність цифр при повторній генерації.
- Панель класифікації порівнює кожне повідомлення з попереднім у послідовності. Вона не може відокремити скасування від виконання, що є саме тим обмеженням, яке описує ця стаття.
Часті питання
У чому різниця між ринковими даними MBO та MBP?
MBP (market by price) агрегує відображений обсяг на кожному ціновому рівні та надсилає одне оновлення на рівень. MBO (market by order) надсилає кожну окрему заявку з її власним ідентифікатором, а також події додавання, зміни, скасування та виконання, що з нею відбуваються.
Чи є дані Level 2 тим самим, що й дані MBO?
Зазвичай ні. «Level 2» у роздрібного брокера майже завжди означає агреговану глибину, тобто MBP з п'ятьма-двадцятьма ціновими рівнями. Деякі постачальники продають потік на рівні заявок під тією ж назвою рівня, тому саме назва схеми, а не назва рівня, визначає, що саме ви отримаєте.
Наскільки потік MBO більший за потік MBP?
На порядки, залежно від майданчика та інструменту. Лише консолідований верх книги генерував 9.6 повідомлень на одну угоду для найбільш активного інструменту на панелі вище. Потік на рівні заявок додає кожне додавання, зміну та скасування за кожним рівнем на кожному майданчику, включаючи переважну більшість заявок, які ніколи не виконуються.
Чи можна відновити книгу MBP з даних MBO?
Так, це стандартний процес: застосувати кожну подію заявки до книги, де ключем є ідентифікатор заявки, а потім опублікувати підсумки рівнів. Зворотне неможливо: як тільки заявки підсумовані в загальний обсяг рівня, окремі ідентифікатори та черговість їх надходження втрачаються.
Кожна панель тут постачається з точним SQL-кодом, на якому вона побудована. Щоб підрахувати ті самі повідомлення для іншого інструменту або сесії, поставте питання звичайною англійською мовою в терміналі Strasmore.