L'abbonato puo ricevere il segnale corretto e comunque ritrovarsi in una posizione sbagliata. La causa spesso non si trova nella logica del leader, ma tra l'invio dell'ordine e il suo stato finale: timeout, esecuzione parziale, annullamento, richiesta ripetuta o operazione manuale sul conto.

Per evitare che tali discrepanze si accumulino, il sistema di copytrading necessita di una riconciliazione separata. Questa confronta la posizione target, gli ordini attivi noti e lo stato effettivo del conto di borsa. Nessuna di queste fonti puo essere considerata l'immagine completa da sola.

Tre stati di una singola operazione

Dopo il segnale esistono almeno tre stati diversi.

Intenzione del sistema. Quale posizione dovrebbe avere l'abbonato dopo l'applicazione del coefficiente di copia, dei limiti di rischio, del lotto minimo e dell'arrotondamento.

Ordini inviati ma non completati. Possono gia modificare la posizione, anche se il volume attuale sul conto non e ancora cambiato.

Fatto di Borsa. Ordini, esecuzioni e posizione che la borsa restituisce tramite il flusso privato e le chiamate REST di controllo.

Se si confronta solo l'obiettivo con la posizione attuale, il sistema potrebbe non notare un ordine in transito e inviare volume in eccesso. Se ci si affida solo al registro locale, non si vedra un'operazione manuale o una modifica avvenuta dopo una perdita di connessione. La riconciliazione deve considerare entrambe le fonti.

Perche la risposta alla creazione di un ordine non conclude l'operazione

Le API di borsa funzionano in modo asincrono. La risposta positiva ad una richiesta di solito indica che la piattaforma ha accettato la richiesta per l'elaborazione. Lo stato dell'ordine puo cambiare successivamente.

Nella documentazione di Bybit, per ottenere gli ordini aperti e chiusi sono indicati separatamente stati come non riempiti, esecuzione parziale e recentemente completati. Per aggiornamenti tempestivi, la borsa raccomanda un flusso WebSocket privato degli ordini. Binance trasmette le variazioni dello stato e il volume eseguito accumulato nell'evento di aggiornamento ordine. Anche la documentazione di OKX descrive la sottoscrizione al canale ordini e le transizioni tra gli stati live, filled e annullamento.

Da cio si ricava una regola pratica: risposta HTTP, evento ordine e posizione nel conto sono testimonianze diverse. Per una conclusione finale, devono essere collegate mediante un identificatore stabile.

Timeout e ripetizione pericolosa

Timeout indica solo che il client non ha ricevuto la risposta in tempo. Non indica se la richiesta e arrivata al sistema di trading.

Sono possibili due scenari:

  • la borsa non ha ricevuto l'ordine;
  • la borsa ha ricevuto e persino eseguito l'ordine, ma la risposta si e persa durante il percorso.

Se si ripete immediatamente la richiesta senza verifica, nel secondo scenario si creera un secondo ordine. Percio l'integrazione di trading di solito utilizza un identificatore cliente univoco e un'elaborazione idempotente lato proprio. Dopo un risultato incerto, il sistema cerca prima l'ordine tramite l'identificatore o lo recupera tramite lo storico e il flusso di eventi. Un nuovo ordine e necessario solo dopo che il tentativo precedente e stato classificato.

Questo e un principio generale di integrazione affidabile e non una dichiarazione su una specifica implementazione interna di CopyTrader.

L'esecuzione parziale modifica il calcolo della delta

Supponiamo che la posizione target dell'abbonato sia 1,0 BTC, la posizione attuale effettiva sia 0,6 BTC e un ordine di acquisto aperto di 0,4 BTC sia stato eseguito per meta.

Se la borsa ha gia incluso i 0,2 BTC eseguiti nella posizione attuale, resta aperta una quantita di 0,2 BTC. Lo stato considerato e:

posizione effettiva residuo non eseguito degli ordini attivi.

Nell'esempio, questo e 0,8 0,2 = 1,0 BTC. Non serve un ordine aggiuntivo.

