Core Banking Radar

Neo Core Banking Systeme und ihr Beitrag zur IT-Architektur der Zukunft

Das Core Banking Radar von Swisscom in Zusammenarbeit mit dem Business Engineering Institute St. Gallen (BEI) beobachtet seit 2017 die Systemunterstützung von Banken und analysiert anhand eines umfangreichen Beurteilungsmodells die relevantesten Systeme für den Schweizer Markt. Hierzu wurden bereits 13 Kernbankensysteme gründlich untersucht und dokumentiert.

Text: Christine Popp, BEI, Bilder: Wendy Buck, Zense GmbH, 16. August 2022

Die Bankenlandschaft Schweiz zeichnet sich durch aktuell 243 Banken aus (Quelle: Statista, 2022), von denen fast alle auf einem Kernbankensystem eines uns bekannten Herstellers laufen. Die Systeme decken die Bedürfnisse einer Gesamtbank ab und haben unterschiedliche Schwerpunkte funktionaler und architektonischer Art. Wenige, wie beispielsweise die beiden Grossbanken, haben ihr eigenes Kernbankensystem.

Trends wie zunehmende Vernetzung Richtung Ecosystem und Embedded Banking werden die Bank der Zukunft prägen. Um in diesem Kontext entlang der «Customer Journey» (dem von den Kundinnen und Kunden durchlaufenen Prozess) Dienstleistungen bereitzustellen, müssen sich Banken auch in der Core-IT sich stetig wandelnden Herausforderungen stellen. Die kontinuierliche Antizipation dieses Wandels verlangt vorausschauende Flexibilität und eine stetige Investition in die Bankenarchitektur.

Dieser Artikel befasst sich mit der Systemunterstützung für Banken und wie sich diese in der zunehmend vernetzten Welt künftig ausgestaltet.

Trend: Vernetzung im Banking

Frau und Herr Schweizer sind zunehmend unsicher bezüglich ihrer Vorsorge und äussern dies bei einem Banktermin. Die Kundenberaterin geht auf die Möglichkeiten einer Lebensversicherung ein und erklärt deren Konditionen, falls jemand der beiden invalide würde. Den Vertrag unterschreiben sie direkt in der Bank.

So könnte eine Customer Journey im Bereich «Vorsorge» aussehen.

Konsumentinnen und Konsumenten verlangen vor dem Hintergrund zunehmender Unsicherheiten auch in der digitalen Welt nach einer Gesamtsicht ihrer finanziellen Absicherung. Initiativen wie beispielsweise das Swiss Pension Cockpit, welches eine übergreifende Sicht über die drei Vorsorgesäulen ermöglicht,
gehen bereits darauf ein.
Zudem gewinnt bei Dienstleistungen für Konsumentinnen und Konsumenten der Einsatz von IoT und damit die Vernetzung von physischen Gütern an Bedeutung. Im Lebensmittelgeschäft wollen sie mit der Smartwatch bezahlen, die Autoversicherung gewährt über das mittels Smartphones gemessene Fahrverhalten einen Rabatt oder die gefahrene Zugstrecke wird direkt bei der Bank abgebucht. Welche Anbieter dahinterstehen und dass dies die Vernetzung über Schnittstellen bedingt, spielt einem Grossteil der Kundschaft keine Rolle, Hauptsache es geht bequem und schnell.

Die klassische Customer Journey schaut längst nicht mehr nur die Beziehung einer Kundin oder eines Kunden mit der Bank allein an, sondern verändert sich Richtung eventgetriebener Interaktionen mit der Kundschaft. Banken versuchen, zusätzlichen Kundenmehrwert durch ihre Positionierung in Ökosystemen zu generieren, indem sie beispielsweise situativ Versicherungen anbieten. So ist in einer Customer Journey «Urlaub» denkbar, Frau Schweizer beim Einloggen ins e-Banking aus dem Ausland eine Reiseversicherung mit Sofortschutz anzubieten. Dies erfordert teilweise die Verarbeitung externer Daten (z.B. den Standort). Die Relevanz von Analytics, Machine Learning und Artificial Intelligence (AI) gewinnt entsprechend an Bedeutung. Im Gleichschritt steigt das Bewusstsein für und Know-how im Datenmanagement in der Finanzindustrie.

