Point-in-Time-Datenbanken die Look-Ahead-Bias an der Wurzel verhindern.

Der häufigste Grund, warum ein brillanter Backtest im Live-Betrieb scheitert, ist nicht die Strategie — es sind die Daten. Genauer: Daten, die rückwirkend verändert wurden. Bilanzkennzahlen werden Monate nach Veröffentlichung korrigiert, Indexzusammensetzungen werden nachträglich bereinigt, Analystenschätzungen werden überschrieben. Wer einen Backtest auf der heutigen, finalen Version dieser Daten rechnet, lässt seine Strategie mit Wissen handeln, das zum damaligen Zeitpunkt niemand hatte. Das ist Look-Ahead-Bias in seiner subtilsten Form — und er bläht Backtest-Renditen systematisch und erheblich auf. Point-in-Time-Datenbanken lösen das an der Wurzel, indem sie nicht nur speichern, was ein Wert war, sondern auch wann er bekannt wurde. Dieser Beitrag erklärt, wie Restatements und Revisionen Backtests vergiften, wie eine Point-in-Time-Architektur das verhindert, welcher Aufwand realistisch ist — und warum diese unscheinbare Datendisziplin oft mehr über die Glaubwürdigkeit einer Strategie aussagt als das ausgefeilteste Modell.

Das Problem — Daten, die sich rückwirkend ändern.

Viele Datenarten, die in Strategien einfließen, sind nicht in Stein gemeißelt. Sie werden nach ihrer ersten Veröffentlichung noch verändert — und genau diese Veränderungen sind der Kern des Problems.

Das prominenteste Beispiel sind Bilanz-Restatements. Ein Unternehmen meldet im Quartalsbericht einen Gewinn, korrigiert ihn aber Wochen oder Monate später nach oben oder unten — wegen einer geänderten Bewertung, eines Fehlers, einer neuen Rechnungslegung. Eine heutige Datenbank zeigt meist nur den finalen, korrigierten Wert. Wer einen Value- oder Quality-Faktor darauf backtestet, lässt das Modell mit Zahlen handeln, die zum Handelszeitpunkt noch gar nicht existierten.

Ähnlich wirken Revisionen von Makrodaten (BIP, Arbeitsmarkt werden routinemäßig nachjustiert), überschriebene Analystenschätzungen (die Konsensschätzung von gestern ist in vielen Datenbanken durch die heutige ersetzt) und Index-Rekonstitutionen, bei denen die historische Mitgliedschaft nachträglich "sauber" dargestellt wird. In all diesen Fällen ist die scheinbar harmlose, aktuelle Datenbank eine Zeitmaschine, die der Vergangenheit Wissen aus der Zukunft unterschiebt.

Warum das Backtests systematisch schönt.

Der Bias ist nicht zufällig, sondern gerichtet — und das macht ihn gefährlich. Restatements und Revisionen korrigieren oft in Richtung der "Wahrheit", die sich später herausstellte. Ein Modell, das auf finalen Daten handelt, profitiert damit indirekt von der Korrektur, die zum Handelszeitpunkt noch ausstand. Es kauft das Unternehmen, dessen Zahlen später nach oben revidiert wurden — eine Information, die im echten Leben unmöglich war.

Die Größenordnung ist erheblich. Bei fundamentalen Faktorstrategien, die direkt auf Bilanzkennzahlen aufbauen, kann der Unterschied zwischen einem Backtest auf finalen Daten und einem auf Point-in-Time-Daten mehrere Prozentpunkte Jahresrendite ausmachen — oft genau die Spanne, die über "attraktive Strategie" und "nicht handelbar" entscheidet. Was im Look-Ahead-Backtest wie ein robuster Edge aussieht, schrumpft auf sauberen Daten nicht selten zur Nulllinie.

