Core-Architekturen im Wandel – zwischen Stabilität und Innovation?

Technologischer Wandel ist für Banken nichts Neues. Neu ist jedoch, dass sich Veränderungen nicht mehr in klar abgegrenzten Innovationswellen vollziehen. Stattdessen überlappen sich neue regulatorische Anforderungen, digitale Produktideen, Sicherheits­bedrohungen und Integrations­anforderungen heute kontinuierlich. Die zentrale Herausforderung ist daher nicht die Innovation selbst, sondern ihre Vereinbarkeit mit bestehenden Core-Systemen.

von Narendra Mistry, Finastra

Für Technologieverantwortliche bedeutet dies, dass es keine Phasen mehr gibt, in denen sich Systeme stabilisieren können, bevor die nächste Veränderung beginnt.
Modernisierung scheitert selten an einem Mangel an Ideen; sie scheitert daran, wo neue Logik technisch verankert wird – und wo bewusst nicht.

Warum der Core das Problem ist – und wie er adressiert wird

In vielen Diskussionen wird der Kern als etwas dargestellt, das vor Veränderungen geschützt werden muss. In der Praxis greift diese Sichtweise jedoch zu kurz. Das eigentliche Problem ist nicht der Core als einzelnes System, sondern bestimmte Core-Fähigkeiten, die die aktuellen oder zukünftigen Geschäftsanforderungen der Bank nicht mehr erfüllen.
Im Laufe der Zeit hat der Core Verantwortlichkeiten angesammelt, die weit über stabile Buchungs- und Registerfunktionen hinausgehen.

Produktlogik, Prozesssteuerung und Geschäftsregeln sind eng mit transaktionalen Funktionen verflochten. Infolgedessen wird jede Einführung neuer Fähigkeiten durch den am wenigsten flexiblen Teil der Systemlandschaft begrenzt.“

Erfolgreiche Modernisierungsprogramme behandeln den Core daher nicht als unantastbar. Sie erkennen, dass bestimmte Core-Fähigkeiten zum begrenzenden Faktor werden und ersetzt oder ausgelagert werden müssen, wenn sie Fortschritt verhindern. Übrig bleibt ein bewusst gestalteter Core-Footprint: stabil dort, wo Stabilität erforderlich ist, und durch moderne Komponenten ergänzt, wo Veränderung essenziell ist.
In diesem Sinne ist der Core das Problem – allerdings eines, das selektiv adressiert werden kann, ohne die gesamte Systemlandschaft zu destabilisieren.

Geschwindigkeit entsteht durch Reihenfolge, nicht durch Radikalität

Ein wiederkehrendes Muster erfolgreicher Programme ist die bewusste Sequenzierung von Modernisierungsinitiativen. Anstatt „von innen nach außen“ vorzugehen, beginnen Banken dort, wo Kundennutzen entsteht.

Digitale Onboarding-Journeys, Payment-Orchestrierung, kanalnahe Produktlogik und operative Datenplattformen werden modernisiert, während der Core zunächst unverändert bleibt.“

Zunächst ändern sich die Core-Operationen, nicht zwingend das physische Core-System selbst. Im Rahmen eines symbiotischen Ansatzes wird die operative Verantwortung auf moderne Komponenten verlagert, die sich schnell weiterentwickeln können, während der bestehende Core weiterhin seine verbleibenden System-of-Record-Funktionen erfüllt.

Core-Replacements scheitern häufig, weil die Kultur der Institution nicht auf tiefgreifende Veränderungen vorbereitet ist, wodurch Change Management zu einem wichtigen Bestandteil jeder Modernisierung wird.“

Der symbiotische Ansatz reduziert den Umfang der Veränderung, indem bestimmte Teile unverändert bleiben, wodurch sowohl die Disruption als auch der Anpassungsbedarf für Mitarbeitende verringert werden – vergleichbar mit der Renovierung einer Küche, während die übrigen Räume unverändert bleiben, anstatt das gesamte Haus abzureißen, nur um die Küche zu ersetzen.
Dieser Ansatz beschleunigt die Time-to-Market, ohne disruptive Alles-oder-nichts-Entscheidungen zu erzwingen. Im Laufe der Zeit entsteht eine geschichtete Architektur, in der einzelne Core-Fähigkeiten dann modernisiert werden, wenn es dafür eine klare geschäftliche Begründung gibt.

APIs sind keine Öffnung – sie sind ein Enabler

