ICAAP: Anforderungen und Umsetzung der neuen ICAAP-Vorgaben

Das Feld aufsichtlicher Anforderungen wird zunehmend dichter und komplexer. So sind bei der Umsetzung der neuen Anforderungen an den ICAAP nicht nur die rein fachlichen Vorgaben zu beachten, sondern auch all jene mit Fokus auf der technisch-prozessualen Realisierung sowie darüber hinaus auch jene des Meldewesens. An sich ist das nichts Neues. Jedoch erhöht sich die Taktung regulatorischer Neuerungen zusehends, sodass eine ganzheitliche Betrachtung dieser, gepaart mit einer zukunftsfähigen, pragmatisch anpassbaren bzw. erweiterbaren Realisierung an Bedeutung gewinnt. Nicht zuletzt, um selbst zukunftsfähig zu bleiben. 

Um sowohl die fachliche als auch technische Implementierung der ICAAP-Anforderungen im Einklang mit absehbaren zukünftigen Anforderungen sowie Problemen aus der alltäglichen Praxis darstellen zu können, haben wir unsere Erfahrungen und Kompetenzen zusammengebracht. Dies auch, um resultierende Erkenntnisse mit Ihnen zu teilen. In dem folgenden Beitrag erhalten Sie einen Überblick über die aktuellen Herausforderungen aus primär regulatorischer und praxisbezogener Perspektive. 

Die praktische Darstellung einer potenziellen Lösungsmöglichkeit stellen wir Ihnen in einem separaten Beratungsprogramm sowie dem mittels Power BI realisierten beispielhaften ICAAP-Reporting (Clickdummy) für Sie bereit.

Ausgangslage

Für Less Significant Institutions (LSI) ist mit Veröffentlichung des neuen ICAAP-Leitfadens der BaFin im Mai 2018 ein Verfallsdatum für die Nutzung des Going Concern Ansatzes alter Prägung in Kraft getreten. Untermauert wird dies mit der per 16.08.2021 veröffentlichten MaRisk-Novelle. Dort wird in AT 4.1 Tz. 2 die Umsetzung einer ökonomischen sowie einer normativen Perspektive gefordert und hinsichtlich deren Ausgestaltung auf den oben genannten ICAAP-Leitfaden der BaFin verwiesen. 

Folglich besteht die ICAAP-Welt zukünftig aus einer normativen sowie einer ökonomischen Perspektive, welche einzelne bereits bekannte Bausteine aus der „alten“ ICAAP-Welt in sich vereinen, diese jedoch um neue Aspekte erweitern.

 

Abbildung 1: Direkte Anforderungen der neuen ICAAP Anforderungen

Hier dürfte vor allem die Realisierung einer rein barwertigen Risikotragfähigkeitsrechnung eine Neuerung und Herausforderung für die meisten kleinen und mittelständischen Institute darstellen. Gleiches gilt für die Anforderung, dass im Rahmen der normativen Perspektive, die Entwicklung der RWA-Positionen für den gesamten Planungszeitraum unter Anwendung der für den jeweiligen Planungsstichtag gültigen CRR-Methoden, zu ermitteln ist. Sprich, die Institute müssen unter anderem in der Lage sein, geplante und absehbare künftige Änderungen der CRR-Methoden ab dem Zeitpunkt der regulatorischen Gültigkeit in der Kapitalplanung darzustellen.

Neben den aufgeführten direkten Anforderungen an die fachliche Umsetzung (vgl. ICAAP-Leitfaden der BaFin und MaRisk AT 4.1) sowie an die Ausgestaltung der Risikosteuerungs- und -controllingprozesse (vgl. MaRisk AT 4.3.2 ff.) gibt es bei der Umsetzung der neuen Anforderungen an den ICAAP und dessen An- bzw. Einbindung in die bestehende Prozesslandschaft diverse weitere (indirekte) Anforderungen zu beachten. So unter anderem die Vorgaben der MaRisk zu Organisationsrichtlinien, Dokumentation und Ressourcen (vgl. dazu MaRisk AT 5 – 7). Darüber hinaus die Anforderungen aus den BAIT hinsichtlich der technischen Realisierung des ICAAP.

