BCBS239 in der Bankenpraxis am Beispiel des Regulatory Reportings

Thomas Steiner, BearingPoint, Frankfurt am Main

Quelle: BearingPoint

Thomas Steiner, Partner, Erik Becker, Director, und Bernd Corzelius, Director, alle BearingPoint, Frankfurt am Main - Als die Bankenaufsicht im Zuge der jüngsten Finanzkrise zur aktuellen Lagebeurteilung Risikodaten von Kreditinstituten abrufen wollte, waren diese teilweise nicht in der Lage, die angeforderten Angaben in einer angemessenen Zeit zu liefern und hatten dementsprechend auch keine Chance ihre eigenen Geschäfte unter Berücksichtigung dieser Informationen zu steuern. Mit BCBS 239 als Vorgabe für die Erhebung von Risikodaten und die Risikoberichterstattung soll dieses Defizit behoben werden. Die Kreditwirtschaft ist mit teils großem Aufwand mitten in der Umsetzungsphase. Aus Sicht der Autoren kann der Einsatz von Standardsoftware helfen, den Auf- und Ausbau eines (fachlich) vollständigen und konsistenten Datenhaushalts zu unterstützen. Darüber hinaus halten sie aber insbesondere bei den Themen Data Governance und Data Management auch organisatorische Prinzipien sowie einen entsprechenden Kulturwandel für erforderlich, um die Datenqualität von der Datenquelle bis zum finalen Bericht an die Aufsicht oder das Management zu verbessern. (Red.)

Die Baseler Anforderungen (insbesondere über BCBS 239) an die Risikodatenaggregation und Risikoberichterstattung beschäftigt global systemrelevante Institute schon seit drei Jahren und hält über die MaRisk nun auch verstärkt Einzug in die Regularien für alle deutschen Kreditinstitute. Die elf Prinzipien von BCBS 239 lassen erheblichen Interpretationsspielraum und haben in vielen Banken zu groß angelegten IT-Projekten geführt. Stichworte wie Single Point of Truth und integrierte Finanz- und Risikodatenarchitektur gehen oft einher mit Projektbudgets im zweistelligen Millionenbereich.

Defizite bei Datenarchitektur und IT-Infrastruktur

Seit Januar 2016 sind die neuen Anforderungen von allen global als systemrelevant geltenden Finanzinstituten (G-SIBs, global systemically important banks) einzuhalten und sind sowohl auf Konzernebene als auch auf Einzelinstitutsebene verpflichtend.

In der Praxis stehen Institute bei der Umsetzung aber vor vielen Problemen. Dementsprechend hat der Baseler Ausschuss in seinem im März 2017 veröffentlichten Fortschrittsbericht*) ein unbefriedigendes Ergebnis konstatiert. Nur eine der rund 30 global systemrelevanten Institute erfüllt alle Anforderungen zufriedenstellend. Für keines der Prinzipien wurde eine vollständige Compliance erreicht. Insbesondere beim Thema P2 Datenarchitektur und IT-Infrastruktur liegen derzeit noch bei rund der Hälfte der G-SIBs die größten Herausforderungen (Abbildung 1).

Zudem besteht in vielen Instituten auch bei den Themen Datenqualität, Reporting-Effizienz, Stresstests und Ad-hoc-Reporting noch erheblicher Nachbesserungsbedarf, um die genannten Prinzipien adäquat zu erfüllen.

Im Wesentlichen lassen sich aus den Anforderungen aus BCBS 239 folgende sieben Praxisprobleme herausarbeiten:

- Wie lässt sich die Datenkonsistenz bei stark zunehmendem Informationsbedürfnis der Bankenaufsicht nach innen und außen herstellen?

- Wie lassen sich Datenflüsse lückenlos bis zur Quelle verfolgen (Data Lineage)?

- Wie bekommt man das Thema Datenqualitätsmanagement dauerhaft nachhaltig in den Griff?

- Wie lassen sich ad hoc neue Informationsbedürfnisse der Aufsicht oder auch interner Stakeholder befriedigen?

- Wie lassen sich der Berichtszyklus und die Prozesslaufzeiten verkürzen?

- Wie lassen sich stärker zukunftsgerichtete Aspekte in die Finanz- und Risikoberichterstattung einbetten?

- Wie lassen sich vielfach eingesetzte Excel-Anwendungen (IDV) in ein professionelles Datenmanagement integrieren?

Im Folgenden wird auf diese verschiedenen Herausforderungen eingegangen und es werden Antworten auf diese Fragen geliefert, beispielhaft an einem der neuralgischen Prozesse für die Finanz- und Risikodaten - dem Meldewesenprozess.

Lösungsansätze mit neuer Software

