Zahlungsverkehr unter Druck – Wer jetzt nicht steuert, wird gesteuert

Vor ein paar Wochen hat mir ein Architekt bei einer mittelgroßen Bank seinen Abhängigkeitsgraphen gezeigt. Keinen schönen – einen ehrlichen. Ein Wiki-Export, ergänzt um handschriftliche Notizen auf ausgedruckten Seiten. Was man darauf sehen konnte: dutzende COBOL-Module, verkettet über Batch-Jobs, von denen die meisten seit fünfzehn Jahren nicht mehr sauber dokumentiert worden sind. Irgendwo in dieser Kette, so viel war klar, sitzt auch ein SEPA-Konverter. Wo genau, konnte er mir nicht sagen. Der Entwickler, der das wusste, ist vor zwei Jahren in Rente gegangen.

Ich erzähle das, weil solche Situationen kein Sonderfall sind. Wer regelmäßig in Zahlungsverkehrsabteilungen deutscher Banken unterwegs ist, kennt Varianten davon zur Genüge. Und wäre das Umfeld stabil, könnte man damit leben. Nur ist es das nicht.

Banken am Limit: Veraltete Systeme, schwindendes Wissen

McKinsey beziffert die operativen Kosten für Zahlungsverkehr auf 30 bis 40 Prozent einer typischen Universalbank. BCG schätzt, dass über 60 Prozent der IT-Budgets in „Run the Bank" gebunden sind, mit regulatorisch verpflichtenden Änderungen sogar bis zu 70 Prozent. Das ist der Spielraum, der für echte Transformation übrig bleibt – und in den drängt gerade alles gleichzeitig rein.

Instant Payments mit 24/7-Verfügbarkeit und Zehn-Sekunden-Abwicklung. ISO 20022 mit Mapping, Enrichment, jahrelangem Parallelbetrieb. DORA mit Resilienz als Vorstandspflicht. PSD3/PSR mit verschärfter Betrugshaftung. Am Horizont dann noch FiDA, der Digitale Euro, die EUDI-Wallet. Und all das greift in dieselben Systeme ein – Payment Engine, Core Banking, Fraud, Sanktionsscreening, Kanäle, Reporting. Es addiert sich nicht. Es multipliziert sich.

Wobei man sich klarmachen muss, was allein schon Instant Payments in der Praxis bedeutet: Echtzeit-Scoring im Sub-Sekunden-Bereich, Fraud-Monitoring rund um die Uhr, Pre-Funding in TIPS auch nachts und am Wochenende, Verification of Payee über alle Kanäle. Das trifft auf Architekturen, die für Nacht-Batches konzipiert wurden. Für Settlement-Fenster, die es bald schlicht nicht mehr gibt.

Wer an solchen Systemen etwas ändern will, steht vor einem Problem, das weniger mit der Technik zu tun hat als mit dem Wissen über sie oder genauer: mit dem Fehlen dieses Wissens.

Nicht COBOL ist das Problem, sondern fehlendes Systemwissen

In den meisten Diskussionen, die ich dazu führe, geht es reflexartig um COBOL, um Mainframe, um Batch. Aber mal ehrlich: COBOL tut, was es soll. Die Sprache und die Systeme laufen seit Jahrzehnten zuverlässig.

Das eigentliche Risiko sieht anders aus. Es geht um fehlendes Systemwissen in einer Umgebung, die sich keine Fehler leisten kann. Converter-Logik, die bei jedem SEPA-Release manuell angefasst wird – von einem Team, das mit jedem Jahr kleiner wird. Gebührenmodule mit Sonderroutinen, die irgendwann mal als Workaround entstanden sind und die heute niemand anrühren will, weil niemand sicher weiß, was sonst noch daran hängt. Batch-Abhängigkeiten, die erst auffallen, wenn etwas schiefgeht.

Die Zahlen dazu sind ernüchternd. Pelican schätzt, dass Ausnahmebearbeitung 42 Prozent der Zahlungsabwicklungskosten ausmacht. Die globale STP-Quote im Cross-Border-Bereich lag 2023 bei 26 Prozent – drei von vier Transaktionen brauchen manuelle Nacharbeit. IDC rechnet damit, dass die Betriebs- und Wartungskosten für Legacy-Zahlungssysteme weltweit bis 2028 auf 57 Milliarden Dollar steigen werden. Das hat mit der Programmiersprache wenig zu tun und mit fehlender Steuerung viel.

Wenn das Fundament zur Blackbox wird

