Разработка алгоритма smart order routing под ключ

Smart order routing: где заявки теряют на фрагментации ликвидности

Крупная заявка почти никогда не находит весь объём в одном стакане. Ликвидность размазана: часть стоит на централизованных биржах, часть — в пулах децентрализованных площадок, часть выставляют маркет-мейкеры. У каждого источника своя глубина, свой спред и свои правила исполнения.

Фрагментация ликвидности сама по себе не проблема — проблема в том, что маршрут выбирается один: по привычке, по лучшей верхней котировке или по самой знакомой площадке. Система видит только тот объём, который лежит на выбранном источнике, и отправляет туда заявку целиком.

Отсюда два класса потерь. Проскальзывание цены: каждый следующий уровень стакана дороже предыдущего, и средняя цена сделки уезжает от той, что была видна в момент принятия решения. Частичное исполнение: глубина площадки заканчивается раньше объёма, и недобранный остаток либо возвращается, либо уходит в повторный запрос уже по сдвинутому рынку.

Дальше эффект накапливается. Повторные заявки конкурируют друг с другом и с чужими алгоритмами, а потеря объёма заявки растёт нелинейно: чем крупнее размер, тем хуже результат выбора одной площадки.

Smart order routing закрывает именно этот разрыв — маршрут собирается динамически, из нескольких источников, под конкретный объём и текущее состояние стаканов. Ниже разбираем, как это устроено и от чего зависит качество исполнения.

Что меняется после внедрения маршрутизации заявок

Первое, что видно уже в первые сутки после включения маршрутизации, — доля исполнения. Заявка перестаёт уходить на одну заранее выбранную площадку: алгоритм оценивает доступный объём на каждой и распределяет её частями, поэтому объём, который раньше оставался неисполненным или снимался вручную, закрывается в том же цикле.

Второй эффект — средняя цена исполнения. Маршрутизатор сопоставляет не только лучшую котировку, но и глубину рынка на каждом уровне, комиссии и ожидаемое проскальзывание, а крупную заявку дробит так, чтобы не выедать один стакан. На дистанции это сдвигает среднюю цену ближе к середине рынка и убирает разовые переплаты на тонких уровнях.

Третий — устойчивость к отказу отдельной площадки. Если подключение рвётся, растёт задержка ответа или падает доступная глубина, маршрут перестраивается на резервные источники, а неисполненный остаток переносится туда с сохранением исходных условий заявки. Отказ одной площадки перестаёт быть событием, требующим ручного вмешательства.

Четвёртый — предсказуемые издержки. Чем точнее распределён объём, тем меньше встречных переводов между площадками и промежуточных конвертаций, а расходы на перемещение средств перестают зависеть от того, кто и в каком порядке выставлял заявки руками.

Дальше метрики стабилизируются: доля исполнения и средняя цена перестают зависеть от того, какой площадке «повезло» в моменте. Появляется наблюдаемость — по каждой заявке видно выбранный маршрут и причину выбора, поэтому изменения в правилах проверяются на истории, а не на ощущениях.

Режимы routing: книга заявок, пулы ликвидности, гибрид

Схемы исполнения отличаются не наличием книги заявок или пулов ликвидности, а тем, кто удерживает ордер в момент сделки и как делится объём. От этого зависит проскальзывание, число частичных заполнений и то, как контур ведёт себя, когда одна из площадок перестаёт отвечать.

Ниже — рабочие варианты, между которыми выбирают при проектировании роутера. Мы не фиксируем схему заранее: сначала смотрим, где стоит ликвидность и насколько предсказуем поток встречных заявок, и только потом предлагаем контур.

Варианты комбинируются: роутер-контракт обычно дополняет разбиение заявки, а внутренний мэтчинг работает поверх гибрида.

Внедрение алгоритма маршрутизации: этапы работ

Маршрутизацию не пишут «в вакууме»: сначала нужно понять, где именно теряется цена исполнения. На входе — цель снизить проскальзывание и стоимость прохода по стакану при заданном лимите времени на сделку. Ниже семь этапов, каждый заканчивается артефактом, который можно проверить и передать вашей команде.

