Aufrufe
vor 11 Monaten

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 2 | Konzern

REGULIERUNG 2 | Konzern Anforderungen der Dt. Bundesbank sind nicht in der gesamten Gruppe umzusetzen AnaCredit AnaCredit AnaCredit Unklarheit bzgl. Systemverantwortung und -erweiterung Anpassungen in den Frontoffice-Systemen der IT bekannt waren, begann die technische Entwicklung der Felder, die Anpassung der Lieferstrecke und die Anbindung der Felder in die Schnittstelle für die AnaCredit-Meldung. Da sich die fachlichen Anforderungen auch nach Beginn der Umsetzung noch ändern können, stellen diese Testverfahren eine besondere Herausforderung dar. In solchen Fällen ist eine enge Abstimmung notwendig, damit die IT kurzfristig reagieren und Anforderungen trotz veränderter Vorgaben umsetzen kann. Zusätzlich muss die Dokumentation in allen Bereichen angepasst werden, damit keine Informationen verloren gehen. Neben unterschiedlichen IT-Abteilungen (verantwortlich für Systeme, Lieferstrecken und technische Umsetzung der Mappingvorgaben) waren auch diverse Fachabteilungen für den Test zuständig. Da Mitarbeiter aus dem Meldewesen nur selten Zugriff auf die Systeme im Frontoffice haben, musste eine höhere Projektebene sicherstellen, dass das neu geschaffene Feld den konkreten AnaCredit-Anforderungen entsprach und von der jeweiligen Fachabteilung getestet und abgenommen wurde. Lieferstrecken ins Data Warehouse definieren Bei den Anpassungen der Lieferstrecke stellt sich gerade in großen Instituten die Frage, über welchen Weg die Information ins Data Warehouse transferiert werden soll. Lieferstrecken, die nur von einigen Abteilungen für ganz bestimmte Zwecke genutzt werden, las- sen sich nämlich nicht einfach für AnaCredit erweitern. Nur eine ausreichend transparente Kommunikation zwischen allen Abteilungen kann über diese Hürden hinweghelfen, damit alle relevanten Informationen erfolgreich ins Data Warehouse gelangen. Auch bei der Umsetzung und beim Test der Mappings für die Meldewesen-Software spielt die Flexibilität der IT eine große Rolle. Änderungen der regulatorischen Anforderungen wirken sich direkt auf die Software aus, die vom Bereich Meldewesen mit Daten und Mappings beliefert wird. Selbst wenn mehrere kleine Releases für die AnaCredit-Umsetzung geplant sind, lässt sich nicht gänzlich verhindern, dass Software-Änderungen zu neuen Meldungsanforderungen führen. Dies bedeutet eine immense Herausforderung an das Testverfahren und erfordert von allen Mitwirkenden größte Flexibilität. Einbindung in das konzernweite Projekt Die Notwendigkeit zur Erweiterung und Anpassung bestimmter Front-Office-Systeme, für die die Konzernmutter verantwortlich ist, erfordert eine enge Abstimmung innerhalb des Konzerns. ÿ 3 illustriert das Spannungsfeld der Abstimmungsanforderungen bei der Umsetzung von AnaCredit. Neben den bereits genannten Herausforderungen führte die Einbindung in die Konzernstruktur zu den größten Schwierigkeiten. Aufgrund fehlender Erfahrung war dies zu Projektbeginn nicht absehbar gewesen. Zwar war bekannt, dass die Meldefristen für die AnaCredit-Attribute in Deutschland strenger sind als im Heimatland des Konzerns, doch die unmittelbaren Konsequenzen zeigten sich erst im Verlauf des Projekts. Die für die Konzernmutter zuständige Zentralbank richtet sich nach den Vorgaben der EZB, die verlangen, bis zum 31. März 2018 erste Vertragspartner- Stammdaten zu versenden. Im Gegensatz dazu fordert die Deutsche Bundesbank schon zum 31. Januar 2018 erste Daten zu den Vertragspartnern. Trotzdem wurde im Konzern Wert auf die Nutzung von Synergien gelegt. Einmal vorgenommene Erweiterungen in zentralen Systemen konnten und sollten von allen betroffenen Töchtern genutzt werden. Dabei musste innerhalb des Konzerns darauf geachtet werden, dass alle Beteiligten auf die gleichen Felder zurückgriffen, da AnaCredit im Kern eine harmonisierte Meldung innerhalb des Euroraums darstellt. Granularität der Daten Es ist davon auszugehen, dass die Zentralbank auf die konsistente Umsetzung im Konzern achten und diese früher oder später auch überprüfen wird. Schließlich werden die Deutsche Bundesbank und die EZB durch die Granularität der AnaCredit-Daten erstmals in der Lage sein, sämtliche Auswertungen selbst vorzunehmen und somit auch jeden Datensatz einzeln begutachten können. Die Prüfung kann durch simple Plausibilisierungsregeln vorgenommen werden. Dies spielt gerade bei der Umsetzung der Attribute zu Vertragspartner-Stammdaten eine zentrale Rolle. 48 05 // 2018

