Entkopplungs­schicht für Kernbanken­systeme: Der Weg zu mehr Agilität

Kernbankensysteme (KBS) wie Avaloq oder Finnova sind das Rückgrat jeder Bank. Sie sind extrem stabil, regulatorisch sicher und als «Booking Engine» für das Kerngeschäft unersetzlich. Doch genau hier liegt das Paradoxon: Die Stabilität, die wir im Core brauchen, wird in der digitalen Welt oft zur Innovationsbremse.

Wenn du heute moderne Architekturanforderungen wie Open Finance, Cloud-SaaS-Anbindungen oder Near-Realtime-Services umsetzen willst, stösst du mit feingranularen und hochfrequenten Anfragen schnell an die Grenzen des Kernbankensystems. Und jedes Mal, wenn das KBS für Wartungsfenster offline geht, stehen auch deine digitalen Kanäle still.

Die Lösung? Eine strategischer Entkopplungsschicht (auch Decoupling Layer genannt). Doch Entkopplung ist nicht gleich Entkopplung. In der Architekturpraxis haben sich drei wesentliche Reifegrade etabliert, um diese Hürden zu überwinden.

Die Herausforderungen moderner Banking-Architekturen: Mehr als nur APIs

Die Anforderungen an moderne Banken-IT sind massiv gestiegen. Es geht heute nicht mehr nur darum, Daten von A nach B zu schieben.

1. Near-Realtime-Daten: Kund:innen erwarten heute, dass ihre Transaktionen sofort in der Mobile App sichtbar sind – nicht erst nach dem nächsten Batch-Lauf.
2. Flexible Ökosysteme: Die Vernetzung via Open Finance nimmt zu. Ob Produkte von Drittanbieter:innen aus der Cloud oder interne Microservices – die Integration muss nahtlos funktionieren.
3. End-to-End Security: Ein modernes Identity and Access Management (IAM) Konzept mit JSON Web Tokens (JWT), Role-Based Access Control (RBAC) oder sogar Attribute-Based Access Control (ABAC) muss über alle Layer hinweg greifen, ohne die Performance zu korrumpieren.

Um diese Hürden zu nehmen, ist eine saubere Architekturstrategie für die Entkopplung des Kernbankensystems entscheidend. 

Die drei Stufen der Kernbanken-Entkopplung 

Die Entkopplung des Kernbankensystems kann in drei verschiedene Stufen unterteilt werden.

Stufe 1: Die Schnittstellen-Entkopplung (API-First)

In dieser Stufe greifen alle Umsysteme über fachliche APIs auf einer zentralen Integrationsplattform auf das Kernbankensystem zu.

• Das Prinzip: Die Plattform abstrahiert die proprietäre Logik des KBS und bietet standardisierte synchrone oder asynchrone Schnittstellen an.
• Der Vorteil: Schnelle Implementierung von neuen Anforderungen ohne unmittelbare Anpassungen am Kernbankensystem und eine saubere Abstraktion der Fachlogik des Kernbankensystems gegenüber den Entwicklern.
• Architektur-Insight: Dieser Ansatz eignet sich hervorragend als «Quick Win», um die Interoperabilität zu erhöhen. Die technische Herausforderung liegt hier primär im Mapping komplexer, proprietärer Datenstrukturen auf moderne API-Standards. Die Verfügbarkeit bleibt jedoch eng an die Wartungsfenster des Core-Systems gekoppelt.

Stufe 2: Entkopplung mit Datenhaltung und Lesezugriff

Hier gehen wir einen Schritt weiter: Die Integrationsplattform hält eine lokale Kopie der Daten des Kernbankensystems vor.

• Das Prinzip: Daten werden in Echtzeit in die Entkopplungsschicht gestreamt. Lesezugriffe erfolgen direkt auf der Integrationsplattform.
• Der Vorteil: 24/7-Verfügbarkeit ist möglich. Die entfallenden Lesezugriffe entlasten das Kernbankensystem.
• Implementierungs-Kontext: Dies ist der logische Schritt, um effizient den Kund:innen einen 24/7-Zugriff auf ihre Daten zu ermöglichen. Die grosse Komplexität liegt nicht im Datentransport, sondern in der Autorisierung und in der Datenkonsistenz. Sicherheitskonzepte und Zugriffsberechtigungen müssen konsistent vom Core auf die Integrationsplattform gespiegelt werden, um sicherzustellen, dass die lokale Datenhaltung denselben regulatorischen Anforderungen entspricht wie das KBS. Die Datenkonsistenz zwischen Kernbankensystem und Integrationsplattform muss mit technischen Mitteln (z. B. Reconciliation, Monitoring) sichergestellt werden.

Stufe 3: Entkopplung mit Schreib- und Lesezugriff

Die höchste Ausbaustufe kombiniert die lokale Datenhaltung mit dem asynchronen Schreiben in das Kernbankensystem.

• Das Prinzip: Schreibzugriffe (Writes) werden asynchron in das Kernbankensystem geschrieben und können so das Kernbankensystem zusätzlich entlasten.
• Der Vorteil: Hohe Verfügbarkeit, weil die 24/7-Verfügbarkeit nicht nur lesend, sondern auch schreibend vorhanden ist.
• Kostenfaktor technische Lösung: Beim Schreiben von Daten kann es vorkommen, dass der schreibende Prozess auf veralteten Daten basiert. In diesem Fall wird das Kernbankensystem einen Fehler zurückgeben. Diese Situation muss entweder technisch oder manuell aufgelöst werden. Dabei ist der springende Punkt, mit einer Analyse den Business Value einer technischen Lösung (z.B. SAGA-Pattern) gegen eine sozio-technische Lösung (z.B. Refresh) abzuwägen. Die technische Lösung in aller Konsequenz umgesetzt werden, kann sehr schnell sehr teuer werden.

Das Potenzial einer modularen Architektur & KI-Ausblick 

Eine moderne Architektur muss atmen können. Die gezielte Entkopplung der monolithischen Booking-Engine bricht die starren Release-Zyklen des Kernsystems auf. Sie bietet das Potenzial, fachliche Domänen unabhängig voneinander zu skalieren und technologische Schulden sukzessive abzubauen.

Mit Blick auf die Zukunft wird die Entkopplungsschicht zudem zum Enabler für Künstliche Intelligenz. Ob Hyper-Personalisierung im Wealth Management oder Echtzeit-Betrugserkennung: KI-Modelle benötigen keine Batches, sondern verlässliche Datenströme in Echtzeit. Nur wer seine Daten aus den Silos des monolithischen Kerns befreit und in einer entkoppelten Architektur nutzbar macht, wird KI-Anwendungen nicht nur als Prototyp, sondern als produktive Business-Value skalieren können.