Ein Abonnent kann das richtige Signal erhalten und trotzdem in der falschen Position sein. Die Ursache liegt oft nicht in der Logik des Leaders, sondern in der Zeit zwischen dem Absenden der Order und ihrem endgultigen Status: Timeout, Teilausfuhrung, Stornierung, erneute Anfrage oder manueller Handel im Konto.

Damit sich solche Abweichungen nicht anhaufen, benotigt das Copytrading-System einen eigenen Abgleich. Dieser vergleicht die Zielposition, bekannte aktive Orders und den tatsachlichen Zustand des Borsenkontos. Keine dieser Quellen allein kann als vollstandiges Bild betrachtet werden.

Drei Zustande eines Trades

Nach dem Signal gibt es mindestens drei verschiedene Zustande.

Absicht des Systems. Welche Position der Abonnent nach Anwendung des Kopierfaktors, Risikobeschrankungen, Mindestlos und Rundung haben sollte.

Gesendete, aber noch nicht abgeschlossene Orders. Diese konnen die Position bereits verandern, obwohl das aktuelle Volumen auf dem Konto noch nicht angepasst wurde.

Fakt des Borsenstatus. Orders, Ausfuhrungen und Position, die die Borse uber den privaten Stream und Kontroll-REST-Requests zuruckgibt.

Wenn man nur die Zielposition mit der aktuellen Position vergleicht, kann das System eine ausstehende Order ubersehen und ein zu gro?es Volumen senden. Vertraut man nur auf das lokale Log, sieht man keine manuellen Trades oder Anderungen, die nach Verbindungsverlust passiert sind. Der Abgleich muss beide Quellen berucksichtigen.

Warum die Antwort auf die Ordererstellung die Operation nicht abschlie?t

Borsen-APIs arbeiten asynchron. Eine erfolgreiche Antwort auf eine Anfrage bestatigt meist nur, dass die Plattform die Anfrage zur Verarbeitung angenommen hat. Der Status der Order kann sich danach andern.

In der Bybit-Dokumentation sind fur das Abrufen offener und geschlossener Orders die Zustande unbefullt, teilweise ausgefuhrt und kurzlich abgeschlossen separat genannt. Fur Echtzeitaktualisierungen empfiehlt die Borse den privaten WebSocket-Order-Stream. Binance sendet Statusanderungen und das kumulierte ausgefuhrte Volumen in einem Order-Update-Event. In der OKX-Dokumentation wird ebenfalls ein Abonnement auf den Order-Kanal und Zustandsubergange zwischen live, filled und Stornierung beschrieben.

Daraus folgt eine praktische Regel: HTTP-Antwort, Order-Event und Kontoposition sind unterschiedliche Nachweise. Fur eine endgultige Bewertung mussen sie uber eine stabile ID verknupft werden.

Timeout und gefahrliche Wiederholung

Ein Timeout bedeutet nur, dass der Client nicht rechtzeitig eine Antwort erhalten hat. Es zeigt nicht, ob die Anfrage die Handelsplattform erreicht hat.

Es sind zwei Szenarien moglich:

  • Die Borse hat die Order nicht erhalten;
  • Die Borse hat die Order erhalten und sogar ausgefuhrt, aber die Antwort ist auf dem Weg verschwunden.

Wenn man ohne Uberprufung sofort erneut sendet, entsteht im zweiten Szenario eine doppelte Order. Daher verwenden Handelsintegrationen ublicherweise eine eindeutige Client-ID und eine idempotente Verarbeitung auf ihrer Seite. Nach einem unbestimmten Ergebnis sucht das System zuerst nach der Order anhand der ID oder stellt sie uber Historie und Event-Stream wieder her. Eine neue Order wird nur gesendet, wenn der vorherige Versuch klassifiziert ist.

Dies ist ein generelles Prinzip zuverlassiger Integrationen und keine Aussage uber eine konkrete interne Umsetzung von CopyTrader.

Teilausfuhrungen andern die Delta-Berechnung

Angenommen, die Zielposition des Abonnenten ist 1,0 BTC, die aktuelle tatsachliche Position 0,6 BTC und eine offene Kauforder uber 0,4 BTC ist bereits zur Halfte ausgefuhrt.

Wenn die Borse die ausgefuhrten 0,2 BTC bereits in die aktuelle Position einbezogen hat, verbleiben noch 0,2 BTC offen. Der zu berucksichtigende Zustand lautet:

tatsachliche Position + nicht ausgefuhrter Rest der aktiven Orders.

Im Beispiel sind das 0,8 + 0,2 = 1,0 BTC. Eine zusatzliche Order ist nicht notwendig.

