BCBS 239 is the Basel Committee's January 2013 paper 'Principles for effective risk data aggregation and risk reporting': 14 principles in four groups, covering governance and data architecture (1–2), the accuracy, completeness, timeliness and adaptability of risk data (3–6), the quality of risk reports (7–11), and supervisory review and remediation (12–14). Global systemically important banks had to comply by January 2016 and domestic ones three years after designation; supervisors enforce it through Pillar 2, the ECB through its May 2024 RDARR guide, on-site campaign and escalation framework. For AI it matters because the data that trains and feeds a model is risk data: the Committee's January 2026 newsletter says AI-driven outputs depend on high-quality data, and examiners apply Principles 1, 3, 4 and 6 to training sets, feature pipelines and lineage whether or not the paper is cited.
TRACKED DOCUMENTS: BCBS 239 · BCBS 239 Implementation Newsletter (Jan 2026)
Issued
Basel Committee, 9 January 2013 (publication no. 239)
Form
14 principles in 4 groups; supervisory expectation, not a law
Who
G-SIBs from January 2016; D-SIBs 3 years after designation
Enforced through
Pillar 2 and national supervisors (ECB, PRA, others)
Status
In force; Jan 2026 newsletter says still ‘a work in progress’
What is BCBS 239 and why does it exist?
BCBS 239 is the short name for the Basel Committee on Banking Supervision's paper Principles for effective risk data aggregation and risk reporting, published on 9 January 2013. The number is simply its place in the Committee's publication series. The paper was a direct response to the 2007–09 financial crisis, during which, in the Committee's words, many banks lacked the ability to aggregate risk exposures and identify concentrations “fully, quickly and accurately” at the group level, across business lines and between legal entities. A bank that could not say what its total exposure to a failing counterparty was, in days rather than weeks, could not manage the risk, and its supervisor could not manage the resolution.
The remedy was not a reporting template. It was a set of 14 principles about the capability itself: who owns risk data, what architecture carries it, whether it is accurate, complete, timely and available for questions nobody planned for, how it is presented to the board, and what supervisors do when it is not. The principles apply to the data a bank uses to manage the risks it faces, including the data behind its regulatory capital and liquidity figures and, in the Committee's scope note, its key internal risk-management models. That last point is why a paper that never mentions artificial intelligence has become the document examiners reach for when they ask how the data feeding a bank's AI and machine-learning models is controlled. The official text, deadlines and every update are on our BCBS 239 document page; this guide explains the principles and what they mean in practice.
How are the 14 principles organised?
The paper groups its principles into four sections, which practitioners call the four pillars. The first three are obligations on the bank; the fourth describes what supervisors will do. Groups I and II are where AI and machine-learning data pipelines are examined, because they govern the data before it reaches a report or a model. Group III matters once a model's output appears in a risk report to the board.
What does each of the 14 principles require, and how do AI data pipelines fit?
The table paraphrases each principle from the January 2013 text, describes what supervisors accept as evidence of compliance (drawn from the Committee's progress reports and the ECB's 2024 guide), and says where a bank's AI or machine-learning data pipeline meets the principle. The principle wording in the first column is the Committee's; the other three columns are our reading.
I. Overarching governance and infrastructure · Principles 1–2
| Principle | One-line meaning | What ‘compliant’ looks like | AI / ML data pipelines |
|---|---|---|---|
| 1. Governance | Risk data aggregation and reporting sit under the bank's governance; the board and senior management own them. | Named data owners, a board-approved data governance framework, RDARR on the board's agenda, independent validation of the framework. | Training sets, feature stores and retrieval corpora need the same named owner and board visibility as any other risk data. |
| 2. Data architecture and IT infrastructure | Architecture and infrastructure fully support aggregation and reporting in normal times and in stress or crisis. | Documented data architecture, data dictionaries and taxonomies, single authoritative sources, resilience under stress. | Model data pipelines must be part of the governed architecture, not side-loaded from spreadsheets or ad hoc extracts. |
II. Risk data aggregation capabilities · Principles 3–6
| Principle | One-line meaning | What ‘compliant’ looks like | AI / ML data pipelines |
|---|---|---|---|
| 3. Accuracy and integrity | Risk data is accurate and reliable, aggregated on a largely automated basis to minimise errors. | End-to-end lineage from report to source, reconciliation to the books, documented controls, minimal manual intervention. | The principle examiners cite most for AI: lineage of every input to a model, reproducible feature definitions, automated data-quality checks. |
| 4. Completeness | All material risk data is captured and aggregated across the group by business line, legal entity, asset type, industry, region and other groupings. | Scope covers every material entity and risk type; exceptions are documented and approved. | A model trained on a subset that silently excludes an entity, product or population is a completeness failure before it is a model failure. |
| 5. Timeliness | Aggregated, up-to-date risk data is produced in time to meet reporting needs in normal and stress conditions. | Defined turnaround times per risk type and scenario, with evidence from stress exercises. | Feature freshness and drift monitoring are timeliness controls; a model scoring on stale data fails Principle 5. |
| 6. Adaptability | The bank can meet a broad range of on-demand, ad hoc requests, including in stress and from supervisors. | Ad hoc requests answered without manual rebuilds; capabilities tested in good times. | Being able to re-cut, re-run or re-train a model on request, with the exact data used, is adaptability applied to models. |
III. Risk reporting practices · Principles 7–11
| Principle | One-line meaning | What ‘compliant’ looks like | AI / ML data pipelines |
|---|---|---|---|
| 7. Accuracy | Reports accurately and precisely convey aggregated risk data and are reconciled and validated. | Reports reconciled to source, with stated precision and documented validation. | Model outputs that feed risk reports (scores, forecasts, flags) are reported figures and need the same reconciliation. |
| 8. Comprehensiveness | Reports cover all material risk areas, with depth and scope matching the bank's size, complexity and risk profile. | Coverage matrix of risk types against reports; no material risk without a report. | Model risk and AI usage belong in the comprehensive risk picture presented to the board. |
| 9. Clarity and usefulness | Reports communicate clearly and concisely, balancing data, analysis, interpretation and qualitative explanation. | Recipient-tailored reports with commentary and limitations stated. | Explainability for decision-makers: a model-driven figure in a report needs enough interpretation to be used. |
| 10. Frequency | The board and senior management set reporting frequency to recipients' needs and how fast the risk can change; frequency rises in stress. | Documented frequencies per report with a stress escalation path. | Monitoring cadence for model performance and data quality should match the speed at which the model's risk can change. |
| 11. Distribution | Reports reach the relevant parties while confidentiality is maintained. | Distribution lists tied to roles; access controls on sensitive risk data. | Access to training data and model outputs is a distribution and confidentiality question, including for vendor-hosted models. |
IV. Supervisory review, tools and cooperation · Principles 12–14
| Principle | One-line meaning | What ‘compliant’ looks like | AI / ML data pipelines |
|---|---|---|---|
| 12. Review | Supervisors periodically review and evaluate the bank's compliance with Principles 1–11. | The bank can evidence a current self-assessment and gap analysis against the principles. | Expect AI data pipelines to be in scope of the next review; the Committee's 2026 newsletter made the link explicit. |
| 13. Remedial actions and supervisory measures | Supervisors have and use tools, including Pillar 2, to require effective and timely remediation. | Remediation plans with credible end dates, tracked to closure. | Capital add-ons and binding measures can follow data findings, whatever system the data feeds. |
| 14. Home/host cooperation | Home and host supervisors cooperate on the review of the principles and on remedial action. | Group-wide standards applied consistently across subsidiaries and jurisdictions. | Models trained centrally and deployed in subsidiaries need lineage that both home and host supervisors can follow. |
What happened between publication in 2013 and the 2026 newsletter?
The Committee set a single hard date: global systemically important banks designated in November 2011 or November 2012 had to meet the principles by the beginning of 2016. Domestic systemically important banks were to follow three years after their national designation, and national supervisors were free to apply the principles more widely. The Committee then tracked implementation through self-assessment surveys of G-SIB supervisors, published as progress reports.
The reports tell a consistent story. The June 2018 report, covering 30 G-SIBs designated in 2011–12, found that in 2017 most had made “at best, marginal progress” and that the expected date of compliance “has slipped back for many banks”, blaming the complexity and interdependence of IT projects. The April 2020 report, covering 34 G-SIBs as of end-2018, said none were fully compliant in building the necessary data architecture. The November 2023 report, covering 31 G-SIBs designated during 2011–21, concluded that “additional work is required at all banks to attain or sustain full compliance” and told boards to take full responsibility for data governance and to treat sound data as the basis for digitalisation projects. The 6 January 2026 newsletter, which we track as bcbs_nl36, is not a new assessment but a summary of supervisory and industry outreach; it says a data-driven culture “remains a work in progress” at some banks, that data lineage is still hampered by legacy systems and distributed data estates, that ad hoc reporting in a crisis remains “a significant hurdle”, and, for the first time in a Committee document on BCBS 239, that “as the quality of AI-driven outputs depends on high-quality data, robust data management becomes more important for effective implementation”.
Which authorities enforce BCBS 239, and how?
The Basel Committee has no legal powers; its principles bind through the supervisors that adopt them. Principle 13 asks supervisors to have and use tools, including Pillar 2 capital measures, to require timely remediation, and Principle 12 asks them to review compliance periodically. Three supervisory regimes matter most to the banks we track.
| Authority | Instrument | What it does | Date |
|---|---|---|---|
| ECB Banking Supervision | Guide on effective risk data aggregation and risk reporting (RDARR) | Turns BCBS 239 into minimum supervisory expectations for the banks the ECB supervises directly: management body accountability, scope of the data governance framework, data architecture, quality controls and the implementation programme. Published after a consultation that ran from 24 July to 6 October 2023; the ECB's February 2025 supervision newsletter calls it “a common benchmark for assessing progress”. | 3 May 2024 |
| ECB Banking Supervision | On-site inspection campaign and targeted reviews | A centrally coordinated campaign launched in 2022 covering around one-third of directly supervised banks over three years, with the last inspections launched towards the end of 2024, plus targeted reviews across a sample of banks in 2024 and an annual Management Report on data governance and data quality signed by the management body (105 banks in the 2024 exercise). Findings feed SREP scores. | 2022–2025 |
| ECB Banking Supervision | SSM supervisory priorities 2026–28 and escalation framework | Keeps data and ICT capabilities inside Priority 2 (operational resilience) and describes a defined escalation process: timelines and interim milestones first, then the binding measures of Article 16 of the SSM Regulation, which include periodic penalty payments. | 18 Nov 2025 |
| PRA | ‘Dear CEO’ letter, thematic findings on the reliability of regulatory returns | The PRA does not transpose BCBS 239 as a rule for UK banks; it examines the same capabilities through regulatory-reporting reviews. The September 2021 letter reported “significant deficiencies” in several firms' processes for accurate and reliable returns, and in December 2021 the PRA fined Metro Bank £5,376,000 for regulatory reporting governance and control failings. | 10 Sep 2021 |
| US agencies | Model risk guidance (SR 26-2 / OCC 2026-13; SR 11-7 before April 2026) | The US agencies never issued a BCBS 239 rule; US G-SIBs are assessed through the Committee's surveys and through the data-quality expectations in model risk guidance, which keeps assessment of input data quality and relevance inside conceptual-soundness review (SR 26-2). | 17 Apr 2026 |
What have supervisors actually found at banks?
The findings are remarkably stable across a decade and two continents. From the Committee's reports and the ECB's February 2025 newsletter on its RDARR work programme, the recurring deficiencies are:
- No current gap analysis. The ECB's 2024 targeted reviews found that “many banks do not provide proper recent or regular gap analyses” against BCBS 239 and supervisory expectations, and that banks “repeatedly fail to provide credible target end dates for implementation”.
- Scope gaps in the data governance framework. Unclear criteria for defining material legal entities, entities excluded even where criteria existed, key decision-making reports left out, and frameworks that do not cover the whole chain “from data capture to final reporting”.
- Lineage that cannot be proven. The Committee's January 2026 newsletter names legacy systems, distributed data estates and the dynamic nature of lineage as the reasons end-to-end traceability is still hard, while noting that automated lineage tools are starting to show business value.
- Ad hoc reporting that depends on manual work. Producing timely, accurate and complete reports in a crisis or for a supervisory request remains, in the Committee's words, “a significant hurdle for some banks”; it recommends running ad hoc reports in good times as a test.
- Boards that are informed but not in charge. The 2023 report asked boards to take “full responsibility” for data governance; the 2026 newsletter still cites resistance to change, fragmented responsibilities and insufficient senior-management attention.
- Cross-border misalignment. Internationally active groups struggle to aggregate at entity level and up to the consolidated parent, and to reconcile differing national expectations; the Committee suggests standardised group-level practices.
The ECB's conclusion in February 2025 was blunt: “the number of institutions without fully adequate RDARR capabilities is still too high”. Its 2026–28 priorities keep the topic open, and the Basel Committee's June 2026 range-of-practices report on ICT risk management records the same legacy-system constraints from the technology side.
What does BCBS 239 mean for AI and machine-learning models?
BCBS 239 was written about a failure of data, not a failure of models, which is exactly why it travels so well into AI. A training dataset, a feature store, a retrieval corpus for a generative-AI assistant and the inference-time inputs to a credit or fraud model are all risk data in the paper's sense once the model informs a risk decision. An examiner reviewing an AI model's inputs asks the BCBS 239 questions whether or not the paper is cited: who owns this data, where did it come from, how do you know it is complete and current, and could you reproduce it tomorrow with a different cut? Three principles carry most of the weight.
- Principle 3, accuracy and integrity, is where lineage lives. A model output is defensible to a supervisor, an auditor or a declined customer only if every input can be traced to its source and transformation. The 2026 newsletter singles lineage out as the capability legacy systems still frustrate; for AI it is the first artefact a validator should ask for.
- Principle 4, completeness, is the control against models trained on a subset that silently excludes a business line, a legal entity, a period or a population, which is also how representativeness and bias problems enter a model.
- Principle 6, adaptability, is the ad hoc test: a bank that cannot re-run or re-cut the data behind a model on request has a model it cannot explain in a crisis. For vendor-hosted models the question becomes contractual, which is where DORA and US third-party guidance take over.
Newer rules restate the same expectations in their own vocabulary, and a bank that has genuinely implemented BCBS 239 has most of the evidence they ask for. The 2026 US model risk guidance, SR 26-2, keeps data quality and relevance inside conceptual-soundness review for the machine-learning models that remain in its scope (our SR 11-7 and OCC 2011-12 guide explains the lineage of that expectation). Article 10 of the EU AI Act turns data governance into a legal duty for high-risk systems such as consumer credit scoring, with provenance, preparation, bias examination and gap analysis to be documented. The ECB's revised guide to internal models (July 2025) asks whether a machine-learning model's complexity is justified by its performance, a question that cannot be answered without controlled data, and the ECB's February 2025 newsletter states the dependency directly: “high-quality data is a prerequisite for exploiting innovative technologies such as AI and advanced analytics”. The gap at most banks is not the framework; it is that AI datasets were assembled outside the governed perimeter.
How should a bank apply BCBS 239 to its AI programme?
- Classify the training, validation and inference datasets of every material AI model as risk data under the BCBS 239 framework, each with a named owner (Principle 1), a lineage record (Principle 3) and a documented data-quality threshold.
- Make lineage the first artefact a model validation requests: source systems, transformations, feature definitions and the date of the data cut, reproducible on demand (Principles 3 and 6).
- Test completeness explicitly: which entities, products, periods and populations are absent from the training set, and what that does to outputs (Principle 4). Record the answer in the model documentation.
- Put model-performance and data-drift monitoring on a cadence that matches how fast the risk can change (Principles 5 and 10), and make sure model-driven figures in board reports are reconciled and explained (Principles 7 and 9).
- Keep one current gap analysis against the 14 principles and the ECB guide, with credible end dates. That absence is the finding the ECB reports most often.
- For EU credit scoring, map the BCBS 239 evidence onto Article 10 of the AI Act now; the documentation takes years to assemble and the stand-alone Annex III obligations apply from 2 December 2027.
- Expect the board question. The Committee's 2026 newsletter says boards must oversee risk data aggregation; AI has made data the board-level risk the paper always said it was.
What are the 14 principles of BCBS 239?
Governance (1), data architecture and IT infrastructure (2), accuracy and integrity (3), completeness (4), timeliness (5), adaptability (6), accuracy of reports (7), comprehensiveness (8), clarity and usefulness (9), frequency (10), distribution (11), supervisory review (12), remedial actions and supervisory measures (13) and home/host cooperation (14). Principles 1–11 are obligations on the bank; 12–14 describe what supervisors do.
Is BCBS 239 a law?
No. It is a Basel Committee standard, a supervisory expectation that national and regional supervisors enforce through their own tools, mainly Pillar 2 measures, on-site inspections and remediation orders. The ECB's May 2024 RDARR guide is the clearest statement of how one supervisor applies it; the US agencies have not issued a BCBS 239 rule.
Which banks must comply with BCBS 239 and by when?
Global systemically important banks designated in November 2011 or 2012 had to comply by the beginning of 2016. Domestic systemically important banks follow three years after their national designation. Supervisors may apply the principles to other banks, and the ECB assesses all the banks it supervises directly against its guide.
Are banks compliant with BCBS 239 in 2026?
Not fully. The Basel Committee's November 2023 progress report on 31 G-SIBs said additional work was required at all banks, its January 2026 newsletter describes data culture, lineage and ad hoc reporting as still a work in progress, and the ECB said in February 2025 that the number of institutions without fully adequate capabilities is still too high.
Does BCBS 239 apply to AI training data?
Not by name, but in substance. Its scope is the data a bank uses to manage its risks, including data behind key internal models, so training sets, features and inference inputs of models used in risk decisions are risk data. The Committee's January 2026 newsletter links AI explicitly to the principles, and the ECB says high-quality data is a prerequisite for AI.
What is the ECB's RDARR guide and how does it relate to BCBS 239?
The ECB's Guide on effective risk data aggregation and risk reporting, published on 3 May 2024 after a 2023 consultation, sets minimum supervisory expectations for the banks the ECB supervises directly. It does not add new requirements to BCBS 239; it consolidates earlier ECB communications and prioritises the root causes of slow remediation, such as management-body shortcomings and weak implementation programmes.
What is the difference between risk data aggregation and risk reporting in BCBS 239?
Aggregation (Principles 3–6) is the capability to collect, process and consolidate risk data so the bank can measure its performance against risk tolerance. Reporting (Principles 7–11) is how that aggregated data is presented to the board, senior management and supervisors. A bank can aggregate well and report badly, or the reverse, which is why they are assessed separately.
What happens to a bank that fails BCBS 239?
Principle 13 asks supervisors to use remedial tools including Pillar 2 capital measures. The ECB's escalation framework moves from timelines and milestones to binding measures under Article 16 of the SSM Regulation, which can include periodic penalty payments; findings also feed SREP scores. The PRA has fined a bank (Metro Bank, £5.4 million in December 2021) over regulatory reporting governance.
- Principles for effective risk data aggregation and risk reporting (BCBS 239) — Basel Committee on Banking Supervision, Jan 9, 2013 (bis.org) · our page on BCBS 239
- Implementation of the Principles for effective risk data aggregation and risk reporting (newsletter bcbs_nl36) — Basel Committee on Banking Supervision, Jan 6, 2026 (bis.org) · our page on BCBS 239 Implementation Newsletter (Jan 2026)
- Progress in adopting the Principles for effective risk data aggregation and risk reporting (press release, report d559) — Basel Committee on Banking Supervision, Nov 28, 2023 (bis.org)
- Progress in adopting the Principles for effective risk data aggregation and risk reporting (report d501) — Basel Committee on Banking Supervision, Apr 27, 2020 (bis.org)
- Basel Committee issues progress report on banks' implementation of the Principles (press release, report d443) — Basel Committee on Banking Supervision, Jun 21, 2018 (bis.org)
- Sound risk data reporting: key to better decision-making and resilience (Supervision Newsletter) — ECB Banking Supervision, Feb 19, 2025 (bankingsupervision.europa.eu)
- Public consultation on the Guide on effective risk data aggregation and risk reporting — ECB Banking Supervision, Jul 24, 2023 (bankingsupervision.europa.eu)
- SSM supervisory priorities for 2026–28 — ECB Banking Supervision, Nov 18, 2025 (bankingsupervision.europa.eu) · our page on SSM supervisory priorities 2026–28
- Thematic findings on the reliability of regulatory returns (Dear CEO letter) — Prudential Regulation Authority, Sep 10, 2021 (bankofengland.co.uk)
- PRA fines Metro Bank £5,376,000 for failings in its regulatory reporting governance and controls — Prudential Regulation Authority, Dec 21, 2021 (bankofengland.co.uk)
- SR 26-2: Revised Guidance on Model Risk Management — Federal Reserve Board, Apr 17, 2026 (federalreserve.gov) · our page on SR 26-2
- Revised ECB Guide to internal models (machine-learning section) — ECB Banking Supervision, Jul 28, 2025 (bankingsupervision.europa.eu) · our page on ECB Guide to internal models (July 2025, ML section)
When this rule moves, the next morning's brief says so
when one of these regulators moves, the next morning's brief says so · six sourced stories · 7 am ET · free
plus every tracker, bank and agent page update, the morning after · leave any morning