Geänderte Anforderungen des Marktes an Softwaresysteme für Risk und Regulatory Reporting

Viele Institute haben im Risikomanagement und Regulatory Reporting historisch gewachsene Architekturen und IT-Systeme im Einsatz. Diese Systeme sind häufig monolithisch aufgebaut und über die Jahre sukzessive erweitert worden. Notwendig werdende Anpassungen gestalten sich zunehmend aufwendig und langwierig. Hinzu kommt, dass jedes System in der Regel seine eigene Datenhaltung mitbringt. Das Gesamtsystem besteht in diesem Fall aus einer Vielzahl an unterschiedlichen Datentöpfen, verbunden mit einer hohen Datenredundanz und der Notwendigkeit, die Daten synchron und konsistent zu halten.

Auf diese Situation hat die Aufsicht reagiert und in den letzten Jahren insbesondere mit BAIT (Bankaufsichtliche Anforderungen an die IT) und BCBS239 (Grundsätze für die effektive Aggregation von Risikodaten und die Risikoberichterstattung) Vorgaben und Richtlinien veröffentlicht, die auf die Konsistenz der Daten und Methoden sowie die schnelle Verfügbarkeit von Informationen fokussieren. Redundante Daten und damit die Gefahr von inkonsistenten Datenständen sind möglichst zu vermeiden. Zusätzlich ist die Nachvollziehbarkeit der Datenlieferstrecke und Verarbeitungswege zu ermöglichen und transparent zu machen.

Um diese Anforderungen zu erfüllen, stehen inzwischen neue technische Möglichkeiten zur Verfügung. In den letzten Jahren sind insbesondere in den Bereichen Cloud, Big Data, künstliche Intelligenz (KI) und Business Intelligence (BI) moderne Systeme entstanden, deren Einsatz bei zukünftigen Risk-und-Regulatory-Reporting-Lösungen nicht mehr wegzudenken sind.

Im Mittelpunkt vieler neuer Architekturen steht das zentrale Data Warehouse (DWH)

Um redundante Daten und damit die Gefahr von inkonsistenten Datenständen zu vermeiden und zusätzlich die Nachvollziehbarkeit der Datenlieferstrecke und Verarbeitungswege zu ermöglichen, setzen viele Institute bei neuen IT-Architekturen für Risk und Regulatory Reporting auf einen zentralen Datenhaushalt und damit auf ein zentrales DWH.

Diese zentralen DWH-Lösungen können entweder kundenindividuell konzipiert und umgesetzt oder eine Standardlösung sein, die zahlreiche Vorteile mit sich bringt. Dies wird im Folgenden am Beispiel der FSDP dargestellt.

Die FSDP als zentrales DWH im SAP-Umfeld

FSDP steht für „Financial Services Data Platform“ und ist ein von SAP entwickeltes Produkt für das Kernbankgeschäft innerhalb des Finanzdienstleistungssektors, das die Daten unterschiedlicher Bankbereiche an einer zentralen Stelle bündelt. Es nutzt die HANA-2.0-Technologie und hat eine standardisierte Anbindung an zahlreiche S/4HANA-Umsysteme.

Die FSDP bringt das fachliche Datenmodell (FSDM) für Risk und Regulatory Reporting und weitere Themenfelder wie Accounting und Customer Analytics bereits mit. Somit müssen die Nutzer kein eigenes fachliches Datenmodell konzipieren und umsetzen, sondern können auf ein bereits bestehendes und erfolgreich in der Praxis eingesetztes Datenmodell aufsetzen. Das fachliche Datenmodell wird im Standard erweitert und an neue Anforderungen angepasst.

Auch technisch bringt die FSDP eine Vielzahl von Funktionen und Möglichkeiten mit, die nicht individuell und neu implementiert werden müssen. Hier sind insbesondere die Historisierungs- und Versionierungsfunktionalitäten hervorzuheben, auch bekannt unter dem Begriff „bitemporale Datenhaltung“. Darüber hinaus kann die SAP-Lösung SAC (SAP Analytical Cloud) standardisiert auf die Daten der FSDP zugreifen, diese weiterverarbeiten und visualisieren.

