Aufrufe
vor 11 Monaten

die bank 03 // 2015

  • Text
  • Banken
  • Unternehmen
  • Diebank
  • Anforderungen
  • Deutschland
  • Banking
  • Digitalisierung
  • Institute
  • Insbesondere
  • Regulatorischen
die bank gehört zu den bedeutendsten Publikationen der gesamten Kreditwirtschaft. Die Autoren sind ausnahmslos Experten von hohem Rang. Das Themenspektrum ist weit gefächert und umfasst fachlich fundierte Informationen. Seit 1961 ist die bank die meinungsbildende Fachzeitschrift für Entscheider in privaten Banken, Sparkassen und kreditgenossenschaftlichen Instituten. Mit Themen aus den Bereichen Bankmanagement, Regulatorik, Risikomanagement, Compliance, Zahlungsverkehr, Bankorganisation & Prozessoptimierung und Digitalisierung & Finanzinnovationen vermittelt die bank ihren Lesern Strategien, Technologien, Trends und Managementideen der gesamten Kreditwirtschaft.

ó BETRIEBSWIRTSCHAFT

ó BETRIEBSWIRTSCHAFT Datenmengen im Big-Data-Bereich, wie z. B. Monte-Carlo basiertes Marktrisiko oder Kreditexposure mit flexiblen Drill- Down-Dimensionen, ist enorm. Die Charakteristika, Flexibilität und Geschwindigkeit in Verbindung mit großen Datenvolumen sind nur mit modernen In-Memory-Technologien vereinbar. Die reine Technologie ist hier wenig hilfreich, notwendig ist vielmehr die Kombination von Technologie und Verständnis von Risikomanagement-Prozessen und finanzmathematischen Berechnungen. Berücksichtigt man nun die gesamte Wertschöpfungskette einer Bank, insbesondere auch das Handelsbuch, so rücken portfoliobasierte Methoden des Risikomanagements (insbesondere FVA, CVA, KVA, IM, aber auch LR, LCR sowie RWA) schon bei der Geschäftsanbahnung und Bewertung (also das sogenannte Risk at Inception und Global Pricing) gleichzeitig mit BCBS 239 in den Vordergrund. Diese Themen treiben gemeinsam die Geschwindigkeit und Verfügbarkeit von Berechnungen im Konzern. Der klassische Data-Warehouse (DWH)-Gedanke und dessen Technologie ist daher aus mehrfacher Sicht überholt. Gleichwohl existiert für BCBS 239-konforme Infrastrukturen keine einheitliche Blaupause. Da die Systemlandschaft jeder Bank individuell ausgestaltet ist, wird auch jede BCBS 239-Infrastruktur, die existierende Lösungen umfasst, institutsspezifisch sein. Eine BCBS 239-Infrastruktur wird nicht ein triviales neues zusätzliches Software-Paket sein. Auch ist eine solche Infrastruktur mehr als ein weiteres Data- Warehouse- oder BI-Reporting-Projekt, das man um die bestehende Software-Lösung herumimplementiert. Vielmehr besteht die Kunst darin, für die diversen Systeme innerhalb der Bankengruppe sicherzustellen, dass alle natürlichen Personen und Systeme mit den gleichen Daten, den gleichen Modellen und den identischen Annahmen arbeiten. Zudem ist eine Inventarisierung der Systemlandschaft nötig, da speziell bei größeren Instituten mehrere Systeme überlappende Funktionalitäten aufweisen. Kernstück einer BCBS 239-Infrastruktur ist deshalb eine zentrale Meldestelle. Hier wird für jede einzelne Applikation registriert, welche Portfolien bearbeitet, welche Input- Daten und Berechnungen benötigt und welche Resultate in welcher Frequenz und Granularität erzeugt werden können. So kann zentral gesteuert werden, mit welchen Systemen eine bestimmte Auswertung vorgenommen werden soll, um Redundanzen und potenziell widersprüchlichen Resultaten vorzubeugen. Entsprechend der Zusammenführung der Risikoarten tritt, statt der traditionellen Fokussierung auf die einzelnen Risikokategorien, die Gesamtrisikosicht in den Mittelpunkt. Für die effektive Umsetzung einer BCBS 239-Infrastruktur sollte sichergestellt sein, dass insbesondere die folgenden Prozesse zentral administriert werden: ó Data Lifecycle Management – Speicherung und Versionierung der benötigten Daten. ó Model Governance – Verwaltung der verwendeten Risikomodelle. 3 Illustration einer BCBS 239-Architektur Gesamtbank-Risiko-Reporting Resultat- Historisierung RWA Prozess-Orchestrierung Regulatorisches Reporting Market Risk Analytische Plugins CVA PFE PV FTP Data Lifecycle Management Model Governance Szenario- Definition Stammdatenmanagement Credit Risk Liquidity Risk OpRisk Risiko- & Finanz-Systeme CF Gesamtbank-Risiko-Reporting Data-Stewardship Marktdaten Finance MIS Gesamtbank-Risiko-Reporting 46 diebank 3.2015

