Überzeugende Vorteile des AnaCredit-DQI-Tools

✅ Blitzschnelle Generierung einreichungsfähiger Meldedateien
✅ Präzise fachliche Validierung gemäß Bundesbank-Vorgaben
✅ Zuverlässige technische Validierung gegen das XSD-Schema
✅ Intuitive Dateneingabe über ein benutzerfreundliches Webformular
✅ Flexible Nutzung: Sofort in der Cloud verfügbar oder einfach auf Ihrem eigenen Webserver installierbar
✅ Höchste Datenschutzstandards durch „Privacy by Design“
✅ Maximale IT-Sicherheit durch „Security by Design“
✅ Ressourceneffizient: Keine zusätzlichen Applikations- oder Datenbankserver erforderlich

Fachlicher Kontext und Bedeutung

Die Deutsche Bundesbank führt umfassende Quer-Validierungen zwischen AnaCredit-Meldungen und Bankenstatistik-Meldungen (BSI) durch. Dabei werden Datenqualitätsindikatoren (DQI) berechnet, die die Qualität der gemeldeten Daten bewerten. AnaCredit-meldepflichtige Institute sind verpflichtet, Abweichungen durch Korrekturmeldungen zu beheben.

Trotz korrekter Meldung können in bestimmten Konstellationen Abweichungen auftreten. Diese müssen der Bundesbank mittels einer DQI-Meldung bestätigt werden. Unser Tool gewährleistet, dass Sie dieser Verpflichtung präzise und effizient nachkommen.

Technische Innovation

• Fortschrittliche Web-App mit vollständiger Ausführung im Browser-Frontend
• Keine Backend-Komponente erforderlich, dadurch maximale Sicherheit und Effizienz
• Höchste Datensparsamkeit und Sicherheit durch Nutung der Browser-Sandbox
• Flexibles Deployment: Nutzung in der Cloud oder auf Ihrem eigenen Webserver

Warum Sie sich für unser AnaCredit-DQI-Tool entscheiden sollten

1. Zeitersparnis: Schnelle und unkomplizierte Erstellung der Meldungen reduziert den Bearbeitungsaufwand erheblich.
2. Fehlerminimierung: Integrierte Validierungen gewährleisten höchste Datenqualität.
3. Permanente Compliance: Stets aktuelle Anpassungen an regulatorische Anforderungen.
4. Benutzerfreundlichkeit: Intuitives Design für eine reibungslose Bedienung.
5. Kosteneffizienz: Keine zusätzliche Hardware oder komplexe IT-Infrastruktur erforderlich.

Optimieren Sie Ihre AnaCredit-Meldeprozesse noch heute mit unserem innovativen DQI-Tool!

Kontaktieren Sie uns für eine Demo oder weitere Informationen

Diese neue Meldepflicht wurde mit dem Datenpunktmodell (DPM) Version 2.9 der European Banking Authority (EBA) eingeführt und ist ab Juni 2020 verpflichtend. Ein neues Tool leitet die fehlenden Zuflüsse und Abflüsse präzise und schnell her.

Wie Zuflüsse und Abflüsse abgeleitet werden

In der FINREP sind die Zu- und Abflüsse des aktuellen Jahres zu zeigen. Ausgangspunkt für deren Herleitung ist der Bestand an notleidenen Risikopositionen zum Jahresbeginn und den darauf folgenden Monatsultimos. Wandert eine Risikoposition zwischen zwei Monatsultimos von den vertragsgemäß bedienten zu den notleidenden Risikopositionen, so wird ein Zufluss erkannt. Im umgekehrten Fall wird ein Abfluss generiert.

Im Detail werden eine Reihe weiterer Meldepositionen berücksichtigt, wie z.B.:

• Abflüsse durch Tilgung
• Abflüsse durch Abschreibung
• Zuflüsse durch Zinsabgrenzung
• Neuklassifizierung von/zu gestundeten Risikopositionen

Da ein einzelner Vertrag innerhalb eines Monats nicht mehrfach zwischen den Meldepositionen migriert, können die Zu- und Abflüsse durch den Vergleich von Monatsultimos präzise bestimmt werden.

