Чому арбітражний бот втрачає прибуток на різких рухах ринку
Різкий рух ринку — це не «поганий день», а перевірка архітектури на міцність. Поки арбітражний бот рахує сигнал, ціна між майданчиками встигає розійтися: спред, який був на момент виявлення можливості, до виставлення заявок уже закритий.
Затримка рішення в частки секунди обертається просковзуванням ціни — угода йде на 0.3–0.8% гірше за розрахункову, і цього достатньо, щоб прибуток стратегії обнулився. Особливо помітно на ліквідних майданчиках на кшталт Binance, де імпульс відпрацьовується за одну-дві секунди.
Друга точка втрат — збій виконання заявок. На імпульсі ліквідність з одного боку книги здувається, майданчик обмежує частоту запитів, надходить часткове заповнення — і нога пари залишається незакритою.
Замість нейтральної позиції власник стратегії отримує спрямовану, а розрахунковий спред перетворюється на незапланований ризик, який доводиться закривати вже за ринком.
Окремий шар — модель. Навчена на спокійних даних, вона на сплеску волатильності бачить входи за межами навчальної вибірки: впевненість падає, сигнал надходить із запізненням або не надходить узагалі.
Далі вмикається простій стратегії: години, коли ринок дає найкраще співвідношення руху й витрат, бот проводить поза ринком — і втрати від такого простою можна порівняти із серією збиткових угод.
Розбираємо, як закривається кожна ділянка: бюджет затримки на всьому шляху від приймання даних до надсилання заявки, політика виконання з контролем просковзування, обробка відмов і часткових заповнень, а також контури контролю моделі, які виводять її з торгівлі в разі виходу за межі навчального розподілу.
Що змінюється після впровадження: швидкість рішення та контроль ризику
Перше, що видно після запуску в робочому режимі, — точність сигналів.
Модель оцінює не лише розходження цін між майданчиками, а й ліквідність інструмента, ширину спреду та історію виконання схожих угод, тому частка сигналів, доведених до реальної угоди, зростає, а хибні спрацювання на новинних сплесках відсікаються до виставлення заявки.
Другий вимірюваний показник — частка виконаних заявок. Система заздалегідь рахує доступний обсяг, розбиває великий вхід на частини й перераховує залишок у разі часткового виконання, замість того щоб залишити висячий ордер і неправильну позицію. Із журналу видно, скільки заявок закривається повністю, скільки частково і з якої причини.
Контроль ризику перестає триматися на увазі оператора: ліміти позицій задаються на інструмент, на напрямок і на сукупну експозицію, а біля межі обсяг наступної заявки знижується автоматично.
Це обмежує максимальну просадку зверху — вона більше не залежить від того, чи встигла людина відреагувати.
Стійкість стратегії перевіряється на зміні режиму ринку: зростання волатильності, падіння ліквідності, розходження котирувань. На такі періоди задано регламент — звуження лімітів або пауза, тому результат не розсипається на першій нестандартній сесії.
Ручні втручання оператора скорочуються до поодиноких випадків: підтвердження змін у параметрах, розбір спірних угод, звірка звітності. Решту система закриває сама й фіксує в журналі.
Схеми підключення до бірж і режими виконання угод
Схема підключення визначає, де лежить капітал, хто виставляє ноги угоди й скільки часу минає між котируванням і фактичним виконанням.
Помилку цього рівня логікою бота не компенсувати: яку б точну сигнатуру не рахувала модель, розходження виникає на стику «побачили ціну — стали в позицію». Тому варіант підключення фіксують до вибору моделі й режиму торгівлі.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пряме підключення до двох майданчиків: потік котирувань плюс приватний канал ордерів | потрібен повний контроль над моментом входу та власним ризик-менеджментом | ключі й ліміти запитів на кожній стороні, баланс доводиться тримати на обох, затримка між майданчиками з'їдає частину розходження |
| Трикутний арбітраж усередині одного майданчика | капітал зосереджений в одному місці, немає переказів між біржами | вузький набір пар, висока конкуренція, спред закривається швидше, ніж устигає спрацювати модель |
| Спот проти ф'ючерса (базисна схема) | потрібна нейтральність до напрямку ринку та утримання позиції довше хвилини | ставка фінансування періодично змінює знак, у маржинальної ноги з'являється ризик примусового закриття, потрібен запас забезпечення |
| Виконання через зовнішній агрегатор ордерів | немає власної інфраструктури та ключів, важливий швидкий запуск | не видно черговості ордерів, чужі ліміти частоти, затримка відповіді повністю поза вашим контролем |
Режим торгівлі вибирається під ту саму схему. Маркет-виконання гарантує, що нога закриється, але сплачує підвищену комісію та знімає стакан на великому обсязі.
Лімітні заявки дешевші, однак нога може не налитися, і тоді відкритою залишається одна сторона — класичне джерело збитку в арбітражі. Робочий компроміс — лімітний вхід із таймаутом і добором за маркетом: бот витримує паузу, а потім закриває розходження примусово. Обов'язковий елемент будь-якої схеми — контроль часткового виконання й автовідкат незакритої ноги.
Етапи впровадження: від аудиту даних до передачі в експлуатацію
Порядок робіт вибудовано так, щоб помилки в логіці знаходилися до підключення реального рахунку. Кожен етап закривається перевірюваним артефактом — звітом, схемою або зафіксованими лімітами, і лише після цього починається наступний.
- Аудит даних. Перевіряємо історію угод і котирувань: повнота, пропуски, мітки часу, коректний облік комісій. На виході — звіт про придатність вибірки та перелік ділянок, де даних не вистачає.
- Схема системи. Фіксуємо джерела котирувань, розрахунок сигналу, формування заявки, зберігання станів і логів. Схема узгоджується до першого рядка коду.
- Налаштування ризику. Ліміти на позицію, денну просадку, кількість одночасних угод і поведінку в разі втрати зв'язку з біржею — усе в конфігурації, а не в коді.
- Перевірка на історії. Прогін на історичних даних з урахуванням комісії та затримки виконання: дивимося просадку, частку невиконаних заявок, стійкість до зміни режиму ринку.
- Тіньовий режим. Бот рахує сигнали за живими даними, але заявки не надсилає. Розходження розрахункової ціни з фактичним стаканом показує, де модель переоцінює ліквідність.
- Передача в експлуатацію. Розгортання на цільовому середовищі, підключення рахунку, контроль і оповіщення, регламент зупинки. Віддаємо документацію й конфігурації.
Далі йде супровід: перегляд моделі в разі зміни режиму ринку та контроль відхилень від очікуваної поведінки.
Що передаємо на руки: конфігурації, схеми, регламенти та звіти
Систему передаємо так, щоб її можна було експлуатувати, дообучувати й зупиняти силами вашої команди — без інженера, який її збирав. До комплекту входить не лише робочий код, а й усе, що потрібно для передбачуваної роботи арбітражного бота в робочому режимі.
- Конфігурації стратегії: профілі, пороги входу, ліміти на позицію та денний ризик, набір ознак — із позначкою, що змінюється на ходу, а що потребує переперевірки на історії.
- Схеми системи: шлях даних від джерела котирувань до виконання угоди, точки відмови на кожній ділянці, зв'язки моделей і черг.
- Регламент реагування: пороги просадки, розсинхрону даних і падіння якості моделі, порядок переведення в ручний режим і зупинки торгів.
- Доступи й ролі: матриця прав на зміну параметрів, запуск перенавчання та перегляд звітів, порядок ротації ключів, журнал дій.
- Документація: опис ознак і логіки сигналів, методика оцінки якості, процедура перенавчання й перевірки моделі перед введенням.
- Звіти: зведення за дохідністю, просадкою, кількістю угод і часткою відмов — щоденні та тижневі, з історією конфігурацій.
Кожен артефакт приймається разом із вами на живій системі: показуємо, як зміна параметра змінює поведінку бота, і фіксуємо зони відповідальності між вашою командою та нашою.
Кейс: як скоротили просадку та прибрали ручні втручання
До впровадження арбітраж між двома торговими майданчиками тримався на ручному підтвердженні: оператор бачив розходження цін, звіряв ліміти й виставляв заявки сам. На реакцію йшло 6-8 секунд — за цей час розходження або закривали чужі заявки, або воно йшло в мінус. За зміну набігало 40-60 ручних операцій, а просадка на довгому відрізку сягала 18%.
Що змінили
Цикл перенесли на модель: вона оцінює очікувану дохідність пари з урахуванням комісій і глибини стакана, відсікає сигнали нижче порогу й віддає заявку на виконання сама.
Ризик-ліміти — за інструментом, майданчиком і денною просадкою — перевіряються до надсилання, тому нова позиція не відкривається, поки не закрита попередня.
- Час реакції: з 6-8 секунд на рішення оператора до десятих часток секунди.
- Частка виконаних заявок: 71% → 96%, решту відсікають фільтри за глибиною стакана.
- Ручні втручання: 40-60 за зміну → 1-2, лише розбір нештатних ситуацій.
- Частота збоїв: кілька інцидентів на тиждень → один на місяць, і той на стороні майданчика.
- Просадка: з 18% до 6-7% на зіставному відрізку.
Метрики знімаються з панелі моніторингу Grafana — час реакції, частка виконання, відмови майданчика й поточна просадка за кожною стратегією окремо. Замовник бачить той самий потік даних, на який спираємося ми, тому розходження в цифрах розбирається за фактом, а не за відчуттями.
Чим машинна модель відрізняється від жорстких правил в арбітражному боті
Жорсткі правила — це пороги, прописані вручну: спред вищий за заданий, достатня глибина стакана, враховані комісії та час до розрахунку. Логіка прозора: угоду пояснює один рядок умови, а поведінка відтворюється за того самого входу.
Але ринок змінює режим — ліквідність іде, спреди розширюються, — і пороги, підібрані на минулому періоді, спрацьовують там, де запасу вже немає.
Машинна модель замість списку умов зважує десятки ознак одразу: мікроструктуру стакана, волатильність, історію схожих можливостей. Вона знаходить нелінійні поєднання, які вручну не виписати, і підлаштовується під зміну режиму без правки коду.
Зворотний бік — перенавчання: на короткому або однорідному відрізку даних модель запам'ятовує шум і на нових даних втрачає якість.
Тому робоча схема — гібридна логіка. Жорсткі правила утворюють зовнішній контур: ліміти на експозицію, відсічка за ліквідністю, заборона входу за аномалій. Модель працює всередині — ранжує можливості та вибирає момент. Тоді збій моделі не виходить за явно задані межі й не перетворюється на некерований ризик.
Перенавчання тримають під контролем процедурою: вибірка ділиться за часом, а не випадково, якість перевіряється на періоді, якого модель не бачила, навчання йде на ковзному вікні, а розходження прогнозу з фактом відстежується постійно. Просіли метрики — відкат до попередньої версії.
Інтерпретація рішень потрібна для розбору інцидентів і ризик-контролю: видно, які ознаки дали внесок у конкретну угоду і чому бот увійшов. Логи рішення та зрозумілі пороги спрацювання роблять поведінку моделі перевірюваною, а не чорною скринькою.
Технічні сумніви: надійність, ризик і підтримка системи
До запуску на реальному рахунку замовник перевіряє не точність прогнозу, а поведінку бота в нештатних ситуаціях: обрив зв'язку з біржею, компрометація ключів, відмова стратегії. Нижче — відповіді на чотири сумніви, які найчастіше виникають на цьому етапі.
Що буде, якщо зв'язок із біржею обірветься за відкритої позиції?
Стан позиції та виставлені заявки пишуться в журнал на диску, а не тримаються лише в пам'яті процесу. Під час обриву бот припиняє надсилання розпоряджень, а після відновлення звіряє фактичний рахунок з обліковим і закриває розходження до відновлення торгівлі. Дублювальні заявки, які зазвичай і перетворюють короткий збій на збиток, не виникають.
Як захищені торгові ключі?
Ключі не лежать у коді або файлах репозиторію: вони зберігаються в захищеному сховищі й видаються процесу на час роботи. Права ключа обмежені торгівлею — виведення коштів за ним неможливе, тому компрометація не дає доступу до балансу. Ротація проходить без зупинки бота.
Що робити, якщо стратегія перестане працювати?
Правила торгівлі винесено в конфігурацію окремо від коду, тому вони змінюються без перезбирання ядра.
Нова версія перед викаткою проходить прогін на історичних даних і на тестовому рахунку, метрики — просадка, частка скасованих заявок, поведінка за низької ліквідності — порівнюються з попередньою. Відкат до попередніх правил займає хвилини.
Хто відповідає за збої після запуску?
Межі фіксуємо до старту: наша зона — виконання розпоряджень, журналювання, стійкість до обривів і моніторинг з оповіщеннями; ваша — доступи, рахунок і вибір стратегії. Підтримка системи включає реакцію на інциденти та планові доопрацювання.
Обговоримо задачу й повернемося з оцінкою та планом робіт
Арбітражний бот — це зв'язка моделі, виконавця заявок і контролю ризику, тому оцінка «на око» тут не працює. Щоб повернутися з планом робіт і строками етапів, а не з вилкою припущень, нам потрібно побачити дані й обмеження конкретного контуру. Підготуйте до розмови:
- перелік майданчиків і типів подій стратегії: розходження котирувань, рух лінії, неузгодженість лотів;
- історичні дані — глибина архіву, частота знімків стакана, чи записані результати подій;
- обмеження майданчиків і каналів: ліміти запитів, затримка відгуку, способи виставлення заявок;
- правила ризик-контролю — гранична просадка, стоп-умови, чи потрібен ручний підтверджувальний крок;
- цільові метрики: допустима частка хибних сигналів, час від події до заявки, стійкість до обривів зв'язку;
- хто з боку замовника валідує сигнали й приймає етапи.
Цього достатньо, щоб визначити склад команди — інженер даних, ML-спеціаліст, серверний розробник, інженер інфраструктури — і зафіксувати строки за етапами: розбір даних, прототип моделі, сервіс передбачень, інтеграція з майданчиками, моніторинг.
Кожен етап закриваємо демонстрацією на ваших даних і передачею документації: схеми потоків, опис ознак, регламент перенавчання й відкату моделі. Опишіть задачу — повернемося з оцінкою та планом робіт.