Vor dem Hintergrund von Entwicklungen wie Embedded Banking und Open Banking sind Banken darauf angewiesen, sich mit anderen Industrien zu vernetzen. Der Ausbau von Partnerschaften im Ecosystem geht nicht nur einher mit der Ausweitung digitaler Kommunikationskanäle, sondern auch mit der Förderung der Integrationsfähigkeit über APIs etc. und hoher technischer Standardisierung. Gleichzeitig ist die Individualisierung in der Customer Journey aus systemarchitektonischer Sicht ein Treiber für Microservices.

Es sind viele Anforderungen, denen die künftigen IT-Systeme der Bank gerecht werden muss.

Vier Veränderungsbereiche beeinflussen die zukünftige Banken-IT-Architektur massgeblich:

FinTechs, welche früher ergänzende Features (z.B. Personal Finance Management) beitrugen, sind heute fester Bestandteil des Bankings und nicht mehr aus Bankenarchitektur wegzudenken (siehe auch Swisscom FinTech Map).
Digitalisierung bewirkt ein dauerndes Spannungsfeld zwischen Individualisierung und Standardisierung. Individuelle Bedürfnisse der Konsumentinnen und Konsumenten müssen in der digitalisierten Welt mit standardisierten Anwendungen adressiert und erfüllt werden.
Es zeigt sich eine wachsende Entkopplung von Front- und Backoffice-Funktionalitäten. Während Backoffice-Funktionalitäten nach wie vor lange Lebenszyklen haben (15-30 Jahre), haben Frontoffice-Funktionalitäten sehr variable Lebenszyklen von teilweise wenigen Monaten bis zu mehreren Jahren.
Die herkömmliche zentrale Organisation von Banken, welche die Interaktion mit ihrer Kundschaft orchestriert, wird zumindest teilweise durch dezentrale Organisationsformen ersetzt. Dies wird insbesondere gestützt durch Technologien wie z.B. Blockchain, welche die Abbildung von unternehmensübergreifenden, dezentralen Strukturen ermöglichen. Ein weiteres Beispiel ist der Einbezug der Crowd bei der Durchführung von Tests oder der Meinungsbildung.

In der Umsetzung all dieser Entwicklungen ist die Ausrichtung der Banken-IT eine treibende Kraft und ein Unterscheidungsmerkmal, welche unter Berücksichtigung der eigenen strategischen Ausrichtung und anstehender Regulation kontinuierlich transformiert werden muss. In Zukunft sind IT-Architekturen zu erwarten, welche die Agilität steigern, die Adaptation aufkommender Technologien beschleunigen, die Verfügbarkeit von Schnittstellen erhöhen, sowie Modularität und Offenheit unterstützen.

Herausforderungen für die Systemunterstützung in der Bank

In der künftigen IT-Landschaft steht die Interaktion mit der Kundin und dem Kunden im Zentrum. Unter dem Aspekt der Serviceerbringung im Ecosystem ist zu definieren, wie die künftige Systemunterstützung auszusehen hat. Plakativ lassen sich deshalb zur Strukturierung der anstehenden Herausforderungen die drei Bereiche Kundenmanagement, Servicemanagement und Systemmanagement unterteilen.

Kundenmanagement

Werden Endkundinnen und Endkunden im Customer Journey bedient, bündelt die Bank im Rahmen des Kundenmanagements entweder selbst Services unter Integration externer Services (und hat damit die Gesamtsicht der Beratung respektive Kundeninteraktion) oder sie bettet ihre Services in die Customer Journey anderer Anbieter ein (siehe Abbildung 1).

Dazu muss sich die Bank entscheiden, in welchen Ökosystemen sie sich bewegen und welche Customer Journeys sie unterstützen möchte, welche Services sie selbst anbietet und welche sie effizienter auslagert. Die meisten Banken wollen die Beratung beispielsweise selbst anbieten und werden hier neben den eigenen Services vermehrt Services der Partner mit einbinden.

Drei Herausforderungs-Ebenen: Kundenmanagement, Servicemanagement, Systemmanagement

Servicemanagement

Die Orchestration der Services für Endkundinnen und Endkunden verlangt eine fachliche und eine technische Sicht auf die Integration mit Partnern.

