Встать за чужой заявкой: пассивное исполнение без прогноза

Пассивное исполнение обычно начинается с неприятного вопроса: где поставить лимитную заявку, чтобы ее исполнили, но не исполнили ровно перед плохим движением цены? На него принято отвечать еще одной моделью: оценить очередь, вероятность fill, краткосрочный сигнал, риск adverse selection, затем оптимизировать. Статья Vincent Maciejewski про Shadow-PPOV предлагает почти вызывающе скромный ход: не угадывать. Увидели чужую новую заявку - поставили свою по той же цене и на той же площадке, записав связь с ее order-ID. Чужой ордер живет - ваш стоит за ним; чужой отменен - ваш отменяется.
Это не магия и не бесплатный обед. Это способ превратить решение о размещении из предсказания в наблюдение за уже совершенным действием другого участника. В полном годовом replay фьючерса CME ES автор сравнивает такой пассивный алгоритм с агрессивным эквивалентом POV. Результат интереснее рекламного лозунга: метод годится как честный baseline для моделей, но его сила целиком держится на качестве событий, идентификаторах и задержке. Иначе вы не "идете за информированным ордером", а очень быстро догоняете его тень.
Почему пассивный ордер часто получает билет именно на плохой поезд

Лимитная покупка на лучшем биде экономит спред. В идеальном учебнике это почти комплимент ликвидности: кто-то пришел продать немедленно, вы терпеливо купили дешевле середины. В реальном стакане сделка часто содержит информацию. Если поток продаж вызван тем, что участник быстрее вас увидел ухудшение, ваша покупка исполняется перед снижением mid. Спред вы формально заработали, направление - нет.
Именно это называют adverse selection. Важна не средняя вероятность fill сама по себе, а условная: что происходит с ценой после fill и что за поток привел к нему. У пассивного ордера есть еще одна проблема: он стоит в очереди. Видимые объемы перед ним могут исчезнуть от сделок или отмен; без order-level сообщений нельзя достоверно сказать, какое из двух событий приблизило вас к исполнению.
Обычный алгоритм пытается решить это статистикой: признаки L2, imbalance, интенсивность отмен, короткая альфа, модель времени до fill. Полезно, но опасность прозрачна. Чем богаче модель, тем легче ей выучить особенности конкретного режима, реконструкции или фида. Shadow-PPOV не заявляет, что информация исчезла. Он говорит ровно обратное: решение наследует информацию из наблюдаемого действия - кто-то только что поставил капитал по конкретной цене.
Это тонкое отличие. Стратегия не утверждает, будто чужая заявка "умная". Она лишь проверяет, дает ли дисциплинированное следование наблюдаемым добавлениям достойную точку отсчета против агрессивного POV. Если предиктор не превосходит этот baseline с учетом комиссий, latency и рисков, его сложность пока не заработала себе право на жизнь.
Shadow-PPOV: тень у ордера, а не прогноз в голове

Алгоритм читает каждое сообщение стакана. Когда на нужной стороне появляется чужая limit-заявка, он может послать собственную по той же цене на том же venue. Между ними сохраняется одна ассоциация: observed_order_id -> my_order_id. Это и есть "тень". Ставка участия привязана не к уже наторгованному объему, как в обычном POV, а к наблюдаемому потоку добавлений, поэтому автор называет схему passive percentage of provided volume, или PPOV.
Жизненный цикл важнее красивой аббревиатуры. Чужая отмена означает немедленную отмену тени. После сделки по чужому ордеру используется короткое grace-окно: сообщение о сделке может означать частичное исполнение, а оставшаяся часть ордера еще существует; после окна тень также снимается. Цену, площадку и решение оставить ликвидность алгоритм не выводит из функции. Он берет их из факта, который уже произошел.
За это платят намеренной пассивностью. Тень встает за наблюдаемой заявкой в FIFO-очереди, поэтому не притворяется, что заполнит ее объем. И она не пытается поддержать расписание любой ценой. В тихом рынке или в одностороннем потоке недобор может оказаться существеннее, чем сэкономленный спред. Здесь полезно отделять тактику от цели: Shadow-PPOV - правило размещения дочерних пассивных ордеров, а не обещание завершить большой parent-order к дедлайну.
В этом есть здоровая инженерная ирония. Иногда лучшая первая версия модели fill - не еще один классификатор, а хорошо обработанное событие add и очень короткий список условий, когда надо уйти.
Что означает полный год CME replay - и чего он не означает

В статье схема тестируется на полном календарном годе переигранных CME ES futures в детерминированном order-book simulator. Это сильнее демонстрации на нескольких спокойных сессиях: у года есть открытия, новости, roll-периоды, тонкие часы и дни, когда стакан ведет себя так, словно заранее прочитал ваш код. Автор сообщает slippage, чувствительность к задержке и сопоставление с агрессивным POV, а реализация симулятора и алгоритма опубликована в kaspar-hft.
Но replay не делает эксперимент контрфактической реальностью. Исторический поток фиксирован; наша заявка не меняет поведение остальных и не конкурирует с реакциями, которые ее появление могло бы вызвать. Детерминированный симулятор полезен именно тем, что политика сравнивается на одинаковом пути событий, а не тем, что он доказывает будущую доходность.
Контекст смены режимов делает этот вывод еще важнее. В работе Moret и Lillo о market making поток заявок описан как эпизодический, направленный и режимно-зависимый; контроллеры, обученные на стационарном потоке, могут упереться в inventory saturation при устойчивом дисбалансе. Это другая задача и другой симулятор, но предупреждение переносится аккуратно: наблюдаемая заявка не является вечным сертификатом качества. В режиме метаордера множество похожих добавлений может быть следствием одного настойчивого участника, а не независимых голосов рынка.
Практически я бы смотрел не только на средний shortfall, но и на conditional slices: время суток, скорость отмен, направление недавних сделок, длина жизни исходного ордера, доля недоисполнения. Если эффект есть только в одной красивой корзине, год в заголовке его не спасает.
Order-ID и latency: место, где простая идея становится системной задачей

Shadow-PPOV требует market-by-order данных с устойчивыми exchange order-ID. L2-снимка недостаточно: он показывает, что объем на уровне уменьшился, но не говорит, какой именно ордер отменен и был ли он тем самым, за которым вы стоите. Подмена идентификатора эвристикой по цене и объему меняет природу метода: связь становится догадкой, а не наблюдаемым фактом.
Вторая уязвимость - задержка. Между получением чужого add, отправкой своей заявки и подтверждением биржи очередь уже выросла, цена могла сдвинуться, а исходный ордер - исчезнуть. Между получением cancel и снятием собственной тени вы можете остаться один на уровне, который первоначальный участник уже счел плохой идеей. Поэтому latency sensitivity в статье - не сервисный график, а часть экономического результата.
Минимальный production checklist выглядит прозаично: измерять feed-to-decision, decision-to-ack и cancel-to-ack отдельно; обрабатывать out-of-order и gap в фиде; иметь kill rule при потере последовательности; логировать исходный ID, собственный ID и причину каждого cancel. Нужны и ограничения на exposure по цене, времени жизни и доле участия. Без них стратегия может стать коллекционером старых теней.
Итог не в том, что прогнозы больше не нужны. Shadow-PPOV полезен потому, что сужает вопрос: способен ли ваш сложный placement model обыграть простой, воспроизводимый и order-aware baseline? Если да - отлично, покажите разницу по режимам и задержкам. Если нет, стакан только что сэкономил вам несколько недель настройки гиперпараметров.
Источники
- Vincent Maciejewski, "Model-Free Passive Execution via Order-Level Shadowing", arXiv:2609.18019, 2026. Основной источник: определение Shadow-PPOV, CME ES replay, сравнение с агрессивным POV и ограничения latency.
- Felipe Moret, Fabrizio Lillo, "Deep Learning of Robust Market Making under Regime-Switching Order Flow", arXiv:2609.11614v1, 2026. Использован только как контекст нестационарного и направленного order flow.
- Исходный код, упомянутый автором основной статьи: kaspar-hft.
Авторы
Инженер торговых систем
Разработка торговых ботов с 2017 года: межбиржевой арбитраж (подключал до 30 бирж), парный арбитраж на коинтеграции между спотом и фьючерсами, скальпинг, фронтраннинг, торговля по новостям, сентиментный анализ, трендовые алгоритмы, а также алгоритмы управления и балансировки портфелей. Делает выставление ордеров до 1 мс, warehouse для big data, бэктестинг-движки, AI-агентов и интерфейсы для ботов (в т.ч. open-source profitmaker.cc). Стек: JS/TS, Python, Rust/Zig/Go, DevOps, backend, frontend, архитектура.