The Basel Committee on Banking Supervision published its Principles for Effective Risk Data Aggregation and Risk Reporting — universally referred to as BCBS 239 — in January 2013. Global Systemically Important Banks were expected to comply by January 2016. When the ECB conducted its first thematic review of compliance among significant European institutions in 2016 and 2018, the finding was stark: implementation status was "unsatisfactory." In 2019, the ECB wrote to all significant institutions under its direct supervision urging "substantial and timely improvements." In 2023, a further thematic review found continued material weaknesses. In May 2024, the ECB published its Risk Data Aggregation and Risk Reporting (RDARR) Guide — a document whose tone and content communicate, with increasing directness, that the supervisory community's patience is exhausted.

BCBS 239 is now fourteen years old. The institutions subject to it are among the most resourced in the world. The principles themselves are not ambiguous. And yet the compliance gap persists. This article examines why — and, more importantly, what closing it actually requires. It draws on direct experience of building BCBS 239-compliant data architecture in a regulated German bank, where the work of documenting over 200 enterprise interfaces, establishing Collibra as the data governance platform, and designing the Operational Data Store layer that supports risk data aggregation illustrated, with specific clarity, the structural reasons why BCBS 239 compliance remains elusive at institutions with far greater resources.

What BCBS 239 Actually Requires

The 14 principles of BCBS 239 are organised across four domains. The governance and infrastructure principles establish the foundational requirements; the data aggregation and risk reporting principles define the operational capabilities; and the supervisory principles address how regulators assess and enforce compliance. It is worth being specific about what the principles require, because a significant part of the compliance gap reflects institutions treating BCBS 239 as a documentation exercise rather than an architectural and operational capability requirement.

Governance & Infrastructure
P1
Governance
Strong governance framework; board ownership; data aggregation as a strategic priority with explicit accountability.
P2
Data Architecture & IT Infrastructure
Comprehensive, integrated data architecture; IT infrastructure supporting aggregation in normal and stress conditions; single authoritative source for each risk data element.
Risk Data Aggregation Capabilities
P3
Accuracy & Integrity
Data must reconcile with source systems; automated rather than manual aggregation; data quality controls at source.
P4
Completeness
All material risk data captured; coverage across all legal entities, asset classes and business lines.
P5
Timeliness
Risk data aggregated within timescales appropriate to risk management needs; faster in stress. Specific RTO expectations from supervisors.
P6
Adaptability
Ability to generate ad-hoc risk reports on demand — any metric, any cut, within short timescales, without bespoke development.
Risk Reporting Practices
P7
Accuracy (Reporting)
Risk reports accurately reflect aggregated data; reconcile with financial accounts where applicable.
P8
Comprehensiveness
Reports cover all material risks; management has complete picture across all business dimensions.
P9
Clarity & Usefulness
Reports support informed decision-making; format and content appropriate to the recipient.
P10
Frequency
Reporting frequency appropriate to the nature of the risk; increased during stress.
P11
Distribution
Reports distributed to appropriate recipients with appropriate access controls.
Supervisory Review & Cooperation
P12–14
Supervisory Oversight
Regular supervisory assessment; home-host cooperation for cross-border groups; remedial action where deficiencies identified. Increasingly, individual accountability of management body members.

Two principles deserve particular emphasis because they define the architectural requirements that most institutions have not yet met. Principle 2 requires a single authoritative source for each risk data element — which means no institution can satisfy it while maintaining multiple independent copies of the same data in different systems without clear, documented lineage back to a single master. Principle 6 requires adaptability — the ability to generate any requested risk aggregation on demand, without new development work. An institution that can produce its standard risk reports but cannot answer a regulator's ad-hoc question about its exposure to a specific counterparty within 24 hours is not BCBS 239 compliant, regardless of how well its standard reports are produced.

The Supervisory Escalation: From Guidance to Accountability

The ECB's 2024 RDARR Guide represents a material shift in supervisory posture. Previous guidance described what was expected. The RDARR Guide explains, with precision, what the ECB has found to be wrong and what it now requires — and it does so in language that places personal accountability squarely on the management body, not on the data management or technology function.