Die fachliche Integration muss sämtliche Services, die die Bank den Kundinnen und Kunden anbietet, in einer partnerübergreifend einheitlichen Nomenklatur abbilden. Ausgehend von der Customer Journey werden also Bedürfnisse in Services übersetzt und beispielsweise in einem Katalog gebündelt. Dies unabhängig davon, ob die Services von der Bank selbst erbracht oder wie beim Beispiel der Versicherung über Partner einbezogen werden. Die Produktinformation muss bei allen beteiligten Partnern vorhanden sein. Nur so lässt sich koordinieren, welcher Anbieter welche Schritte übernimmt, wenn beispielsweise bei der von der Bank verkauften Lebensversicherung eine Invalidität eintritt.

Dies ist architektonisch ein Treiber für redundante Datenhaltung auf Seiten der Bank und der Versicherung und verlangt, wie auch die Integration von öffentlich verfügbaren Daten in die Services, eine hohe Kompetenz im Datenmanagement.

Die technische Integration muss kanalübergreifend sämtliche Informationen für die Kundschaft bereitstellen, über das Monitoring die Interaktion nachvollziehbar machen und die gemachten Transaktionen handhaben, sei es für Services von der Bank selbst (z.B. Kauf einer Aktie) oder dem Partner (z.B. Veränderung einer Lebensversicherung). In einem Archiv oder Data Hub sind sämtliche Daten für die Erstellung von Auswertungen und Analysen und insbesondere auch für die Bereitstellung des regulatorischen Reportings vorzuhalten.

Dies bedingt eine starke, auch über offene APIs orchestrierte Integrationsplattform. Darauf aufbauend muss das Servicemanagement über klare organisatorische wie auch technische Vereinbarungen (z.B. SLAs) zwischen den Akteuren verfügen. Nur so kann die verteilte und somit teilweise komplexe Leistungserbringung effizient organisiert und bei Problemen auch schnell reagiert werden. Die übergreifende Voraussetzung bei der Leistungserstellung für den Endkunden ist ein gemeinsames Verständnis der Governance im Ecosystem.

Systemmanagement

Im Rahmen des Systemmanagements bedingt das Bedienen der Endkundschaft im Ecosystem neben dem Betrieb des Kernbankensystems und zugehöriger eingebundener Umsysteme zunehmend die Integration von FinTechs oder weiteren Anbietern. Es stellt sich somit für die Bank und auch die Anbieter eines Kernbankensystems die Frage, ob und wie weit Funktionalität im Core abgebildet oder über Partner eingekauft werden soll. Das Kernbankensystem der Bank deckt mit seiner Buchungs-Engine sicherlich sämtliche von der Bank angeboten Services ab, welche eine Transaktion auslösen. Die vollständige Sicht auf die kundenseitigen Transaktionen wird künftig jedoch im Service Layer sein.

Die dargestellten Herausforderungen bewirken eine zunehmende Vernetzung im Ecosystem. Effiziente Kollaboration im Ecosystem kann nur durch (offene) Release-feste APIs organisiert werden. Die künftige Ausgestaltung der architektonischen Bausteinen und das flexible Agieren im Ecosystem verlangen ein entsprechend offenes System, was bei den meisten Banken in der Schweiz noch nicht gegeben ist. Anpassungen, um Daten frei aus dem Core zur Verfügung zu stellen und auch aufzunehmen, sind aufwändig und führen in gewachsenen Systemlandschaften oft zu weiterer kostentreibender Komplexität.

Bausteine für die IT-Architektur der Zukunft

In der künftigen Systemarchitektur einer Bank können in Anlehnung an die gewählte Struktur für anstehende Herausforderungen wiederum die drei Ebenen Kundenmanagement, Servicemanagement und Systemmanagement unterschieden werden. Diese werden ergänzt um architektonische Bausteine für die IT-Architektur der Zukunft.

Bausteine für die Systemarchitektur der Zukunft auf drei Ebenen

