What is Data Lineage? Request a Demo
Created with Fabric.js 5.2.4

What is BCBS 239?

A summary of key principles and compliance

Prove where your risk data came from, predict what a change will break, and protect the reporting your regulators examine.

What BCBS 239 compliance looks like with Solidatus

Months → minutes

Change impact assessment across an Oracle data warehouse fed by 30 source systems, at a global investment bank

2 people, <6 months

HSBC modeled its wholesale credit and lending book, against a competing quote of 18 months and 25 people

45 systems, 80,000+ fields

One shared data lineage model, used by more than 500 people

What is BCBS 239?

BCBS 239 is the publication code for “Principles for effective risk data aggregation and risk reporting,” issued by the Basel Committee on Banking Supervision (BCBS) through the Bank for International Settlements in January 2013. It exists because the 2008 financial crisis exposed a specific failure. Banks could not aggregate risk exposures fast or accurately enough for boards and supervisors to act. The 14 principles require you to strengthen governance, data architecture, and reporting so your institution produces risk data that is accurate, complete, and timely under stress.

Adoption has been slow from the start. The European Central Bank (ECB) launched a thematic review of risk data aggregation and risk reporting (RDARR) practices in 2016 and reported in May 2018 that “none of those significant institutions – some of which are classified as global systemically important banks – have fully implemented the BCBS 239 principles.” The Basel Committee reached a similar conclusion in 2023.

Who BCBS 239 applies to

The principles apply to all global systemically important banks (G-SIBs). National supervisors are also expected to apply them to domestic systemically important banks (D-SIBs), typically within three years of designation. In practice, the requirements cascade further, because supervisors examine the same evidence whenever they review risk data at any large institution.

What are the 14 key principles of BCBS 239?

The principles fall into four groups.

Group Principles
Governance and architecture1. Governance · 2. Data architecture and IT infrastructure
Risk data aggregation3. Accuracy and integrity · 4. Completeness · 5. Timeliness · 6. Adaptability
Risk reporting7. Accuracy · 8. Comprehensiveness · 9. Clarity and usefulness · 10. Frequency · 11. Distribution
Supervisory review12. Review · 13. Remedial action and supervisory measures · 14. Home and host cooperation

Principles 3 through 6 carry the heaviest data burden. Accuracy and completeness mean reconciling a reported figure back to its authoritative source, and timeliness means doing it fast enough to matter during a stress event. Adaptability means producing a report your supervisor did not ask for last quarter, which the Basel Committee still lists among the harder capabilities for banks to demonstrate.

What the ECB’s May 2024 guide changed

The ECB’s “Guide on effective risk data aggregation and risk reporting,” published in May 2024, is the most consequential update since the original standard, and it introduced a term the 2013 principles never used — data lineage.

Section 3.3 lists data lineage as a minimum element of an effective data governance framework, alongside named data owners and data quality controls. Section 3.4 specifies what that lineage has to look like.

“Complete and up-to-date data lineages on data attribute level (starting from data capture and including extraction, transformation, and loading).”

— ECB, Guide on effective risk data aggregation and risk reporting, May 2024

Two words in that sentence set the bar for every institution the guide covers.

Complete means end to end

Every system that touches risk data, from capture through to the report, not a subset and not only what a scanner reached.

Data attribute level means column rather than table

You have to show how business logic applies to individual fields, because a faulty calculation or mismatched currency conversion lives in a column.

Read the full ECB guide or our BCBS 239 whitepaper, which works through it section by section. Supervisors have since moved from setting that expectation to inspecting against it. The ECB’s supervisory priorities for 2026-28 report no improvement in banks’ RDARR sub-score under SREP 2025, and commit to targeted on-site inspections of RDARR frameworks through 2028.

Why catalog lineage does not satisfy BCBS 239

Many institutions go into a BCBS 239 review expecting the lineage bundled with their data catalog to satisfy BCBS 239. It usually does not, for two reasons from Section 3.4.

Catalog lineage is column-level only where a scanner can parse the code. Most catalogs now trace columns through SQL, cloud pipelines, and BI tools, so the gap is no longer granularity but what the trace can evidence. A catalog typically keeps business lineage at the table level and technical lineage in a separate, scanner-generated graph, so when a supervisor questions a number in a risk report, a column path exists but nothing ties it to the reported figure, the transformation logic behind it, or the date the figure was produced. Attribute-level lineage in Solidatus names the column, the transformation, and the upstream field that produced it in one model, versioned to the report filing date.

Catalog lineage also stops at the first system its connectors cannot read. Mainframes, bespoke calculation engines, and spreadsheet-driven adjustments are common in risk reporting and uncommon in connector libraries, and a trace that breaks partway back to source does not evidence completeness.

“Legacy systems, distributed data estates and the dynamic nature of data lineage complicate banks’ efforts to confirm end-to-end data traceability.”

— Basel Committee on Banking Supervision, Newsletter No. 36, January 2026

Each is a capability shortfall, not a coverage shortfall. Solidatus combines automated capture with visual modeling, so the trace runs end to end even across the systems a scanner cannot see.

What a BCBS 239 data lineage program gives you

Data journey

See how critical data is defined, manipulated, transformed, and aggregated on its way into reporting, with the architecture that carries it visible in the same model.

Data quality

Place data quality controls and their supporting rules at the right point in the process, informed by where risks and issues arise along the data journey.

Data governance

Underpin data ownership and governance with consistent definitions and controls across every critical data element in scope.

The evidence supervisors ask for

A BCBS 239 examination tests whether you can produce five things on demand.

Provenance

Where a reported figure originated, traced to the authoritative source system.

Transformation detail

Every calculation, mapping, and aggregation applied between source and report, at column level.

Ownership

Who is accountable for each critical data element and each control.

Change history

