Die Entwicklung der Kernbankenplattformen: Wie wir hierher gekommen sind. Nächste Schritte

Von: Niloy Sengupta

Kernbankensysteme eignen sich nicht für aufsehenerregende Werbekampagnen.

Bei diesen, oft als Legacy-Technologie bezeichneten Anwendungen, handelt es sich um geschäftskritische Anwendungen, die tägliche Transaktionen, Kontoaktualisierungen und mehr verarbeiten. Banken locken ihre Kunden mit dem Versprechen von Bequemlichkeit und finanzieller Sicherheit, aber es sind die Kernsysteme, die die Arbeit leisten.

Diese Kernsysteme stellen in der Regel auch Hindernisse dar, wenn Manager eine Modernisierung anstreben.

Da heutzutage so viel Aufregung um die Transformation im Bankenwesen herrscht, ist es hilfreich, sich daran zu erinnern, wie Kernsysteme zum Gegenstand der Diskussion in der Führungsetage wurden. In diesem Beitrag werfe ich einen Blick zurück, um einen Blick nach vorn zu werfen, wie Banken ihre wichtigsten Anwendungen erfolgreich modernisieren können. 

Die Geburt der Kernbankensysteme

Die ersten Kernbankensysteme kamen in den 1980er Jahren auf den Markt und lösten die Banken von der jahrhundertealten Praxis handgeschriebener Journale und Hauptbücher ab.

Banken benötigten die Möglichkeit, große Transaktionsvolumina schnell, zuverlässig und effizient abzuwickeln. So entstanden die Kernbankensysteme der ersten Generation¹, die Zentralisierung, Geschwindigkeit, Skalierbarkeit und Zuverlässigkeit boten. Diese Systeme wurden in den Sprachen COBOL, Assembler, PL/I und JCL geschrieben und waren monolithisch, mit einer engen Kopplung aus zugrunde liegenden, abhängigen Geschäftsmodulen wie Kunden, Transaktionen und Produkten.

Diese Anwendungen unterstützten nur die Stapelverarbeitung und die Buchung erfolgte am Ende des Tages. Intraday-Salden könnten durch Workarounds wie die Veröffentlichung von Memos verfügbar gemacht werden. In solchen Anwendungen waren Geschäftslogik und Datenzugriffslogik stark miteinander verwoben² und die Trennung der beiden wurde zur Herausforderung.

Die zweite Generation von Kernbankensystemen

In den späten 1980er- und frühen 1990er-Jahren weiteten die Kernbankensysteme der zweiten Generation den Markt auf regionale und kleinere Banken aus. Die neuen Kernsysteme führten kostengünstigere N-Tier-Architekturen ein, die Echtzeitverarbeitung unterstützten und die Trennung der Front-End-Geschäftslogik von der Mid-Tier-Geschäftslogik und der Datenzugriffslogik ermöglichten.

Die Architektur dieser Anwendungen war in der Regel produktzentriert; die Produkte waren einfacher zu erstellen und zu konfigurieren, und es wurden mehrere Integrationsmethoden eingesetzt. Da die Anwendungen von vornherein einfacher und parametergesteuert waren, konnten die Banken neue Produkte, Funktionen und Preise in kürzerer Zeit auf den Markt bringen.³

Der Aufstieg des Internets in den 1990er Jahren förderte das Wachstum von Kassierern, Filialbanken und Online-Banking-Anwendungen. Die Investitionen in Kernbankanwendungen gingen erheblich zurück und es traten schnell Integrationsprobleme zwischen dem Front-End und den Kernsystemen auf.

Um diese Einschränkungen zu überwinden, entwickelten oder kauften Banken serviceorientierte und nachrichtengesteuerte Middleware-Anwendungen, die eine einfachere und lose gekoppelte Integration zwischen Front- und Back-End-Anwendungen ermöglichten. Branchen-Frameworks wie IFX, FIX und FpML versuchten, die Standardisierung und Interoperabilität zwischen verschiedenen Institutionen zu gewährleisten.

Die dritte Generation der Kernbankensysteme

In den 2010er Jahren beschleunigten die Banken die Einführung des digitalen Bankings mit Cloud-Technologien. REST-APIs und JSON wurden zu beliebten Technologien für Datenaustausch und -integration.

Mit der wachsenden Zahl von FinTechs, die Nischen- und Punktlösungen anbieten, die das Kundenerlebnis verbessern, verspürten die Banken den Druck, mit den FinTechs zusammenzuarbeiten und die Integration zu ermöglichen. API und Cloud wurden zur treibenden Kraft, die weitere Änderungen an den Kernbankensystemen der ersten und zweiten Generation vorantrieb.