Se il sistema guarda solo alla posizione di 0,8 BTC, potrebbe inviare altri 0,2 BTC e dopo la conclusione del primo ordine ritrovarsi con 1,2 BTC. Se invece calcola l'intero volume originale dell'ordine sopra la posizione gia aggiornata, l'errore avverra per un motivo diverso: la parte eseguita sara conteggiata due volte.

La formula specifica dipende dal modello di posizione, dalla direzione, dalla modalita hedge/one-way e dal contratto di borsa. Ma il principio e uno: il volume eseguito e il residuo aperto non devono essere mescolati.

Ciclo di riconciliazione ordini e posizione

Un ciclo pratico di riconciliazione consiste in diversi passaggi.

  1. Ottenere l'obiettivo. Registrare la posizione target dopo le regole di copia e le limitazioni dell'abbonato.
  2. Rilevare il fatto di borsa. Ottenere posizione attuale, ordini attivi e stati finali recenti.
  3. Associare gli identificatori. Abbinare la decisione interna, l'ID cliente e l'ID ordine di borsa.
  4. Normalizzare lo stato. Considerare direzione, volume eseguito, residuo aperto, step di quantita e modalita di posizione.
  5. Calcolare la discrepanza. Confrontare l'obiettivo con la posizione effettiva e il volume ancora eseguibile.
  6. Classificare la causa. Timeout, rifiuto, esecuzione parziale, annullamento, operazione manuale, perdita evento o cambiamento configurazione.
  7. Scegliere l'azione. Osservare, annullare il residuo, inviare un ordine correttivo, bloccare la correzione automatica o passare il caso a un operatore.
  8. Verificare lo stato finale. Dopo l'azione, richiedere di nuovo il fatto di borsa.

La correzione automatica non e sempre adatta. Se la causa e sconosciuta o c'e attivita esterna rilevata sul conto, e piu sicuro fermarsi e mostrare la discrepanza che inseguire indefinitamente l'obiettivo con nuovi ordini di mercato.

Scenari tipici

Osservazione Possibile causa Cosa verificare prima di inviare un nuovo ordine
Nessuna risposta dopo invio timeout o perdita connessione ID ordine cliente, storico ordini e flusso privato
Stato rimane partially filled liquidita insufficiente o prezzo limite volume eseguito, residuo, scadenza e obiettivo corrente
Ordine annullato annullamento manuale, IOC/FOK, regola borsa stato finale e motivo annullamento
Posizione differisce senza ordini aperti operazione manuale, evento perso, modalita posizione diversa storico esecuzioni e impostazioni conto
Dopo retry il volume supera l'obiettivo prima tentativo accettato entrambi gli ID ordine e regola retry

La tabella aiuta a iniziare un'indagine, ma non sostituisce il contratto specifico di ogni borsa. Nomi degli stati e ordine degli eventi variano.

Cosa deve vedere l'utente

Lo stato "operazione copiata" non e sufficiente. Unisce diversi stati e crea una falsa sicurezza.

E piu utile mostrare separatamente:

  • segnale ricevuto;
  • ordine preparato;
  • ordine accettato dalla borsa;
  • eseguito parzialmente o completamente;
  • rifiutato o annullato;
  • posizione riconciliata;
  • discrepanza rilevata e richiesta azione.

Per casi controversi serve un registro minimo senza segreti: tempo, strumento, direzione, volume richiesto ed eseguito, prezzo medio, stato finale e link all'identificatore interno. Chiavi API e altri dati di accesso non devono comparire in tale registro.

Come questo materiale si collega ad altre verifiche

La sincronizzazione delle impostazioni risponde alla domanda se e sicuro inviare la copia di un'operazione con i parametri attuali del conto. Lo studio dello slippage mostra perche lo stesso segnale non garantisce lo stesso prezzo medio. La riconciliazione post-esecuzione risolve un terzo compito: se lo stato reale corrisponde a quello che il sistema ha inteso creare.

Questi controlli non eliminano il rischio di mercato. Separano le cause delle discrepanze e forniscono all'operatore prove per un'azione corretta.

Il materiale ha uno scopo educativo e descrive principi generali di integrazione commerciale. Non rappresenta una garanzia di esecuzione specifica, la caratteristica di tutte le piattaforme collegate o una raccomandazione di investimento.