Stammdaten-Management für Finanz-KI bedeutet, die langsam veränderlichen Fakten, die ein Modell als Grundwahrheit behandelt, versioniert und point-in-time-korrekt zu halten: Währungscodes, Kalender, Instrumenten-Identifier, Klassifikationen, Kontrahenten-Hierarchien. Sie ändern sich selten und sind fast nie das, was man eigentlich modelliert – und genau deshalb richten sie im Stillen Schaden an. Ein falscher Kalender wirft keinen Fehler. Er macht einfach jede nachgelagerte Zahl unsichtbar falsch.
Die vollständige Liste ist länger, als die meisten Teams erwarten: Währungscodes, Handels- und Settlement-Kalender, Instrumenten-Identifier, Sektor- und Länderklassifikationen, Kontrahenten-Hierarchien, Produkt- und Konten-Taxonomien. Niemand liefert eine Pipeline aus, die USD als EUR liest. Was tatsächlich passiert, ist subtiler. Eine Börse benennt einen Ticker um, ein Land teilt einen ISIN-Bereich auf, ein Feiertag wird mitten im Jahr zu einem Settlement-Kalender hinzugefügt – und drei deiner Feeds übernehmen die Änderung an drei verschiedenen Terminen. Dein Modell läuft weiter. Seine Inputs haben sich unter ihm verschoben, und das erste Anzeichen ist ein langsamer Drift in den Vorhersagen, den irgendwann jemand dem Modell anlastet statt den Daten, die es speisen.
Point-in-Time-Korrektheit ist das ganze Spiel
Der teuerste Fehler im Finanz-ML ist, auf Stammdaten so zu trainieren, wie sie heute aussehen, statt so, wie sie an dem historischen Datum aussahen, das man vorgibt zu sein. Die aktuelle Sektorklassifikation einer Aktie, ihr aktueller Identifier, ihre aktuelle Muttergesellschaft: nichts davon war zwangsläufig vor zwei Jahren wahr. Joine die heutige Stammdatentabelle auf ein zwei Jahre altes Feature, und du hast die Zukunft in die Vergangenheit lecken lassen. Der Backtest sieht großartig aus. Die Produktion passt nicht dazu, und jetzt debuggst du ein Modell, obwohl der Fehler in einem Join steckt.
Wir behandeln Stammdaten standardmäßig als bitemporal. Jeder Datensatz trägt zwei Uhren:
- Effective Time: wann der Fakt in der Welt wahr wurde. Eine Ticker-Umbenennung wird zum Änderungsdatum der Börse wirksam.
- Knowledge Time: wann wir den Fakt erfahren haben. Ein Anbieter liefert diese Umbenennung womöglich drei Tage zu spät oder rückdatiert eine Korrektur.
Mit beiden Uhren kannst du die zwei entscheidenden Fragen beantworten. Was war an Datum X wahr, und was glaubten wir an Datum X, dass wahr sei? Training und Backtests nutzen die zweite und rekonstruieren exakt den Stammdatenstand, den das Modell gesehen hätte – inklusive späten Korrekturen. Das Serving nutzt den aktuell besten Wissensstand. Diese beiden getrennt zu halten ist das, was verhindert, dass sich Lookahead durch die Stammdatenschicht einschleicht – jene eine Stelle, an der Teams fast nie daran denken, danach zu suchen.
Praktisch bedeutet das: keine zerstörenden Updates. Stammdatentabellen sind Append-only-Historien mit Valid-from- und Valid-to-Bereichen. Eine Korrektur schließt die alte Zeile und öffnet eine neue; sie überschreibt nie. Speicher ist billig, und der Audit-Trail bezahlt sich schon beim ersten Mal, wenn jemand fragt, warum sich eine Zahl geändert hat.
Die Mappings verwalten, nicht nur die Codes
Die Codes selbst sind der einfache Teil. ISO 4217 für Währung, ISO 3166 für Land, ISO 10383 (MIC) für Handelsplätze, LEI für Rechtsträger, ISIN und FIGI für Instrumente. Der schwierige Teil sind die Mappings zwischen ihnen – und die Tatsache, dass dasselbe reale Objekt in jedem Feed einen anderen Namen trägt.
Ein Instrument kommt vielleicht als ISIN von einer Depotbank an, als anbieterspezifische ID aus einem Marktdaten-Feed, als interne Wertpapier-ID aus dem Book of Record und als Freitextbeschreibung aus einer Tabelle, die ein Desk noch von Hand pflegt. Diese in Einklang zu bringen ist Entity Resolution, und genau dort verbringen die meisten Stammdatenprojekte tatsächlich ihre Zeit. Ein paar Regeln, an denen wir festhalten:
- Ein Golden Key pro Konzept, mit jedem Quell-Identifier darauf gemappt und dem Mapping selbst versioniert. Nachgelagerte Systeme referenzieren den Golden Key, nie direkt die ID eines Anbieters.
- Cross-References sind über die Zeit many-to-many. Eine ISIN kann über eine Wiederverwendungslücke hinweg auf verschiedene Instrumente zeigen; ein FIGI ist stabiler, aber nicht universell. Modelliere die Beziehung als zeitlich begrenzte Kanten, nicht als statisches Lookup.
- Nicht zugeordnete Datensätze wandern in eine Review-Queue, nicht in einen stillen Default. Eine Default-Währung oder ein Fallback-Kalender ist genau der Weg, auf dem falsche Zahlen ins System gelangen, ohne dass irgendjemand entschieden hätte, sie hereinzulassen.
Kalender verdienen eine eigene Erwähnung, denn sie sind täuschend fummelig. Handelskalender, Settlement-Kalender, Feiertagskalender und Geschäftstagskonventionen unterscheiden sich je Markt und ändern sich über die Zeit. Setz einen einzigen Feiertag falsch, und du verschiebst jedes gelaggte Feature, jedes Rolling Window und jedes Settlement-Datum, das du für diesen Markt berechnest – egal ob er T+1 oder T+2 settelt. Wir beziehen Kalender je Handelsplatz, versionieren sie und testen die Datumsarithmetik gegen bekannte Settlement-Daten, statt den Defaults einer Bibliothek zu vertrauen.
Governance, die das Quartalsende übersteht
Stammdaten gehen an den Rändern schief. Ein Anbieter ändert ein Schema, ein neuer Markt wird onboarded, eine Corporate Action formt einen Identifier um – und es landet immer ausgerechnet am Quartalsende, wenn niemand Zeit hat, es zu bemerken. Die Kontrollen, die das abfangen, sind unglamourös, und genau auf ihnen bestehen wir.
- Reconciliation zwischen Quellen nach Zeitplan. Wenn die Währung der Depotbank für eine Position mit der des Marktdaten-Feeds nicht übereinstimmt, ist das ein Finding – protokolliert mit einem False-Positive-Budget, damit echte Breaks nicht im Rauschen untergehen.
- Lineage von jedem Modell-Input zurück zum Quelldatensatz und zur exakt verwendeten Version. Wenn eine Vorhersage schief aussieht, sollte die Frage „Woher kam dieser Code und wann hat er sich geändert?” Minuten dauern, nicht einen Tag.
- Change-Alerting auf der Stammdatenschicht selbst. Ein Anstieg neuer Identifier, eine Kalenderänderung, ein Mapping, das plötzlich weniger Datensätze abdeckt als gestern: das sind Frühwarnungen, dass sich vorgelagert etwas bewegt hat.
- Ownership. Jemand zeichnet neue Code-Sets und Mapping-Änderungen ab. Stammdaten ohne Owner verrotten, und die Fäulnis bleibt unsichtbar, bis ein Modell sie frisst.
Nichts davon ist aufregende Arbeit. Es ist Klempnerei. Aber das Modell ist nur so point-in-time-korrekt wie die Stammdaten darunter, und diese Daten fangen in dem Moment an zu driften, in dem du aufhörst hinzusehen. Die Teams, die konsistentes, reproduzierbares Modellverhalten erreichen, sind meist nicht die mit der cleversten Architektur. Es sind die, die Währungen, Kalender, Instrumente und Codes als versioniertes und abgeglichenes Asset mit klarem Owner behandelt haben – statt als Lookup-Tabelle, die jemand einmal aufgesetzt und dann vergessen hat.
Häufige Fragen
Wie versioniert man Stammdaten, damit sich ein Modell später reproduzieren lässt?
Speichere jedes Code-Set, jedes Mapping und jeden Kalender als reine Append-only-Historie mit Valid-from- und Valid-to-Zeitstempeln plus dem Ingest-Zeitpunkt. Um einen Lauf zu reproduzieren, fragst du die Daten so ab, wie sie zum Entscheidungszeitpunkt des Laufs standen – nicht so, wie sie heute stehen.
Brauchen wir einen bitemporalen Speicher, oder reicht eine einfache Effective-Date-Spalte?
Wenn du Fragen immer nur zum Stand von jetzt beantwortest, reicht eine Effective-Date-Spalte. Sobald du erklären musst, was ein Modell an einem vergangenen Datum gesehen hat, oder es in einem Audit verteidigen musst, brauchst du sowohl Effective Time als auch Knowledge Time – also bitemporal.
Wo sollten Stammdaten relativ zum Feature Store liegen?
Vorgelagert. Löse Identifier auf, wende den korrekten Kalender an und normalisiere Codes, bevor Features berechnet werden, sodass der Feature Store immer nur saubere, point-in-time-korrekte Keys zu sehen bekommt. Stammdaten innerhalb der Feature-Logik zu korrigieren streut dieselbe Korrektur über jede einzelne Pipeline.