Das meiste Corporate-Cash-Forecasting beantwortet die Frage: Wo werden wir den Tag beenden? Intraday-Liquiditätsprognose beantwortet eine schwierigere und nützlichere: Wo stehen wir jetzt gerade, und schaffen wir den nächsten Settlement-Peak, ohne einen Puffer zu reißen oder hektisch Funding zu suchen? Der Unterschied zählt, weil Funding-Probleme nicht am Tagesende entstehen. Sie entstehen um 10:40 Uhr, wenn ein großer Zahlungseingang verspätet ist, die Payroll in der Queue steht und die Position auf dem Bildschirm eine Stunde alt ist.
Für Banken hat diese Disziplin einen regulatorischen Anker: BCBS 248 erwartet, dass Institute die erwarteten Brutto-Zu- und -Abflüsse messen, deren Intraday-Timing antizipieren, die Bandbreite möglicher Netto-Funding-Lücken zu verschiedenen Tageszeitpunkten prognostizieren und Positionen gegen verfügbare Ressourcen wie Zentralbankreserven, verbleibenden Intraday-Kredit und mobilisierbare Sicherheiten überwachen. Für Unternehmen gibt es kein entsprechendes Mandat, aber die operative Logik überträgt sich direkt: kontinuierliche Sichtbarkeit über Entitäten, Banken und Währungen, ein Policy-Puffer oberhalb der erwarteten Peaks und die Fähigkeit zu handeln, bevor aus einer Lücke eine gescheiterte Zahlung wird.
Der ehrliche Name für das, was 2026 funktioniert, ist Nowcasting. Das Ziel sind die aktuelle Position und die nächsten Stunden, kontinuierlich aktualisiert, mit einer Aktion an jeder Schwelle. Cash-Forecasting auf langen Horizonten ist ein anderes Problem mit anderen Daten, und wer beides vermischt, baut Systeme, die über den nächsten Monat präzise sind und über den heutigen Nachmittag falsch.
Die Daten bestimmen die Obergrenze
Kein Modell läuft seinen Feeds davon. Der praktische Stack hat drei Schichten.
- Bankreporting. camt.052-Intraday-Kontoberichte sind das Arbeitspferd: Salden- und Transaktionsupdates im Tagesverlauf, im ISO-20022-Format, in der Frequenz, die die eigenen Banken liefern. Wo Banken API-Endpunkte für Salden und Transaktionen anbieten, sollte man sie nutzen; sie liefern Saldo-Snapshots, schwebende Posten und Buchungsstatus mit geringerer Latenz als Batch-Reporting und machen den Unterschied zwischen einer Position, die Minuten alt ist, und einer, die Stunden alt ist.
- Das eigene Forward Book. Terminierte Zahlungen, erwartete Settlements, offene ERP-Posten und TMS-Deal-Flows sind der vorhersehbarste Teil des Tages, und es sind Daten, die man ohnehin besitzt. Ein großer Teil der Intraday-Bewegung ist selbst initiierte Aktivität; eine Prognose, die sie ignoriert, rät bei Dingen, die sie schlicht wissen sollte.
- Nachrichtenanreicherung. ISO-20022-Zahlungsdaten tragen strukturierte Gegenpartei- und Verwendungszweckinformationen, die weit bessere Modell-Features abgeben, als Legacy-Formate es erlaubten. Gegenparteiverhalten, Purpose Codes und historische Timing-Muster je Zahler sind die Inputs, mit denen ein Modell sagen kann: “Dieser Eingang landet üblicherweise bis 11:00 Uhr”, mit Konfidenzintervall.
Die wiederkehrenden Schmerzpunkte sind Latenz-Mismatch, wenn der gemeldete Saldo dem realen hinterherhinkt, weil Zahlungen schneller laufen als das Reporting aktualisiert, und Zeitstempelqualität, wenn Buchungszeit und Wertstellungszeit vermengt werden und still jedes darauf gebaute Timing-Feature korrumpieren. Klären Sie die Semantik bei der Ingestion, je Bank, vor jeder Modellierung. Die Fragmentierung über ERP, TMS, Bankportale und Payment Hubs ist die andere Steuer; die Abhilfe ist eine einzige Treasury-Datenschicht, in der alles landet. Das ist langweiliger als Modellierung und mehr wert.
Modelle: Komplexität verdienen, nicht voraussetzen
Die Evidenz spricht für eine Benchmark-Leiter statt des direkten Griffs zu Deep Learning. Klassische Baselines, autoregressive und HAR-artige Modelle sowie dynamische Panels, sind schnell, interpretierbar und schwer zu schlagen: Eine europäische Liquiditätsstudie fand die niedrigsten Prognosefehler bei einem dynamischen Panelmodell, und Diebold-Mariano-Tests zeigten keinen statistisch signifikanten Vorteil von Random Forest, XGBoost oder SVR dagegen. In anderen Liquiditäts-Settings haben Gradient-Boosting-Ensembles sowohl Random-Forest- als auch LSTM-Benchmarks übertroffen, und die breitere Literatur sieht ML vor allem dort vorn, wo die Dynamik nichtlinear oder regimeabhängig ist, auch unter Stress.
Das Muster, das wir empfehlen: zuerst eine regelbasierte Prognose, weil sie kodiert, was Treasury bereits weiß, und einen Boden liefert; dann statistische Baselines; danach ein Gradient-Boosted-Modell, und Sequenzmodelle nur dort, wo Timing-Abhängigkeit nachweislich zählt. Prognostizieren Sie auf mehreren Horizonten, nächste 15 Minuten, Stundenende, Tagesende, weil an jedem andere Entscheidungen hängen. Halten Sie jede Sprosse der Leiter in Produktion und berichten Sie sie gegeneinander, denn dieser Vergleich ist der laufende Beleg, dass das komplexe Modell seinen Platz noch verdient.
Erklärbarkeit ist hier nicht optional. Eine Treasurerin, die gleich einen Lieferantenlauf verzögert oder eine Intraday-Linie zieht, braucht den Treiber, etwa “das Modell erwartet, dass der übliche Konzentrations-Sweep um 11:00 Uhr verspätet ist”, nicht eine nackte Zahl. Feature Attribution auf Tree-Ensembles bringt einen fast ans Ziel, was ein weiteres Argument für sie gegenüber weniger transparenten Architekturen ist.
Von der Prognose zur Aktion
Eine Prognose, die kein Verhalten ändert, ist Reporting. Der Design-Schritt, der das System operativ macht, ist das Mapping prognostizierter Pufferverletzungen auf ein kleines Menü an Aktionen: Sweep aus einer anderen Entität, Verzögerung einer diskretionären Zahlung, Beschleunigung eines Eingangs, Ziehen von Intraday-Kredit, Verpfändung oder Mobilisierung von Sicherheiten, oder Umleitung einer Zahlung auf eine andere Bank oder Rail.
Puffer machen das konkret. Für Unternehmen ist der Puffer ein Policy-Boden je Entität, Bank und Währung, dimensioniert gegen Timing-Unsicherheit, verspätete Eingänge und Zahlungsballungen, und gebunden an den realen Kalender aus Settlement-Fenstern, Payroll und Lieferantenzyklen. Für Banken ist das Pufferdesign durch das tatsächliche Inventar nutzbarer Ressourcen unter BCBS 248 begrenzt. So oder so ist der nützliche Output probabilistisch: nicht “der Saldo um 14:00 Uhr wird X betragen”, sondern “mit 10 % Wahrscheinlichkeit reißt der Saldo um 14:00 Uhr den Boden”, denn der Puffer existiert genau dafür, den Tail zu absorbieren, und die Aktionsschwelle sollte an der Tail-Wahrscheinlichkeit hängen.
Staffeln Sie die Reaktionen. Aktionen mit hoher Konfidenz und niedrigen Kosten, etwa ein interner Sweep, können automatisch auslösen; alles, was Gegenparteien berührt oder Geld kostet, läuft zu einem Menschen, mit Prognose, Treiber und empfohlener Aktion in einer Ansicht.
Die Betriebsrealität
Der Großteil der Lebenszykluskosten dieses Systems ist nicht das Modell. Kontinuierliche Ingestion muss überleben, dass eine Bank ihren Dateifahrplan ändert, dass ein camt doppelt geliefert wird und dass ein Feiertag jedes Muster gleichzeitig verschiebt. Drift ist strukturell, nicht zufällig: Payroll-Kalender verschieben sich, Gegenparteien ändern ihr Verhalten, Quartalsenden verzerren alles, und ein auf ruhigen Märkten trainiertes Modell degradiert genau dann, wenn es am meisten zählt. Das bedeutet: Prognosefehler je Horizont und je Konto überwachen, bei Degradierung alarmieren und nach Plan sowie auf Trigger neu trainieren.
Fehlermodi verdienen explizites Design. Wenn ein Feed veraltet, sollte das System auf die regelbasierte Prognose zurückfallen und das auch sagen, statt eine selbstbewusste Zahl auf alten Daten zu präsentieren. Jede automatisierte Aktion braucht ein Log mit Position, Prognose, Schwelle und der Regelversion, die ausgelöst hat, für Prüfer ebenso wie für die eigenen Post-Incident-Reviews. Und die funktionsübergreifende Naht, Treasury verantwortet Entscheidungen, eine Datenfunktion die Pipeline, braucht auf jeder Seite einen benannten Owner. Nach unserer Erfahrung ist die Modellierung der schnelle Teil; an Ingestion, Monitoring und Ownership entscheidet sich, ob Intraday-Liquiditätsprogramme gelingen oder still außer Gebrauch geraten.
Häufige Fragen
Wie viel Historie brauchen wir, bevor sich das Training eines ML-Intraday-Modells lohnt?
Genug, um die Kalendereffekte abzudecken, die die eigenen Flüsse treiben: Payroll-Zyklen, Lieferantenläufe, Steuertermine, Quartalsenden. In der Praxis heißt das mindestens ein Jahr an Intraday-Salden- und Transaktionsdaten, und selbst dann sollte das Modell hinter statistischen Baselines zurückstehen, bis es sie out of sample schlägt. Wer drei Monate Daten hat, baut zuerst die Ingestion und die regelbasierte Prognose; das Historienproblem löst sich währenddessen von selbst.
Unsere Banken senden camt.052 nur wenige Male am Tag. Ist Intraday-Forecasting trotzdem tragfähig?
Ja, aber die Aktualisierungsrate begrenzt, worauf die Prognose reagieren kann; behandeln Sie die Reporting-Frequenz deshalb als Design-Input. Zwischen den Updates lässt sich die Position mit den eigenen terminierten Zahlungen und erwarteten Settlements fortschreiben, was an einem normalen Tag den Großteil der Bewegung ausmacht. Wo eine Bank API-Endpunkte für Salden anbietet, nutzt man sie für die wichtigsten Konten und akzeptiert anderswo gröbere Sichtbarkeit. Einheitliche Latenz über alle Konten ist nicht nötig, nur Ehrlichkeit darüber, welche Positionen veraltet sind.
Wer sollte das Intraday-Modell verantworten, sobald es live ist?
Treasury verantwortet die Entscheidungen und die Puffer-Policy; eine Daten- oder Analytics-Funktion verantwortet Pipeline, Monitoring und Retraining. Der Fehlermodus ist ein Modell, das ein Datenteam gebaut hat und dem Treasury nicht traut, oder ein Treasury-Spreadsheet, das um 7 Uhr morgens niemand bedienen kann, wenn der Owner im Urlaub ist. Schreiben Sie den Eskalationspfad für den Fall auf, dass der Feed bricht oder die Prognose degradiert, denn beides wird passieren.