Architekturbausteine im Kundenmanagement umfassen alle Frontsysteme, den Data Hub, welcher Daten aller Quellen und Systeme verwaltet und die Durchführung von Analytics auf dem gesamten Datenvolumen erlaubt. Vielfach ist das übergreifende Datenmanagement noch in den Kinderschuhen.
Architekturbausteine im Servicemanagement umfassen mit dem Service Integration Layer die Logik, wie mit Partnern zusammengearbeitet wird, während der API Layer der Bank das Einholen von Informationen unterschiedlichster Anwendungen über APIs erlaubt. Die Nutzung von offenen Schnittstellen im Sinne des Open Bankings ist in der Schweiz noch wenig ausgeprägt.
Architekturbausteine im Systemmanagement umfassen das eigentliche Kernbankensystem bzw. deren Buchungs-Engine, welches alle kundenseitigen Transaktionen abwickelt, zudem oft eng eingebundene Umsysteme (z.B. für Credit Rating, das SNB Reporting oder das Portfolio Management) und Partner wie FinTechs oder Versicherungen in unterschiedlicher Integrationstiefe.

Nicht zuletzt dem vermehrten Fokus auf die Kundeninteraktion geschuldet, zeichnet sich ab, dass das Frontend der Bankenarchitektur in Zukunft Serviceleistungen nicht nur der eigenen Bank, sondern auch ihrer Partner im Netzwerk mit abbilden muss. Damit hat sie im Service Layer ein viel breiteres Servicespektrum zu handhaben als dasjenige, welches im eigenen Kernbankensystem abgebildet ist. Gleichzeitig besteht die Entwicklung, dass die Bank, getrieben durch den zunehmenden Druck der unternehmensübergreifenden Standardisierung, das Backend zunehmend verkleinert.

Die drei grundsätzlichen Strategien (wie in einem früheren Artikel beschrieben) bringen unterschiedlichen Potentiale und Risiken mit sich.

Grafik Bausteine IT-Architektur der Zukunft

Vereinfachte Übersicht der Architektur basierend auf drei grundsätzlichen Strategien

Strategie Core (Best of Suite):

Die Bank bezieht so weit wie möglich alle Funktionalitäten über das Kernbankensystem. Das heisst, die Bank lässt sich auch die Frontsysteme und den API Layer über das Kernbankensystem abdecken.

Damit verlässt sich die Bank weitgehend auf ihren Kernbankensystem-Provider und sollte eine enge Partnerschaft für gemeinsame Weiterentwicklungen mit diesem anstreben. Die Integration zusätzlicher Services im Ecosystem entlang der Customer Journey, wie beispielsweise Versicherungen, sind in Zusammenarbeit mit dem Systemhersteller abzubilden.

Strategie Front-to-Back:

Die Kundeninteraktion wird vermehrt durch weitere Systeme der Bank abgedeckt. Häufig wird dabei mit einer eigenen Integrationsplattform die Grundlage geschaffen. Während sich die Bank für die Backendfunktionalitäten weiterhin grundsätzlich auf das Kernbankensystem verlässt, findet bei den Services eine zunehmende Entkopplung vom Core statt. Häufig verarbeitet das CRM-System, welches selbst eine Frontlösung ist, die Daten. Ehemalige CRM-Systeme entwickeln sich zunehmend hin zu Plattformen, die weit über das angestammte Kernbankensystem mit den Kernbankenprozessen hinausgeht.

Modular (Best of Breed):

Je nach Anforderung der Bank werden die Funktionalitäten über verschiedene Anbieter modular zusammengesetzt. Dies verlangt eine hohe Integrationskompetenz und technologisches Wissen, welches in der Bank vorgehalten werden muss.

Bei Banken mit modularer Strategie ist insbesondere der Service Integration Layer und der API Layer auszuprägen. Als Buchungs-Engine dürften bei der modularen Strategie in Zukunft auch Neosysteme in Frage kommen, welche mit schlankem und performantem Kern die Best of Breed Strategie unterstützen.

Aufkommende Neo-Kernbankensysteme entwickeln sich kontinuierlich, gewinnen Marktanteile und werden mittlerweile bei bekannten Grössen wie N26 eingesetzt. Neuartige plattformorientierte Ansätze mit hoher Standardisierung, flexibler Datenhaltung kombiniert mit modularer serviceorientierter Architektur prägen diese Systeme. Mit dem Aufbau auf der grünen Wiese lassen sich z.B. pure SaaS Angebote viel konsequenter umsetzen. Gleichzeitig ist eine im Vergleich zu bekannten Kernbankensystemen eingeschränkte Funktionalität vorzufinden, die auf eine Einbettung in ein Ecosystem weiterer Systeme angewiesen sind. Nachfolgende Ausführungen charakterisieren aus dieser Sicht für die Schweiz relevante Systeme.

