Die meisten KI-Initiativen im Finanzwesen beginnen am falschen Ende. Ein Team sieht eine überzeugende Demo, wählt ein Modell aus und beginnt, es in einen Workflow einzubinden. Dann stellt sich heraus, dass die darunterliegende Finanzdateninfrastruktur fragmentiert ist, voller Point-in-Time-Fehler steckt und sich nicht bis zur Quelle zurückverfolgen lässt.
Im Finanzbereich ist das kein Schönheitsfehler, sondern ein Showstopper. Eine Antwort, die sich nicht nachvollziehen lässt, ist eine Antwort, die man weder einem Portfoliomanager noch einem Prüfer vorlegen kann. Und ein Modell, das auf unzuverlässigen Daten steht, liefert nicht einfach nur falsche Antworten, es liefert sie mit voller Überzeugung.
Zu Beginn bleibt diese Lücke meist unsichtbar. Die Demo läuft auf einem sauber aufbereiteten Auszug, den jemand von Hand gezogen hat, vielleicht ein paar tausend Zeilen, die ordentlich aussehen, weil ein Mensch sie bereinigt hat. Der Produktivbetrieb läuft auf der echten Finanzdateninfrastruktur, mit verspätet eintreffenden Kursen, nachträglichen Korrekturen von Datenanbietern, nicht übereinstimmenden Identifikatoren und einem halben Dutzend Feeds, die jeweils ihre eigene Vorstellung davon haben, was ein Geschäftsquartal ist. Das Modell hat sich nicht verändert. Die Daten darunter schon, und genau da zerbricht das Projekt klammheimlich.
Erst die Daten festigen, dann das Modell
Wir drehen die übliche Reihenfolge um. Vor jeder Modellauswahl muss die Datenebene abfragebereit und korrekt sein. Das heißt, die zugrunde liegende Finanzdateninfrastruktur als das eigentliche Produkt zu behandeln und das Modell als dünne Schicht darüber. Die Bausteine, auf die wir zuerst bestehen:
- Point-in-Time-Daten, damit ein Backtest ausschließlich mit Kursen und Fundamentaldaten arbeitet, die am jeweiligen Tag tatsächlich bekannt waren, und nicht heimlich Werte heranzieht, die zu diesem Zeitpunkt noch gar nicht existierten
- Ingestion aus Markt-, Transaktions-, Meldungs- und alternativen Datenquellen
- Data Lineage und Validierung, damit sich jeder Wert vom Modellergebnis bis zum exakten Feed, zur Datei und zum Zeitstempel zurückverfolgen lässt, aus dem er stammt
- Entity Resolution, damit “dasselbe Unternehmen” über alle Feeds hinweg wirklich dasselbe Unternehmen ist
- Retrieval-Setup: Vektor- und Warehouse-Speicher, zugeschnitten auf die Fragen, die Sie tatsächlich stellen werden
Nichts davon ist glanzvoll. Es ist aber genau der Unterschied zwischen einem System, das in der Demo funktioniert, und einem, das zum Quartalsende funktioniert.
Point-in-Time-Daten sind der Teil, den Teams am häufigsten falsch machen, weil das Versagen lautlos geschieht. Eine Pipeline, die eine Kennzahl im Nachhinein korrigiert oder eine Berichtigung ohne Vintage nachträgt, lässt einen Backtest besser aussehen, als die Strategie je war. Bis das jemandem auffällt, ist das Modell längst im Produktivbetrieb, und die Zahlen, die es erzeugt hat, wurden Menschen gezeigt, die danach gehandelt haben. Point-in-Time-Daten richtig aufzusetzen ist unscheinbare Klempnerarbeit, und zugleich die günstigste Versicherung, die Sie je abschließen werden.
Dann mit Evaluation den Beweis antreten
Erst wenn die Daten solide sind, bauen wir Prototypen, und jeder Prototyp kommt mit einem Evaluationsdatensatz. Damit wird aus “sieht gut aus” eine Zahl, über die man streiten kann. Wenn das System den Prozess, den es ersetzen soll, bei dieser Zahl nicht schlägt, ist es weitaus besser, das in Woche drei zu erfahren als nach sechs Monaten Entwicklung.
Eine belastbare Data Lineage ist das, was diese Zahl verteidigungsfähig macht. Wenn ein Prüfer fragt, warum das Modell zu seiner Aussage kam, können Sie die Antwort über die Validierungsprüfungen bis zum Quelldatensatz zurückverfolgen, statt mit den Schultern zu zucken. Dieselbe Lineage, die einen Wirtschaftsprüfer zufriedenstellt, sagt auch Ihrem eigenen Team, woher eine Regression kam, wenn der Eval-Score einbricht. Lineage ist kein Formalismus, den man am Ende dranhängt, sondern das, was es überhaupt erst möglich macht, das System zu debuggen.
Wie das in der Praxis aussieht
Konkret verbringt ein Data-Layer-First-Projekt seine ersten Wochen mit Dingen, die in keiner Folienpräsentation auftauchen. Wir kartieren jeden Feed und halten seine Eigenheiten fest: welche Felder nachträglich korrigiert werden, welche verspätet eintreffen, wie Berichtigungen versioniert sind. Wir bauen die Vintage-Historie auf, sodass Point-in-Time-Daten rekonstruierbar sind und nicht bloß unterstellt werden. Wir gleichen Identifikatoren über die Quellen hinweg ab, damit ein Entity-Match eine Entscheidung ist, die wir nachvollziehen können, und kein Zufallsprodukt der Zeichenformatierung. Erst dann trägt der Lineage-Graph verlässlich genug, um ihm zu vertrauen.
Am Anfang ist das langsamer und danach weitaus schneller. Ein Team, das sich diese Arbeit gespart hat, sucht im vierten Monat danach, warum sich eine Zahl bewegt hat; ein Team, das sie geleistet hat, liest die Lineage und hat noch am selben Nachmittag eine Antwort. Die Kosten sind dieselbe Arbeit, nur früher bezahlt, wenn sie günstig ist.
Wenn Ihre KI-Roadmap mit der Wahl eines Modells beginnt, beginnt sie an der falschen Stelle. Fangen Sie bei den Daten an.