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

Чому HFT алгоритм не дає результату на реальних даних

HFT алгоритм, який гарно виглядає на історичних даних, найчастіше ламається не в математиці, а на стику з реальною інфраструктурою біржі.

У високочастотній торгівлі результат визначає не сама модель, а те, наскільки точно вона бачить ринок і наскільки швидко її рішення доходять до книги заявок. Розглянемо три місця, де логіка перестає працювати.

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

Затримка відгуку накопичується по всьому ланцюжку «приймання — розбір — розрахунок — відправлення», і на виході виходить рішення за ціною, якої на ринку вже немає.

Друге — виконання заявок. У тестовому прогоні заявка зазвичай спрацьовує миттєво й повністю за ціною з котирування.

У реальності вона стає в чергу, де пріоритет визначається часом подання, частина обсягу не набирається, а лімітна заявка залишається висіти після того, як можливість зникла. Звідси розбіжність між розрахунковою та фактичною ціною входу.

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

Тому робота над HFT алгоритмом починається не з оптимізації дохідності, а з вимірювань: де саме втрачається час, як формується черга на виконання, за яких режимів стратегія деградує. Нижче розбираємо, як ці місця закриваються в реалізації.

Що дає керована високочастотна торгівля

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

Передбачуваний час реакції

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

Тому поведінка системи на спокійному ринку та в момент сплеску відрізняється в межах заданого коридору, а не на порядок.

Стійкість під піком і керований клас відмов

Навантажувальні перевірки задають стелю: видно, за якої кількості одночасних подій контур починає відставати, і цей запас закладається з кратним перевищенням до звичайного дня.

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

Контроль ризиків описує, що відбувається при збої: обрив каналу, відмова вузла або розсинхронізація даних ведуть не до серії помилкових заявок, а до зупинки стратегії та коректного закриття позиції.

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

HFT алгоритм: варіанти виконання та їхні обмеження

Режим роботи торгової логіки визначає решту: вимоги до обробки потоку ринкових даних, до ризик-контролю і до того, як алгоритм виставляє заявки.

Один і той самий HFT алгоритм не можна без переробки переключити з підтримання котирувань на арбітраж цін — змінюється горизонт утримання позиції та характер навантаження на біржовий шлюз.

Вибір режиму роботи логіки

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

Сумісність із працюючим контуром

Алгоритм рідко ставлять на порожнє місце: поруч уже працюють шлюз до біржі, облік позицій і ризик-ліміти. Логіку розводимо за обміном даними — алгоритм отримує потік і віддає заявки, не зачіпаючи внутрішні структури наявної системи.

Перед запуском звіряємо формати інструментів, правила ризик-контролю та порядок скасування заявок, щоб старий контур не блокував нові.

Етапи впровадження: від аудиту даних до передачі

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

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

Перевірка на історії: що вважаємо доказом

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

Приймання та передача рішення

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

Передаємо вихідні коди, схему контуру, регламент запуску та зупинки, а також порядок дій при збої — команда замовника далі веде систему самостійно.

Комплект постачання: конфігурації, схеми, регламенти

Після здачі в команди замовника залишається не «працюючий екземпляр на нашому сервері», а комплект, за яким систему можна розгорнути, перевірити й розвивати власними силами. Усе, що налаштовувалося під час проєкту, фіксується в репозиторії та передається разом із доступами.

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

• Конфігурація системи: файли середовищ, параметри підключення до бірж і брокерів, ліміти за інструментами та обсягами, налаштування ризик-контролю.
• Схема потоків даних — від ринкового фіду до виставлення заявки, з точками, де можливі затримки та розрив з'єднання.
• Політики доступу: ролі, права на зміну стратегії, розділення середовищ, порядок видачі та відкликання ключів.
• Набір перевірок: як переконатися, що після правок HFT алгоритм поводиться так само, як на еталоні.
• Інструкція з розгортання на чистому середовищі — від встановлення залежностей до першого запуску.

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

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

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

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

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

Де система втрачала час

Вузьке місце виявилося не в моделі, а в обв'язці. Ринкові дані та заявки йшли одним потоком із синхронними перевірками ризику: затримка в журналюванні блокувала весь цикл, а черга команд зростала швидше, ніж оброблялася.

