Harmonisierung des Stresstesting

Die Aufsicht rückte in der näheren Vergangenheit daher ihren Fokus immer stärker auf Szenario-basierte Analysen und verwendete eher Stresstestergebnisse für vergleichende Solvabilitätsanalysen, wie beispielsweise im Zuge der letzten EZB-Stresstestübung.

Für die Institute folgten aus dieser Entwicklung stetig höhere und deutlich komplexere Umsetzungs- und Durchführungsaufwände und die Notwendigkeit, sich in kurzer Zeit immer wieder auf neue Stresstestanforderungen einstellen zu müssen. Dies gilt für alle Arten von aufsichtsrechtlich geforderten Stresstests. Einen Überblick über die jüngsten Entwicklungen gibt die folgende Abbildung.

Abbildung 1: Ausgewählte, gestiegene Anforderungen im Rahmen des Stresstestings

Aktuell werden im aufsichtsrechtlichen Kontext folgende Stresstests verlangt:

• Säule I – Stresstest (Basel-III-Stresstest) betrifft nur Institute, welche interne Risikomessmodelle zur Berechnung ihrer Eigenkapitalanforderungen verwenden (sog. Modelle-Banken).
• Säule II – Stresstests (ICAAP- bzw. MaRisk-Stresstests) hingegen müssen alle Institute im Rahmen ihrer ökonomischen Risikotragfähigkeitsermittlung bzw. Kapitalplanung durchführen.
• Beim EZB/EBA-Stresstest handelt es sich um eine regelmäßige Erhebung der europäischen Aufsichtsbehörden, bei der signifikante Banken(-gruppen) explizit auf ihre Krisenfestigkeit geprüft werden (sog. EZB-Institute).

Aufgrund der gestiegenen Anforderungen in den unterschiedlichen Stresstestarten und der zunehmend von der Aufsicht geforderten Konvergenz der Stresstestdurchführung, auch aufgrund von Interdependenzen zwischen den Stresstests, ergeben sich diverse Herausforderungen für die betroffenen Institute, welche im zweiten Teil des Artikels dargestellt werden. Die Harmonisierung der Stresstestarchitekturen stellt einen Lösungsansatz zum Bestehen der Herausforderungen dar. Dieser wird im dritten Teil vorgestellt.

Herausforderungen

Banken stehen heutzutage vor einer Vielzahl an Problemstellungen gegenüber, die in der folgenden Abbildung übersichtsartig dargestellt werden.

Abbildung 2: Aktuelle Problemstellungen im Kontext Stresstesting

1. Daten

Für den EZB-Stresstest werden Daten aus verschiedenen Bereichen der Bank benötigt (u.a. Risikocontrolling, Meldewesen und Accounting). Diese werden in der Regel aus den dezentral bestehenden Datenbanken der bankinternen Bereiche bezogen.

Die Überleitbarkeit von gleichen Daten aus verschiedenen Datenquellen einer Bank ist jedoch oftmals nicht vollständig möglich bzw. verursacht hohe manuelle Aufwände. Dies führte im vergangenen EZB-Stresstest zu Inkonsistenzen der verwendeten Informationen und provozierte Rückfragen und Korrekturanforderungen der Aufsicht.

Zudem gingen die im EZB-Stresstest gestellten Anforderungen an die Granularität der Daten über bisherige Anforderungen z.B. der COREP-Meldung hinaus. So war beispielsweise eine Zuordnung von KSA-Positionen zu IRBA-(Unter-)Forderungsklassen gefordert – diese war nur mithilfe zusätzlicher Informationen über die jeweilige Forderung möglich.

2. Prozesse und Schnittstellen

Zur Datenbereitstellung, -aufbereitung und -verarbeitung im Rahmen von Stresstests werden in der Regel separat bestehende Datenbanken sowie Kalkulations- und Verarbeitungssysteme verwendet. Dies führt zu zwei grundlegenden Herausforderungen:

1. Um die Integrität der im Rahmen der Stresstestdurchführung verwendeten Systeme zu gewährleisten, sind sogenannte Reconciliation-Maßnahmen in die Verarbeitungsprozesse zu integrieren. Mittels dieser Maßnahmen soll die Überleitbarkeit gleicher Informationen aus verschiedenen Quellsystemen sichergestellt werden.
2. Um auf die sich fortwährend ändernden Anforderungen der Aufsicht adäquat reagieren zu können, sind die bankinternen Systeme und Verarbeitungsprozesse flexibel auszugestalten. Der hohe Anteil an manuellen Workarounds im letzten EZB-Stresstest hat gezeigt, dass diese Flexibilität noch nicht vorhanden ist.

