Kernbankensysteme aus den 1990er-Jahren wickeln noch heute den größten Teil des Bankgeschäfts ab, und genau das wird zum Problem. Produkt-Einführungszeiten dauern mehrere Quartale, die Fähigkeit zur API-Integration ist begrenzt oder fehlt ganz, und Cloud-Lösungen lassen sich auf dieser Basis kaum einführen. Das bedeutet für IT-Verantwortliche eine technische Sackgasse, für Produktverantwortliche verlorene Zeit im Wettbewerb um neue digitale Angebote. Jede zusätzliche Schnittstelle, die über das Altsystem laufen muss, verlängert die nächste Produkteinführung erneut um Wochen, weil sie das ohnehin unbewegliche System noch enger mit weiteren Anwendungen verknüpft. Beide Seiten treibt am Ende dieselbe Frage: wie sich das Altsystem ablösen lässt, ohne den täglichen Zahlungsverkehr für Tausende Kundinnen und Kunden zu gefährden.

Drei Wege aus dem Altsystem

Der passende Ansatz hängt vom Zustand des bestehenden Systems und vom Zeitdruck ab, unter dem neue Produkte auf den Markt sollen. Sie unterscheiden sich vor allem im Risiko und in der Geschwindigkeit, mit der ein Institut vom Altsystem wegkommt. Alle drei lassen sich mit dem bestehenden Betrieb kombinieren, keiner verlangt einen sofortigen kompletten Stopp der laufenden Systeme.

Inkrementelle API-Schicht

Ein API-Gateway umhüllt das bestehende Kernbankensystem und lässt dessen Code unangetastet, sodass sich digitale Kanäle darüber anbinden lassen, während eine vollständige Modernisierung erst geplant wird. Wenig Aufwand, wenige Wochen Umsetzungszeit – dafür bleibt das Altsystem im Kern unverändert. Passend ist das, solange schnell neue Schnittstellen gebraucht werden und das Altsystem selbst noch tragfähig ist; wer diesen Weg wählt, verschiebt die eigentliche Modernisierung damit aber nur nach hinten.

Parallelbetrieb nach dem Strangler-Fig-Muster

Ein cloud-natives Kernbankensystem läuft neben dem Altsystem. Neue Produkte werden schrittweise auf die neue Plattform migriert, bestehende Konten bleiben so lange im Altsystem, bis sie geordnet übernommen werden können. Dieser Weg gilt als empfohlener Standardansatz, weil wir damit das Risiko eines einzelnen großen Umschaltmoments vermeiden und die Kontrolle über das Tempo der Migration behalten.

Dieser Weg zahlt sich für Fachbereiche zuerst aus: Neue Produkte laufen auf der modernen Plattform, sobald sie fertig sind, unabhängig davon, wie weit die Migration des Altsystems insgesamt fortgeschritten ist. Er bedeutet für IT-Verantwortliche zugleich, dass der laufende Betrieb während der gesamten Migrationsdauer stabil bleibt, weil das Altsystem für die verbleibenden Konten unangetastet weiterläuft. Die eigentliche Arbeit steckt in der Reihenfolge, in der Produkte und Kontoarten migriert werden: Wir priorisieren zuerst, was am meisten Entwicklungskapazität im Altsystem bindet, damit jede migrierte Einheit sofort spürbar Kapazität für die nächste freisetzt.

Vollständige Migration

Alle Daten werden in einem einzigen Schritt migriert und abgeglichen, danach übernimmt das neue System sofort den gesamten Betrieb. Dieser Weg gilt als der riskanteste der drei, weil ein Fehler in der Abstimmung erst nach der Umschaltung sichtbar wird und dann den gesamten Betrieb betrifft, nicht nur ein einzelnes Produkt. Wir empfehlen ihn nur, wenn das Altsystem am Ende seiner Lebensdauer angelangt ist und ein Parallelbetrieb technisch oder wirtschaftlich nicht mehr sinnvoll ist, etwa weil der Hersteller den Support eingestellt hat und sich Sicherheitslücken nicht mehr schließen lassen. Wer sich in dieser Lage für einen Parallelbetrieb entscheidet, verschiebt das eigentliche Problem nur in die Zukunft.

Technologie-Stack

Cloud-native Plattformen wie Mambu, Thought Machine Vault, Temenos Transact und Finacle kommen zum Einsatz. Die Integration in die bestehende Systemlandschaft läuft über Microservices und Event-Sourcing, angebunden über REST- und GraphQL-Schnittstellen.

Welche Plattform passt, hängt von der bestehenden Architektur und von den Produkten ab, die zuerst migriert werden sollen. Wir legen diese Entscheidung gemeinsam mit deinem Architekturteam fest, bevor die erste Zeile Code entsteht. Mambu haben wir zuletzt für eine White-Label-Wallet-Plattform eingesetzt, auf derselben Infrastruktur, auf der auch N26 und Revolut laufen, inklusive Echtzeit-Compliance-Prüfung in jedem Zahlungsablauf.

Aufsichtsrecht von Anfang an mitgedacht

Regulatorische Anforderungen lassen sich nicht nachträglich in eine Migration einbauen. Das gilt für alle drei Wege gleichermaßen: Auch eine inkrementelle API-Schicht muss die gleichen Prüfungs- und Meldepflichten erfüllen wie eine vollständige Migration, nur eben in kleineren, früher überprüfbaren Schritten. Ein Beispiel dafür zeigt der Kasten neben diesem Text.

Für IT-Entscheider und Fachbereich

Wer in der IT-Leitung sitzt, entscheidet über den Weg, trägt aber auch die Verantwortung dafür, dass der laufende Betrieb während der Migration stabil bleibt. Diese Entscheidung lässt sich nicht rein technisch treffen, weil regulatorische Fristen und Budgets mit hineinspielen.

Im Digital Banking zeigt sich das alte System dagegen zuerst im Tagesgeschäft: Eine neue Produktidee, die eigentlich binnen Wochen an den Start gehen sollte, bleibt an der Systemgrenze hängen. Genau diesen Engpass löst der Parallelbetrieb schon vor Abschluss der vollständigen Modernisierung, weil neue Produkte direkt auf der neuen Plattform starten können.

Bestandsaufnahme, Wegwahl, Etappenplan

Am Anfang steht die Frage, wie tragfähig dein bestehendes Kernbankensystem noch ist und welche Anwendungen und Schnittstellen daran hängen – diese Bestandsaufnahme liefert die Grundlage für alles Weitere. Zeitdruck, Risiko und regulatorische Vorgaben geben dann gemeinsam den Ausschlag, welcher der drei Wege passt.

Für die Migration selbst zählt vor allem eines: Jede Etappe muss für sich abnehmbar sein und in einem Zustand enden, in dem sowohl das Alt- als auch das neue System den Betrieb übernehmen könnten, falls sie doch mehr Zeit braucht als geplant. So entsteht eine Roadmap, an der sich Fortschritt und Restrisiko jederzeit ablesen lassen, nicht erst am Ende des Projekts, und dein Institut behält die Kontrolle darüber, wie schnell die restliche Migration weitergeht.