1. Аудит площадок и моделей исполнения. Собираем режимы выставления заявок, правила отмены, лимиты, поведение при обрыве соединения — фиксируем, какие источники ликвидности реально доступны.
2. Схема правил выбора маршрута. Описываем приоритеты: цена, доступный объём, вероятность исполнения, задержка ответа площадки. Правила согласуются письменно до первой строки кода.
3. Прототип ядра. Модуль разбиения крупной заявки на части и пересчёта маршрута при каждом изменении стакана.
4. Интеграции. Единая модель заявки и сделки, обработка частичных исполнений, повторных попыток и отказов площадки.
5. Проверка на исторических данных. Прогон на записанных потоках котировок и сравнение с базовой стратегией: проскальзывание, доля исполненных заявок, поведение на тонком рынке.
6. Предохранители и мониторинг. Лимиты на размер позиции и темп выставления, автоматическое отключение маршрута при отклонении метрик, журнал принятых решений.
7. Передача в эксплуатацию. Конфигурация, документация по правилам, регламент изменений и обучение вашей команды.

Артефакты поставки: ядро маршрутизации, схемы, регламенты

Отдаём не отчёт, а работающий контур умной маршрутизации ордеров, который ваша команда ведёт дальше без нас. Приёмка прикладная: инженеры заказчика сами собирают ядро из репозитория и меняют правила маршрута на тестовом контуре — если это выходит без подсказки, поставка состоялась.

• Исходный код ядра маршрутизации и воспроизводимая сборка: репозиторий, зависимости, тесты на сценарии с низкой ликвидностью и отказом площадки.
• Схема маршрутов: граф площадок и связок, порядок разбиения объёма, приоритеты и условия переключения между маршрутами.
• Конфигурации подключений: параметры сессий, лимиты на объём и частоту обращений, поведение при недоступности источника.
• Политики доступа и ключей: роли, права на правку маршрутов, ротация ключей, разделение сред исполнения.
• Документация алгоритма: критерии выбора маршрута, ограничения модели, карта метрик и трактовка отклонений.
• Регламент мониторинга: перечень метрик качества исполнения, пороги оповещений, дежурные действия.
• Регламент отката: версионирование правил, возврат к предыдущему набору маршрутов, порядок вывода площадки из работы.

Всё передаём вместе с разбором на ваших данных: где узкие места, какие пороги выставлены и почему. Дальше добавление площадок и правка маршрутов идут у вас, без обращения к нам за каждой итерацией.

Кейс: маршрутизация потока заявок между шестью площадками

Клиент — маркет-мейкер, который держал поток заявок на шести площадках. До внедрения маршрут выбирал оператор вручную: сверял таблицы ликвидности, решал, куда отправить объём, и на подвижном рынке это решение отставало от цены. Часть объёма оставалась неисполненной, а сделки уходили по цене заметно хуже ориентира.

Мы собрали единый стакан со всех шести площадок и научили алгоритм распределять объём по доступной ликвидности с учётом комиссий, задержки ответа и риска частичного исполнения. Подключения идут через FIX-шлюзы — это даёт единый поток событий и журнал маршрутов: площадка, вес, причина выбора. Отказ площадки обрабатывается штатно — её вес перераспределяется между оставшимися внутри одного цикла, без ручного вмешательства.

Замеры до и после

Оба замера заказчик проводил сам, на разных периодах и разных наборах инструментов, сравнивая журнал маршрутов с выгрузкой из торговых систем. Оба дали одинаковое направление: доля исполнения выросла, отклонение от ориентира сжалось, а падение одной площадки перестало быть инцидентом — заявки уходили на оставшиеся, качество исполнения не проседало. По этим же замерам видно, куда сместилось узкое место: уже не ручной выбор площадки, а полнота и свежесть входных данных о ликвидности.

Чем отличается маршрутизатор от простого разбиения заявки

Разбиение заявки — арифметика, заданная заранее: объём делится на доли и раскидывается по площадкам по фиксированному правилу. Маршрутизатор считает маршрут на каждом шаге заново: прежде чем отправить очередную часть, он перечитывает состояние книги заявок и пулов ликвидности, а также издержки перевода средств между площадками.

