Starte deine Strategie mitten im Backtest neu. Weiß sie noch, was ihr gehört?

Ein nützlicher Backtest-Test hat nichts damit zu tun, einen besseren Parameter zu finden: Stoppe den Prozess auf halber Strecke, stelle ihn wieder her und spiele denselben Lauf zu Ende. Bei identischen Eingaben und einem kontrollierten Ausführungssimulator sollten Entscheidungen, Orders und Eigenkapital mit einem ununterbrochenen Lauf übereinstimmen.

Wenn nicht, hast du ein Problem mit der Zustandsverwaltung gefunden. Die Strategie hängt von etwas ab, das du nicht gespeichert hast oder nicht rekonstruieren konntest. Diese Abhängigkeit ist wichtig, wenn Forschungsdurchläufe fortgesetzt, Worker ersetzt oder neue Codeversionen für einen Paper-Trading-Dienst ausgerollt werden.

Ich mag diesen Test, weil die erwartete Antwort ungewöhnlich eindeutig ist. Es gibt keine Diskussion darüber, ob sich der Markt verändert hat. Beide Läufe erhalten denselben Markt.

Hier sind 3 falsche Wege, neu zu starten. Die Zahlen dienen zur Veranschaulichung; jeder dieser Fehler kann auch in einem ansonsten deterministischen System auftreten.

1. Lade ein paar Kerzen nach und behaupte, die Indikatoren seien aufgewärmt

Nehmen wir an, eine Strategie verwendet einen exponentiellen gleitenden Durchschnitt über 100 Perioden. Seine Aktualisierung lautet:

alpha = 2 / 101
ema_next = alpha * close + (1 - alpha) * ema_previous

Der ununterbrochene Prozess führt den akkumulierten EMA-Zustand weiter. Der neu gestartete Prozess ruft 100 Kerzen ab, initialisiert den EMA mit dem ersten Schlusskurs und geht davon aus, dass ein Indikator über 100 Perioden 100 Beobachtungen benötigt.

Diese Annahme verwechselt den Glättungsparameter des Indikators mit einem Speicherfenster endlicher Länge. Ein EMA behält einen abklingenden Beitrag seines Anfangszustands bei. Beginnen zwei Versionen mit einem EMA-Unterschied von 10 Preiseinheiten, verringern identische Folgekurse diesen Unterschied wie folgt:

Die Rechnung lautet 10 * (99 / 101)^k. Wenn du 100 Kerzen abrufst und die erste Beobachtung als Startwert verwendest, erhältst du nur 99 Aktualisierungen.

Der Schaden zeigt sich meist nahe einer Entscheidungsgrenze. Ein Lauf sieht den Kurs über dem EMA, der andere darunter. Ein kleiner numerischer Unterschied erzeugt einen ganzen zusätzlichen Trade. Danach können auch Abklingzeiten, verfügbares Guthaben und spätere Entscheidungen auseinanderlaufen.

Speichere den rekursiven Indikatorzustand, seinen Initialisierungsstatus und das zuletzt verarbeitete Ereignis. Alternativ kannst du von einem bekannten Anfangszustand an erneut abspielen. Ein längeres Warm-up kann eine akzeptable Näherung liefern, aber lege seine Länge anhand einer ausdrücklichen Fehlertoleranz fest und prüfe, ob diese Toleranz Entscheidungen verändern kann. „Das Fünffache der Periode“ ist eine Konvention, kein Beweis.

Und Indikatoren bilden nicht die gesamte Historie ab. Ein rollendes Perzentil braucht sein Fenster. Ein Online-Modell benötigt möglicherweise den Zustand seines Optimierers. Eine Regel, die nach einem Verlust 3 Kerzen wartet, muss sich an den Verlust und den Zähler erinnern.

2. Speichere Positionen und vergiss die noch offenen Orders

Deine Zielposition beträgt 10 Einheiten. Eine Kauforder über 10 wurde zu 4 ausgeführt, 6 sind noch offen. Du sicherst die Position als 4, startest neu und gibst eine weitere Kauforder über die fehlenden 6 auf.

Wenn sowohl der ursprüngliche Rest als auch die Ersatzorder ausgeführt werden, besitzt du 16 Einheiten.

Im Backtest bleibt dieser Fehler oft verborgen, weil beim Neustart der Fill-Engine offene Orders stillschweigend gelöscht werden. Beim Paper-Trading kann der Simulator oder ein externer Dienst sie beibehalten. Derselbe Wiederherstellungscode führt dann zu unterschiedlichem Exposure, je nachdem, welche Komponente überlebt hat.

