Backtest

Ein Backtest rechnet eine Trading-Strategie auf historischen Daten durch, um Kennzahlen wie Rendite, Drawdown, Trefferquote und Sharpe vor dem Live-Einsatz zu bewerten.

Die Gefahren sind groß: Overfitting (Strategie nur auf Vergangenheit angepasst), Look-Ahead-Bias (Daten verwendet, die zur Trade-Zeit gar nicht verfügbar waren), Survivorship-Bias (nur überlebende Aktien getestet), unrealistische Annahmen zu Slippage und Gebühren. Ein ehrlicher Backtest folgt Walk-Forward-Logik mit echter Out-of-Sample-Validierung.

Genaue Definition

Ein Backtest ist eine Simulation: Zu jedem historischen Zeitpunkt entscheidet die Strategie nur mit den Daten, die damals bekannt waren, und ein Ausführungsmodell bestimmt, zu welchem Preis und mit welchen Kosten die Order gefüllt worden wäre. Dazu gehören vier Bausteine: die Datenbasis (Kurse oder Ticks, Spreads, Dividenden, historische Index-Zugehörigkeit), die Signallogik, das Ausführungs- und Kostenmodell und die Regel für die Positionsgröße. Das Ergebnis ist eine simulierte Equity-Kurve mit Kennzahlen, kein Beleg für künftige Ergebnisse. Die einzelnen Verzerrungen und ihre Korrektur beschreibt der Artikel Bias-Korrektur in Backtests.

Technisch gibt es zwei Bauarten. Ein vektorisierter Backtest rechnet ganze Zeitreihen auf einmal durch, etwa mit pandas; er ist schnell und eignet sich für erste Tests einfacher Regeln. Ein ereignisgesteuerter Backtest arbeitet Kerze für Kerze oder Tick für Tick und bildet Orders, Teilausführungen, Stops und Kontostand so ab, wie ein Trading-Bot sie live erlebt. Für die Frage, ob ein System live gehen kann, ist die zweite Bauart näher an der Wirklichkeit, zumal sie denselben Code wie der Live-Betrieb nutzen kann. Zu jeder Auswertung gehören neben dem Ergebnis nach Kosten mindestens der Max-Drawdown, die Zahl der Trades und das mittlere Ergebnis pro Trade.

Wie aussagekräftig ist das Ergebnis?

Wie viele Trades ein Backtest braucht, hängt vom Verhältnis zwischen mittlerem Ergebnis pro Trade und dessen Streuung ab. Eine erste Prüfung ist der t-Wert des Mittelwerts: t = Mittelwert / (Standardabweichung / √n), wobei n die Zahl der Trades ist.

Rechenbeispiel: Eine Strategie erzielt im Mittel 0,2 R pro Trade bei einer Standardabweichung von 1,5 R (R = Anfangsrisiko, siehe R-Multiple). Bei 50 Trades beträgt der Standardfehler 1,5 / √50 ≈ 0,21 R, also t ≈ 0,94: Das Ergebnis lässt sich nicht von Zufall unterscheiden. Bei 400 Trades ist der Standardfehler 1,5 / 20 = 0,075 R und t ≈ 2,67. Damit liegt der Wert über der üblichen Schwelle von etwa 1,96 (5-%-Niveau, zweiseitig), die in diesem Beispiel ab (1,96 × 1,5 / 0,2)² ≈ 216,1, also ab 217 Trades erreicht wird. Ein Vorteil ist dann statistisch plausibel, aber nur, wenn nicht viele Varianten auf denselben Daten getestet wurden. Dass die Trades unabhängig und ähnlich verteilt sind, ist dabei eine vereinfachende Annahme. Mehr dazu im Artikel Wie viele Trades braucht ein Backtest?

Umsetzung im Code und typischer Fehler

Der typische Programmierfehler ist ein Look-Ahead beim Ausführungszeitpunkt. In einem vektorisierten Python-Backtest sieht er so aus: signal * rendite. Die Rendite einer Kerze wird dabei mit einem Signal verrechnet, das erst an ihrem Schluss feststand. Richtig ist position = signal.shift(1) und ergebnis = position * rendite - kosten * position.diff().abs(). Die Position wirkt damit erst in der Folgeperiode, und jeder Positionswechsel kostet. Wer nicht zum Schlusskurs der Signalkerze handeln kann, rechnet ab dem Eröffnungskurs der nächsten Kerze. In einem ereignisgesteuerten Backtest wie dem MT5-Strategietester gilt dieselbe Regel: Entscheidungen beruhen nur auf abgeschlossenen Kerzen. Der Modus „Open prices only“ ist nur gültig, wenn die Strategie tatsächlich nur zur Kerzeneröffnung handelt; Stops und Limits innerhalb einer Kerze brauchen Tick- oder Minutendaten.

Grenzen und Missverständnisse

Ein Backtest zeigt, dass eine Regel in der Vergangenheit unter den gewählten Annahmen funktioniert hätte, nicht, dass sie künftig funktioniert. Je mehr Varianten auf denselben Daten ausprobiert wurden, desto stärker überzeichnet das beste Ergebnis die Wirklichkeit (siehe Overfitting). Er ersetzt auch keinen Test der Live-Infrastruktur: Verbindungsabbrüche, abgelehnte Orders, Teilausführungen und Zeitzonen-Fehler kommen in historischen Daten nicht vor. Damit ein Ergebnis später nachprüfbar bleibt, gehören fester Datenstand, Programmversion und alle Parameter ins Protokoll. Üblich ist deshalb eine Prüfkette aus Backtest, Walk-Forward-Analyse, erhöhten Kostenannahmen (siehe Slippage) und einem Demo- oder Kleinbetrieb. Wie stark sich Verläufe allein durch Zufall unterscheiden können, zeigt der Monte-Carlo-Simulator.