Aufrufe
vor 2 Jahren

RISIKO MANAGER 07.2016

  • Text
  • Institute
  • Unternehmen
  • Banken
  • Risiko
  • Risiken
  • Valuation
  • Modelle
  • Prudent
  • Insbesondere
  • Standardansatz
RISIKO MANAGER ist das führende Medium für alle Experten des Financial Risk Managements in Banken, Sparkassen und Versicherungen. Mit Themen aus den Bereichen Kreditrisiko, Marktrisiko, OpRisk, ERM und Regulierung vermittelt RISIKO MANAGER seinen Lesern hochkarätige Einschätzungen und umfassendes Wissen für fortschrittliches Risikomanagement.

16

16 RISIKO MANAGER 07|2016 Marktrisiken im Handelsbuch FRTB: Enorme Herausforderungen an die IT Mit der Veröffentlichung der „Minimum capital requirements for market risk“ (BCBS d352) im Januar 2016 wurden die neuen Regeln für den Fundamental Review of the Trading Book (FRTB) finalisiert. Das Papier des Baseler Ausschusses für Bankenaufsicht (Basel Committee on Banking Supervision – BCBS) sieht eine Umsetzungsfrist bis zum Jahr 2019 vor. Mit der Veröffentlichung kann nun die Implementierung der neuen Regeln geplant werden. Neben den Auswirkungen auf die Eigenkapitalanforderungen und die Eigenkapitalrentabilität stellt insbesondere die Implementierung der neuen Regeln an die IT-Systeme eine große Herausforderung dar. Betroffen sind Risikosysteme sowie insbesondere auch Systeme aus den Bereichen Marktdaten, Referenzdaten, Front Office, Meldewesen, Treasury, Reporting, etc. Neben der Implementierung der FRTB-Modelle muss auch noch der laufende Betrieb der existierenden VaR-Modelle (Value-at-Risk) sowie gegebenenfalls die parallele Implementierung von anderen IT-Projekten (wie z. B. BCBS 239) gewährleistet werden. Der nachfolgende Artikel widmet sich speziell den Herausforderungen, denen sich das IT-Management bei der IT-Umsetzung der FRTB-Regeln stellen muss. Parallelbetrieb der aktuellen und der neuen Modelle Während der Umsetzungsphase und eventuell auch darüber hinaus, müssen die betroffenen Banken sowohl die aktuellen VaR-Modelle als auch die Risikomodelle für den Standardansatz und gegebenenfalls auch die neuen internen Modelle parallel betreiben. Da alle drei Modelle sehr viele Gemeinsamkeiten und Überschneidungen haben, benötigen sie auch ähnliche Daten und eine ähnliche Systeminfrastruktur. Andererseits gibt es auch deutliche Unterschiede, z. B. bei „Sticky-Delta“, der Indexzerlegung oder der Vega-Skalierung. Bei der Umsetzung in den Risikosystemen sollte deshalb im Vorfeld geklärt werden, welchem Ansatz zu folgen ist. Einerseits lässt sich ein „Silo“-Ansatz wählen, bei dem alle drei Modelle völlig separat und isoliert voneinander umgesetzt werden. Dadurch vereinfacht sich zwar das Programm-, Test- und Release-Management, andererseits entstehen jedoch höhere Kosten für die IT. Im Extremfall müssten drei Risikosysteme parallel betrieben werden. Andererseits kann auch versucht werden, die Überschneidungen der Modelle herauszuarbeiten und diese möglichst nur einmal zu implementieren. Dieser Ansatz steigert jedoch die Komplexität des Projektmanagements erheblich, da sich die Überschneidungen ständig ändern können und Änderungen an den neuen Modellen keine Auswirkungen auf den laufenden Betrieb des VaR-Modells haben sollen. Definition der Handelstische Die Definition der Handelstische scheint auf den ersten Blick aus IT-Sicht nur zu bedeuten, dass eine neue Portfolio-Hierarchie in den Aggregations-Engines bereitgestellt werden muss. Die Definition der Handelstische hat jedoch signifikante Auswirkungen auf die Höhe der Risk Weighted Assets (RWA). Für die bestmögliche Neuausrichtung des Geschäftsmodells unter den neuen Regeln ist es daher wichtig zu wissen, wie sich verschiedene Definitionen der Handelstische auf die RWA niederschlagen. Falls die neuen Regeln in den Systemen schon implementiert wurden, lässt sich dies sehr einfach herausfinden, indem man verschiedene Portfolio-Konfigurationen laufen lässt. Dies setzt jedoch voraus, dass die Risikosysteme schon vor der Umsetzungsfrist implementiert wurden, sodass noch genügend Zeit für die Optimierung der Definition der Handelstische besteht. Risikosicht statt Produktsicht Eine wichtige, aber wenig beachtete Änderung unter FRTB ist die „Risikozentrierte Sichtweise“. Während man sich früher primär dafür interessierte, welche Risiken ein bestimmtes Portfolio an Finanzprodukten hat, wird unter FRTB der Fokus mehr auf das Risiko gelegt, das von einer Gruppe von Risikofaktoren ausgeht. Hätte man z. B. früher gefragt, wie hoch das Risiko der deutschen Staatsanleihen im Portfolio ist, würde man unter FRTB nach der Höhe des Risikos, das von der Änderung der Libor Kurve ausgeht, fragen. Die Aggregation nach Risikofaktoren bedeutet für bestimmte Simulationsmodelle aber einen erheblichen Mehraufwand oder einen kompletten Umbau der Rechenkerne. Zusätzliche Attribute für die Aggregation In den FRTB-Regeln werden Instrumente und Risikofaktoren in verschiede Klassen kategorisiert. Ein Großteil dieser Kategorisierung ist entweder FRTB-spezifisch oder