Die Bankenaufsicht erwartet vollständige Meldungen

Die Deutsche Bundesbank und die Europäische Zentralbank (EZB) erwarten von den Banken vollständige und korrekte Meldungen und können diese auch mit Sanktionen durchsetzen.

Ziegemeyer Consulting unterstützt Banken und Finanzdienstleister bei der Einhaltung regulatorischer Vorgaben. Meine Leistungen umfassen alle Projektphasen: von der Vorstudie über die Konzeption bis hin zu Umsetzung und Test. Kontaktieren Sie mich unverbindlich.

Die Software berechnet aus den bei der Deutschen Bundesbank eingereichten XML Dateien einfach zu lesende CSV Tabellen mit den aktiven Datensätzen. Das Ergebnis wird vom AnaCredit-Tool zum Erzeugen von Lösch- und Korrekturmeldungen und für stichtagsübergreifende Validierungen verwendet.

AnaCredit-Meldungen bauen aufeinander auf

AnaCredit-Meldungen bauen eine Historie in den Datenbanken von Deutscher Bundesbank und Europäischer Zentralbank (EZB) auf. Jede neue Meldung basiert auf dieser Historie. Die Kenntnis dieser Historie wird aus den folgenden Gründen benötigt:

• Um ein Instrument mit dem Aktionsattribut Löschung zu melden, weil es
  • fälschlicherweise übertragen wurde oder
  • nicht mehr meldepflichtig ist.
• Um Validierungsregeln zu prüfen, die auf vorherige Meldestichtage verweisen.
• Um Änderungen in den Vertragspartner- und Kreditstammdaten zu erkennen.

Die zentralen Regeln für die historische AnaCredit-Datenbank hat die Deutsche Bundesbank wie folgt festgelegt:

• Das Startdatum für den Aufbau der historischen Datenbank ist der Meldestichtag September 2018 – siehe Rundschreiben 63/2018.
• Kredit-Stammdaten sind so lange unbegrenzt gültig, bis sie ausdrücklich mit dem Aktionsattribut Löschung beendet werden.
• Bereits als beendet gemeldete Kredit-Stammdaten leben durch eine Korrekturmeldung für einen vorherigen Meldestichtag wieder mit unbegrenzter Gültigkeit auf. Nach der Korrekturmeldung muss erneut eine separate Löschmeldung eingereicht werden.

Um die Menge der Kredit-Stammdaten mit unbegrenzter Gültigkeit zu ermitteln, muss die chronologische Reihenfolge der gemeldeten Daten bekannt sein. Die Anforderungen der Deutschen Bundesbank hinsichtlich Korrekturen und Löschungen sind ausführlich in den Rundschreiben 76/2018 und 27/2019 erläutert.

Wie es funktioniert

Der AnaCredit-History-Reader benötigt die folgenden Daten:

• Liste aller XML-Dateien in chronologischer Reihenfolge, die an die Deutsche Bundesbank gesendet wurden. Das deckt die Meldungen des Berichtspflichtigen und all seiner beobachteten Einheiten und alle Meldungen seit September 2018 ab.
• Meldestichtag, für den der aktive Datenbestand ermittelt werden soll
• alle erfolgreich gemeldeten XML-Dateien

Die Software erzeugt eine CSV-Datei für jedes AnaCredit SDMX-DataSet pro Berichtspflichtigem und jede seiner beobachteten Einheiten. Die technische Spezifikation der Deutschen Bundesbank hinsichtlichtlich der Aktionsattribute Ersetzung (“Replace”) und Löschung (“Delete”) sind ebenso abgebildet, wie die unterschiedlichen Regeln für Kredit-Stammdaten und dynamische Kreditdaten.

Einsatzfelder für den AnaCredit-History-Reader

Der AnaCredit-History-Reader ist eine eigenständige Software, deren Ergebnis für folgende Zwecke verwendet werden kann:

• Löschung von Kreditdaten in AnaCredit-Meldungen
• stichtagsübergreifende Validierung
• um Änderungen in den Vertragspartner- und Kreditstammdaten zu erkennen
• Anzeigen aktiver Datensätze für einen Meldestichtag
• Altdatenübernahme bei der Migration zu einer neuen AnaCredit-Meldesoftware

