Aufrufe
vor 3 Jahren

RISIKO MANAGER 02.2016

  • Text
  • Attribute
  • Forderungen
  • Risikogewicht
  • Risiko
  • Ratings
  • Baseler
  • Banken
  • Risikogewichte
  • Institute
  • Risikopositionen
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.

8

8 RISIKO MANAGER 02|2016 ren. Die Bereitstellung bisher nicht verfügbarer Attribute kann im Einzelfall mit erheblichem Aufwand verbunden sein. Zuordnung der Attribute Die Verwendung der vorgestellten Kategorien ist institutsunabhängig für jeden Meldepflichtigen hilfreich, wobei die Zuordnung der Attribute in die jeweiligen Kategorien von Haus zu Haus variieren wird. Daher können im Folgenden nur Tendenzaussagen basierend auf Erfahrungswerten getroffen werden. Tab. 04 stellt demzufolge nur eine initiale Einschätzung vor, wie sich die Attribute auf die drei Kategorien verteilen lassen. Insgesamt werden bereits 24 Attribute in der Reportinglandschaft von deutschen Instituten für regulatorische Meldungen genutzt. Weitere 50 Attribute, die für die AnaCredit-Meldung erforderlich sind, liegen üblicherweise in den Systemen der Institute vor. Dies ist jedoch im Einzelfall zu überprüfen. Schließlich sollte für 20 Attribute eine intensive Überprüfung erfolgen, ob diese systemseitig erfasst wurden oder aus anderen Dokumenten extrahiert werden können. Die Attribute der ersten Kategorie (Attribute geringen Aufwands) können als weitgehend unproblematisch betrachtet werden, da von ihrer passgerechten Verfügbarkeit aufgrund von bereits bestehenden Meldepflichten auszugehen ist. Von den 94 näher zu untersuchenden Attributen können insgesamt 24 Attribute der ersten Kategorie zugeordnet werden. Diese teilen sich in 20 Attribute ohne und vier Attribute mit vordefinierten Ausprägungen auf. Es handelt sich bei den Attributen im Wesentlichen um Daten aus den COREP-, FIN- REP- oder Asset Encumbrance-Meldungen oder dem bestehenden Kreditmeldewesen. Überwiegend handelt es sich bei den angesprochenen Attributen um die Kreditnehmerdaten, die im ersten Dataset erhoben werden. Hierzu gehören beispielsweise der Name und die Adresse des Kreditnehmers sowie die Rechtsform. Des Weiteren zählen zur dieser Kategorie Daten zur Rechnungslegung, die bereits meldefähig zur Verfügung stehen. Beispiele hierfür sind der aktuelle Buchwert des Geschäfts, die Angabe, ob es sich um einen notleidenden Kredit handelt oder die Angabe, für welche Transaktion das Instrument vom Institut gegebenenfalls als Sicherheit eingesetzt wird. Für die Attribute der zweiten Kategorie (Attribute mittleren Aufwands) stehen die geforderten Daten grundsätzlich zur Verfügung. Allerdings ist durch jedes Institut zu prüfen, inwieweit die verfügbaren Daten den Formatvorgaben entsprechen. 26 Attribute dieser Kategorie sind ohne vordefinierte Ausprägung, für die weiteren 24 Attribute sind Ausprägungen vorgegeben. Inhaltlich gehören die Attribute überwiegend dem zweiten Dataset an, bei dem allgemeine Vertragsinformationen zum Geschäft gefordert werden. Aus diesem Dataset werden 15 Attribute dieser Kategorie zugeordnet, darunter beispielsweise verschiedene Informationen zu der Zinsstruktur sowie dem Vertragsbeginn, Erfüllungstag oder dem Fälligkeitsdatum für das Geschäft. Weitere Attribute dieser Kategorie sind Teil des dritten Datasets, das die aktuellen Finanzdaten des Geschäfts beleuchten. Darunter fallen insgesamt elf Attribute, wie der aktuelle Ausfall-Status inklusive des Datums im Fall eines eingetretenen Ausfalls, die Zinsrate und die angesammelten Zinsforderungen. Für 20 Attribute (Attribute hohen Aufwands) muss untersucht werden, ob und in welcher Form die erforderlichen Daten verfügbar sind. So sind bei Dokumentationen, die bisher nur in Papierform erfolgten, prozessuale Lösungen zu erwägen, die eine standardisierte technische Anbindung vorsehen. Die betroffenen Attribute gehören unter anderem auch zu dem zweiten Dataset, wie der Geschäftsgrund, die Abschreibungsart und die Zahlungsfrequenz. Zudem handelt es sich hierbei um Informationen zu den für das Geschäft erhaltenen Sicherheiten des Instituts, beispielsweise die Angabe über die ausgewählte Methode für die Bewertung der erhaltenen Sicherheit. Weitere in dieser Kategorie befindliche Attribute sind die Angabe zur Größe des Kreditnehmers, welche auch Angaben zu der Anzahl der Mitarbeiter, der Bilanzsumme und zum Jahresumsatz berücksichtigt. Diese Daten sollten erfahrungsgemäß aus den Vertragsunterlagen oder Kreditentscheidungsvorlagen entnommen werden können. Sollten diese Daten bereits technisch erfasst worden sein, wird dies den Umsetzungsaufwand tendenziell reduzieren. Tab. 04 Aufwandsbasierte Kategorisierung der Attribute Lösungsskizze Kategorie Kategorie 1 (Bestandteil einer bestehenden Meldung) Kategorie 2 (Daten in Banksystem vorhanden, Format zu überprüfen) Kategorie 3 (Daten wahrscheinlich im Institut vorhanden, systemseitige Erfassung sowie Formate zu überprüfen) Attribute ohne vordefinierter Ausprägung Attribute mit vordefinierter Ausprägung Gesamt 20 4 24 26 24 50 10 10 20 Gesamt 56 38 94 Mittels der durchgeführten Analyse können die Attribute strukturiert und verschiedene Arbeitsfelder identifiziert werden. Dies wird eine spätere Implementierung auch dann noch deutlich erleichtern, wenn im Rahmen weiterer Untersuchungen Attribute im Einzelfall einer anderen Kategorie zugeordnet oder neue Attribute von der Aufsicht hinzugefügt werden. In einem nächsten Schritt sind Lösungsansätze zu den identifizierten Kategorien zu entwickeln. Dabei stehen Institute vor der Herausforderung kosteneffizient, aber