Marktrisiko 17 nicht in geeigneter Form in den existierenden Systemen vorhanden. Als Beispiele lassen sich hier der „Correlation Trading Portfolio“ (CTP)-Indikator, ein „exotic indicator“ für den Residual Risk Add-On, der „market cap“-Indikator oder der FRTB-Sektor-Klassifizierung nennen. Die Beschaffung, Bereitstellung und Wartung dieser Attribute erfordert erfahrungsgemäß oft einen größeren Umbau der Quell- und Referenzdatensysteme sowie einen Umbau der Lieferstrecken. Beim Umbau sind zudem die BCBS 239-Prinzipien zu beachten. Reporting und Meldewesen Obwohl die Regeln für die Offenlegung unter der 3. Säule noch nicht feststehen, ist zu erwarten, dass es auch im Meldewesen erheblichen Anpassungsbedarf geben wird. Mit zahlreichen neuen Kennzahlen, dem Konzept der regulatorischen Handelstische sowie neuen Meldefrequenzen müssen vermutlich sehr viele neue Kennzahlen und Daten produziert, geprüft und gemeldet werden. Es ist wahrscheinlich, dass die Anbieter von Reporting- und Meldewesen-Software hierzu neue FRTB-Module anbieten werden. Diese müssen jedoch noch konfiguriert und an die Liefersysteme angebunden werden. Credit Valuation Adjustment (CVA) Mit dem Internal Model Approach (IMM- CVA), dem Standardized Approach (SA- CVA) und dem Basic Approach (BA-CVA) waren ursprünglich für CVA unter FRTB drei Ansätze vorgesehen (BCBS d325). Mit dem Konsultationspapier BCBS d362 wird der IMM-CVA jedoch nicht mehr weiter verfolgt. Da die Regeln im Fall des CVA Anfang 2016 noch nicht finalisiert waren, ist eine Projektplanung für die Implementierung noch mit vielen Unwägbarkeiten verbunden. Default Risk Charge (DRC) Um auch Risiken wie den Ausfall von Anleihen im Handelsbuch zu berücksichtigen, wurde unter FRTB eine sogenannte Default Risk Charge eingeführt. Dieses Maß ist eine Weiterentwicklung der bisherigen Incremental Risk Charge (IRC). Da sowohl DRC als auch IRC auf ähnlichen Daten und Modellen beruhen, sollte die Erweiterung der Systeme zur Berechnung der DRC im Allgemeinen für die meisten Produkte, wie z. B. Anleihen keine großen Schwierigkeiten bedeuten. In die Berechnung der DRC müssen jedoch im Vergleich zur IRC auch Equity Produkte, wie z. B. Aktien, miteinbezogen werden. Da hierfür in vielen Systemen noch keine entsprechenden Daten vorhanden sind, müssen diese erst aus anderen Systemen beschafft und für die Berechnung der DRC transformiert werden. Dieses Prozedere wird noch dadurch erschwert, dass unter FTRB auch viele Indexprodukte und Optionen mit mehreren Basiswerten zerlegt werden müssen. Liegt z. B. eine europäische Option auf den DAX im Handelsbuch, so muss die DRC für alle Einzelkomponenten berechnet werden. Die Berechnung per se stellt hier nicht die große Schwierigkeit dar, sondern die Beschaffung und Verwaltung der notwendigen Daten. Umstieg auf neue Technologien Viele interne Modelle zur Berechnung des Value-at-Risk (VaR) wurden vor über zehn Jahren implementiert und seitdem teils nur geringfügig angepasst. Die damals benutzten Technologien sind heute teilweise schon veraltet bzw. sehr teuer in der Wartung oder Lizenzierung. Mit der Implementierung der neuen Modelle bietet sich die Möglichkeit, auf neue Technologien umzusteigen. Mit neuen Big-Data-Technologien kann etwa die Risikodatenaggregation deutlich effizienter und kostengünstiger gestaltet werden. Offene Punkte Obwohl die FRTB-Regeln sehr detailliert sind, gibt es in einigen Punkten noch Interpretationsbedarf, der von der Fachabteilung oder dem Regulator geklärt werden muss. Dies führt in der Praxis dazu, dass für die IT-Umsetzung keine ausreichend klaren Spezifikationen erstellt werden können. Dies verzögert daher die Umsetzung und verkompliziert das Projektmanagement. Es empfiehlt sich hier Wahlmöglichkeiten zu implementieren, die es einem erlauben, gegebenenfalls zwischen verschiedenen Regelauslegungen ohne großen Aufwand zu wechseln. Spezifische Herausforderungen: Internes Modell Expected Shortfall (ES) statt Value-at-Risk (VaR) Risikokennzahlen wie der ES oder der VaR werden üblicherweise in den Aggregations-Systemen berechnet und benötigen in der Regel nicht mehr, als die Profit & Loss (P&L)-Szenarien für das zugrunde liegende Portfolio. Die Umstellung des Risikomaßes von VaR nach ES sollte deshalb keine großen Herausforderungen für die Systeme darstellen. Unter FRTB wird der Begriff ES jedoch etwas weiter gefasst und bezieht sich sowohl auf den modellierbaren Teil mit P&L-Szenarien, als auch auf den nicht-modellierbaren Teil sowie deren Aggregation. Da die Berechnung des ES für nicht-modellierbare Komponenten und die Aggregation des ES ein neues Konzept darstellt, sind mehrere Systemanpassungen nötig. Neue Halteperioden - Liquidity Horizons (LH) Auch in Stresssituationen soll sichergestellt werden, dass Banken genügend Sicherheiten vorhalten können und Risikopositionen gegebenenfalls schnell verkaufen können. Allerdings lassen sich nicht alle Risikopositionen gleich schnell abbauen. Zum Beispiel können liquide Aktien von internationalen Firmen im Notfall vermutlich deutlich schneller verkauft werden, als bestimmte illiquide strukturierte Produkte. Um diesen Unterschieden Rechnung zu tragen, werden für unterschiedliche Risikofaktoren verschiedene Halteperioden vorgegeben, die von 10 bis 120 Tagen reichen. Für die Implementierung bedeutet dies erst einmal, dass Risikofaktoren in unterschiedliche Kategorien von Halteperioden eingruppiert werden müssen, z. B. über Zuordnungstabellen. Für den modellierbaren Teil der Risikofaktoren wird dann ein skalierter ES berechnet, der auf einer vom Regulator vorgegebenen Summenformel basiert und die unterschiedli-

