Крос-біржовий арбітраж: де втрачається прибуток
Крос-біржовий арбітраж виглядає як найпростіша стратегія: побачив розбіжність цін між біржами, купив дешевше, продав дорожче, зафіксував різницю.
На практиці прибуток з'їдає не ринок, а затримка виконання угоди — від моменту, коли котирування потрапило в наш потік даних, до моменту, коли зустрічна заявка реально стала в стакан на другому майданчику.
Розбіжність цін живе частки секунди. Поки сигнал доходить до виконавця, проходять перевірки лімітів і ризиків, відправляється й підтверджується заявка — спред схлопується, обидва майданчики вже перебудували стакани. Ми ловимо не ту ціну, яку бачили, а ту, що залишилася після нас.
Друге вузьке місце — прослизання ціни. Рівень, на якому видно потрібний обсяг, зазвичай тонкий: частина заявки закривається за заявленою ціною, залишок — за наступними, гіршими. Чим більший обсяг, тим помітніший розрив між очікуваною та фактичною середньою ціною угоди.
Третя проблема — розсинхронізація стану позицій. Нога на одному майданчику виконана, на другому відхилена або закрита частково, кошти розмазані між балансами, а курси вже пішли. Схема без контролю обох ніг перетворюється на незаплановану позицію з ринковим ризиком.
Тому робота починається не з сигналів, а з бюджету часу та оцінки ліквідності кожного майданчика: скільки займає повний цикл, який обсяг проходить без помітного прослизання, що робити, коли одна нога не виконалася. Далі розбираємо, як ці місця закриваються в архітектурі.
Зниження прослизання та контроль виконання
Арбітражна угода живе секундами: розбіжність між майданчиками відкривається й закривається швидше, ніж оператор встигає глянути на стакан.
Тому виконання будується на правилах, які спрацьовують без людини — підключення до Binance та інших майданчиків тримає єдиний потік котирувань, а рішення про вхід ухвалює алгоритм.
Швидкість реакції на розбіжність цін
Сигнал від сканера перетворюється на пару зустрічних ордерів автоматично: обсяг ділиться між майданчиками з урахуванням доступної глибини, а не «на око».
Реакція на розбіжність скоротилася з ручних 20–30 секунд до часток секунди, частка угод, закритих за очікуваною ціною, зросла з 60–70% до 90%+. Заявка, яка не пройшла за ціною, скасовується та перераховується, а не висить у стакані.
Контроль ризику на позиції
Ліміти на позицію задаються за кожним інструментом і майданчиком: алгоритм не набере обсяг більший за заданий, навіть якщо розбіжність виглядає вигідною.
Комісії — торгові та за виведення — закладені в розрахунок спреду, тому в роботу потрапляють лише ті розбіжності, які залишаються прибутковими після всіх витрат.
Якщо одна нога не виконалася, друга закривається автоматично: кількість незакритих розбіжностей пішла з десятків на місяць до одиничних випадків, а клас відмов «зависла одностороння позиція» на відпрацьованих сценаріях перестав виникати.
Порівняння режимів крос-біржового арбітражу
Режим обирають не за зручністю, а за часом життя вікна угоди: розбіжність цін між майданчиками закривається за секунди, а переказ коштів — за десятки хвилин. Звідси чотири варіанти, між якими реально обирають.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Повний автомат із власним виконанням | Потік сигналів стабільний, кошти лежать на обох майданчиках | Потрібні ключі з правом торгівлі, захист від часткового виконання |
| Напівавтомат із підтвердженням оператора | Великий розмір позиції, вузький список майданчиків | Швидкість реакції задає людина, частина сигналів минає |
| Сигнальний режим | Обкатка логіки, ручна торгівля | Немає автоматичного виконання — лише оповіщення та розрахунок |
| Доробка наявного контуру | Є робочий бот і облік, потрібен другий контур | Попередня архітектура обмежує швидкість і набір майданчиків |
Пари майданчиків і типи інструментів
Вважаємо робочими не майданчики, а їх пари. Спот-спот дає просту логіку, але потребує переказу коштів між біржами; спот-ф'ючерс і ф'ючерс-ф'ючерс дозволяють тримати обидві ноги без виведення.
Інструмент на двох сторонах має збігатися за базовим активом і кратністю контракту — інакше розрахунок розбіжності втрачає сенс.
Що накладає обмеження: ліквідність, ліміти, швидкість виведення
Глибина стакана задає межу обсягу: прослизання з'їдає спред швидше, ніж зростає позиція. Ліміти майданчиків обмежують частоту запитів і кількість ордерів на рахунок, тому сигнали відсіюємо до відправлення.
Де виведення не вкладається у вікно, контур будуємо без переказу — через ф'ючерсну ногу та передторгову перевірку з перерахунком після комісій.
Як будується алгоритм: етапи інженерної роботи
Крос-біржовий арбітраж живе на різниці цін між майданчиками, і майже вся маржа з'їдається чотирма речами: затримкою між котируванням і виконанням, комісіями обох ніг, глибиною стакана та частковим виконанням.
Тому ми не починаємо з коду — спочатку фіксуємо, що вже є в інфраструктурі та даних, і лише потім пишемо логіку. Нижче — послідовність із семи етапів, кожен закінчується перевірюваним артефактом.
Аудит інфраструктури та даних
- Аудит інфраструктури: дивимося підключення до майданчиків, права ключів, ліміти запитів, мережеві затримки до точок розміщення та те, де зберігається стан позицій.
- Збір та очищення історичних даних: піднімаємо стакани та угоди за потрібний період, прибираємо викиди, відновлюємо пропуски, приводимо позначення пар і кроки ціни до єдиного вигляду.
- Схема логіки та лімітів: описуємо, що вважаємо можливістю, поріг входу з урахуванням комісій, ліміти на пару та майданчик, поведінку при частковому виконанні та правила зупинки.
Перевірка на історії та на малому обсязі
- Реалізація: збираємо модулі збору, розрахунку та виконання окремо, щоб відмова однієї частини не тягла за собою інші.
- Тестовий контур: проганяємо логіку на історичних вікнах, включно з розривами зв'язку та різкими рухами ринку.
- Перевірка на малому обсязі: виводимо мінімальні розміри угод, звіряємо очікуваний результат із фактичним за кожною ногою та за розбіжністю в комісіях.
- Передача та супровід: віддаємо документацію, налаштування порогів і порядок розбору відхилень на живому контурі.
Після шостого етапу видно розбіжність між розрахунком і реальним виконанням — саме вона визначає, які пороги ставити і чи варто взагалі запускати стратегію на повному обсязі.
Конфігурації, регламенти та документація на передачу
Робота вважається переданою не в момент, коли алгоритм приніс першу угоду, а коли ваша команда може змінювати його параметри, зупиняти й піднімати без нашої участі.
Тому пакет передачі збирається з першого дня розробки, а не дописується в кінці: конфігурації відокремлені від коду, а всі зовнішні дотики — біржі, оповіщення, доступи — описані так, щоб їх можна було відтворити на стенді.
Документація та регламенти реагування
- Файли конфігурації за кожною біржею та парою: ліміти обсягу, пороги входу та виходу, облік комісій і затримок — правляться та застосовуються без перезбирання алгоритму.
- Схема взаємодії компонентів: збір котирувань, розрахунок розбіжності цін, модуль виконання, контроль балансів і звірка з біржовими звітами — із зазначенням інтервалів і точок відмови.
- Журнали подій та оповіщень із рівнями важливості: угоди, відмови біржі, розбіжності балансу, простій каналу; вивантаження за період для розбору інциденту.
- Інструкція із запуску, штатної зупинки та аварійного стопу — з описом станів: де залишаються відкриті позиції та як закрити їх вручну.
- Регламент реагування на збій: послідовність кроків, хто ухвалює рішення про зупинку, за який час виходимо на зв'язок і які дані додавати до звернення.
Права доступу та розподіл ролей
- Ролі з різним обсягом прав: спостерігач, оператор, адміністратор конфігурації. Зміна лімітів і зупинка модуля — лише у двох останніх.
- Біржові ключі без права виведення коштів; зберігаються на вашій стороні, у конфігурації залишаються лише посилання на них.
- Політика ротації ключів і відкликання доступів при звільненні співробітника — прописана як процедура, а не як побажання.
- Журнал дій операторів: хто, коли і що змінював у параметрах і коли зупиняв алгоритм.
Кейс: переведення позицій між біржами без втрат
Торгова команда тримала позиції на чотирьох майданчиках і переносила їх вручну: основний обіг ішов через Binance, решта — через менш ліквідні біржі.
Розбіжність знаходили в терміналі, виводили кошти, чекали зарахування і лише потім відкривали другу ногу — нетто-ціна на той момент уже від'їжджала. За зміну черговий трейдер встигав відпрацювати одиниці розбіжностей, решту просто пропускали.
Що було до і що стало після
| Показник | До | Після |
|---|---|---|
| Угоди за очікуваною ціною | близько третини входів | дев'ять із десяти |
| Реакція на розбіжність | десятки секунд | частки секунди |
| Ручні втручання за зміну | 30–40 | одиниці |
| Прослизання на переказі | десяті частки відсотка | у межах заданого ліміту |
Ми зібрали єдиний потік котирувань з усіх майданчиків і рахуємо нетто-ціну з урахуванням комісій, глибини стакана та затримки виконання.
Ноги виставляються одночасно, а баланси заздалегідь розподілені по біржах — переказ коштів стає рідкісним винятком і йде фоном, не блокуючи угоди. Якщо нетто-ціна виходить за поріг, алгоритм не відкриває позицію взагалі: краще пропустити розбіжність, ніж увійти за поганою ціною.
Прослизання перестало з'їдати результат, а робота — залежати від того, хто на зміні. По кожній парі ордерів зберігається журнал: видно, де пройшла затримка і чому угода не відбулася.
Пороги, ліміти за обсягом і список майданчиків винесені в конфігурацію і змінюються без переписування ядра.
Що робити, якщо між біржами вже працює бот
Робот, який уже торгує між біржами, — не привід переписувати контур з нуля. Він служить джерелом вимог: всередині зашиті припущення про комісії, ліміти на виведення, розбіжності стаканів і мінімальний спред, за якого угода ще залишається прибутковою. Завдання — зняти цю логіку та перевірити її на фактах, а не вгадати заново.
Починаємо з аудиту поточного коду та журналів виконання. Відновлюємо, як рахується спред з урахуванням комісій на вхід і вихід, як вибирається розмір позиції, що відбувається при частковому виконанні та куди йде скасований залишок ордера.
Потім звіряємо знайдені правила з фактичною історією угод — розбіжності показують місця, де логіку вже правили вручну.
Перенесення стану відкритих позицій іде за знімком і журналом подій. Фіксуємо, що відкрито за кожним інструментом на кожному майданчику, середню ціну входу, невиконані частини ордерів і нараховані комісії.
Знімок звіряємо з біржовими вивантаженнями — за Binance та іншими майданчиками через історію угод і балансові звіти. Якщо звірка не сходиться, новий контур буде рахувати неправильну доходність і ухвалювати рішення на кривих даних.
Перехоплення управління проходить без розриву роботи. Новий робот запускається паралельно в режимі спостереження: повторює рішення старого і пише в журнал кожну розбіжність.
Коли поведінка збігається на достатній історії угод, перемикаємо по одному інструменту — старий робот залишається в режимі закриття позицій і нових не відкриває.
Зворотна операція — повернення управління за конкретним інструментом, а не відновлення з резервної копії: відкриті позиції продовжують обслуговуватися, ключі доступу до бірж не перевипускаються.
Сумніви замовників щодо надійності та ризиків
Сумніви у замовників зазвичай одні й ті самі: що станеться, якщо майданчик почне гальмувати, як алгоритм поведеться на різкому русі і чи можна вірити результатам перевірки на минулих даних. Нижче — відповіді на технічні питання, які найчастіше лунають до старту робіт.
Що якщо виведення коштів затримується?
Позиція закривається в момент, коли виконані обидві ноги угоди. Якщо майданчик затримує виведення, завислий актив виключається з розрахунку доступної ліквідності — алгоритм позначає позицію незакритою і не враховує її при пошуку наступної можливості.
Далі працює заздалегідь прописаний сценарій: очікування з контролем статусу, при перевищенні порогу — спроба закриття на другому майданчику або фіксація позиції до відновлення.
Майданчик обмежує обсяг або частоту запитів?
Обмеження майданчика закладаються в модель, а не вважаються збоєм. Алгоритм оцінює доступний обсяг за кожною парою, дробить великий ордер і витримує паузу при наближенні до ліміту запитів.
Коли майданчик закриває напрямок, її пара вимикається, а потік перерозподіляється на інші — без ручного втручання.
Як поведеться на різкому русі ринку?
Тут головний ризик — ліквідність: на різкому русі глибина падає, а розбіжність цін зростає швидше, ніж виконується ордер. Тому перед відправленням іде перевірка, яка відсіює можливості, де очікувана різниця менша за можливе прослизання. Частина сигналів не проходить фільтр — це штатна робота, а не втрачений прибуток.
Наскільки можна вірити перевірці на минулих даних?
Тестування на історії йде з урахуванням комісій, затримок і часткового виконання, а не на «ідеальному» наповненні стакана.
Конфігурація йде в роботу, якщо результат тримається при навмисно завищених витратах; якщо розсипається — правимо логіку, а не підганяємо параметри під гарну криву.
Кому належать вихідні коди?
Вихідний код, конфігурації та документація передаються вам — з описом логіки, точок відмови та порядку відновлення після збою. Жодної прихованої залежності від нашої сторони: систему можна розвивати своєю командою або з іншим підрядником.
Обговоримо задачу та повернемося з планом
Щоб оцінка обсягу робіт була реалістичною, а не усередненою по ринку, нам потрібен від вас мінімум вхідних даних. Їх достатньо, щоб порахувати трудовитрати, зібрати склад команди і не закладати в план зайві етапи.
- Список майданчиків: де торгуєте зараз і куди плануєте виходити — від цього залежить кількість модулів підключення та обсяг роботи за кожним.
- Типи акаунтів і права ключів: торгівля, виведення коштів, ліміти на запити — визначають, які дії алгоритм закриває сам, а де потрібна ручна операція.
- Доступ до тестових середовищ майданчиків — на них перевіряємо логіку виставлення та зняття заявок без ризику для балансу.
- Відповідальні з боку замовника: хто ухвалює рішення щодо торгової логіки і хто відповідає за безпеку ключів.
- Поточні напрацювання — скрипти, ручні розрахунки, таблиці зі спредами та комісіями: беремо як основу, а не винаходимо заново.
- Межі ризику: допустима просадка, ліміт на угоду, поведінка алгоритму при обриві зв'язку та розсинхронізації цін між майданчиками.
- Вимоги до розміщення: ваш сервер або наш, чи є обмеження щодо мережевих доступів і журналювання дій.
Опишіть задачу у вільній формі — за цими вхідними даними повернемося з оцінкою обсягу, планом робіт за етапами та складом команди під ваш контур.
