BCBS 239
Ausgangssituation
Im Januar 2013 veröffentlichte das Basel Committee das unter dem Namen “BCBS 239” bekannt gewordene Papier “Principles for effective risk data Aggregation and risk reporting”.
Das Basel Committee stellt in dem Papier die These auf, dass die IT und die Datenarchitektur in vielen Banken unzureichend ist, um Finanzkrisen zu managen. So waren nach Auffassung des Basler Ausschusses viele Banken nicht ausreichend in der Lage, Risikodaten aggregiert, schnell und korrekt auf Gruppenebene über alle “business lines und legal entities” hinweg zu generieren, um ein Gesamtbild der Risiken zu erhalten. Daher waren nach Auffassung des Basler Ausschusses viele Banken während der Finanzkrise nicht in der Lage, Risiken angemessen zu managen.
Aus diesem Grund hat das Basel Committee ergänzende Vorgaben zum Pillar 2 (aufsichtsrechtlicher Review-Prozess) gemacht, um die Fähigkeiten zur Identifikation und zum Managen von Risiken zu verbessern. Im Speziellen wurde hervorgehoben, dass das Risiko-Management ein angemessenes Management Information System (MIS) besitzt.
Mit den nun veröffentlichten Richtlinien werden in Ergänzung hierzu erstmals umfassende und konkrete regulatorische Anforderung an die IT-Architektur, das Datenmanagement und die IT-Infrastruktur formuliert.
Inhalt
Der Terminus “risik data aggregation” bedeutet, dass das Sammeln und Verarbeiten der Daten so zu erfolgen hat, dass die Bank in der Lage ist, auf dieser Basis das Risiko Reporting bezüglich Risikotoleranz und Risikoappetit zu steuern.
Aus diesem Grund präsentiert das Papier eine Reihe von Zielen, welche die Fähigkeiten der Bank stärken sollen, Daten zu aggregieren und daraus Entscheidungsprozesse abzuleiten. Die Umsetzung dieser Ziele soll fundamentale Verbesserungen in folgenden Bereichen erzielen:
- Verbessern der Infrastruktur zum Reporting von Schlüsselinformationen, speziell der Daten, die vom Vorstand und Senior-Management verwendet werden, um Risiken zu überwachen und zu managen
- Verbessern der bankweiten Entscheidungsprozesse über die gesamte Bank hinweg
- Verbessern des Informationsmanagments über alle “legal entities” hinweg, durch Erleichterung umfassender Einschätzungen von Risikopositionen auf konsolidierter Ebene
- Reduzieren der Wahrscheinlichkeit und Schwere von Verlusten, die aus Schwächen des Risikomanagements resultieren
- Verbessern der Geschwindigkeit, mit der Informationen verfügbar werden – also auch der Geschwindigkeit, mit der Entscheidungen getroffen werden können
- Verbesserung der Qualität der strategischen Planung und der Fähigkeit, Risiken von neuen Produkten und Dienstleistungen zu managen
- Übergreifende Steuerung und Infrastruktur
- Fähigkeiten zur Risikodaten-Aggregation
- Risiko-Reporting-Routinen
- Aufsichtsrechlicher Review, Handwerkszeug und Kooperationen
Richtlinie I – Übergreifende Steuerung und Infrastruktur
Gemäß BCBS 239 soll eine Bank über eine übergreifende Steuerung und Infrastruktur verfügen. Daher ist ein starker Steuerungsrahmen zu errichten. Insbesondere muss der Vorstand die Implementierung dieses Rahmens durch das leitende Management überwachen.
- Der Vorstand und das leitende Management sind für die Identifikation, die Bemessung und die Steuerung des Dataqualitätsprozesses im Rahmen des übergreifenden Risikosteuerungsrahmens verantwortlich.
- Es ist eine Richtlinie zu erarbeiten, die Dienstleistungsvereinbarungen für in- und externe Prozesse bei allen datenbezogenen Prozessen wie Vertraulichkeiten, Vollständigkeiten und Verfügbarkeit des Risikomanagements umfasst.
- Der Vorstand und das leitende Management sollen die unternehmensweite Datenaggregation überwachen und genehmigen.
Richtlinie II – Fähigkeiten zur Risikodaten-Aggregation:
Die Datenarchitektur und IT-Infrastruktur einer Bank soll so geschaffen sein, dass diese die Risikodaten-Aggregation und die Risiko-Reporting-Fähigkeiten auch in Krisenzeiten leisten kann. Im Einzelnen werden unter anderem folgende Punkte genannt, die berücksichtigt werden sollen:
- Die Bank soll eine integrierte Klassifizierung und Architektur über die Bankengruppe hinweg aufbauen, welche Inhalte des Metadatenmodelles enthält, aber gleichzeitig einheitliche Identifikatoren und/oder einheitliche Namenskonventionen (unter anderem für Legal Entities, Kontrahenten, Kunden und Konten) nutzt.
- Rollen und Verantwortlichkeiten sollen so beschaffen sein, dass sie nach IT- und Businessverantwortlichkeiten zu unterscheiden sind. Die beiden Funktionen sollen gemeinsam eine adäquate Kontrolle über den gesamten Prozess hinweg gewährleisten.
- Genauigkeit und Richtigkeit: Eine Bank soll in der Lage sein, richtige und verlässliche Risikodaten zu generieren, die unter Normal- und Stressbedingungen Anforderungen an die Genauigkeit erfüllen. Die Daten sollen auf einer hochautomatisierten Basis aggregiert werden, um Fehlerwahrscheinlichkeiten zu reduzieren.
- Vollständigkeit: Die Bank soll in der Lage sein, alle materiellen Risikodaten über die Bankengruppe hinweg zu erfassen und zu aggregieren. Die Daten sollen nach Geschäftssparte, Anlageklasse, Industrie, Region und anderen Aufteilungen, die für die Risikobetrachtung von Relevanz sind, identifizierbar sein, sodass eine Identifizierung und das Risikoreporting von Engagements, Risikokonzentrationen und aufkommenden Risiken möglich sind.
- Zeitliche Aspekte: Eine Bank soll in der Lage sein, Risikodaten zeitnah (up to date) zu generieren und zu aggregieren. Hierbei sollen keine Abstriche an der Genauigkeit, Vollständigkeit und Korrektheit der Daten gemacht werden. Der genaue Zeitplan soll sich an der Natur und der Volatilität der gemessenen Risiken und dem übergreifenden Risikoprofil der Bank orientieren.
- Anwendbarkeit: Eine Bank soll in der Lage sein, Risikodaten auf Anforderung zu generieren und zu aggregieren. Hierbei sind Ad-hoc-Anfragen, Anforderungen im Rahmen von Stresstests und Krisensituationen, sich ändernde interne Anforderungen und aufsichtliche Anfragen zu berücksichtigen.
Richtlinie III – Risiko-Reporting-Routinen
Korrekte, vollständige und zeitnahe Daten sind Voraussetzung für ein effektives Risikomanagement. Daten alleine sind jedoch keine Garantie für die Verantwortlichen, dass angemessene Entscheidungen zu Risiken getroffen werden. Um Risiken effektiv managen zu können, benötigen die Entscheider die richtigen Informationen zur richtigen Zeit. Daher wurden einige Vorgaben für die Erstellung, den Inhalt und die Qualität von Risikoreports gemacht:
- Risikomanagment-Reports sollen Risikodaten akkurat und präzise übermitteln und die Risiken exakt reflektieren. Reports müssen überprüft und abgestimmt werden.
- Risikoreports müssen umfassend sein. Sie sollten alle materiellen Risiken der gesamten Organisation abdecken. Die Tiefe und der Anwendungsbereich sollten sich an der Größe und Komplexität der Banktätigkeit und des Risikoprofiles sowie an den Bedürfnissen der Empfänger orientieren.
- Übersichtlichkeit und Zweckdienlichkeit: Risikomanagement-Reports sollen Informationen klar und prägnant zusammenfassen. Reports sollen einfach zu verstehen, gleichzeitig jedoch umfangreich genug sein, um eine Entscheidung zu ermöglichen. Reports sollen bedeutende Informationen beinhalten, die auf den Adressaten zugeschnitten sind.
- Frequenz: Der Vorstand und das leitende Management bzw. andere zuständige Empfänger sollen die Reportingfrequenz und den Verteilerkreis bestimmen. Die Frequenz sollte sich in den Bedürfnissen der Empfänger widerspiegeln.
- Verbreitung: Die Risikomanagment-Reports sollen unter Beachtung von Vertraulichkeitsaspekten an die relevanten Adressaten verteilt werden.
Richtlinie IV – Aufsichtlicher Review
Aufseher sollen eine wichtige Rolle bei der Implementierung und bei der Überwachung spielen. Die Aufseher sollen die Einhaltung der Regeln innerhalb der Bank überwachen, um festzulegen, ob die Richtlinien dem gewünschten Ergebnis entsprechen, oder ob weitere Verbesserungen notwendig sind.
- Überprüfung: Die Aufseher sollen regelmäßig die Einhaltung der oben genannten Regeln überwachen.
- Abhilfe und aufsichtliche Maßnahmen: Aufseher sollen über die notwendigen Tools und Ressourcen verfügen, um Defizite in der Risikodaten-Aggregation und im Risikoreporting sowie effektive und zeitnahe Abhilfemaßnahmen zu adressieren. Aufseher sollen über die Fähigkeit verfügen, eine Reihe von Tools zu nutzen. Dies beinhaltet auch Pillar 2.
Einführungszeitraum und Übergangsfristen
Der Einführungsrahmen hängt davon ab, ob eine Bank als “global systemically important banks” (G-SIB), als “domestic systemically important bank” (D-SIB) oder als sonstige Bank klassifiziert wurde. Aus der Zuordnung in eine dieser drei Kategorien lassen sich die Umsetzungsfristen ableiten.
Kategorie | (voraussichtlicher) Einführungstermin |
global systematically important banks (G-SIB) | Dezember 2015 |
domestic systematically important banks (D-SIB) | Dezember 2015: Definition der D-SIB durch die deutsche Aufsicht Dezember 2018: Voraussichtliche Einführung für die als D-SIB definierten Instititue (3 Jahre nach Benennung durch die Aufsicht) |
sonstige Banken | Dezember 2015: Einführung wird gestaffelt nach der Tragweite der Anforderungen Dezember 2018: Voraussichtliche abschließende Umsetzung |
Unsere Leistungen
Die umfangreichen und in Teilen sehr detaillierten Vorgaben zur Datenverarbeitung in diesem Bereich stellen Banken vor große Herausforderungen. Unschwer ist zu erkennen, dass die Umsetzung mit großen Anstrengungen verbunden sind. Neben fachlichen Themen wie dem Bankgeheimnis (bei grenzüberschreitender Datenweiterleitung auf Kundenebene) und der Weisungsbefugnis (bei konsolidierten Töchtern, bei denen kein Weisungsrecht besteht bzw. dieses ausgeübt werden muss) muss auch ein Zielmodell entwickelt werden. So ist der Ansatz des Papieres an einem Zielbild orientiert, welches es gilt, fachlich zu erarbeiten und mit den entsprechenden Fachbereichen (beispielsweise Risikocontrolling, Finanzen, IT, Marktbereiche, Revision) und dem Vorstand abzustimmen. BCBS 239 ist also eine Chance, die fachlichen Prozesse und Abläufe unabhängig von den rechtlichen Anforderungen neu zu definieren.
Sind diese Hürden genommen, gilt es, eine Vielfalt von technischen Fragestellungen zu klären und zu lösen. Ohne ein leistungsfähiges Data Warehouse, welches die Anforderungen von BCBS 239 abdeckt, ist eine technische Umsetzung nicht denkbar. Die bestehende Systemarchitektur ist auf Leistungsfähigkeit, Erweiterbarkeit und Automatisierbarkeit hin zu überprüfen. Im Wesentlichen gibt es vier Handlungsfelder:
- IT-Architektur
- Organisations- und IT-Management
- Data-Quality-Anforderungen
- Risiko-Reporting