Unverbindlich testen

Überzeugen Sie sich selbst. Fordern Sie unverbindlich eine Testversion des AnaCredit-History-Readers per E-Mail an.

Benötigt werden dazu lediglich die Vertragspartner-Stammdaten, die Kreditdaten und die historischen AnaCredit-Meldungen. Die Datenfeldbeschreibungen entsprechen fast vollständig der technischen Spezifikation der Bundesbank und sind damit hervorragend dokumentiert.

Das AnaCredit-Tool ermittelt aus dem angelieferten Geschäftsportfolio die meldepflichtigen Vertragspartner- und Kreditdaten. Diese werden anschließend mit den bereits historisch an die Bundesbank gemeldeten Daten abgeglichen. Löschmeldungen aufgrund ausgelaufener oder korrekturbedürftiger Geschäfte erzeugt das Tool automatisch.

Die validierten und einreichungsfähigen Meldedateien werden – je nach Größe des Geschäftsportfolios – innerhalb weniger Sekunden bis Minuten erstellt. Eine übersichtliche Auswertung der Haupt-Kennzahlen und Validierungsergebnisse erlaubt eine erste Prüfung auf einen Blick und einen Vergleich mit dem Vormonat.

Detaillierte Verarbeitungsprotokolle zeigen fehlerhaft angelieferte Daten und verletzte Validierungsregeln. Nach Korrektur der Eingabedaten wird die Verarbeitung einfach wiederholt.

Vorteile des AnaCredit-Tools

• Installation und Customizing in nur fünf Minuten
• Blitzschnelle Erstellung einreichungsfähiger Meldedateien
• Nachvollziehbar: alle nicht meldepflichtigen Kredite werden mit Begründung protokolliert
• Fachliche Validierung nach den Vorgaben der Bundesbank
• Technische Validierung gegen das Xsd-Schema
• Übersichtliche Darstellung der Schlüsselkennzahlen
• Einfaches tabellarisches Eingabeformat (csv)
• Datenfeldbeschreibung in Anlehnung an technische Spezifikation der Bundesbank
• „Privacy by design“:
  • Lokale Datenverarbeitung – ganz ohne Cloud
  • Datensparsamkeit – Rechenkern ohne Datenspeicherung
• Ressourcen-schonend:
  • Keine Datenbank erforderlich (spart Lizenzgebühren, Installations- und Wartungsaufwand)
  • Kein Server erforderlich
  • Keine Cloud erforderlich
  • Läuft auf Standard-Büro-PC’s unter Windows und unter Mac OS X
• Zukunftssicher:
  • Regelmäßige Einarbeitung neuer aufsichtsrechtlicher Vorgaben
  • Sehr hohe Qualität, Stabilität und sehr gute Wartbarkeit der Software durch einen Entwicklungsprozess auf dem neuesten Stand der Technik
  • Plattform-unabhängig: läuft unter Windows und Mac OS X (Linux, Java und Docker Container sind auf Anfrage möglich)

Über die AnaCredit-Meldung

Gegenstand der AnaCredit-Meldung sind granulare Kredit- und Kreditrisikodaten. Meldepflichtig an die Deutsche Bundesbank sind in Deutschland gebietsansässige Kreditinstitute sowie Zweigniederlassungen ausländischer Kreditinstitute.

Gemeldet werden Instrumente, deren Kreditbetrag mindestens 25.000 Euro erreicht. Kredite an natürliche Personen sind nicht meldepflichtig.

Die Meldung ist monatlich fällig und bis zum 6. Geschäftstag nach Monatsultimo abzugeben.

Unverbindlich testen

Überzeugen Sie sich selbst. Fordern Sie unverbindlich eine Testversion des AnaCredit-Tools per E-Mail an.

Dazu werden die Betragsdaten (BA-Datensätze) in der Form einer Tabelle eingelesen. Das Mio-Tool validiert die Daten und speichert diese als Meldedatei, die anschließend direkt über das Extranet der Bundesbank eingereicht werden kann.

Vorteile des Mio-Tools

