Разработка HFT-алгоритма (высокочастотная торговля)

Почему HFT алгоритм не даёт результата на реальных данных

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

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

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

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

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

Что даёт управляемая высокочастотная торговля

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

Предсказуемое время реакции

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

Устойчивость под пиком и управляемый класс отказов

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

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

HFT алгоритм: варианты исполнения и их ограничения

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

Выбор режима работы логики

Тип заявки — отдельное решение внутри режима. Лимитные заявки держат цену, но оставляют риск неисполнения и требуют управления отменой; рыночные закрывают позицию сразу, но на тонком стакане дают проскальзывание.

Совместимость с работающим контуром

Алгоритм редко ставят на пустое место: рядом уже работают шлюз до биржи, учёт позиций и риск-лимиты. Логику разводим по обмену данными — алгоритм получает поток и отдаёт заявки, не затрагивая внутренние структуры существующей системы. Перед запуском сверяем форматы инструментов, правила риск-контроля и порядок отмены заявок, чтобы старый контур не блокировал новые.

Этапы внедрения: от аудита данных до передачи

Работу выстраиваем так, чтобы ни одно решение не попадало в живой контур, пока не проверено на данных. Порядок этапов одинаков и для нового HFT алгоритма, и для переработки уже работающего:

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

Проверка на истории: что считаем доказательством

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

Приёмка и передача решения

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

Комплект поставки: конфигурации, схемы, регламенты

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

Конфигурации, схемы и доступы

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

Регламенты и документация

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

Комплект собирается под ваш контур: если часть систем уже работает, встраиваемся в них, а не дублируем.

Разбор внедрения: метрики до и после

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

Где система теряла время

Узкое место оказалось не в модели, а в обвязке. Рыночные данные и заявки шли одним потоком с синхронными проверками риска: задержка в журналировании блокировала весь цикл, а очередь команд росла быстрее, чем обрабатывалась. Часть задержки снималась на сетевом уровне — приём потока перевели на адаптеры Solarflare с аппаратной обработкой пакетов.

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

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

Чем низкая задержка отличается от высокой частоты заявок?

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

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

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

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

Ограничения, риски и частые вопросы

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

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

Кто отвечает за сбой внешнего поставщика данных?

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

Как проверяете стратегию до запуска на реальном объёме?

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

Какой сбой считается худшим и что тогда?

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

Обсудим задачу: разбор гипотезы и план работ

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

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

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

На выходе вы получаете:

• карту гипотезы: где логика чувствительна к качеству данных и к задержке реакции;
• план работ по этапам с точками контроля и метриками приёмки;
• сценарии отката и порядок аварийной остановки алгоритма.

Опишите задачу — вернёмся с оценкой и планом работ.