Kernbanksysteme verlieren das Zentrum: Was Banken-Architektur jetzt braucht

48,65 Millionen Pfund musste die britische TSB Bank an FCA und PRA zahlen – Strafe für eine IT-Migration, die 2018 gründlich schiefging. Kunden kamen tagelang nicht an ihr Geld, Systeme spielten nicht zusammen, die Aufsicht sah gravierende Governance-Mängel. Die FCA hat den Fall in ihrer Pressemitteilung detailliert aufgearbeitet und listet dabei genau jene Schwächen auf, die sich bei vielen Häusern noch heute finden: unklare Verantwortlichkeiten während der Migration, fehlende Testtiefe, mangelnde Eskalationswege. Der Fall zeigt, was passiert, wenn Banken ihre Kernbank-Architektur falsch angehen: Modernisierung wird selbst zum Risiko, das sie eigentlich vermeiden sollte.

Unter dem Strich stehen Banken heute vor einem Dilemma. Sie müssen ihre IT beschleunigen, dürfen dabei aber keine neuen Betriebsrisiken produzieren. Die Aufsicht schaut genauer hin, die Fristen werden enger, und das alte Rezept – ein neues Kernbanksystem für alles – funktioniert immer seltener. Genau hier setzt der aktuelle Umbau der Banken-Architektur an, den auch Karl im Brahm, CEO DACH bei Objectway, beschreibt.

EZB-Prioritäten für die kommenden Jahre: Kernbank-Risiken sollen nicht nur erfasst, sondern behoben werden

Die Europäische Zentralbank hat ihre Aufsichtsprioritäten für die kommenden drei Jahre in einem eigenen Dokument formuliert, und operative Resilienz gehört klar zu den Schwerpunkten. Konkret geht es um IT-Risiken, Abhängigkeiten von Drittanbietern, Cloud-Konzentration und die Qualität von Daten und Reporting. Der entscheidende Unterschied zu früheren Prüfzyklen: Die EZB will nicht mehr nur Schwachstellen dokumentiert sehen, sie erwartet, dass Institute sie tatsächlich beheben.

Das ist ein Wechsel im Ton. Wer beim nächsten Aufsichtsgespräch nur eine Mängelliste mit Zeitplan vorlegt, ohne belastbare Fortschritte, gerät schneller in eskalierende Maßnahmen. Für viele Häuser bedeutet das: Die Modernisierung der Kernbank-Systeme ist keine strategische Kür mehr, sondern eine aufsichtsrechtliche Pflichtübung mit Deadline. Auch der Umgang mit Drittanbietern rückt stärker in den Fokus – ein Thema, das auch bei automatisierten Prozessen im Finanzsektor zunehmend Haftungsfragen aufwirft.

Bemerkenswert an den EZB-Prioritäten ist zudem der Bezug zum Change-Management selbst: Institute sollen nachweisen, dass sie größere IT-Vorhaben – Migrationen, Systemwechsel, Auslagerungen – kontrolliert steuern können, inklusive Rollback-Fähigkeit und klaren Eskalationsstufen. Das ist im Kern die Lehre aus TSB, nur eben aufsichtsrechtlich kodifiziert. Wer DORA-Anforderungen bereits umgesetzt hat, bewegt sich hier auf bekanntem Terrain, denn beide Regelwerke verlangen im Grunde dasselbe: Nachweisbarkeit statt Behauptung.

Change-Management ist dabei kein Randthema, sondern oft die eigentliche Fehlerquelle. Erfahrungsgemäß scheitern IT-Vorhaben in Banken seltener an der Technik selbst als an unklaren Zuständigkeiten während der Umstellung: Wer entscheidet im Zweifel, ob ein Rollout gestoppt wird? Wer trägt die Verantwortung, wenn ein Zulieferer eine Frist verpasst? Wer informiert Kunden, wenn ein Prozess länger dauert als geplant? Diese Fragen klingen banal, bis sie im Ernstfall unbeantwortet bleiben – dann kostet das, wie TSB zeigt, nicht nur Geld, sondern auch Reputation über Jahre.

T+1 ab Oktober 2027: Warum die Architektur der Banken jetzt schneller werden muss

