Standardsoftware sollte Banken von ihrer IT befreien: Kein Eigenbau mehr, keine Truppe von Entwicklern, die COBOL-Monolithen pflegen, bis die Rente droht. Man kauft ein System, parametrisiert statt programmiert, und die regulatorischen Updates kommen frei Haus.

Das war das Versprechen und für mehr als 20 Jahre hat es leidlich funktioniert.

Die heutige Realität

Heute ist von diesem Versprechen nicht mehr viel übrig – und das aus einem Grund, der zu wenig thematisiert wird.

Die Kosten

Fangen wir bei den Kosten an, weil die am ehesten weh tun.

Die jährlichen Lizenzkosten zum Beispiel eines Temenos liegt bei ca. einer halben Million Dollar pro Kunde, große Häuser natürlich mehr – bis zu einer Million pro Jahr.

Leute, die in diesem Bereich tätig sind, wissen, dass das verkraftbar klingt. Aber das sind die Kosten, bevor überhaupt nur eine Zeile individueller Code implementiert ist! Denn das ist das Wesen von Standards:

„Der Standard deckt den Standard ab.“

Und wie es einmal ein Sparkassenvorstand treffend auf den Punkt brachte:

„Standard ist toll! Solange es mein eigener ist“

Denn alles, was eine Bank tatsächlich von der Konkurrenz unterscheidet, ist faktisch individuell und muss damit selbst bezahlt werden.

Man kauft ein System, das Individualität verspricht, und finanziert die Individualität dann trotzdem aus eigener Tasche:

• Effiziente Kreditprozesse im Privatkundenumfeld
• Integration von Partnerplattformen (Stichwort „FIDA“ – Hier gibt’s Details dazu)
• Integration von Handels- und Wertpapierplattformen
• Telefonie
• Einbindung von Kryptowährungen und -plattformen
• Paymentplattformen…

Die Liste könnten wir deutlich verlängern.

Dazu ein Überbau an Modulen, die man nicht braucht und eine Abhängigkeit von einer Handvoll spezialisierter Berater, die als Einzige wissen, wo im System die Schrauben sitzen.

Und dann der Vendor-Lock-in

Das Ergebnis kennt jeder, der ein Kernbank-Programm begleitet hat:

Man landet in einem Vendor-Lock-in, und damit verkommt eine natürlich und richtigerweise durch die Regulatorik geforderte Exitstrategie zur theoretischen Fingerübung.

Und die Zahlen sprechen eine deutliche und ernüchternde Sprache:

1. 94 Prozent der Kernbank-Modernisierungsprojekte reißen ihren Zeitplan.
2. Vollmigrationen dauern drei bis fünf Jahre.
3. Die Abschaltung von Altsystemen zieht sich nochmal ein bis zwei Jahre.
4. Manche Altsysteme bleiben darüber hinaus teilweise Jahre bestehen.

An dieser Stelle kommt der berechtigte Einwand:

„Eigenentwicklung? Das hatten wir doch schon und hat uns in teure Legacy-Systeme getrieben“

Das ist richtig. Und wer heute „zurück zur Eigenentwicklung“ ruft, muss diese Frage beantworten:

Was ist diesmal anders?

Die Architektur

Diesmal ist die Architektur anders. Eine Bankplattform der 90er war ein Monolith – ein einziger Block, den man nur als Ganzes anfassen konnte. Zart sprießende Ansätze zur Modularisierung (wer erinnert sich an COM, RMI, CORBA?) führten eigentlich nie zu echter Entkopplung, sondern eher zu höherer Komplexität.

Ein Kernbanksystem von heute ist eine Menge überschaubarer, unabhängig operierender Services:

• event-basiert über Quasi-Standards wie „Kafka“, „RabbitMQ“ usw.
• cloudfähig, aber nicht gebunden an einen speziellen Hyperscaler
• mit automatisierten Infrastruktur-Setups, Deployments und Tests, ebenfalls basierend auf Standardtools wie „Terraform“, „Ansible“ usw.

Fällt ein Baustein aus der Zeit, wird er ausgetauscht, nicht das System selbst.

Der entscheidende Unterschied: Der alte Eigenbau wurde zum Gefängnis, weil man ihn nicht mehr ändern konnte. Moderne Architektur ist so gebaut, dass Änderbarkeit das Grundprinzip ist. Und ja: Das erfordert Disziplin und ein starkes Selbstbewusstsein der IT zur Vermeidung vordergründig kostengünstiger Workarounds.

Der entscheidende Unterschied: Änderbarkeit ist im Design verankert.

Standards sind wichtig und bleiben es auch

Das heißt nicht, dass Standardsoftware verschwindet. Rechnungsbearbeitung, Dokumentenmanagementsysteme, Teile des Risikocontrollings, Telefonie: Das sind Felder, in denen sich Banken nicht unbedingt differenzieren – „Ausnahmen bestätigen die Regel“.

