Börsen fallen aus. Nicht selten, nicht überraschend, sondern regelmäßig — durch Wartungsfenster, Überlast in volatilen Phasen, Störungen beim Anbieter oder Netzprobleme auf dem eigenen Weg dorthin. Ein Handelssystem, das nur den Normalfall kennt, ist deshalb kein fertiges System. Dieser Beitrag ordnet das Thema technisch ein und stellt ausdrücklich keine Anlageberatung dar.
Fünf Ausfallarten, die sich unterschiedlich anfühlen
- Vollständiger Ausfall: Die Schnittstelle antwortet gar nicht. Unangenehm, aber eindeutig erkennbar.
- Teilausfall: Kursdaten kommen, Orderfunktionen antworten nicht. Das System sieht Signale, kann aber nicht handeln.
- Degradierter Betrieb: Alles antwortet, aber langsam. Die gefährlichste Variante, weil sie nach Normalbetrieb aussieht.
- Stale Data: Der Datenstrom läuft, liefert aber alte Kurse. Ohne Prüfung des Zeitstempels handelt der Bot auf einem eingefrorenen Bild.
- Ungewisse Quittung: Die Order wurde gesendet, die Antwort ging verloren. Der Zustand ist unbekannt.
Der letzte Fall ist der teuerste. Wer bei ausbleibender Antwort einfach erneut sendet, riskiert eine doppelte Position. Wer gar nichts tut, hat womöglich eine ungesicherte offene Position. Beides lässt sich nur vermeiden, wenn jede Order eine eigene, vom System vergebene Kennung trägt, mit der sich ihr Zustand später zweifelsfrei abfragen lässt.
Erkennen, bevor es weh tut
Ein Ausfall muss aktiv festgestellt werden, nicht erst durch eine Fehlermeldung. Bewährt haben sich drei Wächter, die unabhängig voneinander laufen: ein Heartbeat auf die Schnittstelle, eine Prüfung des Alters der zuletzt empfangenen Kursdaten und eine Beobachtung der Antwortzeiten. Überschreitet einer dieser Werte seine Schwelle, gilt die Verbindung als gestört — auch wenn technisch noch Daten fließen.
Wichtig ist eine klare Zustandslogik statt eines Flickenteppichs aus Wiederholungen. Ein System sollte jederzeit wissen, in welchem von wenigen definierten Zuständen es sich befindet: normal, eingeschränkt, angehalten, im Abgleich. Jeder Zustand erlaubt genau bestimmte Aktionen.
Der Zustandsabgleich nach der Rückkehr
Wenn die Verbindung zurückkommt, ist der erste Reflex meist falsch. Nicht handeln, sondern abgleichen. Die Reihenfolge, die sich bewährt hat:
- Offene Orders abfragen und mit dem eigenen Orderbuch vergleichen.
- Positionen und Kontostand abfragen und gegen den intern erwarteten Stand prüfen.
- Ausführungen im Ausfallzeitraum abrufen und nachbuchen.
- Abweichungen protokollieren. Erst wenn interne und externe Sicht übereinstimmen, wird der Handel wieder freigegeben.
Weicht etwas ab und lässt sich nicht auflösen, ist Anhalten die richtige Antwort. Ein System, das auf Basis eines falschen Positionsstands weiterrechnet, produziert Folgefehler, die schwerer zu korrigieren sind als der ursprüngliche Ausfall.
Verwaiste Absicherungen
Besonders unangenehm sind Absicherungsorders, die während des Ausfalls verschwinden oder nie ankamen. Manche Handelsplätze löschen offene Orders nach Wartungsfenstern, andere behalten sie. Ein System, das sich auf serverseitige Stopps verlässt, muss deren Existenz nach jeder Störung ausdrücklich bestätigen, nicht annehmen. Eine ergänzende clientseitige Überwachung ist sinnvoll, ersetzt aber nichts: Sie funktioniert nur, solange die Verbindung steht.
Was in den Betrieb gehört
- Wartungsfenster kennen: Angekündigte Wartungen sind planbar. Ein Kalender verhindert, dass ein geplantes Fenster als Störung behandelt wird.
- Zeitsynchronisation: Ohne saubere Systemzeit sind Signaturen und Zeitfenster unzuverlässig — ein Punkt mit vielen stillen Nebenwirkungen.
- Getrennte Alarmwege: Wer nur über denselben Kanal alarmiert, über den auch gehandelt wird, erfährt vom Ausfall zuletzt.
- Manuelle Übersteuerung: Ein Mensch muss jederzeit alles anhalten und schließen können, ohne Kenntnis der Programmlogik.
Testen, was man nicht sehen will
Ausfallverhalten lässt sich nur bewerten, wenn es geprobt wurde. Sinnvoll sind gezielte Übungen: Netzwerk trennen, künstliche Verzögerungen einbauen, Fehlerantworten simulieren, den Prozess mitten in einer Order beenden. Was danach beim Neustart passiert, ist die eigentliche Qualitätsaussage über das System. Diese Tests gehören in eine Testumgebung, niemals in den Livebetrieb mit echtem Kapital.
Der Abschaltmechanismus ist dabei das letzte Sicherheitsnetz und sollte unabhängig von der übrigen Logik funktionieren — die Kriterien dafür beschreibt der Beitrag zum Kill-Switch und zur Notabschaltung. Ein System, das im Zweifel stillsteht, verliert Gelegenheiten. Ein System, das im Zweifel weiterläuft, verliert Kapital.