Чому 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 тижні. Проганяємо логіку на ваших даних і показуємо, де розбіжність — у правилах, у даних чи у виконанні.
Оцінка надходить у вигляді плану робіт зі складом команди та зоною відповідальності кожного. Формат передачі — репозиторій, документація з конфігурації, регламент запуску та відкату; дані й доступи залишаються у вас. Опишіть задачу — повернемося з оцінкою та планом.