Der ICAAP spielt zudem im Rahmen des Supervisory Review and Evaluation Process (SREP) eine wichtige Rolle bei der Bewertung der Institute. Hier erfolgt eine Betrachtung des ICAAP im Rahmen der Beurteilung der Angemessenheit der SREP-Bausteine Governance und Risikomanagement sowie Kapitaladäquanz. Eine Datenquelle der Aufsicht bildet dafür zudem die jährliche FinaRisikoV-Meldung (Verordnung zur Einreichung von Finanz- und Risikotragfähigkeitsinformationen nach dem Kreditwesengesetz).

 

Abbildung 2: Übersicht der wesentlichen aufsichtlichen Anforderungen an den ICAAP sowie an dessen Einbindung in die Banksteuerung. (Weitere Ausführungen siehe „Überblick relevante regulatorische Anforderungen“)

Die Anpassungen im Rahmen des ICAAP betten sich insofern inmitten der bankinternen Steuerungsprozesse ein und werden durch beschriebene Anforderungen sowohl ergänzt als auch durch die interne Prozesslandschaft restringiert. Eine vollumfängliche Berücksichtigung tangiert somit fast alle bankinternen Prozesse und Ebenen, wie nachfolgend illustrativ dargestellt.

 

Abbildung 3: Sphären der Risiko Governance im Kontext der ICAAP Anforderungen

Mit Umsetzung der neuen Anforderungen an den ICAAP sowie den aus den 2021er Novellen der MaRisk und der BAIT resultierenden Neuerungen bietet sich aktuell durchaus die Gelegenheit, die Eignung und Zukunftsfähigkeit der derzeit im Einsatz befindlichen Anwendungen zu hinterfragen. Damit einhergehend sollten ebenfalls die relevanten Datenflüsse und -schnittstellen sowie die zugehörigen Prozesse auf den Prüfstand gestellt werden. Dies auch und nicht zuletzt unter Beachtung der regulatorischen Anforderungen an interne Kontrollsysteme (Prozesse, Dokumentation, Ressourcen) sowie an die IT.

Zudem sollten Digitalisierungschancen, wie etwa der Einsatz von Cloudtechnologien und die Anbindung mobiler Endgeräte an das Reporting, aber auch die damit einhergehenden Risiken (z. B. Cyber-Risiken) betrachtet werden.

Aus der Praxis

Wie bereits beschrieben, sind die regulatorischen Anforderungen, welche es im Rahmen des täglichen „Doings“ zu beachten und zu erfüllen gilt, in den letzten Jahren umfangreicher und dichter, folglich komplexer geworden. Dabei haben wir in diesem Beitrag – auch um den Rahmen nicht zu sprengen – die absehbar anstehenden beziehungsweise zukünftigen Änderungen und Neuerungen (z. B. Stichwort Basel „4“: Output-Floor, neuer KSA Ansatz, Input-Floor für IRB Ansatz, neuer OpRisk Standardansatz, etc.) noch nicht einmal berücksichtigt.

So bilden neben den rein fachlich-methodischen Aspekten zur Umsetzung des ICAAP im Institut die prozessualen und technischen Aspekte (Datenqualität und -verfügbarkeit, Integrität der verwendeten Systeme, IT-Sicherheit, Abkehr von der Individuellen Datenverarbeitung) der Realisierung eine wichtige Rolle.

Hierbei trifft man auch in den 20er Jahren des 21. Jahrhunderts teilweise immer noch eher heterogene, historisch gewachsene Lösungen in den Instituten an, welche sich durch eine hohe Anzahl verschiedener Datenquellen und Schnittstellen sowie den damit einhergehenden Schnittstellen- bzw. Kompatibilitätsproblemen und einer Vielzahl selbstentwickelter Anwendungen (IDVen) auszeichnen. Damit einher gehen oftmals viele kleinteilige Prozessschritte, die in Summe ein gewisses Fehlerpotenzial in sich bergen, welches man sicher gerne vermeiden würde und dies grundsätzlich auch kann. Darüber hinaus stellt sich bei derartig komplizierten Lösungen die Integration neuer oder geänderter fachlicher Anforderungen oftmals als große Herausforderung dar. Ursachen dafür sind neben einer hohen Abhängigkeit von den internen Know-how-Trägern, die die jeweiligen Applikationen programmiert haben, bzw. die Betreuung der Programme durchführen, oftmals eine nicht vorhandene, nicht vollständige oder nicht mehr aktuelle Dokumentation. Zudem sind auch die initialen Anforderungen oftmals nicht im Detail dokumentiert, was Analysen sehr langwierig macht.

