Разработка алгоритма cross-exchange арбитража под ключ

Кросс-биржевой арбитраж: где теряется прибыль

Кросс-биржевой арбитраж выглядит как самая простая стратегия: увидел расхождение цен между биржами, купил дешевле, продал дороже, зафиксировал разницу. На практике прибыль съедает не рынок, а задержка исполнения сделки — от момента, когда котировка попала в наш поток данных, до момента, когда встречная заявка реально встала в стакан на второй площадке.

Расхождение цен живёт доли секунды. Пока сигнал доходит до исполнителя, проходят проверки лимитов и рисков, отправляется и подтверждается заявка — спред схлопывается, обе площадки уже перестроили стаканы. Мы ловим не ту цену, которую видели, а ту, что осталась после нас.

Второе узкое место — проскальзывание цены. Уровень, на котором виден нужный объём, обычно тонкий: часть заявки закрывается по заявленной цене, остаток — по следующим, более худшим. Чем крупнее объём, тем заметнее разрыв между ожидаемой и фактической средней ценой сделки.

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

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

Снижение проскальзывания и контроль исполнения

Арбитражная сделка живёт секундами: расхождение между площадками открывается и закрывается быстрее, чем оператор успевает взглянуть на стакан. Поэтому исполнение строится на правилах, которые срабатывают без человека — подключение к Binance и другим площадкам держит единый поток котировок, а решение о входе принимает алгоритм.

Скорость реакции на расхождение цен

Сигнал от сканера превращается в пару встречных ордеров автоматически: объём делится между площадками с учётом доступной глубины, а не «на глаз». Реакция на расхождение сократилась с ручных 20–30 секунд до долей секунды, доля сделок, закрытых по ожидаемой цене, выросла с 60–70% до 90%+. Заявка, которая не прошла по цене, отменяется и пересчитывается, а не висит в стакане.

Контроль риска на позиции

Лимиты на позицию задаются по каждому инструменту и площадке: алгоритм не наберёт объём больше заданного, даже если расхождение выглядит выгодным. Комиссии — торговые и за вывод — заложены в расчёт спреда, поэтому в работу попадают только те расхождения, которые остаются прибыльными после всех издержек.

Если одна нога не исполнилась, вторая закрывается автоматически: число незакрытых расхождений ушло с десятков в месяц до единичных случаев, а класс отказов «зависшая односторонняя позиция» на отработанных сценариях перестал возникать.

Сравнение режимов кросс-биржевого арбитража

Режим выбирают не по удобству, а по времени жизни окна сделки: расхождение цен между площадками закрывается за секунды, а перевод средств — за десятки минут. Отсюда четыре варианта, между которыми реально выбирают.

Пары площадок и типы инструментов

Считаем рабочими не площадки, а их пары. Спот-спот даёт простую логику, но требует перевода средств между биржами; спот-фьючерс и фьючерс-фьючерс позволяют держать обе ноги без вывода. Инструмент на двух сторонах должен совпадать по базовому активу и кратности контракта — иначе расчёт расхождения теряет смысл.

Что накладывает ограничения: ликвидность, лимиты, скорость вывода

Глубина стакана задаёт предел объёма: проскальзывание съедает спред быстрее, чем растёт позиция. Лимиты площадок ограничивают частоту запросов и число ордеров на счёт, поэтому сигналы отсеиваем до отправки. Где вывод не укладывается в окно, контур строим без перевода — через фьючерсную ногу и предторговую проверку с пересчётом после комиссий.

Как строится алгоритм: этапы инженерной работы

Кросс-биржевой арбитраж живёт на разнице цен между площадками, и почти вся маржа съедается четырьмя вещами: задержкой между котировкой и исполнением, комиссиями обеих ног, глубиной стакана и частичным исполнением. Поэтому мы не начинаем с кода — сначала фиксируем, что уже есть в инфраструктуре и данных, и лишь потом пишем логику. Ниже — последовательность из семи этапов, каждый заканчивается проверяемым артефактом.

Аудит инфраструктуры и данных

1. Аудит инфраструктуры: смотрим подключения к площадкам, права ключей, лимиты запросов, сетевые задержки до точек размещения и то, где хранится состояние позиций.
2. Сбор и очистка исторических данных: поднимаем стаканы и сделки за нужный период, убираем выбросы, восстанавливаем пропуски, приводим обозначения пар и шаги цены к единому виду.
3. Схема логики и лимитов: описываем, что считаем возможностью, порог входа с учётом комиссий, лимиты на пару и площадку, поведение при частичном исполнении и правила остановки.

Проверка на истории и на малом объёме

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

После шестого этапа видно расхождение между расчётом и реальным исполнением — именно оно определяет, какие пороги ставить и стоит ли вообще запускать стратегию на полном объёме.

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

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

Документация и регламенты реагирования

• Файлы конфигурации по каждой бирже и паре: лимиты объёма, пороги входа и выхода, учёт комиссий и задержек — правятся и применяются без пересборки алгоритма.
• Схема взаимодействия компонентов: сбор котировок, расчёт расхождения цен, модуль исполнения, контроль балансов и сверка с биржевыми отчётами — с указанием интервалов и точек отказа.
• Журналы событий и оповещений с уровнями важности: сделки, отказы биржи, расхождения баланса, простой канала; выгрузка за период для разбора инцидента.
• Инструкция по запуску, штатной остановке и аварийному стопу — с описанием состояний: где остаются открытые позиции и как закрыть их вручную.
• Регламент реагирования на сбой: последовательность шагов, кто принимает решение об остановке, за какое время выходим на связь и какие данные прикладывать к обращению.

