BCBS 239 and ECB RDARR: synthetic data lineage for cross-border European banks.

§ 01 / Why now

The shift from patience to pressure

The Basel Committee on Banking Supervision published its principles for effective risk data aggregation and risk reporting in January 2013, with an original implementation expectation of early 2016 for global systemically important banks. The publication followed the post-2008 acknowledgement that during crisis conditions, several G-SIBs were unable to provide their own boards or supervisors with accurate, aggregated risk positions in a useful timeframe. The principles were designed to make that failure structurally impossible.

Thirteen years later, the supervisory verdict on implementation progress is unambiguous. The Basel Committee's seventh progress report, published in November 2023, found that the average compliance score for the 31 G-SIBs examined improved from 3.14 in 2017 to 3.17 in 2022 on a scale of 1 (non-compliant) to 4 (fully compliant). The bulk of that nominal improvement reflects supervisors' increasing precision about what fully compliant means, not genuine progress at the institutions. Compliance with principles 1, 5, 7, and 9 — covering governance, completeness, accuracy and reporting timeliness — actually deteriorated in some assessments. Andrea Enria, while chair of the SSM Supervisory Board, observed publicly that banks with adequate risk data aggregation and reporting capabilities remain the exception.

The supervisory response from 2024 has been deliberate. The ECB published the final RDARR Guide on 3 May 2024, after consulting on a draft from July 2023. SSM supervisory priorities for the cycles 2024-2026 and 2025-2027 both name RDARR as a priority area. From 2025, RDARR compliance is a formal component of the Supervisory Review and Evaluation Process. Dedicated on-site inspections have started across multiple SSM jurisdictions. The clear message from supervisors: the patience that characterised the period between 2016 and 2022 has ended.

§ 02 / Cross-border consequence

What the consolidating supervisor expects

For banking groups operating across multiple European jurisdictions, BCBS 239 and the RDARR Guide produce a specific operational pattern that domestic frameworks alone do not capture. The ECB, as consolidating supervisor for significant institutions in the SSM, assesses group-level RDARR capabilities and expects consistency across subsidiaries. A finding at group level cascades into expectations for individual entities, and weaknesses in a subsidiary that contribute to a group-level finding generate distinct supervisory dialogue between the ECB and the relevant national competent authority.

The practical pressure points for cross-border groups are three. First, group-level taxonomy alignment: subsidiaries in different jurisdictions typically developed local risk taxonomies aligned to local supervisory requirements. The RDARR Guide expects a coherent group taxonomy permitting aggregation without manual reconciliation. Second, intra-group data flow lineage: when risk data moves from a subsidiary to the group reporting hub, the lineage from the originating source system through transformation logic to the group-level report must be documented and audit-proof. Third, consistent quality metrics: the ECB expects the same data quality framework to apply at group and at each subsidiary, with comparable indicators rolling up.

UK banks under PRA supervision face a parallel framework. PRA SS3/18, finalised in 2018, sets out expectations on outsourcing and third-party risk management with implications for risk data aggregation. PRA SS1/23, in force since 17 May 2024, addresses model risk management with overlapping data quality expectations. UK-incorporated subsidiaries of EU banking groups must satisfy both PRA expectations and the consolidating supervisor's RDARR requirements simultaneously, with the additional layer of UK GDPR Article 32 obligations that DUAA 2025 preserves substantively unchanged.

§ 03 / The 14 principles

What BCBS 239 actually requires

BCBS 239 organises 14 principles into four thematic blocks. The first 11 principles apply directly to banks. Principles 12 to 14 govern supervisory action. The blocks build on each other, and the ECB RDARR Guide treats deficiencies in earlier principles as foundational issues whose resolution is required before claims about later principles carry weight.

Block I — overarching governance and infrastructure — covers Principle 1 (governance) and Principle 2 (data architecture and IT infrastructure). These are the most consistently cited weaknesses in supervisory observations. Boards that have not formally assigned risk data accountability, IT architectures that depend on manual reconciliation between systems, and infrastructures that fail under stress are all symptoms of inadequate Block I compliance. Block II — risk data aggregation capabilities — covers Principles 3 to 6 (accuracy and integrity, completeness, timeliness, adaptability). This is where firms perform their fire-drill demonstrations under supervisor request. Block III — risk reporting practices — covers Principles 7 to 11 (accuracy, comprehensiveness, clarity and usefulness, frequency, distribution). Block IV — supervisory review, tools and cooperation — covers Principles 12 to 14 and governs what supervisors do with findings.