Übersicht massgeblicher Neo-Kernbankensysteme mit Interesse am Schweizer Markt

Im Gegensatz zu herkömmlichen Systemen bieten Neo-Kernbankensysteme mehr architektonische Flexibilität, aber auch weniger aus einer Hand. Alle Neosysteme sind (teilweise ausschliesslich) Cloud-fähig, basieren auf Microservices und verlangen eher ein umfangreiches IT-Knowhow in der Bank.

In der grundsätzlichen Funktionalität gleichen sich die Neosysteme, mit für den Retailbereich umfassender Abdeckung des Kerns (kundenseitige Transaktionsbuchung), des Bereichs Zahlen und ersten Kreditfunktionalitäten wie Hypotheken und Kredite. Zwei Systeme decken auch Funktionalitäten für Firmenkunden wie Betriebskredite ab. Der Wertschriftenteil ist bei allen ausser einem Neosystem noch nicht umgesetzt. Mit Ausnahme eines Systems, welches Schweizer Ursprungs ist, sind die Neo-Kernbankensysteme bisher nicht helvetisiert. Schweiz-spezifische Funktionalitäten wie z.B. die QR Rechnung oder regulatorische Vorgaben für die Berechnung der Tragbarkeit bei der Hypothekenvergabe müssten noch gebaut oder über Umsysteme abgebildet werden. Die Neo-Kernbankensysteme verzichten bewusst auf das Führen des Hauptbuchs (General Ledger), da sie beispielsweise die Lohnbuchhaltung ausserhalb ihres Kompetenzbereichs sehen. Auch die Benutzeroberfläche für Endkundinnen und Endkunden (eBanking, Mobile Banking) ist bei allen Neosystemen über Partner bereitzustellen.

In der grundsätzlichen Funktionsabdeckung gleichen sich die Neosysteme

Trotz grundsätzlich ähnlicher Abdeckung hat jedes System eine Differenzierung und eine individuelle Herangehensweise.

Mambu aus Berlin ist ein ausschliesslich auf der Cloud beziehbares Software-as-a-Service (SaaS) System, welches auf die Buchungs-Engine sowie Finanzierungsservices und Einlagen fokussiert. Hohe Standardisierung erlaubt Mambu, international zu skalieren. Das heisst, nach dem Motto «Configuration over Customization» haben grundsätzlich alle Banken eine identische Version mit der Möglichkeit, Produkte für sich spezifisch zu konfigurieren.

Über die API-Architektur bezieht Mambu flexibel externe Daten oder bindet Umsysteme der Bank mit ein. Die Daten liegen bei Mambu im Kern, inklusive konfigurierbarem Datenmodell zur Ablage und Verbindung strukturierter und unstrukturierter Daten. Zur Verarbeitung von Daten empfiehlt Mambu deren Streaming in ein Data Warehouse oder Data Lake.

Der Mambu Marketplace unterstützt Banken beim Aufbau ihres eigenen Ökosystems und dem Zusammenstellen ihrer spezifischen Best of Breed Lösung. Die länderspezifisch nötigen Kooperationen mit Partnerunternehmen erfordern eine ausgeprägte Integrationskompetenz (seitens Bank oder mit Hilfe von Mambus Netzwerk an System Integratoren), allerdings sprechen mehr als 160 Referenzinstallationen dafür, dass dies keine unüberwindbare Hürde darstellt. Die Möglichkeit, mit Mambu im übertragenen Sinn ein bezugsfertiges Haus mit Schlüsseln zu erwerben (URL, die sofort gestartet werden kann, mit API-Integrationspunkten), erfüllt im Markt einen Bedarf.

SolitX ist ein Transaktionssystem der Schweizer Firma Ariadne Business Analytics, das komplett auf die Transaktions-Abwicklung im Kern fokussiert und diese mit kundenspezifischen Finanzprodukten kombiniert.

Dabei basiert es auf dem algorithmischen ACTUS-Standard für Smart Contracts, der mehr als 99 % der weltweiten Finanzverträge abdeckt. Nach bankspezifischer Konfiguration dieser Smart Contracts ermöglicht SolitX grundsätzlich die Abdeckung der Funktionalität des gesamten Cores, der Buchführung sowie sämtlicher, auch helvetisierter Bankprodukte.