Права доступа и разделение ролей

• Роли с разным объёмом прав: наблюдатель, оператор, администратор конфигурации. Изменение лимитов и остановка модуля — только у двух последних.
• Биржевые ключи без права вывода средств; хранятся на вашей стороне, в конфигурации остаются лишь ссылки на них.
• Политика ротации ключей и отзыва доступов при уходе сотрудника — прописана как процедура, а не как пожелание.
• Журнал действий операторов: кто, когда и что менял в параметрах и когда останавливал алгоритм.

Кейс: перевод позиций между биржами без потерь

Торговая команда держала позиции на четырёх площадках и переносила их вручную: основной оборот шёл через Binance, остальное — через менее ликвидные биржи. Расхождение находили в терминале, выводили средства, ждали зачисления и только потом открывали вторую ногу — нетто-цена к тому моменту уже уезжала. За смену дежурный трейдер успевал отработать единицы расхождений, остальные просто пропускались.

Что было до и что стало после

Мы собрали единый поток котировок со всех площадок и считаем нетто-цену с учётом комиссий, глубины стакана и задержки исполнения. Ноги выставляются одновременно, а балансы заранее распределены по биржам — перевод средств становится редким исключением и идёт фоном, не блокируя сделки. Если нетто-цена уходит за порог, алгоритм не открывает позицию вовсе: лучше пропустить расхождение, чем войти по плохой цене.

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

Что делать, если между биржами уже работает бот

Робот, который уже торгует между биржами, — не повод переписывать контур с нуля. Он служит источником требований: внутри зашиты допущения о комиссиях, лимитах на вывод, расхождении стаканов и минимальном спреде, при котором сделка ещё остаётся прибыльной. Задача — снять эту логику и проверить её на фактах, а не угадать заново.

Начинаем с аудита текущего кода и журналов исполнения. Восстанавливаем, как считается спред с учётом комиссий на вход и выход, как выбирается размер позиции, что происходит при частичном исполнении и куда уходит отменённый остаток ордера. Затем сверяем найденные правила с фактической историей сделок — расхождения показывают места, где логику уже правили вручную.

Перенос состояния открытых позиций идёт по снимку и журналу событий. Фиксируем, что открыто по каждому инструменту на каждой площадке, среднюю цену входа, неисполненные части ордеров и начисленные комиссии. Снимок сверяем с биржевыми выгрузками — по Binance и остальным площадкам через историю сделок и балансовые отчёты. Если сверка не сходится, новый контур будет считать неверную доходность и принимать решения на кривых данных.

Перехват управления проходит без разрыва работы. Новый робот запускается параллельно в режиме наблюдения: повторяет решения старого и пишет в журнал каждое расхождение. Когда поведение совпадает на достаточной истории сделок, переключаем по одному инструменту — старый робот остаётся в режиме закрытия позиций и новых не открывает.

Обратная операция — возврат управления по конкретному инструменту, а не восстановление из резервной копии: открытые позиции продолжают обслуживаться, ключи доступа к биржам не перевыпускаются.

Сомнения заказчиков по надёжности и рискам

Сомнения у заказчиков обычно одни и те же: что произойдёт, если площадка начнёт тормозить, как алгоритм поведёт себя на резком движении и можно ли верить результатам проверки на прошлых данных. Ниже — ответы на технические вопросы, которые чаще всего звучат до старта работ.

Площадка ограничивает объём или частоту запросов?

Ограничения площадки закладываются в модель, а не считаются сбоем. Алгоритм оценивает доступный объём по каждой паре, дробит крупный ордер и выдерживает паузу при приближении к лимиту запросов. Когда площадка закрывает направление, её пара отключается, а поток перераспределяется на остальные — без ручного вмешательства.

Как поведёт себя на резком движении рынка?

Здесь главный риск — ликвидность: на резком движении глубина падает, а расхождение цен растёт быстрее, чем исполняется ордер. Поэтому перед отправкой идёт проверка, которая отсеивает возможности, где ожидаемая разница меньше возможного проскальзывания. Часть сигналов не проходит фильтр — это штатная работа, а не упущенная прибыль.

Насколько можно верить проверке на прошлых данных?

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

Кому принадлежат исходники?

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

Обсудим задачу и вернёмся с планом

Чтобы оценка объёма работ была реалистичной, а не усреднённой по рынку, нам нужен от вас минимум вводных. Их достаточно, чтобы посчитать трудозатраты, собрать состав команды и не закладывать в план лишние этапы.

• Список площадок: где торгуете сейчас и куда планируете выходить — от этого зависит число модулей подключения и объём работы по каждому.
• Типы аккаунтов и права ключей: торговля, вывод средств, лимиты на запросы — определяют, какие действия алгоритм закрывает сам, а где нужна ручная операция.
• Доступ к тестовым средам площадок — на них проверяем логику выставления и снятия заявок без риска для баланса.
• Ответственные со стороны заказчика: кто принимает решения по торговой логике и кто отвечает за безопасность ключей.
• Текущие наработки — скрипты, ручные расчёты, таблицы со спредами и комиссиями: берём как основу, а не переизобретаем.
• Границы риска: допустимая просадка, лимит на сделку, поведение алгоритма при обрыве связи и рассинхроне цен между площадками.
• Требования к размещению: ваш сервер или наш, есть ли ограничения по сетевым доступам и журналированию действий.

Опишите задачу в свободной форме — по этим вводным вернёмся с оценкой объёма, планом работ по этапам и составом команды под ваш контур.