Die Intention des Baseler Komitees zielt auf einen Wandel in der Risikosteuerung. Eine auf Einzelrisiken fokussierte Sicht ist weiterzuentwickeln zu einem holistischen Bild. Schließlich schlagen sich makroökonomische Szenarios in allen Risikoarten der Bank nieder und betreffen das Institut als Ganzes. Diese Erkenntnis ist nicht neu, wurde aber durch die Finanzkrise auf dramatische Weise verdeutlicht. Diese in der Finanzkrise gewonnenen Erkenntnisse schlagen sich nun nieder in den in letzter Zeit stark in den Fokus geratenen Stresstests. Deren Umsetzung im Bankbetrieb gestaltet sich oft mit erheblichem Aufwand, was der bestehenden Architektur geschuldet ist. Schließlich sind mehrere Szenarios parallel in verschiedenen Systemen (Silos) durchzuführen und deren holistische Sicht und konsistente Umsetzung sicherzustellen. Mit den bestehenden Systemen ist dies oft nur schwer möglich. Es stellt sich die Frage nach einer neuen Architektur, die alle Risikoarten zusammenfasst, sortiert und sicherstellt, dass neu aufkommende Fragen ebenso eingegliedert werden können, ohne strukturelle Änderungen vornehmen zu müssen. Dies wird nicht ohne Eingriff in die bestehende Systemlandschaft möglich sein. Die bestehende Architektur der Risikosteuerung limitiert die durchzuführenden Stresstests. Das Ausrollen eines konsistenten Metaszenarios über alle Risikosilos ist nur mit erheblichem Zusatzaufwand verbunden. Die Restriktionen wirken in drei Richtungen. Zum einen können in den Silos nur die Stressparameter verarbeitet werden, die in den Risikoberechnungen der Silos auch Eingang finden. So sind Zinsszenarios nicht nur klassisch im ALM-System einzubinden, sondern beispielsweise auch im Liquiditätsrisiko zu berücksichtigen. Szenariodaten einer Prepaymentrate wirken nicht nur im Kreditrisiko, sondern beeinflussen gleichermaßen auch das Zinsänderungsrisiko oder die Liquidität.
In einem Stressszenario sind die einzeln definierten Szenarioparameter untereinander natürlich nicht unabhängig. So sind als zweiter Punkt die Interdependenzen zwischen einzelnen Risikoparametern zu berücksichtigen. Diese können von einfachen Korrelationen bis zu formalen Abhängigkeiten reichen. In unserem Beispiel ist eine signifikante Korrelation zwischen den Prepayment-Rates und dem Zinsszenario zu erwarten. Derartige Abhängigkeiten sind oftmals bereits bekannt und modelliert, es fehlt aber ein architektonischer Rahmen, um sie risikoübergreifend auswerten zu können. Die beschriebenen Aspekte eines Stresstests bilden bis hierher nur Szenarios mit statischem Verhalten ab. Das heißt, die betrachteten Positionen oder Portfolios zeigen keine Reaktion auf gestresste Markt- oder Geschäftsparameter des statischen Szenarios. Dies geschieht durch sogenannte „Behavioural-Analysis“-Modelle. In der Vergangenheit wurden bereits einige dieser Zusammenhänge evaluiert. So wurde etwa durch die Universität St. Gallen bei der Modellierung von Bodensatzprodukten der Zusammenhang zwischen Zinshöhe und Volumenentwicklung einbezogen. Die Integration dieses dynamischen Aspekts offenbart die 3. Restriktion der Stresstests. Die dynamische Betrachtung erlaubt also einen realistischeren Blick auf die zukünftige Situation. Diese Sicht wird auf die verschiedenen Risiken sowohl kompensatorische als auch verstärkende Wirkungen zeigen. Im Kern erfolgt so die umfassende und konsistente Abbildung eines makroökonomischen Szenarios.
Architektur eines konsistenten Stresstestsystems
Wenn nun solche kombinierten Stresstests erforderliche Praxis werden, wird dies auch auf die bestehende IT-Architektur Auswirkungen haben: Eine Architektur, die den beschriebenen Anforderungen gerecht werden soll, muss zwei grundsätzliche Voraussetzungen erfüllen:
▷Simultanität und Integrität von Stress-szenarios.
▷Einbeziehen der dynamischen Komponente.
Die Umsetzung von Stresstests erfordert eine ganzheitliche Sicht auf die makroökonomische Situation, die sich auch organisatorisch niederschlagen muss. Es ist eine organisatorische Einheit gefordert, der die Sicherstellung der Simultanität und Integrität von Stressszenarios obliegt. Wie bereits ausgeführt, sieht die Aufsicht das Erfordernis, diesen Prozess auch systemisch zu unterstützen. Das umzusetzen, zielt auf eine zentrale Steuerung, die die Silosysteme mit Stressparametern versorgt und Ergebnisse zentral einsammelt und auswertet.
Somit ergeben sich Anforderungen sowohl an die Organisation als auch an die beteiligten Systeme. Innerhalb der Organisation ist eine zentrale Steuerung erforderlich, um
▷alle Risiken zu berücksichtigen und
▷definierte Stresstests auch in allen Risiken zu berücksichtigen.
Hierzu gibt es keine Alternative. Zur Lösung der technischen Anforderungen an die Umsetzung bieten sich zwei unterschiedliche Wege an. Zum einen die Zentralisierung des Risikomanagements in einem System. Offensichtlicher Vorteil ist die Integrität des Systems. Die Risikoapplikationen greifen auf einen zentralen Datenbestand zu und somit sind Interaktionen zwischen den Risikoapplikationen direkt möglich. Nachteil allerdings ist, dass eine solche monolithische Applikation hohe Implementierungskosten hat und bestehende Risikoapplikationen nicht mehr genutzt werden können.
Alternativ ist ein dezentrales Risikomanagement, das aber von zentraler Stelle aus inhaltlich in Bezug auf die Stresstests gesteuert, in der Ausführung synchronisiert wird und deren Ergebnisse konsolidiert werden. Vorteil dieser Architektur ist, dass die bestehenden Risikomanagement-Systeme, in denen die Silostresstests derzeit laufen, nicht alle ausgetauscht werden müssen, sondern lediglich einen technischen und organisatorischen Überbau bekommen, um eine konsolidierte Behandlung der Stresstests sicherzustellen. Eine solche zentrale Unterstützung stellt jedoch vergleichsweise hohe Systemanforderungen an eine Umsetzung. Voraussetzung einer praktikablen Lösung ist die Beibehaltung der bestehenden Architektur und Softwarekomponenten. An dieser Stelle würden sich standardisierte Schnittstellen auszahlen, wie sie durch verschiedene Arbeitskreise, wie etwa BIAN, verfolgt werden. Deren Umsetzung hat jedoch noch nicht die erforderliche Verbreitung gefunden. So ist durch eine zentrale Applikation sicherzustellen, dass mehrere heterogene Systeme verknüpft werden, die meistenteils nicht auf einer zentralen Datenbank („Single Point of Data“) fußen. Aus diesem Grund muss ein solches System in der Lage sein, die vielen unterschiedlichen und dezentralen Datenquellen der Risikosilos zu konnektieren, mit Stressparametern zu beschicken und die Ergebnisse zu lesen. Zudem bestehen Abhängigkeiten zu den Batchroutinen der Risikosysteme und steigende Anforderungen an die Performance. All dies erscheint im Pflichtenheft einer zentralen Szenario Workbench (Die Fragen der Schnittstellen, Datamarts und Anbindung an Drittsysteme können an dieser Stelle nicht behandelt werden, stellen jedoch die Kernkompetenz eines solchen Systems dar und bedürfen weiterer Ausführungen.).
Nachfolgend soll eine Systemarchitektur aufgezeigt werden, die den Anforderungen genügt und zugleich offen für künftige Modellierungen und Systeme ist. Zunächst sollen die einfließenden Parameter dargestellt werden. Die beschriebenen Szenarioparameter lassen sich in vier Kategorien einteilen.
▷Marktparameter sind die bestens bekannten externen Größen, die sich auf die Risikobewertung auswirken. Es waren historisch die ersten Parameter, die zur Risikobewertung betrachtet wurden. Hierzu zählen Zinskurven und Wechselkurse.
▷Geschäftsparameter wie PD und LGD. Diese ermöglichen ebenso direkt, also ohne auf den Geschäftscashflow oder andere Parameter wirkend zu betrachten, die Generierung von statischen Szenarios.
Hinzu kommen Modellierungen von Wirkungszusammenhängen zwischen Parametern, die man als dynamische Szenarios bezeichnen kann. Diese teilen sich wie folgt auf:
▷Marktmodelle, die Zusammenhänge zwischen den einzelnen Marktparametern abbilden. Prominentestes Beispiel ist der Zusammenhang zwischen Zins und Wechselkurs.
▷Geschäftsdatenmodelle, wie den oben genannten Zusammenhang zwischen Zinshöhe und Volumenentwicklung in Sichteinlagen, sogenannte „Behavioural Models“, stellen die komplexesten Modelle dar.
In der Grafik ist diese Logik mit illustrativen Modellen dargestellt.
Diese Parameter sind nun in eine Architektur einzupassen. Die Definition der Stressszenarios unter Einbeziehung der dynamischen Parameter erzeugt ein Set an Eingangsdaten für die Risikosilos. Neben den statischen Parametern sind die dynamischen nun Bestandteil des Metaszenarios. Durch die Modellierung, die unter Verwendung unterschiedlichster Eingangsgrößen geschieht, stellen Cashflows den kleinsten gemeinsamen Nenner dar, auf dem die Verarbeitung in den nachgelagerten Systemen erfolgt. Mit geänderten Markt- und Geschäftsparametern sowie gestressten (Kompensations-) Cashflows können die entsprechenden Risikomaße berechnet werden. Diese sind in einem weiteren Schritt zentral einzusammeln, zu aggregieren und in einer Risikotragfähigkeitsanalyse des Eigenkapitals zu reporten, die hier nicht näher ausgeführt wird.
Fazit
Die länderübergreifende Diskussion von Stresstests für Banken liegt nun etwas mehr als zwei Jahre zurück und in weiten Teilen wurden die darin enthaltenen Forderungen nach bankindividuellen Stresstests in die nationale Regulierung aufgenommen und seitens der Banken umgesetzt. Erste Reaktion war, Stresstests als modifizierte Szenarios in den einzelnen Applikationen durchzuspielen. Es ist jedoch auffällig, dass Risikoparameter sich nicht voneinander unabhängig verändern. Vielmehr bestehen multiple und komplexe Abhängigkeiten. In einem sauber definierten Metaszenario sind diese Zusammenhänge und Abhängigkeiten bereits inkludiert, jedenfalls die Zusammenhänge zwischen einzelnen Parametern des Marktes (Zinssatz, Wechselkurse etc.) und der geschäftsbezogenen Parameter (PD, LGD etc.). Diese Sicht ist zu ergänzen durch Cashflows von Geschäften, die in einem Szenario Änderungen unterliegen. Niederschlag finden diese in „Behavioural Models“, die ebenfalls in die Metaszenariodefinition einfließen.
Systemisch stellen diese Anforderungen die Banken vor eine Aufgabe, die Softwarearchitektur darauf abzustimmen. Eine veritable Lösung ist, die bestehenden (dezentralen) Risikosysteme mit ihren Szenariofunktionen auch weiterhin zu nutzen, aber zu synchronisieren mit einer (zentral organisierten) Szenario Workbench. In ihr werden Stressszenarios zentral definiert und das Metaszenario simultan in den bestehenden Softwareapplikationen simuliert und die Auswirkungen wieder in der zentrale Szenario Workbench zurückgeführt und dort aggregiert. Ergänzt wird diese Szenarioverwaltung durch weiterführende Berechnungen zur Risk-Return-Steuerung und Eigenmittelallokation.