6
6 RISIKO MANAGER 02|2016 exakte Abstimmung zusätzlich erschwert. Ferner ist der Aspekt der zeitnahen Verfügbarkeit bezüglich einer erfolgreichen Validierung zu beachten. Schließlich dürften Abstimmungen zwischen Meldungen auf loan-to-loan Basis zu aggregierten Meldungen weitere technische Herausforderungen darstellen. Die Datenqualität wird von Institut zu Institut eine unterschiedlich große Herausforderung darstellen. Mit der Notwendigkeit, zahlreiche, zum Teil verschieden strukturierte Datenquellen nutzen zu müssen, sind die Anforderungen an die Datenqualität besonders hoch. Hier werden Schwächen von der Ersterfassung über die Weiterverarbeitung bis hin zu der Datenverwertung im Zentrum einer dezidierten Überprüfung stehen müssen. Prozessuale Anpassungen, Schulungen der betroffenen Bereiche, Nacherfassungen und technische Umgestaltungen werden im Einzelfall nicht auszuschließen sein. Wie anfangs beschrieben, soll hier im Folgenden der Fokus auf der Datenbeschaffung und der Datenverarbeitung liegen. Analyse der Datenanforderungen Eine Analyse der von der EZB am 4. Dezember 2015 veröffentlichten Liste der Attribute zeigt, dass zahlreiche der angefragten Daten bereits Gegenstand von aufsichtlichen Meldungen sind [vgl. Europäische Zentralbank, 2015b]. Diese sind dort entweder in aggregierter Form verfügbar, zum Beispiel im Rahmen der COREP-, FINREPoder der Asset-Encumbrance-Meldung [vgl. Europäische Kommission, 2015], oder auf Kreditnehmerebene, wie in den Groß- und Millionenkreditmeldungen. Da die geforderten Daten meist aus den Einzelgeschäftsdaten aggregiert werden, liegen sie erfahrungsgemäß in der für AnaCredit geforderten Granularität in den Systemen der Institute vor. Des Weiteren werden relevante Daten für interne Bewertungsrechnungen oder das Risikomanagement in den entsprechenden Systemen ermittelt und vorgehalten. Schließlich sind bestimmte Daten in eingeschränktem Umfang aufgrund von gesetzlichen Dokumentationspflichten (z. B. Kreditunterlagen nach KWG) vorhanden. Bei diesen ist im Einzelfall zu prüfen, ob diese vollständig, zeitnah und im geforderten Format systemseitig erfasst werden, damit sie für die AnaCredit-Meldung genutzt werden können. Für eine detaillierte Analyse werden im Folgenden die Attribute unter Zuhilfenahme verschiedener für eine Umsetzung relevanter Kriterien untergliedert. Zunächst ist es zur Erlangung eines Überblicks hilfreich, die verschiedenen Arten von Attributen zu erläutern. Anschließend werden die Attribute nach dem Kriterium der bestehenden Verfügbarkeit in drei Kategorien eingeteilt. In Abhängigkeit dieser Kategorien lässt sich sowohl der Umfang als auch die Art des Umsetzungsaufwands ableiten, und es ergibt sich eine erste Indikation zur Planung der anstehenden AnaCredit-Projekte. Insgesamt gibt der Katalog der EZB 101 Attribute vor, die sich auf zwei Templates mit zehn Datasets verteilen. Davon sind sieben Attribute Identifikationsattribute („Identifier“) für den Meldepflichtigen, die meldende Einheit, Kreditnehmer, Geschäft oder erhaltene Sicherheiten, die über die verschiedenen Datasets wiederholend abgefragt werden ( Tab. 01). Der aktuelle AnaCredit-Entwurf der EZB beinhaltet ausschließlich detailliertere Angaben zu der ersten Phase der AnaCredit-Initiative. Die vorliegenden Attribute sind nur auf Einzelinstitutsebene zu melden. Eine Meldung von Daten auf konsolidierter Ebene ist zunächst nicht vorgesehen. Die EZB unterscheidet bei dem Kreditgeber zwischen dem Meldepflichtigen („Reporting Agent“) und der meldenden Einheit („Oberserved Agent“). Erstgenannter ist das jeweils meldepflichtige Institut mit Sitz im Euro-Raum beziehungsweise die im Euro-Raum ansässige Niederlassung eines Instituts, das selbst nicht im Euro-Raum sitzt. Der „Observed Agent“ ist hingegen die Einheit, die das Geschäft meldet. Demnach kann es sich also bei dem „Observed Agent“ um den „Reporting Agent“ selbst oder um eine Auslandsniederlassung innerhalb oder außerhalb des Euro-Raums handeln. In der AnaCredit-Meldung sind „Reporting Agent“ und „Observed Agent“ über eindeutige Identifikationsnummern zu kennzeichnen. Als primäre Identifikation für die Kreditnehmer wird von der EZB der LEI-Code („Legal Entity Identifier“) eingesetzt. Es ist anzunehmen, dass für zahlreiche Kreditnehmer kein LEI-Code vorliegen wird. In diesen Fällen kann die primäre Identifikation über eine nationale Identifikationsnummer vorgenommen werden [vgl. Europäische Zentralbank, 2015a]. Ohne die Identifikationsmerkmale verbleiben 94 geschäfts- bzw. kreditnehmerbezogene Attribute, die durch die betroffenen Institute für jeden relevanten Sachverhalt in unterschiedlichen Frequenzen zu melden sind. Eine wesentliche Unterscheidung unter den 94 Attributen bildet das Format der zu meldenden Daten. Hier wird zwischen Attributen ohne vordefinierte Ausprägungen und Attributen mit vordefinierten Ausprägungen unterschieden ( Tab. 02). Insgesamt 56 Attribute erfordern eine direkte Eingabe der Ausprägungen aus den Vorsystemen in den jeweiligen AnaCredit-Meldebogen ohne besonderen inhaltlichen Anpassungsbedarf. Dabei handelt es sich beispielsweise um Namen, Betrags- Tab. 01 AnaCredit Attribute Tab. 02 Aufteilung der Attribute nach Art der Ausprägung AnaCredit Meldebögen Anzahl Felder Attribute 94 Identifikationsfelder 7 Gesamt 101 Art Attribute Anzahl Attribute Attribute mit vordefinierter Ausprägung 56 Attribute ohne vordefinierter Ausprägung 38 Gesamt 94
Kreditrisiko 7 werte oder ein Datum. Bei den verbleibenden 38 Attributen sind die Ausprägungen bereits vordefiniert. Es muss folglich im Rahmen einer Implementierung zusätzlich neben der reinen Verfügbarkeit auch die Prüfung eines Mappings für eine Übertragung in die korrekten Ausprägungen vorgenommen werden. In der Regel ist bei einem Mapping auf vordefinierte Ausprägungen ein tendenziell erhöhter fachlicher Aufwand gegenüber der Meldung von Beträgen oder Zeichenfolgen zu erwarten. Bei der technischen Umsetzung liegt hingegen ein erhöhter Aufwand bei den Textfeldern, da hierbei technische Feldanforderungen beachtet werden müssen. Tab. 03 gibt einen Überblick über den Meldeumfang je Tabelle und wie sich die Attributarten auf die verschiedenen Datasets der Templates verteilen. Bewertung der Datenanforderungen Der Implementierungsaufwand hängt maßgeblich von der Verfügbarkeit bzw. dem Aufwand für die Verfügbarmachung der geforderten Daten ab. Ferner ist die passgerechte Integration dieser Daten in die relevanten Banksysteme von Bedeutung. Demnach bestehen die beiden wesentlichen Herausforderungen für ein erfolgreiches Projekt aus der Datenverfügbarkeit sowie dem Transformationsaufwand für eine meldungskongruente Bereitstellung der Attribute. Zur Abschätzung des Aufwands für diese Aspekte werden die 94 Attribute in drei Kategorien eingeordnet. 1. Bestandteil einer bestehenden Meldung (Kategorie „geringer Aufwand“) Attribute, die bereits in identischer Form zu melden sind, werden voraussichtlich den geringsten zusätzlichen Aufwand im Rahmen einer Implementierung verursachen. In diese Kategorie fallen somit sämtliche Attribute, die nicht nur dem Namen nach, sondern auch von der inhaltlichen Beschreibung sowie den geforderten Ausprägungen mit einem Attribut aus einer bestehenden Meldeanforderung übereinstimmen. Es ist zu beachten, dass die meisten bereits bestehenden Meldungen nicht auf Kreditnehmer- oder Kreditebene erfolgen, diese jedoch erfahrungsgemäß bei zahlreichen Instituten aus den granularen Datensätzen des Einzelkredits aggregiert werden. 2. Daten in einem Banksystem vorhanden, Format zu überprüfen (Kategorie „mittlerer Aufwand“) Neben regelmäßig zu meldenden Attributen wird eine Vielzahl von Attributen für Zwecke der Banksteuerung und der Rechnungslegung in Banksystemen vorgehalten. Ferner basieren einige für Meldezwecke erzeugte Attribute auf internen Berechnungen in verschiedenen vorgelagerten Systemen. Für diese Attribute muss überprüft werden, wie sie für die AnaCredit-Meldung nutzbar gemacht werden können. Im Idealfall können die Daten direkt übernommen werden, in anderen Fällen hat ein Mapping zu erfolgen. Eine weitergehende Analyse der Attribute dieser Kategorie muss den Anpassungsbedarf im Einzelfall feststellen. Überwiegend ist hier von einem überschaubaren Aufwand auszugehen. Jedoch kann hier – wie auch in der folgenden Kategorie – der Fall eintreten, Tab. 03 Verteilung der Attribute auf das Dataset Übersicht Meldebögen und „Datasets“ dass ein Attribut nicht in gewünschter Form erhoben wird und somit eine Anpassung bestehender Erfassungs- und Verarbeitungsprozesse notwendig wird. 3. Datenverfügbarkeit, systemseitige Erfassung sowie korrekte Formatierung zu überprüfen (Kategorie „hoher Aufwand“) Die Attribute in dieser Kategorie werden bisher nicht aktiv für Meldezwecke oder ähnliche Anforderungen abgefragt. Es ist jedoch im Regelfall anzunehmen, dass die Daten bereits für interne Zwecke erhoben wurden. Daher ist zu prüfen, wo und in welcher Form die bisherige Dokumentation erfolgt ist. Hierbei sind neben den verschiedenen Banksystemen auch andere Dokumentationsformen, wie Vertragsunterlagen, Kreditentscheidungsvorlagen oder Bewertungsgutachten zu überprüfen. Es ist zu evaluieren, wie die entsprechenden Daten zukünftig in automatisierter Form bereitgestellt werden können. Sollte die Untersuchung für Attribute zu dem Schluss kommen, dass diese bisher nicht erfasst wurden, sind neue Erfassungs- und Verarbeitungsprozesse zu implementie- ohne vordefinierte Ausprägung Attribute mit vordefinierter Ausprägung Gesamt Template 1 39 24 63 1. Daten zum Kreditnehmer 17 6 23 2. Daten zum Kredit 11 13 24 3. Finanzdaten 10 4 14 4. Daten zur Gegenpartei eines Kredits 0 1 1 5. Konsortialkredite 1 0 1 Template 2 17 14 31 6. Daten zur Rechnungslegung 8 8 16 7. Daten zu erhaltenen Sicherheiten 5 5 10 8. Daten zu erhaltenen Sicherheiten 2 0 2 (Bezug auf Kredit) 9. Risikodaten zur Gegenpartei 1 0 1 (nur für Kreditnehmer, Kontrahenten, Sicherungsgeber) 10. Daten zum Ausfall der Gegenpartei 1 1 2 (nur für Kreditnehmer, Kontrahenten, Sicherungsgeber) Gesamt 56 38 94