Parallel zieht die EU die Abwicklungsfrist für Wertpapiergeschäfte zusammen. Ab dem 11. Oktober 2027 gilt T+1 statt T+2 – ESMA hat das Datum bereits verbindlich vorgeschlagen. Rechnen wir nach, was das bedeutet: Ein Geschäftstag weniger Puffer heißt, dass Daten schneller verfügbar sein müssen, manuelle Nacharbeiten wegfallen sollten und Systeme in Echtzeit miteinander sprechen müssen – nicht per nächtlichem Batch-Lauf.

Für Banken mit einer gewachsenen, monolithischen Kernbank-Architektur ist das eine erhebliche Belastung. Viele Abwicklungsprozesse hängen heute an Schnittstellen, die für den Zwei-Tage-Rhythmus gebaut wurden. Wer diese Prozesse jetzt nicht modularisiert, wird 2027 unter Zeitdruck improvisieren müssen – und Improvisation unter Aufsichtsdruck ist erfahrungsgemäß keine gute Kombination, wie der TSB-Fall zeigt.

Kernbank verliert ihre Rolle als alleiniges Zentrum der Architektur

Die klassische Vorstellung, ein Kernbanksystem sei das eine System, das alles steuert, stimmt in dieser Form immer seltener. Banken verlagern Funktionen zunehmend in cloudbasierte, modulare Komponenten und lösen die Geschäftslogik schrittweise aus dem Kern. Der Grund ist einfach: Ein kompletter Austausch dauert Jahre, kostet enorm und ist – siehe TSB – ein erhebliches Betriebsrisiko.

„Banken können ihre Modernisierung nicht länger verschieben. Sie können aber auch nicht jedes gewachsene System auf einmal ersetzen“, sagt Karl im Brahm, CEO DACH von Objectway.

Karl im Brahm, CEO DACH Objectway

Im Brahm beschreibt damit eine Praxis, die sich über mehrere Institute hinweg beobachten lässt: Statt Big-Bang-Migration setzen Banken auf priorisierte Etappen. Das reduziert das Risiko einzelner Projekte, verlangt aber eine klare Vorstellung davon, in welcher Reihenfolge Funktionen aus dem Kern gelöst werden – und was währenddessen im alten System stabil weiterlaufen muss.

Priorisierte Etappen: eine Checkliste für die Praxis

Wer den Umbau seiner Architektur nicht als einmaliges Großprojekt, sondern als geordnete Folge von Etappen plant, kommt an ein paar Fragen kaum vorbei:

• Welche Funktionen sind regulatorisch am stärksten exponiert und müssen daher zuerst nachweisbar kontrolliert werden?
• Welche Komponenten lassen sich isoliert testen, ohne den laufenden Betrieb zu gefährden?
• Wo bestehen bereits saubere Datenmodelle, und wo müsste vor jeder Modernisierung erst die Datenqualität hergestellt werden?
• Welche Abhängigkeiten zu Drittanbietern entstehen durch jede neue Komponente, und wer verantwortet deren Überwachung?
• Gibt es für jede Etappe einen Rollback-Plan, der im Ernstfall innerhalb von Stunden greift, nicht Tagen?

Diese Liste ersetzt keine Projektplanung, aber sie zwingt dazu, Prioritäten vor der Technikauswahl zu klären – genau der Schritt, der bei TSB offenbar gefehlt hat. Wer die Reihenfolge falsch wählt, etwa weil eine besonders sichtbare Kundenfunktion zuerst modernisiert wird, während die darunterliegende Buchungslogik unverändert bleibt, produziert im schlimmsten Fall neue Inkonsistenzen, die erst Monate später auffallen.

Treiber der Modernisierung: nicht nur Kosten, auch Kundenerlebnis

Modernisierung wird häufig als reines Kostenthema verkauft, tatsächlich spielt das Kundenerlebnis eine größere Rolle als gedacht. Laut einer in der Pressemitteilung zitierten Analysten-Untersuchung nennen 54 Prozent der befragten Führungskräfte aus dem Finanzsektor ein besseres Kundenerlebnis als wichtigen Treiber für den IT-Umbau, 46 Prozent die Gewinnung neuer Kunden, 41 Prozent Umsatzwachstum. Diese Zahlen stammen aus der Herstellerkommunikation und sollten entsprechend als Tendenz, nicht als belastbare Studienlage gelesen werden.