The May 2024 RDARR Guide is the operational manual for how the ECB now interprets Blocks I to III. The Guide does not introduce new principles. Instead, it sharpens supervisory expectations on each principle: what evidence the bank must produce, what board engagement looks like in practice, what data lineage documentation must contain, what an independent validation function for RDARR is expected to do. The Guide deliberately moves the conversation from principle-level discussions to evidence-level expectations.

§ 04 / Audit-proof lineage

The RDARR Guide's data lineage requirement

One specific RDARR Guide expectation deserves separate examination because it is operationally challenging and directly intersects with data infrastructure: audit-proof data lineage. The Guide stipulates that the bank must maintain "active, audit-proof control and maintenance of the data lineage" for risk data feeding regulatory reporting. The lineage must be controlled as a managed process, audit-proof, and actively maintained as systems change.

The practical content of a compliant lineage record covers the full path from source system through every transformation step to the report consumed by the supervisor or the board. Each step must be documented, including the technical owner, the transformation logic, the data quality controls applied at that step, and the version history. The lineage must be available to validators and supervisors on demand. It must reflect the actual current state of the data pipeline, not a historical snapshot of the documented design.

For multi-system banks running a mix of mainframe core banking, decades-old data warehouses, and recent cloud analytical platforms, full lineage documentation is a substantial engineering effort. Manual lineage maintenance fails at the scale typical of significant institutions: typically thousands of data elements, hundreds of source systems, and continuous deployment cycles changing the pipeline. Tooling — automated metadata extraction, lineage capture from ETL platforms, integration with data catalogues — is necessary but not sufficient. The tooling produces a technical record; the regulatory record requires governance overlay that explains intent, controls, and decision history.

§ 05 / Independent validation

The new RDARR validation function

The RDARR Guide expects banks to establish an independent validation function for risk data quality, analogous to the independent model validation function familiar from internal model approvals. This is a structural change for most banks, where data quality has historically been the responsibility of data owners and IT operations rather than a separately reporting risk function.

The independent RDARR validation function has three operational responsibilities. First, validation of the data quality framework itself: are the dimensions appropriate, are the thresholds calibrated, are the controls running. Second, independent testing of data flows: can the validation function reproduce the path from source to report and identify discrepancies. Third, independent reporting to the audit committee or risk committee: findings from validation must escalate through a path independent of the line organisation responsible for the data.

The function's effectiveness depends heavily on its testing infrastructure. A validator that runs all tests on production data has the right fidelity but creates personal data exposure under GDPR Article 32 across an additional team and environment. A validator that runs tests on masked or sub-sampled data has reduced privacy exposure but produces validation findings of disputed evidentiary value, because the model owner or data owner can rebut findings on data preparation grounds. The architectural answer is high-fidelity test data that is not personal data: a synthesis layer preserving causal multi-table relationships of production data without retaining any specific real customer record.

§ 06 / Consequences

What can happen under non-compliance

Non-compliance with the RDARR Guide expectations does not produce automatic consequences. The supervisory response depends on the materiality of the finding, the bank's remediation progress, and the broader supervisory context. The ECB has indicated four possible pathways for material non-compliance.

The first is higher Pillar 2 Requirements or Pillar 2 Guidance in SREP. The ECB may determine that material data quality weaknesses generate operational risk that warrants additional capital buffer. This is not an automatic mechanism; it requires supervisory documentation and is a SREP outcome. Practice across the past three SREP cycles indicates that banks with severe RDARR findings have faced upward P2R adjustments of 25 to 50 basis points, generating capital costs in the hundreds of millions of euros for the largest institutions.

The second is administrative sanctions. Under SSM Regulation Article 18 and CRD V Articles 65 to 67, the ECB may impose financial penalties for material breaches of governance and risk management obligations. Sanctions are published, generating reputational consequences alongside the financial impact.