• Installation und Customizing in nur fünf Minuten
• Lokale Datenverarbeitung – ohne Cloud/Internet
• Einfaches tabellarisches Eingabeformat (Excel/csv)
• Fachliche Validierung nach den Vorgaben der Bundesbank
• Technische Validierung gegen das Xsd-Schema
• Erfüllt die Dateinamenskonventionen
• Neues Meldeschema ab Meldestichtag 2019-03
• Läuft unter Windows und Mac OS X (Linux und Java auf Anfrage)

Über die Millionenkreditmeldung

Kredite von 1,0 Millionen Euro oder mehr müssen an die Deutsche Bundesbank gemeldet werden. Meldepflichtig sind nach § 14 Kreditwesengesetz (KWG):

• Kreditinstitute
• Wertpapierhandelsbanken
• Eigenhändler
• Factoring-Unternehmen
• Finanzdienstleistungsinstitute mit Factoring/Finanzierungsleasing
• Sozialversicherungsträger
• Versicherungsunternehmen
• Unternehmensbeteiligungsgesellschaften

Neue Datenanforderungen ab 2019

Anfang 2019 ändern sich die Vorschriften zur Millionenkreditmeldung. Ab dem Meldestichtag 2019-03 kommen folgende Felder in den Betragsangaben (BA) hinzu:

• POS093 Risikogewicht (aus dem COREP-Kreditrisiko-Standardansatz)
• POS094 Durchschnittliche Verlustquote (LGD)
• POS104 Notleidende Kredite (ausgefallen gemäß COREP-Definition)
• POS105 Erwarteter Verlust (EL)
• POS106 Risikoposition bei Ausfall (EaD)
• POS111 Schuldverschreibungen (POS112: darunter im Handelsbuch)
• POS113 Aktien/Beteiligungen (POS113: darunter im Handelsbuch)
• POS115 Repo/Leihe als Pensions-/Darlehensnehmer
• POS116 Repo/Leihe als Pensions-/Darlehensgeber
• POS122 Unwiderrufliche Kreditzusagen
• POS123 Widerrufliche Kreditzusagen
• POS131 Kontrahentenrisiko aus Kreditderivaten als Sicherungsnehmer
• POS132 Kontrahentenrisiko aus Kreditderivaten als Sicherungsgeber

Das Mio-Tool beherrscht die neuen Anforderungen.

Unverbindlich testen

Fordern Sie unverbindlich eine Testversion des Mio-Tools per E-Mail an.

Die Bankenaufsichtsbehörden möchten sich mit der Meldung zur Asset Encumbrance einen Überblick über die Belastung von Vermögenswerten der Banken verschaffen, da die Institute für eine günstigere Finanzierung verstärkt Sicherheiten stellen. Dies ist im Falle einer Bankenpleite zwar vorteilhaft für die Gläubiger der besicherten Forderungen, vermindert jedoch die Insolvenzquote für die Inhaber unbesicherter Bankanleihen. Sicherheiten stellt eine Bank zum Beispiel bei der Geldaufnahme im Rahmen von Wertpapierpensionsgeschäften, bei der Emission von Pfandbriefen oder bei der Verbriefung von Forderungen.

Im Projektteam wurden zunächst die neuen Meldeanforderungen analysiert. Davon ausgehend bestimmte man den zusätzlichen Datenbedarf, der anschließend durch die IT mittels neuer und erweiterter Schnittstellen gedeckt wurde.

Die Umsetzung des Ausweises auf den Formularen der Bankenaufsicht erfolgte durch die Anlieferung von Geschäftsdaten an die Standardsoftware ABACUS/DaVinci, die von der Bank bereits für andere aufsichtliche und statistische Meldungen eingesetzt wird. Die Befüllung der Meldewesen-Formulare durch ABACUS wurde eng mit dessen Hersteller BearingPoint abgestimmt.

Ein abschließender Test stellte die korrekte Anbindung von der Datenzulieferung über die Erstellung der Meldeformulare bis hin zur XBRL-Datei sicher.

Für die erstmalige Asset-Encumbrance-Meldung wurde vom Projektteam besonderer Augenmerk auf die Abstimmung mit dem Pfandbrief-Reporting und anderen bankaufsichtlichen Meldungen gelegt.