Частину затримки знімали на мережевому рівні — приймання потоку перевели на адаптери Solarflare з апаратною обробкою пакетів.

Сигнали, ризик-контроль і відправлення заявок рознесли за незалежними контурами: ліміти перевіряються за заздалегідь порахованим станом рахунку й не блокують приймання даних.

Гарячий шлях переписали без динамічних структур, додали звірку ключа ордера — дублюючі заявки перестали йти.

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

Чим низька затримка відрізняється від високої частоти заявок?

Це дві незалежні характеристики, і плутати їх дорого. Низька затримка — скільки часу проходить від ринкової події до виходу заявки, частота заявок — скільки їх іде за одиницю часу.

Контур можна зробити дуже швидким, але вузьким, або широким, але із помітною реакцією на подію; вибір завжди про пріоритет.

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

Пропускна здатність важлива в стратегіях, де рахують обсяг: щільні драбини заявок, супровід багатьох інструментів, утримання потрібної частки присутності.

Вузьким місцем стає не швидкість одного запиту, а черга заявок — підтвердження надходять потоком, а алгоритм, який чекає кожне, втрачає темп. Тут рятують пакетне відправлення, асинхронна обробка відповідей і коректний розбір обмежень площадки на частоту.

Тому контур часто розділяють: тонкий шар для термінових рішень тримається поруч із площадкою, а облік позицій, контроль ризику та масові перестановки йдуть в окремий потік і спілкуються з першим через чергу.

Затримку вимірюють за перцентилями, а не за середнім — рідкісні сплески в хвості обходяться дорожче за рівний фон.

Обмеження, ризики та часті запитання

Площадка задає рамки жорсткіше, ніж здається на етапі прототипу: ліміт заявок за секунду, мінімальний крок ціни, правила зняття заявок і автоматичне вимкнення при виході за ризик-профіль.

Частина цих правил змінюється без окремого анонсу, тому HFT-алгоритм тримає ліміти в конфігурації адаптера площадки, а не в ядрі логіки. Інакше стратегія ловить відмови заявок і втрачає позицію на рівному місці.

Друге джерело ризику — аномальний ринок: розрив ліквідності, стрибок ціни, зупинка торгів.

Логіка, розрахована на рівний потік, у такі моменти поводиться непередбачувано, тому запобіжники закладаються заздалегідь: пауза при відхиленні ціни, зняття завислих заявок, денний ліміт збитку та відновлення позиції після розриву з'єднання.

Хто відповідає за збій зовнішнього постачальника даних?

Відповідальність провайдера майже завжди обмежена застереженням про збої, тому дублювання — на нашій стороні: два незалежні канали котирувань і звірка потоків. При розбіжності вище порогу алгоритм переходить у стоп-режим замість торгівлі за пошкодженими даними.

Як перевіряєте стратегію до запуску на реальному обсязі?

Спочатку прогін на історичних даних із відновленою книгою заявок, включно з днями з аномаліями. Потім тіньовий режим на живому ринку без виставлення заявок — звіряємо рішення алгоритму з фактом. Тільки після цього ліміт обсягу піднімається сходинками.

Який збій вважається найгіршим і що тоді?

Розрив з'єднання з утримуваною позицією: без контролю вона залишається відкритою. Тому в алгоритмі є сторожовий таймер серцебиття зв'язку та план виходу — зняття заявок, фіксація позиції за ринком, зупинка до ручного підтвердження.

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

Щоб обговорити задачу предметно, не потрібна презентація — достатньо того, як стратегія працює зараз. Чим точніші вихідні дані, тим швидше оцінка проєкту перетворюється на план, а не на список припущень.

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

Далі працюємо в три кроки. Спочатку перезбираємо логіку на історичних даних і перевіряємо, чи відтворюється результат при повторних прогонах. Потім готуємо пілотне впровадження в режимі спостереження: алгоритм рахує рішення, але не надсилає заявки. У реальний контур потік виводимо лише після збігу розрахункових і фактичних результатів.

На виході ви отримуєте:

• карту гіпотези: де логіка чутлива до якості даних і до затримки реакції;
• план робіт за етапами з точками контролю та метриками приймання;
• сценарії відкату та порядок аварійної зупинки алгоритму.

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