KI-gestützte Liquiditätsplanung und Treasury-Optimierung

Das echte Ausmaß des Problems

Das Problem beginnt nicht mit dem schlechten Forecast. Es beginnt mit den Daten, die den Forecast unmöglich machen.

Ein Unternehmen mit fünf bis fünfzehn Bankverbindungen in zwei oder mehr Ländern hat täglich mindestens ebenso viele Datenquellen: MT940-Dateien unterschiedlichen Formats, EBICS-Kontoauszüge mit abweichendem Feldmapping, SWIFT-Confirmations für Devisengeschäfte, offene-Posten-Listen aus dem ERP, dazu manuelle Korrekturen für noch nicht verbuchte aber bereits bekannte Zahlungen.

Diese Datenfragmentierung hat eine direkte Folge: Prognosen dauern zu lange, sind zu alt, wenn sie fertig sind, und decken nicht alle Szenarien ab. Laut Capgemini World Payments Report verlassen sich mehr als 60 Prozent der Finanzinstitute noch immer auf manuelle Abstimmungsprozesse im Cash Management, obwohl die Technologie für Automatisierung seit Jahren verfügbar ist. Weniger als 5 Prozent der befragten Treasury-Teams hatten KI-gestützte Prozesse 2024 vollständig skaliert, der Rest exploriert noch oder hat Pilotprojekte gestartet, die nicht ins Produktiv-Stadium kamen.

Was Treasury-Teams durch den manuellen Aufwand verlieren, ist nicht nur Zeit. Es sind drei konkrete Steuerungsmöglichkeiten:

• Kurzfristige Anlageoptimierung: Wer nicht weiß, ob er übermorgen 8 oder 12 Millionen Euro überschüssige Liquidität haben wird, kann den Überschuss nicht sinnvoll in Tages- oder Dreimonatsgeld anlegen, er parkt ihn ungeplant auf dem Kontokorrent.
• Früherkennung von Liquiditätsengpässen: Ein Engpass, der in der 30-Tage-Prognose erkennbar gewesen wäre, wird im manuellen Prozess erst sichtbar, wenn er wenige Tage entfernt ist, zu spät für günstige Refinanzierungsoptionen.
• LCR/NSFR-Reporting: Banken unter Basel III-Regelwerk müssen täglich nachweisen, dass ihre Liquidity Coverage Ratio (LCR) ≥ 100 % beträgt. Die manuelle Berechnung dieser Kennzahl bindet täglich 1–2 Stunden Kapazität im Treasury.

Mit vs. ohne KI, ein ehrlicher Vergleich

¹ Prognosegenauigkeit: eigene Schätzwerte, variiert stark nach Datenqualität und Prognosemodell, kein allgemeingültiger Benchmark. ² Basierend auf dem Bosch-Fallbeispiel aus der KPMG-Erhebung 2025; nicht repräsentativ für alle Implementierungen.

Der Vergleich verführt zu Optimismus. Was er verbirgt: Der Nutzen entsteht nicht am ersten Tag. Ein KI-gestütztes Treasury-System braucht 6–12 Monate historische Daten in einheitlichem Format, bevor seine Prognosen die manuellen Modelle systematisch schlagen. Wer schlechte Daten in ein KI-Modell eingibt, bekommt schlechte Prognosen schneller, nicht bessere.

Einschätzung auf einen Blick

Zeitersparnis, hoch (4/5) Der tägliche Prognoseaufwand von 2–4 Stunden ist greifbar und wiederholbar, ein KI-System, das MT940 und EBICS-Daten automatisch einliest, konsolidiert und zum Forecast verarbeitet, spart diese Zeit zuverlässig ein. Nicht höher bewertet, weil der verbleibende manuelle Plausibilisierungsaufwand real ist: KI-Outputs im Treasury werden vor Entscheidungen geprüft, nicht blind übernommen.

Kosteneinsparung, mittel (3/5) Die Einsparung entsteht indirekt über freigesetztes Working Capital: Bosch berichtete im Rahmen der KPMG-Erhebung (2025) eine Reduktion des Liquiditätspuffers um 30 Prozent, bei einem Konzern mit hohem Liquiditätsbestand können das achtstellige Beträge sein, die in Anlage oder Schuldentilgung fließen. Für mittelständische Unternehmen mit überschaubaren Cashpositionen ist der absolute Effekt deutlich kleiner. Mittelfeld, weil die Verbesserung real ist, aber schwer vom operativen Geschäft isolierbar bleibt.