Der Punkt bleibt trotzdem plausibel: Wer Kreditprozesse oder Kundenservice automatisiert, wie es etwa Volksbanken bei der Automatisierung ihrer Kreditprozesse vormachen, spürt den Effekt direkt am Kunden – nicht nur in der Bilanz.

Composability: Was im Kern bleiben muss und was nicht

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2Prompt16:9 documentary photo of a modern bank IT operations room with multiple monitors showing abstract network diagrams and soft data visualizations (no readable UI text or logos), cool daylight through blinds, mood of IT migration and operational risk, empty chairs, no brand names, photorealistic editorial style

Der zentrale Begriff hinter dem Umbau heißt Composability – die Zerlegung gewachsener Monolithen in unabhängig steuerbare Komponenten. Die eigentliche Schwierigkeit liegt nicht darin, ob eine Bank ihr Kernsystem ersetzt, sondern darin, zu entscheiden, welche Funktionen aus Stabilitätsgründen im Kern bleiben und welche sich unabhängig modernisieren lassen.

Kontoführung und Buchungslogik etwa bleiben in vielen Häusern bewusst im Kern, weil sie tief mit Abrechnung und Meldewesen verzahnt sind. Kundenschnittstellen, Portfolioanalysen oder KI-gestützte Beratungsfunktionen lassen sich dagegen leichter herauslösen und modular ergänzen. Diese Trennung erlaubt es, dort zu investieren, wo der Druck am größten ist, während der Rest weiterläuft – ein Ansatz, der auch bei der Einführung neuer Zahlungsinfrastrukturen wie tokenisierten Abwicklungslösungen der EZB zu beobachten ist.

Best-of-Breed-Architektur: Wo neue Abhängigkeiten entstehen

Je mehr Spezial-Lösungen eine Bank entlang ihrer Wertschöpfungskette einsetzt, desto mehr verschiebt sich die Herausforderung von der einzelnen Anwendung zur Verbindung zwischen ihnen. Der Haken an Best-of-Breed: Ohne gemeinsame Architektur entstehen zusätzliche Schnittstellen, fragmentierte Datenflüsse und operative Abhängigkeiten, die im Ernstfall schwer zu entwirren sind.

„Ein Best-of-Breed-Ansatz kann Fachwissen und Flexibilität in einzelne Bereiche bringen. Ohne eine gemeinsame Architektur und ein klares Orchestrierungsmodell entstehen jedoch zusätzliche Schnittstellen, fragmentierte Datenflüsse und operative Abhängigkeiten“, warnt im Brahm.

Karl im Brahm, CEO DACH Objectway

Notwendig sind deshalb einheitliche Datenmodelle, klar zugewiesene Verantwortlichkeiten und gemeinsame Vorgaben für Governance, Sicherheit und regulatorische Kontrollen. Werden Komponenten über standardisierte Schnittstellen verbunden, lassen sie sich später austauschen, ohne das gesamte Betriebsmodell neu aufzusetzen – ein Argument, das auch bei Banklizenzverfahren mit Auflagen relevant wird, wie der Fall von Revolut und der US-Bankenaufsicht zeigt.

Fragmentierte Daten bremsen KI-Projekte in der Kernbank

Spätestens beim Einsatz von KI wird eine unsaubere Architektur zum Belastungstest. KI-Anwendungen greifen oft gleichzeitig auf Daten aus Kernbanksystem, Kundenmanagement, Portfoliomanagement und Compliance zu. Sind diese Systeme nicht ordentlich verbunden, arbeitet die KI mit widersprüchlichen oder veralteten Informationen – und niemand kann im Nachhinein sauber nachvollziehen, woher ein Ergebnis stammt.

„KI macht eine fragmentierte Architektur nicht automatisch intelligenter. Ohne einheitliche Daten und klar geregelte Verantwortlichkeiten skaliert eine Bank nicht ihre Effizienz, sondern ihre Fehler“, sagt im Brahm.

Karl im Brahm, CEO DACH Objectway

Das ist der Kern der Sache: Datenqualität ist kein nachgelagertes Thema, das man nach der KI-Einführung optimiert, sondern die Voraussetzung dafür, dass ein Modell überhaupt verlässliche Ergebnisse liefert. Banken, die zuerst KI-Anwendungen ausrollen und die Datenbasis später bereinigen wollen, drehen die Reihenfolge um – mit dem Ergebnis, dass Fehler nicht kleiner werden, sondern lediglich schneller produziert werden.

