Warum funktioniert mein Live-Handel schlechter als meine Backtest-Strategie?
Kurzantwort: Meist liegt es an zu optimistischen oder unvollständigen Annahmen im Test (Gebühren, Slippage, Ausführung, Margin), an einer Überanpassung an die Vergangenheit ohne strikt reservierten Zeitraum zum Prüfen – und daran, dass sich Marktphasen ändern. Unten folgt die Einordnung Schritt für Schritt – und wie SPAIKE diese Fehlerquellen gezielt reduziert.
Viele kennen die Diskrepanz: Im Backtest wirkt eine Strategie klar und stark, im Live-Handel sind Ergebnis und Gefühl davon entfernt. Der Markt kann sich ändern, aber oft ist der Hauptgrund ein anderer: Die Strategie wurde auf historischen Daten so angepasst, dass sie diese Periode gut abbildet – ohne dass klar getrennt wurde, was zum Entwickeln und was zum späteren Prüfen dient.
Der folgende Text fasst zusammen, warum solche Abweichungen typisch sind und wie du mit einem reservierten Zeitfenster und Out-of-Sample-Logik strenger arbeitest.
Warum Backtest und Live auseinanderlaufen
Ein Backtest spiegelt deine Annahmen wider: Datenqualität, Kosten, Slippage, Margin, Reihenfolge der Bedingungen, Ausführung. Sind diese Annahmen zu optimistisch oder unvollständig, liegt die simulierte Performance über dem, was real erreichbar ist.
Zusätzlich entsteht Überanpassung (Overfitting), wenn du viele Parameter, Filter oder Zeiträume so lange veränderst, bis die Historie gut aussieht. Das Modell kann dann Muster aus Zufallsbewegungen lernen, die sich nicht wiederholen.
Schließlich wechseln Märkte ihre Eigenschaften (Volatilität, Liquidität, Trends). Eine Logik, die in einer Phase stark war, kann in einer anderen schwächer sein, ohne dass der Code einen Fehler hat.
Die fehlende Prüfung: Daten, die beim Bauen tabu sind
Zentrale Methode: Du trennst die Zeitachse. Ein Teil der Historie wird für die Entwicklung und Optimierung der Strategie verwendet. Ein anderer Teil bleibt zunächst unberührt und dient nur der späteren Bewertung. So simulierst du, dass du die Zukunft beim Entwerfen noch nicht kennst.
Ein konkretes Vorgehen (Beispiel): Du schließt die letzten fünf Monate aus dem Zeitraum aus, auf dem du optimierst. Auf dem davor liegenden Fenster entwickelst du Regeln und Parameter. Danach prüfst du die Strategie auf den folgenden fünf Monaten: Trägt dieselbe festgelegte Logik dort noch, ohne dass du diese Monate in die Optimierung einbezogen hast? Wenn nicht, war die Anpassung vermutlich zu stark an die erste Periode gebunden.
Die genaue Monatszahl ist veränderbar; entscheidend ist die Regel: Was als reserviert gilt, darf nicht heimlich wieder in die Suche nach Parametern einfließen. Das entspricht der Idee von Out-of-Sample-Testing bzw. einer einfachen Walk-forward-Struktur.
Was dir diese Trennung bringt
Strengere Tests liefern selten die höchsten Kurven in der Simulation. Sie reduzieren aber das Risiko, eine Strategie zu überbewerten, die nur auf einen Ausschnitt der Vergangenheit passt. Du erhältst eine klarere Antwort auf die Frage, ob die Regeln außerhalb des Optimierungsfensters noch tragfähig sind.
Wie SPAIKE genau diese Probleme löst
Die beiden Hauptfehlerquellen – zu optimistische Annahmen und Überanpassung – lassen sich nicht wegreden, aber methodisch eindämmen. Genau dafür ist SPAIKE gebaut: realistischere Ausführung auf Tick-Ebene und eine eingebaute Trennung von Entwicklungs- und Prüfdaten.
Tick-Backtests statt grober Kerzen
SPAIKE rechnet Ein- und Ausstiege nicht auf groben OHLC-Kerzen oder geglätteten Endkursen, sondern auf echten NBBO-Quote-Ticks (National Best Bid/Offer) aus historischen Optionsdaten. Der Trigger-Zeitpunkt wird am tatsächlichen Tick fixiert, und es wird mit dem real verfügbaren Bid/Ask-Spread gerechnet statt mit einem bequemen Mid-Fill, den es so im Markt nie gab. Das nimmt einen großen Teil der „zu optimistischen Annahmen“ heraus, bevor sie überhaupt entstehen: Was im Test als ausführbar gilt, war auch im Tick-Strom ausführbar.
Realistische Slippage-Simulation (Latenz-Touch-Modell)
Statt eines pauschalen Fix-Slippage pro Trade modelliert SPAIKE die Ausführung über ein Latenzfenster. Der Exit-Zeitpunkt und der theoretische Mid-Exit bleiben am Trigger-Tick fixiert; für die Slippage wird zusätzlich das NBBO-Tickfenster vom Trigger bis Trigger + Latenz geladen (Standard fünf Sekunden, pro Leg oder Leg-Gruppe konfigurierbar). Der Fill wird am ausführbaren Ende des Spreads des letzten Ticks im Fenster angenommen: ein Sell-Leg schließt per Rückkauf am Ask, ein Buy-Leg per Verkauf am Bid. Die Slippage ist die adverse Differenz zwischen theoretischem Mid-Exit und realem Fill – und nie negativ, d. h. sie schönt das Ergebnis nicht. So bildet der Test die Verzögerung zwischen Signal und tatsächlicher Ausführung konservativ ab, anstatt sie zu ignorieren.
Out-of-Sample als Teil des Workflows
Gegen Überanpassung hilft kein realistischeres Fill-Modell allein, sondern die saubere Trennung der Zeitachse. SPAIKE unterstützt genau diese Logik: Du optimierst auf einem Fenster und prüfst dieselbe festgelegte Logik auf einem reservierten Zeitraum, der nicht in die Parametersuche zurückfließt. Realistische Ausführung und Out-of-Sample-Prüfung zusammen geben dir eine ehrlichere Erwartung für den Live-Handel.
Fazit
Wenn Live und Backtest stark divergieren, lohnt sich zuerst die Prüfung der Methodik: Annahmen, Überanpassung und fehlende unabhängige Testphase. Wer einen Teil der Daten konsequent für die nachträgliche Bewertung reserviert und zugleich auf Tick-Ebene mit realistischer Slippage rechnet – wie es SPAIKE tut – testet die Idee schärfer als mit einer einzigen optimierten Gesamtkurve auf groben Kursen.