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.
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:
Aus diesem Grund wurden vier eng miteinander verbundene Richtlinien formuliert, die aus Sicht des Basler Ausschusses der Verbesserung bedürften, und entsprechende Prinzipien definiert. Die vier Themengebiete sind:
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.
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:
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:
Risikodaten, Aggregationsfähigkeiten und Risikoreporting-Routinen sollen als Teil des Geschäftskontinuitätsplanungsprozesses berücksichtigt werden.
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.
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 |
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:
Da die Fragestellungen, die sich für Institute ergeben, individuell und abhängig von der Zuordnung zu den Bankenkategorien sind, ist ohne einen qualifizierten Review wie beispielsweise eine Studie, aus der sich eine Handlungsempfehlung und ggf. ein Projektplan ableitet, nur schwer möglich.