BIRD 3.0 – Datenmodell reif zur Umsetzung?

Mit der aktuellen Version wird das Modell zusätzlich zur AnaCredit und der Securities Holdings Statistics (SHS) um die FINREP-Meldung sowie die Meldung zur Sanierungs- und Abwicklungsplanung erweitert.
Das BIRD-Datenmodell definiert dabei nicht nur den aggregierten Reportingumfang, sondern vor allem eine granulare Eingangsschnittstelle für die Meldedaten und liefert zusätzlich die Transformationen in die Meldungen. BIRD reiht sich dabei in die Bemühungen der Aufsicht ein – wie z. B. BCBS #239 – über ein integriertes Datenmodell die Abstimmbarkeit von Finanz- und Risikodaten zu verbessern.

Umfang des BIRD-Datenmodells

Das Banks’ Integrated Reporting Dictionary beschreibt insgesamt ein mehrschichtiges Datenmodell. Jede Datenschicht (auch Layer genannt) erfüllt dabei eine definierte Funktion. Abgerundet wird der Umfang durch Transformationsregeln, die den Übergang der Dateien aus einer Schicht in die nächste abbilden. BIRD liefert damit im Wesentlichen eine komplette fachliche Vorgabe für die Implementierung einer Reportingplattform. Im Folgenden wird nun detaillierter auf die Datentransformation und die verschiedenen Ebenen des Datenmodells eingegangen.

Beschreibung des Layer-Konzepts

Das Layer-Konzept von BIRD besteht aus vier aufeinander aufbauenden Schichten:

• Der Input Layer (IL) fasst alle granularen Informationen in einem Entity Relationship Model (ERM) zusammen, wie beispielsweise Informationen über Geschäftspartner, Zusagen, Instrumente oder Sicherheiten. Im IL werden die notwendigen Basisdaten zur Generierung der unterschiedlichen Reports angeliefert, eine direkte Anlieferung aus den Frontofficesystemen ist auch möglich.
• Alle dem IL angelieferten Daten werden dann dem Enriched Input Layer (EIL) zugeführt, der als Zwischenschicht dient. Dort werden die Daten des IL mit zusätzlichen Informationen angereichert, wie beispielsweise dem Ergebnis der Ableitung der Kleine-und-mittlere-Unternehmen(KMU)-Klassifizierung.
• In dem Referenz Output Layer (ROL) erfolgt die Meldevorbereitung für die Templates mit den originalen Wertebereichen des IL. Der ROL erlaubt damit Analysen der Meldedaten in den angelieferten Formaten und erhöht somit die Nachvollziehbarkeit.
• Im Non Referenz Output Layer (NROL) erfolgt die finale Aufbereitung der Daten im Meldeformat der einzelnen Reports (Melde-Cube). Der NROL ist so ausgelegt, dass eine Aufbereitung in XBRL direkt erfolgen kann, diese ist allerdings nicht Bestandteil von BIRD.

Abbildung 1: Übersicht der verschiedenen Layer-Ebenen im BIRD-Datenmodell

Die Transformationen

Der Umfang von BIRD 3.0 wurde über ein reines Dictionary oder Datenmodell hinausgehend um ein umfangreiches Set von Transformations- und Abbildungsregeln erweitert. Die Transformationen dienen zur Anreicherung und Überführung von Daten zwischen den Layern – sie geben also die fachliche Vorgabe, wie sich die Daten in den aufbauenden Layern EIL, ROL und NORL aus den Eingangsdaten des IL zusammensetzen.

Die Transformationen erfüllen somit die Lineage bei der Befüllung der Meldepositionen und lassen sich in die Bereiche Ableitungsregeln und Regeln zum Datentransfer (copy, data transfer) unterteilen. Zusätzlich gibt es eine Reihe von Validation Rules, die die Integrität der Daten innerhalb der einzelnen Schichten sicherstellen.

Eine zusätzliche Integration von Validation Rules der European Banking Authority (EBA), die einzelne Meldepositionen untereinander als auch übergreifend zwischen COREP und FINREP prüfen, wäre hier eine wertvolle Ergänzung und würde die Dimensionen von BIRD mit weiteren aufsichtlichen Anforderungen zu Daten und Qualität abrunden. Die EBA Validation Rules sind typischerweise im Umfang kommerzieller Meldewesenlösungen enthalten, und die Überprüfung der Validierungen ist mittlerweile fester Bestandteil des Meldeprozesses einer jeden Bank geworden.

Weitere Ausbaustufen

Der bereits eingangs beschriebene Umfang von BIRD 3.0 soll bis Mitte 2019 erweitert werden. Als nächste Schritte in der Roadmap für BIRD ist bis Mitte 2019 eine Integration der COREP im Kreditrisiko-Standardansatz (KSA) und im Internal Rating-Based Approach (IRB) geplant. Weiter ist bis Ende 2019 die Aufnahme der Meldungen zur Liquidity Coverage Requirement, die als europaweiter Mindeststandart im Bereich Liquiditätsüberwachung eingeführt wurde, geplant – ergänzt um die Asset Encumbrance Leverage Ratio, die als Kennziffer im Risikomanagement und der Bonitätsanalyse der Banken eingesetzt wird.

