Backfilling historischer Daten die Falle der nachtraeglich gefuellten Luecken.
Es ist eine der verführerischsten Fallen im quantitativen Trading: eine Datenlücke, die sich nachträglich elegant schließen lässt. Ein Datenanbieter liefert plötzlich auch die fehlenden historischen Werte mit, ein Fundamentaldatum wird rückwirkend ergänzt, ein Index-Mitglied bekommt seine Vorgeschichte. Das Ergebnis sieht wunderbar sauber aus — eine lückenlose Zeitreihe, bereit für das Modell. Genau hier beginnt das Problem. Nachträglich gefüllte Daten täuschen eine Kenntnis vor, die es zum jeweiligen Zeitpunkt live nie gab. Sie sind oft revidiert, manchmal mit Information aus der Zukunft angereichert, und sie reichern Look-Ahead-Bias auf eine Weise an, die im Backtest unsichtbar bleibt, aber im Livebetrieb verschwindet. Dieser Beitrag erklärt, warum Backfilling so trügerisch ist, welche Arten von Lücken es gibt, wie man Original- von Revisionsstand unterscheidet, und wie ein disziplinierter Backfill-Prozess aussieht, der die Historie vervollständigt, ohne sich selbst zu betrügen. Das Ziel ist nicht, niemals zu backfillen — sondern es so zu tun, dass der Backtest hält, was er verspricht.
Was Backfilling überhaupt bedeutet.
Backfilling beschreibt das nachträgliche Füllen von Lücken in einer historischen Zeitreihe. Das klingt harmlos und ist oft notwendig — Datenquellen wechseln, neue Felder kommen hinzu, ein Anbieter erweitert seine Historie rückwirkend. Die Frage ist nie, ob man backfillt, sondern wie ehrlich man dabei mit der Zeitachse umgeht.
Der Kern des Problems: Eine heute eingefügte historische Zahl trägt heutiges Wissen. Sie kann revidiert sein, sie kann mit Methoden berechnet worden sein, die es damals nicht gab, sie kann Information aus späteren Ereignissen enthalten. In der fertigen Tabelle steht sie aber gleichberechtigt neben den Werten, die damals tatsächlich bekannt waren.
Genau diese Gleichbehandlung ist der Selbstbetrug. Ein Modell, das auf solchen Daten trainiert und getestet wird, lernt aus Information, die zum Handelszeitpunkt nicht verfügbar war — und glänzt deshalb im Backtest, ohne dass dieser Glanz live reproduzierbar wäre.
Die zwei gefährlichsten Mechanismen.
Zwei Mechanismen machen Backfilling tückisch — sie wirken unabhängig und oft zusammen:
- Revisions-Bias: Viele Daten werden nach ihrer Erstveröffentlichung korrigiert. Wirtschaftsindikatoren, Unternehmenskennzahlen, sogar Kurse nach Corporate Actions. Der nachträglich gefüllte Wert ist meist der finale, revidierte Stand — nicht der, der live bekannt war. Ein Modell, das den revidierten Wert sieht, weiß mehr als der Markt damals wusste.
- Selektions-Bias durch nachträgliche Aufnahme: Wenn historische Daten rückwirkend nur für die Entitäten ergänzt werden, die heute noch existieren oder heute relevant sind, schleicht sich Survivorship-Bias ein. Die nachträglich gefüllte Historie repräsentiert dann nicht die damalige Realität, sondern eine im Rückblick gefilterte Auswahl.
Beide Mechanismen haben dieselbe Wirkung: Der Backtest profitiert von Wissen, das es live nicht gab. Und beide sind in der fertigen, lückenlosen Tabelle nicht mehr sichtbar — das macht sie so gefährlich.
Original- gegen Revisionsstand unterscheiden.
Der Schlüssel zu sauberem Backfilling ist, zwei Fragen für jeden Datenpunkt getrennt zu beantworten: Welcher Wert galt? Und welcher Wert war wann bekannt? Das ist im Kern bitemporale Datenhaltung — eine Achse für die wirtschaftliche Gültigkeit, eine für den Zeitpunkt der Kenntnis.
Konkret heißt das: Statt eine Zelle einfach mit dem heute besten Wert zu überschreiben, speichert man die Versionen. Welcher Wert wurde wann erstmals gemeldet, welche Revisionen folgten wann? Ein Backtest greift dann nicht auf den finalen Wert zu, sondern auf den, der am Simulationsdatum tatsächlich bekannt war — den sogenannten As-of-Stand.
Für viele Datentypen liefern seriöse Anbieter solche Vintage- oder Point-in-Time-Versionen mit. Wo sie fehlen, muss man ehrlich sein: Lässt sich nicht rekonstruieren, was wann bekannt war, ist der nachgefüllte Wert für realistische Backtests mit Vorsicht zu genießen — oder man behandelt ihn explizit als unsicher.
Lückentypen und der richtige Umgang.
Nicht jede Lücke ist gleich. Der korrekte Umgang hängt davon ab, warum die Lücke existiert:
| Lückentyp | Ursache | Sicherer Umgang |
|---|---|---|
| Echte Datenpause | Feiertag, Handelsstopp, kein Ereignis | als „kein Wert“ belassen, nicht erfinden |
| Verlorene Originaldaten | Quelle erst später verfügbar | nur füllen, wenn As-of belegbar |
| Rückwirkende Erweiterung | Anbieter liefert Historie nach | auf Revisions-/Survivorship-Bias prüfen |
| Fehlwerte (NaN) | Übertragungs-/Erfassungsfehler | vorsichtig interpolieren oder maskieren |
Die wichtigste Regel: Eine Lücke ist nicht automatisch ein Fehler. Manchmal ist „kein Wert“ die korrekte Information — etwa an einem Tag ohne Handel. Sie blind mit dem letzten Wert fortzuschreiben oder zu interpolieren, erzeugt Scheindaten, die das Modell für real hält. Interpolation über echte Informationslücken ist eine besonders subtile Form, Zukunftswissen einzuschmuggeln, weil sie meist beide Endpunkte der Lücke kennt.
Forward-Fill und Interpolation als Leakage-Quellen.
Zwei alltägliche Operationen sind häufige, oft übersehene Leakage-Quellen. Forward-Fill — das Fortschreiben des letzten bekannten Werts — ist meist legitim, weil es nur Vergangenheit nutzt. Aber nur, solange der „letzte bekannte Wert“ auch wirklich der live bekannte ist und nicht ein revidierter.
Heikler ist die Interpolation, die zwischen zwei Stützstellen rechnet. Sie nutzt definitionsgemäß den Wert am Ende der Lücke — also Zukunftsinformation aus Sicht der Punkte innerhalb der Lücke. In einem Feature, das zur Vorhersage dienen soll, ist das direkter Look-Ahead-Bias. Was als harmlose Datenbereinigung erscheint, kann das Backtest-Ergebnis still aufblähen.
Die Faustregel: Jede Fülloperation muss die Frage bestehen „Hätte ich diesen Wert zu diesem Zeitpunkt live gehabt?“. Forward-Fill besteht sie meist, Interpolation und rückwärtsgerichtetes Füllen fast nie. Im Zweifel ist eine sauber als fehlend markierte Lücke einem hübsch interpolierten, aber zukunftsverseuchten Wert vorzuziehen.
Ein disziplinierter Backfill-Prozess.
Sauberes Backfilling folgt einigen festen Prinzipien, die sich in der Praxis bewähren:
- Herkunft dokumentieren. Jeder nachgefüllte Wert wird als solcher markiert — mit Quelle und Einfügedatum. So bleibt jederzeit unterscheidbar, was Original- und was Backfill-Stand ist.
- As-of vor finalem Wert. Wo immer möglich, wird der Stand verwendet, der am jeweiligen Datum bekannt war, nicht der heutige Endstand.
- Backfill und Original getrennt testen. Läuft eine Strategie nur mit backgefüllten Daten gut, aber nicht auf den Originalständen, ist das ein Alarmsignal — kein Erfolg.
- Fehlend bleibt eine valide Option. Nicht jede Lücke muss geschlossen werden. Eine ehrliche fehlende Markierung ist besser als ein erfundener Wert.
Der Mehraufwand ist real — Versionierung und Herkunfts-Tracking kosten Engineering-Zeit und Speicher. Aber er ist die einzige Möglichkeit, die Frage zu beantworten, ob eine schöne Backtest-Kurve auf echtem Signal oder auf nachträglich eingeschmuggeltem Wissen beruht.
Grenzen und realistische Einordnung.
Auch der disziplinierteste Prozess hat Grenzen. Manche historischen Daten lassen sich schlicht nicht in ihren damaligen Kenntnisstand zurückversetzen — die Vintage-Information existiert nicht mehr oder wurde nie erfasst. In solchen Fällen bleibt nur, die Unsicherheit transparent zu machen und Backtest-Ergebnisse, die stark von diesen Daten abhängen, entsprechend vorsichtig zu interpretieren.
Ebenso gilt: Nicht jeder Backfill ist gefährlich. Das nachträgliche Laden roher Kurs-Ticks, die damals real existierten und sich nicht ändern, ist meist unproblematisch. Riskant wird es bei revidierbaren Größen — Fundamentaldaten, Schätzungen, Indexzusammensetzungen, abgeleiteten Kennzahlen. Hier lohnt die Sorgfalt am meisten.
Die ehrliche Quintessenz: Backfilling ist weder verboten noch per se falsch. Gefährlich ist nur das unreflektierte Backfilling, das die Zeitachse ignoriert. Wer den Unterschied zwischen „galt“ und „war bekannt“ konsequent durchhält, vervollständigt seine Historie, ohne sich selbst zu täuschen — und genau das ist der Unterschied zwischen einem Backtest, der live hält, und einer Illusion, die beim ersten echten Trade zerfällt.
Sie sind unsicher, ob nachträglich gefüllte Datenlücken Ihre Backtests heimlich schönen, statt echtes Signal zu zeigen? Unverbindlich anfragen — wir prüfen Ihre Historie auf Revisions- und Survivorship-Bias, trennen Original- von Revisionsstand und richten einen Backfill-Prozess ein, dem Ihre Live-Ergebnisse später nicht widersprechen.