Der Schaden zeigt sich in einem unerklärlichen Schub neuer Orders unmittelbar nach der Wiederherstellung. Manchmal verdoppelt sich das Exposure. Manchmal wird eine Position geschlossen, obwohl ihre Schutzorder noch aktiv ist und später eine neue Position eröffnen kann.

Ein Checkpoint muss neben Positionen auch die Order-Identität und den Lebenszyklusstatus enthalten. Bevor die Wiederherstellung neue Aktionen erzeugt, muss sie diese Datensätze mit dem Ausführungssystem abgleichen. Bei einer Order mit unbekanntem Ausgang muss nachgeforscht werden. „Keine Bestätigung gespeichert“ als „nie aufgegeben“ zu behandeln, führt zu doppelten Orders.

Stabile Client-Order-IDs helfen dir dabei, den Ausgang nachzuschlagen. Sie verhindern Duplikate nur dann, wenn das empfangende System die erforderlichen Eindeutigkeits- oder Idempotenzregeln tatsächlich durchsetzt. Speichere auch verarbeitete Ausführungs-IDs, damit ein erneut eingespielter Fill die Position nicht zweimal erhöht.

Ich habe eine Schwäche für den unspektakulären Orderstatus-Bildschirm. Am Tag des Neustarts werden seine kleinen Zeilen plötzlich zur interessantesten Oberfläche im ganzen Gebäude.

3. Stelle die Position wieder her und beginne mit einem frischen P&L-Konto

Betrachten wir ein ungehebeltes Spot-Beispiel ohne Gebühren. Beginne mit $10,000 Bargeld, kaufe 10 Einheiten zu je $100 und setze einen Checkpoint, wenn der Marktkurs $110 erreicht.

Der korrekte Zustand besteht aus $9,000 Bargeld und einer Position im Wert von $1,100: Das Eigenkapital beträgt $10,100. Wenn bei der Wiederherstellung die 10 Einheiten zurückgespielt, das Bargeld aber auf die ursprünglichen $10,000 zurückgesetzt wird, weist das System $11,100 aus. Durch den Neustart eines Prozesses hast du $1,000 geschaffen.

Andere Varianten fallen weniger drastisch aus. Die Wiederherstellung erhält das Eigenkapital, setzt aber den Einstiegskurs auf $110 zurück. Das Gesamteigenkapital kann stimmen, während sich die Zuordnung zwischen realisiertem und nicht realisiertem Ergebnis ändert. Wenn ein Stop oder eine Ausstiegsbedingung auf den Einstiegskurs verweist, verändert diese Abkürzung in der Buchhaltung nun das Handelsverhalten.

Oder das System vergisst den bisherigen Eigenkapitalhöchststand. Angenommen, das Eigenkapital erreichte vor dem Rückgang auf $10,100 einen Höchststand von $10,600. Der Drawdown beträgt etwa 4.72%. Wird der Höchststand bei der Wiederherstellung zurückgesetzt, glaubt die Strategie plötzlich, ihr Drawdown liege bei 0. Jede risikobasierte Kontrolle, die auf dem Drawdown beruht, wurde gerade unautorisiert zurückgesetzt.

Der Schaden kann sich also als Sprung im Eigenkapital, verdächtig verbesserter Drawdown oder Risikoregel zeigen, die nach Deployments nicht mehr greift. Bewahre das Buchungskonto und den buchhaltungsabhängigen Zustand der Strategie auf: Geldbewegungen, Positionen, gegebenenfalls Einstandskosten, aufgelaufene Gebühren und den Zustand der Risikokontrollen. Gleiche das wiederhergestellte Eigenkapital mit dem Buchungskonto zum selben Bewertungszeitpunkt ab.

Den Test, den ich im Forschungs-Harness beibehalten würde, bildet zunächst einen ununterbrochenen Referenzlauf ab und startet dann einen zweiten Lauf an gezielt ungünstigen Punkten neu: während der Indikatorinitialisierung, nach einem Partial Fill und bei aktivem Risikolimit. Verwende dieselbe Ereignisreihenfolge und bewahre jeden Zufallszustand des Simulators auf. Vergleiche die erste Entscheidung nach der Wiederherstellung, die Order- und Fill-Datensätze sowie den Eigenkapitalverlauf. Ein übereinstimmender Endstand allein kann gegenläufige Fehler verbergen.

Für einen Absturz nach dem Absenden, aber vor der Bestätigung, muss der Harness auch den Zustand des Ausführungsdienstes unabhängig vom Strategieprozess bewahren. Andernfalls löscht er genau die Unsicherheit, die du testen willst.

Zur Spezifikation einer Strategie gehört auch, woran sie sich erinnert. Mache dieses Gedächtnis so explizit, dass du den Prozess mitten in einer Wiedergabe beenden und genau zeigen kannst, wie er seine Arbeit wieder aufnimmt.