BETRIEBSWIRTSCHAFT ó ó Szenario-Definition – zentrale Definition der zukünftigen Marktszenarien. ó Stammdatenmanagement – einheitliche Definition der verwenden Dimensionen, Gegenparteien etc. Um eine einheitliche Gesamtbank-Risikoberichterstattung erreichen zu können, ist speziell das Stammdatenmanagement von großer Relevanz. Nur wenn die Dimensions-Ausprägungen und Attribute in allen Systemen die gleiche Bedeutung und Granularität haben, ist eine Auswertung über den gesamten Resultate-Bestand möglich. Das Stammdatenmanagement stellt auch eine prozessübergreifende eindeutige Vergabe einer Objektidentifikation (ID) sicher. Kunden- und Geschäftsdaten sind Beispiele für Objekte, für die eine konzernweite ID vergeben werden muss. Diese ID wird über die ganze Wertschöpfungskette hinweg konsistent verwendet. Um die einzelnen Systeme miteinander vernetzen zu können, ist zudem eine Prozess-Orchestrierung unerlässlich. Hierbei handelt es sich um das zweite Kernelement neben der Meldestelle einer BCBS 239-Infrastruktur ” 3. Die DNA der BCBS 239-Infrastruktur ist Adaptionsfähigkeit Unter Prozess-Orchestrierung wird das geordnete Zusammenspiel der verschiedenen Risiko- und Finanzapplikationen verstanden. Wie erwähnt, gibt es im Risikomanagement einer Bank üblicherweise eine Vielzahl produktiv eingesetzter Systeme. In einer modernen Prozess-Orchestrierung wird eine automatische Registrierung von Plug-ins und Applikationen bei der Meldestelle angestrebt. Somit hat die BCBS 239-Infrastruktur die Möglichkeit, eine ganze Prozesskette entlang der Systeme und Plug-ins zu kreieren, die nötig sind, um z. B. die Szenarien eines Gesamtbank-Stresstests durchzurechnen. Diese Prozesse ändern sich idealerweise automatisch mit sich ändernden Systemen und Plug-ins. Entsprechend lassen sich neue Anforderungen mit ggf. notwendigen zusätzlichen Funktionalitäten der Plug-ins oder erweiterten Systemen in der sich adaptierenden Infrastruktur darstellen. Es gibt zwei Arten von Applikationen: ó analytische Rechenkerne, die in der Lage sind, eine bestimmte Berechnung durchzuführen (z. B. Cashflow- Generatoren, Marktwertrechner oder Rechenkerne für Kreditexposures), ó Systeme, die einen Risikobereich großflächig oder sogar vollständig abdecken. Aus System-Architekturüberlegungen wäre es erstrebenswert, hauptsächlich auf analytischen Rechenkernen aufzubauen, die beliebig kombiniert werden können. Dies bleibt aber meistens Wunschdenken. Durch geschickte Prozess-Orchestrierung kann aber erreicht werden, dass sich ganze Applikationen wie Rechenkerne ansteuern lassen, um zum Beispiel Teilergebnisse zu erzeugen, die von anderen Systemen wiederverwendet werden können. Ein weiterer Vorteil der zentralen Prozess-Orchestrierung ist, dass bei der Korrektur fehlerhafter Input-Daten die ganze Prozesskette automatisiert einen Korrekturlauf vornehmen kann. Zukunftssicherheit durch unstrukturierte Daten Eine Kernfrage bleibt aber bestehen: Wie lässt sich sicherstellen, dass auf Ad-hoc- Anfragen, die Informationen erfordern, die nicht zentral verwaltet werden, zeitnah reagiert werden kann? Für solche Fälle ist es von Vorteil, neben den strukturierten, also heute bekannten und benötigten Daten, auch einen Pool von unstrukturierten Daten über den Zeitablauf vorzuhalten. Zum Beispiel können das Transaktionsdaten von Spar- und Girokonten sein oder zusätzliche Informationen über Kunden oder Sicherheiten, die zwar heute nicht in den Risikosystemen gebraucht werden, aber zum Geschäftsabschluss in den Front-Systemen verfügbar wären. Häufig historisieren Front- Systeme diese Informationen nicht, d. h. wenn man tatsächlich darauf angewiesen ist, sind die Informationen entweder nicht mehr verfügbar oder nur noch in ihrer aktuellen Ausprägung. Die Ausprägung zum Zeitpunkt des Geschäftsabschlusses ist allerdings nicht vorhanden. Will man aber tatsächlich einen solchen Datenspeicher auf Vorrat aufbauen, bedeutet dies freilich, mit riesigen Datenmengen zu arbeiten. Eine kostengünstige Variante, solche Datenmengen vorzuhalten, bringen Big-Data-Lösungen mit sich, obwohl diese eigentlich nicht in erster Linie zu diesem Zweck entwickelt wurden. Fazit BCBS 239 ist weder eine reine Herausforderung der IT, noch eine Aufgabe einzelner Fachbereiche. Die Grundsätze erfordern eine Sicht auf die Gesamtbank. Die Grundsätze sind die regulatorisch verordnete Vereinheitlichung des Finanzinstituts. Das Erreichen einer BCBS 239-konformen Bank ist allerdings eine Mammutaufgabe für Fach- und IT-Bereich. Der beschriebene Plug-in-Mechanismus und der Einsatz von zielgerichteten In-Memory-Technologien statt klassischen Datenbanken eröffnen neue Möglichkeiten und stellen gleichzeitig die Umsetzbarkeit sicher. Das Ergebnis erlaubt die kurzfristige Compliance mit neuen Regularien, die genauere Steuerung der Bank sowie die Adaption an kontinuierlich wandelnde Geschäftsmodelle. ó Autoren: Dr. Sven Ludwig, Senior Vice President Risk and Analytics EMEA, SunGard. Markus Gujer, Head of Product Management, AMBIT Risk and Performance, SunGard. Quellenverzeichnis: BCBS: Grundsätze für die effektive Aggregation von Risikodaten und die Risikoberichterstattung, Januar 2013. BCBS: Progress in adopting the principles for effective risk data aggregation and risk reporting (BCBS 268), Dezember 2013. Boston Consulting Group: Breaching the next Banking Barriere, 2013. KPMG: BCBS 239: Neue Anforderungen an die IT-Architektur und Data-Governance, Juni 2013. Senior Supervisors Group: Progress Report on Counterparty Data, 2014. SunGard: Trends in Risk Management. Risk Magazine, 2014. 3.2015 diebank 47

