Management-Summary
Viele kleinere und mittelgroße Banken haben die BCBS #239 zunächst als für sie nicht relevant eingestuft, da sie als sog. LSIs (Less Significant Instituts) als nicht systemrelevant bewertet werden und sie sich daher nicht im Geltungsbereich des Papiers sahen. Doch der Basler Ausschuss schrieb in o. g. Papier offensichtlich sehr bewusst „zunächst“ – „Diese Grundsätze richten sich zunächst an SIB“[1].
BaFin, Bundesbank und OeNB machen immer wieder deutlich, dass sie bei aller Proportionalität die Umsetzung wesentlicher Kerngedanken aus BCBS #239 bei allen Banken erwarten – explizit mit der 5. Novelle der MaRisk, aber auch implizit in Aussagen auf Tagungen oder in Prüfungsgesprächen. Zu den Kernelementen zählen:
- Governance – klare Verantwortlichkeiten für die Zusammenstellung der Risikodaten und das Risikoreporting – von den Basisdaten bis zum Gesamtbankrisikobericht.
- Aktualität und Relevanz des Risikoreportings – um zeitgerecht Entscheidungen des Managements zu unterstützen, werden Prägnanz und beschleunigte Prozesse erwartet.
- Konsistenz – die verschiedenen Steuerungssichten (ökonomisches Risiko, aufsichtsrechtliches Risiko, Rechnungslegung) müssen konsistent zueinander/überleitbar sein und auf denselben Geschäfts- und Marktdaten basieren.
- Datenbasis und Systeme – ein hoher Automatisierungsgrad, eine Reduktion von IDV sowie eine Datenarchitektur und IT-Infrastruktur, die schnell und flexibel über das Standardreporting hinausgehende Analysen ermöglicht (u. a. Ad-hoc-Abfragen).
Nach zeb-Erfahrung besteht für alle Banken hier ein Handlungsbedarf. Auch wenn ggf. genutzte Rechenzentren weite Teile der IT-Infrastruktur entsprechend anpassen oder die Bankenverbände fachliche Hilfestellungen bieten: Die Ausgestaltung der Verantwortlichkeiten, der Prozesse und des Risikoreportings ist bankindividuell. Die „Late(r) Mover“ haben gegenüber den G-SIBs den Vorteil, dass sie von deren Erfahrungen profitieren können, auch wenn Aufgaben und Lösungen einfacher ausfallen. Allerdings benötigen auch diese Lösungen Zeit, weshalb die Erarbeitung einer Umsetzungsstrategie dringend anzuraten ist.
Ausgangslage
Seit 2013 beschäftigen sich global systemrelevante Banken intensiv mit den „Grundsätze[n] für die effektive Aggregation von Risikodaten und die Risikoberichterstattung“ BCBS #239. Kleinere und mittelgroße Banken sahen sich davon nicht betroffen. Mit der Veröffentlichung des Entwurfs der 5. Novelle der MaRisk (im Weiteren „MaRisk5“) Anfang 2016 änderte sich dies in Ansätzen. Doch da die Anforderungen zu Datenmanagement, Datenqualität und Aggregation von Risikodaten (AT 4.3.4) vermeintlich nur an „große und komplexe Institute“ adressiert sind, wurden von Nicht-SIBs nur vereinzelt entsprechende Umsetzungsprojekte aufgesetzt.
Abbildung 1: Proportionale Umsetzung der BCBS-#239-AnforderungenAber der mit der Konsultation der MaRisk5 veröffentlichte Appell „auch andere Institute […] zu prüfen, inwieweit Datenaggregationskapazitäten weiter verbessert und ausgebaut werden können“ scheint von BaFin und Bundesbank, aber auch von der OeNB intensiv weiterverfolgt zu werden. So wird auch in Prüfungsgesprächen in kleineren Häusern mitunter darauf verwiesen, dass die Grundsätze aus BCBS #239 bekannt sind.
Welche Ausgestaltungsalternativen die Aufsicht mit Hinweis auf das Proportionalitätsprinzip akzeptieren wird, bleibt abzuwarten. Denn als „kleinere Bank mit einfachem Geschäftsmodell und wenig volatilen Risiken“ sollte es auch deutlich einfacher sein, die Anforderungen zu erfüllen, als für G-SIBs mit vielen international ausgerichteten Konzerntöchtern. So dämpfte die BaFin im Rahmen der Konsultation auch bereits Hoffnungen auf einige Erleichterungen – „grundsätzlich können allerdings Produktionszeiten von einzelnen Berichten von zum Teil mehreren Wochen nicht mehr akzeptiert werden“.
Und schließlich stellt sich die Frage, wie die für alle Banken geltende Anforderung, dass „die Berichte […] auf vollständigen, genauen und aktuellen Daten beruhen [müssen], die flexibel für die Erfordernisse des Risikomanagements aufbereitet und angepasst werden können“ (BT 3.1 Tz.1), erfüllt werden kann, ohne o. g. Anforderungen an das Datenmanagement automatisch mitzuerfüllen. Als Konsequenz werden alle Banken Lösungen erarbeiten müssen, wie sie die Anforderungen zu Datenmanagement, Datenqualität und Aggregation von Risikodaten (AT 4.3.4) umzusetzen gedenken.
Die Verbände und Rechenzentren von Sparkassen und Genossenschaftsbanken arbeiten an Eckpapieren zur Risikodaten-Governance, angepassten Standardreports, Fach-Glossaren und Data-Warehouse-Lösungen, die wesentliche Lösungsbausteine darstellen. Doch die Einbettung dieser Elemente in die spezifische Umgebung der einzelnen Häuser (Geschäftsstrategie, Prozesse, Aufbauorganisation, IDV) bleibt eine nicht zu unterschätzende Aufgabe für die einzelnen Häuser.
„Erfahrung hebelt Unheil aus“ (M. Hinrich)
Bei der Umsetzung von BCBS #239 in den global systemrelevanten Banken haben diese, aber auch die Aufsicht und beteiligte Unternehmen einige Erfahrungen hinsichtlich Auslegung, Umsetzungshürden und pragmatischer Lösungen sammeln können. Daraus lassen sich für die Umsetzung der BCBS #239 für LSIs die in Abbildung 1 dargestellten Module im Sinne von Handlungsfeldern ableiten:
Abbildung 2: Module „BCBS #239 für Nicht-SIBs“Je nach Banken-/Sparkassenverband liefert dieser Unterstützung zu den Modulen 1–7 und 10. Die großen Verbandsrechenzentren stellen Lösungen für die Module 5–8 und 10 bereit.
Im Rahmen des Artikels fokussieren wir im Weiteren auf folgende Module, da diese aus den Erfahrungen der BCBS-#239-Projekte besonders erfolgsrelevant sind:
- Modul 2 – Projektaufsatz und ‑planung
- Modul 4 – Aufbauorganisation und Verantwortlichkeiten
- Modul 7 – Datenarchitektur und Abstimmbarkeit
- Modul 9 – Prozesse
Modul 2 – Projektaufsatz und ‑planung
Insbesondere die Anforderungen hinsichtlich Konsistenz und Abstimmbarkeit machen das Thema zu einer steuerungsbereichsübergreifenden Aufgabe. Der in den Banken nicht selten vorhandene Silogedanke von Kreditrisiko, Marktrisiko, Liquiditätsrisiko – untereinander, aber insbesondere auch gegenüber dem Rechnungswesen und Meldewesen – wird in den Banken daher eine wesentliche Umsetzungshürde darstellen. Daher ist es wichtig, bereits beim Projektaufsatz diese Denkmuster durch entsprechende Projektstrukturen aufzubrechen.
Gleichzeitig muss dem Impuls widerstanden werden, „alles, was wir schon immer mal machen wollten“, nun auf dem Trittbrett der regulatorischen Anforderungen abzuladen und die Projekte damit zu überfrachten. Daher sollten am Anfang die Ziele des Umsetzungsprojekts präzisiert, daraus ein holistisches Zielbild abgeleitet und schließlich mit kleinen Iterationen erste nutzbare Ergebnisse erzielt werden, welche Bausteine einer nachhaltigen Lösung sind.
Modul 4 – Aufbauorganisation und Verantwortlichkeiten
Die Daten, die zur Banksteuerung verwendet werden, sollten zumindest teilweise zentral gemanagt werden, um Konsistenz und zeitgerechte Bereitstellung der Risikodaten gewährleisten zu können. Hier geht es weniger um die technische Sicht, für die dies grundsätzlich auch gilt, sondern vor allem um das fachliche Datenmanagement bei neuen Anforderungen, aber auch für den laufenden Betrieb.
Abbildung 3: Hybrider Ansatz für das fachliche DatenmanagementDie meisten großen Banken haben hierzu eine Einheit „fachliches Datenmanagement“ aufgebaut, die bereichsübergreifend bestimmte Aufgaben des Datenmanagements zentral übernimmt, andere aber in der dezentralen Verantwortung der Banksteuerungsbereiche belässt – ein „hybrides Modell“.
Modul 7 – Datenarchitektur und Abstimmbarkeit
Kern der fachlichen Datenarchitektur und Basis für eine Abstimmbarkeit ist ein fachliches Glossar, im dem die fachlichen Begriffe der Banksteuerungsbereiche klar definiert werden. Was sich zunächst einfach nach „Gablers Banklexikon“ anhört, ist in der Praxis doch bank- oder zumindest verbandsspezifisch. Denn Fragen wie „Was ist ein Geschäft?“, „Was ist ein Konto?“, „Welche Cashflowarten müssen unterschieden werden?“ und „Haben die Kunden eines Solidarkredits stets dieselbe Rolle?“ werden im Detail je nach Bank und meist sogar je nach Abteilung innerhalb derselben Bank und der dort etablierten „Sprache“ unterschiedlich beantwortet.
Reicht die Struktur eines einfachen Glossars nicht mehr aus, stellt ein „fachliches Datenmodell“ die nächste Ausbaustufe dar. Auch wenn manchmal mit „Datenmodell“ direkt „IT“ und „Technik“ assoziiert werden, verstehen wir hierunter vielmehr eine grafische Repräsentation der Elemente der neuen, harmonisierten Fachsprache und ihrer Beziehungen zueinander. Ein fachliches Datenmodell stellt einen in der Praxis bewährten Ausgangspunkt für weiterführende Aspekte eines Datenmanagements dar, wie z. B. ein leistungsfähiges Datenqualitätsmanagement oder eine Data Lineage.
In allen Ausbaustufen ist entscheidend, dass die bankfachlichen Begriffe eindeutig definiert, Homonyme[2] beseitigt und Synonyme transparent gemacht werden.
Abbildung 4: Datenarchitektur und AbstimmbarkeitWerden diese bankfachlichen Begriffe dann auf die ggf. bereits vorhandenen technischen Datenmodelle gemappt bzw. neue technische Datenmodelle auf deren Basis entwickelt, stellen diese hochwertige Metadaten zu den IT-Systemen dar.
Modul 9 – Prozesse
In vielen Instituten sind die (Risiko-)Datensammlungs- und -plausibilisierungsprozesse deutlich zu beschleunigen. Ein höherer Automatisierungsgrad ist dabei ein wesentlicher Stellhebel. Eine Reduktion von IDV-Lösungen (von den Fachbereichen selbst entwickelte Anwendungen) dezimiert die operativen Risiken und ist daher auch unter diesem Gesichtspunkt anzustreben. Doch betrachtet man die sich herausbildenden Branchenstandards zur Reportinggeschwindigkeit in großen Bankinstituten –Standardreporting zehn bis 15 Tage nach Monatsultimo, Krisenreporting nach zwei bis drei Arbeitstagen – und berücksichtigt die Anforderung zur Konsistenz der Kennzahlen aus den verschiedenen Banksteuerungsbereichen, ist eine Überarbeitung der Prozesse in den meisten Banken zwingend notwendig. Zumal die Aufsicht insbesondere für kleinere Institute ohne komplexe Konzernstrukturen wenig Verständnis für lange Prozesse aufbringen wird.
Bei der Anpassung der Prozesse ist sowohl bei der Ist-Aufnahme als auch im Zielbild eine End-to-End-Sicht über alle Zulieferer zu den relevanten Risikoberichten notwendig, da nur so der kritische Pfad und alle Abhängigkeiten berücksichtigt werden können. Bei der Ableitung der Soll-Prozesse hat sich eine Top-down-Vorgehensweise bewährt, um sich nicht in Details verlieren – ein breites Verständnis der bankfachlichen Steuerungsprozesse ist hier von wesentlichem Vorteil.
Abbildung 5: Vorgehen zur Prozessoptimierung „Gesamtbankrisikobericht“Fazit
Sofern noch nicht geschehen, sollten sich alle Banken kurzfristig mit den für sie relevanten Anforderungen aus BCBS #239 befassen und institutsindividuell ein Zielbild bzw. eine Umsetzungsstrategie entwickeln. Zielbild und Umsetzungsstrategie stellen die notwendige Basis für die Eintaktung entsprechender Umsetzungsprojekte dar. Auch wenn die 5. Novelle der MaRisk noch nicht final veröffentlicht ist, der Geist der Grundsätze aus BCBS #239 schwingt bereits heute in Prüfungsgesprächen mit.
Generell sollten die Banken die aufsichtsrechtlichen Vorgaben nicht als notwendiges Übel sehen, sondern vielmehr als Chance, das Datenmanagement und damit die Datenqualität weiterzuentwickeln. Damit stellt BCBS #239 einen Baustein in einem Umdenkprozess in Banken und bei der Aufsicht dar, dass die Bedeutung von qualitativ hochwertigen Daten immer mehr an Bedeutung gewinnen wird („Daten als Asset in Banken“). So ist die Weiterentwicklung von Digitalisierungs- bzw. Big-Data-Lösungen ohne entsprechende Datenbasis kaum vorstellbar. In diesem Sinne kann die Umsetzung von BCBS #239 – bei entsprechendem Projektaufsatz – einen Wertbeitrag für die Bank generieren, der darüber hinausgeht, „nur“ eine regulatorische Anforderung zu erfüllen.
