Im Backtest existiert das Problem nicht: Dort läuft alles in einem Prozess, nichts stürzt ab, nichts geht verloren. Im Live-Betrieb ist die Lage anders. Prozesse werden neu gestartet, Server rebooten nach Updates, Verbindungen brechen mitten in einer Order ab. Nach jedem dieser Ereignisse stellt sich dieselbe Frage: Was weiss der Bot noch über seine offenen Positionen, seine wartenden Orders und seine laufende Strategie-Logik? Die Antwort entscheidet darüber, ob er kontrolliert weiterarbeitet — oder blind doppelt kauft.
Zwei Wahrheiten, ein Problem
Ein Trading-Bot verwaltet immer zwei Zustandsbilder. Das interne Bild: was die Software glaubt — offene Positionen, platzierte Orders, Zwischenstände der Strategie. Und das externe Bild: was bei der Börse tatsächlich der Fall ist. Im Idealfall sind beide identisch. In der Praxis laufen sie auseinander, sobald etwas Unerwartetes passiert: Eine Order wird ausgeführt, während die Verbindung tot ist. Ein Teil-Fill kommt an, aber die Bestätigung geht verloren. Der Prozess stirbt zwischen „Order gesendet" und „Antwort gespeichert".
Persistenz: Zustand überlebt den Prozess
Der erste Baustein ist banal und wird trotzdem oft übersprungen: Der Bot muss seinen Zustand ausserhalb des Arbeitsspeichers sichern. Jede Order, jede Positionsänderung, jeder relevante Strategie-Zwischenstand gehört in eine Datenbank oder zumindest in eine Datei — und zwar bevor die Aktion ausgelöst wird, nicht danach. Wer erst nach der Order speichert, hat im Absturzmoment eine Order im Markt, von der die eigene Software nichts weiss.
Reconciliation: der Abgleich mit der Börse
Der zweite Baustein ist der eigentliche Kern: Beim Start fragt der Bot die Börse nach dem tatsächlichen Stand — offene Orders, Positionen, Kontostand — und vergleicht ihn mit dem gespeicherten Bild. Erst wenn dieser Abgleich abgeschlossen ist, darf die Strategie wieder handeln. Der Ablauf in vier Schritten:
- Offene Orders von der Börse abrufen und mit den lokal gespeicherten vergleichen
- Positionen und Salden gegen die eigene Buchführung prüfen
- Abweichungen klassifizieren: erklärbar (Fill während der Downtime) oder unerklärlich
- Erst nach sauberem Abgleich neue Signale zulassen — vorher gilt Handelssperre
Die Börse ist die einzige Quelle der Wahrheit. Der lokale Zustand ist nur eine Vermutung darüber — und jede Vermutung muss nach einem Neustart überprüft werden, bevor Geld bewegt wird.
Idempotenz: dieselbe Aktion darf nicht doppelt wirken
Eng verwandt ist die Frage, was passiert, wenn ein Bot nach dem Neustart ein altes Signal erneut verarbeitet. Ohne Schutz platziert er dieselbe Order zweimal. Die Lösung sind Client-Order-IDs: Jede Order bekommt eine eindeutige, selbst vergebene Kennung. Sendet der Bot dieselbe ID erneut, lehnt die Börse die Dublette ab oder liefert den Status der bestehenden Order. So wird aus „nochmal senden" ein harmloses „Status prüfen" statt einer doppelten Position.
Wenn der Abgleich scheitert
Der wichtigste Grundsatz: Bei unerklärlichen Abweichungen handelt der Bot nicht weiter. Eine Position, die es laut lokaler Buchführung nicht geben dürfte, ist kein Schönheitsfehler, sondern ein Alarmsignal — möglicherweise ein Softwarefehler, möglicherweise ein Sicherheitsproblem. Ein robuster Bot geht dann in einen sicheren Modus: keine neuen Orders, sofortige Benachrichtigung, manuelle Freigabe vor dem Weiterbetrieb. Das kostet im Zweifel ein paar verpasste Trades und verhindert im Gegenzug den einen Vorfall, der das Konto ernsthaft beschädigt.
Abgleich auch im laufenden Betrieb
Reconciliation ist keine reine Start-Routine. Auch im Normalbetrieb driften Zustände schleichend auseinander — durch verpasste WebSocket-Nachrichten, Rundungsdifferenzen oder Teilausführungen. Ein periodischer Abgleich, etwa alle paar Minuten, erkennt solche Drifts früh, solange sie noch klein und erklärbar sind. In Kombination mit Logging und Monitoring entsteht so ein Betrieb, in dem Überraschungen selten sind und Abweichungen eine Geschichte erzählen, statt ein Rätsel zu sein.
Neustarts gehören in den Dry-Run
Wie jeder Sicherheitsmechanismus muss auch die Reconciliation geprobt werden, bevor sie im Ernstfall zum ersten Mal läuft. Im Dry-Run oder auf dem Testnet lässt sich das gefahrlos durchspielen: Prozess mitten im Betrieb hart beenden, neu starten und prüfen, ob der Bot seinen Zustand korrekt rekonstruiert, Abweichungen erkennt und im Zweifel in den sicheren Modus geht. Wer diesen Test nie gemacht hat, weiss schlicht nicht, wie sich sein System nach einem echten Absturz verhält.
Strategie-Ideen gibt es viele. Was einen dauerhaft betreibbaren Bot von einem Skript unterscheidet, ist unspektakuläre Handwerksarbeit: Zustand sichern, gegen die Börse abgleichen, Dubletten verhindern, im Zweifel stoppen. Wer diese Ebene überspringt, testet sie unfreiwillig — mit echtem Geld.