„Wir modernisieren doch bereits." Ich höre ihn regelmäßig, und meistens stimmt er sogar. Viele Häuser haben Payment-Hub-Programme aufgesetzt, arbeiten mit equens oder PPI, migrieren Richtung Cloud, setzen ISO-20022-Projekte um. Alles richtig.

Was mich dabei umtreibt, ist eine andere Frage: Weiß die Bank eigentlich, was in ihren Altsystemen passiert – wirklich im Detail, nicht auf Foliensatz-Niveau –, bevor sie Entscheidungen trifft?

Meiner Erfahrung nach: oft nicht. Ich kenne Institute, die SEPA-Converter in Auftrag geben, ohne die abhängigen Batch-Jobs zu überblicken. Die Payment Engines evaluieren, ohne einen vollständigen Abhängigkeitsgraphen der Bestandslandschaft zu haben. Die DORA-Programme starten, ohne beziffern zu können, auf wie wenigen Köpfen welches kritische Wissen liegt. Das ist übrigens kein Vorwurf an irgendjemanden – es ist die logische Konsequenz gewachsener Landschaften, in denen über zwanzig Jahre lang funktional erweitert wurde, ohne die Dokumentation mitzuziehen.

Und es betrifft keineswegs nur die großen Adressen. Jedes Institut, das Host-Systeme im Zahlungsverkehr betreibt, steht vor dieser Frage – die mittelgroße Privatbank genauso wie das Spezialinstitut oder ein Haus, das Teile an ein Rechenzentrum ausgelagert hat, aber die Fachlogik weiter selbst verantwortet. Es geht nicht um Bilanzsumme, es geht darum, ob eine fachlich bewertete Sicht auf Abhängigkeiten und Impact-Pfade existiert.

Parallel dazu verengt sich der ökonomische Spielraum weiter: Account-to-Account-Zahlungen umgehen die Kartensysteme – zu Transaktionskosten von 0,1 bis 0,5 Prozent statt 0,3 bis 3 Prozent bei Karten. Wer gleichzeitig Legacy-Kartensysteme, Clearing und Instant-Rails betreibt, ohne zu konsolidieren, sitzt in der Zange.

Wem das abstrakt vorkommt: TSB in Großbritannien, 2018. Acht Monate Störungen nach einer Core-Migration. 400 Millionen Pfund Kosten. 48,65 Millionen Pfund Aufsichtsstrafe. Das Problem war nicht die neue Plattform, sondern dass man die alte nicht verstanden hatte.

KI im Maschinenraum: Wo sie hilft und wo nicht

Die Frage kommt jedes Mal: „Und wo setzen wir da KI ein?"

Meine Antwort fällt regelmäßig weniger begeistert aus, als mein Gegenüber es sich erhofft.

Generative KI kann bei der Dokumentation helfen, keine Frage. COBOL-Module zusammenfassen, Kommentare erzeugen, Geschäftslogik in natürlicher Sprache beschreiben. Wenn sich jemand in eine unbekannte Codebase einarbeiten muss, spart das tatsächlich Wochen. Auch bei der Testfall-Generierung oder beim Aufspüren potenziell toter Codepfade leistet sie brauchbare Dienste.

Wo es heikel wird: bei der vollständigen Analyse von Abhängigkeiten. Ein Large Language Model kann eine COBOL-Routine plausibel beschreiben, ob es dabei aber jeden Aufrufpfad, jede JCL-Verkettung und jede Seiteneffekt-Kette tatsächlich korrekt erfasst hat, weiß niemand. Und in einer Umgebung, in der ein übersehener Batch-Job Fehlbuchungen in Millionenhöhe auslösen kann, reicht „wahrscheinlich richtig" eben nicht. Da braucht man deterministische Parser, die Zeile für Zeile durch den Code gehen – nicht Wahrscheinlichkeitsmodelle, die in fünf Prozent der Fälle halluzinieren.

Für die Code-Konvertierung – COBOL nach Java etwa – gilt im Grunde dasselbe. Deterministisch, Modul für Modul, nachweisbar durch Regression Testing: das funktioniert. KI als Ergänzung, meinetwegen. Aber als primäres Werkzeug in kritischer Zahlungsinfrastruktur ist sie heute schlicht nicht belastbar genug.

Worauf es ankommt, ist eine nüchterne Unterscheidung: Wo bringt KI echten Zeitgewinn, und wo erzeugt sie ein neues Risiko, das dem alten zum Verwechseln ähnlich sieht?

Warum Legacy Control eine eigene Disziplin ist