Als kleinere Updates werden die Bereiche Balance Sheet Items Statistics (BSI) und Monetary Financial Institutions’ Interest Rate Statistics (MIR) umgesetzt, welche die statistischen Meldungen in BIRD komplettieren.

Ist BIRD in der aktuellen Version geeignet für eine Umsetzung?

Mit der BIRD-Initiative legt die Aufsicht die richtigen Akzente für eine harmonisierte und abstimmbare Meldung vor und liefert eine Antwort auf die bisherige Lösungsvielfalt für die einzelnen Meldungen und die damit verbundene Komplexität.

Mit der aktuellen Version von BIRD sind wichtige Schritte hin zu einer umsetzbaren Blaupause getan. Allerdings bestehen aufgrund der Freiwilligkeit einer Implementierung und eines zögerlichen Bekenntnisses der nationalen Aufsichten bisher keine Softwareunterstützungen am Markt, und eine eigene Implementierung ist mit Risiken versehen, die jedes Institut individuell für sich bewerten muss.

In anderen Ländern, wie z. B. Österreich, wurde bereits mit der Gemeinsamen Meldeplattform (GMP) ein vereinheitlichtes (Melde-)Datenmodell in enger Zusammenarbeit mit Aufsicht und Banken erarbeitet, welches nun die Grundlage für die Vielzahl an aufsichtsrechtlichen Meldungen darstellt. Hier wird es spannend sein zu beobachten, wie sich BIRD gegenüber konkurrierenden Ansätzen positionieren kann.

Eine deutliche Steigerung der Umsetzbarkeit könnte erreicht werden, wenn Weiterentwicklung und Release des BIRD-Datenmodells ein verbindlicher Bestandteil der Veröffentlichung von Initiativen würde. Bisher bedingt die verzögerte Veröffentlichung den Aufbau von temporären und kostenintensiven Workarounds, die damit vermieden werden könnten.

Welcher Nutzen kann aus der aktuellen Version von BIRD gezogen werden und welche Chancen ergeben sich langfristig?

Aus der langjährigen Projekterfahrung von zeb mit regulatorischen und integrierten Datenhaushalten heraus umfasst der Umfang integrierter Datenmodelle typischerweise 2500 bis 4000 Attribute, je nach Geschäftsmodell und Datenbedarf der jeweiligen Bank. Der Anteil der Attribute, die für das Meldewesen benötigt werden, macht ca. 60 % aus, also rund 1500 bis 2400 Attribute für alle Meldebereiche.

Betrachtet man den bisherigen Scope von BIRD liegt der aktuelle Umfang mit ca. 480 Terms und etwa 120 Entitäten für den Input Layer (IL) in der zu erwartenden Größenordnung.

Die definierten Transformationen und Validation Rules erscheinen mit rund 770 eher gering. In integrierten Datenhaushalten werden leicht 2000 bis 3000 benötigt. Berücksichtigt man allerdings, dass der Fokus auf der Transformation eines auf die Meldungen optimierten Eingangsdatenmodells in die einzelnen Reports liegt, relativiert sich der Eindruck. In integrierten Datenhaushalten fallen die meisten Transformationen zwischen den anliefernden Systemen und der Eingangsdatenschicht an, da hier über diverse Systeme und Datenmodelle hinweg harmonisiert und transformiert werden muss. Dieser Aufwand würde auch beim Einsatz von BIRD bei der Anlieferung in den Input Layer (IL) aus den Vorsystemen anfallen.

Das umfangreiche Fachwissen der aktuellen Version von BIRD kann jetzt schon als Benchmark der eigenen Lösung herangezogen werden. Das eigene Dateninventar kann einem ersten Vollständigkeitscheck unterworfen werden, das Glossar mit den Definitionen von BIRD abgeglichen und harmonisiert werden, und eigene DQ-Checks können um die Validation Rules von BIRD erweitert werden. Andererseits zeigt sich jedoch auch, dass durch die Anzahl der aktuell dokumentierten Terms der Weg bis zu einer vollständigen Abdeckung der Meldewesenanforderungen in BIRD noch weit ist.

Neben einer höheren Meldequalität bietet sich für Banken und Hersteller langfristig vor allem die Chance, den Abstimmungs- und IT-Aufwand deutlich zu reduzieren. Eine verbindliche Vorgabe von Interfaces und Datenmodell reduziert den Modellierungsaufwand. Die veröffentlichten Transformationen können schnell in eigene Implementierungskonzepte überführt werden und reduzieren damit den Aufwand in der IT- und Fachkonzeption.