Klassische Kernbankensysteme im Anwendungssystem Konglomerat

Welche Voraussetzungen muss ein Standard-Core Banking Systems erfüllen, um sich in die komplexe und heterogene Gesamtanwendungs- und Prozesslandschaft einer Bank optimal zu integrieren? Besonders im Umfeld der sich stetig wandelnden Anforderungen wie „Digitalisierung, und Big Data“.

Digitalisierung und Individualisierung von Finanzdienstleistungen und klassische Kernbankensysteme
© Shutterstock

Partner des Bank Blogs

Kurzer Rückblick in die historische Entwicklung von Standardsoftware in Bankensystemen

Im Gegensatz zu Industrie und Handel hat sich der Einsatz von Standardsoftware gegenüber Individualentwicklungen erst sehr spät in der Bankenwelt durchgesetzt. Die verschiedenen Geschäftsmodelle und Größendifferenzen der Banken und der Anspruch auf „Individualität“ erschwerten den frühzeitigen Einsatz von Standard-Anwendungssystemen. In diesem Spannungsfeld sind in den letzten 20 bis 30 Jahren mehrere Core Banking Systeme entstanden, die sich vor allem auf Wertpapier und klassischen Bank-Kernfunktionen konzentrieren. Dabei gab es ganz grob zwei Richtungen. Zum einen den Sparkassenverband und die Genossenschaftsbanken mit „geschlossenen“ eigenentwickelten Systemwelten und die Privatbanken mit zum größten Teil gekauften Standard-Anwendungssystemen.

Das Streben nach Verringerung der Fertigungstiefe und nach Erfüllung der technischen, regulatorischen und marktgetriebenen Anforderungen an Bankensysteme in einem vertretbaren Zeit- und Kostenaufwand hat dazu geführt, dass Dritt-Standard-Core Banking Systeme, vor allem bei den Privatbanken sowohl im Retailbereich als auch im Wealth Management Einzug hielten.

Damit dieses Vorgehen aber langfristig zielführend ist, müssen ausgewählte Standard Core-Banking System eine wohldefinierte Architektur, eine Serviceorientierung und vor allem ausreichende Serviceschnittstellen (API´s) nach „Außen“ besitzen. Das sind wichtige Voraussetzungen für eine erfolgreiche Integration an ein Standard-Core Banking Systems und die Integration anderer Systemen in die komplexe und heterogene Gesamtanwendungs- und Prozesslandschaft einer Bank.

Vor dem Hintergrund der immer weiter zunehmenden Digitalisierung und von „Big Data“ kommen vor allem den Serviceschnittstellen besondere Bedeutungen zu.

Serviceschnittstellen

Offen gelegte Schnittstellen eines Standard-Core Banking System kann man dabei grob (konkret in einem großen deutschen Standardsoftwaresystem auch so hinterlegt) in die folgenden Kategorien unterteilen.

• Serviceschnittstelle
  • Bereitstellung der Geschäftsvorfälle des Bankenbusiness.Die Herausforderung und „Kunst“ ist der fachliche Schnitt der bankfachlichen Services. Der fachliche Schnitt entscheidet, ob die Anforderungen, die z.B. die Digitalisierung an Kernbankensystem stellen erfüllt werden können.

• Dateischnittstelle
  • Standardisierte, meist extern vorgegebene Schnittstellen (z.B. SCHUFA, SWIFT, Bankverlag, SEPA, WM-Verlag…)
  • Schnittstellen zu Output-Managementsystemen (Nettodaten), Meldungswesen-Systeme, …

• User-Exit
  • User-Exit sind wohl definierte Stellen im Sourcecode des Standardsystems mit definierten Schnittstellen, in denen Veränderungen durch den Anwender zulässig sind.
  • User Exits bieten z.B. die Möglichkeit für zusätzliche Validierungen, algorithmische Erweiterungen, Differenzierungen in Prüfvorgängen,… durch den Anwender.

Problematik „Borderline“

Eine eindeutige Schnittstelle zwischen einem Standardsystem und den Kundensystemen ist oft fließend. Große Anbieter wie SAP haben dabei den Vorteil, aufgrund Ihrer Marktdominanz den Kunden eindeutige Adapterschnittstellen „aufzuzwingen“. Eingriffe in die Systemwelt einer SAP erfolgen auf eigenes Risiko des Anwenders.

Diese „Borderline“ ist aber gerade in anderen Standardsystemen oft so nicht gegeben bzw. nur unscharf definiert. Obwohl die Unveränderbarkeit der Interna ein Definitionsmerkmal von Standardsoftware ist, muss beachtet werden, das der Unterscheid zwischen Tailoring (Anpassung) und der Veränderung der Interna oft fließend ist.

Des Weiteren werden auch oft „private“ interne Schnittstellen benutzt. Das sind z.B.

• interne, temporäre Dateien.
• Datenbank-Tabellen.
• Druckaufbereitete Kundenmitteilung (statt Nettodaten).
• interne fachliche und technische Services aus verschieden Eben der eingesetzten Frameworks.

Diese internen Schnittstellen erfüllen nicht die Eigenschaften der offengelegten Serviceschnittstellen (abgeschlossen, wohldefiniert, versioniert, qualitätsgesichert und dokumentiert) und gefährden mit jedem neuen Release die Stabilität des Gesamtsystems.

Im Allgemeinen ist der Grad der kundenspezifischen Anpassungen (Abweichung vom Standard, Tailoring) auch ein gutes Maß für den Aufwand, der bei jedem neuen Release zur Stabilisierung und Qualitätssicherung zu leisten ist.

Fazit

Der Aufwand zur Qualitätssicherung von ausgewählter Standardsoftware durch Regressionstests, Aufbau diverser Testumgebungen beim Anbieter und Kunden, Simulation vom Echtzeitbetrieb und Performancetest, etc. ist bereits heute eine signifikante Größe bei den Banken.

Auf Grund der Korrelation vom Grad der Abweichung vom Standard der eingesetzten Standard-Core Banking Systeme und den Kosten zur Qualitätssicherung setzen die Banken vermehrt auf Individualisierung durch kundenspezifische Apps mit dem Ziel komplexe Änderungen an den Backendsystemen zu vermeiden.

Partner des Bank Blog – adesso

Mehr über das Partnerkonzept des Bank Blogs erfahren Sie hier.