Neben dem Produktbereich Zahlen hat SolitX auch Anlageprodukte und jüngst Finanzierungsservices schon breit abgebildet.

Zur Kundschaft von Ariadne gehört beispielsweise die Schweizer Entwicklungsfirma einer Plattform, welche für Dienstleistungen wie Micro Finance oder Peer-to-Peer Lending die schnelle Entwicklung einer App erlaubt. Die Abwicklung der entsprechenden Finanzprodukte läuft über SolitX.

Für die Integration mit Umsystemen stehen ein technischer API Layer und ein DLT (Blockchain) Adapter bereit.

Tuum aus Estland zielt auf möglichst komplette Abdeckung der Bankfunktionalitäten, versucht mit wenig weiteren Partnern fehlende Funktionalität abzubilden und hält gleichzeitig die Plattform so offen wie möglich, um weitere Systeme bei Bedarf anschliessen zu können. Damit kombiniert Tuum die Vorteile einer modularen Strategie mit der Core Strategie (Best-of-Suite-Lösung).

Tuum, das je nach Bedarf auf der Cloud oder vor Ort installiert läuft, gruppiert seine Services in eigenständige Module (z.B. Core Modul mit Konten und Transaktionen, Karten-Modul, …) mit jeweils eigener Datenbank und erlaubt das Abkoppeln dieser Module und deren Anbindung an andere Core Systeme. So startet auch der Grossteil der Kundschaft von Tuum mit einzelnen Modulen und fügen dann nach Bedarf Schritt für Schritt weitere Funktionalitäten hinzu.

Vordefinierte Produkte, wie beispielsweise die elektronische Erfassung der Kundenunterschrift, erfordern wenig Programmierkenntnisse, dafür die Anpassung der Bankprozesse an den Standard von Tuum. Neben dem Retail- unterstützt Tuum auch das Firmenkundengeschäft, insbesondere mit Betriebskrediten. Zudem gestattet Tuum die Nutzung seiner Funktionalitäten durch bankfremde Industrien in Form von «Embedded Banking Use Cases» entlang der Customer Journey und hat mehrere Nicht-Bankenkunden aus verschiedenen Branchen.

Vault Platform (bestehend aus Vault Core und Vault Payments) des in Grossbritannien ansässigen Banktechnologieunternehmens Thought Machine beruht auf dem Grundprinzip des Einsatzes neuster Technologien für hohe Leistung und Konfigurierbarkeit. Die Kernfunktionalitäten sind Transaktionsbuchung, Kontoführung und Produktentwicklung (Vault Core) und seit diesem Sommer auch Karten- und Zahlungsverarbeitung (Vault Payments). Jedes Finanzprodukt im Vault Core wird über Smart Contracts dargestellt, was die schnelle Einführung neuer Produkte (selbst mittels Python programmiert oder aus der Product Library) und Anpassung auf individuelle Bedürfnisse der Endkundschaft erlaubt. Die Architektur dieses Systems basiert auf möglichst granularen Microservices mit jeweils eigenen Datenbanken.

Die Idee hinter Vault Core ist, Funktionalitäten und Services je nach Bedarf über offene Schnittstellen anzubinden. Um schlank zu sein, verzichtet Vault auf den General Ledger (GL) beziehungsweise das Angebot der Hauptbuchführung, hingegen überträgt das Nebenbuch als «single source of truth» Transaktionen aller bankbezogenen Produkte in Echtzeit über den General Ledger in das Data Warehouse der Bank.

Die Vault Platform lässt für zukünftige architektonische Entwicklungen von Banken alle Möglichkeiten offen und kann von Banken mit hoher Tech-Affinität an ihr existierendes System angebunden werden.

Leveris war eine integrative Plattform mit modularer und skalierbarer Architektur, welche auf Datenauswertung und -nutzung in Echtzeit setzte. Dabei mischte es Microservices, Open API und Data Lake mit herkömmlichen Ansätzen wie Oracle und PLSQL-Technologien. Im Juli 2021 verkündete Leveris die Einstellung der Geschäftstätigkeit. Genannte Gründe waren die Verlangsamung des Investitionsmarktes durch Covid-19 und das Scheitern eines bedeutenden Finanzierungsgeschäfts.