Schnelle Umsetzung, niedrig (2/5) Die Bankdatenpipeline ist der Flaschenhals. EBICS-Anbindung für fünf Banken dauert allein 4–8 Wochen, jede Bank hat eigene Freigabeprozesse, eigene Formatvarianten und eigene Testzeiträume. ERP-Integration, historische Datenaufbereitung und Modellkalibrierung kommen dazu. Realistisch sind 5–9 Monate bis zum produktiven KI-Forecast. Wenige Anwendungsfälle im Finanzbereich sind technisch aufwendiger.

ROI-Sicherheit, mittel (3/5) Die Zeitersparnis ist unmittelbar messbar. Der Renditeeffekt aus optimierten Anlagen ist berechenbarer als bei vielen anderen KI-Anwendungsfällen, aber er hängt stark vom Zinsniveau und vom Volumen des freigesetzten Kapitals ab. Wer in einem Niedrigzinsumfeld implementiert, sieht geringere absolute Effekte als wer im Hochzinsumfeld arbeitet. Der ROI ist real, aber kontextabhängig.

Skalierbarkeit, niedrig (2/5) Das ist der entscheidende Unterschied zum generischen KI-Anwendungsfall: Treasury-Modelle sind institutionsspezifisch. Jede neue Entity, Währung oder Bankverbindung erfordert neue EBICS-Verbindungen, angepasste Datenmapping-Regeln und Modell-Neukalibrierung. Wer drei neue Tochtergesellschaften bekommt, muss das System entsprechend erweitern, das ist Integrationsaufwand, kein einfaches „hinzufügen”. Unter den finanziellen KI-Anwendungsfällen in dieser Kategorie ist die Skalierbarkeit damit vergleichsweise schwach.

Richtwerte, stark abhängig von Unternehmensgröße, Anzahl der Bankverbindungen und der Qualität vorhandener Finanzdaten.

Was das KI-System im Treasury konkret macht

Das Herzstück ist kein Chatbot und kein generativer Textassistent. Es ist eine Predictive Analytics-Pipeline, die drei Aufgaben übernimmt:

1. Datenaggregation und -normalisierung Das System liest täglich automatisch alle Bankkontoauszüge ein, über EBICS (Standard im deutschsprachigen Raum), SWIFT-MT940-Dateien oder ISO-20022-camt.053-Nachrichten (der MT940-Nachfolger). Diese Nachrichten haben unterschiedliche Feldstrukturen je nach Bank und Konfiguration. Das System normalisiert sie in ein einheitliches Format, gleicht Buchungsposten mit dem ERP ab und erstellt einen tagesaktuellen konsolidierten Kassenspiegel.

2. Cashflow-Prognose mit Zeitreihenmodellen Auf dieser Datenbasis trainiert das Modell mit historischen Cashflow-Mustern, typischerweise 24–36 Monate rückwärts. Es erkennt Zahlungsmuster: wann bestimmte Kunden üblicherweise zahlen, wie sich das Zahlungsverhalten in Q4 gegenüber Q2 unterscheidet, welche Lieferanten früher als vertraglich vereinbart bezahlen. Für den Prognosehorizont von 30 bis 90 Tagen werden diese Muster mit offenen Posten aus dem ERP, bekannten Fälligkeiten und externen Faktoren kombiniert.

3. Empfehlungsformulierung mit LLM-Unterstützung Das Forecasting-Modell liefert Zahlen. Ein nachgelagerter LLM-Layer übersetzt diese Zahlen in lesbare Treasury-Berichte und Handlungsempfehlungen: „Für den Zeitraum 15.–22. Juni ergibt sich eine voraussichtliche Liquiditätslücke von 2,3 Mio. EUR, die durch folgende Maßnahmen gedeckt werden kann…” Dieser Layer ist kein autonomer Agent, er formuliert, was das Rechenmodell gefunden hat.

Was das System nicht kann

Es kann keine externen Schocks antizipieren. Das COVID-Quartal März 2020 oder der erste Monat nach Russlands Einmarsch in die Ukraine hätte kein auf historischen Mustern trainiertes Modell korrekt prognostiziert. In strukturellen Brüchen, Bankenstress, Lieferkettencrash, plötzliche Zinswende, versagen alle Zeitreihenmodelle. Der Mensch muss bei Krisen-Overrides im Cockpit sitzen.

Integrations-Realität: EBICS, SWIFT und MT940