In diesem Kontext spielen Application Programming Interfaces (APIs) eine zentrale Rolle – nicht als technische Modetrends, sondern als architektonische Enabler für Veränderungen im großen Maßstab.

APIs machen Geschäftsinteraktionen explizit, konsumierbar und wiederholbar.“

Dadurch wird die Integration neuer Fähigkeiten erleichtert, anstatt diese über fragile Punkt-zu-Punkt-Verbindungen zu realisieren.
Entscheidend ist die geschäftliche Qualität dieser Schnittstellen. Erfolgreiche Architekturen kapseln Aktionen – wie die Kontoeröffnung oder Zahlungsinitiierung – anstatt rein technischer Datenoperationen. Asynchrone Events entkoppeln nachgelagerte Prozesse und machen Fehler isolierbar. So wird Innovation nicht um jeden Preis schneller, sondern planbar.

Cloud ergibt dort Sinn, wo Bewegung ist

Ein wachsender Pragmatismus zeigt sich auch bei der Cloud-Nutzung. Universalbanken betrachten die Cloud nicht mehr als Alles-oder-nichts-Entscheidung, sondern als Frage der passenden Platzierung. Workloads mit hoher Änderungsfrequenz, hoher Integrationsdichte oder variabler Last profitieren von cloudnativen Architekturen.

Da Core-Operationen durch spezialisierte Komponenten modernisiert werden, können auch diese – sofern die regulatorischen, operativen und geschäftlichen Rahmenbedingungen dies zulassen – in cloudfähigen Architekturen betrieben werden.“

Entscheidend ist nicht die Einstufung als „Core“ oder „Non-Core“, sondern ob elastische Skalierung, Continuous Delivery und schnelle Weiterentwicklung gerechtfertigt sind.
Diese hybride Realität ist kein Übergangszustand, sondern ein bewusst gewählter Zielzustand. Sie ermöglicht es, neue Services schnell zu entwickeln und zu skalieren, ohne dabei die Core-Operationen unnötig zu destabilisieren.

Daten entkoppeln, bevor sie genutzt werden

Ein weiterer entscheidender Hebel liegt im Umgang mit Daten. Viele Modernisierungsinitiativen scheitern, weil der analytische und operative Zugriff direkt auf Core-Systemen erfolgt. Erfolgreiche Programme entkoppeln die Daten dagegen frühzeitig. Events und Zustände werden aus dem Kernsystem extrahiert und in einer operativen Datenebene nutzbar gemacht.
Erst dann sind Near-Realtime-Personalisierung, kanalübergreifende Orchestrierung und der sinnvolle Einsatz analytischer Modelle möglich, ohne dass zusätzliche Last auf dem Core entsteht oder regulatorische Risiken eingeführt werden.

Vereinfachung schlägt Technologie

Auffällig ist zudem, dass technologischer Fortschritt häufig dort ins Stocken gerät, wo funktionale Komplexität unkontrolliert gewachsen ist.

Große Produktkataloge, historisch gewachsene Preislogiken und Sonderfälle verlangsamen jede Modernisierungsinitiative, ganz gleich, welche Technologie eingesetzt wird.“

Banken, die diese Komplexität angehen – unterstützt durch darauf ausgerichtete Plattformen – kommen schneller und mit geringerem Risiko voran. Vereinfachung ist demnach keine Voraussetzung für Modernisierung, sondern ein Verstärker, der die Wirkung neuer Core-Fähigkeiten erhöht.

Modernisierung ist kein Zielzustand

Die beschriebenen Muster spiegeln den derzeit in Diskussionen zur Modernisierung von Universalbanken verfolgten Ansatz wider. Im Zentrum steht dabei nicht der radikale Systemersatz, sondern die kontrollierte Weiterentwicklung bestehender Kernsysteme durch Entkopplung, modulare Erweiterungen und klar definierte Schnittstellen.

Die Modernisierung im Jahr 2026 ist kein Projekt mit Enddatum, sondern eine permanente architektonische Disziplin.“

Universalbanken, die versuchen, Veränderungen in großen, seltenen Schritten zu managen, erhöhen ihr Risiko. Institute, die Stabilität und Innovation bewusst trennen, gewinnen hingegen Handlungsspielraum.
Der entscheidende Vorteil entsteht nicht durch maximale Geschwindigkeit, sondern durch die Fähigkeit, Veränderungen sicher, wiederholt und kontrolliert umzusetzen. Genau das ist es, was reaktive Technologie heute von strategischer Architektur unterscheidet. Narendra Mistry, Finastra