Die nachfolgende Übersicht stellt ausgewählte Kerncharakteristika der untersuchten aktiven Neobankensysteme gegenüber.

Charakteristika der bisher im Core Banking Radar untersuchten Neo-Kernbankensysteme

Die Marktdynamik bei den Neo-Kernsystemen ist ausserordentlich hoch. Der Kernbankenradar beobachtet diese Entwicklung aus Sicht der Schweiz und hat zu weiteren Herstellern wie z.B. 10X oder SaaScada bereits Kontakt aufgenommen.

Sowohl für die Banken wie auch für die Hersteller von Kernbankensystemen kann die Kooperation und Nutzung solcher agilen und aufgrund reduzierter Komplexität kostengünstigeren Plattformen über kurz oder lang eine lohnende Alternative für die Transformation und Weiterentwicklung der eigenen Systemlandschaft darstellen. Dies gilt für jede der grundsätzlichen Strategien zur Weiterentwicklung (vgl. oben) und vermeidet grundsätzlich einen Big Bang, welcher über lange Zeit umfangreiche Ressourcen bindet.

Fazit

Digitalisierung, Embedded Banking und Open Finance verlangen von den Banken vermehrt systemgestützte Zusammenarbeit mit Partnern. Banken müssen sich zunehmend in Ökosysteme einbringen, um so der Kundschaft basierend auf deren Bedürfnisse Services entlang des individuellen Customer Journeys anzubieten. Dazu ergänzen Banken Services aus dem Ökosystem anderer Partner bei sich selbst oder positionieren sich mit ausgewählten eigenen Services in anderen Ökosystemen.

Dies stellt neue Systemanforderungen an Banken und Hersteller. Die künftige Systemarchitektur von Banken lässt sich mit architektonischen Bausteinen auf drei Ebenen beschreiben: Kundenmanagement, Servicemanagement und Systemmanagement.

Die Ausprägung der Bausteine ist je nach strategischer Ausrichtung der Systemunterstützung unterschiedlich. Bei der Umsetzung ihrer jeweiligen Strategie können auch Neo-Kernbankensysteme eine Rolle spielen. Die Neo-Kernbankensysteme haben unterschiedliche Charakteristika, eine moderne Architektur und entwickeln sich schnell.

Ein Wechsel dürfte aber erst mittel- bis langfristig zur Debatte stehen. Aktuell besteht in der Schweiz noch keine erfolgreiche, umfangreiche Implementation eines Neo-Kernbankensystems. Zusätzlich ist der Aufwand für die notwendige Helvetisierung noch zu erbringen. Die untenstehende Tabelle zeigt plakativ unterschiedliche Ausprägungen von Neo-Kernbankensystemen und etablierten Kernbankensystemen. Hauptaugenmerk ist sicherlich die fokussierte funktionale Abdeckung der Neo-Kernbankensysteme im Gegensatz zu den etablierten Kernbanksystemen.

Unterschiede Neobankensysteme und etablierte Kernbankensysteme

Unterschiede Neo- und etablierte Kernbankensysteme

Banken haben grundsätzlich zwei Varianten zur Weiterentwicklung ihrer Systemarchitektur:

Sie arbeiten mit ihrem Kernbankensystem-Hersteller für die Bereitstellung architektonischer Bausteine zur Öffnung zusammen (Core Strategie), denn auch etablierte Kernbankensystemhersteller müssen sich mit Vernetzung und Kooperationsfragen auseinandersetzen.
Sie suchen innerhalb der beschriebenen Architekturbausteine die Zusammenarbeit auch mit Neo-Kernbanksystemen und setzen bei einer gewissen Grösse die Kraft für einen guten Integrations-Layer zur Öffnung ein (Front-to-Back und modulare Strategie).

In beiden Varianten lohnt es sich, Veränderungen zu beobachten und mit Partnerschaften sowie organisationsübergreifendem Servicemanagement Erfahrungen zu sammeln. Zudem empfiehlt sich, systematisch Teilstrategien zu Datenmanagement, Analytics und AI zu formulieren, um die zunehmende Redundanz der Daten abzufangen.

Mit der Ableitung verkraftbarer Transformationsszenarien hin zur Architektur der Zukunft (bezüglich Ressourcen, Geld, Zeit) wird sich einer der folgenden Core Banking Radar Artikel beschäftigen.

Quelle: