KI für Treasury-Cash-Positioning und Forecasting

Ein Treasury-Cash-Forecast, der funktioniert, beantwortet jeden Morgen zu einem festen Cutoff eine einzige Frage: Wie viel Cash wird über die nächsten ein bis fünfzehn Bankarbeitstage auf jedem Konto und in jeder Währung liegen, und wie sicher sind wir uns bei jedem Tag? Man baut ihn, indem man jeden bekannten und terminierten Flow aus den Quellsystemen kategorisiert und danach nur noch die verbleibende zeitliche Streuung modelliert.

Das Modell ist der einfache Teil. Ob das Ganze funktioniert, entscheidet eine engere Disziplin: dafür zu sorgen, dass jeder Input das widerspiegelt, was am Forecast-Datum tatsächlich bekannt war, und nichts, was erst danach hineingesickert ist.

Die meisten Treasury-Teams haben bereits ein Spreadsheet, das eine Variante davon leistet. Es zieht die Schlusssalden von gestern, addiert erwartete Eingänge aus dem OP-Bericht der Forderungen, zieht Zahlungslauf und Lohn ab und landet bei einer Zahl. Es ist weniger falsch als langsam und fragil. Jemand baut es jeden Morgen von Hand neu auf, die Kategorisierungslogik steckt im Kopf eines einzigen Analysten, und wenn ein großer Kunde drei Tage zu spät zahlt, verschiebt sich die ganze Woche, ohne dass man erkennen kann, warum. Was wir bauen, behält dasselbe Grundgerüst und repariert die Teile, die unter Last versagen.

Mit der Kategorisierung beginnen, nicht mit einem Modell

Die Position am nahen Horizont ist größtenteils deterministisch. Man kennt die Lohntermine und den Zeitpunkt, zu dem die vierteljährliche Steuerzahlung abgeht. Lastschriften, Kreditbedienung und stehende Intercompany-Sweeps stehen alle irgendwo im Kalender. Ein großer Teil der Eingänge lässt sich konkreten offenen Rechnungen mit Zahlungszielen und Zahlungshistorie zuordnen. Bevor überhaupt ein Forecasting stattfindet, besteht die Aufgabe darin, jeder erwarteten Cash-Bewegung eine Kategorie und ein wahrscheinlichstes Datum zuzuweisen, mit sauberer Herkunft zurück zum ursprünglichen Datensatz.

Diese Zuordnung ist der Punkt, an dem die eigentliche Engineering-Arbeit steckt, und sie ist ein Klassifikationsproblem mit einem anspruchsvollen False-Positive-Budget. Eine Kontoauszugszeile mit dem Text “SEPA CT REF 88213 ACME HLDG” muss zu einem Geschäftspartner, einer Gesellschaft, einer Währung und idealerweise der Rechnung, die sie ausgleicht, aufgelöst werden. Die Entity Resolution über ERP, Bankfeeds und TMS hinweg entscheidet, ob ein Eingang auf dem richtigen Konto und am richtigen Tag landet. Macht man es falsch, ist die Position daneben ohne erkennbare Ursache, was schlimmer ist, als aus einem Grund daneben zu liegen, den man sehen kann.

Wir bauen das als gelabelte Pipeline mit Audit-Trail:

• Regelbasierte Extraktion für die strukturierten, hochsicheren Flows: terminierte Zahlungen, Lohn, Steuern, Schuldendienst.
• Ein trainierter Klassifikator für die mehrdeutigen Auszugstexte und die Eingänge, die keine saubere Referenz mitführen.
• Ein Eval-Set aus handgelabelten historischen Zeilen, das jede Modelländerung vor dem Ausrollen bestehen muss, damit eine “kleine Verbesserung” das Counterparty-Matching nicht klammheimlich verschlechtern kann.
• Ein Confidence-Score auf jeder kategorisierten Position, sodass Flows mit geringer Konfidenz einem Menschen vorgelegt werden, statt still in die Position einzugehen.

Straight-through processing ist das Ziel für die sichere Mehrheit. Der Rest geht in eine Queue, die ein Analyst in Minuten abarbeitet, und jedes Override wird zu einem neuen Trainingslabel.

Point-in-time-Korrektheit ist das ganze Spiel

Hier werden Treasury-Forecasts still und leise ruiniert. Wenn man Trainingsdaten zusammenstellt oder einen Backtest fährt, lässt man leicht zu, dass eine Zeile Informationen sieht, die am prognostizierten Datum noch gar nicht existierten. Eine Zahlung, die am 12. gebucht wurde, taucht in den Features für den 10. auf, weil der Extrakt schlicht den aktuellen Stand des Ledgers abgefragt hat. Das Modell lernt, Dinge zu “prognostizieren”, die ihm in Wahrheit gezeigt wurden. Die Backtest-Genauigkeit sieht hervorragend aus. Die Produktionsgenauigkeit bricht zusammen.

Die Abwehr besteht darin, jeden Input as-of dem Forecast-Datum zu snapshotten und Lookahead zu verbieten. Konkret:

• Kontoauszüge, offene Posten und Terminpläne mit dem Zeitstempel speichern, zu dem sie bekannt wurden, nicht nur mit ihrem Wertstellungsdatum.
• Beim Aufbau des Feature-Vektors für Forecast-Datum T die Welt so abfragen, wie sie zum Zeitpunkt T stand, einschließlich der Tatsache, dass manche Rechnungen noch offen und manche Zahlungen noch ausstehend waren.
• Backtests auf dieselbe Weise rekonstruieren, indem man einen wandernden Cutoff durch die Historie schiebt, sodass der berichtete Fehler der Fehler ist, den man tatsächlich bekommen wird.

Ein Feature Store, der As-of-Snapshots liefert, macht das beherrschbar statt zu einem archäologischen Projekt pro Analyse. Er liefert außerdem die Abstimmung, die man für das Audit braucht: Jeder Forecast lässt sich gegen exakt die Inputs erneut abspielen, die er gesehen hat, was zählt, wenn ein Treasurer oder ein Prüfer fragt, warum die Zahl vom letzten Dienstag daneben lag.

Den Rest modellieren und die Unsicherheit quantifizieren

Sobald die bekannten Flows kategorisiert und datiert sind, bleibt Streuung übrig. Kunden zahlen früh, pünktlich oder spät, und die Verteilung unterscheidet sich je nach Segment und Geschäftspartner. Nicht committete operative Ausgaben treffen ohne Terminplan ein. Der Tail sind Positionen, die niemand gebucht hat. Dieser Rest ist das eigentliche Forecasting-Problem, und er ist klein genug, dass man nichts Exotisches braucht.

Wir fitten Zeitpunktverteilungen pro Kategorie statt einer einzelnen Punktschätzung. Ein Kunde mit 30-Tage-Ziel, der historisch an Tag 34 mit fünf Tagen Standardabweichung zahlt, sollte den erwarteten Eingang verschieben und das Band dieses Tages verbreitern, nicht nur einen Punkt versetzen. Das Ergebnis ist eine Tagesposition mit Intervall, sodass der Treasurer nicht nur die zentrale Zahl sieht, sondern auch, wo das Risiko einer Unterdeckung oder eines untätigen Guthabens tatsächlich liegt.

Zwei operative Disziplinen halten das über die Zeit ehrlich:

• Drift-Monitoring auf der Kategorisierung und den Zeitpunktverteilungen. Das Zahlungsverhalten ändert sich zum Quartalsende, rund um Aktionen und wenn ein großer Kunde die Konditionen neu verhandelt. Wenn sich der Fehler nach Wochentag oder Segment bewegt, will man einen Alert, keine Überraschung.
• Ein stehender Backtest, der den Fehler nach Horizont berichtet. Tag eins und Tag zwei sollten eng sein. Tag zehn sollte sichtbar breiter sein, und die Intervalle sollten die Ergebnisse ungefähr zu ihrer angegebenen Rate abdecken. Sind die Bänder zu eng, lügen sie, und ein Treasurer, der einem engen Band vertraut, gerät in die Unterdeckung.

Heraus kommt eine Position, auf die ein Treasurer noch vor dem Mittagessen handeln kann, mit dem Grund für jeden Tag, der Herkunft zurück zu den Quelldatensätzen und ehrlichen Bändern für die Unsicherheit. Das ist der Unterschied zwischen einem Forecast, der eine Finanzierungsentscheidung stützt, und einem, der still ignoriert wird, weil niemand sehen kann, woher er kommt.