die bank

die bank 01 // 2019
die bank 02 // 2019
die bank 03 // 2019
die bank 04 // 2019
die bank 05 // 2019
KINOTE 01.2019
die bank 06 // 2019
diebank 07 // 2019
diebank 08 // 2019
die bank 01 // 2018
die bank 02 // 2018
die bank 03 // 2018
die bank 04 // 2018
die bank 05 // 2018
die bank 06 // 2018
die bank 07 // 2018
die bank 08 // 2018
die bank 09 // 2018
die bank 10 // 2018
die bank 01 // 2017
die bank 02 // 2017
die bank 03 // 2017
die Bank 04 // 2017
die bank 05 // 2017
die bank 06 // 2017
die bank 07 // 2017
die bank 08 // 2017
die Bank 09 // 2017
die bank 10 // 2017
die bank 01 // 2016
die bank 02 // 2016
die bank 03 // 2016
die bank 04 // 2016
die bank 05 // 2016
die bank 06 // 2016
die bank 07 // 2016
die bank 08 // 2016
die bank 09 // 2016
die bank 10 // 2016
die bank 11 // 2016
die bank 12 // 2016
die bank 01 // 2015
die bank 02 // 2015
die bank 03 // 2015
die bank 04 // 2015
die bank 05 // 2015
die bank 06 // 2015
die bank 07 // 2015
die bank 08 // 2015
die bank 09 // 2015
die bank 10 // 2015
die bank 11 // 2015
die bank 12 // 2015

© die bank 2014-2018