Die Banken im Europäischen Wirtschaftsraum geben nach einer Schätzung der Europäischen Bankenaufsicht (EBA) aus 2021 insgesamt 11,2 Milliarden Euro pro Jahr für das umfangreiche Reporting an die Aufsichtsbehörden aus. Diese immense Summe basiert auch darauf, dass Europas Banken heute ähnliche Informationen mehrfach, in unterschiedlichen Formaten, Granularitäten und Prozessen an die Aufsicht melden. Die EBA hat daher in ihrem Report 25 Maßnahmen zur Kostenreduktion vorgeschlagen, die von Aufsichtsbehörden und Zentralbanken umgesetzt werden sollen, um die Banken zu entlasten. Konsultationen der Aufsicht mit den Banken haben gezeigt, dass die langfristigen Vorteile eines besser aufeinander abgestimmten Meldewesens die kurzfristigen Implementierungskosten überwiegen.
Die Europäische Kommission hat in ihrem diesjährigen Bericht zur Wettbewerbsfähigkeit des Bankensektors und des Gemeinsamen Marktes Stellung zum Umsetzungsstand dieser Maßnahmen genommen. Während ein Großteil der kurz- und mittelfristig wirksamen Maßnahmen seitens der Aufsicht schon umgesetzt ist, wird die Maßnahme mit langfristigem Wirkungshorizont erst demnächst Fahrt aufnehmen. Durch ein Integrated Reporting Framework (IReF) wollen Europäische Zentralbank und nationale Notenbanken das statistische Meldewesen für Banken im Euroraum deutlich vereinfachen. IReF verspricht somit eine Harmonisierung und Entlastung der Banken in Europa in ihrem Meldewesen. Kurzfristig verlangt es aber auch erhebliche fachliche, technische und organisatorische Veränderungen auf Seiten der Banken.
Viele Banken haben zuletzt vor etwa zehn Jahren große Veränderungen an ihrer Daten- und Reporting-Architektur vorgenommen. Der Anlass damals war die Umsetzung von BCBS 239 in Verbindung mit dem für Banken wichtigen IFRS 9-Standard. Wird die ähnlich klingende, wiederum vierbuchstabige Abkürzung IReF die Datenarchitektur von Banken und anderen Finanzdienstleistern möglicherweise erneut fundamental verändern und sind hiermit ähnlich lange und teure Projekte verbunden? Oder können Finanzdienstleister die Umsetzung von IReF so gestalten, dass durch Investitionen in eine tragfähige Datenarchitektur nicht nur die regulatorische Pflicht erfüllt wird, sondern zugleich eine nachhaltige Grundlage für Reporting, Risikosteuerung und Finance entsteht?
Dieser Beitrag nimmt IReF zum Anlass, einen Blick auf die in den damaligen Projekten umgesetzte Architektur zu werfen und ein Zielbild zu skizzieren, wohin sich mit IReF die Datenarchitektur der Banken weiterentwickeln wird. IReF kann für Banken der Anlass sein, die mit BCBS 239 begonnenen Integrationsbestrebungen über das regulatorische Reporting hinaus konsequent fortzuführen und als Katalysator für eine integrierte, wiederverwendbare und qualitätsgesicherte Datenarchitektur im Finanzsektor zu verstehen.
Im folgenden Abschnitt werden zunächst die Regulierungsbestrebungen rund um IReF geschildert. Anschließend wird die für BCBS 239 eingeführte integrierte Risiko- und Finanzarchitektur skizziert und Herausforderungen abgeleitet, die sich den Banken nun stellen. Auf Basis der Medallion-Architektur für Daten wird ein möglicher Lösungsansatz zur Bewältigung dieser Herausforderungen skizziert. Der Beitrag schließt mit Ansatzpunkten und Empfehlungen, wie Banken die Zeit bis zur Einführung von IReF effektiv nutzen können.
Aktueller Sachstand von IReF
Das Eurosystem unter der Federführung der Europäischen Zentralbank (EZB) will mit dem Integrated Reporting Framework (IReF) die statistischen Meldeanforderungen für Banken im Euroraum in einem einheitlichen, unmittelbar anwendbaren Rahmen bündeln. Die EZB arbeitet dazu mit den nationalen Zentralbanken der EU-Länder zusammen. Standardisiert werden sollen nicht nur die Inhalte, sondern auch Datenmodelle sowie Erhebungs- und Transformationsprozesse. Gemeinsam mit den nationalen Zentralbanken sollen auch die statistischen Anforderungen harmonisiert, Überschneidungen und Redundanzen abgebaut, die Datenqualität erhöht und insbesondere grenzüberschreitend tätige Institute entlastet werden.
In der ersten Ausbaustufe konzentriert sich IReF auf statistische Anforderungen zu Bilanzpositionen und Zinssätzen, Wertpapierbeständen sowie granularen Kredit- und Kreditrisikodaten, wie sie heute z. B. im Rahmen der Regulierung zu Analytical Credit Datasets (AnaCredit) gemeldet werden. Zahlungsverkehrs- und Geldmarktstatistiken stehen zunächst nicht im Fokus. Nationale Meldeanforderungen sollen berücksichtigt werden, soweit sie für die in IReF einbezogenen Erhebungsrahmen relevant sind.
Nach der eingangs erwähnten, 2020 begonnenen Kosten-Nutzen-Analyse der Europäischen Bankenaufsicht (EBA) befindet sich IReF nun in der Ausgestaltung der rechtlichen, fachlichen und technischen Umsetzung. Die EZB kündigte im Juni 2026 an, einen umfassenden Implementierungsplan mit zusätzlichen methodischen und technischen Details vorzubereiten. Dieser soll auch erläutern, wie sich die nationalen Erhebungsrahmen durch IReF verändern.
Die Bankenbranche soll wesentliche Informationen zu den Meldeanforderungen vor der öffentlichen Konsultation zum Entwurf der IReF-Verordnung erhalten, die für die zweite Jahreshälfte 2027 vorgesehen ist. Im zweiten Quartal 2030 soll eine einjährige Pilotphase beginnen, in der Meldepflichtige und Eurosystem die fachliche, technische und operative Umsetzbarkeit testen. Der erste offizielle Meldetermin ist für das zweite Quartal 2031 geplant. Daran schließt sich zunächst eine einjährige Parallelphase an, in der die bisherigen statistischen Meldungen im IReF-Scope neben IReF fortgeführt werden. Der aktuelle Zeitplan gemäß Abbildung 1 steht ausdrücklich unter dem Vorbehalt der Verabschiedung der IReF-Verordnung.
Dieser Zeitplan schafft einen mehrjährigen Vorlauf, aber keine stabile fachliche Ziellinie: Umfang, Detailanforderungen und nationale Übergänge werden bis zur Konsultation und zum Erlass der Verordnung weiter konkretisiert. Institute können aber schon jetzt passende Architekturentscheidungen, Dateninventur, Begriffs- und Schlüsselharmonisierung, Lineage sowie die Verzahnung mit laufenden Risiko-, Finance- und Cloud-Programmen vorantreiben. Die eigentliche IReF-Ausleitung sollte dagegen eng an den fortschreitenden regulatorischen Spezifikationen versioniert werden.
Damit IReF Wirkung entfalten kann, ist ein einheitlicher Datenkatalog als Fundament des regulatorischen und statistischen Meldewesens notwendig. Nur mit standardisierten Definitionen werden Daten institutsübergreifend vergleichbar und können insgesamt für eine aggregierte Sicht im Bankensystem genutzt werden. Zu diesem Zweck wurde das Joint Bank Reporting Committee (JBRC) aufgesetzt. Es bildet den übergreifenden Governance-Rahmen für die schrittweise semantische Integration statistischer, aufsichtlicher und abwicklungsbezogener Anforderungen. Als Mitglieder im JBRC sind neben der Europäischen Zentralbank und Europäischen Bankenaufsicht auch die nationalen Zentralbanken und Aufsichtsbehörden vertreten.
Das einheitliche Datenwörterbuch, das Banks’ Integrated Reporting Dictionary (BIRD), wird in einer freiwilligen, gemeinsam von Zentralbanken und Geschäftsbanken entwickelten Initiative erstellt. Es beschreibt Begriffe redundanzarm und stellt Datenmodelle sowie Transformationsregeln bereit, mit denen regulatorische Meldungen aus bankinternen Daten erzeugt werden können. IReF gehört zu den ersten zentralen Anwendungsfeldern dieses Datenwörterbuchs.
Heutige Datenarchitektur und Herausforderungen
Welche Herausforderungen bringt die Einführung einer neuen Verordnung mit möglicherweise tiefgreifenden Veränderungen in der Datenarchitektur nun aber tatsächlich für die Banken mit sich? Hierzu lohnt sich ein Blick auf die Datenarchitektur, wie sie im Zuge der BCBS 239-Einführung von vielen Banken implementiert worden ist.
BCBS 239 als Auslöser grundlegender Investitionen in die Datenarchitektur
Mit der Umsetzung der Anforderungen aus BCBS 239 zu den Grundsätzen für die effektive Aggregation von Risikodaten und die Risikoberichterstattung haben zahlreiche Banken seit Mitte der 2010er-Jahre ihre historisch gewachsenen Datenarchitekturen grundlegend modernisiert. Auslöser hierfür waren vor allem Defizite bei der Verfügbarkeit, Qualität und Aggregation von Risikodaten, die während der Finanzkrise 2008 deutlich geworden waren. Die 2013 veröffentlichten Grundsätze des Basler Ausschusses für Bankenaufsicht (BCBS) verlangen, dass Banken ihre Risiken vollständig, konsistent, zeitnah und auch unter Stressbedingungen aggregieren und berichten können. Dazu gehören eine geeignete Datenarchitektur, weitgehend automatisierte Datenverarbeitung, eindeutige Datenverantwortlichkeiten und die Nachvollziehbarkeit der Daten vom Ursprung bis zur Berichterstattung.
Die Umsetzung erforderte vielfach mehrjährige Transformationsprogramme mit erheblichen Investitionen in die IT- und Dateninfrastruktur. Im Mittelpunkt stand die Ablösung fragmentierter, überwiegend für einzelne Fachbereiche entwickelter Datenversorgungsstrecken durch integrierte Datenarchitekturen. Typische Lösungsansätze waren zentrale Datenintegrationsschichten oder Data-Warehouse-Plattformen, in denen Informationen aus unterschiedlichen operativen Systemen zusammengeführt, harmonisiert, qualitätsgesichert und für nachgelagerte Anwendungen und spezifische Berichtsformate bereitgestellt werden. Ergänzend etablierten die Banken unternehmensweite Datenmodelle, Datenqualitätskontrollen und Data-Governance-Prozesse. Tabelle 1 stellt die beiden Regulierungen von BCBS 239 und IReF gegenüber.
| Dimension | BCBS 239 – bestehende Risk & Finance-Integration | IReF – zukünftige Anforderungen |
|---|---|---|
| Primäres Ziel | Verlässliche Risikodatenaggregation und Risikoreporting | Harmonisiertes statistisches Meldewesen im Euroraum |
| Datenintegration | Integration vor allem für interne und aufsichtsrechtliche Steuerungszwecke | Einheitliche Datenbasis für mehrere bisher getrennte statistische Meldeanforderungen |
| Datenmodell | Häufig bankspezifisches, historisch entwickeltes Datenmodell | Standardisierte regulatorische Datendefinitionen und Strukturen |
| Granularität | Oft Mischung aus Einzelgeschäfts- und aggregierten Daten | Höherer Stellenwert granularer Einzelgeschäftsdaten, abhängig von der Meldeanforderung |
| Verarbeitung | Teilweise eigenständige Datenstrecken für einzelne Berichte | Wiederverwendbare Daten und standardisierte Ableitungslogiken |
| Veränderbarkeit | Häufig auf bestehende Berichtsanforderungen optimiert | Flexible Anpassung an neue Datenfelder, Definitionen und Meldeanforderungen |
Bei zahlreichen größeren Banken entstanden im Zuge der BCBS 239-Umsetzung zentrale Datenintegrationsschichten, häufig als Bestandteil einer integrierten Risiko- und Finanzarchitektur (IRFA). Die damals durchgeführten Projekte haben damit wesentliche Voraussetzungen für einen integrierten Datenhaushalt geschaffen, ohne zwangsläufig die Komplexität der zugrunde liegenden Haupt- und Nebenbuchsysteme zu beseitigen. In welchem Umfang daraus ein langfristiger Modernisierungsbedarf resultiert, hängt insbesondere von der Zahl der weiterhin bestehenden Buchungsplattformen, der Redundanz ihrer Datenhaltung sowie dem Aufwand für die Abstimmung zwischen Risiko- und Finanzdaten ab.
Die durch die IRFA-Transformationsprojekte geschaffene Datenarchitektur der Banken weist regelmäßig eine zentrale Datenintegrationsschicht auf. Der Aufbau eines solchen Data Warehouses begann typischerweise in der ersten Hälfte der 2010er-Jahre und wurde durch die ab 2016 sukzessive erweiterten aufsichtsrechtlichen Anforderungen begleitet. Widersprüchliche Datenbestände und redundante Aufbereitungsprozesse wurden reduziert und eine konsistente Datenversorgung unterschiedlicher Steuerungs- und Reportinganwendungen, wie z. B. IFRS 9, auf Basis dieses Datenintegrations-Layers ermöglicht. Einmal entwickelte Datenanbindungen konnten dadurch von mehreren Anwendungen wiederverwendet werden.
Ob die damit angestrebte Integration tatsächlich erreicht wurde, hängt allerdings davon ab, in welchem Umfang parallele Datenbestände, individuelle Schnittstellen und fachbereichsspezifische Verarbeitungslogiken tatsächlich dauerhaft reduziert wurden. Zudem war die Einführung der IRFA überwiegend an bestehenden Datenstrecken und spezifischen Berichten orientiert. Nicht immer gibt es fachlich harmonisierte Datendefinitionen und Bewertungslogiken auf einer granularen Ebene über Statistik, Risiko und Finanzen hinweg.
Herausforderungen durch IReF
Eine Lehre aus den IRFA-Projekten ist daher, dass eine ausschließlich an einzelnen Berichtsanforderungen orientierte Integration bestehende Silos fortschreiben oder neue schaffen kann. Nachhaltig wird die Umsetzung erst, wenn gemeinsame Datenprodukte und wiederverwendbare Regeln in der Kernarchitektur verankert werden. Wird die Einführung von IReF in diesem Sinne verstanden, verbleiben große Herausforderungen an die Banken.
Während BCBS 239 die interne Risikoaggregation und -berichterstattung in den Fokus nimmt, zielt IReF primär auf standardisierte externe statistische Meldungen auf europäischer Ebene ab. IReF erhöht insbesondere die Anforderungen an die einheitliche, granulare und für unterschiedliche Meldezwecke wiederverwendbare Datenbereitstellung. Einen Vorgeschmack auf dieses Vorgehen bietet die bereits heute geltende Regulierung zu AnaCredit. Hier werden nicht nur aggregierte Risiko- und Finanzdaten von den Banken verlangt, sondern sie müssen Kredite an juristische Personen auf Einzelkreditebene melden. Ein solcher Granularitätsgrad stellt erhöhte Anforderungen sowohl an Data Lineage als auch an die Datenqualität. Die Datenherkunft muss eine lückenlose Rückverfolgbarkeit vom gemeldeten Wert bis in die operativen Quellsysteme erlauben. Bei der Datenqualität müssen Kontrollen näher an die Datenentstehung rücken. Nachgelagerte Korrekturen im Meldewesen reichen nicht aus.
Zudem müssen Banken europaweit die gleichen Datendefinitionen verwenden und bei der Meldung berücksichtigen. Die Harmonisierung sollte sich an den regulatorischen Datendefinitionen orientieren und eine eindeutige Abbildung auf das IReF-Datenmodell ermöglichen. BIRD kann hierfür als fachliches Referenzmodell genutzt werden. Dazu sind Prozesse und Verantwortlichkeiten rund um das Datenmanagement weiter zu schärfen und ggf. Stammdaten, Datenschlüssel und Attribute in den Kernsystemen als notwendige fachliche Grundlage zu pflegen.
Technisch erschwert die historisch und institutsspezifisch gewachsene IT mit zahlreichen Datenextrakten und Schattenhaushalten trotz Aufbau einer zentralen Datenintegration die weitere Transformation. Der vorhandene Modernisierungsbedarf in der Banken-IT kann durch technische Neuerungen, wie z. B. der Verwendung eines Data Lakehouses, sinnvoll ergänzt werden, um den Veränderungsimpuls von IReF bei der logischen Datenarchitektur bestmöglich zu unterstützen. Für eine erfolgreiche Transition müssen laufende und geplante Datenarchitektur-Projekte der Banken orchestriert werden.
Tabelle 2 fasst die Herausforderungen zur Einführung von IReF, die sich typischerweise den Banken stellen, zusammen.
| Herausforderung | Typische Ausgangssituation nach BCBS 239 | Zusätzlicher Handlungsbedarf durch IReF |
|---|---|---|
| 1. Granularität | Daten bereits zentralisiert, aber teilweise voraggregiert oder auf bestehende Reports zugeschnitten | Erhalt und Nutzung von Einzelgeschäftsinformationen einschließlich Historie und Stichtagsbezug |
| 2. Fachliche Semantik | Gemeinsame Datenbasis, jedoch bankspezifische Begriffe und fachbereichsspezifische Transformationen | Eindeutige Zuordnung zu IReF-Datendefinitionen und kompatibles Mapping zu BIRD |
| 3. Datenqualität | Qualitätskontrollen häufig für bestehende Berichte oder Datenstrecken definiert | Einheitliche, möglichst quellsystemnahe Datenqualitätsregeln und nachvollziehbare Korrekturen |
| 4. Mehrfachnutzung | Zentrale Integration, aber weiterhin getrennte Aufbereitung für Risk, Finance und Meldewesen | Wiederverwendbare harmonisierte Datenobjekte für mehrere regulatorische und interne Anwendungsfälle |
| 5. Veränderbarkeit | Teilweise komplexe ETL-Strecken und fest verdrahtete Datenmodelle und Datenstrecken | Änderbare, versionierte Datenmodelle und fachliche Transformationsregeln; modulare Anpassungen |
| 6. Technische Basis | Datenintegrationsschicht durch Data Warehouse abgebildet; strukturierte Daten für bekannte Anforderungen | Verbesserung von Skalierbarkeit und Flexibilität, ggf. mittels Modernisierung durch Data Lakehouse |
Als Zwischenfazit lässt sich somit festhalten, dass es trotz hoher Vorinvestitionen ein noch nicht ausgeschöpftes Integrationspotential gibt. Die BCBS 239-Projekte in die Integrierte Risiko- und Finanzarchitektur haben zentrale Datenintegrationsschichten geschaffen und eine gute Ausgangsbasis gelegt. IReF verschiebt allerdings die Anforderungen von der konsistenten Berichtsversorgung zur standardisierten, granularen Datenbereitstellung. Mit BIRD und dem IReF-Datenmodell entstehen gemeinsame fachliche Referenzstrukturen. Banken müssen deshalb vor allem prüfen, inwieweit ihre vorhandenen Datenmodelle und Datenintegrationsschichten diese Anforderungen erfüllen können. Unterschiedliche fachliche Definitionen, fehlende Granularität der Daten, redundante Datentransformationen und historisch gewachsene, am jeweiligen Verwendungszweck orientierte Reporting-Silos lassen erheblichen Handlungsbedarf vermuten.
Zielbild einer tragfähigen integrierten Datenarchitektur
Wie können Banken diesen Handlungsbedarf am besten adressieren? Idealerweise ist konzeptionell zunächst ein Zielbild für solch ein granulares Meldewesen zu erarbeiten und zwischen betroffenen Fachbereichen und IT abzustimmen. Mit diesem Zielbild einer tragfähigen integrierten Datenarchitektur wird der Rahmen für Datenmanagement, Prozesse, Organisation und Steuerung sowie für die IT-Architektur festgelegt.
In diesem Abschnitt werden exemplarisch für diese konzeptionellen Arbeiten zwei Aspekte behandelt: Mit der sogenannten Medallion-Architektur wird zum einen ein geeignetes Datenarchitekturkonzept vorgestellt, das für die erforderliche Weiterentwicklung des Datenmodells und der Transformationslogiken hilfreich sein kann. Zum anderen wird mit dem Data Lakehouse-Ansatz eine technische Basis skizziert, die diesen fachlichen Architekturansatz sinnvoll unterstützen kann.
Medallion-Architektur
Die Medallion-Architektur gliedert die Datenverarbeitung in aufeinander aufbauende Qualitätsstufen. Sie trennt die quellnahe Datenhaltung, die bankweite fachliche Harmonisierung und die zweckgerichtete Bereitstellung von Datenprodukten. Damit schafft sie die Voraussetzungen für eine konsistente Mehrfachnutzung granularer Bankdaten für statistische Meldungen zu IReF sowie eine flexiblere Umsetzung künftiger regulatorischer Anforderungen.
Die Medallion-Architektur ist keine grundsätzlich neue Erfindung der Datenintegration, sondern eine moderne Strukturierung und technische Umsetzung bewährter Data-Warehouse-Prinzipien. Das bedeutet, dass Banken mit ihren BCBS 239-Architekturen bereits wichtige Grundlagen gelegt haben und die Anforderungen von IReF möglicherweise auch mittels einer bestehenden Datenintegrationsschicht realisieren könnten. Aus einer bereits vorhandenen zentralen Datenintegrationsschicht heraus bietet die Medallion-Architektur allerdings einen überzeugenden fachlichen Weiterentwicklungsansatz. Mit ihrem mehrstufigen Datenarchitekturkonzept werden Daten über eine Bronze-, Silber- und Gold-Schicht schrittweise qualitätsgesichert, harmonisiert und für unterschiedliche Anwendungszwecke aufbereitet.
Abbildung 2 skizziert die drei Ebenen der Medallion-Datenarchitektur. Den drei Ebenen kommen dabei unterschiedliche Aufgaben zu:
- Die Bronze-Schicht bewahrt die ursprünglichen Daten in ihrer Quellstruktur und mit den relevanten zeitlichen Informationen. Das ist besonders für regulatorische Meldungen wichtig: Frühere Datenbestände müssen bei Rückfragen, Korrekturen oder geänderten fachlichen Regeln nachvollzogen werden können. Datenbestände werden so historisiert und revisionssicher aufgenommen. In der Praxis bedeutet dies, dass eine weitgehend unveränderte, ggf. technisch normalisierte Übernahme der relevanten Daten aus den Nebenbüchern zum Kredit- und Wertpapiergeschäft sowie die zugehörigen Kunden- und weitere Referenzdaten erfolgt. Lieferzeitpunkt, Herkunft, Version und technische Qualitätsmerkmale werden hierbei als wichtige Metadaten miterfasst. Der Nutzen für die Implementierung von IReF besteht darin, dass eine belastbare Auditierbarkeit aufgrund von reproduzierbaren Meldeständen möglich ist.
- Die Silber-Schicht veredelt und harmonisiert diese Daten. Es entstehen einheitliche Geschäftspartner-, Vertrags-, Instrumenten- und Transaktionsdaten, die von unterschiedlichen Fachbereichen genutzt werden können. Anders als heute in der IRFA-Architektur häufig üblich, sollten die fachlichen Definitionen möglichst unabhängig von spezifischen Ausleitungsstrecken oder einzelnen Meldeformaten sein. In der Praxis bedeutet dies, dass eine Vereinheitlichung von Schlüsseln, Datenformaten, Zeitbezügen und fachlichen Definitionen gemäß BIRD erfolgt, so dass die Daten den logischen Anforderungen und Transformationsregeln von IReF gerecht werden. Der Nutzen für IReF entsteht durch eine wiederverwendbare, redundanzarme Datenbasis jenseits einzelner Meldeformulare.
- In der Gold-Schicht entstehen konkrete regulatorische und analytische Datenprodukte, wie sie in der ersten Stufe von IReF für die statistischen Meldungen benötigt werden. Perspektivisch können aber auch weitere bestehende aufsichtsrechtliche Meldungen oder das interne Management-Reporting mit diesen Datenprodukten konsistent versorgt werden. Die benötigten Transformationen erfolgen auf Basis der zuvor harmonisierten Daten und werden möglichst zentral in einem Datenkatalog verwaltet, versioniert und wiederverwendet. Damit wird vermieden, dass jede Anwendung erneut aus operativen Daten ihre eigene fachliche Interpretation erzeugt. Durch diese Entkopplung regulatorischer Ausleitungen von operativen Quellsystemen ergibt sich der Nutzen für IReF vor allem durch die schnellere Anpassbarkeit bei Änderungen und der kontrollierten Mehrfachnutzung.
Ein Beispiel macht die Vorteile einer solchen Trennung deutlich: Banken nutzen heute für Bilanzstatistik, AnaCredit und interne Risikoberichte häufig unterschiedliche Ableitungen von Kreditvertragsdaten. Ändert sich ein Datenfeld im Kreditkernsystem, müssen gegebenenfalls mehrere Datenstrecken angepasst und getestet werden. In einer stärker harmonisierten Architektur wird die Änderung möglichst einmalig in der Datenübernahme oder Silber-Schicht berücksichtigt. Die darauf aufbauenden Datenprodukte können die konsistenten Vertragsinformationen weiterverwenden, sofern die fachlichen Definitionen übereinstimmen und die Datenprodukte keine abweichenden Anforderungen enthalten.
Die Medallion-Architektur ist einer vorhandenen Datenintegrationsschicht aus den BCBS 239-Projekten aber nicht allein deshalb überlegen, weil sie Bronze, Silber und Gold unterscheidet. Der zusätzliche Nutzen entsteht vor allem durch die konsequente logische Unterscheidung der drei Schichten und der Aufgabe, die die jeweilige Schicht erfüllen soll.
So werden in der Bronze-Schicht Veränderungen operativer Datenstrukturen in den Quellsystemen möglichst frühzeitig abgefangen. Auf Ebene der Silber-Schicht wird die Harmonisierung der fachlichen Semantik zentral und unabhängig von einzelnen Reports vorgenommen. Und auf Ebene der Gold-Schicht können Abwandlungen regulatorischer Datenprodukte weitgehend ohne Anpassung der gesamten Datenverarbeitung umgesetzt werden, wenn sich Meldeanforderungen ändern. Die Anwendung des Medallion-Architekturprinzips mit der konsequenten Trennung zwischen den drei Schichten erleichtert somit die Weiterentwicklung älterer BCBS 239-Architekturen und senkt zukünftige Anpassungskosten.
Data Lakehouse-Architektur
Der durch IReF induzierte und fachlich durch das geschilderte Medallion-Architekturkonzept adressierte Modernisierungsbedarf bei der logischen Datenarchitektur kann technisch durch die Verwendung eines Data Lakehouses unterstützt werden. Ein Data Lakehouse verbindet die Vorteile von Data Lakes und Data Warehouses. Hierbei werden die Daten im Data Lakehouse sukzessive über mehrere Ebenen verbessert und angereichert, wobei die Data Lineage deutlich nachvollziehbar bleibt. Durch dieses Vorgehen passt die Technologie gut zu dem primär fachlich orientierten Medallion-Architekturprinzip.
Die Einführung eines Data Lakehouses ist vordringlich dann besonders attraktiv, wenn es sich um sehr große granulare Datenbestände mit umfangreichen Historisierungsanforderungen aus vielen heterogenen Quellsystemen handelt und sich die Datenstrukturen häufig ändern. Außerdem sollte die Einführung eines Data Lakehouses dann erwogen werden, wenn eine parallele Nutzung der granularen Daten für regulatorische Meldungen und vielfältige interne Analysen benötigt wird und an diese Daten aufgrund des Einsatzes von Künstlicher Intelligenz erhöhte Anforderungen gestellt werden.
Nicht jede Bank muss daher ihre bestehende Datenintegrationsschicht ersetzen. Vielmehr sind drei Ausgangssituationen zu unterscheiden:
- Banken, die bereits heute eine granulare, harmonisierte und flexible Datenintegrationsschicht haben, sollten die bestehende Plattform weiterverwenden. Die Anforderungen von IReF und das Mapping der Daten auf die Definitionen gemäß BIRD können durch die Ergänzung der fehlenden Attribute und Transformationsregeln relativ einfach gelöst werden.
- Banken, die heute zwar technisch eine zentrale Datenintegration haben, diese aber stark Reporting-orientiert an den verschiedenen Ausleitungsstrecken implementiert haben, müssen die fachliche Harmonisierung stärken. Sie sollten die Datengranularität in der Silber-Schicht verbessern und diese von der jeweiligen meldespezifischen Logik schrittweise entkoppeln.
- Banken, die bislang eine Zentralisierung nur teilweise erreicht haben und die noch zahlreiche individuelle Datenstrecken bedienen, müssen ihre Integrationsarchitektur stärker umbauen. Insbesondere für diese Banken ist eine gemeinsame Datenplattform auf Data Lakehouse-Architektur empfehlenswert.
Da viele Banken durch die oben beschriebenen IRFA-Projekte eine Datenintegrationsschicht besitzen und moderne Data Warehouse-Lösungen viele der IReF-Anforderungen erfüllen können, liegt der größere Handlungsbedarf für Banken somit nicht unbedingt in der Einführung einer neuen Speicherungstechnologie, sondern eher in der Weiterentwicklung des Datenmodells und der Transformationslogiken sowie der granularen Datenbereitstellung. Fachliche und technische Modernisierungen können daher zu einem guten Teil getrennt werden, was den zusätzlichen Migrationsaufwand reduzieren kann.
Weitere wesentliche Elemente im Zielbild
Fachliche und technische Aspekte sind allerdings noch nicht alles, was in einem Zielbild einer tragfähigen Datenarchitektur abgebildet werden muss. Darüber hinaus sind auch organisatorische Aspekte, Governance-Fragen und der Einsatz von Künstlicher Intelligenz wichtige Facetten.
Gute Datenstruktur, hervorragende Datenqualität und einordnende Metadaten schaffen eine solide Basis für die weitere Automatisierung durch den Einsatz von KI-Lösungen. Perspektivisch kann zukünftig möglicherweise ein Großteil der Meldungen von KI-Agenten übernommen werden, die in den meldepflichtigen Banken die Daten aufbereiten, prüfen und versenden oder, auf der regulatorischen Gegenseite, die Meldung entgegennehmen und weiterverarbeiten. Für solch einen Einsatz müssen allerdings Schnittstellen, Qualitätsregeln und Verantwortlichkeiten klar definiert werden. Governance, Metadaten, Datenqualität, Data Lineage, Datensicherheit und das Betriebsmodell wirken über alle fachlichen Schichten und technischen Speicherungen hinweg.
Die vertikale Veredelung von Rohdaten zu nutzbaren Datenprodukten entlang der Bronze-, Silber- und Gold-Schichten in der Medallion-Architektur muss auf allen Ebenen durch Verantwortlichkeiten unterstützt werden. Es ist festzulegen, wer für Sammlung, Harmonisierung und Aufbereitung der Daten zuständig ist, wer die erforderliche Datenqualität und die Existenz von Metadaten verantwortet und wer übergreifend über alle Ebenen den Lebenszyklus von Daten beachtet. Auch wenn die fachlichen Domänen Meldewesen, Risiko, Finanzen und weitere Geschäftsdomänen dieselben kontrollierten Datenbausteine nutzen, verlieren sie nicht ihre jeweilige fachliche Verantwortung.
Fazit
Die künftige IReF-Verordnung erfordert voraussichtlich keine vollständige Neuerfindung der Datenarchitektur, stellt aber die mit BCBS 239 erreichte Datenintegration auf den Prüfstand. Die zentrale Herausforderung für Banken liegt dabei in der Weiterentwicklung der bisher häufig an meldungsspezifischen Datenhaushalten orientierten Integration zu einer granularen, semantisch harmonisierten und mehrfach nutzbaren Datenbasis. Eine Medallion-Architektur bietet hierfür ein geeignetes fachliches Zielbild, das durch moderne Data Lakehouse-Technologien technisch unterstützt werden kann.
Banken sollten zur Vorbereitung auf die künftige IReF-Verordnung vor allem folgende Punkte berücksichtigen:
- IReF ist mehr als eine neue oder geänderte Meldung. Die IReF-Verordnung wird höhere Anforderungen an Datenmodell, Prozesse, Governance und Plattformarchitektur stellen. Banken sollten daher zeitnah mit der Analyse ihres Datenhaushalts und der integrierten Berichterstattung beginnen und eine ggf. notwendige Anpassung ihrer Systeme vorbereiten.
- Der langfristige Nutzen für Banken entsteht vor der Ausleitung oder einer konkreten Meldung. Die Harmonisierung und Qualität der Daten müssen in einer gemeinsamen, granularen Datenbasis verankert werden, nicht erst im Reporting für den jeweils spezifischen Zweck.
- Aus der Einführung von BCBS 239 können wertvolle Erfahrungen genutzt werden. Dies betrifft vor allem die Festlegung klarer Verantwortlichkeiten entlang der gesamten Data Lineage-Kette sowie die Nutzung von wiederverwendbaren Datenbausteinen als zentrale Erfolgsfaktoren.
- Die Medallion-Architektur bietet ein pragmatisches Ordnungsprinzip: Sie verbindet revisionssichere Rohdaten, fachliche Harmonisierung und vielfältige Datenprodukte in einem logisch konsistenten Zielbild.
- Die frühzeitige Auseinandersetzung mit der künftigen Datenarchitektur ist sinnvoll. Die Banken sollten daher den von IReF ausgehenden Impuls nutzen, um die Anforderungen mit laufenden oder geplanten Projekten aus der Unternehmenssteuerung zu verzahnen.
