Wir haben eine Paper-Trading-Strategie mitten in einem Trade neu gestartet und eine andere Orderabfolge erhalten als vor dem Neustart. Dieselben Marktdaten, dieselbe Strategieversion, derselbe Kontostand. Die Signalberechnung stimmte überein. Das Gedächtnis der Strategie für ihre Position und ausstehenden Orders dagegen nicht.
Wir haben die Abweichung im Laufe eines Tages mit Replay-Tests zurückverfolgt. Die wichtige Erkenntnis war einfach: Für deine Software ist ein Neustart ein Marktereignis. Wenn du nicht testest, wie die Strategie ihren Zustand wiederherstellt, kann ein sauberer Backtest ein Paper-Trading-System verbergen, das vergisst, was ihm gehört.
09:10 — Wir wählten eine unspektakuläre Position
Die Teststrategie handelte einen liquiden Perpetual: Long einsteigen, wenn ein kurzer gleitender Durchschnitt einen längeren von unten nach oben kreuzt, und beim umgekehrten Kreuzungssignal aussteigen. Wir starteten das Replay mit einer kleinen offenen Position und einer ruhenden Reduce-only-Limitorder, um sie zu verkleinern. So musste die Wiederherstellung 2 Dinge rekonstruieren: was wir hielten und was wir die Börse bereits auszuführen gebeten hatten.
Zum Prüfzeitpunkt hielt das Konto 0.04 Kontrakte. Die offene Order belief sich auf 0.01. Der Strategieprozess hatte beide Werte im Arbeitsspeicher zwischengespeichert, aber beim Start rief er nur die Position ab. Die gespeicherte Order behandelte er als nicht mehr vorhanden.
09:25 — Die erste doppelte Order erschien
Nach dem Neustart erkannte die Strategie die bestehende Long-Position, führte ihre Signal-Logik aus und übermittelte eine weitere Order zum Abbau von 0.01. Auf der Paper-Trading-Börse waren jetzt 2 Orders aktiv. Für sich genommen war keine davon falsch. Zusammen konnten sie die doppelte geplante Menge verkaufen, falls beide ausgeführt würden.
Zuerst gaben wir der Signalschleife die Schuld. Doch es lag nicht an der Schleife, sondern am unvollständigen Snapshot. Die Strategie fragte: „Welche Position habe ich?“, aber nie: „Welche Orders sind noch aktiv?“
| Zustand nach dem Neustart | Was der Prozess annahm | Was das Konto hielt |
|---|---|---|
| Position | Long 0.04 | Long 0.04 |
| Offene Orders zum Abbau | Keine | 2 Orders zu je 0.01 |
| Geplante Position nach einer Ausführung | Long 0.03 | Könnte auf Long 0.02 sinken |
10:00 — Wir korrigierten die Wiederherstellung und fanden dann ein Timing-Problem
Wir änderten den Startvorgang so, dass der Zustand aus den Positionen des Kontos und den offenen Orders wiederhergestellt wird, bevor neue Entscheidungen freigegeben werden. Damit war die doppelte Order behoben. Dann gestalteten wir die Unterbrechung weniger sauber: Eine Order wurde ausgeführt, während die Strategie offline war, und die Ausführungsbenachrichtigung traf erst nach der Wiederverbindung ein.
Der Kontostand hatte die Ausführung im Snapshot bereits berücksichtigt. Die verspätete Benachrichtigung verringerte daraufhin die lokale Position ein zweites Mal. Einige Sekunden lang glaubte die Strategie, 0.02 Kontrakte zu halten, während das Konto 0.03 hielt. Ihr nächster Rebalancing-Schritt beruhte auf einem fälschlich angenommenen Fehlbetrag.
Wir ergänzten Regeln für den Abgleich: Der Kontosnapshot ist der Ausgangspunkt, Ereigniskennungen verhindern, dass bereits darin berücksichtigte Ausführungen erneut angewendet werden, und bis zum Abschluss der ersten Synchronisierung werden keine Orders übermittelt. Eine Benachrichtigung kann verspätet oder doppelt eintreffen. Die Wiederherstellung muss beides verkraften.
13:40 — Das Replay deckte eine unauffällige Abweichung auf
Wir spielten denselben Kursverlauf für den ursprünglichen und den neu gestarteten Lauf erneut ab. Ein Vergleich des abschließenden P&L hätte das Problem nicht aufgedeckt: Nach der Umkehr des Marktes endeten beide Varianten mit derselben Position. Erst der Vergleich der Orderereignisse machte die Abweichung sichtbar.
Wir protokollierten jede Entscheidung zusammen mit dem gelesenen Zustand: Position, offene Orders, Kennung der zuletzt verarbeiteten Ausführung, Signalwert und Strategieversion. So ließ sich das erste abweichende Ereignis erklären. Ein Lauf sah eine aktive Order, der andere eine leere Liste. Später verarbeitete einer eine Ausführung doppelt.
Ein übereinstimmender Endkontostand beweist nicht, dass auch das Verhalten übereinstimmte. Vergleiche die Abfolge von Entscheidungen und Orders, besonders an den Übergängen bei der Wiederherstellung.
16:20 — Was wir beim nächsten Mal anders machen würden
Wir hatten zu lange Kursdaten erneut abgespielt, bevor wir die Zustandsübergänge des Kontos überprüften. Beim nächsten Mal würden wir zuerst die Fehlerfälle gezielt auslösen und den Marktverlauf fast flach halten. So ist der Softwarefehler leichter zu erkennen, ohne dass eine volatile Kursbewegung die Diagnose erschwert.
- Mit einer Position und einer teilweise ausgeführten Order neu starten.
- Nach dem Übermitteln trennen und wieder verbinden, bevor die Ausführungsbenachrichtigung eintrifft.
- Dasselbe Ausführungsereignis zweimal senden und prüfen, ob es den Zustand nur einmal ändert.
- Neue Orders blockieren, bis Positionen und offene Orders abgeglichen sind.
- Entscheidungs- und Orderprotokolle aus durchgehenden und neu gestarteten Läufen vergleichen.
Außerdem haben wir gelernt, neben der Strategieversion und dem Ereignisprotokoll auch einen Snapshot für die Wiederherstellung zu speichern. Damit ließ sich der Fehler in wenigen Minuten reproduzieren, statt darauf angewiesen zu sein, dass sich jemand an die genaue Abfolge der Wiederverbindung erinnerte.
Eine Paper-Trading-Strategie, die sich nur dann korrekt verhält, wenn ihr Prozess am Leben bleibt, hat die vollständige Generalprobe nicht bestanden. Starte sie mitten in einer Position neu, lass Ausführungen verspätet eintreffen und prüfe jede danach übermittelte Order. Es geht nicht darum zu beweisen, dass sie niemals ausfällt. Es geht darum, ihre Wiederherstellung sichtbar zu machen, bevor dich das Paper-Konto auf dieselbe Weise überraschend belehrt.
← Alle Beiträge
