Für wen dieser Artikel gedacht ist — Für alle, die historische Daten in Signale verwandeln, Parameter optimieren, Machine Learning einsetzen oder Orders simulieren. Ein Modell kann fehlerfrei programmiert sein und dennoch die Zukunft „kennen“, weil eine Verknüpfung, ein Feature, ein Split oder ein Ausführungspreis die Kausalität verletzt.
Data Leakage ist die Verunreinigung eines Forschungsprozesses mit Informationen, die an der betreffenden Stelle noch nicht verfügbar sein durften. Look-ahead Bias ist der zeitliche Spezialfall: Die Entscheidung zum Zeitpunkt t enthält direkt oder indirekt Daten, die erst nach t bekannt wurden. Das Ergebnis ist nicht nur zu optimistisch. Simuliert wird eine andere Strategie mit einem Informationskanal, den es real nicht gab.
Einfach gesagt — Nach Datum sortierte Zeilen reichen nicht. Jeder Schritt muss dieser Reihenfolge folgen: verfügbare Information → Signal → Order → möglicher Fill → Position → Ergebnis.
Die wichtigsten Abgrenzungen
| Problem | Was geschieht | Beispiel |
|---|---|---|
| Look-ahead | Ein zukünftiger Wert fließt in die Entscheidung ein | Mit dem endgültigen Auktionspreis entscheiden und die Order auf dieselbe Auktion zurückdatieren |
| Target Leakage | Die Zielvariable sickert in die Features | Eine Aggregation umfasst bereits den künftigen Zielzeitraum |
| Leakage im Preprocessing | Schätzung oder Auswahl nutzt Training und Test gemeinsam | Standardisierung mit Mittelwert und Streuung des gesamten Datensatzes |
| Leakage zwischen Stichproben | Das Training enthält Ergebnisse, die an seinem Stichtag noch nicht beobachtbar waren | Ein Label über fünf Handelstage endet im Testzeitraum |
| Revidierte Information | Der endgültige statt des damals bekannten Werts wird verwendet | Eine Monate später korrigierte Makrozahl |
| Nicht kausale Simulation | Eine Order erhält einen unmöglichen Preis | Signal auf dem Close und garantierter Fill am selben Close |
Der Survivorship Bias ist davon zu unterscheiden: Er entsteht, wenn nur später überlebende oder rückblickend ausgewählte Einheiten beobachtet werden. Korrekte Zeitstempel stellen allein keine gescheiterten Unternehmen, geschlossenen Fonds oder früheren Indexmitglieder wieder her.
Drei Uhren: Signal, Order und Fill
Eine Handelsregel muss mindestens drei Zeitpunkte festlegen:
- Signalzeit: Zeitpunkt, zu dem das Signal bereitsteht; davon zu unterscheiden ist der Informationsstichtag für seine Berechnung.
- Orderzeit: Erstellung und Übermittlung, gefolgt von Ankunft und Annahme am Handelsplatz.
- Fillzeit: Zeitpunkt oder Intervall, in dem die zugelassene Order auf passende Preise und Mengen treffen kann.
Benötigt die Entscheidung den endgültigen Preis close[t], kann sie nicht die Teilnahme an derselben Auktion bestimmen, die diesen Preis bildet. Eine zuvor übermittelte Schlussorder muss die Fristen des Handelsplatzes einhalten und die damals verfügbaren Informationen nutzen: Das zitierte NYSE-Merkblatt trennt Ordereingabe und Auktionsprozess. Ein späterer Fill könnte denselben Zahlenwert als Preis haben, aber nicht denselben Zeitpunkt. Das endgültige Hoch und Tief einer Kerze sind vor ihrem Abschluss keine verfügbaren Eingaben; ein Intrabar-Replay darf bei jeder Entscheidung nur bereits beobachtete Ereignisse zeigen.
Bei Meldungen, Filings und Makrodaten ist das Datum des wirtschaftlichen Berichtszeitraums nicht der Veröffentlichungszeitpunkt. Die Strategie muss die Daten außerdem empfangen haben und verarbeiten können. Point-in-time-Daten bewahren Versionen (Vintages): Eine spätere Revision ersetzt nicht die bei der Entscheidung verfügbare Fassung. ALFRED rekonstruiert den Kenntnisstand an einem historischen Datum; daraus folgt allein kein Nachweis der Intraday-Uhrzeit oder der Latenz des eigenen Datenanbieters.
Wo Leakage verborgen sein kann
Features und Transformationen
- zentrierte gleitende Durchschnitte, bidirektionale Filter oder Interpolation mit künftigen Beobachtungen;
- Cross-Section-Rankings auf einem mit heutigem Wissen rekonstruierten Universum;
- Winsorisierung, Imputation oder Standardisierung auf dem gesamten Datensatz;
- Fundamentaldaten am Quartalsende statt am tatsächlichen Filing-Zeitpunkt;
- Splits und Dividenden ohne Trennung von Wirksamkeit und Bekanntwerden.
Standardisierung einer Variablen: z = (x − Mittelwert_train) / Standardabweichung_train. Mittelwert und Streuung werden im Training jedes Folds geschätzt und für dessen Test wiederverwendet; eine Streuung von null muss behandelt werden. scikit-learn unterscheidet fit und transform.
Forschung und Auswahl
Data Snooping verwendet die Stichprobe wiederholt für Inferenz oder Auswahl: Auch bei zeitlich korrekten Eingaben kann ein Zufallssieger entstehen. Es ist daher vom Look-ahead Bias zu unterscheiden.
Auch ohne zukünftige Spalte kann ein Testset verunreinigt werden. Wird sein Ergebnis wiederholt zur Auswahl von Features, Schwellen oder Modellen betrachtet, wird es schrittweise zum Entwicklungsdatensatz. Out-of-Sample ist keine Dateibeschriftung, sondern eine Rolle im Entscheidungsprozess. Getestete Alternativen, verworfene Entscheidungen und Auswahlkriterien gehören ins Forschungsprotokoll.
Orders und Ausführung
Ein OHLC-Preis beweist keinen Fill. Stop- und Limitkurse können berührt werden, ohne dass eine Ausführung stattfindet; die verfügbare Menge kann fehlen; die Warteschlangenposition ist unbekannt; Verzögerungen und Teilfills verändern die Position. Immer den günstigsten Preis der Kerze zuzuweisen ist rückblickendes Wissen und berührt zugleich die Transaktionskosten im Backtest.
Kausales Prüfprotokoll
- Entscheidung vor dem Code beschreiben. Inputs, Zeitstempel, Zeitzone, Cut-off, Frequenz und Aktion festhalten.
- Rohdaten versionieren. Snapshots, Vintages, Universum und Corporate Actions aufbewahren, ohne Geschichte zu überschreiben.
- Jedes Feature „as of“ berechnen. Bei der Entscheidung
tDatensätze mitavailable_at > tausschließen und jeweils die damals verfügbare Version wählen; die Herleitung vonavailable_atdokumentieren. - Nur im Training fitten. Imputation, Skalierung und Variablenauswahl im Training jedes Folds schätzen; die erlernten Transformationen auf dessen Test anwenden. Parameter anhand der Validierung wählen und den finalen Test unangetastet lassen.
- Zeitliche Ordnung wahren. Jedes Trainingslabel muss am Trainingsstichtag bereits beobachtbar sein. Überschneiden sich Informationsintervalle mit dem Test, Purging und zeitliche Lücken anhand tatsächlicher Daten statt bloßer Zeilennähe prüfen.
- Spezifikation einfrieren. Regeln, Parameter, Universum, Benchmark und Kennzahlen vor der finalen Bewertung versionieren.
- Signal, Order und Fill trennen. Verzögerung, Kalender, Ordertyp und wirklich beobachtbare Daten berücksichtigen.
- Alle Versuche erhalten. Ein Variantenregister macht Data Snooping sichtbar.
- Aus sauberem Snapshot wiederholen. Das Ergebnis muss ohne mit Zukunftswissen erzeugte Zwischendateien reproduzierbar sein.
Illustratives Beispiel — Eine Regel kauft zur Eröffnung, wenn der Quartalsgewinn die Erwartungen übertrifft. Die Datenbank ordnet den Wert dem Quartalsende zu, obwohl die Meldung erst sechs Wochen später erscheint. Der ursprüngliche Test handelt damit vor der Veröffentlichung. Die Korrektur bewahrt Verfügbarkeit und Vintages sowohl der Meldung als auch des Erwartungskonsenses, berechnet das Signal und wartet auf eine mit der Ankunft der Order vereinbare Ausführungsphase. Zahlen und Ablauf erläutern die Kausalprüfung; sie sind keine Strategieempfehlung.
Diagnosetests
| Test | Möglicher Befund |
|---|---|
| Jedes Feature um eine Kerze verzögern | verborgene Abhängigkeit von der aktuellen Kerze |
| Datensatz zu einem historischen Stichtag rekonstruieren | Revisionen oder rückblickende Mitgliedschaften |
| Latenz und zeitliche Lücke künstlich erhöhen | Empfindlichkeit gegenüber der kausalen Reihenfolge |
| Preprocessing je Fold getrennt fitten | Verunreinigung zwischen Training und Test |
| Den „perfekten“ Kerzenpreis entfernen | unmögliche Fills oder günstige Auswahl |
| Placebo mit zeitlich verschobenem Ziel ausführen | verdächtige Korrelationen in der Pipeline |
Ein Einbruch nach diesen Tests ist ein Warnsignal, aber kein automatischer Ursachenbeweis. Umgekehrt beweist Stabilität nicht die Abwesenheit von Leakage: Manche Lecks überstehen solche Störungen.
Zukünftige Labels und Trainingsgrenzen
Das Label ist das vorherzusagende Ergebnis. Beispielsweise ist die Rendite der fünf Handelstage nach Zeile t erst nach diesen Tagen bekannt. Sie als Ziel eines späteren Trainings zu nutzen, ist normal; sie unter die Eingaben bei t oder in ein vor ihrer Realisierung abgeschlossenes Training aufzunehmen, führt Zukunftsinformation ein. Labels jenseits des Stichtags auszuschließen ist etwas anderes, als jede Korrelation zwischen Beobachtungen zu verbieten. Der scikit-learn-Parameter gap zählt ausgeschlossene Zeilen: Er rekonstruiert Dauer und Verfügbarkeit der einzelnen Labels nicht automatisch.
Grenzen
Zeitliche Splits, Walk-forward oder Cross-Validation reparieren keine bereits verunreinigten Daten. Purging und Embargo müssen aus der Labelstruktur folgen und dürfen kein Ritual sein. Ein kausaler Datensatz kann weiterhin Messfehler, Mehrfachselektion, Regimewechsel, geringe Teststärke oder ein unvollständiges Universum enthalten. Validierung benötigt daher statistische Kontrollen und ein Audit des gesamten Informationswegs.
Quellen
- Halbert White, A Reality Check for Data Snooping, Econometrica, 2000 — Inferenz, wenn ein ausgewähltes Ergebnis aus vielen Spezifikationen hervorgeht.
- Robert D. Arnott, Campbell R. Harvey und Harry Markowitz, A Backtesting Protocol in the Era of Machine Learning — Trennung von Forschung, Auswahl und Holdout bei knappen Finanzdaten.
- David H. Bailey, Jonathan M. Borwein, Marcos López de Prado und Qiji Jim Zhu, The Probability of Backtest Overfitting — Overfitting-Risiko durch die Auswahl unter vielen Konfigurationen.
- Federal Reserve Bank of St. Louis, FRED® versus ALFRED® — Unterschied zwischen heute sichtbarer Geschichte und dem damals bekannten Vintage.
- scikit-learn, Common pitfalls — Data leakage und StandardScaler — Training, Vorverarbeitung und Anwendung auf den Test.
- NYSE, Opening and closing auctions, p. 2 — Abfolge von Ordereingabe und Schlussauktion am beschriebenen Markt.
- scikit-learn, TimeSeriesSplit — zeitlich geordnete Cross-Validation und Gap-Parameter; offizielle technische Dokumentation.