The Guide's most significant statement is that deficiencies in RDARR governance arrangements "may also lead to a reassessment of the suitability of the responsible members" of the management body. This is not a new power — supervisors have always been able to assess management suitability — but invoking it explicitly in the context of data governance is a clear signal. The failure to achieve BCBS 239 compliance is no longer being characterised as a technical programme management problem. It is being characterised as a governance failure at the highest level of the institution.

The ECB's designation of RDARR as a supervisory priority for 2025-2027 means that on-site inspections with specific BCBS 239 scope are expected to intensify across significant institutions throughout this period. Institutions that receive an on-site inspection and cannot demonstrate adequate progress — particularly on the governance and data architecture principles — face the prospect of binding supervisory measures under the SREP process.

"The 2024 RDARR Guide does not describe a new regulatory requirement. It describes the same requirement that has existed since 2013, applied with the patience of an institution that has been asking for the same improvements for eleven years and is no longer prepared to accept explanations for why they have not been delivered."

Four Structural Reasons the Gap Persists

The persistent BCBS 239 compliance gap is not primarily a resource problem, a technology problem, or a programme management problem. Institutions have spent substantial sums on BCBS 239 programmes over the past decade. The gap persists because of structural issues that technology investment and programme activity cannot address unless the structural issues themselves are resolved first.

The Data Lineage Problem: You Cannot Demonstrate What You Have Not Documented
BCBS 239 Principle 2 requires that institutions can demonstrate the complete lineage of every risk data element — from the source transaction in the originating system, through every transformation and aggregation, to its appearance in a risk report. This demonstration requires that every interface in the data supply chain is documented, its transformation logic is understood, and its outputs are tested for accuracy. At institutions with legacy data estates and hundreds or thousands of undocumented interfaces — a common condition in established banks — this documentation does not exist, and the interfaces themselves may be understood only by people who have since left. The lineage demonstration is impossible until the interface discovery and documentation programme has been completed. Most BCBS 239 programmes attempt to build lineage documentation without first completing the underlying interface inventory work. The result is lineage maps that are incomplete in ways that are not always visible until a supervisor asks a specific question about a specific data element.
The Ownership Vacuum: Data Quality Without an Owner Is Nobody's Problem
BCBS 239 Principle 1 requires a governance framework with explicit accountability for risk data quality. In practice, most institutions have a patchwork of partial accountability: the front office is accountable for trade capture accuracy, the risk function is accountable for the risk calculation, the finance function is accountable for the books and records, and the data management function is accountable for the data governance framework. Nobody is accountable end-to-end for the quality of risk data from origination to report. When a data quality problem is identified in a risk report, the investigation invariably crosses functional boundaries — the error is discovered in risk but originates in finance or operations — and accountability for remediation falls into the gap between functions. The ECB's thematic reviews have consistently found that governance frameworks "often lacked the necessary authority and resources to drive meaningful change." This is the ownership vacuum. It is not resolved by creating a Chief Data Officer role. It is resolved by designing explicit, non-overlapping accountability for data quality across the full supply chain from origination to consumption, with the authority to impose requirements on source systems and the resources to enforce them.
The Legacy Architecture Problem: Systems Designed Before the Requirement Existed
Most banks' risk data architectures were designed before BCBS 239 was published. They were designed to produce specific, known risk reports for specific, known regulatory and management purposes — not to support the general, flexible aggregation capability that Principle 6 requires. Data flows are optimised for the standard reports; ad-hoc requests require manual data extraction, manipulation and reconciliation that is both slow and prone to error. Core banking, risk engine, and reporting systems are often tightly coupled in ways that make architectural change expensive and risky. The practical implication is that achieving Principle 6 compliance in a legacy risk data architecture is not an upgrade exercise — it is an architectural redesign. The institutions that are closest to genuine BCBS 239 compliance are those that have either replaced their legacy risk data infrastructure or built an aggregation layer — an Operational Data Store or equivalent — that sits above the legacy sources and provides the flexible aggregation capability the principles require, without requiring changes to the underlying source systems.
The Timeliness Paradox: Batch Architecture in a Real-Time Requirement
Principle 5 requires that risk data can be aggregated within timescales appropriate to the nature of the risk — and specifies that these timescales must be shorter in stressed conditions, which is precisely when the data infrastructure is under greatest load. Most legacy risk data architectures are built on overnight batch processing: data is extracted from source systems at close of business, transformed and loaded into risk systems during the night, and available for reporting the following morning. This architecture satisfies stable, low-frequency reporting requirements but fails the timeliness test for stress scenarios. Regulators expect institutions to be able to produce material risk aggregations within hours, not the following business day. Meeting this requirement requires either near-real-time data pipelines from source systems or an aggregation architecture with sufficiently current data snapshots to meet the intraday timeliness requirements.

The Architectural Solution: What BCBS 239-Compliant Data Architecture Actually Looks Like

The structural problems described above point toward specific architectural requirements. An institution that has resolved its interface documentation deficit, its data ownership gaps, its legacy aggregation architecture, and its timeliness limitations has, in the process, built a data architecture that looks substantially different from what most banks currently operate.

Foundation Layer
Complete Interface Inventory with Documented Lineage
The non-negotiable prerequisite. Every data flow contributing to risk data — from source transaction system to risk report — must be documented, its transformation logic understood, and its outputs testable. This is the work of systematic interface discovery: network analysis, institutional memory interviews, ERP deep-dive, and reconciliation against every risk report's claimed data sources. The interface documentation programme is simultaneously the BCBS 239 lineage foundation and the data mesh design input — a single programme of work that serves both purposes.
Aggregation Layer
Operational Data Store / Data Products
An ODS or equivalent aggregation layer that provides single authoritative representations of key risk data entities — counterparty, position, exposure, collateral — sourced from the documented interfaces and updated at a frequency that meets Principle 5 timeliness requirements. This layer is the technical implementation of Principle 2's single authoritative source requirement. For institutions adopting a data mesh architecture, this is the domain data product layer: the risk domain's data products present risk data in a governed, documented, stable interface that decouples consumers from the complexity of source systems.
Governance Layer
Data Catalogue with Lineage, Quality and Ownership
A data governance platform — Collibra, Alation, or equivalent — that registers all risk data assets, captures their lineage from source to report, records the data stewards and owners responsible for each asset, and monitors data quality metrics. This is the supervisory evidence layer: when the ECB asks for a demonstration of Principle 3 (accuracy and integrity) or Principle 4 (completeness) compliance, the data catalogue is where the evidence lives. An institution that has populated and maintained a data catalogue to the standard required for BCBS 239 evidence is also, simultaneously, meeting the data documentation requirements of DORA's ICT asset management provisions.
Adaptability Layer
Self-Service Risk Aggregation Capability
The hardest layer to build and the most frequently missing. Principle 6 compliance requires that authorised users can construct any required risk aggregation from the documented data assets without bespoke development. This requires a combination of well-structured, well-documented data products; a query and reporting capability that exposes those products through an accessible interface; and data quality assurance at the aggregation layer that ensures ad-hoc outputs are as reliable as standard reports. Institutions that have built this capability report a transformative change in their relationship with supervisory requests: ad-hoc questions that previously required weeks of manual work can be answered within hours.

What the RDARR Guide Requires of Management Bodies

The ECB's 2024 RDARR Guide is explicit that the management body — the board or supervisory board — is accountable for the institution's RDARR framework. The specific obligations that the Guide places on the management body are worth setting out clearly, because they mirror the structure of DORA's management body obligations and similarly cannot be delegated to the technology or data management function.

Accountable Role RDARR Guide Obligation
Management Body Approve and oversee the RDARR framework; ensure adequate resources; set risk appetite for data quality; demonstrate active oversight rather than passive receipt of reports. Personal suitability of members may be reassessed if RDARR governance is found deficient.
Senior Management Implement the board-approved framework; establish clear data ownership and accountability structures; ensure the RDARR programme has sufficient authority to require improvements from source system owners; report material data quality issues to the management body.
CRO / Risk Function Define the risk data requirements that the RDARR framework must meet; validate that risk reports accurately reflect the underlying data; identify and escalate material data quality issues affecting risk management decisions.
CTO / Data Function Design and maintain the data architecture and IT infrastructure supporting BCBS 239 compliance; own the data catalogue and lineage documentation; lead the interface documentation programme; ensure timeliness requirements are met by the data pipeline architecture.
From Practice: The Interface Documentation Programme as BCBS 239 Artefact

In developing the data architecture for a BaFin-regulated bank, the programme of documenting over 200 enterprise interfaces was initiated primarily as an input to data mesh design — establishing the domain boundaries, data product specifications and lineage required for a governed data platform. The secondary benefit, which became increasingly significant as the programme progressed, was that the resulting interface documentation directly satisfied the BCBS 239 lineage requirements that the institution's risk data was subject to. A single programme of work produced two major regulatory deliverables: the data mesh foundation and the BCBS 239 lineage documentation. The alignment between what good data architecture requires and what BCBS 239 compliance requires is not coincidental — they are both asking the same question: "Do you actually know where your data comes from?"

The Intersection with DORA and the AI Act

BCBS 239 does not exist in isolation. Its requirements interact with two other significant regulatory obligations in ways that create both additional pressure and, where the interactions are managed intelligently, opportunities for programme efficiency.

Under DORA, risk data systems are ICT systems within the meaning of the Regulation and must be included in the ICT asset register, covered by business continuity and disaster recovery plans, and subject to third-party risk management where data processing is outsourced. The timeliness requirements of BCBS 239 Principle 5 — particularly the expectation of faster aggregation in stress — must therefore be met by an architecture that is also DORA-resilient: an architecture that can aggregate risk data within hours during a stress scenario must also be able to recover from an ICT incident within the RTO/RPO targets required by the bank's continuity plans. Designing these requirements jointly, rather than as separate compliance workstreams, produces a more coherent architecture at lower cost.

Under the EU AI Act, the growing use of machine learning models in risk data aggregation — for exposure estimation, collateral valuation, and PD/LGD modelling — creates new BCBS 239 dimensions. AI-generated risk data is subject to the same accuracy, completeness and lineage requirements as any other risk data. The explainability requirements of the AI Act for high-risk systems intersect directly with the BCBS 239 accuracy demonstration: if a model contributes to a risk metric, the institution must be able to demonstrate that the model's output is accurate and that its contribution to the aggregated figure can be traced. An AI model used in risk data aggregation that does not meet the AI Act's explainability and documentation requirements is also unlikely to meet BCBS 239's accuracy and lineage requirements for the data it produces.

Questions for CROs, CFOs and Data Architecture Leaders

Conclusion: From Compliance Exercise to Data Capability

The most honest framing of BCBS 239, for an institution that has not yet achieved genuine compliance, is this: the principles describe a data capability that a well-managed bank should want to have regardless of regulatory requirement. The ability to aggregate any risk metric on demand, from documented sources, with demonstrated accuracy and traceability, within timescales that support real risk management decisions — this is not a regulatory burden. It is a description of what good risk data infrastructure looks like.

Institutions that have treated BCBS 239 as a compliance exercise — assembling documentation to satisfy a checklist — have consistently failed to achieve it because the compliance documentation requires the underlying capability to exist. You cannot write a convincing lineage map for data whose provenance is unknown. You cannot demonstrate adaptability with an architecture that cannot aggregate on demand. The documentation follows the capability; it cannot substitute for it.

The institutions closest to genuine compliance are those that treated BCBS 239 as an architectural mandate and invested accordingly — in interface documentation, in single authoritative data sources, in aggregation infrastructure, and in the governance framework with sufficient authority to enforce data quality standards at source. These investments are expensive and disruptive. They are also, increasingly, non-negotiable: the ECB has been patient for more than a decade. The 2024 RDARR Guide and the 2025-2027 supervisory priorities indicate clearly that the patience has expired.

Written by Peter Pitkin · Senior IT Consultant & Enterprise Architect · Germany
Views reflect practical experience of BCBS 239-compliant data architecture design within a BaFin-regulated German financial institution. Regulatory positions described reflect the author's understanding as of May 2027; readers should verify current supervisory guidance against the ECB's published RDARR Guide and BaFin's supervisory communications.