BIRD und IReF - Auf dem Weg zu einem Integrierten Reporting System
Photo by Sergio. R. Ortiz auf Unsplash.com, Download am 13.6.22
Aktuelle Entwicklungen
Die EZB (Europäische Zentralbank) und die EBA (European Banking Authority) beschäftigen sich aktuell parallel mit dem Thema eines integrierten Reportingsystems, in welchem die Finanzinstitute perspektivisch vergleichbare, einheitliche und redundanzfreie Daten in Form von Einzeldatensätzen und Meldeschemata im Rahmen der aufsichtsrechtlichen, abwicklungsseitigen und statistischen Meldevorschriften der Aufsicht bereitstellen. Neben einem aktuellen Überblick über die Thematik, erläutern wir in diesem Beitrag auch die konkrete Anwendung anhand von Beispielen.
Die EBA beschreibt das Ziel eines integrierten Reporting-Systems damit, den Meldeprozess für beide Seiten, also für die Institute sowie die Aufsichtsbehörden, zu vereinfachen und zu vereinheitlichen, sodass die Aufwände im besten Fall auf beiden Seiten reduziert und die Datenkonsistenz zwischen Instituten erhöht wird. Basis hierfür soll eine einheitliche “Sprache” für das Regulatory Reporting sein, hierzu sei auf den u.g. Abschnitt zum BIRD Ansatz (Banks‘ Integrated Reporting Dictionary) verwiesen. Der aktuelle Zustand des Regulatory Reportings wird von der EBA unter Nennung von negativen Entwicklungen der letzten Jahre wie folgt zusammengefasst:
- Verschiedene europäische Reportingansätze für unterschiedliche Datenerhebungszwecke (aufsichtsrechtliches Meldewesen, Abwicklung, Statistik).
- National unterschiedliche Datenanfragen.
- Unterschiedliche Adhoc-Anfragen einzelner Aufsichtsbehörden in den jeweiligen reporting frameworks.
- Dezentralisierter Ansatz der Fachdefinitionen und Datenerhebungen innerhalb der EU.
Die Kernidee des integrierten Reportingansatzes lautet: Daten werden nur einmal definiert und nur einmal gemeldet.
Abbildung 1 soll diesen Ansatz der EBA veranschaulichen, indem der aktuelle Meldeprozess dem Zielbild gegenübergestellt wird:
Abbildung 1 Meldeprozess im IST und im ZIEL-Bild
Die EBA untersucht derzeit unter Einbeziehung der Marktteilnehmer (Finanzinstitute, Aufsichtsbehörden) mögliche Optionen der Ausgestaltung dieses Integrierten Meldeansatzes und erhebt Vor- und Nachteile sowie deren Auswirkungen.
Im Kern werden drei Handlungsfelder aufgezeigt:
1. Etablierung eines einheitlichen Datenlexikons (siehe BIRD),
2. Platzierung eines zentralen Datenmeldepunktes für alle Institute und Aufsichtsbehörden,
3. Optimierung des Abstimmungs- und Koordinierungsprozesses zwischen Aufsichtsbehörden zur Vereinheitlichung des Datenerhebungsprozesses.
Die EZB bzw. das ESZB (Europäisches System der Zentralbanken) geht im Rahmen einer Kosten-Nutzen-Analyse (Stand: 12/2021) neben aggregierten Qualitätsbewertungen auch auf wesentliche technische Aspekte ein und konkretisiert damit bereits die o.g. Ziele, wie in der folgenden Auflistung beispielhaft zu entnehmen ist:
1. Ausweitung auf die Meldung von Krediten unterhalb der Grenze von 25 T€,
2. Sammlung von Wertpapierinvestmentdaten von Wertpapieren ohne ISIN,
3. Baseline Szenario zu bestimmten Einzelgeschäftsinformationen, die redundanzfrei von den Finanzinstituten gemeldet werden sollen (siehe BIRD),
4. Baseline Szenario zur Abgabe der Meldungen von Branchen im Euro-Raum nicht mehr direkt über die Branche, sondern auf Ebene der legalen Einheit/des Mutterinstituts.
Hierzu untersucht die EZB die möglichen positiven Auswirkungen auf die Institute und die Aufsichtsbehörden, indem sie diese Vorschläge eben diesen Finanzakteuren im Rahmen von Umfragen zur Bewertung einreicht und sie zu einem Dialog einlädt. Grundlage hierfür ist Art. 430c der CRR.
Vor dem Hintergrund der Aktivitäten von EZB und EBA wird die Implementierung der IReF-Berichterstattung (Integrated Reporting Framework), welche das statistische Meldewesen umfasst, unter Nutzung der BIRD-Methodik voraussichtlich bis Ende 2027 andauern. Der nächste Schritt ist, eine konkrete IReF-Regulatorik zu konzipieren, die dann öffentlich diskutiert werden soll. Sobald die IReF-Regulatorik feststeht, soll die entsprechende Berichterstattung ab 2024 implementiert werden. Abbildung 2 fasst die aktuelle Timeline zusammen:
Abbildung 2 Zeitplan und nächste Schritte zu BIRD und IReF
Aufbau von BIRD und Verwendung des SMCube
BIRD bildet die Basis zur Harmonisierung des Meldewesens. Durch ein integriertes Meldesystem haben die Aufsichtsbehörden ein gemeinsames Datenlexikon, eine einheitliche Datengrundlage und einen zentralisierten Prozess, welcher zur Vermeidung von Redundanzen führt. Zudem vereinfacht ein integriertes Meldesystem den Meldeprozess der Finanzinstitute und mindert langfristig ihre Kosten.
Die BIRD-Methodologie umfasst den BIRD-Prozess, welcher die vorgesehene Arbeitsweise vom Daten-Input bis zum Daten-Output (end-to-end) erklärt. Dieser Prozess beinhaltet die BIRD-Komponenten, die die Datenstrukturen und die Verbindungskomponenten ausmachen. In der folgenden Abbildung sind die grundlegenden Komponenten dargestellt:
Abbildung 3 BIRD Prozess und Methodik
Wie Abb. 3 zeigt, sind die zwei Ebenen des BIRD-Prozesses die logische Ebene (logical level) und die technische Ebene (technical level).
Zu der logischen Ebene gehören das Logical Data Model (LDM) und das Enriched Logical Data Model (ELDM). Diese Datenmodelle sind normalisierte Entity-Relatonship-Modelle (ERM), was bedeutet, dass sie in Form von Datenbankentitäten mit Tabellenstruktur vorliegen, die in Attribute aufgeteilt sind und in mehreren Relationen gemäß vordefinierten Normalisierungsregeln verbunden sind.
Das LDM ist die Basis für die Erzeugung der BIRD-Layer. Finanzinstitute können das Datenmodell nutzen, um eigene physische Implementierungen zu entwerfen oder logische Abhängigkeiten zu visualisieren. Abgeleitet aus den Daten des LDM wird das ELDM erzeugt. Hauptsächlich werden betriebswirtschaftliche Konzepte angewandt, wie beispielsweise die Klassifizierung der Unternehmensgröße, welche sich aus der Anzahl der MitarbeiterInnen und dem jährlichen Umsatz sowie der Bilanzsumme zusammensetzt.
Zu der technischen Ebene gehören Input Layer (IL), Enriched Input Layer (EIL), Reference Output Layer (ROL) und Non-Reference Output Layer (NROL). Die BIRD-Layer sind die Datenstruktur-Komponenten, die die Schritte vom Input zum Output beschreiben und basierend auf dem SMCube (Single Multidimensional Metadata Model) gebaut sind (zur Erläuterung des SMCube siehe unten). Genau wie LDM und ELDM (logische Ebene) stellen auch IL und EIL (technische Ebene) Entity-Relationship-Modelle dar, die jedoch weniger normalisiert sind. Zudem ist das LDM mit der IL und das ELDM mit der EIL inhaltlich gleich.
Die Datenstrukturen der IL und der EIL haben weniger Entitäten als das LDM bzw. das ELDM, was eine gute Eigenschaft für eine Schnittstelle zur Anbindung der internen IT-Systeme der Finanzinstitute darstellt. Es könnte daher der Startpunkt für die technische Implementierung des BIRD sein.
Sowohl die ROL als auch die NROL beschreiben die Meldedaten, z.B. für AnaCredit. Jedoch werden in der ROL die regulatorischen Berichtsanforderungen mithilfe von „Reference-Codes“, die sich aus dem BIRD-Lexikon ableiten, beschrieben. Dasselbe wird in der NROL beschrieben, aber mit der Nutzung von „Non-Reference-Codes“ aus dem EBA DPM (Data Point Model). Die „Reference-Codes“ werden von allen BIRD-Layers, außer der NROL, als einheitliche Sprache genutzt. Die NROL nutzt die Konzepte und Codes, die nach den jeweiligen regulatorischen Berichtsanforderungen angepasst werden. Die verschiedenen NROL werden immer aus einer ROL erzeugt, wodurch sichergestellt wird, dass die BIRD-Layer semantisch integriert sind.
Die Verbindungskomponenten haben die Aufgabe, mithilfe von logischen und semantischen Transformationsregeln sowie Mappings („Forward Engineering“) eine Verbindung zwischen den beiden Ebenen herzustellen und die BIRD-Layer miteinander zu verbinden. Hinzu kommen weitere Validierungskomponenten wie betriebswirtschaftliche und strukturelle Validierungsregeln, welche die Konsistenz und Qualität der Daten sicherstellen.
Abbildung 4 BIRD Komponenten
Jede BIRD-Layer ist mit dem SMCube Information Model aufgebaut. Dies bedeutet, dass die Daten als Tabellen mit Zeilen und Spalten aufgebaut sind und als mehrdimensionale Würfel strukturiert werden. Der SMCube kann mehr als drei Dimensionen haben.
Abbildung 5 Visualisierung des SMCube
Um einen tieferen Einblick zur SMCube-Methodik zu erhalten, wird anhand eines Beispiels näher erklärt, wie sie aufgebaut ist. Es wird im Beispiel angenommen, dass ein Finanzinstitut die SMCube-Methodik nutzt und Datensätze in einer Tabelle der Sicherheiten von bestimmten Finanzinstrumenten eintragen will, was wie folgt aussehen könnte:
Abbildung 6 SMCube Datenbeispiel
Nach der SMCube-Methodik werden die Spalten der Tabellen Variablen genannt und sind unabhängig vom Würfel definiert. Das hat den Vorteil, dass Variablen einmal definiert werden und in mehreren Würfeln enthalten sein können. Jede Variable wird in einer Domäne definiert, die die erlaubten Werte der Variable angibt. Domänen können Aufzählungen sein, wenn sie eine Liste mit erlaubten Werten aufweisen. Wenn Domänen einen Datentyp haben, werden sie als Nicht-Aufzählungen definiert. Beispiele für Nicht-Aufzählungen wären „ISIN“ (String Domäne), „Vertragsbeginn“ (Datum Domäne) oder „Fair Value“ (Monetäre Domäne). Bei den Aufzählungen ist beispielsweise die „Art der Sicherheit“ zu finden, da sie eine Liste mit vordefinierten Werten hat. Jedoch kann eine Variable unterschiedliche erlaubte Datensätze haben. Zum Beispiel könnte sich auch die Liste der Variable „Art der Sicherheit“ vergrößern, wenn sich die Anzahl der Finanzinstrumente vergrößern würde. Dasselbe gilt bei Variablen, die als Nicht-Aufzählung definiert sind. Im Kontext der Sicherheiten würde man nur positive Werte bei der Variablen „Fair Value“ zulassen.
Ein relevanter Aspekt bei der Struktur der Datensätze ist der Identifier des Datensatzes. Dieser kann eindeutig (unique) sein, was bei der Variablen „ISIN“ bedeuten würde, dass nur ein Datensatz einen bestimmten ISIN-Code haben darf. Wenn es aber im Kontext der Sicherheiten mehrere Währungen gibt, kann es sein, dass dieselbe „ISIN“ mehrmals mit verschiedenen Währungen auftreten kann.
Nach der SMCube-Methodik nehmen die Variablen, die als Identifier fungieren, eine Dimensions-Rolle ein. Wenn man annimmt, dass „ISIN“ die einzige Variable mit einer Dimensions-Rolle wäre, erhielten die restlichen Variablen eine andere Rolle abhängig davon, zu welchen Variablen sie Informationen hinzufügen. Wenn die „Währung“ eine Rolle zugewiesen bekommen soll, gibt es zwei Interpretationsmöglichkeiten: Die Variable „Währung“ fügt Informationen zu der Variablen „ISIN“ hinzu, welche eine Dimensions-Rolle hat, und würde daher die Observationswert-Rolle einnehmen. Variablen die nur Informationen zu einer Variable, aber nicht zu einer Dimension, hinzufügen, nehmen die Attribut-Rolle ein. Zudem kann eine Variable verschiedene Rollen in verschiedenen Datensätzen einnehmen.
Die Zielsetzung von BIRD ist es, die statistischen und aufsichtsrechtlichen Anforderungen wie AnaCredit, Securities Holdings Statistics (SHS), Balance Sheet Items (BSI) und Monetary Financial Institutions Interest Rate Statistics (MIR) zu vereinheitlichen. Banken begegnen stets der Herausforderung, für jede aufsichtsrechtliche Meldung andere Berichtsanforderungen beachten zu müssen und dieselben Informationen für verschiedene Meldungen bereitzuhalten. Die u.s. Abbildung zeigt diese Problematik beispielhaft für die Angaben zu den Sicherheiten bei SHS und Centralised Securities Database (CSDB) auf. Die Spalten der verschiedenen Meldungen sind unterschiedlich benannt und formatiert. Beispielsweise werden für die ISIN in der SHS-Meldung zwei Spalten und in der CSDB-Meldung nur eine Spalte benötigt. Diese Vorgehensweise ist redundant und führt zu einem zeitlichen Mehraufwand.
Abbildung 7 Datenbeispiel ohne semantische Integration
In der folgenden Abbildung wird dargestellt, wie die zukünftige Situation der Banken bzgl. der aufbereiteten Meldedatensätze am Beispiel SHS und CSDB im Rahmen von BIRD und der darunterliegenden SMCube-Methodik aussehen könnte. Mit dem Referenz-Code des BIRD-Ansatzes werden die Daten semantisch integriert. Die Spaltennamen sind nun für beide Meldungen gleich. Deutlich zu erkennen ist, dass ohne Verlust von Informationen eine vereinheitlichte Datengrundlage für verschiedene Meldungen entsteht und daher dieselben Informationen nicht wiederholt für eine andere Meldung aufbereitet und eingetragen werden müssen.
Abbildung 8 Datenbeispiel mit semantischer Integration
Herausforderungen
Finanzinstitute stehen ebenso wie die Aufsichtsbehörden vor erheblichen Veränderungen, was ihre Meldeprozesse angeht. Seit Jahren ist zu beobachten, dass Banken und Aufsicht mit zunehmend redundanten und uneinheitlichen Daten arbeiten, sie erheben, auswerten und analysieren. Verschiedene Meldeanforderungen referenzieren auf ähnliche oder gleiche Datenerhebungen. Jedes Institut meldet die vermeintlich gleiche Datenanforderung mit teils unterschiedlichen Interpretationen und Konventionen. Aufsichtsbehörden bekommen unzählige, mittlerweile durchaus komplexe Meldeschemata zugeliefert und suchen sich die für sie relevante Information mit erheblichem Aufwand heraus. Institute melden über die Zeit immer mehr und zunehmend aufwändige Meldetemplates und versuchen, mit Hilfe von Cross-Validierungen Konsistenz in ihren Daten zu erhalten. Überleitungsrechnungen offenbaren aufwändig zu behebende Differenzen in den jeweiligen Reporting Frameworks.
Mit der Entwicklung hin zu einem Integrierten Reporting System und einem einheitlichen und abgestimmten Meldeprozess könnten diese aktuellen Fehlentwicklungen behoben werden. Dazu ist es jedoch erforderlich, dass neben den notwendigen Veränderungen in den Aufsichtsbehörden vor allem die Finanzinstitute die vorgesehenen Vereinheitlichungen in den Datenmodellen angehen und im Rahmen von BIRD ihre Meldedaten semantisch, syntaktisch und infrastrukturell auf Basis der Vorgaben überarbeiten, um die relevanten Meldedaten der Aufsicht so anzuliefern, dass damit Meldungen auf Seiten der Behörden redundanzfrei, einheitlich und konsistent erstellt werden können.
Mit dem Finbridge-Erfolgsmodell zum Ziel
Finbridge unterstützt Sie gerne bei der Umsetzung der Anforderungen zum BIRD Datenmodell und auf dem Weg hin zu einem Integrierten Reporting-Framework. Unsere Expertinnen und Experten haben teils selbst bei der Bundesbank, dem SRB (Single Resolution Board) und Anbietern von Meldewesen Software gearbeitet. Sie sind am Markt in Vorstudien und Umsetzungsprojekten im Kontext der Einführung von Datenmodellen und Datenhaushalten sowie im Aufsichtsrecht, der statistischen Meldungen und der Abwicklungsplanung mit langjähriger Erfahrung aktiv und können Sie bei all den Herausforderungen mit fundierter Erfahrung und Expertise wertstiftend unterstützen. Aufgrund unseres umfangreichen Fachwissens in der Gesamtbanksteuerung, gekoppelt mit weitreichender umsetzungsorientierter Praxiserfahrung rund um das Regulatory Reporting, können wir flexibel auf Ihre Wünsche und Institutsspezifika eingehen und begleiten Sie bis zur Erfüllung der Erwartungen der Aufsichtsbehörden.
Sie haben Fragen zu den fachlichen und technischen Änderungen im Detail? Unsere Finbridge-Experten stehen Ihnen mit ihrem fachlichen Know-How bei der Planung und Umsetzung gerne zur Seite.