Das ist der Teil, der in den Verkaufspräsentationen oft weniger als fünf Minuten bekommt und in der Projektplanung dann sechs Wochen frisst.

EBICS (Electronic Banking Internet Communication Standard) ist das dominierende Protokoll für den Bankdatenaustausch in Deutschland, Österreich, der Schweiz und Frankreich. Jede Bank, mit der dein Unternehmen via EBICS kommuniziert, muss einen separaten EBICS-Vertrag abschließen, Zugangsdaten einrichten und die Verbindung freischalten. Für zehn Bankverbindungen bedeutet das zehn parallele Abstimmungsprozesse, mit Banken, die unterschiedlich schnell reagieren. Realistische Erfahrungswerte: 3–6 Wochen je Bank, parallel bearbeitet 6–10 Wochen Gesamtlaufzeit.

MT940 ist das klassische Kontoauszugsformat, das seit Jahrzehnten im Einsatz ist. Problem: MT940 hat kein fixes Feldmapping, der Verwendungszweck landet in unterschiedlichen Subfeldern je nach Bank, der strukturierte Datentransfer (SEPA-Datei) ist mal dabei, mal nicht. Das bedeutet: Für jede Bank braucht das Treasury-System eine eigene Mapping-Konfiguration. Wer mit Kyriba, SAP S/4HANA Treasury oder einem ähnlichen TMS arbeitet, hat Mapping-Templates, aber das initiale Setup ist dennoch Projektarbeit.

ISO 20022 / camt.053 ist der MT940-Nachfolger, seit November 2022 verbindlich im europäischen SEPA-Zahlungsverkehr. Die Migration läuft: Viele Banken senden noch parallel MT940 und camt.053. Wer jetzt ein TMS implementiert, sollte ausschließlich camt.053 konfigurieren und MT940 nur noch als Fallback betreiben, die SWIFT-Deadline für die vollständige MT940-Abschaltung rückt näher.

SWIFT (für internationale Transaktionen) läuft parallel zu EBICS, typisch für Devisen, Akkreditive und internationale Transaktionen. SWIFT Business Connect über einen Service Bureau oder direkten SWIFT-Zugang hinzuzufügen ist ein weiteres Projekt für sich.

Was das für dein Projekt bedeutet: Plane die Bankanbindungsphase als eigenständiges Projektpaket mit eigenem Zeitplan, eigenen Eskalationswegen zu den Banken und einem eigenen Budget-Puffer von 20–30 Prozent. Projekte scheitern hier nicht an der KI, sondern daran, dass Bank Nr. 7 drei Monate für die EBICS-Freischaltung braucht.

FP&A und Treasury: Was hier wirklich gemeint ist

In vielen Unternehmen unter 500 Mitarbeitenden sitzt eine Person in beiden Rollen gleichzeitig, das ist der Ausgangspunkt für die häufigste Verwechslung.

FP&A (Financial Planning & Analysis) plant auf einer Zeitachse von 12–18 Monaten. Die Fragen dort lauten: Was kostet das Headcount-Wachstum nächstes Jahr? Wie entwickelt sich die EBITDA-Marge? Die Liquidität ist hier ein abgeleitetes Ergebnis der P&L-Planung, Cashflow ergibt sich indirekt aus Ergebnis, Investitionen und Veränderung des Working Capitals.

Treasury arbeitet auf einem Horizont von heute bis 90 Tagen. Die Fragen lauten: Haben wir übermorgen die Mittel für die Lohnzahlung? Wann genau landet die Forderung auf dem Konto? Können wir das kurzfristige Geld für drei Wochen anlegen oder brauchen wir es für die Steuervorauszahlung? Die Datenbasis ist direkt: Bankkonten, EBICS-Feeds, offene-Posten-Listen.

KI-gestützte Liquiditätsplanung ist ein Treasury-Werkzeug, kein FP&A-Werkzeug. Tools wie Anaplan oder Workday Adaptive Planning sind exzellente FP&A-Plattformen, aber ihre Stärke liegt in der Jahresplanung und der Verknüpfung von Finance, Sales und HR, nicht im täglichen Cash-Positioning auf Basis von Kontoauszügen. Wer versucht, die 30-Tage-Liquiditätsprognose in einem FP&A-Tool zu bauen, kämpft gegen das falsche Werkzeug.

Die richtige Trennung: FP&A-Plattform für Budget, Forecast und Szenarioanalyse über Quartale. Treasury-System für täglichen Cash-Spiegel, LCR-Berechnung und kurzfristige Anlageoptimierung. Beide brauchen konsistente Daten aus demselben ERP, aber sie lösen fundamental verschiedene Probleme.