3. Kalkulation

Für die Kalkulation von gestressten Parametern und Kennzahlen werden in der Regel vorhandene (Teil-)Standardlösungen verwendet. Diese im Regelfall starr ausgestalteten Tools sind nicht ausreichend an die sich fortlaufend ändernden Anforderungen der EBA und EZB adaptierbar. Infolge dessen werden im EZB-Stresstest von vielen Banken zusätzlich „manuelle“ Kalkulationen in Excel/ Access aufgesetzt – Mehraufwand und Fehleranfälligkeit sind hierdurch vorprogrammiert.

4. Reporting

Für die Befüllung der von der EBA vorgegebenen Templates können die bestehenden Standardreports aus den regulatorischen und ökonomischen Stresstests nicht verwendet werden. Die Templates werden daher vorrangig dezentral in den verschiedenen Bereichen der Bank manuell befüllt. Die Fehleranfälligkeit dieser „Reportinglösungen“ ist zum einen durch Eingabefehler bei der manuellen Erfassung aber auch durch die fehlende Überprüfung der Reportingdaten gegeben.

5. Zeitdruck

Der EZB-Stresstest ist innerhalb eines zeitlich eng begrenzten Rahmens durchzuführen. Innerhalb weniger Monate sind Datenbereitstellung, Berechnung der Szenarien und ihrer Auswirkungen sowie die Templatebefüllung vorzunehmen. Je nach Qualität der Daten, Systeme und Methodik werden von der Aufsicht Korrekturanforderungen gestellt. Diese führen oftmals dazu, dass Berechnungen vollständig oder in Teilen mehrfach durchzuführen sind. Die Effizienz der Prozesse sowie der verwendeten Kalkulationslösungen ist daher neben der Qualität von Daten, Systemen und Methoden von zentraler Bedeutung.

Lösungsansatz

Eine mögliche Antwort auf die zentralen Herausforderungen im Kontext von Stresstests spiegelt sich in einem Lösungsbild wider, das sowohl Harmonisierung als auch bewusste Trennung an den relevanten Stellen innerhalb des gesamten Stresstestwesens einer Bank vorsieht. Die Harmonisierung ist dabei von einer bewussten, aber ausgewählten Zentralisierung an den richtigen Stellen geprägt; in der Frage der Datenhaltung, der verwendeten Risikoparameter sowie Kalkulationstools und der anschließenden Ergebnisbereitstellung:

Abbildung 3: Zielbild Stresstestarchitektur

Harmonisierung ist somit ein zentrales Thema der Datenhaltung. Aber auch die Abstimmung zwischen Säule I und Säule II – Stresstests und hier insbesondere die Ableitung und Verwendung derselben Szenarien und im Idealfall derselben Risikoparameter beschreibt eine wesentliche Harmonisierungsbaustelle. Hier liegen große Potentiale, um aus dem bestehenden Stresstesting einen möglichst flexiblen und schnellen bzw. automatisierten Prozess zu formen. Beim Reporting empfiehlt sich eine enge Abstimmung insbesondere bei den Reports und Ergebnispräsentationen, die Auswertungen verzahnt aus beiden Säulen darstellen. Am Markt verfügbare Business Intelligence-Lösungen können hierbei unterstützen und standardisierte Reportvorlagen schnell verarbeiten sowie automatisierte Berichte erzeugen.

Separater Datenhaushalt für Eingangs- und Ergebnisdaten

Die Schaffung eines einheitlichen Datenhaushaltes und somit die Vorhaltung eines zentralen Datenablageortes für die Stresstestdaten ist ein zentraler Erfolgsfaktor. Doch auch die richtige Architektur bzw. Vorverarbeitung ist von zentraler Bedeutung. In einem ersten Schritt ist innerhalb des Stresstestdatenhaushaltes grundsätzlich die Vorhaltung und Schaffung weniger Ausgangsdatentabellen ratsam, in deren Datensätzen möglichst verschiedene Attribute aus verschiedenen Disziplinen integriert werden. In der Praxis ist dies oftmals aufgrund von unterschiedlichen Datengranularitäten bzw. differierender Abbildungen von Einzeldaten bzw. -geschäften nicht möglich. Hier muss institutsspezifisch geprüft werden, inwieweit Verteilungslogiken aufgebaut werden können, die die Informationen mit möglichst wenig Informationsverlust auf Einzeldatensätze verteilen. In Häusern mit sehr vielen Einzeldatensätzen ist eine vorherige Datenaggregation aus Performancegründen zu empfehlen. Nur anhand benötigter Attribute für die spätere Kalkulation und Ergebnisbereitstellung werden Einzeldatensätze aggregiert. Hier kann das Beschleunigungspotential, insbesondere in der späteren Kalkulation enorm sein.

