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

Чтобы такое расхождение не накапливалось, системе копитрейдинга нужна отдельная сверка. Она сравнивает целевую позицию, известные активные ордера и фактическое состояние биржевого счёта. Ни один из этих источников нельзя считать полной картиной сам по себе.

Три состояния одной сделки

После сигнала существуют как минимум три разных состояния.

Намерение системы. Какую позицию должен иметь подписчик после применения коэффициента копирования, риск-лимитов, минимального лота и округления.

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

Факт биржи. Ордера, исполнения и позиция, которые биржа возвращает через приватный поток и контрольные REST-запросы.

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

Почему ответ на создание ордера не завершает операцию

Биржевые API работают асинхронно. Успешный ответ на запрос обычно сообщает, что площадка приняла запрос к обработке. Дальше статус ордера может меняться.

В документации Bybit для получения открытых и закрытых ордеров отдельно указаны незаполненные, частично исполненные и недавно завершённые состояния. Для оперативных обновлений биржа рекомендует приватный WebSocket-поток ордеров. Binance передаёт изменения статуса и накопленный исполненный объём в событии обновления ордера. В документации OKX также описана подписка на канал ордеров и переходы между состояниями live, filled и отменой.

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

Timeout и опасный повтор

Timeout означает только то, что клиент не получил ответ вовремя. Он не показывает, дошёл ли запрос до торговой системы.

Возможны два сценария:

  • биржа не получила заявку;
  • биржа получила и даже исполнила заявку, но ответ потерялся по пути.

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

Это общий принцип надёжной интеграции, а не утверждение о конкретной внутренней реализации CopyTrader.

Частичное исполнение меняет расчёт дельты

Предположим, целевая позиция подписчика — 1,0 BTC, текущая фактическая позиция — 0,6 BTC, а открытая заявка на покупку 0,4 BTC уже исполнена наполовину.

Если биржа уже включила исполненные 0,2 BTC в текущую позицию, остаётся открытым ещё 0,2 BTC. Учитываемое состояние равно:

фактическая позиция + неисполненный остаток активных заявок.

В примере это 0,8 + 0,2 = 1,0 BTC. Дополнительная заявка не нужна.

Если система посмотрит только на позицию 0,8 BTC, она может отправить ещё 0,2 BTC и после завершения первого ордера получить 1,2 BTC. Если она, наоборот, посчитает весь исходный объём заявки поверх уже обновлённой позиции, ошибка возникнет по другой причине: исполненная часть будет учтена дважды.

Конкретная формула зависит от модели позиций, направления, режима hedge/one-way и контракта биржи. Но принцип один: исполненный объём и открытый остаток нельзя смешивать.

Цикл сверки ордеров и позиции

Практический reconciliation loop состоит из нескольких шагов.

  1. Получить цель. Зафиксировать целевую позицию после правил копирования и ограничений подписчика.
  2. Снять биржевой факт. Получить текущую позицию, активные ордера и недавние конечные статусы.
  3. Связать идентификаторы. Сопоставить внутреннее решение, клиентский ID и биржевой order ID.
  4. Нормализовать состояние. Учесть направление, исполненный объём, открытый остаток, шаг количества и режим позиции.
  5. Вычислить расхождение. Сравнить цель с фактической позицией и тем объёмом, который ещё способен исполниться.
  6. Классифицировать причину. Timeout, reject, partial fill, cancel, ручная сделка, потеря события или изменение настроек.
  7. Выбрать действие. Наблюдать, отменить остаток, отправить корректирующую заявку, заблокировать автоматическую коррекцию или передать случай оператору.
  8. Проверить конечное состояние. После действия снова запросить биржевой факт.

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

Типовые сценарии

Наблюдение Возможная причина Что проверять до повторной заявки
Нет ответа после отправки timeout или потеря соединения client order ID, историю ордеров и приватный поток
Статус остаётся partially filled недостаточная ликвидность или лимитная цена исполненный объём, остаток, срок действия и текущую цель
Ордер отменён ручная отмена, IOC/FOK, правило биржи конечный статус и причину отмены
Позиция отличается при отсутствии открытых ордеров ручная сделка, потерянное событие, иной режим позиции историю исполнений и настройки счёта
После retry объём стал больше цели первая попытка была принята оба order ID и правило повторной отправки

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

Что должен видеть пользователь

Статуса «сделка скопирована» недостаточно. Он объединяет несколько разных состояний и создаёт ложную уверенность.

Полезнее показывать отдельно:

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

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

Как этот материал связан с другими проверками

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

Эти проверки не устраняют рыночный риск. Они разделяют причины расхождений и дают оператору доказательства для корректного действия.

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

Поделиться материалом