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

Каб такое разыходжанне не назапашвалася, сістэме копітрэйдынгу патрэбна асобная сверка. Яна параўноўвае мэтавую пазіцыю, вядомыя актыўныя ордэры і фактычны стан біржавога рахунку. Ні адзін з гэтых крыніц нельга лічыць поўнай карцінай сам па сабе.

Тры станы адной здзелкі

Пасля сігналу існуюць як мінімум тры розныя станы.

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

Адпраўленыя, але не завершаныя заяўкі. Яны ўжо могуць змяніць пазіцыю, хоць бягучы аб'ём на рахунку яшчэ не змяніўся.

Факт біржы. Ордэры, выкананні і пазіцыя, якія біржа вяртае праз прыватны паток і кантрольныя REST-запыты.

Калі параўноўваць мэту толькі з бягучай пазіцыяй, сістэма можа не заўважыць заяўку ў дарозе і адправіць лішні аб'ём. Калі спадзявацца толькі на лакальны журнал, яна не ўбачыць ручную здзелку або змену, якая адбылася пасля страты злучэння. Сверка павінна ўлічваць абодва крыніцы.

Чаму адказ на стварэнне ордэра не завершвае аперацыю

Біржавыя API працуюць асінхронна. Паспяховы адказ на запыт звычайна паведамляе, што пляцоўка прыняла запыт да апрацоўкі. Далей статус ордэра можа змяняцца.

У дакументацыі Bybit для атрымання адкрытых і закрытых ордэраў асобна паказаны незапоўненыя, часткова выкананыя і нядаўна завершаныя станы. Для аператыўных абнаўленняў біржа рэкамендуе прыватны WebSocket-паток ордэраў. Binance перадае змены статусу і накоплены выкананы аб'ём у падзеі абнаўлення ордэра. У дакументацыі OKX таксама апісана падпіска на канал ордэраў і пераходы паміж станамі live, filled і адменай.

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

Тайм-аўт і небяспечны паўтор

Тайм-аўт азначае толькі тое, што кліент не атрымаў адказ своечасова. Ён не паказвае, дастаўся ці запыт да гандлёвай сістэмы.

Ёсць два сцэнары:

  • біржа не атрымала заяўку;
  • біржа атрымала і нават выканала заяўку, але адказ страціўся па дарозе.

Калі адразу паўтарыць запыт без праверкі, у другім сцэнары з'явіцца другі ордар. Таму гандлёвая інтэграцыя звычайна выкарыстоўвае унікальны кліенцкі ідэнтыфікатар і ідэмпатэнтную апрацоўку на сваёй баку. Пасля невызначанага выніку сістэма спачатку шукае ордар па ідэнтыфікатару або аднаўляе яго праз гісторыю і паток падзей. Новы ордар патрэбны толькі пасля таго, як папярэдняя спроба класіфікавана.

Гэта агульны прынцып надзейнай інтэграцыі, а не заява пра канкрэтную ўнутраную рэалізацыю 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. Класіфікаваць прычыну. Тайм-аўт, адмова, частковае выкананне, адмена, ручная здзелка, страта падзеі або змена налад.
  7. Выбраць дзеянне. Назіраць, адмяніць астатак, адправіць карэкціруючую заяўку, заблакаваць аўтаматычную карэкцыю або перадаць выпадак аператару.
  8. Праверыць канчатковы стан. Пасля дзеяння зноў запытаць біржавы факт.

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

Тыповыя сцэнарыі

Назіранне Магчымая прычына Што правяраць да паўторнай заяўкі
Няма адказу пасля адпраўкі тайм-аўт або страта злучэння client order ID, гісторыю ордэраў і прыватны паток
Статус застаецца partially filled недастатковая ліквіднасць або лімітная цана выкананы аб'ём, астатак, тэрмін дзеяння і бягучая мэта
Ордар адменены ручная адмена, IOC/FOK, правіла біржы канчатковы статус і прычына адмены
Пазіцыя адрозніваецца пры адсутнасці адкрытых ордэраў ручная здзелка, страчанае падзея, іншы рэжым пазіцыі гісторыю выкананняў і налады рахунку
Пасля retry аб'ём стаў больш мэты першая спроба была прынята абодва order ID і правіла паўторнай адпраўкі

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

Што павінен бачыць карыстальнік

Статус «здзелка скапіявана» недастаткова. Ён аб’ядноўвае некалькі розных станаў і стварае ілжывую ўпэўненасць.

Больш карысна паказваць асобна:

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

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

Як гэты матэрыял звязаны з іншымі праверкамі

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

Гэтыя праверкі не ліквідуюць рынкавую рызыку. Яны аддзяляюць прычыны разыходжанняў і даюць аператару доказы для карэктнага дзеяння.

Матэрыял носіць адукацыйны характар і апісвае агульныя прынцыпы гандлёвых інтэграцый. Ён не з'яўляецца гарантыяй канкрэтнага выканання, характарыстыкай усіх падключаных пляцовак або інвестыцыйнай рэкамендацыяй.