Bevor weitere KI-Anwendungen ausgerollt werden, sollten Banken deshalb festlegen, welches System welche Information liefert, wer deren Qualität verantwortet und wie sich Ergebnisse nachvollziehen lassen. Das ist keine akademische Übung, sondern eine Voraussetzung dafür, dass KI in regulierten Prozessen überhaupt einsetzbar bleibt – ein Thema, das auch im Zusammenhang mit Haftungsfragen bei automatisierten Entscheidungen im Finanzsektor diskutiert wird.

Governance: Warum Business, IT und Risk die Architektur gemeinsam verantworten müssen

Erfolgreiche Modernisierung ist keine rein technische Aufgabe. Business und IT müssen die Transformation gemeinsam verantworten und technologische Entscheidungen von Anfang an mit den geschäftlichen Zielen abstimmen. Ebenso wichtig: Operations, Risiko, Compliance und Einkauf müssen früh eingebunden werden, sonst entstehen isolierte Entscheidungen und im schlechtesten Fall Schatten-IT – Systeme, die niemand offiziell verantwortet, aber jeder nutzt.

In der Praxis heißt das: Ein Architektur-Board, das aus IT-Verantwortlichen, Fachbereichsleitung und Risikofunktion besteht, sollte jede größere Entscheidung gemeinsam treffen – nicht nacheinander abnicken. Wird die Risikofunktion erst am Ende eines Projekts eingebunden, entstehen genau die blinden Flecken, die bei TSB später als Aufsichtsmängel benannt wurden. Governance ist damit kein bürokratischer Zusatzschritt, sondern die eigentliche Absicherung gegen Betriebsrisiken, die eine Migration mit sich bringt.

Objectway positioniert sich in diesem Feld als Anbieter, der die übergreifende Orchestrierung übernimmt und spezialisierte Lösungen über eine modulare, API-basierte Plattform verbindet. Das ist eine nachvollziehbare Geschäftslogik für einen Anbieter, der genau solche Projekte begleitet – Banken sollten diese Aussage entsprechend einordnen und nicht unkritisch übernehmen. Wer Orchestrierungsversprechen eines einzelnen Anbieters unhinterfragt übernimmt, verlagert das Abhängigkeitsproblem nur von vielen Einzelsystemen auf einen einzelnen Vertragspartner – das ist nicht automatisch besser, nur anders verteilt. Wer sich einen Eindruck vom Angebot verschaffen will, findet Details auf der Website des Unternehmens.

Kernbank-Architektur zwischen Kontrolle und Komplexität

„Die Zukunft gehört weder dem geschlossenen Monolithen noch einer beliebigen Sammlung von Einzellösungen“, resümiert im Brahm – ein Satz, der sich leicht unterschreiben lässt, aber wenig darüber aussagt, wie ein einzelnes Institut die Balance konkret herstellt. Das Kernbanksystem bleibt vielfach das stabile Fundament, neue Funktionen müssen sich flexibel ergänzen lassen, ohne dass die Bank die Kontrolle über das Gesamtsystem verliert.

Wir bei digital-magazin.de sehen in diesem Umbau vor allem ein Governance-Problem, kein reines Technikprojekt. Jede zusätzliche Komponente bedeutet einen zusätzlichen Vertrag, eine zusätzliche Schnittstelle, eine zusätzliche Stelle, an der Verantwortung diffundieren kann. Die EZB-Prioritäten und die T+1-Frist setzen dafür einen klaren Zeitrahmen – wer bis 2027 keine belastbare Architektur-Roadmap vorlegen kann, riskiert nicht nur Bußgelder in der Größenordnung des TSB-Falls, sondern auch das Vertrauen der eigenen Kunden.

Konkret heißt das für Entscheider: Anbieter-Versprechen zu Orchestrierung und Composability kritisch prüfen, Etappen realistisch planen und nicht vergessen, dass jede Migration – ob Big-Bang oder schrittweise – ein Kostenrisiko trägt, das sich erst im Betrieb zeigt. Wir bei digital-magazin.de werden diesen Umbau der Kernbank-Architektur weiter beobachten, denn die eigentliche Bewährungsprobe kommt erst, wenn die ersten Etappen live gehen.