Ein paar Daten von der IT neu sortieren lassen, fertig ist die AnaCredit-Meldung? Dass es so einfach nicht ist, haben Europas Banken mittlerweile erkannt. Die Umsetzung der europäischen Verordnung ist komplex. Die Banken kommen dabei um den Einsatz agiler Methoden kaum herum.
AnaCredit ist das neue Kreditmeldewesen „Analytical Credit Dataset“, das die Europäische Zentralbank den europäischen Banken auferlegt hat.
Partner des Bank Blogs
AnaCredit ist ein Kraftakt. Denn das Kreditmeldewesen „Analytical Credit Dataset“, das die Europäische Zentralbank (EZB) Banken und Finanzdienstleistern im Mai 2016 verordnet hat, erfordert weit mehr, als eine neue Zusammenstellung und Meldung bereits vorhandener Daten. Die stille Hoffnung der Kreditinstitute, sie würden mit leichten Anpassungen ihrer IT davonkommen, haben sich mittlerweile in Luft aufgelöst.
Die Umsetzung von AnaCredit hat tiefgreifende Auswirkungen. 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.
Unsicherheiten über Vorgaben
Dabei herrschte lange Zeit Unklarheit über Details, längst nicht alle Anforderungen an die Kreditinstitute waren ausbuchstabiert. 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 Zielvorgabe müssen alle Datenfelder bis zum 30. September 2018 vollständig und korrekt gemeldet werden. Abgefragt werden 89 Attribute und sechs Identifikatoren.
An Agilität führt kein Weg vorbei
Auch vor diesem Hintergrund kommen die Institute um agiles Arbeiten nicht herum. Eine starre Projektplanung ist für derartige Volatilität schlicht nicht geeignet. Mindestens agile Elemente müssen in das Vorgehen einbezogen werden, um frühzeitig erste Schritte bei der Umsetzung von AnaCredit voranzukommen. Durch Agilität kann der hohen Komplexität sowie der relativen Unsicherheit hinsichtlich der konkreten Inhalte einzelner Attribute entgegengewirkt werden: Die Konzeption sieht dann mehrere kleine IT-Releases in kurzen Zeitabständen vor. Bei der fachlichen Analyse gilt es außerdem, stets Front Office und Risikomanagement einzubeziehen. Nur so können Fehlinterpretationen der AnaCredit-Felddefinitionen vermieden werden.
Agiles Arbeiten und viele kurze Releases bedeuten gleichzeitig schnelle Reaktionszeiten seitens der Fachabteilung und der IT. Weil die Anforderungen in kleinere Prozessschritte zerlegt werden, kann jederzeit nachgesteuert werden. Zu jeder Zeit wird der Fortschritt überprüft und gegebenenfalls die folgende Projektphase angepasst oder neu ausgerichtet.
Neue Anforderungen im Laufe des Projekts
Doch auch mit der bloßen Umsetzung der Attribute ist es nicht getan. Im Rahmen der Datenqualitätsprüfungen oder der ersten Bundesbank-Testphasen zeichnen sich meist noch zusätzliche Themen für eine IT-Umsetzung ab. Auch hier bieten agile Methoden angemessene Antworten. Für AnaCredit sollten somit idealerweise vier bis fünf separate Releases eingeplant werden, um eine vollständige und qualitätsgesicherte AnaCredit-Meldung zu garantieren.
Viele Beteiligte bei der Abarbeitung der Attribute
Bei dem Projekt ist eine enge Abstimmung und Zusammenarbeit der Fachbereiche und der IT bei der Ausarbeitung der Attribute, beim fachlichen Mapping sowie in der Entwicklungs- und Testphase unbedingt erforderlich. Gerade AnaCredit zeigt, dass es unabdingbar ist, die IT bereits in der Konzeptionsphase mit einzubinden, um Fehleinschätzungen zu vermeiden.
Im Projekt muss jedes Attribut fachlich umfassend beleuchtet und genau geprüft werden, inwiefern es bereits in anderen Meldungen vorhanden ist. Ausgehend vom gewählten agilen Vorgehensmodell erfolgt die Umsetzung und Analyse der einzelnen Attribute Schritt für Schritt. Für jedes Attribut wird geprüft, ob und in welchen Systemen es schon vorhanden ist oder ob es neu implementiert werden muss. Involviert sind auch hier unterschiedliche IT-Abteilungen, die für System, Lieferstrecken sowie technische Umsetzung der Mappingvorgaben verantwortlich sind, sowie diverse Fachabteilungen.
Einbindung in das konzernweite Projekt
Dazu treffen sich die zuständigen Mitarbeiter aller Fachabteilungen zunächst in einem Workshop. Dies stellt insbesondere für Großbanken eine Herausforderung dar. Dort sind zwar zahlreiche Mitarbeiter für ein Thema zuständig, ihre Zuständigkeit erstreckt sich aber nur auf ein bestimmtes Portfolio in einem bestimmten System. Mitarbeiter aus dem Meldewesen dürfen auf gar keinen Fall fehlen. Denn nur sie können beurteilen, ob ein AnaCredit-Attribut bereits in anderen Meldungen verwendet wird und die geforderte Konsistenz der Daten sicherstellen. Andererseits hat das Meldewesen nur selten Zugriff auf die Systeme im Front Office. Eine höhere Projektebene muss dann sicherstellen, dass das neu geschaffene Feld den konkreten AnaCredit-Anforderungen entspricht und von der jeweiligen Fachabteilung abgesegnet wird.
Europäische Mutter-Tochter-Beziehung erhöht die Komplexität
Eine zusätzliche Hürde tritt auf, wenn für die Konzernmutter andere Anforderungen gelten als für die Tochtergesellschaft. Dieses Problem betrifft etwa Großbanken, deren Tochtergesellschaft im deutschen Meldewesen anderen Release-Zyklen unterliegt als der Mutterkonzern im europäischen Ausland. Denn mitunter weichen die Vorgaben der Deutschen Bundesbank von denen der EZB ab. In Anbetracht der späteren Datenzusammenführung bei der EZB ist der Abgleich aber unerlässlich, da die Daten am Ende institutsübergreifend konsistent sein müssen. Die erforderlichen Abstimmungen innerhalb des Konzerns erhöhen die Komplexität des AnaCredit-Projekts weiter.
Fazit: Kommunikation ist das A und O
Die Darstellung von granularen Daten auf Instrumentenebene ist ein zentrales Thema von AnaCredit und stellt hinsichtlich der Datenqualität die größte Herausforderung dar. Während des Projektverlaufs muss sichergestellt werden, dass alle Entitäten eines Konzerns auf dieselben Daten zurückgreifen, auch wenn sie gemäß AnaCredit einer unterschiedlichen Meldepflicht unterliegen. Als bereichsübergreifendes Projekt erfordert AnaCredit ein hohes Maß an Kommunikation.
Banken sollten AnaCredit als Chance zur Implementierung sauberer Datenmanagementprozesse begreifen. Dazu gehört nicht nur, den bestehenden Datenhaushalt aufzuräumen, sondern auch, bereichsübergreifend einheitliche und somit wiederverwendbare Datenfeldkataloge zu etablieren. Wenn darüber hinaus flankierende Prozesse zur Datenqualitätsprüfung und -sicherung sowie möglicherweise zur Neuerfassung in den Front-Office-Systemen bestehen, ist das Data Warehouse auch auf die zukünftigen Meldewesen-Themen (Stichwort: BIRD) gut vorbereitet.
Eine saubere Datenbasis hilft auch an anderer Stelle, eine Antwort auf die Herausforderungen der Zukunft geben zu können. Konsistente Daten von hoher Qualität sind die Grundlage für zahlreiche Schritte in Richtung digitale Transformation, etwa für den Einsatz der Roboter-Technologie Robotic Process Automation (RPA) sowie die erfolgreiche Implementierung von Big-Data-Lösungen.
Andreas Bruckner
Andreas Bruckner ist Managing Consultant im Bereich Banking Risikomanagement der PPI AG und Co-Autor des Beitrags. Seit 2010 berät er Banken und Finanzdienstleister rund um regulatorische Fragestellungen aus den MaRisk, Basel III oder der CRR. In aktuellen Projekten beschäftigt er sich mit der Herausforderung, regulatorische Anforderungen in agilen Projekten für Banken effizient umzusetzen.