Besonders heimtückisch: Der Bias ist im Ergebnis unsichtbar. Die Backtest-Kurve sieht sauber und plausibel aus, die Kennzahlen sind hervorragend — nichts deutet auf das Datenleck hin. Erst der Live-Betrieb deckt die Diskrepanz auf, dann allerdings mit echtem Geld. Genau diese Unsichtbarkeit ist der Grund, warum Look-Ahead durch Restatements so viele Strategien zu Fall bringt, die im Test überzeugten.

Die Lösung — speichern, was wann bekannt war.

Eine Point-in-Time-Datenbank löst das Problem konzeptionell einfach: Sie überschreibt einen Wert nie, sondern legt jede Version mit einem zusätzlichen Zeitstempel ab — dem Zeitpunkt, ab dem dieser Wert öffentlich bekannt war. Ein Quartalsgewinn existiert dann nicht als eine Zahl, sondern als Folge von Versionen: die Erstmeldung mit ihrem Bekanntwerdungsdatum, jede Korrektur mit ihrem eigenen.

Ein Backtest fragt diese Datenbank dann nicht "Wie war der Gewinn für Q1?", sondern "Welcher Gewinn für Q1 war am Handelstag X bekannt?" — eine sogenannte As-of-Query. Die Datenbank liefert die Version, die zu diesem Zeitpunkt gültig war, und ignoriert alle späteren Korrekturen. Damit handelt das Modell exakt mit dem Informationsstand, den es im echten Leben gehabt hätte. Look-Ahead durch Restatements ist strukturell ausgeschlossen, nicht durch Vorsicht, sondern durch die Datenarchitektur.

Wichtig ist der Zeitstempel: Maßgeblich ist nicht, für welche Periode ein Wert gilt, sondern ab wann er verfügbar war — inklusive realistischem Meldeverzug. Ein Quartalsbericht für den 31. März ist oft erst Mitte Mai veröffentlicht; eine korrekte Point-in-Time-Datenbank macht ihn auch erst dann abfragbar.

Survivorship und Index-Mitgliedschaft als Spezialfall.

Ein eng verwandtes, ebenso unterschätztes Problem ist die historische Index-Zusammensetzung. Wer eine Strategie auf den "heutigen" Mitgliedern eines Index backtestet, begeht gleich zwei Fehler: Survivorship-Bias (die Pleiten und Delistings fehlen) und Look-Ahead bei der Mitgliedschaft (Unternehmen werden gehandelt, bevor sie überhaupt aufgenommen wurden).

Eine Point-in-Time-Sicht auf die Indexmitgliedschaft hält fest, welche Titel zu jedem historischen Datum tatsächlich im Universum waren — inklusive der später ausgeschiedenen. Erst damit handelt eine Strategie auf dem Universum, das ihr zum jeweiligen Zeitpunkt real zur Verfügung stand. Der Effekt ist messbar: Strategien, die scheinbar zuverlässig den Index schlagen, verlieren einen erheblichen Teil ihres Vorsprungs, sobald die "Toten" und die korrekte historische Mitgliedschaft im Datensatz sind.

Diese beiden Themen — Restatement-Bias und Survivorship — sind technisch unterschiedlich, gehören aber zur selben Grundforderung: Der Backtest darf nur Information verwenden, die zum jeweiligen Zeitpunkt verfügbar war. Wer das eine sauber löst, sollte das andere nicht offen lassen.

Aufwand, Datenquellen und Kosten.

Point-in-Time-Daten sind nicht gratis — weder beim Einkauf noch in der eigenen Infrastruktur. Beim Einordnen helfen einige Faustregeln:

• Spezialisierte Datenanbieter liefern fundamentale und Schätzungsdaten bereits als Point-in-Time-Produkt, inklusive Bekanntwerdungs-Zeitstempeln. Das ist die bequemste, aber teuerste Variante — solche Datensätze kosten ein Vielfaches der "finalen" Standardprodukte.
• Selbst aufgebaute Snapshots sind die günstige Alternative: Man zieht regelmäßig (etwa täglich) den aktuellen Stand einer Datenquelle und archiviert ihn unverändert. Mit der Zeit entsteht so eine eigene Point-in-Time-Historie — allerdings erst ab dem Tag, an dem man begonnen hat. Für die Vergangenheit hilft das nicht.
• Bitemporale Speicherung (zwei Zeitachsen: Gültigkeit und Bekanntwerdung) ist die saubere technische Grundlage, erhöht aber die Komplexität von Datenmodell und Abfragen spürbar.

