Die zentrale Erhebung granularer Kreditdaten und Kreditrisikodaten auf der Ebene von Einzelkrediten ist in Europa keine Neuheit. Auf nationaler Ebene werden diese Informationen bereits seit Jahrzehnten von einzelnen europäischen Zentralbanken erhoben (zum Beispiel in Frankreich seit 1946, in Italien seit 1964).1) Neu ist indes, dass die Europäische Zentralbank (EZB) mit der Schaffung des Analytical Credit Dataset (Ana-Credit) zum ersten Mal eine länderübergreifende und einheitliche Erfassung von Einzelkrediten ab 25 000 Euro in standardisierter Form ab dem Jahr 2018 etablieren wird, die es ermöglichen wird, eine länderübergreifende Vergleichbarkeit herzustellen.
Gute und konsistente Qualität der Daten sicherstellen
Das wesentliche Problem, dem sich indes jegliches Unterfangen, Daten standardisiert zu erheben, gegenübersieht, ist es, eine ausreichend gute und konsistente Qualität der Daten zu gewährleisten. Aufgrund der Komplexität von Ana-Credit wird diese paneuropäische Daten-Initiative vor besonderen Herausforderungen stehen.
Um zu ermessen, wie diese Herausforderungen im Detail aussehen werden, bietet sich der Vergleich mit anderen paneuropäischen Daten-Initiativen an. Ein gutes Beispiel ist dabei das European Data Warehouse. Es wurde im Rahmen der ABS-Loan-Level-Initiative der EZB im Jahr 2012 als Marktinitiative gegründet, mit der Maßgabe, die Einzelkreditdaten in den zugrunde liegenden Forderungspools europäischer Verbriefungstransaktionen Investoren und anderen Markteilnehmern zur Verfügung zu stellen.
Ziel der Initiative ist es, eine deutlich höhere Transparenz hinsichtlich der zugrunde liegenden Kreditrisiken zu schaffen, asymmetrische Informationsverhältnisse zwischen Investoren und Ratingagenturen zu beseitigen und letztlich das Vertrauen in das Produkt ABS zu fördern. In diesem Zusammenhang sind die veröffentlichten Daten auf ihre Vollständigkeit und Richtigkeit hin zu prüfen. Im Rahmen der täglichen Arbeit mit Einzelkreditdaten hat das European Data Warehouse dabei in den vergangenen drei Jahren umfangreiche Erfahrungen gesammelt, die für die vergleichbare Aufgabenstellung von Ana-Credit sehr relevant sind.
Im Gegensatz zu Ana-Credit ist bei der ABS-Loan-Level-Initiative keine formale Berichtspflicht vorgeschrieben. Die Veröffentlichung erfolgt grundsätzlich freiwillig, wobei die Einbeziehung der jeweiligen ABS-Transaktion als Sicherheit für Repo-Transaktionen des Eurosystems eine Veröffent lichung der Daten zwingend erforderlich macht und dementsprechend ein hoher wirtschaftlicher Anreiz für das Reporting besteht.
Die wesentliche Parallele ist die Bereitstellung granularer Daten (loan-by-loan beziehungsweise (instrument-by-instrument) durch Finanzinstitute auf paneuropäischer Basis. Entscheidend ist hierbei eine einheitliche Definition der zu berichtenden Datenattribute (Taxonomie), die über Europa beziehungsweise die Eurozone hinweg gültig sein müssen. Bei der ABS-Loan-Level-Initiative wurden unter der Federführung der EZB die für die jeweiligen Assetklassen einheitlichen Vorlagen (Data Templates) und die Definition der Datenattribute (Taxonomie) zusammen mit Vertretern der ABS-Branche in Arbeitsgruppen diskutiert und festgelegt. Für einzelne Attribute (Datenfelder) wurden dabei weitere Erläuterungen vorgenommen und auch nationale Besonderheiten berücksichtigt.
Aufteilung in verpflichtende und optionale Datenfelder
Wichtig ist zudem die Aufteilung in verpflichtende und optionale Datenfelder. Optionale Datenfelder müssen nicht im Rahmen der Anforderungen an repofähige Sicherheiten veröffentlicht werden. Zusätzlich werden Definitions- und andere Fragen auf einer speziellen EZB-Webseite (Frequently asked questons - FAQ) erörtert und in Zweifelsfällen können berichtende Finanzinstitute sich auch bilateral über eine EZB-Helpline an die EZB wenden.
Im Rahmen von Ana-Credit gibt es mehrere Projekte in der Vorbereitungsphase, wesentlich ist hier vor allem für die berichtenden Finanzinstitute das Bank's Integrated Reporting Dictionary (BIRD). Das BIRD-Projekt wird ein Kompendium genauer Definitionen der notwendigen Eingabedaten für Ana-Credit erarbeiten inklusive einer Beschreibung der notwendigen Transformationen, die auf Basis der Eingabedaten ein einheitliches Reporting ermöglicht. Ziel ist unter anderem durch BIRD eine hohe Datenqualität und -konsistenz zu erreichen. Die Beachtung der BIRD-Vorgaben ist indes freiwillig, es bleibt also abzuwarten, inwieweit in der Praxis Finanz institute hier eine Umsetzung in Angriff nehmen, da unweigerlich nicht unerhebliche Kosten entstehen werden.
Hoher Projektaufwand für Ana-Credit
Insgesamt ist der erwartete Projektaufwand für Ana-Credit erheblich höher als für die Umsetzung der ABS-Loan-Level-Initiative. Auch wird durch BIRD sowie das Ana-Credit-Manual bereits vorab ein umfangreiches Netz an Richtlinien und Definitionen erstellt, das bereits bei Beginn des Reportings viele Zweifelsfragen geklärt haben sollte. Die folgenden Herausforderungen werden indes auch bei Ana-Credit unweigerlich auftreten:2)
- unterschiedliche Rechnungslegungsvorschriften auf nationaler Ebene, - Interpretationsspielräume auf nationaler Ebene,
- bislang keine Vereinheitlichung regulatorischer Vorschriften, die auf Ebene der Finanzinstitute weiterhin zu hohem Erfassungsaufwand führen,
- Nichtverfügbarkeit von Daten aufgrund alter IT-Systeme oder Nichterhebung bestimmter Daten in der Vergangenheit,
- unterschiedliche Verfügbarkeit und Zugang zu Daten auf Ebene der Finanzinstitute, zum Beispiel aufgrund von Akquisitionen und Fusionen,
- unterschiedliche Praktiken zur Behandlung und Verwaltung von notleidenden Krediten, die wiederum ein einheitliches Reporting erschweren.
In den letzten Jahren musste das European Data Warehouse viele dieser Punkte in der Praxis auch im Rahmen der ABS-Loan-Level-Initiative addressieren und hat dementsprechend ein umfangreiches Datenqualitätsmanagement aufgebaut. Diese Erfahrungen werden in den nächsten Abschnitten zusammengefasst.
Datenqualitätsmanagement im Rahmen der ABS-Loan-Level-Initiative
Im Wesentlichen können drei verschiedene Ursachen für Probleme der Datenqualität identifiziert werden, die im Rahmen dieses Aufsatzes diskutiert werden sollen:
1. Datenqualitätsprobleme aufgrund nicht hinreichender Defintion von Datenfeldern,
2. Datenqualitätsprobleme aufgrund von Falscheingaben,
3. Datenqualitätsprobleme aufgrund inhaltlicher Abweichungen der erhobenen Daten.
Datenqualitätsprobleme aufgrund nicht hinreichender Definition von Datenfeldern: Um den Banken und Emittenten europäischer Verbriefungstransaktionen die Erhebung der notwendigen Detailinformationen zu ermöglichen, hat die EZB (wie bereits erwähnt) Erfassungsvorlagen (sogenannte Data Templates) und zugehörige Erläuterungen (sogenannte Taxonomien) für die verschiedenen Assetklassen (zum Beispiel RMBS, Leasing-ABS, KMU-ABS) auf ihrer Webseite zur Verfügung gestellt.3)
Die Taxonomien haben dabei vor allem das Ziel, den Emittenten den Abgleich der geforderten Detailinformationen mit den bankintern verfügbaren Informationen zu erleichtern und Missverständnisse bei der Datenerhebung zu vermeiden.
Obwohl die Taxonomien bereits umfangreiche Erläuterungen je gefordertem Datenfeld enthalten, ergeben sich im Einzelfall regelmäßig Unklarheiten hinsichtlich der Interpretation dieser Erläuterungen. Da eine Taxonomie - so detailliert sie auch entworfen wird - niemals sämtliche möglichen Eventualitäten abbilden kann, ist die einzige Lösung, um diesem Problem zu begegnen, eine umfangreiche und sich stetig erweiternde, Sammlung von Fragen und Antworten.
Aufgrund der zahlreichen Fragen zu den verwendeten Taxonomien unterhält die EZB eine entsprechende Webseite mit Fragen und Antworten zu den Data Templates, zu den Melderegelungen und mit weiter gehenden Erläuterungen zu den Taxonomien (siehe Beispiele aus der RMSB-Taxonomie).4) Insgesamt hat die EZB detaillierte Antworten zu mehr als 350 Einzelfragen zu den Data Templates auf ihrer Webseite zusammengetragen.5)
Missverständnisse kaum vermeidbar
Mit Blick auf die ungleich umfangreichere Zahl von einmeldenden Insititutionen sowie die größere Abdeckung des Kreditgeschäfts durch Ana-Credit werden sich ähnliche Missverständnisse zum einen kaum vermeiden lassen und zum anderen in einer weitaus größeren Zahl auftreten. Als Beispiel kann hier bereits das Attribut "Ausfallwahrscheinlichkeit" genannt werden, welches als Teil der Daten des Vertragspartnerrisikos erhoben werden soll.6) Während das Eingabeformat des Feldes definiert ist (numerischer Wert zwischen 0 und 1), wird bislang nicht das Datum der letzten Beurteilung des Ausfallrisikos erhoben. Dementsprechend ist unklar, wie alt die gemeldete Ausfallwahrscheinlichkeit sein darf. Migrationsmatrizen, die auf dieser Information aufbauen, werden folglich wenig aussagefähig sein.
Datenqualitätsprobleme aufgrund von Falscheingaben: Im Rahmen der ABS-Loan-Level-Initiative der EZB melden die Emittenten europäischer Verbriefungstransaktionen die ausgefüllten Data Templates an das European Data Warehouse. Die Dateneingabe erfolgt im Datenformat XML bei dessen Generierung verschiedene Datenformatchecks vorgenommen werden (sogenannte Syntax/Schema-Checks). Sollten die Daten diesen formalen Kriterien nicht entsprechen, können sie nicht in die Datenbank des European Data Warehouse hochgeladen werden. Diese formalen Fehler sind zum Beispiel
- Texteingaben anstelle von numerischen Werten, - fehlerhafte Datumsformate (zum Beispiel 12-2015 anstelle von 2015-12),
- Angaben außerhalb des definierten Wertebereichs (etwa Eingaben können die Werte von "1" bis "6" annehmen, aber die Eingabe ist "7" oder die Eingabe soll als "Y" oder "N" erfolgen, die Eingabe ist aber "X"),
- Eingaben von "ND" (No Data), obwohl diese Option laut Taxonomie nicht vorgesehen ist,
- Nichtbeachtung der geforderten Syntax (zum Beispiel Währungsabkürzungen nach ISO 4217, Regionenbezeichnungen nach NUTS-Systematik oder Wirtschaftszweigklassifikation nach NACE Rev. 2).
Mehrstufige Datenqualitätsanalyse notwendig
Unabhängig von diesen formalen Checks müssen aber auch inhaltliche Falscheingaben geprüft werden. Während viele dieser Falscheingaben auf Einzeldarlehensebene relativ leicht ersichtlich sind, ist in der Praxis durch die hohe Anzahl von Darlehen (aktuell sind insgesamt über 50 Millionen Darlehen in der Datenbank des European Data Warehouse) eine mehrstufige Datenqualitätsanalyse notwendig.
Typische Beispiele sind:
- fehlender Dezimalpunkt: Eingabe von 10000000 anstelle von 100000.00,
- Nutzung von Platzhaltern, zum Beispiel Angabe des Einkommens des Kreditnehmers mit "0.00" für 80 Prozent aller Darlehen,
- Eingabe von "ND5 (no data - data not relevant for this loan)", obwohl eine Relevanz unzweifelhaft vorliegt,
- Duplikation einzelner Darlehen mit der gleichen Darlehensnummer.
Für die Datenerhebung von Ana-Credit werden ebenfalls Erfassungsvorlagen vonseiten der EZB und nationaler Zentralbanken vorgegeben, mit denen bis zu 95 Attribute je Kreditinstrument erhoben werden.7) Da hier zum Teil die identischen Informationen wie in den Data Templates der ABS-Loan-Level-Initiative erhoben werden (zum Beispiel Regionenbezeichnung nach NUTS-Systematik, Wirtschaftszweigklassifikation nach NACE Rev. 2, Jahresumsatz oder Zinsspanne) ist zu erwarten, dass im Rahmen der Datenerhebung von Ana-Credit vergleichbare Datenfehler auftreten werden.
Datenqualitätsprobleme aufgrund inhaltlicher Abweichungen der erhobenen Daten: Eine umfassende und zielgerichtete Datenqualitätsanalyse prüft nicht nur die Einhaltung der Kriterien auf Datenfeldebene, sondern hinterfragt auch die inhaltliche Konsistenz der Daten. Im Fall von Loan-Level-Daten umfasst eine solche Prüfung daher auch den Abgleich einzelner Felder in den Data Templates untereinander. Zudem ist zu überprüfen, ob die Dateneingabe zwar grundsätzlich korrekt ist (das heißt, die Daten entsprechen dem zugrunde liegenden Sachverhalt), allerdings die Taxonomie einen anderen Wert definiert hat.
Verlässlichkeit der Einzeldaten beurteilen
Die Prüfung auf inhaltliche Konsistenz berücksichtigt die Tatsache, dass ein einzelnes Kreditengagement durch zahlreiche Eingabefelder (bei Ana-Credit als sogenannte "Attribute" bezeichnet) beschrieben wird. Um die Verlässlichkeit dieser Einzeldaten zu beurteilen, muss man sie in einen logischen Zusammenhang bringen und dann die Qualität ihrer Aussage verifizieren. Im Einzelfall bedeutet dies zum Beispiel, dass der ausstehende Kreditbetrag eines ausgefallenen Kreditnehmers (Feld AS121 Default or Foreclosure, Eingabewert "Y") in dem dafür vorgesehenen Eingabefeld ausgewiesen sein muss (Feld AS125 Default Amount) und nicht im Eingabefeld für nicht ausgefallene Kredite (AS55 Current Balance). Ein weiteres Beispiel ist die Zuordnung von Kreditsicherheiten. So muss ein als besicherter Kredit erfasstes Engagement (Feld AS26 Seniority, Eingabewert: "senior secured") eine zugehörige Sicherheitenart (Feld CS6 Collateral Type) und einen zugehörigen Sicherheitenwert (Feld CS4 Collateral Value) aufweisen.
Die beschriebenen Datenqualitätsanalysen erfolgen ausschließlich auf Basis der gemeldeten Loan-Level-Daten und erlauben eine weitgehende Beseitigung möglicher Datenfehler. Der Analyseprozess des European Data Warehouse geht indes noch einen Schritt weiter, indem bei einzelnen Emittenten die gemeldeten Werte nochmals kritisch hinterfragt werden.
Bei einer Umfrage unter spanischen Emittenten von Residential Mortgage-Backed Securities (RMBS) im Herbst 2015 ergaben sich dabei zum Teil erhebliche Abweichungen der gemeldeten Werte von Emittent zu Emittent aufgrund des Fehlens standardisierter Definitionen innerhalb von ABS-Transaktionen, aufgrund unterschiedlicher Prozesse und Praktiken innerhalb von Banken sowie aufgrund der Verwendung von Schätzern beim Fehlen der geforderten Informationen.
Rein datenbasierte Qualitätsanalyse unzureichend
Die folgenden Beispiele aus der Umfrage8) verdeutlichen diese Herausforderungen, die im Rahmen einer rein datenbasierten Qualitätsanalyse nicht gelöst werden können.
1. Aufgrund des Fehlens standardisierter Definitionen innerhalb des europäischen Verbriefungsmarktes greifen Emittenten für das regulatorische Meldewesen zum Teil auf die Transaktionsdokumentation zurück. Im Rahmen der Umfrage wurde dies anhand der gemeldeten Werte für Kredite mit Zahlungsverzügen deutlich (Feld AR166 Account Status, Eingabewert: 2, in arrears). Die Abbildung 1 zeigt, dass etwa die Hälfte (47,9 Prozent) der Emittenten diese Informationen für Kredite ab dem ersten Tag des Zahlungsverzugs melden. Ein Drittel der Emittenten (33,7 Prozent) meldet diese Kredite indes erst am 91. Tag nach dem Fälligkeitstag als "in Verzug" und weitere 16,6 Prozent der Emittenten melden diese Kredite nur im Zeitraum zwischen dem Fälligkeitstag und dem 91. Tag als "in Verzug". Vor allem die beiden letzten Vorgehensweisen zeichnen dementsprechend ein deutlich unterschiedliches Bild über die Zahl der Kredite mit Zahlungsrückständen (Abbildung 1).
2. Unterschiedliche Prozesse, IT-Systeme und Praktiken innerhalb von Banken sind ein weiterer Grund für inhaltliche Abweichungen in den Daten, die sich erst durch ein Gespräch mit dem Emittenten erklären lassen. Diese Abweichungen betreffen dabei häufig Informationen aus der Abwicklung von notleidenden Krediten. Im Rahmen der Umfrage unter spanischen RMBS-Emittenten zeigte sich, dass etwa ein Drittel der Emitteten nicht über die notwendigen Daten zu den Verwertungserlösen von Immobilien, die als Kreditsicherheit dienten, verfügten (siehe Abbildung 2).
Arbeit mit Schätzwerten
3. Das Fehlen genauer Angaben zwingt Emittenten häufig dazu, mit Schätzwerten zu arbeiten. Dies kann darin begründet liegen, dass die aufsichtsrechtlichen Datenanforderungen nicht jenen Daten entsprechen, die während des Kreditvergabeprozesses erhoben wurden. Im Fall der spanischen RMBS-Emittenten war dies vor allem bei den Gehaltsangaben der Kreditnehmer ein wiederkehrendes Problem. Die Taxonomie der EZB fordert für das Feld AR26 (Primary Income) die Erfassung des Bruttojahresgehalts. Dieser Wert konnte indes nur von etwa der Hälfte (52,6 Prozent) der spanischen Emittenten gemeldet werde, währen mehr als ein Drittel (37,0 Prozent) das Nettogehalt oder eine Mischung verschiedener Einkommensarten verwendete (Abbildung 3).
Dieses Beispiel zeigt, dass auch bei klaren Definitionen in der Praxis erhebliche Qualitätsprobleme relevant sind. Dies ist im Übrigen auch für das Thema Transformationen im Rahmen des BIRD-Projektes relevant. In diesem Beispiel ist eine Umrechung von Net Income auf Gross Income nur ansatzweise möglich, da für eine genaue Transformation Kreditnehmerdaten wie zum Beispiel individueller Steuersatz notwendig wären, die aber typischerweise nicht erhoben sind.
Die angeführten Beispiele aus Spanien basieren auf den Erfahrungswerten, die das European Data-Warehouse aufgrund der täglichen Arbeit mit Loan-Level-Daten seit 2013 gesammelt hat. Wie erläutert haben die beobachteten Datenqualitätsprobleme drei wesentliche Ursachen: unklare Vorgaben zur Datenerhebung, formale Fehler sowie inhaltliche Abweichungen der erhobenen Daten.
Kein Raum für Interpretation
Für die europaweite Datenerhebung im Rahmen des Ana-Credit-Projekts und vor allem die laufende Sicherung der Datenqualität bedeuten diese Erfahrungen, dass im Wesentlichen zwei wichtige Ziele verfolgt werden müssen:
Die Beschreibung der zu erfassenden Attribute darf möglichst keinen Raum für Interpretation aufseiten der einmeldenden Institute lassen. Dies ist angesichts der Vielzahl der Kreditinstrumente im Firmenkundengeschäft, deren individueller Ausgestaltung sowie nationaler Kreditvergaberichtlichen und -gewohnheiten eine nicht einfach lösbare Aufgabe. Zwar werden über das Ana-Credit Manual und das BIRD-Projekt im Vorfeld umfangreiche Arbeiten zu Definitionen inklusive Fallstudien vorgenommen, allerdings ist es realistisch unmöglich, alle in der Praxis vorkommenden Fälle bereits ex ante abschließend behandeln zu können.
Es muss einen umfassender Datenqualitätsprozess aufgesetzt werden, der neben der Verbindung einer regelbasierten Datenanalyse mit der Kontrolle durch spezialisierte Datenanalysten vor allem eine Vielzahl von Feedback-Schleifen beziehungsweise Datenqualitätsthemen zwischen einmeldenden Instituten und den Berichtsempfängern im Eurosystem vorsieht. Nur mithilfe dieser regelmäßigen Kommunikation mit den einmeldenden Instituten und den nationalen Zentralbanken kann eine nachhaltig hohe Datenqualität erreicht werden.
Quellenverzeichnis
Jentzsch, Nicola; Do We Need a European Directive for Credit Reporting? in: CESinfo DICE Report, No. 2, 2007, S. 48-54.
European Banking Federation (EBF); EBF comments on the ECB draft regulation on Anacredit, 27.1.2016, http://www.ebf-fbe.eu/wp-content/uploads/2016/01/EBF_019220-EBF-Positioning-on-AnaCredit-tracked-changes.pdf
Europäische Zentralbank, Verordnung (EU) 2016/867 vom 18. Mai 2016 über die Erhebung granularer Kreditdaten und Kreditrisikodaten (EZB/2016/13). Europäische Zentralbank, Data templates, https:// www.ecb.europa.eu/mopo/assets/loanlevel/transmission/html/index.en.html.
Europäische Zentralbank, Frequently Asked Questions, https://www.ecb.europa.eu/mopo/assets/loanlevel/faq/html/index.en.html.
European Data Warehouse, Special Report - European Data Warehouse Commentary on Spanish RMBS Loan Level Data, January 2016.
Fußnoten
1) Vgl. Jentzsch, N.; Do We Need a European Directive for Credit Reporting?; S. 50.
2) Vgl. EBF zu einer kritischen Stellungnahme bez. Ana-Credit; EBF comments on the ECB draft regulation on Ana-Credit.
3) Vgl. Europäische Zentralbank, Data templates, https://www.ecb.europa.eu/mopo/assets/loanlevel/transmission/html/index.en.html.
4) Vgl. Europäische Zentralbank, Frequently Asked Questions, https://www.ecb.europa.eu/mopo/assets/loanlevel/faq/html/index.en.html.
5) Vgl. Europäische Zentralbank, Frequently Asked Questions, https://www.ecb.europa.eu/mopo/assets/loanlevel/faq/html/index.en.html.
6) Vgl. Europäische Zentralbank, Verordnung (EU) 2016/867 vom 18. Mai 2016 über die Erhebung granularer Kreditdaten und Kreditrisikodaten (EZB/2016/13), Anhang IV.
7) Vgl. Europäische Zentralbank, Verordnung (EU) 2016/867 vom 18. Mai 2016 über die Erhebung granularer Kreditdaten und Kreditrisikodaten (EZB/2016/13), Anhang IV.
8) European DataWarehouse, Special Report - European DataWarehouse Commentary on Spanish RMBS Loan Level Data, January 2016, S. 4-6.