Ein großer Teil der Daten zur Erfüllung der BCBS-239-Prinzipien wird über das regulatorische Reporting an die Bankenaufsicht gemeldet. Vor dem Hintergrund des ungestillten Datenhungers der Aufsicht wird dieser Teil sich in den nächsten Jahren noch tendenziell weiter erhöhen. So war dies einer der Haupttreiber für die Entwicklung einer neuen Generation von Regulatory Reporting und Risk Management Software mit dem Namen Abacus 360 Banking.

Mit der Software lässt sich für den Nutzer die Vision eines "Single Point of Truth" mit bestehenden Datenanbindungen greifbar machen, ohne dass zwingend komplett neue und aufwendige Data-Warehouse-Projekte initiiert werden müssen. Folglich verbessert sich die Datenkonsistenz zwischen Meldewesen, Reporting an die Aufsicht (zum Beispiel EU-weite Stresstests) und gegebenenfalls sogar das interne Risiko-Reporting.

Datenkonsistenz durch Integration (Validation Designer): Die neue Softwaregeneration ist eine integrierte Lösung für Reporting, Risikokalkulation und Steuerung regulatorischer Kennziffern auf Basis eines einheitlichen Datenmodells (Abbildung 2). Hierbei lassen sich neben dem statistischen Meldewesen auch Rechnungswesen-Daten (Stichwort FinRep/CoRep, Offenlegungsberichte) nach nGAAP (zum Beispiel HGB) und IFRS verarbeiten. Durch die Integration der verschiedenen fachlichen Sichten lässt sich die Datenkonsistenz verbessern und durch gezielte Validierungsregeln transparent machen.

Data Lineage (Complete Audit Trail): Um den BCBS-239-Prinzipien gerecht zu werden, müssen Banken den gesamten Datenfluss transparent machen und visualisieren, um die verschiedenen Transformationen von der Quelle bis zum endgültigen Ziel nachvollziehen zu können.

Qualität der Daten sicherstellen

Dieser "End-to-end"-Datenverlauf muss für alle kritischen Risikodatenelemente (Critical Risk Data Element - CRDE) abgebildet werden. Darüber hinaus muss für alle Metadaten über die gesamte Architektur hinweg eine integrierte Daten-Taxonomie geschaffen werden. Dazu gehören zum Beispiel eine klare Namenskonvention, die Eigenschaften der Datenfelder und die eindeutige Kennung. Außerdem müssen Rollen und Verantwortlichkeiten für CRDEs sowie für SRDEs (Support Risk Data Elements) definiert werden. Dies muss innerhalb der Geschäfts- und IT-Funktionen sichergestellt sein. Die Dateneigentümer sind verantwortlich für die Qualität der Daten und müssen gegebenenfalls geeignete Maßnahmen ergreifen. Dabei haben sich die folgenden Ansätze bewährt, um vorhandene Lücken zu schließen:

- Prüfung des bestehenden Mappings der Datenelemente im Geschäftsglossar,

- Abgleich der Metadaten von Datenelementen mit allen Beteiligten (einheitliche Formulierung) inklusive Freigabe,

- klar definierte Eigentümer für jedes Datenelement,

- Analyse der Data-Governance-Prozesse und Maßnahmen zur Einbettung von Daten-Eigentümerkonzepten und -prozessen,

- Untersuchung und Prüfung von Geschäfts- und IT-Konzepten inklusive Transformationsregeln für relevante Datenflüsse,

- Festlegen der Kritikalität von SRDEs für CRDEs auf Grundlage ihres Anteils am Gesamtrisiko,

- Empfehlungen für Regeln zur Datenqualität, - bei Abweichungen Lückenanalysen zwischen Geschäftsglossar und Datenverlaufs-Tool,

- Abgleich der Dimensionalität der CRDEs,

- Prüfung des bestehenden Änderungsüberwachungsprozesses für das Geschäftsglossar inklusive Automatisierungsgrad.

Auf dieser Grundlage werden das Geschäftsglossar und der Datenverlauf aktualisiert. Die Visualisierung der Datenströme ist abhängig von dem verwendeten Datenverlaufstool. Darüber hinaus liefert die Analyse hinsichtlich Datenverlauf und Taxonomie wertvolle Erkenntnisse und schnelle Erfolge bei der Verbesserung der Datenqualität. Die Einbeziehung des Eigentümerkonzepts in den Data-Governance-Prozess wirkt sich auch positiv auf den Qualitätsverbesserungsprozess aus. Der Dateneigentümer wird auf der Ebene der einzelnen Datenelemente zusammen mit den beschreibenden Eigenschaften und den geltenden Datenqualitätsregeln dokumentiert.