Konkrete Werkzeuge, was wann passt

Agicap, wenn ihr KMU seid und zuerst lernen wollt Marktführer im europäischen KMU-Segment, deutsche Niederlassung, EU-Hosting. Bindet Bankkonten via PSD2 an, integriert offene Posten aus DATEV oder Lexware und baut einen rollierenden 13-Wochen-Forecast. KI-Komponente ist augmentierend, kein echter Prognosemotor, aber für Unternehmen bis 30 Mio. EUR Umsatz mit wenigen Bankverbindungen realistisch genug. Jahreskosten: berichtete 3.000–8.000 EUR für KMU. Einstieg möglich ohne EBICS-Kompetenz.

Tidely, wenn ihr einen deutschen Anbieter mit transparentem Pricing wollt Münchner Anbieter, entwickelt für KMU. PSD2-Anbindung, KI-gestützte Kategorisierung, rollierende Prognose. Starter ab 45 EUR/Monat. Kein EBICS, kein Multi-Entity-Consolidation, aber transparent kalkulierbar und für einfache Strukturen vollständig ausreichend.

Kyriba, wenn ihr Multi-Banking, Multi-Entity und LCR-Compliance braucht Führendes Cloud-TMS für mittelgroße bis große Unternehmen. EBICS, SWIFT, H2H-Anbindung zu über 9.900 Banken weltweit, integriertes Cash AI-Modul, LCR/NSFR-Reporting direkt in der Plattform. Euromoney Best TMS 2025. Jahreskosten typisch 50.000–150.000 USD bei Mid-Market (10–50 Entities); Implementierung 5–9 Monate mit Partnerunterstützung. Für KMU überdimensioniert, für mittlere und größere Unternehmen die vollständigste Lösung.

SAP S/4HANA Treasury, wenn ihr bereits SAP habt Wer SAP S/4HANA als ERP betreibt, hat das Treasury- und Cash-Management-Modul lizenziert oder kann es nachlizenzieren. Vorteil: keine separate Datenpipeline, alle Buchungsdaten sind direkt verfügbar; EBICS-Anbindung über SAP Multi-Bank Connectivity. Nachteil: Implementierung und Customizing durch SAP-Berater sind teuer (Tagessätze 1.500–2.500 EUR/Tag). Sinnvoll, wenn ohnehin SAP-Know-how intern vorhanden ist.

Custom ML-Modell mit Python, wenn ihr ein starkes Data-Science-Team habt Für Unternehmen mit vorhandener Data-Engineering-Infrastruktur: EBICS-Daten direkt in eine Zeitreihenpipeline laden, Machine Learning-Modell (Prophet, LSTM, XGBoost) trainieren, Outputs über ein internes Dashboard visualisieren. Höchste Flexibilität und niedrigste Lizenzkosten, höchster initialer Aufwand und kontinuierlicher Betriebsaufwand. Sinnvoll nur, wenn das Team diese Kompetenz bereits hat oder aufbauen will.

Zusammenfassung: Wann welcher Ansatz

• Unter 30 Mio. EUR Umsatz, wenige Bankverbindungen → Agicap oder Tidely
• SAP-Bestandsnutzer → SAP S/4HANA Treasury-Modul
• Multi-Entity, Multi-Currency, LCR-Compliance → Kyriba
• Eigene Dateninfrastruktur und ML-Team → Custom-Lösung mit Predictive Analytics-Stack

Datenschutz und Datenhaltung

Treasury-Daten gehören zu den sensibelsten Finanzdaten eines Unternehmens. Kontoauszüge enthalten Informationen über Geschäftspartner, Gehälter, Steuerverbindlichkeiten und strategische Investitionen. Die DSGVO greift hier an zwei Punkten:

Personenbezogene Daten in Bankbewegungen: Gehaltszahlungen enthalten Namen und Kontonummern von Mitarbeitenden. Lieferantenzahlungen können personenbezogene Daten natürlicher Personen enthalten. Wer diese Daten an ein Cloud-System übergibt, muss einen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO abschließen.

DSGVO-Status der empfohlenen Tools:

• Agicap: EU-Hosting (Frankreich), AVV ohne Diskussion, PSD2-Zugang read-only, konform für normale Nutzung
• Tidely: Datenhaltung in Deutschland, deutschsprachiger Support, AVV verfügbar
• Kyriba: EU-Rechenzentrum aktivierbar, AVV nach Art. 28 DSGVO, Audit-Logs vollständig, für regulierte Unternehmen geeignet
• SAP S/4HANA: Je nach Hosting-Modell (On-Premise, SAP Rise Private Cloud) vollständige Kontrolle über Datenhaltung; AVV als Standardbestandteil

Regulatorische Besonderheiten für Banken: Kreditinstitute unter BaFin-Aufsicht unterliegen darüber hinaus den Anforderungen der MaRisk (AT 7.2) und DORA. KI-Modelle in systemkritischen Prozessen, und Liquiditätsprognosen können systemkritisch sein, müssen dokumentiert, validiert und auditierbar sein. Die BaFin hat in ihrer Veröffentlichung zu KI im Finanzsektor (2024) klargestellt: Modellentscheidungen müssen nachvollziehbar bleiben. Ein Black-Box-Modell, das die LCR-Prognose erstellt, ohne erklärbare Entscheidungslogik, ist für regulierte Banken nicht akzeptabel.

Was es kostet, realistisch gerechnet

Einmalige Projektkosten

• Agicap/Tidely (KMU): Kein separates Implementierungsprojekt. Setup 1–3 Wochen intern. Jahresvertrag 3.000–10.000 EUR.
• Kyriba Mid-Market (10–50 Entities): Implementierungsprojekt mit Partner 80.000–200.000 EUR; Jahreslizenz 50.000–150.000 USD; Gesamtprojektbudget Jahr 1: 130.000–350.000 EUR.
• SAP S/4HANA Treasury-Modul (für SAP-Bestandskunden): Customizing und Rollout mit SAP-Berater typisch 150–400 EUR/Tag × 60–120 Beratertage = 90.000–480.000 EUR.
• Custom ML-Lösung: Data Engineering + Modellentwicklung 3–6 Monate × 1 Data Engineer (interne Kosten oder Freelancer 700–900 EUR/Tag) = 60.000–150.000 EUR Erstaufwand.

Laufende Kosten (monatlich)

• Agicap: 250–670 EUR/Monat (3.000–8.000 EUR/Jahr)
• Tidely: 45–215 EUR/Monat je nach Tarif
• Kyriba: 4.000–12.500 USD/Monat je nach Modulumfang
• Custom ML: Infrastruktur + Wartung intern, typisch 1.000–3.000 EUR/Monat

Wie du den Nutzen tatsächlich misst Der ehrlichste Beweis ist kein theoretisches Einsparungsmodell, es sind zwei konkrete Kennzahlen:

1. Täglicher Cash-Positioning-Aufwand vor vs. nach Einführung (Stunden/Tag, einfach zu messen)
2. Durchschnittliche freie Liquidität auf Kontokorrentkonten vs. im Durchschnitt angelegte Geldmarktposition (belegt, ob das freigesetzte Kapital tatsächlich arbeitet)

Was du dagegen rechnen kannst: 2 Stunden täglich eingesparter Aufwand bei einem Senior-Treasury-Analysten (Bruttostundensatz ca. 50–75 EUR) sind 500–750 EUR täglich oder 100.000–150.000 EUR im Jahr. Das entspricht, bei Kyriba, in etwa dem Jahresvolumen der Lizenz. Was tatsächlich den ROI sichert, ist die Anlageoptimierung: 1 Million EUR freigelegtes Working Capital, das zu 3,5 % auf einem Tagesgeldkonto liegt statt ungeplant auf dem Kontokorrent, macht 35.000 EUR Mehrertrag im Jahr.

Drei typische Einstiegsfehler

1. Das Datenpipeline-Problem unterschätzen. In Verkaufspräsentationen kostet die Bankanbindung fünf Minuten Aufmerksamkeit. Im Projekt kostet sie sechs Wochen. EBICS-Freischaltungen bei Banken scheitern an abgelaufenen Zertifikaten, an internen Genehmigungsprozessen, an veralteten Formatversionen oder schlicht daran, dass die zuständige Ansprechperson bei der Bank im Urlaub ist. Wer die Bankanbindungsphase im Projektplan mit zwei Wochen ansetzt, gerät zwangsläufig in Verzug. Realistische Pufferplanung: 8–12 Wochen für fünf bis zehn Bankverbindungen, mit expliziten Eskalationswegen.