What your data environment looked like at a past reporting date, and what has changed since.

Impact analysis

Which reports and models a proposed change would affect, before it reaches production.

Items 4 and 5 defeat most tooling, because producing them requires a data lineage model that stores time as a first-class property rather than a snapshot overwritten on the next scan.

Retrospectively scanned metadata is documentation, not impact analysis.

Bi-temporal version control in Solidatus lets you compare any two points in time. When an examiner returns to check a remediation they raised last year, you can show the state of your data landscape on the date they raised it and the resolved state today, evidencing a trajectory rather than asserting one.

Case study

A global investment bank automates BCBS 239 compliance

Challenge

Risk data ran through an Oracle data warehouse fed by 30 source systems, with calculations embedded in code across siloed platforms. Aggregation and reporting were slow, and the resulting data quality issues made meaningful analytics difficult.

Solution

A visual model of the bank’s critical data environment, with data quality rules active in the model to alert owners automatically.

Results

  • Change impact assessment cut from months to minutes
  • The bank’s first comprehensive data dictionary, with automated updates and complete traceability
  • Subject matter expertise captured in the model, reducing key person risk
  • Controls on critical data demonstrable to executives, board members, and regulators in a few clicks

How Solidatus supports BCBS 239 compliance

Solidatus is a business lineage platform built for complex, regulated, and hybrid data environments. Three capabilities map to what BCBS 239 examinations test.

Secure Ai data lineage

Prove

Model the complete journey of risk data across every system, including the mainframes and bespoke platforms scanners cannot reach, then drill from the map view down to the column.

Network

Predict

Model a proposed change in a sandboxed copy of your live model and see which reports, controls, and downstream systems it affects before you touch production.

Secure data lineage solution

Protect

Link data flows to owners, policies, controls, and regulatory tags, so a critical data element carries its accountability wherever it travels.

That foundation supports the reporting and decision-making your board relies on, and the AI systems now governed under the same scrutiny.

Only Solidatus gives you this level of control.

Former Head of Wholesale Credit and Lending Data, HSBC

HSBC modeled its wholesale credit and lending book with two people in under six months, against a competing approach quoted at 18 months and 25 people. Solidatus also supports risk and governance programs at Deutsche Bank and BNY.

BCBS 239 is not the only obligation asking these questions. DORA extends traceability to third-party and ICT dependencies, EU AI Act Article 10 covers the data behind high-risk AI systems, and SR 26-2 applies data quality and selection principles across the model lifecycle at United States banks above $30 billion in assets. One data lineage model built for BCBS 239 supports regulatory compliance across all of them.

What supervisors do when institutions come up short

Supervisors decide case by case, and their response scales with the severity of the finding. Measures include supervisory follow-up letters, mandatory independent reviews, capital add-ons under Pillar 2 requirements, restrictions on business activity or capital distributions, required revisions to recovery and resolution plans, and financial penalties.

Severe or repeated breaches lead to heightened scrutiny and corrective action orders. Targeted on-site inspections of RDARR frameworks also run through 2028 for banks carrying unresolved findings, so the examination burden arrives well before any penalty does.

Where to start

Three moves make a BCBS 239 data lineage program tractable.

1

Work backward from the reports under supervisory scrutiny

Map their critical data elements to source at column level rather than cataloging the enterprise first, and the program produces examination evidence from the first month.

2

Model the systems no scanner reaches

Completeness under Section 3.4 depends on the mainframes, calculation engines, and manual adjustments your connectors miss, so model those visually alongside the automated capture.

3

Work on a living model from day one

Attach owners, data quality rules, and regulatory tags as you map, and the bi-temporal record accumulating underneath becomes the before-and-after evidence for your next examination.

Frequently asked questions

01.

What has changed for BCBS 239 in 2026?

Supervisory intensity, rather than the requirement itself. In November 2025, the ECB published its supervisory priorities for 2026-28, reporting no improvement in banks’ RDARR sub-score under SREP 2025 and committing to targeted on-site inspections of RDARR frameworks through 2028. A Basel Committee newsletter followed in January 2026, naming data lineage traceability as a continuing obstacle for banks. That newsletter states it does not create new supervisory guidance or expectations.

02.

Is BCBS 239 compliance mandatory?

The principles are mandatory for global systemically important banks, and national supervisors apply them to domestic systemically important banks, usually within three years of designation. The ECB’s RDARR guide sets supervisory expectations for significant institutions across the eurozone. Supervisors test compliance during examinations, and the ECB has stated it is intensifying that supervisory approach.

03.

How long does a BCBS 239 data lineage program take?

It depends on scope and approach. A global investment bank working with Solidatus cut its change impact assessment from months to minutes across 30 source systems. HSBC modeled its wholesale credit and lending book with two people in under six months, against a competing approach quoted at 18 months and 25 people. Scoping by report rather than by enterprise is what compresses the timeline.

04.

How does BCBS 239 relate to DORA, the EU AI Act, and SR 26-2?

All four require traceable, documented data flows. BCBS 239 and the ECB guide are the most explicit about data lineage. DORA extends the expectation to third-party and ICT dependencies, EU AI Act Article 10 covers data used in high-risk AI systems, and SR 26-2 applies data quality and selection principles across the model lifecycle at United States banks above $30 billion in assets. One data lineage foundation supports all of them.

05.

What is bi-temporal data lineage, and why does BCBS 239 need it?

Bi-temporal data lineage records both when something was true in your systems and when your model knew it so that you can reconstruct any past state. For BCBS 239, it lets you show an examiner the issue as it stood when they raised it and the resolved state today, and it lets you model a change before production is touched, which is what Principle 6 on adaptability requires.

See attribute-level lineage against your risk reporting

Book a demo to see attribute-level data lineage modeled against your own risk reporting.