Kreditrisiko 9 auch nachhaltig vorzugehen. Es kann somit zielführend und gegebenenfalls langfristig günstiger sein, alte Strukturen und Prozesse vor dem Hintergrund der aktuellen Anforderungen kritisch zu hinterfragen. Im Zentrum muss die Beantwortung der Frage stehen, wie die Prozesse, die IT-Architektur, der Datenhaushalt und schließlich die gesamte Governance ausgerichtet sein müssen, um die identifizierten Problemfelder möglichst direkt und effizient adressieren zu können. Der wachsende Druck, Prozesse untereinander abzustimmen und gleichzeitig ein Höchstmaß an Flexibilität zu erhalten, lässt eine Implementierung von AnaCredit innerhalb von organisatorischen Silo-Strukturen nicht mehr sinnvoll erscheinen. Ein umfassender Reporting-Prozess für die AnaCredit-Meldung wird daher die althergebrachten Grenzen aufweichen und teilweise aufbrechen. Die künftige Struktur wird dazu auf die Daten und Kompetenzen aller betroffenen Organisationseinheiten zurückgreifen müssen. Hierzu gehört auch, dass bisher noch nicht durch die Kreditsachbearbeiter systemseitig aufgezeichnete Daten zukünftig technisch erfasst werden müssen. Es besteht somit bereits im Marktbereich Handlungsbedarf. Für eine künftige Organisationsstruktur in den Instituten ist daher die permanente Anpassungsfähigkeit und hohe Anpassungsgeschwindigkeit bereits bei ihrer Einrichtung vorzusehen. Diese neuen Kompetenzen stellen neben dem Fachwissen einen immer wichtiger werdenden Faktor dar. Der Aufwand für die Umsetzung kann für die Attribute aus der vorgenommenen Kategorisierung abgeleitet werden. Um ein Umsetzungsprojekt zu planen, bildet die Kategorisierung eine erste Grundlage für das Vorgehen, um kritische Themen möglichst frühzeitig in den Instituten identifizieren und adressieren zu können. Für das Umsetzungsprojekt sind die Attribute daher zeitnah nach Verantwortlichkeiten zu strukturieren, sodass die zu involvierenden Bereiche von Beginn an bei der Umsetzung aktiv eingebunden werden. Attribute der ersten Kategorie werden bereits in einer meist aggregierten Form an die Aufsicht gemeldet. Es bedarf grundsätzlich keiner Konzeption von neuen Schnittstellen aus Vorsystemen, da die Meldewerte aus Einzelgeschäftsdaten aggregiert und bestehende Schnittstellen benutzt werden können. Sollten Anpassungen im Rahmen anderer Meldepflichten entstehen, wären die Anpassungen bei AnaCredit analog durchzuführen. Möglicher Aufwand für die Implementierung der Attribute dieser Kategorie entsteht durch anstehende Tests und gegebenenfalls einer Prüfung, ob die Schnittstellen bereits in der benötigten Frequenz (einige Daten müssen für die AnaCredit-Meldung monatlich zur Verfügung stehen) und Granularität die Informationen liefern. Ein zusätzlicher Aufwand entsteht bei den Attributen der zweiten Kategorie. Hier liegen die Informationen in den verschiedenen Vorsystemen des Instituts vor. Es muss jedoch gegebenenfalls eine Schnittstelle zur Anlieferung an das für AnaCredit vorgesehene Reportingsystem definiert werden. Zusätzlich sind hier die vordefinierten Ausprägungen zu beachten. Es entstehen erhöhte Projektaufwände bei der Identifikation der jeweiligen Daten in den Systemen sowie bei der Konstruktion passender Schnittstellen. Da erfahrungsgemäß die Schnittstellenkonstruktion und das verbundene Testen aufwandsintensiv sind sowie verschiedene Bereiche eines Instituts einzubeziehen sind, ist ein frühzeitiges Adressieren der Anforderungen angeraten. Der höchste Aufwand kann in Zusammenhang mit Attributen der dritten Kategorie erwartet werden. Im Regelfall werden die geforderten Daten für die Meldung der Attribute nicht in den Zielsystemen der Institute vorliegen. Die Herausforderung für Projekte bestehen hierbei zunächst in Abb. 01 Handlungsbedarf je Kategorie Prozesse Daten Kategorie 1 Beurteilung der IT-Architektur Governance Kategorie 3 Kategorie 2 • Überprüfung der IT-Architektur hinsichtlich der Verfügbarkeit granularer Daten • Implementation von neuen Schnittstellen für Anbindung der Daten an das Reportingsystem • Vermehrte Einbindung von Fachbereichen für korrekte Ausführung der Anforderungen • Erstellen von fachlichen Mappings für Attribute mit vordefinierten Ausprägungen • Ermittlungsfrequenz gemäß AnaCredit-Meldefrequenz überprüfen • Durchführen von Tests der Schnittstellen und Meldeerstellung • Prüfen von neuen Validierungsschritten zu anderen aufsichtlichen Meldungen • Identifikation der geforderten Attribute in bestehender Dokumentation • Überprüfung und Erweiterung der IT-Architektur für Datenerfassung • Ermittlungs-, Erfassungs- und weitere Verarbeitungsprozesse anpassen oder neu implementieren • Einbinden von Fachbereichen sowohl im Back- als auch im Front-Office zusätzlicher Handlungsbedarf

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.