2. Das Modell einmal trainieren und dann sich selbst überlassen. Ein Cashflow-Prognosemodell, das auf Daten aus 2022–2024 trainiert wurde und im Jahr 2026 ohne Nachkalibrierung läuft, gibt 2026 immer noch Prognosen aus dem Jahr 2022 heraus, nur mit neuem Interface. Zinssätze ändern sich. Zahlungsgewohnheiten von Kunden verschieben sich. Neue Lieferantenverträge verändern Fälligkeitsmuster. banking.vision hat diesen Punkt in ihrer Analyse (2025) explizit dokumentiert: Treasury-KI braucht „continuous oversight, model validation, and governance control”, nicht weil die Software schlecht ist, sondern weil sich die Welt ändert. Plan: Quartalsweise Forecast-vs.-Ist-Überprüfung, jährliche Modell-Rekalibrierung, explizite Verantwortung für den Modellbetrieb in einer namentlich benannten Person.

3. FP&A-Werkzeuge für Treasury-Aufgaben nutzen (oder umgekehrt). Wer versucht, die tägliche Liquiditätsprognose in einer FP&A-Plattform wie Anaplan oder Workday Adaptive Planning zu bauen, baut das falsche Tool für die Aufgabe aus. Diese Plattformen glänzen bei rollierenden Jahresplänen mit Treiberbaumlogik, nicht bei tagesaktuellem Cash-Positioning auf Basis von EBICS-Feeds. Das Ergebnis: monatelange Anpassungsversuche, ein Modell, das funktioniert, aber täglich manuelle Korrekturen braucht, und ein Projektteam, das sich fragt, warum es so kompliziert ist. Treasury ist eine eigene Disziplin mit eigenen Werkzeugen.

Was mit der Einführung wirklich passiert, und was nicht

Die technische Seite des Projekts ist der handhabbare Teil. Das Schwierigere ist die organisatorische Seite.

Das „Goldene-Excel”-Problem. Fast jede Treasury-Abteilung hat ein Spreadsheet, das über Jahre von einer Person gebaut wurde und die eigentliche Steuerungslogik enthält: das Modell, das die CFO-Reportings erzeugt, das jede Ausnahme kennt und jeden Kommentar trägt. Die Person, die dieses Excel gebaut hat, wird das neue System skeptisch betrachten, nicht aus Böswilligkeit, sondern weil sie das Rückgrat des Prozesses kennt und dem Neuen noch nicht traut. Was hilft: Diese Person in die Modellkonfiguration des neuen Systems einbinden. Ihre Logik explizit in das Mapping und die Kalibrierung übersetzen. Sie bekommt dadurch ein besseres Werkzeug, ohne das Gefühl, ersetzt zu werden.

Die „Prognose-Haftungs”-Frage. Wenn das KI-System eine Liquiditätslücke vorhersagt und die Treasury-Leitung auf dieser Basis eine Refinanzierungsentscheidung trifft, und die Prognose falsch war, wer trägt die Verantwortung? Das ist keine hypothetische Frage. Kläre vor dem Go-Live: Welche Entscheidungen darf das System alleine antreiben, welche brauchen menschliche Bestätigung? Die Antwort für regulierte Institute lautet fast immer: Alle Entscheidungen über definierten Schwellenwerten brauchen Human-Approval. Das System empfiehlt. Menschen entscheiden.

Widerstand aus der Fachabteilung. Treasury-Professionals haben oft jahrelange Erfahrung mit den Eigenheiten ihrer Banken, ihrer Buchhaltung und ihres Geschäftsmodells. Sie wissen, dass der Konzernkunde immer in der zweiten Woche des Monats zahlt, nicht wann er zahlen soll. Dieses Wissen ist nicht in den EBICS-Daten, es ist in Köpfen. Der Rollout muss dieses Wissen explizit erheben und als Kalibrierungsinput in das Modell einarbeiten. Wer das überspringt, bekommt ein Modell, das statistisch korrekt ist und in der Praxis von niemandem ernst genommen wird.

Basel III, DORA und was das mit KI zu tun hat

Für Kreditinstitute unter BaFin-Aufsicht gilt über die allgemeine DSGVO-Konformität hinaus ein erweitertes regulatorisches Korsett.

Basel III LCR/NSFR: Die Liquidity Coverage Ratio verlangt, dass Banken täglich nachweisen, dass ihr Bestand an hochwertigen liquiden Aktiva (HQLA) den netto-Abfluss über einen 30-Tage-Stresshorizont abdeckt. KI-Systeme können diese Berechnung automatisieren und in Echtzeit überwachen, aber die Berechnungslogik muss revisionssicher dokumentiert sein. Keine Black-Box-Ausgabe, die nur das Ergebnis zeigt.

