Wissen · Business Intelligence
DWH-Architektur für granulare Meldungen:
Was Ihr Datenhaushalt können muss
AnaCredit war der Anfang, IReF setzt den Maßstab: Granulare Meldungen entscheiden sich nicht im Meldewesen-Tool, sondern in der Data-Warehouse-Architektur dahinter.
Granulare Meldungen verlangen vom Data Warehouse vier Eigenschaften, die klassische Melde-Datenhaushalte selten mitbringen: lückenlose (bitemporale) Historisierung jedes Einzelgeschäfts, Skalierbarkeit für um Größenordnungen wachsende Datenvolumina, Datenqualitätssicherung auf Einzelsatzebene statt auf Aggregaten und eine dokumentierte Data Lineage vom Quellsystem bis zur Meldung. Wer diese Basis für IReF aufbaut, erfüllt zugleich die Infrastruktur-Anforderungen von BCBS 239.
Stand: Juni 2026 · Regulatorischer Kontext: EZB-IReF-Portal · BCBS 239 (BIS, PDF)
Warum granulare Meldungen das DWH verändern
Mit AnaCredit liefern Banken seit 2018 Kreditdaten auf Einzelgeschäftsebene; mit IReF wird dieses Prinzip ab 2031 auf das gesamte statistische Meldewesen ausgeweitet – Bilanzpositionen, Zinsen und Wertpapierbestände inklusive. Parallel verlangt BCBS 239 für die Risikoseite belastbare, nachvollziehbare Datenaggregation.
Der gemeinsame Nenner: Die Aufsicht will keine befüllten Formulare mehr sehen, sondern verlässliche Einzelgeschäftsdaten, aus denen sie Aggregate selbst bildet. Damit verschiebt sich der Engpass vom Meldewesen-Tool in den Datenhaushalt – und Architekturentscheidungen von heute bestimmen, wie teuer die Meldepflichten von morgen werden.
Die vier Architektur-Anforderungen
1. Bitemporale Historisierung
Korrekturlieferungen und Rückfragen der Aufsicht beziehen sich auf vergangene Stichtage. Das DWH muss daher zwei Zeitachsen führen: die fachliche Gültigkeit (was galt zum Stichtag?) und den technischen Wissensstand (was wussten wir, als gemeldet wurde?). Nur so lässt sich ein damaliger Meldestand exakt reproduzieren und gleichzeitig korrigieren. Nachträglich eingebaute Historisierung ist erfahrungsgemäß eines der teuersten Refactorings überhaupt – sie gehört ins Fundament.
2. Volumen & Performance
Der Schritt von Aggregaten zu Einzelgeschäften multipliziert das Datenvolumen – über alle Stichtage und Historisierungsstufen hinweg. Ladefenster, die heute komfortabel sind, kippen unter granularen Vollabzügen. Gefragt sind Delta-Ladelogiken, Partitionierung und massiv parallelisierbare Verarbeitung; spaltenorientierte und verteilte Plattformen spielen hier ihre Stärken aus.
3. Datenqualität auf Einzelsatzebene
In Aggregaten mitteln sich Fehler weg – auf Einzelgeschäftsebene wird jeder fehlende Schlüssel und jedes implausible Attribut sichtbar und potenziell zum Validierungsfehler bei der Bundesbank. Datenqualitätsregeln müssen deshalb dorthin, wo die Daten entstehen: in die Ladeprozesse, mit messbaren Qualitätskennzahlen je Datendomäne und klaren Verantwortlichkeiten (Data Ownership) für die Bereinigung.
4. Data Lineage & Nachvollziehbarkeit
Jede gemeldete Zahl muss bis zum Quellsystem rückverfolgbar sein – für die Aufsicht ebenso wie für die interne Fehlersuche. Wer das Mapping strukturiert dokumentiert, etwa entlang der Ebenen des BIRD-Datenmodells (Input Layer → Enriched Input Layer → Output Layer), bekommt die Lineage als Nebenprodukt der Architektur statt als nachgelagerte Dokumentationspflicht.
Das Zielbild: eine Datenbasis für Meldung und Risiko
Bewährt hat sich eine klassische Schichtenarchitektur – Staging (Rohdaten aus den Quellsystemen), Core (harmonisierte, historisierte Einzelgeschäftsdaten) und Data Marts (zweckgebundene Abnehmersichten) –, bei der die granulare, qualitätsgesicherte Core-Schicht sowohl das Meldewesen als auch das Risikoreporting versorgt. Eine Datenbasis, zwei Abnehmerwelten: Das vermeidet Abstimmungsdifferenzen zwischen Meldung und Risikobericht und halbiert den Pflegeaufwand für Datenqualität und Lineage.
Ob diese Architektur on-premise, hybrid oder cloud-nativ betrieben wird, ist eine Abwägung aus Skalierungsbedarf, Kostenprofil und aufsichtlichen Anforderungen an Auslagerungen – wichtig ist, dass sie vor dem IReF-Umsetzungsprojekt getroffen wird. Der IReF-Zeitplan lässt dafür noch Raum, aber nicht beliebig viel: Zur Pilotphase ab Q2 2030 muss die Plattform tragen.
Häufige Fragen zur DWH-Architektur für Meldungen
Warum reicht unser bestehendes Melde-DWH für granulare Meldungen oft nicht aus?
Klassische Melde-Datenhaushalte wurden für aggregierte Formularmeldungen gebaut: Sie halten verdichtete Positionen zum Stichtag, oft ohne lückenlose Historie und ohne alle Attribute der Einzelgeschäfte. Granulare Meldungen wie AnaCredit – und künftig IReF – drehen die Anforderung um: Jedes Einzelgeschäft muss mit Dutzenden Attributen, korrekten Schlüsselbeziehungen und nachvollziehbarer Historie vorliegen. Das betrifft Datenmodell, Speichervolumen und Ladeprozesse gleichermaßen.
Was bedeutet Historisierung in diesem Kontext konkret?
Es muss rekonstruierbar sein, welcher fachliche Stand zu welchem Stichtag galt – und zusätzlich, wann diese Information technisch ins DWH gelangte. In der Praxis hat sich dafür die bitemporale Historisierung etabliert (fachliche Gültigkeit plus technischer Wissensstand). Sie ermöglicht Korrekturlieferungen für vergangene Stichtage, ohne den damaligen Meldestand zu verlieren – genau das verlangen Rückfragen- und Korrekturprozesse der Aufsicht.
Müssen wir für IReF in die Cloud?
Nein – aber die Frage stellt sich bei den zu erwartenden Datenvolumina fast zwangsläufig. Cloud-Plattformen punkten bei elastischer Skalierung und Parallelisierung der Ladeprozesse; dem stehen aufsichtliche Anforderungen an Auslagerungen, Datenschutz und die Exit-Strategie gegenüber. Realistisch sind alle drei Wege: eine ausgebaute On-Premise-Architektur, hybride Modelle oder eine Cloud-native Plattform. Entscheidend ist, dass die Architekturentscheidung vor dem IReF-Umsetzungsprojekt fällt – nicht mittendrin.
Wie hängen Meldewesen-DWH und Risiko-DWH zusammen?
Idealerweise speisen sich beide aus derselben granularen, qualitätsgesicherten Datenbasis. BCBS 239 verlangt für die Risikoseite dieselben Eigenschaften, die IReF für die Meldeseite voraussetzt: definierte Golden Sources, dokumentierte Data Lineage und automatisierte Datenqualitätskontrollen. Getrennte Datenhaushalte für Melde- und Risikodaten bedeuten doppelte Kosten und garantierte Abstimmungsdifferenzen.
Wie wir solche Architekturen konzipieren und umsetzen, zeigt unsere Business-Intelligence-Beratung.
Trägt Ihre DWH-Architektur die granulare Zukunft?
Wir prüfen Historisierung, Skalierbarkeit und Lineage Ihres Datenhaushalts gegen die Anforderungen von IReF und BCBS 239 – mit einer priorisierten Ausbau-Roadmap.