Überblick über die maßgeblichen Herausforderungen

Wir sehen daher vor allem die folgenden Herausforderungen bei der technischen Umsetzung der neuen Anforderungen an den ICAAP:

• Heterogenität der Anwendungen und Systeme: Verwendung verschiedener Anwendungen im Rahmen des Gesamtprozesses bis hin zur Erstellung der Reports.
• Ergebnisaufbereitung: Zusammenführung und Aufbereitung der Ergebnisse häufig in selbstentwickelten Lösungen (IDV), meist auf Basis von Excel, Access o. Ä.
• Transformation und Aufbereitung der Daten: häufig hoher manueller Aufwand bei der Zusammenführung, Transformation und Verarbeitung der Daten (Copy und Paste, Zwischenschritte via. Makro o. Ä., …) und damit einhergehende Anfälligkeit für Fehler.
• Heterogenität der Anwendungen und Systeme:
  • Schnittstellenproblematik zwischen Anwendungen/ Systemen: Output System A nicht oder nur bedingt geeignet als Input für System B –> Kompatibilitätsprobleme.
  • Daten aus verschiedenen Quellen lassen sich nicht zu 100% überführen und abgleichen aufgrund unterschiedlicher Umsetzung in Bezug auf betrachtete, bzw. verfügbare Kategorien und Kriterien, Granularität bzw. Aggregationslevel, etc.
• IKS – Internes Kontrollsystem: keine oder nur aufwändig durchführbare Tests / Kontrollen.
• Erweiterbarkeit/ Weiterentwicklung: hoher Aufwand bei der Erweiterung der Anwendungen, z. B. aufgrund der Implementierung neuer oder geänderter fachlicher Anforderungen.
• Handling: häufig eher umständliche und zeitaufwendig zu erstellende Sonderauswertungen wie zum Beispiel Ad-hoc Stresstests oder sonstige steuerungsrelevante Szenario- bzw. Auswirkungsanalysen.
• Archivierung: umständliche und/oder unvollständige Historisierung und Archivierung der Daten und (Zwischen-)Ergebnisse in einer Datenbank –> bei Bedarf schneller Zugriff auf alle historisierten Daten und Ergebnisse (z. B. für Prüfungen durch interne Revision, Wirtschaftsprüfer oder aufsichtliche Prüfungen).

ADVISORI Lösungsansatz

Zur Darstellung der aktuellen und zukünftigen Anforderungen hat ADVISORI in Kooperation mit einem Referenzkunden eine Anwendung zur Umsetzung ausgewählter Anforderungen, auf technischer sowie fachlicher Ebene, gebaut. Hier gelangen Sie direkt zum interaktiven Musterreporting aus der Anwendung.

 

Grundsätzlich stellt die Anwendung keine ausschließlich auf den ICAAP ausgerichtete Lösung dar, sondern kann auch für andere Aufgaben und Herausforderungen im Risikomanagement und -controlling eingesetzt werden, bei denen es um die Zusammenführung, Transformation, Verarbeitung von Daten geht sowie um die Generierung von Ergebnissen und deren Reporting.

Neben der Verwendung für die institutsspezifische Umsetzung des ICAAP sehen wir unter anderem die folgenden Anwendungsmöglichkeiten für unsere Anwendung:

