Aufrufe
vor 5 Jahren

die bank 05 // 2018

die bank gehört zu den bedeutendsten Publikationen der gesamten Kreditwirtschaft. Die Autoren sind ausnahmslos Experten von hohem Rang. Das Themenspektrum ist weit gefächert und umfasst fachlich fundierte Informationen. Seit 1961 ist die bank die meinungsbildende Fachzeitschrift für Entscheider in privaten Banken, Sparkassen und kreditgenossenschaftlichen Instituten. Mit Themen aus den Bereichen Bankmanagement, Regulatorik, Risikomanagement, Compliance, Zahlungsverkehr, Bankorganisation & Prozessoptimierung und Digitalisierung & Finanzinnovationen vermittelt die bank ihren Lesern Strategien, Technologien, Trends und Managementideen der gesamten Kreditwirtschaft.

REGULIERUNG UMSETZUNG

REGULIERUNG UMSETZUNG VON ANACREDIT Eine Chance für saubere Datenmanagementprozesse Ab September 2018 gilt die vollumfängliche Meldepflicht im Rahmen von AnaCredit. Doch bisher war das Projekt von Unsicherheiten geprägt. Gerade in der Anfangsphase mangelte es an Definitionen und Auslegungen. Welche Hürden Geldhäuser bei der Umsetzung von AnaCredit im Einzelnen bewältigen müssen, wird in diesem Beitrag am Beispiel einer Direktbank erläutert. Als die Europäische Zentralbank (EZB) im Mai 2016 Europas Banken das Kreditmeldewesen „Analytical Credit Dataset“ (kurz: AnaCredit) verordnete, gaben sich viele Institute noch der Hoffnung hin, dies sei mit einer neuen Zusammenstellung und Meldung bereits vorhandener Daten zu regeln. Diese Zuversicht schwand schnell und es setzte sich die Erkenntnis durch, dass die Umsetzung von AnaCredit vielmehr tiefgreifende Auswirkungen haben würde. Sie reichen hinsichtlich der eingesetzten Meldewesen-Software von der Prozessanpassung in den Front-Office-Systemen, über die erweiterte Datenaufbereitung und Datensammlung im Risikomanagement bis hin zur geänderten Anlieferung und Transformation im Data Warehouse. Zugleich birgt AnaCredit gerade in Großbanken die Chance zur Analyse und Bereinigung des bestehenden Datenhaushalts sowie zum Aufbau einer sauberen Datenbasis. Und davon können sämtliche Bereiche einer Bank profitieren. gabe müssen alle Datenfelder bis zum 30. September 2018 vollständig und korrekt gemeldet werden. Dessen ungeachtet bleiben bis heute viele Fragen an die Deutsche Bundesbank offen: So lautete die Statusmeldung für 215 von 824 FAQs (26,1 Prozent) an die Deutsche Bundesbank noch im September 2017 „in Bearbeitung“ oder „an EZB adressiert“. ÿ 1 Da eine starre Projektplanung für derartige Volatilitäten nicht geeignet ist, hat sich die hier betrachtete Direktbank für ein klassisches Projektvorgehen mit agilen Elementen entschieden. Agile Methoden helfen bei unklaren Vorgaben Einerseits erfolgte eine klassische Aufteilung in fachliche Analyse und Fachkonzeption innerhalb des Meldewesens unter Einbeziehung aller relevanten Abteilungen sowie der Bereiche Entwicklung und Test. Andererseits wurde der hohen Komplexität sowie der relativen Unsicherheit hinsichtlich der konkreten Inhalte einzelner Attribute durch Agilität entgegengewirkt: Mehrere kleine IT-Releases wurden in kurzen Zeitabständen für AnaCredit konzeptioniert. Bei der fachlichen Analyse galt es außerdem, stets auf die ausreichende Einbeziehung von Frontoffice und Risikomanagement zu achten, um Fehlinterpretationen der AnaCredit-Felddefinitionen zu vermeiden. Die Konzeptionierung der IT-Releases orientierte sich dabei an den Meldeterminen der Deutschen Bundesbank (14 Attribute für den Meldetermin 31. Januar 2018, 12 Attribute für den 31. März und 60 Attribute für den 30. Sep- Die Zeit wird knapp Viel Zeit bleibt den Instituten nicht mehr. Ab Ende September 2018 gilt die vollumfängliche Meldepflicht. Doch bisher war das Projekt von Unsicherheiten geprägt. Besonders in der Anfangsphase von AnaCredit fehlten vollständige Definitionen und Auslegungen für einzelne Attribute von Seiten der Deutschen Bundesbank, daher unterlagen die fachlichen Anforderungen einem ständigen Wandel. Trotzdem mussten die Banken mit der Projektplanung und Umsetzung beginnen, denn laut Zielvortember). Dabei war jedoch absehbar, dass das letzte Release thematisch überladen sein würde. Die Bank entschloss sich daher, das Thema Sicherheiten einem früheren Release zuzuordnen. Darüber hinaus war es mit der bloßen Umsetzung der Attribute nicht getan, denn im Rahmen der Datenqualitätsprüfungen oder der ersten Bundesbank-Testphasen können sich durchaus noch zusätzliche Themen für eine IT- Umsetzung abzeichnen. Somit sollten für Ana- Credit idealerweise vier bis fünf separate Releases eingeplant werden. Agiles Arbeiten verbunden mit vielen kurzen Releases ermöglicht gleichzeitig schnelle Reaktionszeiten seitens der Fachabteilung und der IT. Weil die Anforderungen in kleinere Prozessschritte zerlegt werden, kann laufend nachgesteuert werden. Da sich die Direktbank im vorliegenden Fall dazu entschied, die Umsetzung der für AnaCredit relevanten Themen auf mehrere Releases zu verteilen, arbeiteten Fachbereiche und IT bei der Ausarbeitung der Attribute, beim fachlichen Mapping sowie in der Entwicklungs- und Testphase eng zusammen. Gerade AnaCredit hat gezeigt, dass es unabdingbar ist, die IT bereits in der Konzeptionsphase mit einzubinden, um Fehleinschätzungen zu vermeiden. Im hier analysierten Fall war bei der Projektplanung außerdem auf erforderliche Abstimmungen mit der Muttergesellschaft im EU-Ausland zu achten. In Anbetracht der späteren Datenzusammenführung bei der EZB ist dies ein nicht zu unterschätzender Aspekt, da die Daten am Ende institutsübergreifend konsistent sein müssen. 46 05 // 2018

