Zwischen dem Absenden einer Order und dem Eintreffen der Bestätigung liegt ein Zeitfenster, in dem der Bot den Zustand des Marktes nicht kennt. Bricht die Verbindung genau dort ab, gibt es zwei Möglichkeiten: Die Order ist nie angekommen — oder sie ist angekommen, ausgeführt worden, und nur die Antwort ging verloren. Beide Fälle sehen für den Bot identisch aus.
Wer in dieser Situation einfach erneut sendet, riskiert die doppelte Position. Wer gar nichts tut, riskiert eine offene Position ohne Absicherung. Beides ist teurer als jede Strategieschwäche, weil es unabhängig von der Marktrichtung wirkt.
Idempotenz: derselbe Aufruf, dasselbe Ergebnis
Idempotent heißt, dass die mehrfache Ausführung derselben Anfrage denselben Zustand erzeugt wie die einmalige. Für Orders ist das nicht automatisch gegeben — zwei identische Kaufaufträge sind zwei Käufe. Erreicht wird Idempotenz über eine vom Bot vergebene, eindeutige Kennung je Order, die mitgesendet wird.
Nahezu alle relevanten Handelsplätze unterstützen ein solches Feld. Kommt dieselbe Kennung ein zweites Mal an, wird die Order als Duplikat abgewiesen. Der Wiederholungsversuch wird damit ungefährlich: Entweder er legt die Order an, oder er erhält die Meldung, dass sie bereits existiert — und in beiden Fällen existiert am Ende genau eine.
Die Kennung richtig bilden
- Deterministisch: Aus Strategie, Instrument, Signalzeitpunkt und laufender Nummer — nicht aus einem Zufallswert, sonst erzeugt der Wiederholungsversuch eine neue Kennung und damit eine neue Order.
- Vor dem Senden persistiert: Die Kennung muss auf der Platte stehen, bevor die Anfrage rausgeht. Stürzt der Prozess dazwischen ab, weiß der Neustart sonst nicht, wonach er suchen soll.
- Formatkonform: Länge und erlaubte Zeichen sind je Börse begrenzt; eine abgewiesene Kennung führt zur abgewiesenen Order.
- Wiederfindbar: Die Kennung gehört in die eigene Datenbank, damit der Abgleich sie später der Börsenantwort zuordnen kann.
Die Reihenfolge ist der eigentliche Kern: erst Absicht speichern, dann senden, dann Ergebnis speichern. Wer zuerst sendet und danach schreibt, hat nach einem Absturz eine Order am Markt, von der das eigene System nichts weiß. Diese unsichtbare Position ist der Ausgangspunkt der meisten schweren Betriebsfehler.
Was bei welchem Fehler zu tun ist
Nicht jeder Fehler rechtfertigt einen Wiederholungsversuch. Ein Verbindungsabbruch vor dem Senden ist unkritisch und darf sofort wiederholt werden. Ein Timeout nach dem Senden ist der kritische Fall: Hier darf nicht blind wiederholt, sondern muss zuerst der tatsächliche Zustand abgefragt werden — über die Kennung oder über die Liste offener und kürzlich ausgeführter Orders.
Eine fachliche Ablehnung, etwa wegen unzureichendem Guthaben oder ungültiger Ordergröße, darf dagegen nie wiederholt werden. Sie ist kein Übertragungsproblem, sondern ein Zustandsproblem, und ein Wiederholungsversuch erzeugt nur Last und läuft im schlimmsten Fall in eine Sperre wegen zu vieler Anfragen.
Abgleich als Pflichtschritt
Jeder Bot braucht eine Routine, die den eigenen Zustand gegen den der Börse prüft: offene Orders, Positionen und Guthaben. Diese Routine muss zwingend beim Start und nach jedem Verbindungsabbruch laufen, sinnvollerweise zusätzlich in festem Takt.
Findet der Abgleich eine Abweichung, ist die Börse die Wahrheit — nicht der eigene Speicherstand. Der Bot übernimmt den fremden Zustand und protokolliert die Differenz. Was er in diesem Moment auf keinen Fall tun darf, ist eigenmächtig ausgleichen: Eine automatische Gegenorder auf Basis eines möglicherweise unvollständigen Bildes verdoppelt den Schaden. Der richtige Standardweg ist Pause plus Alarm. Mehr dazu im Beitrag State Reconciliation: Bot-Zustand nach Neustart.
Testen, was sich nicht von selbst zeigt
Diese Fehler treten im Normalbetrieb selten auf und lassen sich deshalb nicht durch Warten finden. Sie müssen erzwungen werden: Antwort künstlich verzögern, bis der eigene Timeout greift; Prozess zwischen Senden und Speichern hart beenden; dieselbe Order zweimal absetzen; Netzwerkverbindung während einer offenen Anfrage kappen.
Läuft der Bot durch alle vier Szenarien und steht danach mit genau einer Position da, ist die Ausführungsschicht belastbar. Bis dahin ist jede Aussage über die Zuverlässigkeit eine Vermutung — und in einem System, das ohne Aufsicht Aufträge auslöst, ist eine Vermutung die falsche Grundlage.