Realistisch sollte man einplanen, dass der Aufbau einer belastbaren Point-in-Time-Infrastruktur einen substanziellen Teil des gesamten Datenbudgets und der Engineering-Zeit eines quantitativen Projekts ausmacht — nicht selten mehr als die Modellentwicklung selbst.

Grenzen und ehrliche Einordnung.

Point-in-Time-Disziplin ist notwendig, aber nicht für jede Strategie gleich kritisch. Wer ausschließlich auf Preis- und Volumendaten handelt — reine technische oder Hochfrequenzstrategien — ist von Restatement-Bias kaum betroffen, weil Kurse nicht rückwirkend korrigiert werden (Corporate-Action-Adjustments sind ein eigenes, anders gelagertes Thema). Hier wäre der volle Point-in-Time-Aufwand für Fundamentaldaten überdimensioniert.

Umgekehrt ist die Methode für fundamentale Faktor-, Value- und Quality-Strategien schlicht nicht verhandelbar. Ein Backtest solcher Strategien ohne Point-in-Time-Daten ist nicht konservativ unsauber — er ist im Kern wertlos, weil sein Hauptergebnis vom Datenleck getragen sein kann.

Eine ehrliche Einschränkung: Auch die beste Point-in-Time-Datenbank ist nur so gut wie ihre Zeitstempel. Wenn das Bekanntwerdungsdatum ungenau ist oder den realen Meldeverzug nicht abbildet, bleibt ein Rest-Bias. Und keine Datendisziplin macht eine Strategie profitabel, die es nicht ist — sie verhindert lediglich, dass man sich eine nicht existierende Profitabilität einbildet. Das ist weniger glamourös, aber genau der Punkt: Point-in-Time-Daten schaffen keinen Edge, sie zeigen, ob ein Edge echt ist.

Warum diese Disziplin über Glaubwürdigkeit entscheidet.

In der quantitativen Praxis ist die Frage "Sind eure Backtests Point-in-Time?" eine der ersten, die ein erfahrener Investor oder Risikomanager stellt — und die Antwort trennt belastbare Forschung von hübschen Illusionen. Eine Strategie, deren Edge sich beim Wechsel von finalen auf Point-in-Time-Daten in Luft auflöst, war nie real; eine, die den Wechsel übersteht, hat eine zentrale Hürde genommen.

Deshalb lohnt es sich, die Datendisziplin nicht ans Ende des Forschungsprozesses zu stellen, sondern an den Anfang. Wer von der ersten Idee an auf Point-in-Time-Daten arbeitet, verschwendet keine Wochen an die Optimierung von Phantom-Signalen, die nur durch Look-Ahead existieren. Der Aufwand wird so zur Investition in Effizienz, nicht nur in Korrektheit.

Zusammen mit verwandten Bausteinen — bitemporaler Datenmodellierung, survivorship-freien Universen, korrekter Corporate-Action-Adjustierung und leakagefreier Validierung — bildet Point-in-Time die Grundlage, auf der quantitative Ergebnisse überhaupt erst vertrauenswürdig werden. Sie ist unspektakulär, oft unsichtbar und genau deshalb der Unterschied zwischen einer Strategie, die nur im Backtest funktioniert, und einer, die im Markt besteht.

Sie sind unsicher, ob Ihre fundamentalen Backtests durch Restatements und nachträglich bereinigte Daten geschönt sind? Unverbindlich anfragen — wir prüfen Ihre Datenpipeline auf Look-Ahead durch Revisionen, bauen eine Point-in-Time-Architektur mit As-of-Queries auf und zeigen ehrlich, wie viel von Ihrem Edge nach der Bereinigung übrig bleibt.