DORA (Digital Operational Resilience Act): Seit Januar 2025 müssen alle beaufsichtigten Finanzentitäten die DORA-Anforderungen erfüllen. Für KI-gestützte Treasury-Systeme relevant: IKT-Drittanbieter-Risikomanagement (Art. 28 DORA), Testen der Operational Resilience und Dokumentation kritischer Funktionen. Kyriba und andere TMS-Anbieter sind in der Regel bereits als kritische IKT-Drittanbieter eingestuft oder müssen bei Einsatz so behandelt werden.

MaRisk AT 7.2 (Modell-Governance): Modelle, die für Steuerungsentscheidungen eingesetzt werden, müssen nach MaRisk validiert, dokumentiert und regelmäßig überprüft werden. Ein KI-Cashflow-Modell, das die kurzfristige Refinanzierungsentscheidung beeinflusst, ist ein solches Modell. Die Bank braucht eine Modell-Governance-Struktur: Wer validiert? Wie oft? Was sind die Limits, innerhalb derer das Modell autonom operiert?

Für Nicht-Banken (Industrieunternehmen, Holdings) entfällt der Großteil dieser regulatorischen Anforderungen, hier gilt vor allem DSGVO und ggf. das HGB-Gebot der ordnungsgemäßen Buchführung.

Realistischer Zeitplan mit Risikohinweisen

Gesamtlaufzeit bis produktiver Betrieb: 5–9 Monate.

Häufige Einwände, und was dahintersteckt

„Unsere Bankverbindungen sind zu komplex für ein System.” Kyriba arbeitet mit über 9.900 Banken weltweit, SAP Multi-Bank Connectivity unterstützt EBICS, SWIFT und H2H parallel. Was selten zu komplex ist: die Bankverbindungen an sich. Was tatsächlich komplex ist: das initiale Setup. Der Einwand ist oft eine vorweggenommene Annahme, dass das Projekt zu aufwändig ist, was in der Implementierungsphase real sein kann. Wer mit einer oder zwei der einfachsten Bankverbindungen startet und schrittweise erweitert, kommt weiter als wer den Big-Bang-Ansatz plant.

„Wir haben das schon gut in Excel.” Wahrscheinlich stimmt das. Excel-Modelle im Treasury sind oft sehr ausgereift, jahrelang kalibriert, mit allen Ausnahmen und Eigenheiten versehen. Das Problem ist nicht das Modell selbst, sondern was der manuelle Aufwand kostet: Zeit für die Datenpflege, die nicht für Steuerungsaufgaben bleibt. Wenn der tägliche Zusammentrag weniger als eine Stunde dauert und das Unternehmen unter drei Bankverbindungen hat, ist die Excel-Lösung oft tatsächlich die bessere Wahl. Wenn es zwei bis vier Stunden täglich kostet, ist das eine andere Rechnung.

„KI wird im Stressfall versagen.” Das ist kein Einwand, das ist eine korrekte Einschätzung, zumindest teilweise. Zeitreihenmodelle versagen in strukturellen Brüchen. Der Einwand übersieht aber, dass der bestehende manuelle Prozess in Stressszenarien ebenfalls nicht besser ist, er ist nur mit mehr manuellem Aufwand verbunden. Das Ziel ist nicht, das menschliche Urteil durch KI zu ersetzen, sondern den täglichen Grundbetrieb zu automatisieren, sodass die Treasury-Person im Stressfall Zeit und Kapazität hat, das Notfallmanagement zu übernehmen, statt gerade dann besonders viel manuellen Aufwand zu haben.

Woran du merkst, dass das zu dir passt

• Du hast mindestens fünf Bankverbindungen in mindestens zwei Ländern und täglich zwei oder mehr Stunden Aufwand für den Kassenspiegel
• Das tägliche Cash-Positioning verhindert Steuerungsaufgaben, dein Team berichtet mehr als es steuert
• Du brauchst LCR/NSFR-Reporting als regulierte Bank oder bist freiwillig einer ähnlichen Liquiditätsberichtspflicht unterworfen
• Deine 30-Tage-Prognose ist aktuell eine Schätzung, keine datengetriebene Kalkulation
• Du hast mindestens eine namentlich benannte Treasury-Verantwortliche:n mit ausreichend Zeit für den Modellbetrieb

Wann es sich (noch) nicht lohnt, drei harte Ausschlusskriterien:

1. Unter 50 Mio. EUR Jahresumsatz oder weniger als fünf Bankverbindungen. Das Verhältnis von Implementierungsaufwand zu Nutzen stimmt nicht. Für diese Unternehmen reicht ein Tool wie Agicap oder Tidely ohne KI-Anspruch vollständig aus, oder schlicht eine gut gepflegte Excel-Datei mit automatisiertem Bankdaten-Import.

2. Kein laufendes TMS oder ERP mit strukturierten Finanzdaten. Wer seine Buchhaltung in einer Kombination aus Excel, Papierbelegen und einem Steuerberater-System führt, hat keine valide Datenbasis für ein ML-Prognosemodell. Das System braucht 24–36 Monate strukturierte Transaktionsdaten in maschinenlesbarem Format, ohne diese Basis produziert das Modell statistischen Rauschen, keine Prognosen.

3. Keine namentlich benannte Person mit Ownership für den Modellbetrieb. Ein Treasury-KI-System, das eingerichtet und dann sich selbst überlassen wird, driftet. Zahlungsmuster ändern sich, neue Kunden haben andere Zahlungsgewohnheiten, Zinssätze verschieben sich. Ohne jemanden, der quartalsweise Forecast vs. Ist auswertet und das Modell nachjustiert, hat das System nach 18 Monaten systematisch fehlerhafte Prognosen, und niemand merkt es, weil die Ausgaben professionell aussehen.

Das kannst du heute noch tun

Bevor du eine Demo buchst oder ein Budget freigibst: Verbring eine Stunde damit, deinen aktuellen Cash-Positioning-Prozess aufzuschreiben. Wie viele Bankverbindungen hast du? Wie lange dauert der tägliche Zusammentrag? Wo kommen die Daten her? Welche Prognosen erstellst du, auf welcher Basis, für welchen Horizont?

Das ergibt zwei Dinge: eine ehrliche Einschätzung, ob das Schmerzpotenzial groß genug für ein Projekt ist, und eine Grundlage für jedes erste Gespräch mit einem Anbieter.

Für den nächsten Schritt: Lass das folgende Prompt-Template von ChatGPT oder Claude eine erste strukturierte Lückenanalyse deines aktuellen Treasury-Prozesses durchführen. Du bekommst keine sofort umsetzbare Lösung, aber eine ehrliche Selbsteinschätzung als Ausgangspunkt.

Quellen & Methodik

• KPMG “KI im Corporate Treasury” (2025): kpmg.com/de. Umfrage unter deutschen Treasury-Teams; 63 % Effizienz als primärer Nutzen; Bosch-Fallbeispiel mit 30 % Pufferreduktion.
• U.S. Bank + Kyriba “Liquidity Manager” Launch (November 2025): ir.usbank.com. Produktlaunch mit Kyriba-Technologie für Mid-Market-Firmen; konkrete Produktdaten zu Kyriba Cash AI.
• banking.vision “Treasury AI Is Not Trading AI” (2025): banking.vision. Architekturanalyse: Treasury-KI vs. Trading-KI; Governance-Anforderungen; Argument für menschliche Oversight bei Bilanzsystem-relevanten Entscheidungen.
• Capgemini World Payments Report: Mehr als 60 % der Banken ohne Echtzeit-Cash-Forecasting; über 50 % noch manuelle Abstimmung. Quelle für Status quo der Branche.
• Vendr Kyriba Pricing (2026): vendr.com/marketplace/kyriba. Anonymisierte Vertragsdaten; Mid-Market Jahreskosten 50.000–150.000 USD.
• EBICS-Standarddokumentation: ebics.org. Protokollspezifikation, Versionsstand 3.0, Verbreitung in DACH/FR.
• BaFin Fachartikel “KI bei Banken und Versicherern: Automatisch fair?” (2024): Anforderungen an Modellnachvollziehbarkeit und Governance bei KI-Einsatz in regulierten Instituten.
• Preise Agicap und Tidely: Basierend auf öffentlich zugänglichen Nutzerbewertungen auf Capterra, G2 und OMR (Stand Mai 2026) sowie veröffentlichten Tarifinformationen (Tidely).

Willst du einschätzen, ob der Aufwand für dein Unternehmen gerechtfertigt ist, welche Bankverbindungen tatsächlich EBICS-fähig sind und wie lange euer Implementierungsprojekt realistisch dauern würde? Das klären wir gerne in einem kurzen Gespräch.