RISIKO MANAGER

RISIKO MANAGER 01.2019
RISIKO MANAGER 02.2019
RISIKO MANAGER 03.2019
RISIKOMANAGER_04.2019
RISIKO MANAGER 05.2019
RISIKO MANAGER 06.2019
RISIKO MANAGER_07.2019
RISIKO MANAGER 08.2019
RISIKO MANAGER 09.2019
RISIKO MANAGER 10.2019
RISIKO MANAGER 01.2018
RISIKO MANAGER 02.2018
RISIKO MANAGER 03.2018
RISIKO MANAGER 04.2018
RISIKO MANAGER 05.2018
RISIKO MANAGER 06.2018
RISIKO MANAGER 07.2018
RISIKO MANAGER 08.2018
RISIKO MANAGER 09.2018
RISIKO MANAGER 10.2018
RISIKO MANAGER 01.2017
RISIKO MANAGER 02.2017
RISIKO MANAGER 03.2017
RISIKO MANAGER 04.2017
RISIKO MANAGER 05.2017
RISIKO MANAGER 06.2017
RISIKO MANAGER 07.2017
RISIKO MANAGER 08.2017
RISIKO MANAGER 09.2017
RISIKO MANAGER 10.2017
RISIKO MANAGER 01.2016
RISIKO MANAGER 02.2016
RISIKO MANAGER 03.2016
RISIKO MANAGER 04.2016
RISIKO MANAGER 05.2016
RISIKO MANAGER 06.2016
RISIKO MANAGER 07.2016
RISIKO MANAGER 08.2016
RISIKO MANAGER 09.2016
RISIKO MANAGER 10.2016
RISIKO MANAGER 01.2015
RISIKO MANAGER 02.2015
RISIKO MANAGER 03.2015
RISIKO MANAGER 04.2015
RISIKO MANAGER 05.2015
RISIKO MANAGER 06.2015
RISIKO MANAGER 07.2015
RISIKO MANAGER 08.2015
RISIKO MANAGER 09.2015
RISIKO MANAGER 10.2015
RISIKO MANAGER 11.2015
RISIKO MANAGER 12.2015
RISIKO MANAGER 13.2015
RISIKO MANAGER 15-16.2015
RISIKO MANAGER 17.2015
RISIKO MANAGER 18.2015
RISIKO MANAGER 19.2015
RISIKO MANAGER 20.2015
RISIKO MANAGER 21.2015
RISIKO MANAGER 22.2015
RISIKO MANAGER 23.2015
RISIKO MANAGER 24.2015
RISIKO MANAGER 25-26.2015
 

Copyright Risiko Manager © 2004-2017. All Rights Reserved.