Nachvollziehbare Berechnung von Ergebnisdaten

Gerade auch innerhalb von Standardsoftware-Produkten, die sich im Umfeld der Organisation von Risikodaten bewegen, ist eine integrierte Data-Lineage-Funktion unbedingte Voraussetzung für eine effiziente Erfüllung der BCBS 239 Anforderungen. So bietet Abacus 360 Banking beispielsweise einen Ad-hoc-Audit-Trail, bei dem an beliebigen Stellen in der Software die Berechnung von Ergebnisdaten in der Art nachvollzogen werden können, dass die komplette Rechenlogik für eine angeforderte Ableitung systematisch offengelegt wird. Darüber hinaus kann das integrierte Data Dictionary auch um kundenindividuelle Ausprägungen ergänzt werden, sodass eine umfassende Synchronisierung und Harmonisierung von Begriffen unterstützt wird.

Datenqualitätsmanagement: Bankinstitute müssen die Genauigkeit ihrer Daten messen und überwachen. Die Datengenauigkeit muss über die gesamte Architektur hinweg gewährleistet sein, um den Entscheidungsträgern Daten mit hoher Qualität liefern zu können. Darüber hinaus werden adäquate Eskalationskanäle undprozesse benötigt. Sobald Datenqualitätsprobleme auftreten, müssen wirksame Gegenmaßnahmen eingeleitet werden. Folgende Maßnahmen haben sich dabei bewährt, um Qualitätslücken zu schließen:

- Bekanntmachung und Prüfung der Datenqualitätsrichtlinie und -vision,

- Festlegen von DQ-Kriterien und Identifizieren von Abweichungen von den DQ-Standards,

- Priorisierung von notwendigen Anpassungen basierend auf der Gesamtauswirkung,

- Erstellung eines Zeitplans für die Umsetzung von notwendigen Anpassungen,

- Prüfung der Organisation und Handhabung von Datenqualitätsthemen,

- Festlegen beziehungsweise Prüfung von Eskalations- und Ticketing-Prozessen (innerhalb der Datenzentrale),

- Kategorisierung von Datenqualitätsproblemen,

- Lückenanalyse des DQ-Tools und seiner Integrationsfähigkeit in die DQ-Organisation,

- Entwicklung eines zentralen Protokollierungs- und Datenqualitätsmodells,

- Reduzierung manueller Prozesse durch den Einsatz adäquater Tools und Prozesse,

- Integrierte Prozesse zur Prüfung und Korrektur der Datenqualität (mit der Datenzentrale),

- Messung der DQ mithilfe einer präzisen Metrik und KPIs,

- Ursachenanalyse bei bestehenden Fehlern,

- Berichte zur Fehlerbewertung und Fehlertransparenz.

Diese Maßnahmen zur Verbesserung der Datenqualität können nicht nur die Anzahl von Lücken reduzieren, sondern auch dazu beitragen, diese schneller zu identifizieren und zu lösen. Eine effiziente DQ-Metrik in Verbindung mit einem informativen aggregierten DQ-Bericht kann ebenfalls einen wesentlichen Beitrag zur Erhöhung der Datenqualität leisten.

Zeitdruck durch kurzfristige Anfragen

Ad-hoc-Reporting (TD, Data Model Designer): In der Post-Basel-III-Ära gibt es eine stetig ansteigende Zahl an Ad-hoc-Berichten, die die Institute binnen kürzester Zeit abgeben müssen. Dazu gehören neben den Quantitative Impact Studies (etwa zur NSFR oder Leverage Ratio) auch die Short Term Exercises oder die Fire Drills der EZB. Im Falle der Fire Drills etwa erhalten die Banken von der EZB vordefinierte Templates zu unterschiedlichen Kennziffern oder mit der Anforderung der inhaltlichen Überleitung (zum Beispiel LCR und FinRep), die sie innerhalb von 48 Stunden ausgefüllt abgeben müssen. Diese Anfragen können entweder mit bereits vorhandenen Daten bedient werden oder müssen über kurzfristig abrufbare Daten angereichert werden (Abbildung 3).

Diese sehr kurzfristigen Anfragen stellen Banken gerade aufgrund des hohen Zeitdrucks vor große Herausforderungen. Da es für Ad-hoc-Reportings meist keinen Standardinhalt sowie stets wechselnde Templates gibt, können Banken keine adäquate Vorbereitung treffen. Dies wird durch den häufigen Einsatz von IDV-Prozessen mit zahlreichen Medienbrüchen erschwert, die eine zeitnahe Reaktion behindern. Hinzu kommt, dass die Anforderungs- und Umsetzungszyklen zwischen Geschäfts- und IT-Bereich manchmal nicht zu den von der Aufsicht gesetzten Deadlines passen.