Was im Markt fehlt und das sage ich nach vielen Jahren in diesem Umfeld, ist nicht das nächste Replatforming-Projekt. Auch kein besserer Code-Parser. Und schon gar kein Big Bang.

Was fehlt, ist eine Steuerungsdisziplin. Die Fähigkeit, vor jeder Entscheidung im Zahlungsverkehr zu wissen, was man anfasst, was daran hängt und was sich abschalten lässt.

Klingt trivial? Die Praxis zeigt etwas anderes. Die meisten Analysewerkzeuge liefern technische Fakten – Aufrufgraphen, Datenflüsse, Komplexitätsmetriken. Was sie nicht liefern, ist die fachliche Einordnung. Kein Code-Parser der Welt sagt einem: „Dieses Modul ist regulatorisch kritisch, weil da Ihr SEPA-Credit-Konverter drinsteckt." Oder: „Dieser Batch hängt am Sanktionsscreening und ist damit Instant-relevant." Oder – und das ist unter DORA besonders brisant: „Das Wissen über diese Logik liegt bei zwei Leuten, beide über 60."

Genau diese Übersetzungsleistung – technische Analyse plus fachliche Bewertung im Zahlungsverkehr – ist das, was wir bei adesso und KIWI Consulting unter „Payment Legacy Control" verstehen. Die Fähigkeit, vor jeder regulatorischen oder technologischen Entscheidung zu wissen, was sie im Bestand auslöst.

Was das in der Praxis heißt

Konkret verbinden wir die automatisierte Analyse der adesso transformer Plattform, die den gesamten Host-Code deterministisch parst, COBOL-Module, JCL-Batch-Strukturen, Converter-Logik, Schnittstellen, mit der Zahlungsverkehrs-Expertise von KIWI Consulting. Die Plattform liefert den Graphen.

Wir liefern die Bedeutung:

• Welches Modul ist der SEPA-Konverter?
• Wo steckt die Gebührenlogik?
• Welche Routine validiert die strukturierten Adressen, die ab November 2026 Pflicht werden?
• Was kann weg, was muss bleiben, was lohnt einen Neubau?

Daraus entsteht eine Systemlandkarte mit Impact-Pfaden, Risiko-Heatmap und einem Demografie-Overlay – also der Frage, welches Wissen bei wem liegt und wie lange noch. Auf dieser Basis treffen wir eine Retire/Replace/Rewrite-Entscheidung pro fachlicher Domäne. Keine Beraterfolie, sondern etwas, womit ein SteerCo arbeiten kann, worunter ein CFO seinen Business Case setzt und worauf ein CRO seine DORA-Bewertung aufbaut.

Was uns von klassischen Modernisierungsprojekten unterscheidet? Es ist nicht die Technik. Es ist das Ergebnis. Nicht „wir haben Ihren Code verstanden", sondern „wir haben Ihren Zahlungsverkehr verstanden und können sagen, wo die Risiken liegen, was es kostet und in welcher Reihenfolge Sie vorgehen sollten."

Kein Großprojekt, sondern ein Einstieg

Ein Payment Legacy Risk Scan liefert in vier bis sechs Wochen die Fakten. Kein Commitment zu einem Millionenprogramm. Einfach eine belastbare Grundlage, auf der sich entscheiden lässt, was als Nächstes passieren muss. Wenn dann Zielbild und Abschaltplan stehen, beginnt die Transformation domänenweise – mit Regression Testing als Nachweis, dass Alt- und Neusystem identische Ergebnisse liefern, Cent-genau.

Die wirkliche Einsparung kommt nicht aus der Analyse. Sie kommt aus der Abschaltung. Solange alte Systeme parallel weiterlaufen, laufen auch die Kosten weiter. Wer Legacy nicht kontrolliert, zahlt bei jeder neuen Regulierung doppelt – für die Anpassung und für den Parallelbetrieb, den niemand beendet. In Projekten mit der ING Deutschland, dem ITZBund und der DAK-Gesundheit hat sich gezeigt, dass das funktioniert, auch in Umgebungen, in denen Ausfälle keine Option sind.

Bleibt am Ende eine schlichte Frage: Weiß im Haus wirklich jemand, was da modernisiert wird? Und wenn nicht – wer steuert dann eigentlich? Die Regulierung gibt den Takt vor, der Fachkräftemangel verschärft die Lage, die Margen schrumpfen. Payment Legacy Control ist vor diesem Hintergrund kein Effizienzprojekt. Es ist eine Frage der Handlungsfähigkeit.