Im Ergebnis konnte die Bank den Erfolg verbuchen, die erstmalige Instituts- und Gruppenmeldung zur Asset Encumbrance für den Meldestichtag 31.12.2014 pünktlich abgegeben zu haben, wobei der Prozess zur Meldungserstellung stark durch die IT automatisiert wurde.

Ein direkter Vergleich zweier XBRL-Datensätze ist nicht möglich.

Mit einem Zwischenschritt gelingen Formularansicht und Meldungsvergleich: Die XBRL-Meldung wird mit der Software XBRL-Reader (kostenloser Download) in eine Tabelle umgewandelt.

Diese Tabelle enthält für jede Meldeposition die Datenpunkt-ID und – wenn die Tabelle eine offene Achse hat – ebenfalls den Wert der Schlüsseldimension aus dem Datenpunktmodell (Data Point Model – DPM) der Europäischen Bankenaufsichtsbehörde (EBA). Zusätzlich wird die Formularzelle des Datenpunktes angedruckt - mit Formularname, X-Achse, Y-Achse und Z-Achse.

Den Vergleich zweier Meldungen können Sie jetzt mit einer beliebigen Tabellenkalkulation durchführen, z.B. Excel. Dazu verknüpfen Sie die Meldepositionen beider Datensätze einfach über die Datenpunkt-ID und – für die offenen Tabellen – auch über die Schlüsseldimension.

Das funktioniert für alle bankenaufsichtlichen Meldungen, die auf dem Datenpunktmodell der EBA basieren. In der Version 2.2.0 des DPM sind das die folgenden Module:

• Common Reporting – Own Funds and Leverage (COREP)
• Large Exposures (LE)
• Liquidity Coverage (LCR)
• Stable Funding (NSFR)
• Financial Reporting (FINREP)
• Funding Plans (FP)
• Asset Encumbrance (AE)

Das XBRL-Format erläutert der Fachartikel “Der Weg zwischen XBRL und den COREP-/FINREP-Formularen”.

Europas Banken haben ihr bankenaufsichtliches Meldewesen grundlegend umstellen müssen, um den technischen Durchführungsstandards (ITS - Implementing Technical Standards) der European Banking Authority (EBA) zu genügen. Die gewohnten Dateiformate für die elektronischen Meldungen wurden abgelöst durch das sogenannte Data Point Model (DPM) und Taxonomien in eXtensible Business Reporting Language (XBRL).

Die Informationen, die an die Finanzaufseher gemeldet werden müssen, sind in XBRL nicht mehr wie gewohnt in Formularzellen mit Zeilen und Spalten hinterlegt. Das erschwert nicht nur die Kontrolle der einzelnen Meldung, sondern auch Vergleiche mit weiteren Datensätzen.

Komplexe Verbindung: Von XBRL zu den gewohnten Formularpositionen

Eine Überleitung des von der Bankenaufsicht festgelegten XBRL-Dateiformats in die FINREP- und COREP-Formulare, mit denen die Fachleute im Meldewesen arbeiten, ist möglich. Denn jede COREP- und FINREP-Formularzelle ist exakt einem Datenpunkt im Data Point Model zugeordnet; nur ausgegrauten Zellen ist kein Datenpunkt zugeordnet. Die folgende Abbildung zeigt ein Beispiel:

Allerdings lassen sich die Datenpunkte nicht direkt in der XBRL-Meldung ablesen. Sie sind dort vielmehr umschrieben als Mitglieder von Dimensionen. So ist der Datenpunkt 85024 definiert als Mitglied von vier Dimensionen:

Die dimensionalen Koordinaten eines jeden Datenpunkts sind in XBRL im Fakt und im Kontext der Meldeinformation abgelegt. Denn was in den FINREP- und COREP-Meldungen als Wert in den Zellen stand, die durch Zeilen- und Spaltenangaben beschrieben waren, wird in der XBRL-Meldung als Fakt im Rahmen eines Kontexts notiert. Fakten enthalten in XBRL das Mitglied der Metrik-Dimension, eine Verknüpfung zum Kontext und die Meldeinformation. Im Kontext stehen das meldende Institut, der Meldestichtag und die Mitglieder der verbleibenden Dimensionen.