Mit der Komponente Template Designer (TD) bietet die Software-Lösung nun ein Tool an, mit dem sich Banken gezielt diesen Herausforderungen stellen können. Hier wird die individuelle Datenallokation integriert in der Benutzeroberfläche ermöglicht (Abbildung 4).

Die von der Aufsicht geforderten Templates können sowohl benutzerfreundlich über eine Excelähnliche Benutzeroberfläche erstellt, als auch als vorgefertigte Excel-Vorlagen im xlsx- und json-Format importiert werden. Über einen Berichtsregel-Editor können in den Templates individuelle Berichtsregeln erstellt und mithilfe des Zugriffs auf alle enthaltenen Datenschichten mit den notwendigen Daten gefüllt werden.

Externe Datenquellenschnittstelle

Fehlende Werte, die über den gewöhnlichen Datenhaushalt innerhalb der Lösung hinausgehen, können über eine externe Datenquellenschnittstelle eingebunden werden. In diesem Fall kann mithilfe der Komponente Data Model Designer das Standard-Datenmodell bedarfsgerecht erweitert werden, um bestimmte Aspekte innerhalb der Ad-hoc-Reportings abbilden zu können.

Nach einmaliger Erstellung der Templates und der jeweiligen Berechnungslogik können diese für alle fortlaufenden Adhoc-Reportings wiederverwendet und je nach Bedarf entsprechend etwaiger neuer Anforderungen der Aufsicht abgeändert werden. Damit entsteht ein stabiler automatisierter Prozess der Befüllung der individuellen Templates mit einem hohen Grad an Wiederverwendbarkeit, der durch die mögliche Nutzung des Complete Audit Trails komplett transparent ist.

Ein wesentlicher Vorteil ist die Reduzierung von Medienbrüchen aufgrund der Zentralisierung der Daten innerhalb eines Systems, wodurch eine signifikante Zeit- und Kostenersparnis generiert wird. Durch die Reduktion von IDV-Prozessen ist eine zentrale Anforderung nach BCBS 239 erfüllt. Als Folge der Minimierung manueller Prozesse und der weitestgehenden Automatisierung des gesamten Meldeprozesses des Ad-hoc-Reportings wird schließlich eine geringere Fehleranfälligkeit erzielt.

Prozesslaufzeiten (Workflow-Manager): Neben einer starken Standardisierung, was unter anderem durch die Reduktion von individueller Datenverarbeitung und dem Einsatz von Standardsoftware erreicht werden soll, zielt BCBS 239 auch auf eine hochgradige Automatisierung der Datenbereitstellung und der umliegenden Prozesse ab. Dies kann im Wesentlichen durch eine verbesserte Integration der risikorelevanten IT-Systeme in die IT-Gesamtarchitektur und durch den Einsatz von Workflow unterstützenden Systemen erreicht werden. Auch wenn die Anzahl von manuellen Prozessen durch BCBS 239 stark reduziert werden soll, so ist ein Risiko-Reporting auf Knopfdruck allein schon durch den Faktor Datenqualität nie ganz zu erreichen. Auch wenn viele manuelle Prozesse für sich genommen nicht zwingend komplex sind, so wird durch die Kombination ein gewisses Maß an (organisatorischer) Komplexität erreicht. Diese lässt sich in der Praxis vor allem mit integrierten Workflow-Tools in der Art beherrschen, dass vor allem die Kommunikation und die Abstimmung in den Prozessen verbessert wird, was letztendlich zu kürzeren Durchlaufzeiten für das Risiko- Reporting führt.

Die wesentlichen Forderungen der Aufsicht aus BCBS 239 ist die zunehmende Konsistenz zwischen Management- sowie regulatorischem, gesetzlichem und steuerrechtlichem Reporting. Hierbei kann auch der Einsatz von Standardsoftware sehr gut helfen, die den Auf- und Ausbau eines (fachlich) vollständigen und konsistenten ausbaufähigen Datenhaushalts flexibel unterstützt und bei deren Entwicklung die BCBS 239-Standards bereits im Design berücksichtigt wurden. Alle (BCBS 239-) Prinzipien lassen sich jedoch nicht alleine mit Software lösen. Insbesondere beim Thema Data Governance und Data Management sind auch organisatorische Prinzipien sowie ein entsprechender Kulturwandel erforderlich, um die Datenqualität von der Datenquelle bis zum finalen Bericht an die Aufsicht oder das Management zu verbessern.

Fußnote

*) Vgl. http://www.bis.org/bcbs/publ/d399.htm

Erik Becker , Product Director , Regnology, Frankfurt am Main

Weitere Artikelbilder

Noch keine Bewertungen vorhanden


X