Anforderungen an Risk-und-Regulatory-Lösungen zur optimalen Nutzung eines zentralen DWHs

Eine wichtige Anforderung ist, dass die fachlichen Komponenten vom Datenhaushalt entkoppelt sein müssen. Für bisher monolithische Softwaresysteme bedeutet dies, bestehende Software-Assets zu entkoppeln, zu modularisieren, die Architektur zu öffnen und interdisziplinäre Nutzungsmöglichkeiten zu schaffen.

Die folgenden Darstellungen zeigen beispielhaft das Architekturprinzip der „Open Risk & Reporting Platform“ (ORRP) von msg for banking. Nach diesen Architekturprinzipien werden die aktuellen Softwaresysteme THINC und BAIS sukzessive in die neue Architektur überführt.

Durch die architektonische Öffnung und Entkopplung vom DWH ergeben sich unterschiedliche Einsatzszenarien. Die fachlichen Komponenten können entweder mit einem Standard-DWH von msg, mit einem Standard-DWH von SAP (in unserem Beispiel die FSDP) oder auch mit einem kundenindividuellen DWH passgenau verzahnt werden.

Der Datenadapter als wichtiges Verbindungsglied

In allen drei oben dargestellten Einsatzszenarien bilden Datenadapter jeweils den Schlüssel zum Erfolg oder die Brücke zwischen DWH und Fachkomponenten. Insbesondere im Szenario SAP steht man hier jedoch nicht nur vor der Herausforderung, dass man die Daten fachlich mappen muss, sondern auch, dass die Systeme teilweise auf unterschiedlichen Technologien basieren. Hier hilft der FSDP2msg4banking-Adapter, indem er die Non-SAP-Systeme, die zum Beispiel auf Java-Technologie basieren, mit der HANA-2.0-Technologie des SAP-Banking-Produkts FSDP verbindet.

Der FSDP2msg4banking-Adapter als Schlüssel zum Erfolg in Kombination mit der FSDP

Bei dem FSDP2msg4banking-Adapter handelt es sich um eine standardisierte Softwarekomponente von msg for banking, die auf der SAP FSDP aufsetzt und die msg-for-banking-Komponenten mit den benötigten Inputdaten versorgt.

Durch Customizing des Adapters können die Daten von der FSDP an die Komponenten von msg for banking übergeben und in das Zielformat transformiert werden. Funktionen ermöglichen das Mapping von in- kompatiblen Typen, wie zum Beispiel alphanumerisch zu numerisch, über ein Referenzmapping. Zusätzlich werden die Ergebnisse aus den msg-for-banking-Komponenten über den Adapter auch wieder in der FSDP abgelegt. Durch das „Rückspielen“ der Ergebnisdaten wird die FSDP als zentraler Datamart ideal genutzt.

Erweiterungsmöglichkeiten im Adapter und Konfigurationsmöglichen erlauben eine Kundenerweiterbarkeit an den entscheidenden Stellen. So sind als Beispiel in den Leseschnittstellen kundenspezifische Felder zur Befüllung vorgesehen.

Für das Zusammenspiel zwischen FSDP und msg-for-banking-Lösungen gelten folgende Grundprinzipien:

• Die SAP-HANA-Plattform wird als Primärplattform im Rahmen des Standards unterstützt.
• Für die Anbindung der FSDP wird die SAP-Standard-Integrationsarchitektur mit entsprechenden Schnittstellen zum Lesen der relevanten Eingangs- daten aus FSDP und Ablegen der relevanten Ergebnisse in der FSDP eingesetzt.
• Die FSDP ist der zentrale Datamart für die Verwaltung, Pflege und Korrektur von Daten und damit Datenquelle für standardisierte Reportingtools, wie die SAP-SAC, Tableau, Power-BI und weitere.