The third is reassessment of senior managers. The RDARR Guide stipulates that deficiencies in governance areas may lead to a reassessment of the suitability of the responsible board members. In severe cases, the Guide expressly contemplates removal of such members. This is the most direct personal consequence pathway for board members holding the RDARR responsibility.

The fourth is cascading effects for cross-border groups. Findings at the consolidating supervisor level translate to expectations at subsidiary level. A subsidiary that has been technically compliant with its domestic supervisor's expectations may find itself inside a group-level remediation programme because of findings at the parent level.

§ 07 / Why synthesis

The data infrastructure answer

The intersection of RDARR Guide expectations with GDPR Article 32 obligations creates a specific architectural pressure point that traditional data masking does not adequately resolve. The bank needs validation environments containing data that exhibits the same statistical and causal properties as production for the data quality validation function to be meaningful. The bank also needs to avoid personal data in those environments to maintain proportionate Article 32 controls. These two requirements pull against each other under any approach that copies real production data with masking.

Three failure modes are commonly observed. Masked production data breaks referential integrity across the 100 or more tables of a typical group risk warehouse, producing validation findings about data quality that reflect masking artefacts rather than real issues. Sub-sampled production data smooths the tail behaviour where genuine data quality issues most often arise, producing validation reports that miss critical weaknesses. Static synthetic data built from a fixed snapshot ages out of relevance as production evolves, producing validation work that is increasingly disconnected from current production behaviour.

Causal multi-table synthesis addresses each failure mode. The synthesis preserves referential integrity across all linked tables. The synthesis preserves the conditional distributions and tail behaviour that data quality validation needs to exercise. The synthesis can be regenerated continuously to track production evolution. And critically, no row in the synthesis corresponds to a real customer, removing the Article 32 exposure in the validation environment.

§ 08 / What Infundum is designing

CAUSA AI Data Engine for RDARR

Infundum's CAUSA AI Data Engine is being designed as a causal multi-table synthesis infrastructure for the financial sector. CAUSA is pre-MVP; what follows describes design intent and architectural direction, not shipped feature set.

For BCBS 239 and the RDARR Guide, the design intent addresses three operational needs. First, fire-drill ready scenarios: pre-prepared synthetic datasets for ad-hoc risk aggregation scenarios such as liquidity stress, geographic concentration shifts, and sector exposure inquiries, available to risk and supervisory liaison teams without preparing fresh production snapshots. Second, audit-grade generation lineage: each generated dataset carries documented generation parameters, source model, seed, and privacy threshold, suitable for evidencing to the ECB or national competent authority that the validation work rests on properly governed test data. Third, multi-table fidelity at group scale: synthesis preserving causal dependencies across the 100 or more tables typical of group risk warehouses, ensuring that independent RDARR validation work delivers meaningful evidence about real data quality issues.

Deployment is self-hosted within the bank's secure perimeter. Production data informs the synthesis pattern but never leaves the security boundary. Specific architecture details are available under NDA during formal evaluation.

§ 09 / Related

Regulatory context

For the related framework on model risk management see PRA SS1/23 Model Risk Management: validating multi-table banking models without PII exposure. For UK data protection following DUAA see UK DUAA 2025 and FCA Consumer Duty: synthetic data for demonstrable compliance. For DORA Article 26 TLPT and operational resilience testing see DORA Article 26 test data for European banks.

Conclusion

BCBS 239 is no longer a slow-moving compliance backdrop. ECB supervisors have signalled — through the May 2024 RDARR Guide, the placement of RDARR in SSM priorities for 2025-2027, and the launch of dedicated on-site inspections — that the era of polite supervisory dialogue has ended. Cross-border banking groups face consolidating supervisor pressure that domestic frameworks alone cannot satisfy. The RDARR Guide's data lineage requirement, the independent validation function expectation, and the explicit contemplation of senior manager consequences for material deficiencies combine to create a regulatory exposure that boards now treat with personal attention. The data infrastructure required to evidence compliance — high-fidelity test datasets, audit-grade lineage of generation, and proportionate GDPR Article 32 controls in validation environments — is the operational bottleneck for most groups. Causal multi-table synthesis is the architectural answer, and Infundum is designing CAUSA AI Data Engine for this purpose.