Розробка алгоритму статистичного арбітражу на криптовалютних ринках

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

Де ламається статистичний арбітраж криптовалют

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

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

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

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

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

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

Вимірюваний ефект: затримка, прослизання, простій

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

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

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

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

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

Режими арбітражного контуру: порівняння підходів

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

Режим Коли підходить Чим обмежений
Міжбіржовий переніс Спред між платформами стійко ширший за сумарні витрати: дві комісії, виведення, зарахування, конвертація Потрібні заздалегідь розміщені баланси на обох платформах; поки йде переказ, ціна встигає піти
Внутрішньобіржові пари Потрібен швидкий розворот без міжплатформових переказів: зв'язки через базову валюту та стейблкоїни Обмеження ліквідності в тонких парах: обсяг упирається в глибину стакана, прослизання з'їдає спред
Відхилення від статистичної норми Ряд спреду та зв'язок пари стійкі, відхилення повертається до середнього Зміна режиму ринку ламає модель: зв'язок розпадається, позиція висить до закриття по стопу

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

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

Етапи розробки, перевірки та передачі рішення

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

  1. Аудит даних. Зводимо історичні котирування за потрібними платформами, перевіряємо розриви, пропуски та розходження між джерелами, окремо дивимося низьколіквідні періоди й інструменти, які перестали торгуватися.
  2. Постановка гіпотези. Формулюємо, на якому статистичному відношенні будується перевага, який горизонт утримання позиції та які витрати угода зобов'язана перекривати.
  3. Перевірка на історичних даних. Проганяємо гіпотезу на відкладеному періоді з урахуванням комісій, прослизання та затримки виконання — модель, жива тільки без витрат, відсіюється тут.
  4. Тестовий контур. Виводимо логіку на біржову пісочницю або мінімальні обсяги, звіряємо розрахункову й фактичну ціну виконання, поведінку при обриві зв'язку та відмові частини заявок.
  5. Приймання рішення. Фіксуємо критерії: стійкість результату на різних періодах, допустиме просідання, частка невиконаних заявок, коректність зупинки торгівлі.
  6. Передача в експлуатацію. Віддаємо конфігурацію, регламент запуску й зупинки, набір метрик і правила, за якими система сама припиняє торгівлю.

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

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

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

  • Вихідний код і середовище. Репозиторій з історією змін, конфігурації збірки та розгортання, зафіксовані залежності — збірка піднімається на чистій машині без участі наших інженерів.
  • Схема контуру. Як пов'язані збір ринкових даних, розрахунок сигналу, виставлення заявок і облік позицій; де вузькі місця та які потоки критичні для зупинки стратегії.
  • Політики доступу й ротація ключів. Ролі з різними правами, термін життя ключів до бірж, порядок планової заміни та негайного відкликання при виході співробітника.
  • Регламент чергування. Пороги оповіщень, хто і в які терміни реагує на розходження розрахункової та фактичної позиції, за яких умов стратегія стає на паузу автоматично.
  • Документація з експлуатації. Запуск і плановий перезапуск, оновлення параметрів моделі, типові збої та порядок дій, місця, де потрібне втручання людини.
  • Опис моделі. Які дані на вході, як рахується сигнал, яке вікно оцінки, за якими критеріями модель перенавчається і коли виводиться з роботи.
  • Результати перевірок. Прогін на історичних даних, набір тестів, контрольні метрики — щоб приймати систему можна було за цифрами, а не на слово.

Кейс: скорочення прослизання й хибних входів

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

Сигнали рахувалися за ціною останньої угоди, тому вхід спрацьовував там, де стакан уже спорожнів: частка хибних входів сягала 38%, а прослизання на виході — до 0,9% від обсягу позиції.

Метрики контуру писалися в журнал: час від сигналу до фактичного виконання, обсяг часткового набору та відхилення ціни угоди від розрахункової.

Що змінили

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

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

Результат впровадження

Хибні входи скоротилися до 7%, прослизання — до 0,15–0,25%, а частка сигналів, доведених до повного набору позиції, виросла приблизно вдвічі.

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

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

Що робити, якщо на біржі вже працює торговий робот

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

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

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

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

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

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

Технічні питання, які задають до старту

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

Як стратегія переживає різкі рухи ринку?

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

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

Хто отримує доступ до ключів і грошей на рахунку?

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

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

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

Що відбувається при призупиненні торгів на біржі?

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

Як зрозуміти, що результати реальні, а не гарні на папері?

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

Обговоримо задачу: оцінка, план і порядок робіт

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

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

Що знадобиться від вас на вході:

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

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

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

Напрямки блокчейн-розробки

Останні роботи

  • Розробка сайту компанії B2B ADVANCE
    Розробка сайту компанії B2B ADVANCE
    1542
  • Розробка веб-додатків для компанії FEEDME
    Розробка веб-додатків для компанії FEEDME
    1393
  • Розробка веб-сайту для компанії БЕЛФІНГРУП
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1081
  • Розробка інтернет магазину для компанії FURNORO
    Розробка інтернет магазину для компанії FURNORO
    1368
  • Розробка логотипу компанії B2B Advance
    Розробка логотипу компанії B2B Advance
    815
  • Розробка веб-додатків для компанії Enviok
    Розробка веб-додатків для компанії Enviok
    1139