Von BCBS 239 zu RDARR – Was Banken jetzt umsetzen müssen
Mit RDARR verschärfen BaFin und EZB die Anforderungen an Risikodaten und Data Governance. Aus interpretierbaren Prinzipien werden prüfbare Standards – mit Fokus auf Datenqualität, Verantwortlichkeiten und IT-Architekturen. Lesen Sie, was sich gegenüber BCBS 239 geändert hat und wie Banken jetzt strukturiert und prüfungssicher umsetzen können.
In dieser Collection enthalten:
Collection öffnen
CRR III Offenlegung: Nun folgt die Bearbeitung der Säule III
T+1 Settlement in Europa: Update und konkrete Empfehlungen für Institute
Stressszenarien effizient abbilden
Variables Geschäft – bewährtes Modell, neue Umsetzung
Von BCBS 239 zu RDARR – Was Banken jetzt umsetzen müssen
Der Weg zum effektiven Non-Financial Risk Management – Eine Roadmap für Banken
Rekalibrierung der IRRBB-Zinsschocks - neue Entwicklungen
CRR III – Neuregelungen für außerbilanzielle Positionen
Praxisbericht IRRBB-Kundenprojekt mit der Porsche Bank
Die Geschäftsfeldrechnung: Praxishinweise
BCBS 239, offiziell „Grundsätze für die effektive Aggregation von Risikodaten und die Risikoberichterstattung“, wurde 2013 vom Basler Ausschuss für Bankenaufsicht (BCBS) veröffentlicht und ist seit 2016 für Global Systemically Important Banks (G-SIBs) bindend. Dies verpflichtete systemrelevante Banken zur Umsetzung von elf Grundsätzen für die effektive Aggregation von Risikodaten und einheitliches Reporting. Hinzu kommen drei Grundsätze für die aufsichtliche Prüfung– ein regulatorisches Fundament für Transparenz und Resilienz in der Finanzbranche.
Seit 2016 sind die Grundsätze für G-SIBs bindend, seit 2019 werden sie zunehmend auch auf Domestic Systemically Important Banks (D-SIBs) übertragen. Das sogenannte RDARR Framework (Risk Data Aggregation and Risk Reporting) dient der operativen Umsetzung der Vorgaben aus BCBS 239 und verleiht dem Thema neue Dynamik – insbesondere auch für D-SIBs und mittlere Institute.
Was unterscheidet RDARR von BCBS 239?
Obwohl RDARR auf BCBS 239 basiert, geht es in seiner praktischen Konsequenz deutlich über die ursprünglichen Prinzipien hinaus. Die wichtigsten Weiterentwicklungen sind:
- Prüfbarkeit und Nachweisdruck: RDARR ist explizit Bestandteil von Aufsichtsprüfungen (BaFin §44 KWG, EZB SREP).
- Strukturierte Umsetzungspflicht mit Roadmaps und Reifegradmodellen
- Technologiefokus auf IT-Architektur, Metadatensteuerung, DQ-Tools
- Verzahnung mit DORA (z.B. IKT-Governance, Incident Reporting)
Wie kann RDARR konkret umgesetzt werden? Ihr 5-Stufen-Plan zur strukturierten Umsetzung
RDARR verlangt nicht nur neue Prozesse, sondern eine Transformation des Datenmanagements. Ein bewährter Umsetzungsansatz folgt diesen Schritten:
- Gap-Analyse und Reifegradmodell: Bewertung von Datenflüssen, Verantwortlichkeiten, IT-Integration
- Data Governance verankern: Einführung klarer Rollen, Lenkungskreise, Kontrollinventare
- Datenqualität messen und steuern: DQ-KPIs, Dashboards, Control Frameworks
- Data Lineage und Transparenz: Einführung von Tools zur Datenherkunft, Metadatenmanagement
- Verzahnung mit DORA und IKT-Resilienz: Überschneidungen strategisch nutzen.
DORA-Schulung "IT-Regulatorik für Leitungsorgan und Kontrollfunktionen" am 09.07.2025
Mit dem Digital Operational Resilience Act (DORA) möchte die EU die digitale Widerstandsfähigkeit von Finanzinstituten stärken. In dieser Schulung erfahren Sie, welche Anforderungen und Pflichten sich aus DORA für Ihr Institut ergeben. Im Mittelpunkt stehen dabei kompakte und praxisnahe Ansätze, um digitale Resilienz gezielt aufzubauen und regulatorische Vorgaben sicher zu erfüllen.
Warum jetzt handeln? Fit für die Prüfung, fit für die Zukunft!
Die Aufsicht wird zunehmend restriktiv:
- EZB SREP-Feststellungen 2023 zeigen Unvollständigkeit bei vielen Banken.
- BaFin nutzt BCBS 239 zunehmend als Prüfungsmaßstab (§44 KWG).
- Druck zur Audit-Readiness inklusive Dokumentationspflicht wächst.
Fazit: RDARR ist mehr als ein Update – es ist ein Paradigmenwechsel
RDARR verlangt keine theoretische Compliance, sondern strukturierte, technisch umgesetzte Datenprozesse mit Governance-Nachweis. Es verschiebt die Verantwortung ins Top-Management und zwingt zur operativen Durchdringung. Wer jetzt investiert, vermeidet nicht nur Prüfungsrisiken, sondern schafft auch die Basis für resiliente Banksteuerung, KI-fähige Dateninfrastruktur und regulatorische Zukunftssicherheit.
RDARR in der Praxis: Zwei Beispiele für konkrete Umsetzungsschritte
Beispiel 1: Datenqualität – von KPIs zur institutionellen Steuerung
BCBS 239 IST-Zustand (vor RDARR):
Die Bank hat DQ-Kennzahlen implementiert (z. B. Vollständigkeit, Fehlerquote) und stellt monatlich Berichte an den Data Owner bereit. Die Kennzahlen sind im DWH definiert und technisch messbar.
RDARR-Anforderung:
Die Aufsicht erwartet, dass Datenqualität steuerungsrelevant wird – d. h.:
- Einbindung der DQ-KPIs in das Risikoberichtswesen und ICAAP-Reporting
- Konkrete Maßnahmen bei Grenzwertüberschreitung, z. B. Eskalation an den CRO oder Datenverantwortlichen
- Revisionssichere Dokumentation der Korrekturmaßnahmen (Test of Design/ToD, Test of Evidence/ToE)
- Integration der KPIs in ein übergreifendes Governance-Framework
Umstellung nötig:
- Aufbau eines DQ-Steuerungsprozesses (inkl. Rollen, Schwellenwertlogik, Eskalation)
- Ergänzung der Management-Reports (z. B. an den Vorstand)
- Anpassung des Kontrollinventars und Einführung einer DQ-Kontrollmatrix
Betroffene Prozesse:
Datenmanagement, Risikoreporting, interne Revision, CRO
Dauer (realistisch):
4–6 Monate, je nach Governance-Reife und IT-Tooling
Beispiel 2: Data Lineage – von dokumentiert zu aktiv gesteuert
BCBS 239 IST-Zustand (vor RDARR):
Die Bank hat für zentrale Kennzahlen (z. B. LCR, RWA) eine statische Excel-basierte Data Lineage-Dokumentation. Diese liegt dem Fachbereich und dem Prüfer vor, wird aber nur bei Bedarf aktualisiert.
RDARR-Anforderung:
Die Aufsicht verlangt eine aktive, revisionssichere Steuerung und Pflege der Data Lineage:
- Systematische Pflege über ein zentrales Tool
- Anschlussfähigkeit an Datenkatalog, DQ-Regeln und Berechtigungen
- Nachvollziehbarkeit bei System- oder Modelländerungen („Impact-Analyse“)
- Einbindung in das Change-, Release- oder Modellsteuerungsprozesse
Umstellung nötig:
- Einführung oder Erweiterung eines Data Lineage Tools
- Anbindung an Quellsysteme (ggf. automatisierte Scanner)
- Schulung von Datenverantwortlichen zur Pflege und Nutzung
- Abbildung der Lineage im BCBS 239 Reporting Framework
Betroffene Prozesse:
IT-Architektur, Fachbereiche, Datenmanagement, Modellvalidierung, IT-Governance
Dauer (realistisch):
6–9 Monate, bei Tool-Einführung und organisatorischem Change ggf. länger
Ihr Umsetzungspartner für RDARR und BCBS 239: Praxisnah. Prüfbar. Strategisch
Abbildung 1: Herausforderungen
Unser Team begleitet Sie ganzheitlich: von der fundierten Gap-Analyse und Reifegradbewertung über die Einführung steuerungsrelevanter Governance-Strukturen bis hin zur operativen Umsetzung. Wir liefern belastbare Management-Reports, sichern die Nachweisführung für BaFin & EZB – und verbinden Ihre RDARR-Initiative mit regulatorischen Anforderungen aus DORA, MaRisk, BAIT und IT-Security.
Abbildung 2: Unsere Unterstützung von der Gap-Analyse bis zur BCBS239-Compliance
Lassen Sie uns gemeinsam prüfen, wo Ihre Organisation steht und wie Sie RDARR als strategischen Vorteil nutzen können. Kontaktieren Sie unser Team!
Sie müssen sich anmelden, um einen Kommentar zu schreiben.