Wissen · IReF & BIRD
Das BIRD-Datenmodell erklärt:
Vom Quellsystem zur Meldung
Input Layer, Enriched Input Layer, Output Layer, Transformation Rules in VTL – wie das BIRD-Modell aufgebaut ist und worauf es beim Mapping wirklich ankommt.
Das BIRD-Datenmodell (Banks' Integrated Reporting Dictionary, aktuell Data Model 6.7) ist ein logisches Datenmodell, das beschreibt, wie Banken ihre operativen Daten strukturieren sollten, um regulatorische Meldungen daraus abzuleiten. Es besteht aus drei Ebenen: dem Input Layer (granulare Daten aus den Quellsystemen), dem Enriched Input Layer (angereicherte Zwischenstufe) und dem Output Layer (Beschreibung der Meldeanforderungen). Die Transformation Rules (aktuell v3.1) verbinden die Ebenen – formuliert in der maschinenlesbaren Validation and Transformation Language (VTL).
Stand: Juni 2026 · BIRD Data Model 6.7 · Transformation Rules 3.1 (März 2026) · Quellen: EZB-BIRD-Portal · BIRD Metadata Manual (PDF)
Was BIRD ist – und was nicht
BIRD ist eine freiwillige Kooperationsinitiative der Zentralbanken des ESZB und der Geschäftsbanken; die EZB stellt die Plattform und koordiniert die Arbeit. Das Ergebnis ist kein Software-Produkt und keine Meldepflicht, sondern ein öffentlich verfügbares logisches Datenmodell samt Transformationsregeln – eine gemeinsame Sprache zwischen Banken, Softwareherstellern und Aufsehern.
Wichtig für die Einordnung: BIRD beschreibt die bankinterne Datenwelt (wie organisiere ich meine Daten, um Meldungen abzuleiten). Das künftig verbindliche Meldeschema für die statistischen Meldungen an die Zentralbanken definiert dagegen der IReF Collection Layer. Beide sind aufeinander abgestimmt – wer BIRD umsetzt, kann den Collection Layer mit deutlich weniger individueller Transformationslogik bedienen. Die Grundlagen zu beiden Rahmenwerken erklärt unsere Übersichtsseite IReF & BIRD.
Die drei Ebenen des BIRD-Modells
1. Input Layer (IL)
Beschreibt, welche granularen Daten in welcher Struktur aus den Quellsystemen (Kernbanksystem, Treasury, Kreditrisikosysteme) bereitgestellt werden müssen – redundanzfrei und einzelgeschäftsbasiert. Der Input Layer ist die Schicht, die jede Bank individuell befüllen muss: Hier findet das eigentliche Mapping der eigenen Systemlandschaft statt, und hier zeigen sich Datenlücken und Qualitätsprobleme zuerst.
2. Enriched Input Layer (EIL)
Eine Erweiterung des Input Layer: Per Derivation Rules werden abgeleitete Größen ergänzt (etwa der aktuelle Loan-to-Value), die mehrere Meldungen gemeinsam nutzen. Das vermeidet, dass dieselbe Ableitung für jede Meldung separat implementiert wird – ein zentraler Effizienzhebel des Modells.
3. Output Layer (OL)
Beschreibt die regulatorischen Meldeanforderungen selbst – also das, was am Ende bei Zentralbank oder Aufsicht ankommen soll. Der Output Layer erzeugt die Meldungen nicht; die Erzeugung übernehmen die Transformation Rules, die den Weg vom (Enriched) Input Layer zum Output Layer formal definieren.
Transformation Rules: fachliche Logik als Code
Die Transformation Rules sind das Herzstück von BIRD: formalisierte Regeln, die beschreiben, wie aus den Input-Daten die Meldepositionen entstehen. Sie sind in der Validation and Transformation Language (VTL) formuliert – einem Standard aus der SDMX-Welt, der sich maschinell verarbeiten und in ausführbaren Code übersetzen lässt.
Für Banken bedeutet das einen Paradigmenwechsel: Fachliche Meldelogik liegt nicht mehr nur in Fachkonzepten und individuellen ETL-Strecken, sondern in einer standardisierten, testbaren Form vor. Das aktuelle Release (Transformation Rules 3.1, März 2026) deckt AnaCredit-, FinRep- und Asset-Encumbrance-Logik ab. Dabei gibt es zwei Regeltypen: Derivation Rules berechnen abgeleitete Größen für den Enriched Input Layer, Generation Rules erzeugen daraus die Meldeanforderungen.
Worauf es beim Mapping in der Praxis ankommt
- 1. Scoping vor Mapping: Nicht jedes BIRD-Datenset ist für jede Bank relevant. Zuerst das eigene Produktportfolio auf die BIRD-Strukturen abbilden und den relevanten Modellausschnitt bestimmen.
- 2. Attribut-Lücken früh identifizieren: Viele geforderte Attribute existieren nicht in der nötigen Granularität in den Quellsystemen. Diese Lücken bestimmen den kritischen Pfad des Projekts – nicht die Meldesoftware.
- 3. Release-Prozess etablieren: BIRD wird laufend weiterentwickelt. Ein definierter Prozess für die Auswirkungsanalyse neuer Versionen verhindert, dass jedes Release ein Ad-hoc-Projekt auslöst.
- 4. Data Lineage von Anfang an: Wer das Mapping dokumentiert aufbaut (Quellfeld → IL → EIL → OL), erfüllt nicht nur BIRD, sondern schafft zugleich die Nachweisfähigkeit, die auch BCBS 239 verlangt.
Wann welcher Schritt ansteht, zeigt der IReF-Zeitplan bis 2031; zentrale Begriffe erklärt das IReF & BIRD Glossar.
Häufige Fragen zum BIRD-Datenmodell
Was ist der Unterschied zwischen Input Layer und Enriched Input Layer?
Der Input Layer (IL) beschreibt die Daten so, wie sie aus den Quellsystemen der Bank kommen sollen – granular und redundanzfrei. Der Enriched Input Layer (EIL) ist eine Erweiterung des Input Layer: Er ergänzt alle per Derivation Rules abgeleiteten Attribute (etwa den aktuellen Loan-to-Value), die für mehrere Meldungen gebraucht werden; aus dieser angereicherten Basis erzeugen die Generation Rules die Meldeanforderungen. Banken müssen primär den Input Layer aus ihren Quellsystemen befüllen.
In welcher Sprache sind die BIRD Transformation Rules geschrieben?
Die Transformation Rules sind in der Validation and Transformation Language (VTL) formuliert, einem Standard aus der SDMX-Welt. VTL ist maschinenlesbar und lässt sich in ausführbaren Code (z.B. SQL, Python) übersetzen – damit kann die fachliche Logik der Meldungserzeugung institutsübergreifend einheitlich implementiert und getestet werden.
Muss unsere Bank das komplette BIRD-Modell umsetzen?
Nein. BIRD ist freiwillig und flexibel implementierbar: Institute können eigene (Custom-)Input-Layer-Modelle aus dem logischen Datenmodell ableiten, und framework-spezifische Lineage-Exports zeigen, welche Teile des Input Layer für ein bestimmtes Meldeframework benötigt werden. In der Praxis empfiehlt sich eine Scoping-Phase, die das eigene Produktportfolio auf die BIRD-Datensets mappt – nicht jedes Attribut ist für jede Bank relevant.
Wie oft ändert sich das BIRD-Modell?
Die EZB veröffentlicht regelmäßig neue Releases – zuletzt das BIRD Data Model 6.7 zusammen mit den Transformation Rules 3.1 im März 2026. Institute sollten einen Prozess etablieren, der neue Releases systematisch auf Auswirkungen für das eigene Mapping prüft, statt jede Version ad hoc zu analysieren.
Wie weit ist Ihr Datenhaushalt vom BIRD Input Layer entfernt?
Wir vergleichen Ihr Data Dictionary mit dem aktuellen BIRD-Release und liefern eine priorisierte Lückenliste – die Basis für jede belastbare IReF-Roadmap.