Betrachtet das System nur die Position von 0,8 BTC, konnte es weitere 0,2 BTC senden und nach Abschluss der ersten Order auf 1,2 BTC kommen. Rechnet es hingegen das gesamte ursprungliche Ordervolumen auf die bereits aktualisierte Position drauf, entsteht ein Fehler, da der ausgefuhrte Teil doppelt berucksichtigt wird.

Die genaue Formel hangt vom Positionsmodell, der Richtung, dem Hedge/One-Way-Modus und dem Borsenkontrakt ab. Grundprinzip: Das ausgefuhrte Volumen und der offene Rest durfen nicht vermischt werden.

Reconciliation-Loop von Orders und Position

Ein praktischer Abgleichszyklus besteht aus mehreren Schritten.

  1. Ziel abrufen. Die Zielposition nach Kopierregeln und Abonnentenbeschrankungen festhalten.
  2. Borsenstatus erfassen. Aktuelle Position, aktive Orders und jungste Endstatus holen.
  3. IDs verknupfen. Internen Beschluss, Client-ID und Borsen-Order-ID zuordnen.
  4. Zustand normalisieren. Richtung, ausgefuhrtes Volumen, offenen Rest, Mengenschritt und Positionsmodus berucksichtigen.
  5. Abweichung berechnen. Ziel mit tatsachlicher Position und ausfuhrbarem Volumen vergleichen.
  6. Ursache klassifizieren. Timeout, Ablehnung, Teilausfuhrung, Stornierung, manueller Trade, fehlendes Event oder Einstellungsanderung.
  7. Ma?nahme wahlen. Beobachten, Rest stornieren, korrigierende Order senden, automatische Korrektur blockieren oder den Fall an den Operator weitergeben.
  8. Endzustand prufen. Nach Ma?nahme erneut Borsenstatus abfragen.

Eine automatische Korrektur ist nicht immer geeignet. Ist die Ursache unbekannt oder wurde eine Fremdaktivitat im Konto festgestellt, ist es sicherer, anzuhalten und die Abweichung anzuzeigen, als endlos mit neuen Marktorders die Zielposition zu erzwingen.

Typische Szenarien

Beobachtung Mogliche Ursache Was vor erneuter Orderprufung
Keine Antwort nach Absenden Timeout oder Verbindungsverlust Client Order ID, Orderhistorie und privater Stream
Status bleibt partially filled unzureichende Liquiditat oder Limitpreis ausgefuhrtes Volumen, Rest, Verfallszeit und aktuelles Ziel
Order storniert manuelle Stornierung, IOC/FOK, Borsenregel Endstatus und Stornierungsgrund
Position weicht ohne offene Orders ab manueller Trade, verlorenes Event, anderer Positionsmodus Ausfuhrungshistorie und Kontoeinstellungen
Nach Wiederholung wurde Volumen gro?er als Ziel erster Versuch wurde angenommen beide Order IDs und Wiederholungsregel

Die Tabelle erleichtert den Einstieg in die Untersuchung, ersetzt aber nicht den Vertrag der einzelnen Borse. Statusnamen und Ereignisablauf unterscheiden sich.

Was der Benutzer sehen sollte

Der Status „Trade kopiert“ reicht nicht aus. Er fasst verschiedene Zustande zusammen und schafft falsches Vertrauen.

Hilfreich ist die separate Anzeige von:

  • Signal empfangen;
  • Order vorbereitet;
  • Order von Borse akzeptiert;
  • teilweise oder vollstandig ausgefuhrt;
  • abgelehnt oder storniert;
  • Position abgeglichen;
  • Abweichung erkannt und Aktion erforderlich.

Fur strittige Falle wird ein minimales Protokoll ohne geheime Daten benotigt: Zeit, Instrument, Richtung, angefragtes und ausgefuhrtes Volumen, Durchschnittspreis, Endstatus und interner Identifier. API-Schlussel und andere Kontodaten sollten in diesem Log nicht auftauchen.

Wie dieser Text mit anderen Checks zusammenhangt

Synchronisierung der Einstellungen beantwortet die Frage, ob es sicher ist, eine Trade-Kopie mit den aktuellen Kontoeinstellungen zu senden. Slippage-Studie zeigt, warum dasselbe Signal nicht denselben durchschnittlichen Preis garantiert. Der Abgleich nach Ausfuhrung lost die dritte Aufgabe: Entsprach der tatsachliche Zustand dem, den das System erzeugen wollte.

Diese Prufungen beseitigen das Marktrisiko nicht. Sie trennen Ursachen von Abweichungen und liefern dem Operator Beweise fur richtige Ma?nahmen.

Der Text hat einen Bildungscharakter und beschreibt allgemeine Prinzipien von Handelsintegrationen. Er stellt keine Garantie fur eine konkrete Umsetzung dar, ist keine Charakterisierung aller angebundenen Borsen und ist keine Anlageempfehlung.