Ключевая разница — в реакции на изменение глубины рынка. Статичная сетка не знает, что на второй площадке ликвидность просела: она продолжит отдавать туда доли и соберёт исполнение по худшим уровням цены. Динамический маршрут проверяет глубину на каждом уровне, сравнивает её с порогом ликвидности и переносит остаток туда, где он закроется целиком, без проскальзывания.

Второй фактор — издержки и риск неисполнения. Перевод средств между площадками занимает время и стоит сетевых расходов, а часть объёма может остаться неисполненной. Маршрутизатор отбрасывает варианты, где выигрыш по цене не перекрывает издержки перевода, и делит остаток так, чтобы каждая часть укладывалась в доступную глубину.

Пересчёт маршрута происходит после подтверждения каждой части, а не один раз на входе. Поэтому пришедший в процессе встречный объём или уход ликвидности с площадки меняют остаток, а не ломают всю заявку. Отраслевой разбор Исполнение крупных заявок на децентрализованных площадках подтверждает: именно пошаговый пересчёт даёт выигрыш на объёмах, сопоставимых с глубиной рынка.

На малых объёмах, которые влезают в первый уровень цены, разница между подходами почти незаметна. На крупных — расходятся доля исполненного объёма, отклонение средней цены от расчётной и доля заявок, закрытых частично.

Технические вопросы: задержки, частичные исполнения, отказ площадки

Маршрутизатор работает там, где часть ответов приходит позже, чем нужно, а часть не приходит вовсе. Ниже — разбор сомнений, которые чаще всего всплывают при проектировании smart order routing.

Как обрабатывается остаток заявки при частичном исполнении?

Остаток не отправляется вслепую: маршрут пересчитывается по доступной глубине, объём дробится между площадками. Если ликвидность исчерпана, остаток либо снимается, либо выставляется лимитной частью по заданной цене.

Что происходит при недоступности площадки?

Площадка проверяется до отправки заявки, а не после. При серии ошибок она автоматически выводится из маршрута на время, зависшие заявки снимаются, поток идёт через оставшиеся направления.

Учитываются ли издержки перевода средств между площадками?

Считаем не только комиссию, но и время перевода и риск не дойти. Если издержки съедают разницу в цене, маршрут через эту площадку не рассматривается вовсе.

Насколько сложно встроить это в уже работающую систему?

Маршрутизатор подключается к вашему шлюзу через адаптер, торговый контур и учёт остаются прежними. Включаем поэтапно: сначала часть потока, с возможностью вернуть обработку на прежний контур.

Что нужно для старта и как мы вернёмся с оценкой

Для оценки алгоритма smart order routing нужен ваш контекст, а не общие пожелания: без входных данных любой план этапов превращается в гадание. Ниже — что достаточно передать на первом шаге. Если часть сведений есть только у трейдера в голове или в старых логах — разберём вместе.

• Перечень площадок и инструментов, между которыми нужно распределять заявки, включая те, что планируются к подключению.
• Текущие правила исполнения: как маршрут выбирается сейчас — вручную, скриптом или внешним сервисом — и что именно в них не устраивает.
• Показатели качества исполнения, которые считаете нормой: доля исполненных заявок, отклонение цены от ожидаемой, время от решения до сделки.
• Ограничения по риску: лимиты на площадку и инструмент, поведение при частичном исполнении, что делать при недоступности одного из направлений.
• Характер потока заявок: частоты, типичные размеры, распределение по времени — это определяет, насколько быстрым должен быть расчёт маршрута.
• Требования к наблюдаемости: какие события и метрики нужно видеть в реальном времени, что хранить для разбора инцидентов.
• Инфраструктурные рамки: где алгоритм будет работать, какие доступы и среды уже есть, кто отвечает за эксплуатацию после запуска.

Дальше порядок такой: обсуждаем задачу, изучаем переданные материалы, проверяем ключевые допущения на исторических данных. Затем возвращаемся с оценкой, планом этапов и составом работ — с явным разделением, что закрываем мы, а что остаётся на вашей стороне.