REGULIERUNG 1 | Q&A der Deutschen Bundesbank 7 223 386 102 106 Meldeprozesse Meldeinhalte in Bearbeitung bearbeitet an EZB adressiert Stand: September 2017. Die Kommunikation mit der Muttergesellschaft wurde dabei nicht nur durch Sprachprobleme, sondern auch voneinander abweichende Meldefristen erschwert. Auch die Tatsache, dass einige von der Muttergesellschaft verwaltete Daten über Frontoffice-Systeme in die Meldewesen-Software transferiert werden mussten, wirkte sich nachteilig aus. Schrittweise Analyse der einzelnen AnaCredit-Attribute Ausgehend vom gewählten agilen Vorgehensmodell erfolgt die Umsetzung und Analyse der einzelnen Attribute Schritt für Schritt. Jedes Attribut muss fachlich umfassend beleuchtet und genau geprüft werden, inwiefern es bereits in anderen Meldungen vorhanden ist. Dabei erschien es sinnvoll, Attribute gemäß den vorgegebenen AnaCredit-Tabellen zu gliedern und entsprechend der Meldetermine zu priorisieren, sodass mehrere Attribute gleichzeitig im Rahmen eines Workshops bearbeitet werden konnten. Bei der Zusammensetzung der Workshops ist es sinnvoll, darauf zu achten, dass zuständige Mitarbeiter aller Fachabteilungen involviert sind. Darüber hinaus empfiehlt es sich, dass Mitarbeiter aus dem Meldewesen an den Workshops teilnehmen. Denn nur sie können beurteilen, ob ein AnaCredit-Attribut bereits in anderen Meldungen verwendet wird, und nur sie können die geforderte Konsistenz der Daten sicherstellen. Ist erst einmal der genaue Inhalt eines Attributs definiert, so muss in einem zweiten Schritt geprüft werden, in welchen Systemen das Attribut schon vorhanden bzw. ob es neu zu implementieren ist. Sind geforderte AnaCredit-Attribute bereits vorhanden, etwa weil sie schon für andere Meldungen gebraucht werden, ist lediglich eine weitere Berücksichtigung in der Meldewesen-Software notwendig. Die Anforderungen an eine technische Anbindung sind in diesem Fall eher gering und relativ einfach umzusetzen. Bei der fachlichen Definition des Mappings sollte aber darauf geachtet werden, dass AnaCredit eine andere Darstellung des Attributs erfordert. Ein Beispiel dafür ist die Ausfallwahrscheinlichkeit Probability of Default (PD). Diese muss Exposure-gewichtet, also nach Risikopositionen sortiert dargestellt werden, falls sie auf Instrumentenebene vorliegt, und somit im Mapping angepasst werden. Implementierung neuer Attribute im Frontoffice-System In anderen Fällen sind Attribute noch nicht im Frontoffice und damit auch nicht im Data Warehouse vorhanden. Bei diesen Attributen muss zunächst geprüft werden, in welchem Frontoffice-System die Informationen abgelegt werden müssen und wer für dessen Erweiterung zuständig ist. Bei einer Großbank werden die Anforderungen an das Frontoffice-System häufig durch die Konzernmutter festgelegt und umgesetzt. Fehlende Attribute stellen daher eine enorme Herausforderung dar: Unterschiedliche ITund Fachabteilungen müssen kommunizieren, damit das Attribut eingetragen, über eine Lieferstrecke ins Data Warehouse geladen und im Meldewesen über ein definiertes Mapping in der Meldewesen-Software als gefordertes Ana- Credit-Attribut abgebildet werden kann. Zudem passen die Anforderungen der Tochtergesellschaft nicht zwingend zu den Release-Zyklen des Mutterkonzerns. Dieser Umstand führt zu zeitlichen und kapazitären Engpässen, da die Anforderungen an die wichtigsten Frontoffice-Systeme nicht entsprechend dem Projektplan der Tochtergesellschaft aufgenommen und umgesetzt werden konnten. Dies ist vor allem darauf zurückzuführen, dass Banken im Land der Muttergesellschaft anderen Meldefristen unterliegen als deutsche Geldinstitute. Die Vorgaben der Deutschen Bundesbank für Institute hierzulande wichen mitunter von den EZB-Vorgaben ab. ÿ 2 veranschaulicht die einzelnen Prozessschritte. Im Beispielfall zeigte sich nach einer ersten Workshop-Reihe, dass rund 40 Prozent der geforderten AnaCredit-Attribute schon im Meldewesen vorhanden waren bzw. für andere Meldungen genutzt wurden. Weitere 30 Prozent wurden bereits an anderer Stelle im Unternehmen verwendet (z. B. für die Risikoparameterschätzung) und konnten durch eine Anpassung der Lieferstrecke und des Mappings im Meldewesen angebunden werden. Die verbleibenden 30 Prozent stellten die größte Herausforderung dar, da für diese Attribute zusätzliche Felder in den Frontoffice-Systemen geschaffen und neue Regeln definiert werden mussten. Umsetzung und Test im AnaCredit- Umfeld Sobald im Rahmen der einzelnen Workshops die Attribute für ein Release definiert und die 05 // 2018 47

die bank