Почему HFT бот теряет результат на пиковой нагрузке
HFT бот не «ломается» целиком — он теряет результат постепенно, по мере роста нагрузки. Пока поток котировок умеренный, задержка отклика бота держится в привычных рамках, и модель исполнения заявок совпадает с расчётной. На пиковой нагрузке на площадке — выход статистики, аукцион открытия, каскад срабатываний по стопам — время между сигналом и постановкой заявки растёт в разы, и стратегия начинает работать по устаревшей картине рынка.
Вторая точка отказа — проскальзывание заявок. В момент резкого движения плотность в стакане падает: цена проходит несколько уровней, пока заявка доходит до площадки, и исполнение приходит хуже расчётного. Чем выше частота решений, тем сильнее расхождение между модельной и фактической ценой входа — позиция уже открыта, а ожидаемое преимущество съедено движением.
Третий сбой — обрыв связи в самый неудачный момент. При пиковой волатильности лимиты площадки на число сообщений выбираются быстрее, чем в спокойном режиме: бот теряет поток данных, локальная копия книги заявок расходится с биржевой, а после переподключения часть ордеров остаётся вне контроля. Каждая такая минута — это открытые позиции без управления и просадка стратегии, которую потом приходится отыгрывать вручную.
Разбираем, как это закрывается: где измерять задержку по этапам — от приёма котировки до подтверждения исполнения, как переподключаться без потери состояния книги и какие ограничения по риску останавливают бота раньше, чем расхождение превращается в потерю.
Что даёт внедрение: скорость отклика, отказы, контроль риска
Торговый модуль оценивают не по скорости отправки заявки, а по тому, сколько заявок доходит до сделки. Доля исполненных заявок зависит от актуальности локальной копии книги заявок и от обработки частичных исполнений: если состояние расходится с биржевым, часть заявок отклоняется уже на площадке. После переработки очереди и сверки состояния доля исполненных заявок выросла с 78% до 94% на том же потоке сигналов.
Снижение просадки даёт не скорость сама по себе, а порядок в риск-лимитах. Когда лимиты по позиции, по убытку на сделку и по убытку за интервал проверяются до отправки заявки, а не после ответа площадки, модуль перестаёт догонять рынок серией запоздалых срабатываний. Предсказуемое поведение лимитов убрало всплески, из-за которых просадка на интервале доходила до 9%.
Отдельный класс отказов — разрыв канала. HFT-бот обменивается с площадкой служебными пакетами, при обрыве автоматически переподключается, снимает неактуальные заявки и сверяет позицию по протоколу FIX. Раньше после обрыва модуль мог открыть вторую позицию по тому же сигналу — теперь этот класс отказов закрыт.
Мониторинг торгового модуля строится на четырёх метриках: время отклика, глубина очереди заявок, расхождение локальной и биржевой позиции, число отклонённых заявок. Алерт приходит до того, как расхождение превращается в незапланированную позицию, — контроль риска перестаёт быть реактивным.
Режимы работы: автономный, полуавтономный, арбитражный
Режим определяется не столько стратегией, сколько точкой, в которой принимается решение: кто выставляет заявку в момент срабатывания сигнала и сколько шагов остаётся до сделки. Один и тот же расчётный модуль в автономном и полуавтономном контуре даёт разный профиль риска, поэтому режим мы фиксируем до разработки — иначе изменения приходится вносить в уже работающую логику.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Автономный режим торговли | Стратегия формализована до правил: вход, размер позиции, стоп считаются по котировкам без участия человека | Ошибка в логике тиражируется с той же скоростью, что и результат; нужен внешний контур контроля, жёсткие лимиты и аварийный останов |
| Полуавтономный режим | Сигналы считает система, решение подтверждает человек — либо бот подстраховывает ручную позицию | Реакция ограничена скоростью оператора: часть сигналов уходит, статистика смещается в сторону более спокойных сценариев |
| Кросс-площадочный арбитраж | Одна и та же пара торгуется на нескольких площадках, и расхождение цен перекрывает издержки входа и выхода | Требует синхронного доступа к нескольким источникам котировок и резервов на каждой площадке; окно расхождения живёт недолго |
Что проверяем до выбора режима
Общий знаменатель для всех трёх контуров — ограничения ликвидности. Заявка, которая на истории исполнялась мгновенно, на живом рынке двигает цену, и часть прибыли съедает проскальзывание. Поэтому расчётный модуль прогоняем на записи котировок с реалистичной глубиной, а размер позиции ограничиваем долей от оборота площадки, а не только математическим оптимумом стратегии.
Режим не обязательно постоянный: типовой маршрут — старт в полуавтономном контуре, подтверждение статистики на ограниченном объёме, затем перевод в автономный с сохранением ручного останова. Опишите свою стратегию — вернёмся с оценкой, какой контур под неё подходит и какие лимиты закладывать.
Этапы разработки: от разбора стратегии до запуска
Разработка торгового бота начинается не с кода, а с формализации стратегии: пока правило входа и выхода существует только в голове, его нельзя ни проверить, ни ограничить по риску. Ниже — порядок работ, где каждый следующий этап опирается на артефакты предыдущего, поэтому ошибка в расчёте сигнала обнаруживается на ранних шагах, а не на живом счёте.
- Разбор стратегии. Фиксируем условия входа и выхода, работу с частичным исполнением и поведение в моменты, когда поток заявок рвётся.
- Схема потоков данных. Определяем, откуда приходят котировки, как накапливается история сделок и где проходит граница между расчётным модулем и исполнением.
- Сборка модуля. Реализуем расчёт сигналов, управление заявками и журналирование — так, чтобы каждое решение оставляло след для разбора.
- Проверка на исторических данных. Прогоняем стратегию на накопленном потоке с учётом комиссий и проскальзывания; смотрим не только результат, но и просадку.
- Настройка риск-лимитов. Задаём предельную позицию, дневной стоп, ограничение по числу заявок и автоостановку при отклонении от расчётного поведения.
- Тестовый запуск на живом потоке. Работаем в режиме наблюдения без реального исполнения, сверяя расчётные сигналы с фактическим рынком.
- Передача и сопровождение. Отдаём конфигурации, журналы, схему потоков и порядок аварийной остановки; далее — регламент обновления стратегии.
Что передаём на выходе: конфигурации, логика риска, регламенты
Проект закрывается не демонстрацией работающего HFT-бота, а передачей комплекта, по которому ваши инженеры смогут сопровождать его и разбирать инциденты без нас. Артефакты лежат рядом с кодом в системе контроля версий и обновляются вместе с ним — иначе документация быстро расходится с реальным поведением системы.
- Конфигурации всех модулей — параметры стратегии, лимиты, пороги, таймауты — в версионируемых файлах, с пояснением, что меняет каждая настройка и где её рабочий диапазон.
- Схема потоков данных от источника рыночных данных до выставления заявки: точки, где сообщение может потеряться или прийти с опозданием, и как система это обнаруживает.
- Логика риск-контроля послойно: лимит на позицию и на инструмент, стоп по дневному результату, автоматическое снятие заявок и полная остановка торговли по заданным условиям.
- Документация на каждый модуль: назначение, входы и выходы, зависимости, поведение при отказе соседнего узла.
- Журнал событий: состав записей, детализация, срок хранения, порядок восстановления хронологии инцидента по логу.
- Регламент при сбое: последовательность действий дежурного, переключение на резервный контур, откат на предыдущую конфигурацию.
- Стенд приёмочных проверок на исторических данных: набор сценариев, которые обязаны проходить перед каждым обновлением стратегии.
Комплект рассчитан на независимое сопровождение: без доступа к нашей инфраструктуре, без устных договорённостей и с единым порядком разбора любого сбоя. Дальше бота развивает ваша команда — либо мы, если решите оставить поддержку на себе.
Кейс: HFT бот для поддержания котировок — метрики до и после
Что было до
Команда держала котировки по нескольким инструментам сразу на трёх площадках. Торговое ядро работало по таймеру: пересчёт цен и выставление заявок шли одним циклом, без разделения на расчёт и исполнение. На спокойном рынке это не мешало, но на резких движениях проскальзывание доходило до 18–25 базисных пунктов, а число ошибочных срабатываний — до 40–60 в сутки. После разрыва соединения бот поднимали руками, восстановление занимало от 20 до 40 минут.
Узкое место
Расчёт котировки и отправка заявок жили в одном потоке. Если площадка отвечала медленнее, чем шёл пересчёт, очередь заявок копилась, и бот отдавал их по уже устаревшей цене — отсюда проскальзывание и лишние сделки. Автоматической защиты от разрыва не было: только внешний мониторинг, который сообщал о падении постфактум. Ядро собрали на базе Hummingbot, но переписали контур исполнения под свои правила риска.
Что изменили и какие метрики получили
Разделили контур расчёта и контур исполнения, добавили локальный стакан с отметкой времени и правила отмены заявки по возрасту и отклонению от целевой цены. Резервный канал связи переключается автоматически, позиции переносятся без ручного вмешательства.
- проскальзывание: 18–25 → 3–6 базисных пунктов на сделку;
- ошибочные срабатывания: 40–60 → 2–4 в сутки;
- время восстановления после обрыва: 20–40 минут → 40–90 секунд;
- доля отмен, успевших пройти до исполнения: 88% → 97%.
Через месяц работы на проде команда перешла на дежурство по отклонениям: ручных перезапусков не потребовалось ни одного.
Что делать, если торговый модуль уже работает на площадке?
Работающий на площадке модуль высокочастотной торговли (HFT) — это не повод переписывать всё заново. Сначала нужен разбор текущей логики: как формируются сигналы, где расставлены предохранители по риску, что происходит при обрыве связи с биржей и как ведёт себя модуль при частичном исполнении заявки.
Аудит торговой логики идёт по фактическому поведению, а не по чужой документации. Мы снимаем журналы заявок и сделок за представительный период, сверяем их с заявленной стратегией и находим места, где решение отклоняется от неё: устаревшие условия входа, обход риск-ограничений, обработка редко повторяющихся ситуаций, после которых позиция остаётся открытой дольше, чем задумано.
Доработка существующего модуля строится так, чтобы не останавливать торговлю. Изменения выносятся в отдельные слои — расчёт сигнала, исполнение, контроль позиции — и включаются переключателем режима. Новая логика сначала идёт параллельно на теневом потоке данных и на исторических прогонах; пока результаты не совпадут с ожидаемыми, в рынок уходит прежняя ветка.
Передача в сопровождение — отдельный шаг, и это не просто передача исходного кода. Нужна рабочая система: описание фактической конфигурации, схема потоков данных, перечень аварийных сценариев с порядком действий, регламент обновлений и понятная точка отката на предыдущую сборку.
На выходе заказчик получает модуль, который можно менять частями, а не целиком, и команду, понимающую, почему в нём принято то или иное решение. Опишите, что уже работает на площадке, — вернёмся с оценкой и планом.
Технические сомнения до старта: задержки, лимиты, надёжность
До старта обычно проверяют четыре вещи: как площадка ограничивает частоту запросов, что делает бот при обрыве канала, кто отвечает за систему после релиза и насколько нестандартно выглядит торговый интерфейс. Ниже — короткие ответы; по каждой площадке они уточняются на этапе доступа к тестовому контуру.
Как бот живёт внутри лимитов площадки?
Лимит площадки — это не только число сообщений в секунду, но и суточные квоты на отмены, ограничение на количество активных заявок и штрафные паузы за их превышение. В ядро закладываем собственный планировщик с весами запросов: при подходе к порогу часть заявок уходит пачками, а избыточные отмены перестраиваются. Ограничение перестаёт быть источником случайных блокировок аккаунта.
Что происходит при разрыве связи?
Бот ведёт локальный журнал состояния и помечает каждую заявку идентификатором, по которому повторная отправка не создаёт дубль. После восстановления канала он сверяет свою картину с биржевой, снимает осиротевшие ордера и только затем возвращается к торговле. Отдельный сценарий — аварийный «плоский режим»: закрытие позиций и остановка стратегии без ручного вмешательства.
Что входит в сопровождение после запуска?
Передаём конфигурации, схему развёртывания и регламент дежурства, дальше ведём систему по согласованному окну реакции: смотрим задержки исполнения, долю отклонённых заявок и расхождение с биржевым состоянием. Алерты приходят до того, как отклонение станет убытком, а изменения стратегии проходят через тестовый контур.
А если у площадки нестандартный интерфейс?
Часть площадок вместо FIX отдаёт собственный бинарный формат или ограниченный набор вызовов. Под такое пишем отдельный адаптер и прогоняем его на записях реального трафика, включая ошибки и частичные ответы. Смена интерфейса площадки тогда закрывается правкой одного модуля, а не переписыванием логики.
Обсудим задачу: пришлём оценку, план и состав работ
Оценку и план работ мы собираем из вашей логики торговли, а не из общего описания «нужен HFT-бот». Первый разбор — короткий созвон с вашим трейдером или квантом: инструменты, горизонт удержания позиции, правила входа и выхода, допустимая просадка. Дальше идём по шагам, и на каждом понятно, что требуется от вас и что вы получаете на выходе.
- Постановка, 1–2 дня. Фиксируем правила входа, выхода и риск-лимиты; на выходе спецификация, которую вы подтверждаете письменно.
- Данные, 2–3 дня. История сделок и котировок, журналы прошлых версий, описание инструментов. Чего нет — считаем по имеющемуся и помечаем допущения прямо в оценке.
- Доступы, параллельно. Тестовый контур брокера, ключи только на чтение и на торговлю в песочнице, отдельный счёт для проверок. Боевые ключи не запрашиваем до приёмки.
- Оценка и план, 3–5 дней. Документ: этапы, результат каждого этапа, состав команды, внешние зависимости и риски с вариантами обхода.
- Проверка на истории, 2–4 недели. Прогоняем логику на ваших данных и показываем, где расхождение — в правилах, в данных или в исполнении.
Оценка приходит в виде плана работ с составом команды и зоной ответственности каждого. Формат передачи — репозиторий, документация по конфигурации, регламент запуска и отката; данные и доступы остаются у вас. Опишите задачу — вернёмся с оценкой и планом.