• Managementreporting bzw. Risikoreporting gemäß BT 3 MaRisk (ADR, MPR, OpRisk, LiqR).
• Verwendung im Rahmen der Sanierungsplanung: turnusmäßige Aufbereitung der relevanten Daten rund um den Sanierungsplan mit Fokus auf den Sanierungsindikatoren (Ist, Entwicklung, Limitauslastung Schwellwerte, …).
• sonstige turnusmäßigen Controlling spezifischen Auswertungen und Reports (z. B. Vertriebscontrolling).
• Meldewesen IKS: Auswertung Meldewesendaten und Abgleich mit Daten / Kennzahlen der internen Risikosteuerung, sofern diese nicht auf Basis von Meldewesendaten erfolgt.

Durch einen generischen Aufbau werden jedoch nicht nur aktuelle, sondern auch mittelfristige sowie zukünftige Anforderungen als potenzielle Lösungsanwendungen gesehen. Durch eine simple Pflege und Wartung auf Python Basis können so sowohl heterogene Prozesslandschaften leicht integriert als auch beliebig erweitert werden.

 

Abbildung 4: Übersicht anstehender regulatorischer Anforderungen

Fazit

Der Regulator schärft mit den neuen Vorgaben an den ICAAP in Kombination mit den 2021er Novellen der MaRisk und der BAIT sowie den zukünftigen Initiativen ein klares Zielbild hinsichtlich einer ganzheitlichen Gesamtbanksteuerung, realisiert in einem vollumfänglichen digitalisierten Institut. Anforderungen wie BCBS 239, KnowYourCustomer sowie DSGVO setzten den Rahmen für dieses Zielbild. Im Laufe der Zeit wurde klar, dass der Regulator sukzessiv die Absicht verfolgt, Banken zur Digitalisierung zu „bewegen“. Darunter fällt vor allem die möglichst automatisierte Ausgestaltung der Systemlandschaft unter Einhaltung einer stetig steigenden Anzahl operativer Prozess- und Dokumentationsrichtlinien. Ergänzt wird dies durch den Wunsch einer möglichst hohen Flexibilität hinsichtlich anzubindender Daten, stetige, aber schnell anpassungsfähige Datenverarbeitung, um nicht zuletzt in der Lage zu sein, nachvollziehbare sowie strategisch orientierte Geschäftsführung zu ermöglichen und somit den nachhaltigen Erfolg gewährleisten und kommunizieren zu können.

Die Umsetzung dieses Zielbilds kann und wurde in den letzten Jahren meist durch die Erweiterung der bestehenden Anwendungslandschaft erfüllt. Mit zunehmender Komplexität wächst jedoch der Aufwand, diesen „Flickenteppich“ handzuhaben, zu pflegen und zu erweitern. Aufgrund dessen stellt sich auch hier wieder die Frage: Rechtfertigen die Skaleneffekte eines disruptiven und ganzheitlichen Umdenkens, der gelebte Prozess bzw. die Schaffung der Voraussetzungen für eine zukunftsfähige Lösung den Mehraufwand gegenüber der sukzessiven Erweiterung der bestehenden Anwendungen (Systemlandschaft), um die regulatorischen sowie institutsspezifischen Anforderungen und Entwicklungen zu integrieren?

Wahrscheinlich wird beides ein Teil der Wahrheit abbilden. LSIs haben diesbezüglich jedoch einen signifikanten Vorteil. Ein generelles Umdenken erfordert meist weniger Anpassungs- und Abstimmungsaufwand als bei ihren größeren Gegenspielern. Die entstehenden Skaleneffekte sind somit schneller operationalisierbar und ebnen den Weg dafür, dass Digitalisierung von Banken nicht nur ein Modewort, sondern greifbare Zukunftsmusik ist.

Überblick relevante regulatorische Anforderungen

Hier finden Sie eine Übersicht der wesentlichen aufsichtlichen Anforderungen an den ICAAP sowie an dessen Einbindung in die Banksteuerung.

Primäre bzw. direkte regulatorische Anforderungen in Bezug auf den ICAAP und dessen Umsetzung im Rahmen der Banksteuerung:

• KWG §25a
• MaRisk in der Fassung vom 16.08.2021
  • AT 2.2 Risiken
  • AT 4.1 Risikotragfähigkeit
    • Tz. 2: Das Institut hat einen internen Prozess zur Sicherstellung der Risikotragfähigkeit einzurichten. Die hierzu eingesetzten Verfahren haben sowohl das Ziel der Fortführung des Instituts als auch den Schutz der Gläubiger vor Verlusten aus ökonomischer Sicht angemessen zu berücksichtigen. Zur Erfüllung dieser Ziele sind Verfahren zur Sicherstellung der Risikotragfähigkeit, zum einen aus der normativen Perspektive und zum anderen aus der ökonomischen Perspektive einzurichten.
    • Anmerkungen zu Tz. 2: Ausgestaltung der Risikotragfähigkeitskonzepte – Einzelheiten zur Ausgestaltung der Risikotragfähigkeitskonzepte ergeben sich aus dem Leitfaden zur aufsichtlichen Beurteilung bankinterner Risikotragfähigkeitskonzepte in der jeweils gültigen Fassung.
  • AT 4.3.2 Risikosteuerungs- und -controllingprozesse
  • AT 4.3.3 Stresstests
  • BTR Anforderungen an die Risikosteuerungs- und -controllingprozesse
  • BT 3 Anforderungen an die Berichterstattung
• ICAAP-Leitfaden BaFin 05/2018: Aufsichtliche Beurteilung bankinterner Risikotragfähigkeitskonzepte und deren prozessualer Einbindung in die Gesamtbanksteuerung („ICAAP“) – Neuausrichtung:
  • ICAAP = Interner Prozess zur Sicherstellung der Risikotragfähigkeit gemäß § 25a Abs. 1 Satz 3 Nr. 2 KWG i.V.m. AT 4.1 Tz. 1 MaRisk
  • Interner Prozess zur Sicherstellung der Risikotragfähigkeit gemäß § 25a Abs. 1 Satz 3 Nr. 2 KWG i.V.m. AT 4.1 Tz. 1 MaRisk umfasst:
    • ein Risikotragfähigkeitskonzept mit einer Risikotragfähigkeitsrechnung und einer Kapitalplanung
    • sowie ergänzende Stresstests
    • und die prozessuale Verknüpfung mit der Festlegung der Strategien einerseits und den Risikosteuerungs- und –controllingprozessen andererseits  

Sekundäre regulatorische Anforderungen in Bezug auf den ICAAP mit Fokus auf der Beurteilung der Angemessenheit im Rahmen des aufsichtlichen Überprüfungs- und Bewertungsprozess:

• SREP: Betrachtung des ICAAP im Rahmen der Beurteilung der Angemessenheit der SREP-Bausteine Governance und Risikomanagement sowie Kapitaladäquanz
• FinaRisikoV: jährliche Meldung des ICAAP im Rahmen des Meldewesens (u. a. Ergebnis Risikoinventur, ökonomische Perspektive / RTF, normative Perspektive / Kapitalplanung)

Sonstige Anforderungen mit indirektem Bezug zum ICAAP als Element der Banksteuerung:

• BAIT: Der Einsatz von Informationstechnik (IT) in den Instituten, auch unter Einbeziehung von IT-Services, die durch IT-Dienstleister bereitgestellt werden, hat eine zentrale Bedeutung für die Finanzwirtschaft und wird weiter an Bedeutung gewinnen. Dieses Rundschreiben gibt auf der Grundlage des § 25a Abs. 1 des Kreditwesengesetzes (KWG) einen flexiblen und praxisnahen Rahmen für die technisch-organisatorische Ausstattung der Institute – insbesondere für das Management der IT-Ressourcen und für das IT-Risikomanagement – vor.
  • IT-Governance
  • Informationsrisikomanagement
  • Benutzerberechtigungsmanagement
  • IT-Projekte, Anwendungsentwicklung (inkl. durch Endbenutzer in den Fachbereichen)

Über den Autor

Daniel Storch hat mehr als 13 Jahre Erfahrung bei der Beratung von Banken, Sparkassen und Spezialinstituten zu den Themen Aufsichtsrecht mit Schwerpunkt MaRisk und §44er Prüfungen, Gesamtbanksteuerung und Risikomanagement sowie Kreditprozesse und Interne Kontrollsysteme. Zuvor fungierte er als Risikocontroller in einer Sparkasse mit Schwerpunkt Adressrisikomanagement und operationelle Risiken.