Zur Steigerung der Flexibilität empfiehlt es sich, sowohl in zentralen Datentabellen Dummyspalten für neue Informationen vorzuhalten, als auch mit flexibel erweiterbaren Mappingtabellen zu arbeiten, die weitere Informationen über entsprechende Identifier an die Ausgangsdatensätze heran spielen können.

Der Import der Daten sollte größtenteils automatisiert und mit entsprechenden DQ-Prüfungen erfolgen. Nichtsdestotrotz kann es notwendig oder auch sinnvoll sein, manuelle Daten zu integrieren. In diesem Fall bieten sich separate Eingabe- und Korrekturschnittstellen an, die den Nutzer anleiten, bzw. über weitere DQ-Regeln manuelle Eingabefehler vermeiden. Es sollten grundsätzlich alle Daten in dem Stresstestdatenhaushalt integriert werden, die für die Verarbeitung bzw. Kalkulation, aber auch für das anschließende Reporting notwendig sind. Eine anschließende weitergehende Verarbeitung in separaten Excellösungen aufgrund fehlender Informationen innerhalb des Stresstestdatenhaushaltes sollte wenn möglich vermieden werden.

Erstellung und Verarbeitung Stressrisikoparameter

Im Idealfall wird ein Set an identischen Szenarien in beiden Säulen verwendet. Grundsätzlich sollten ebenfalls dieselben Risikoparameter verwendet werden – soweit dies die methodischen und fachlichen Vorgaben erlauben. Mindestens jedoch sollten dieselben Stressannahmen bei der Ableitung von Risikoparametern herangezogen werden. Bei der eigentlichen Risikoparameterermittlung kann eine bestimmte Abfolge in der Ableitung (bspw. erst Säule I und anschließend Säule II – Risikoparameter) sinnvoll sein, wobei die mitgelieferten Determinanten aus dem vorherigen Ableitungsschritt die noch zu ermittelnden Risikoparametervariablen des folgenden Schritts bestimmen.

Zentrale Reportinglösung

Ein manuelles Zusammenführen von Daten, die unter Umständen aus verschiedenen Bereichen des Instituts zugeliefert und anschließend zentral aufbereitet werden müssen, kostet viel Zeit und birgt ein hohes manuelles Fehlerpotential. Insbesondere bei bestehenden Regelprozessen und –reports oder bei aufsichtsrechtlichen Prüfungen, für deren Ergebnislieferungen relativ stabile Ergebnisformate bereitgestellt werden, empfiehlt es sich dringend, eine zentrale BI-Lösung zu implementieren. Sie schafft es, in kurzen Verarbeitungszeiten qualitätsgesichert Reportvorlagen zu befüllen. Auch semi-stabile Ergebnisvorlagen können teilweise schnell und benutzerfreundlich angepasst werden. Zudem erlauben sie durch die zentrale Datenablage als auch die Definition von Benutzerrollen eine höhere Prozessstabilität und bessere Aufbewahrung von aktuellen und historisierten Ergebnissen. Die Gefahr einer unstrukturierten Ablage in undurchsichtigen Ordnerstrukturen von verschiedenen, vermeintlich finalen Ergebnissen – auch und vor allem in hektischen Phasen – kann hiermit reduziert werden.

Fazit

Bereits heute sind die regulatorischen Anforderungen an Stresstests sehr umfangreich und stellen Institute vor weitreichende Herausforderungen. Es ist zu erwarten, dass künftig die Bedeutung von Stresstests weiter steigen wird. Das gilt sowohl für die Qualität und Quantität des Stresstestings als auch für die Ableitung von Steuerungsmaßnahmen – durch die Institute selbst, aber auch stellvertretend durch die Aufsicht. Der nächste EU-weite Stresstest ist bereits für das Jahr 2016 angekündigt. Eine Optimierung der in den Instituten derzeit vorhandenen, zumeist heterogenen und parallel existierenden Stresstestarchitekturen ist vor diesem Hintergrund zeitnah zu empfehlen. Dabei sollten Abhängigkeiten zu anderen regulatorischen Initiativen – insbesondere die BCBS #239-Anforderungen – beachtet werden.