Point-in-time-Daten

Point-in-time-Daten speichern nicht nur einen historischen Wert, sondern auch, wann er veröffentlicht, empfangen, revidiert und verwendbar wurde. Damit lässt sich der Informationsstand zu einem früheren Zeitpunkt rekonstruieren. Die heute als „final“ sichtbare Zahl reicht dafür nicht.

Ein Umsatz kann dem ersten Quartal zugeordnet, im Mai gemeldet und im August korrigiert worden sein. Ein Indexbestandteil kann im Juni angekündigt und im Juli aufgenommen werden. Ein Backtest im April darf weder den Umsatz noch die spätere Revision oder Mitgliedschaft verwenden.

Vier Daten, die nicht verwechselt werden dürfen

Für handelbare Entscheidungen kommen Cutoff, Zeitzone, Kalender und Verarbeitungsdauer hinzu. „Am selben Tag“ garantiert keine zeitliche Verfügbarkeit vor der Order.

Universum, Identifikatoren und Mitgliedschaft

Ein point-in-time Universum verwendet für jeden Zeitpunkt die damals elegiblen Instrumente. Es bewahrt Aufnahme- und Ausschlussintervalle, Ankündigungs- und Wirksamkeitsdaten, Delistings, Fusionen und dauerhafte Identifikatoren. Der heutige Ticker ist keine stabile Identität; derselbe Ticker kann nacheinander verschiedene Emittenten bezeichnet haben.

Regeln zur Mindestliquidität, Marktkapitalisierung oder Datenhistorie müssen mit damals verfügbaren Werten berechnet werden. Wer heutige Indexmitglieder auf die Vergangenheit projiziert, führt Survivorship Bias ein, selbst wenn alle Preise korrekt zeitgestempelt sind.

Kapitalmaßnahmen und Delisting

Split, Dividende, Spin-off, Bezugsrecht, Fusion und Delisting besitzen mehrere Zeitpunkte und ökonomische Folgen. Bereinigte Preise sind nur dann verwendbar, wenn die Anpassungsmethode keine damals unbekannte Information in frühere Signale trägt. Für Simulation und Ergebnisrechnung müssen Ankündigung, Ex-Tag, Zahlung, Umtausch und letzte handelbare Sitzung getrennt bleiben.

Ein verschwundener Titel darf nicht einfach aus dem Datensatz entfernt werden. Letzter Preis, Barabfindung, Umtauschverhältnis, Delisting-Rendite oder ein als unsicher deklarierter Wert sind Teil des Ergebnisses. Fehlen Daten, werden Annahme und Sensitivität dokumentiert.

Point-in-time-Protokoll

1. Für jede Quelle Ereigniszeit, Veröffentlichung, Empfang und Revision speichern.
2. Rohdaten unveränderlich versionieren und Korrekturen als neue Vintages führen.
3. Abfragen als „known as of t“ ausführen; available_at > t ausschließen.
4. Historische Mitgliedschaften und permanente Identifikatoren verwenden.
5. Kapitalmaßnahmen mit allen relevanten Zeitpunkten und Cashflows abbilden.
6. Vendor-Lag, Zeitzone, Sitzungen, Feiertage und Cutoffs einbeziehen.
7. Transformationen, Imputation und Skalierung nur auf zulässigen Daten fitten.
8. Dataset-Snapshot, Code, Konfiguration und Hash mit dem Ergebnis archivieren.

Ein schneller Audit rekonstruiert einen historischen Stichtag aus dem Archiv, vergleicht die damalige und heutige Datenantwort, zählt aktive und ausgeschiedene Instrumente je Jahr und prüft, ob revidierbare Serien mehr als einen Vintage besitzen.

Operativer Zeitpunkt und Datenherkunft

Der für eine Order maßgebliche Zeitpunkt ist nicht zwingend der sichtbare Zeitstempel der Quelle. Eine Meldung kann um 16:05 Uhr veröffentlicht, um 16:08 Uhr vom Anbieter geliefert und erst um 16:09 Uhr von der Pipeline verarbeitet werden. Für die Strategie gilt der Zeitpunkt, zu dem ihr System die Information tatsächlich nutzen konnte. Fehlt bei Tagesdaten eine belastbare Uhrzeit, wird eine konservative Konvention — etwa Nutzung ab der nächsten Sitzung — vor dem Test festgelegt und in jedem Lauf gleich angewendet.

Die Datenherkunft muss vom Rohwert bis zum Feature nachvollziehbar bleiben: Originaldokument oder Feed, Vendor-Version, Ingestion-Log, Transformation und Abfragecode. So lässt sich unterscheiden, ob eine Abweichung aus einer Quellenrevision, einer verspäteten Lieferung oder einer internen Verarbeitung stammt. Ein heutiger Download derselben URL beweist den früheren Inhalt nicht; dafür braucht es archivierte Snapshots oder echte Vintage-Schnittstellen.

Schnelle Kontrollen vor dem Backtest

Diese Prüfungen ersetzen keinen vollständigen Daten-Audit. Sie verhindern aber, dass eine heute saubere Tabelle stillschweigend als damals verfügbar gilt.

Beispiel

Eine Strategie reagiert auf eine Konjunkturreihe. Der heute verfügbare Verlauf enthält revidierte Werte und ordnet sie dem jeweiligen Referenzmonat zu. Der fehlerhafte Backtest liest diese finale Reihe. Der korrekte Test fragt für jede Entscheidung den damals letzten veröffentlichten Vintage ab, berücksichtigt die Veröffentlichungszeit und handelt frühestens im danach erreichbaren Fenster.

Das Verfahren sagt nicht, welcher Datenanbieter oder Lag universell richtig ist. Es macht die Informationsgrenze überprüfbar.

Grenzen

Point-in-time bedeutet nicht automatisch fehlerfrei, vollständig oder handelbar. Ein Archiv kann falsche Zeitstempel, unvollständige Delistings, veränderte Symbole oder nicht dokumentierte Vendor-Korrekturen enthalten. Auch saubere Daten beseitigen weder Data Snooping noch unrealistische Kosten, geringe Stichprobengröße oder Regimewechsel. Datenherkunft, Abdeckung und bekannte Lücken bleiben Teil der Schlussfolgerung.

Quellen

• Federal Reserve Bank of St. Louis, ALFRED® und Real-Time Periods — Archivierung ursprünglich veröffentlichter Werte, Revisionen und informativer Gültigkeitszeiträume.
• Center for Research in Security Prices, CRSP Survivor-Bias-Free US Mutual Fund Database Guide — Datenmodell für aktive und beendete Fonds.
• U.S. Securities and Exchange Commission, EDGAR Application Programming Interfaces — Einreichungs- und Unternehmensdaten mit Aktualisierungsangaben.
• Tyler Shumway, The Delisting Bias in CRSP Data, The Journal of Finance, 1997 — Folgen ausgelassener Delisting-Renditen.
• S&P Dow Jones Indices, Equity Indices Policies & Practices — Ankündigungen, Wirksamkeitsdaten, Rebalancing und Behandlung von Zusammensetzungskorrekturen.

Verwandte Themen

• Systematischer Handel, Backtests und Validierung
• Backtest
• Data Leakage und Look-ahead Bias
• Survivorship Bias
• Out of sample