Підписник може отримати правильний сигнал і все одно опинитися з неправильною позицією. Причина часто полягає не в логіці лідера, а між відправленням заявки та її остаточним станом: 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-ключі та інші облікові дані у такий журнал потрапляти не повинні.

Як цей матеріал пов’язаний з іншими перевірками

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

Ці перевірки не усувають ринковий ризик. Вони розділяють причини розбіжностей і дають оператору докази для коректної дії.

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

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