Letzte Woche hat uns ein Leser eine RSI-Strategie geschickt, die er selbst in Python programmiert hatte. Der Backtest über fünf Jahre Bitcoin sah aus wie der heilige Gral: 287 % Gewinn, eine Sharpe-Ratio von 4,2, im schlimmsten Moment nur 12 % Rückgang.

Wir haben den Code durchgesehen. Eine Zeile sah so aus:

df['rsi_oversold'] = df['rsi'] < 30
df['exit_signal'] = df['rsi_oversold'].shift(-3)

Fällt es dir auf? Die Strategie verkauft, weil das Signal drei Kerzen später auftaucht. Sie weiß im Moment der Entscheidung also schon, was in der Zukunft passiert. Im echten Handel ist das unmöglich. Im Backtest funktioniert es trotzdem, weil der gesamte Kursverlauf bereits gespeichert vorliegt.

Wir haben den Fehler entfernt — also shift(-3) zu shift(3) korrigiert, damit die Strategie nur auf vergangene Signale schaut. Dann lief der Backtest erneut: −18 % Gewinn, Sharpe −0,3, im schlimmsten Moment 41 % Rückgang. Aus dem heiligen Gral wurde eine schlechte Strategie.

Das ist der Blick in die Zukunft (englisch: Look-Ahead-Bias). Er ist der häufigste, unauffälligste und gefährlichste Fehler in selbst gebauten Backtests. Der Leser war kein Anfänger. Er hatte zehn Jahre Programmiererfahrung und kannte Pandas gut. Der Fehler ist trotzdem passiert — und genau das ist der Punkt. Dieser Fehler entsteht so leicht, dass ihn die meisten Programmierer irgendwo einbauen, ohne es zu merken.

Dieser Beitrag erklärt vier Dinge: was der Blick in die Zukunft ist, warum er so leicht entsteht, wie man ihn erkennt, und was wir bei Backtesting Arena konkret dagegen tun.

Was der Blick in die Zukunft bedeutet

In einem fairen Backtest darf eine Entscheidung zum Zeitpunkt t nur Daten verwenden, die vor t bekannt waren. Im echten Handel geht es gar nicht anders. Du kannst den Schlusskurs von morgen nicht für eine Entscheidung von heute nutzen, weil morgen noch nicht stattgefunden hat.

Im Backtest liegt aber der gesamte Kursverlauf schon auf der Festplatte. Python lädt normalerweise alle Daten auf einmal in eine Tabelle. Wenn du nicht aufpasst, greifst du in Zeile 100 versehentlich auf Zeile 150 zu — und der Backtest tut so, als wäre das in Ordnung. Es ist nicht in Ordnung. Es ist geschummelt, auch wenn du nicht schummeln wolltest.

Anders gesagt: Ein Backtest mit diesem Fehler erzeugt Geschäfte, die ein echter Händler nie hätte machen können. Die Information, auf der sie beruhen, gab es in diesem Moment noch nicht. Der Backtest lässt sich im echten Leben nicht wiederholen. Er bildet nicht den Markt ab, sondern nur eine Eigenheit der Datentabelle.

Die schmerzhafte Folge: Ein solcher Backtest sieht großartig aus, weil die Strategie auf Wissen zugreift, das ein echter Händler nicht hat. Im echten Handel kommt dann das Gegenteil heraus. Sobald die Strategie ihre Daten aus der Zukunft nicht mehr bekommt, verschwindet der Gewinn.

Warum er so leicht entsteht

Der Blick in die Zukunft ist kein Anfängerfehler, den man durch sorgfältiges Programmieren einfach vermeidet. Er ist ein grundlegendes Risiko beim Bauen von Backtests und passiert auch erfahrenen Entwicklern. Hier die häufigsten Quellen.

Erstens: shift() in die falsche Richtung. In Pandas holt df['x'].shift(-N) Werte aus der Zukunft in die Gegenwart. shift(+N) macht das Gegenteil und holt Werte aus der Vergangenheit. Das Vorzeichen ist eine klassische Verwechslungsquelle. Wer einmal shift(-1) statt shift(1) verwendet hat, hat seinen Backtest unbemerkt verfälscht.

Zweitens: ein Durchschnitt über den ganzen Datensatz. Das ist der unauffälligste Fall. df['close'].mean() liefert den Mittelwert über die gesamte Tabelle. Wer diesen Wert als Schwelle für eine Entscheidung nimmt, gibt jeder Zeile Wissen über alle anderen Zeilen — auch über zukünftige. Richtig ist df['close'].rolling(N).mean(). Diese Variante schaut nur auf die letzten N Werte zurück. Aber mean() tippt sich schneller, und der Unterschied fällt erst auf, wenn man genau hinschaut.

Drittens: ein fester Zeilen-Index mit iloc[]. Wer df.iloc[150] verwendet, hat keine Garantie, dass Zeile 150 zum Zeitpunkt von Zeile 50 schon vorhanden gewesen wäre. Das ist eine direkte Quelle für den Blick in die Zukunft.

Viertens: eine zu kurze Signal-Periode beim Indikator. Ein bekanntes Beispiel ist der MACD mit signalperiod=1. Die Signallinie wird normalerweise über mehrere Kerzen geglättet. Bei signalperiod=1 ist sie praktisch der aktuelle Wert selbst — und das kann je nach Umsetzung den Blick in die Zukunft enthalten.

Fünftens: Schleifen mit Index-Zugriff. Wer in einer Schleife for i in range(len(df)): df['signal'][i] = ... schreibt und nicht genau aufpasst, welche i+N-Werte er darin anspricht, baut sich den Fehler ein. Schleifen über eine ganze Tabelle sind in Pandas ohnehin keine gute Praxis, kommen aber oft vor — besonders bei Strategien, die aus mehreren Quellen zusammenkopiert wurden.

Erkennst du das Muster? In all diesen Fällen entsteht der Fehler nicht durch absichtliches Schummeln. Er entsteht durch die Eigenheiten der Datenstruktur, in der Backtests normalerweise gebaut werden. Wer einen Backtest schreibt, denkt in Zeilen und Indizes. Wer in der Realität handelt, denkt in Zeit. Diese beiden Sichtweisen zusammenzubringen, ohne Wissen aus der Zukunft durchsickern zu lassen, ist nicht einfach.

Warum er so schwer zu entdecken ist

Der Blick in die Zukunft hat eine besonders tückische Eigenschaft: Er erzeugt Backtests, die völlig plausibel aussehen. Wenn deine Strategie 300 % macht, denkst du nicht „das muss ein Fehler sein". Du denkst „das ist eine gute Strategie".

Das ist anders als bei anderen Backtest-Problemen. Die Überlebenden-Verzerrung (Survivorship-Bias) zum Beispiel fällt oft auf: Wer nur die zehn größten Coins von heute testet, ahnt, dass das künstlich gut aussieht. Der Blick in die Zukunft dagegen kann jede Strategie besser aussehen lassen — auch eine, die im Kern gar nicht funktioniert. Er ist eine versteckte Verstärkung, die unsichtbar bleibt, bis man gezielt nach ihr sucht.

Die zweite Schwierigkeit: Bei komplexen Strategien mit vielen Indikatoren und Bedingungen kannst du kaum allein durch das Lesen des Codes erkennen, ob irgendwo ein Fehler steckt. Du musst die Strategie unter kontrollierten Bedingungen testen.

Die ehrlichste Prüfmethode kommt aus der Freqtrade-Gemeinschaft. Die Idee: Du lässt die Strategie zweimal laufen — einmal mit dem vollständigen Datensatz und einmal mit Daten, die an verschiedenen Stellen künstlich abgeschnitten wurden. Wenn sich die Indikatorwerte oder Handelsentscheidungen in der Vergangenheit ändern, je nachdem ob Daten aus der Zukunft im Datensatz liegen oder nicht, dann steckt ein Fehler drin. Das ist ein direkter Test, der nicht vom Verständnis des Codes abhängt.

Wie man den Fehler systematisch findet

Wer selbst Strategien programmiert und sichergehen will, dass der Backtest sauber ist, hat vier Prüfebenen.

Erstens: Code nach bekannten Fehlermustern durchsuchen. Such nach shift(-, nach .mean() ohne rolling, nach iloc[] mit festen Zahlen und nach Schleifen über die Tabelle. Diese Stellen sind nicht automatisch ein Fehler. Aber sie sind die häufigsten Orte, an denen einer entsteht. Jede verdient zwei Minuten genaues Hinsehen.

Zweitens: schrittweise prüfen. Bau den Backtest so, dass er nicht den ganzen Datensatz auf einmal sieht, sondern Schritt für Schritt durch die Zeit geht. Bei Kerze i stehen der Strategie nur Daten bis Kerze i-1 zur Verfügung. Das ist langsamer als ein Backtest, der alles auf einmal berechnet, aber es schützt zuverlässig vor den häufigsten Fehlerquellen, weil zukünftige Daten technisch gar nicht erreichbar sind.

Drittens: der Abschneide-Test. Lass den Backtest über den vollständigen Datensatz laufen und merke dir die ersten 50 Geschäfte. Dann lass denselben Backtest nur über die erste Hälfte der Daten laufen und vergleiche die Geschäfte im überschneidenden Zeitraum. Sind sie unterschiedlich, hatte irgendetwas Zugriff auf zukünftige Daten. Die Methode ist kein vollständiger Beweis, aber sie fängt die meisten Fälle.

Viertens: der Echtgeld-Test. Lass die Strategie ein bis drei Monate mit kleinem Einsatz auf echtem Geld laufen. Liegt das Ergebnis deutlich unter dem Backtest — und gibt es keinen offensichtlichen Grund wie Gebühren oder eine Kursabweichung beim Kauf —, ist der Blick in die Zukunft ein Hauptverdächtiger. Das ist die teuerste Methode, aber der endgültige Test.

Diese vier Ebenen sind kein Werkzeug, das man einmal anklickt. Sie sind eine Disziplin. Wer seine eigenen Strategien ernsthaft programmiert, sollte sie zur festen Routine machen.

Was wir bei Backtesting Arena konkret tun

Bei Backtesting Arena gibt es fertige Strategien. Nutzer können sie auswählen, einstellen und anwenden, aber sie schreiben den Code nicht selbst. Das nimmt eine ganze Reihe von Risiken weg. Es schafft aber eine andere Pflicht: Wir müssen sicherstellen, dass unsere Strategien sauber sind, weil unsere Nutzer das nicht selbst prüfen können.

Was wir konkret tun:

Jede Strategie wird vor der Veröffentlichung von Hand auf den Blick in die Zukunft geprüft. Das ist kein automatischer Ablauf, sondern eine Prüfung durch einen Menschen. Wir gehen jede neue Strategie durch, suchen nach den oben genannten Fehlermustern und führen Abschneide-Tests durch, bevor sie auf der Plattform verfügbar ist.

Dafür gibt es zwei Gründe. Erstens ist das bei unserer überschaubaren Zahl an Strategien (aktuell 18) machbar und gründlicher, als es ein automatischer Test wäre. Zweitens müssten wir bei einem automatischen Ablauf zusätzlich beweisen, dass dieser Ablauf selbst fehlerfrei ist. Solange wir nicht so viele Strategien haben, dass die Prüfung von Hand zu aufwendig wird, ist der Mensch die gründlichere Lösung.

Mittelfristig planen wir einen automatischen Abschneide-Test als zusätzliche Sicherheitsebene. Er soll die Prüfung von Hand nicht ersetzen, sondern ergänzen — vor allem dann, wenn wir später einmal eigene Nutzer-Strategien mit eigenem Code zulassen sollten. Im Moment reicht die Prüfung von Hand.

Was das für dich als Nutzer bedeutet: Wenn du eine fertige Strategie auf Backtesting Arena testest, kannst du davon ausgehen, dass die Strategie selbst keinen Blick in die Zukunft enthält. Was du mit den Ergebnissen machst — wie du sie deutest, ob du sie im echten Handel umsetzt, welche Werte du einstellst —, bleibt deine Sache. Aber die Ergebnisse selbst sind ehrlich gegen die historischen Daten gerechnet.

Was eine saubere Strategie noch nicht garantiert

Eine wichtige Einschränkung zum Schluss: Frei vom Blick in die Zukunft zu sein ist eine notwendige, aber noch keine ausreichende Bedingung für eine gute Strategie. Eine saubere Strategie kann trotzdem überangepasst sein. Sie kann ihren Gewinn aus drei Glücksgeschäften ziehen. Sie kann in einer einzigen Marktphase entstanden sein und in anderen versagen.

Die üblichen Mittel gegen diese anderen Probleme bleiben wichtig: der Test auf unbekannten Daten, der Test über mehrere Marktphasen, die Prüfung, wie empfindlich die Strategie auf kleine Änderungen reagiert, und eine Mindestzahl an Geschäften. Wir haben sie in unseren 11 Grundregeln fürs Backtesting zusammengefasst, und sie gelten alle weiter — auch für saubere Strategien.

Frei vom Blick in die Zukunft zu sein ist die Grundlage. Es ist die Schwelle, ab der man überhaupt sinnvoll über die Qualität einer Strategie reden kann. Eine Strategie mit diesem Fehler verdient keine weitere Analyse, sie ist von Grund auf falsch. Erst eine saubere Strategie verdient den Aufwand der weiteren Tests.

Das ist die unromantische Wahrheit über systematisches Handeln: Bevor du die interessanten Fragen stellst (wann funktioniert die Strategie, wann nicht?), musst du die langweilige Frage geklärt haben (ist sie überhaupt fair gemessen?). Die Prüfung auf den Blick in die Zukunft ist die langweilige Frage. Sie ist nicht freiwillig.

---

FAQ

Ist der Blick in die Zukunft bei jedem Backtest-Werkzeug ein Problem? Bei selbst programmierten Backtests in Python und Pandas: ja, mit hoher Wahrscheinlichkeit. Bei kommerziellen Werkzeugen mit eigener Engine: Das hängt von der Engine ab. Die meisten ernsthaften Werkzeuge haben Schutzmechanismen, aber niemand sollte das ohne Beleg annehmen. Bei TradingView Pine Script: deutlich weniger anfällig, weil die Sprache von Natur aus Kerze für Kerze rechnet. Bei Backtests in Excel: sehr anfällig, weil Spaltenformeln meist über den ganzen Datensatz rechnen.

Wie kann ich bei einer fertigen Plattform prüfen, ob sie sauber ist? Ohne Zugang zum Code ist das schwer. Aber zwei Anzeichen helfen. Erstens: ob der Anbieter offen über seine Methodik spricht — eine Liste der Annahmen, eine Beschreibung der Engine oder zumindest ein FAQ zu diesem Thema. Zweitens: ob die Backtests in einem realistischen Bereich landen. Wenn jede vorgestellte Strategie über 100 % Rendite zeigt, ist die Wahrscheinlichkeit eines Fehlers hoch.

Ich habe einen Backtest mit 200 % Gesamtrendite. Muss ich von einem Fehler ausgehen? Wahrscheinlich, aber nicht sicher. 200 % über zehn Jahre sind etwa 11,6 % pro Jahr — durchaus realistisch. 200 % in einem einzigen Jahr sind dagegen mit hoher Wahrscheinlichkeit entweder ein Fehler, Glück oder eine sehr schwankungsreiche Strategie mit hohem Risiko in Extremfällen. Bevor du der Zahl traust, prüfe sie mit den oben genannten Methoden.

Hat eure eigene Engine einen Blick in die Zukunft? Wir haben die Engine so gebaut, dass das vom Aufbau her nicht passieren kann. Wir gehen hier nicht ins technische Detail, aber die Engine hält durchgehend die Reihenfolge „erst entscheiden, dann ausführen" ein. Zusätzlich wird jede einzelne Strategie vor der Veröffentlichung von Hand geprüft.