REGULIERUNG 3 | Enge Abstimmung innerhalb des Konzerns NEIN € Attribut im Vorsystem NEIN JA Anforderungen Systemowner Systemerweiterung Anpassung Lieferstrecke Umsetzung und Test Auslieferung Vorsystem und Lieferstrecke Analyse des Attributs Attribut im DWH JA Fachliches Mapping Umsetzung und Test Fachtest Auslieferung Meldung Bundesbank Darüber hinaus sind bei konzernweiten Projekten Überschneidungen und Abhängigkeiten zu beachten, bei denen beispielsweise aus mehreren parallel laufenden Kontextprojekten auf zentrale Ressourcen zurückgegriffen wird. Diese Konflikte können nur durch enge Abstimmung in der Projektsteuerung und die gemeinsame Priorisierung von Aktivitäten gelöst werden. Des Weiteren erfährt die Abfrage auf Einzeldatensatzebene über alle Banksysteme hinweg mit AnaCredit eine ganz neue Dimension. Gerade in schnell gewachsenen Unternehmen sind Datenstrukturen unter Umständen intransparent, sodass für Dritte nicht unmittelbar ersichtlich ist, welche Abteilungen welche Systeme für welche Portfolios nutzen. Aus AnaCredit erwächst somit nicht nur die Herausforderung, relevante Systeme und Datenstränge zu identifizieren, sondern auch die korrekten, für die Erweiterung zuständigen Ansprechpartner zu finden. Datenqualitätsmanagement ist Pflicht Damit eine hohe Datenqualität erreicht wird, muss die Datenbasis absolut verlässlich sein. Zeit für manuelle Korrekturen bleibt bei der Aufbereitung der Meldung kaum. Deshalb muss die Datenqualität stets überwacht werden. Die Prüfung beginnt schon im Frontend – und zwar unbedingt schriftlich und über das Vier-Augen- Prinzip. Es empfiehlt sich, alle Datenpunkte der AnaCredit-Attribute regelmäßig durch ein automatisiertes Reporting zu überprüfen. Ob man die Reports für die Frontoffice- Systeme aufsetzt oder erst im Meldewesen abfragt, hängt von der Organisation der Bank ab. Für den hier betrachteten Kunden hat sich eine Mischform als beste Vorgehensweise etabliert. So konnte ein Großteil der Stammdaten bereits in den Frontoffice-Systemen im Hinblick auf Vollständigkeit und weitere Plausibilitäten geprüft werden. Die nach Risikopositionen gewichtete Ausfallwahrscheinlichkeit (die sogenannte Exposure-gewichtete PD) ließ sich dagegen erst im Rahmen der Meldung plausibilisieren, da sie systemseitig meist erst dort berechnet wird. FAZIT 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 Frontoffice-Systemen bestehen, ist das Data Warehouse auch auf die zukünftigen Meldewesen-Themen gut vorbereitet. Autoren Janine Radeck ist Senior Consultant für Bankenregulierung. Nach dem Studium der Mathematik an der Fachhochschule Regensburg verschlug es Sie in den Norden. Sie ist für die PPI AG in unterschiedlichsten Regulierungsprojekten tätig. Andreas Bruckner ist Managing Consultant im Bereich Risikomanagement der PPI AG. Er berät er Banken und Finanzdienstleister rund um regulatorische Fragestellungen aus den MaRisk, Basel III oder der CRR und deren Umsetzung in agilen Projekten. 05 // 2018 49

die bank

die bank 01 // 2019
die bank 02 // 2019
die bank 03 // 2019
die bank 04 // 2019
die bank 05 // 2019
KINOTE 01.2019
die bank 06 // 2019
diebank 07 // 2019
diebank 08 // 2019
die bank 01 // 2018
die bank 02 // 2018
die bank 03 // 2018
die bank 04 // 2018
die bank 05 // 2018
die bank 06 // 2018
die bank 07 // 2018
die bank 08 // 2018
die bank 09 // 2018
die bank 10 // 2018
die bank 01 // 2017
die bank 02 // 2017
die bank 03 // 2017
die Bank 04 // 2017
die bank 05 // 2017
die bank 06 // 2017
die bank 07 // 2017
die bank 08 // 2017
die Bank 09 // 2017
die bank 10 // 2017
die bank 01 // 2016
die bank 02 // 2016
die bank 03 // 2016
die bank 04 // 2016
die bank 05 // 2016
die bank 06 // 2016
die bank 07 // 2016
die bank 08 // 2016
die bank 09 // 2016
die bank 10 // 2016
die bank 11 // 2016
die bank 12 // 2016
die bank 01 // 2015
die bank 02 // 2015
die bank 03 // 2015
die bank 04 // 2015
die bank 05 // 2015
die bank 06 // 2015
die bank 07 // 2015
die bank 08 // 2015
die bank 09 // 2015
die bank 10 // 2015
die bank 11 // 2015
die bank 12 // 2015

© die bank 2014-2018