Synergien durch die Nutzung des ADWEKO Universal Adapters als Bestandteil des FSDP2msg4banking-Adapters

Der ADWEKO-Universal-Adapter ermöglicht eine schnelle Integration von analytischen und regulatorischen Lösungen für Meldewesen und Riskmanagement wie die msg-for-banking-Lösung. Er basiert auf einem Framework, das fertige Schnittstellen für die fachlichen Produkte und Entitäten der FSDM bereitstellt und somit das Mapping zu dem Datenmodell der Ziellösung erleichtert. Die bereitgestellten Schnittstellen beinhalten bereits die Best Practices, die in FSDM-Implementierungsprojekten gesammelt wurden. Um individuelle Besonderheiten der Kunden zu berücksichtigen, lässt der Universal-Adapter die Konfigurationen der Mappings durch den Implementierungspartner oder den Kunden zu.

Die Nutzung des Universal-Adapters als Bestandteil des FSDP2msg4banking-Adapters ermöglicht es, auf einer in der Praxis bereits bewährten Teilkomponente aufzusetzen. Somit wird die Synergie der beiden Adapter optimal genutzt.

msg-for-banking-spezifische Erweiterungen einfach und flexibel über die Extensions von msg for banking möglich

Zusätzliche Daten können flexibel über Extensions ergänzt werden. Hierbei können Extensions sowohl an FSDP-Standardentitäten umgesetzt werden als auch neue Entitäten in den msg-for-banking-Extensions. Für alle Extensions gilt, dass auch für diese Daten die Standardfunktionen und -tools der FSDP genutzt werden können. Das heißt, die (Extensions-)Daten verhalten sich analog zu den Standarddatenfeldern der FSDP. In den msg-for-banking-Extensions werden zum Beispiel berechnete Ergebnisse der msg-for-banking-Lösungen zur Weiterverarbeitung abgelegt.

Nutzen von Add-ons am Beispiel der Versionierungs- und Historisierungsfunktionalitäten

Add-ons ermöglichen die Nutzung von erweiterten Funktionalitäten. So können für das Write-back von Daten in die FSDP die Daten zum Stichtag revisionssicher mithilfe von Add-ons historisiert werden.

Die SAP FSDP bietet eine bitemporale Datenspeicherrung in der HANA, die sowohl für die FSDP-Standarddatenentitäten als auch für die msg-for-banking-Extensions genutzt werden kann. Durch diese Funktionalitäten besteht die Möglichkeit, sich die Daten nicht nur für einen bestimmten Stichtag aus der FSDP zu laden, sondern innerhalb des Stichtags auch noch nach verschiedenen Datenversionen unterscheiden zu können. Dies ist insbesondere zur Unterscheidung von nachträglich durchgeführten Korrekturen von großer Bedeutung und Nutzen.

Entscheidende Vorteile der FSDP sind die bitemporale Datenhaltung der FSDP in Kombination mit dem fachlichen Datenmodell, eine Vendor beziehungsweise kundenspezifische Erweiterbarkeit und die Weiterentwicklung der Lösung im Standard. Durch die Integration der msg-for-banking-Lösungen über den FSDP2msg4banking-Adapter werden die Vorteile der FSDP vollständig auch für die Gesamtlösung genutzt.

Fazit

Datenadapter sind der Schlüssel zum Erfolg, um die Vorteile von unterschiedlichen Softwarekomponenten übergreifend zu nutzen. Voraussetzung ist jedoch, dass die einzelnen Softwarekomponenten für diesen Einsatz geeignet sind. Die ORRP-Architektur gibt die Leitplanken für die msg-for-banking-Komponenten vor. Standard-DWH-Lösungen wie die FSDP ermöglichen die nahtlose Verzahnung der Systeme und die Nutzung technischer und fachlicher Mehrwerte lösungsübergreifend.