Разница между данными 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) — это поток событий. Каждое сообщение описывает одну заявку: её ID, сторону, цену, отображаемый объем и произошедшее с ней изменение. Никакой предварительной агрегации нет. Если на одной цене стоят сорок заявок, то сорок отдельных сообщений помещают их туда, и вы должны хранить все сорок в памяти, чтобы знать итоговый объем на этом уровне.
В нашем руководстве по рыночным данным Level 1 и Level 2 мы разбираем, что означают эти розничные уровни у брокера. MBO и MBP — это точные названия того, что находится внутри «черного ящика», когда поставщик говорит «Level 2», и именно о схеме данных стоит спрашивать в первую очередь.
Действия, передаваемые в потоке MBO
Поток MBO — это классификация действий, применяемых к ID заявок. Большую часть трафика составляют четыре из них:
- Добавление (Add): новая заявка поступает в книгу по определенной цене с новым ID.
- Изменение (Modify): существующий ID меняет цену или объем. Увеличение объема или изменение цены отправляет заявку в конец очереди на новом уровне; уменьшение объема обычно сохраняет её позицию.
- Отмена (Cancel): ID покидает книгу полностью или частично.
- Сделка или исполнение (Trade or fill): агрессивная заявка исполняется против одной или нескольких пассивных заявок, уменьшая или удаляя их.
MBP не содержит этого словаря. Обновление MBP — это утверждение об уровне: «на этой цене теперь такой-то объем». Ушел ли объем из-за отмены или из-за сделки, обновление выглядит одинаково. Панель ниже показывает этот лимит на максимально «тонкой» книге — консолидированном верхе стакана (один ценовой уровень с каждой стороны, 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 без изменений, пока другая сторона двигалась. Каждая группа — это итоговое утверждение о ценовом уровне. Ни одно из них не называет ID заявки, и никакая арифметика не позволит восстановить отсутствующий идентификатор.
На какие вопросы отвечает каждая схема
MBP-10 отвечает на вопросы типа «какой объем был там»: форма стакана, дисбаланс книги, ликвидность вблизи середины спреда, сам график глубины рынка. Для всего этого достаточно агрегированных уровней.
MBO отвечает на вопросы типа «что случилось с этой заявкой»: какой объем стоял перед вашей заявкой, когда вы вошли в очередь, как долго заявки остаются в книге до отмены и какова вероятность того, что пассивная заявка на лучшей цене исполнится до того, как цена уйдет. Эти показатели не существуют в агрегированном виде, а суммирование заявок в итоговый уровень уничтожает последовательность, которая их определяла.
Позиция в очереди — самый яркий пример, и она имеет смысл только при приоритете «цена-время» или пропорциональном сопоставлении, где очередность поступления определяет, кто совершит сделку первым. Значение имеет размер сделки (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)Сделки объемом менее ста акций (odd lot) составили 92.3% от всех сделок в этом окне, а самый крупный сегмент, 1000 or more shares, составил 0.1%. Если транслировать сделки такого размера на уровень с отображаемыми четырьмя тысячами акций, заявка, вставшая в очередь последней, может пережить десятки исполнений, так и не совершив сделку. MBP показывает вам четыре тысячи. MBO показывает вам очередь.
Ни одна из схем не показывает скрытый объем. Айсберг-заявка отображает лишь малую часть и каждый раз при исполнении этой части обновляется с новым ID, поэтому резервный объем никогда не появляется ни в одном сообщении.
Восстановление книги из MBO как конечный автомат
Поток MBP дает вам готовый ответ. Поток MBO дает вам исходные данные и ожидает, что вы будете абсолютно точны:
- Начните со снимка состояния (snapshot) или с пустой книги и сообщения об очистке от площадки.
- Применяйте каждое добавление, изменение, отмену и исполнение в строгой последовательности, используя ID заявки как ключ.
- Поддерживайте второй индекс по ценовым уровням, так как именно его считывает ваша стратегия.
- Следите за порядковыми номерами сообщений и запрашивайте новый снимок, если какой-то номер пропущен.
Режим сбоя здесь незаметен. Если вы пропустите одну отмену, «фантомная» заявка останется в вашей книге до конца сессии, завышая объем на этом уровне, и система не выдаст никакой ошибки. MBP деградирует гораздо мягче: каждое обновление пересчитывает итоговый объем уровня, поэтому поврежденное значение будет перезаписано в течение нескольких сообщений.
MBO также существует только в прямых потоках от площадок — по одной книге на биржу, что означает необходимость запуска и объединения нескольких потоков. Консолидированная лента — это сводка по определению, разделение которой описано в SIP против прямых потоков бирж.
Во что обходится дополнительная детализация в полосе пропускания
Количество сообщений — честный способ оценить разницу. Панель ниже сравнивает количество сообщений консолидированного верха стакана с фактическими сделками за те же полчаса для пяти известных компаний.
Точный 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 требуется, когда ответ зависит от конкретной заявки: позиция в очереди, время жизни заявки, поведение при отмене, вероятность пассивного исполнения на лучшей цене. Стратегия, успех которой зависит от того, находится ли она на двухсотой или двадцатитысячной позиции в очереди, не может быть реализована на агрегированных данных, и за это приходится платить лицензионными сборами, полосой пропускания, хранилищем и инженерными затратами на поддержание корректности восстановленной книги в течение дня.
Как были построены эти панели
- Потоком для каждой панели является консолидированный верх стакана (один ценовой уровень с каждой стороны) плюс лента сделок. Это не поток глубины и не поток по каждой заявке, поэтому эти панели иллюстрируют аргумент об объеме сообщений, а не выборку самого MBO.
- Временные окна зафиксированы на конкретной дате в прошлом: 16 июня 2026 года, с 10:00 до 10:30 по восточному времени (ET), что соответствует 14:00–14:30 UTC. Фиксированные окна обеспечивают стабильность цифр при перегенерации.
- Панель классификации помечает каждое сообщение относительно предыдущего в последовательности. Она не может отделить отмену от исполнения — это именно то ограничение, которое описывает данная статья.
Часто задаваемые вопросы
В чем разница между рыночными данными MBO и MBP?
MBP (market by price) агрегирует отображаемый объем на каждом ценовом уровне и отправляет одно обновление на уровень. MBO (market by order) отправляет каждую отдельную заявку с её собственным ID, а также события добавления, изменения, отмены и исполнения, которые с ней происходят.
Являются ли данные Level 2 тем же самым, что и данные MBO?
Обычно нет. «Level 2» у розничного брокера почти всегда означает агрегированную глубину, то есть MBP с пятью-двадцатью ценовыми уровнями. Некоторые поставщики продают поток по каждой заявке под тем же названием уровня, поэтому именно название схемы, а не название уровня, определяет, что именно придет по каналу связи.
Насколько поток MBO больше потока MBP?
На порядки, в зависимости от площадки и тикера. Только консолидированный верх стакана генерировал 9.6 сообщений на сделку для самого активного инструмента на панели выше. Поток по каждой заявке добавляет каждое добавление, изменение и отмену за каждым уровнем на каждой площадке, включая подавляющее большинство заявок, которые никогда не исполняются.
Можно ли восстановить книгу MBP из данных MBO?
Да, это стандартный процесс: применить каждое событие заявки к книге, индексируемой по ID заявки, а затем опубликовать итоговые значения уровней. Обратное невозможно: как только заявки суммируются в итоговый объем уровня, индивидуальные ID и порядок их поступления теряются.
Каждая панель здесь поставляется с точным SQL-запросом, лежащим в её основе. Чтобы подсчитать те же сообщения для другого тикера или сессии, задайте вопрос на обычном английском языке в терминале Strasmore.