Der folgende XBRL-Auszug beschreibt den Datenpunkt 85024:

<!-- XBRL-Fakt: Metrik-Dimension, Verknüpfung zum XBRL-Kontext und zu meldender Wert -->
  <eba:mi180 contextRef="c4" unitRef="U-EUR" decimals="-3">0</eba:mi180>

<!-- XBRL-Kontext: Meldendes Institut, Meldestichtag, und restliche Dimensionen -->
  <xbrli:context id="c4">
    <xbrli:entity>
      <xbrli:identifier scheme="http://standards.iso.org/iso/17442:2012">LEIIDENTIFIERFORTEST</xbrli:identifier>
    </xbrli:entity>
    <xbrli:period>
      <xbrli:instant>2013-12-31</xbrli:instant>
    </xbrli:period>
    <!-- XBRL-Szenario:  enthält die restlichen Dimensionen -->
    <xbrli:scenario>
      <xbrldi:explicitMember dimension="eba_dim:BAS">eba_BA:x9</xbrldi:explicitMember>
      <xbrldi:typedMember dimension="eba_dim:INC">
        <eba_typ:CC>c</eba_typ:CC>
      </xbrldi:typedMember>
      <xbrldi:explicitMember dimension="eba_dim:MCY">eba_MC:x59</xbrldi:explicitMember>
    </xbrli:scenario>
  </xbrli:context>

Einfach Technik: Applikation schafft die Übersetzung

Der Weg von der aufsichtsrechtlichen Meldung im XBRL-Format zur gewohnten Formularansicht und zurück führt also über die DPM-Datenpunkte und deren dimensionale Definition:

Um die von der Bankenaufsicht geforderten Meldungen im XBRL-Dateiformat in die vom Fachbereich gewohnten Formulare überzuleiten, ist eine auf das Lesen von XBRL für COREP/FINREP spezialisierte Applikation erforderlich.

ZIEGEMEYER Consulting hat eine Lösung für die Überleitung von XBRL in die vom Fachbereich gewohnte Formularansicht entwickelt.

So können die Fachleute im Meldewesen die XBRL-Meldung vor der Abgabe an die Bundesbank wie gewohnt kontrollieren. Auch Vergleiche mit früheren Meldungen sind dadurch möglich – etwa um Veränderungen zwischen zwei Meldestichtagen zu ermitteln oder um bei Releasewechseln der Meldewesen-Software regressive Tests durchzuführen.

Das XBRL-Format erläutert der Fachartikel “Der Weg zwischen XBRL und den COREP-/FINREP-Formularen”.

Benutzung

Der XBRL-Reader ist eine Kommandozeilenanwendung. “xbrlread.exe” wandelt eine bestehende XBRL-Datei in eine Tabelle um und speichert diese als neue Datei im CSV-Format.

Aufruf

xbrlread.exe input-filename.xbrl output-filename.csv

Ausgabe

Abgedeckte Meldungen

XBRL-Reader deckt das Datenpunktmodell (Data Point Model – DPM) der European Banking Authority (EBA) in der Version 2.2.0 mit allen enthaltenen Modulen ab:

• Common Reporting – Own Funds and Leverage (COREP)
• Large Exposures (LE)
• Liquidity Coverage (LCR)
• Stable Funding (NSFR)
• Financial Reporting (FINREP)
• Funding Plans (FP)
• Asset Encumbrance (AE)

Download

ABACUS-Hersteller BearingPoint ließ ein umfassendes Datenmodell konzipieren für die benötigten Informationen: Finanzprodukte, Gattungsdaten, Sicherheiten, Partnerbeziehungen, Geschäfte. Auf dieser Basis wurden Datenhaushalt und Schnittstellen von ABACUS von Grund auf neu implementiert.

Das Redesign machte die Software zukunftsfähig und besser zu pflegen: Die zahlreichen neuen gesetzlichen Anforderungen lassen sich gut integrieren, ABACUS bleibt wartbar und performant.