Wo die Regulatorik wehtut, können Standardanwendungen helfen: Man will nicht jede Basel- oder DORA-Anpassung selbst bauen. Also bindet man diese Systeme über moderne Schnittstellen an. Der Standard verschwindet nicht – er wandert von der differenzierenden Mitte an die regulatorischen Ränder. Der Kern, in dem die Bank ihr eigentliches Geschäft und ihr Datenmodell besitzt, gehört ihr selbst.

Wichtig dabei: Diese Standardsysteme haben sich in die Bankarchitektur einzufügen, nicht umgekehrt!

Achtung – „Clickbaitgefahr“: KI, Process Mining, Event Sourcing

Nein ehrlich: Dass Process Mining ein großartiges Instrument zur Optimierung von Prozessen ist, müssen wir sicher nicht mehr diskutieren. Dass abseits vom Hype KI da ist und bleiben wird, ist sicher auch unbestritten. Und nein: Es muss nicht immer ein LLM sein – Machine Learning mittels „guter alter“ Linearer Regression tut es oft auch, ist billiger und zudem nachvollziehbarer!

Process Mining und jede ernstzunehmende KI-Anwendung im Bankbetrieb – Echtzeit-Kreditentscheidung, Betrugserkennung, personalisierte Beratung – hängen an einer Voraussetzung, die in der Praxis zu kurz kommt:

Der Verfügbarkeit feingranularer, prozess- und ereignisbezogener Daten: Nicht der Tagessaldo von gestern, sondern jeder Vorgang, der ihn erzeugt hat, mit seiner fachlichen Bedeutung.

Genau das liefert ein event-sourced System per Konstruktion. Jede Transaktion ist ein permanentes, auditierbares Ereignis. Der Zustand jedes Kontos, jedes Vertrags, jedes Kunden wird aus der Ereignishistorie abgeleitet, jeder Kundenkontakt ist nicht nur ein Log-Eintrag, sondern die Basis für die Rekonstruktion jeglichen Zustandes.

Das ist kein nachträglich krampfhaft zusammengeschraubtes Reporting – das ist die native Struktur des Systems.

Ein lückenloses, zeitlich auflösbares Protokoll dessen, was in der Bank passiert ist.

Ideales Futter für Modelle und für alles, was Reproduzierbarkeit braucht.

Solche Event-Streams kann man heute teilweise aus Standardanwendungen ermitteln: „per Change-Data-Capture“ heißt das Zauberwort, wird man jetzt sagen.

Teilweise ist das richtig, aber es macht einen erheblichen Unterschied sprechende Events aus Systemen abzuleiten und nachzukonstruieren, statt das Event direkt als Nukleus des Geschäfts zu betrachten.

Semantische Granularität lässt sich schwer nachrüsten. Man baut sie ein – oder man hat sie nicht.

Trotzdem erfordert die Integration von Standardanwendungen die Nutzung von „Change-Data-Capture“. Und das ist OK!

Eigenbau ist nie billig

Um nicht falsch verstanden zu werden: Der Eigenbau ist nicht der billige Weg. Er ist nicht mal unbedingt der günstigere. Er ist das Abwägen von

• Lizenzkosten gegen dauerhaften Betriebs-, Security- und Compliance-Aufwand,
• Tausch von Abhängigkeit von spezialisierten Systemberatern gegen die Abhängigkeit von rarem Senior-Engineering – ein Lock-in, das man ebenso ernst nehmen muss.

Für eine Genossenschaftsbank oder Sparkasse ist das keine Option, für eine Direktbank, einen Spezialfinanzierer oder ein ambitioniertes mittelgroßes Haus mit IT-DNA verschiebt sich dagegen die Rechnung gerade grundlegend.

IT ist DAS Produktionsmittel der Bank – Mitarbeiter mit IT-Kompetenz sind für eine Bank so wichtig wie erfahrene Industriemechaniker und Konstrukteure für einen Maschinenbauer!

Niemand reißt sein Kernsystem über Nacht ein: Der realistische Pfad ist, den neuen Kern um das Alte herum wachsen zu lassen und Funktion für Funktion herauszuschneiden.

Fazit

Die Ära der Standard-Kernbanksysteme endet also nicht mit einem Knall. Was enden muss ist der reflexhafte Griff zum Standardkernbanksystem, wenn man dauerhaft im hart umkämpften und sich immer schneller ändernden Markt bestehen will.

Für die wachsende Zahl spezialisierter und kosteneffizienter Banken ist das moderne, event-basierte eigenentwickelte Kernbanksystem die rationalere Wahl – nicht primär wegen der Kosten, sondern weil KI ohne granulare Daten ein Versprechen ohne Substanz bleibt.

Die Frage ist nicht, ob Banken das erkennen, sondern welche Häuser früh genug anfangen, ihre Kernsysteme als das zu behandeln, was sie sind: ihr wertvollstes Asset – ihr wichtigstes Produktionsmittel neben guten Mitarbeitern – zu wertvoll, um es von der Stange zu kaufen.