Traditionelle Banken haben ihre Legacy-Kerne so weit angepasst, dass Cap Currency, also die Praxis, Software in der aktuellsten Version zu pflegen, nicht mehr praktikabel ist. Die Plattformanbieter witterten eine neue Chance und begannen, ihre Plattformen durch eine Kombination aus neuen architektonischen Mustern und der Umgestaltung der Kernbankenplattformen der zweiten Generation für die Cloud umzugestalten.⁴

Die meisten dieser Core-Apps der dritten Generation sind als Microservices konzipiert. Containerisiert können sie in einer oder mehreren öffentlichen Cloud-Umgebungen ausgeführt werden und sind für die Transaktionsverarbeitung in Echtzeit konzipiert. Ihre Microservice-gesteuerte Architektur entkoppelt Geschäftsfunktionen wie Kunden- und Kontoverwaltung, Transaktionsverarbeitung, Kontoauszüge und Berichterstattung.

APIs sind natürlich die bevorzugte Integrationsmethode für diese neuen Kerne, und die meisten Anbieter bieten auch ihre eigenen paketierten API-Gateway-Anwendungen an, die Vorintegrationen mit internen Anwendungen und einigen Anwendungen von Drittanbietern bieten, um die breite Palette von Bankdienstleistungen wie Kundeneinführung, Kundenbetreuung, Geldbewegungen, Kartenverwaltung und andere Zusatzdienste zu unterstützen.⁵

Die nächste Generation: Kombinierbare Kernbankensysteme

In den letzten Jahren sind mehrere neue Kernbankenanbieter auf den Markt gekommen. Sie bieten die nächste Generation von Kernanwendungen, die viele Design-Ähnlichkeiten mit den Kernen der dritten Generation aufweisen, mit einigen bemerkenswerten Unterschieden. Die Kerne der nächsten Generation sind wirklich cloud-nativ und wurden von Grund auf mithilfe von Microservices ohne überarbeiteten Code entwickelt.⁶

Einige dieser Anwendungen verwenden modernste Programmiersprachen wie Golang und RUST und übernehmen neuere Datenbanken wie PostgreSQL. Darüber hinaus werden solche Apps als eine Reihe von „Headless“-APIs angeboten, die flexible Integrationsoptionen ermöglichen, ohne zu versuchen, die Bank an einige wenige Anbieter zu binden. Solche Designmuster machen die Kerne „zusammensetzbar“, indem sie die architektonische Leinwand öffnen und den Banken die Flexibilität bieten, sie parallel zu ihren bestehenden Kernen auszuprobieren, ohne die alten Kerne vollständig migrieren zu müssen.⁷

Einige Anbieter bieten Nischenlösungen wie Produkt-, Preis- und Abrechnungsmodule sowie Kundendienstanwendungen, die für die Cloud entwickelt wurden. Auch wenn diese Anwendungen ein Kernbankensystem möglicherweise nicht vollständig ersetzen, sollen sie doch mit anderen cloud-basierten Kernen zusammenarbeiten und ein wesentlicher Bestandteil des zusammensetzbaren Kernökosystems werden.⁸

Diese jüngsten Fortschritte in den Kernbankensystemen ermöglichen schnelle Innovationen, die es Banken ermöglichen, mit neueren Anwendungsstacks und Migrationsmustern zu experimentieren.

Unterschiedliche Wege zu einem modernen Kern

Kernsysteme der älteren Generation waren darauf ausgelegt, große Transaktionsvolumina effizient und sehr zuverlässig abzuwickeln. Obwohl New-Age-Systeme agil und flexibel sind und zahlreiche Geschäftsvorteile bieten, fallen sie in dieser Hinsicht immer noch hinter ihre älteren Pendants zurück. Dies ist der Hauptgrund, warum man von Legacy-Kernsystemen so schlecht weg kommt. In der Vergangenheit war die Modernisierung des Kernbankwesens eine riskante und kostenintensive Initiative, bei der ein großer Ersatz die einzige Wahl war.

Heutzutage gibt es mehrere Wege zur Kernmodernisierung, die Risiken, Kosten und Aufwand optimieren. Banken können einen iterativen und stetig fortschreitenden Modernisierungsansatz verfolgen. Zu einigen Beispielpfaden gehören:

• Cloud-nativer Kern: Richten Sie cloud-native Kerne für einfachere Servicelinien wie rein digitale Kanäle ein und skalieren Sie diese Anwendungen stetig, indem Sie nach und nach andere Servicelinien vom Legacy-Kern abziehen.
• Ein Übergangskonzept: Eine Variante des cloud-nativen Kerns, aber hier können die Banken erwägen, einfachere Produktlinien wie Sparkonten und Einlagenzertifikate auf die neuen Kerne zu verlagern, bevor sie Girokonten oder Kredite verlagern. Alternativ könnte eine Bank einige Kundensegmente auf der Grundlage von Geografie oder Kaufverhalten in den neuen Kern verschieben und danach iterieren.
• Den alten Kern aushöhlen: Verlagern Sie Geschäftsfunktionen wie Produkt- und Preismanagement, Kundenmanagement, Kontoauszüge und Dokumentenmanagement aus dem Kern. Dieser Ansatz wird den Kern auf ein einfaches Transaktionsbuch reduzieren, sodass Banken Microservices entwickeln oder kaufen können, um die ausgehöhlten Module zu ersetzen.
• Ein hybrider Ansatz: Kombinieren Sie die Vorteile des Mainframes und der Cloud, indem Sie den lokalen, Mainframe-basierten Kern in eine zCloud-Umgebung verlagern. Dieser Schritt kann als Zwischen- oder Zielzustandslösung fungieren. Dieser Ansatz bietet der Bank eine gewisse Flexibilität, um eine Entscheidung über den Wechsel vom Mainframe zu treffen, ohne die Vorteile der Cloud zu verlieren.

Unabhängig davon, für welchen Weg sich die Banken entscheiden, darf die Modernisierung des Kernbankgeschäfts nicht einfach als eine weitere technologische Umstellung betrachtet werden. Änderungen des Betriebsmodells – insbesondere die Umgestaltung von Geschäftsprozessen und das Management von Personalveränderungen – müssen die technologischen Veränderungen ergänzen.

Die Entwicklung der Kernbankensysteme geht weiter

Die Entwicklung der Kernbankensysteme zeigt, warum und wie diese Systeme entworfen und gebaut wurden, um den Geschäftsanforderungen der Vergangenheit gerecht zu werden. Wenn sich die Geschäftsanforderungen weiterentwickeln, liefert uns das Verständnis ihrer Entwicklung eine Richtung und Leitlinien für die Änderung dieser Systeme. Indem wir aus Fehlern der Vergangenheit lernen, können wir neue Möglichkeiten für zukünftige Innovationen erkennen.

Niloy Sengupta ist Financial Services Consulting Partner bei Kyndryl

¹Beispiele für Kernbankensysteme der ersten Generation in den USA: Systematics (FIS), Hogan (DXC) und Trisyn
²Beispiel: Die Verwendung von Prozesssteuerungsdaten in Hogan
³Es gibt viele Beispiele: Profile (FIS), DNA und Premier (Fiserv), Silverlake, CoreDirector, CIF 20/20 (Jack Henry), Bancs (TCS), Finacle (Infosys), Flexcube (Oracle) und T24 (Temenos)
⁴Sie haben keinen neu gestalteten Code aus der Vergangenheit. Dies hat einige Innovationen ermöglicht, wie die Verwendung von Programmiersprachen der nächsten Generation wie GoLang in Finxact.
⁵FIS führte die Modern Banking Platform (MBP) ein und Temenos wandelte T24 in Transact um. Fiserv, Jack Henry, Infosys, TCS, Oracle und Finastra entwickelten alle Cloud-Versionen ihrer beliebten Kernanwendungen.
⁶Zwei verschiedene Wege rund um diese Integration sind sichtbar. Unternehmen wie FIS, Fiserv und Oracle integrieren Anwendungen aus ihrem Produktportfolio vor und versuchen so, ihre Kunden so weit wie möglich an ihr eigenes Ökosystem zu binden. Auf der anderen Seite bieten TCS, Infosys, Temenos und andere einen Marktplatz-Ansatz an, bei dem verschiedene Drittanbieter-Anwendungen für die Interoperabilität mit ihren Kernsystemen über APIs zertifiziert sind.
⁷Diese Kernanbieter verfügen auch über einen großen Marktplatz von Drittanbieteranwendungen, die für die Interoperabilität zertifiziert sind und mit offenen Rahmenwerken der Bankenbranche wie ISO 20022 und BIAN übereinstimmen.
⁸Bei einigen dieser Anwendungen handelt es sich um Produkt-, Preis- und Abrechnungs-Engines, wie sie von Zafin, SunTec oder Oracle RMB angeboten werden. Kundenservice und Onboarding-Anwendungen wie Savana gehören ebenfalls zu dieser Kategorie.