Basel IV runs on data that BCBS 239 already governs

Where risk data aggregation and capital calculation rules overlap

UK banks start calculating capital under Basel 3.1 on January 1, 2027, and EU banks are already two years into the same rules.^1,2 As your bank prepares, someone will ask the data team a fair question: does the BCBS 239 program already cover this? The program covers part of it, because the two frameworks govern different things and intersect only at the data that feeds the capital calculation. That overlap determines whether you build your data lineage once or twice.

No regulator uses the name Basel IV. The Basel Committee on Banking Supervision called its December 2017 package “Basel III: Finalising post-crisis reforms,” and each jurisdiction adopts it under its own label.³ The EU adopted it through the third Capital Requirements Regulation (CRR3), the UK Prudential Regulation Authority (PRA) adopted it as Basel 3.1, and US agencies re-proposed their version, known as the Basel III endgame, in March 2026.⁴ The industry shorthand stuck because the package changes capital outcomes enough to feel like a new accord, and our Basel III overview covers the earlier reforms it completes.

In its 2025 supervisory review, the European Central Bank (ECB) found “no improvement in the relevant average sub-score” for risk data aggregation and risk reporting (RDARR) compared with the year before.⁵ That leaves your bank calculating new capital figures on data your supervisors already question. The ECB’s monitoring strategy also names data quality management and IT and data architecture as its next areas of focus, and Basel IV’s inputs depend on both.

Where BCBS 239 and Basel IV do not overlap

BCBS 239 is the set of 14 principles for risk data aggregation and risk reporting that the Basel Committee published in January 2013.⁶ The principles cover governance and data architecture, the accuracy and completeness of aggregated risk data, and the way risk reports reach senior management and the board. They set no capital requirement and assign no risk weight. Global systemically important banks (G-SIBs) were expected to comply by 2016, and the principles encourage national supervisors to apply them to domestic systemically important banks (D-SIBs) as well.

Basel IV covers the capital side. It rewrites the standardized approaches for credit and operational risk, updates the market risk rules known as the Fundamental Review of the Trading Book (FRTB), and limits how much a bank’s internal models can reduce its risk-weighted assets. The package does not describe how a bank should govern, trace, or reconcile the data those calculations consume.

Because Basel IV and BCBS 239 look unrelated on paper, they often end up with different owners. Basel IV goes to finance and capital management, and BCBS 239 goes to the chief data office or the risk data function. Each team then documents the same source systems for its own purpose, and the bank pays for lineage twice while neither version covers the full path from a source field to the capital ratio.

Where they overlap: the data inputs to the capital ratio

Both frameworks depend on the data that feeds the capital calculation. Every Basel IV risk weight depends on inputs a bank must source, aggregate, and keep accurate, and the BCBS 239 principles govern that work.

Under the revised standardized approach, for example, the risk weight for most residential real estate exposures depends on the loan-to-value (LTV) ratio.⁷ The Basel text defines LTV as “the amount of the loan divided by the value of the property.” The loan amount declines as the loan amortizes, and, with limited exceptions, the property value stays at its origination value. That one ratio draws on at least two systems: the loan servicing platform that holds the current balance and the collateral system that holds the original valuation. When the two disagree about which property secures which loan, the risk weight is wrong, and so is the capital figure built on it.

Supervisors have been specific about what proof of those inputs looks like. The ECB’s May 2024 guide calls for “complete and up-to-date data lineages on data attribute level,” which for the mortgage example means lineage for the balance and valuation fields themselves.⁸ The Basel Committee’s January 2026 newsletter makes the same point from the standard-setter’s side.⁹

“Data lineage, or the traceability of data from its origin to its final use, is important for confirming data quality.”

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

Under Basel IV, the capital ratio is one of those final uses. A bank that can trace an LTV input from the collateral system to the reported ratio therefore has evidence for both frameworks at once. The risk data team can show the ECB the attribute-level lineage it expects, and the capital team can find the source system behind any risk weight that looks wrong.

Two calculation paths have to start from one source

Internal-model rules create a second overlap between capital rules and data principles. A bank approved to use internal models must also calculate its risk-weighted assets under the standardized approaches, and its risk-weighted assets are the higher of the internal-model figure and 72.5% of the standardized figure.¹⁰ The EU phases that percentage in from 50% in 2025 to 72.5% in 2030, and the UK reaches full implementation on January 1, 2030.^11,12 The US takes a different route: the March 2026 re-proposal would have the largest US banks calculate “only one set of risk-based capital ratios” under an expanded risk-based approach.¹³ This comparison therefore applies under the Basel standard and in the EU and UK.

In practice, every in-scope exposure now runs through two calculation engines. The internal model uses the bank’s own estimates of default probability and loss, while the standardized engine applies prescribed risk weights to inputs such as LTV. Both engines must start with the same exposure, counterparty, and collateral record. When they draw on different copies of that data, the bank can’t explain the difference between the two figures, and a supervisor reviewing the comparison can’t separate model risk from a data error. A quarterly finance reconciliation catches a difference between the two totals, and attribute-level lineage shows which input field produced it.

To prove both engines start from one authoritative source, a bank needs lineage that spans both. A lineage tool built into one data platform can show the path through that platform’s pipelines, but it stops where the data leaves that platform for the other engine. Solidatus, a data lineage platform built for regulated enterprises, joins lineage from catalogs, data platforms, and legacy systems into one end-to-end lineage model so that a reviewer can trace a single exposure from its source fields through both calculations to the capital ratio.

A phased rule needs a record of every phase

Because Basel IV phases in, each year’s capital ratio is calculated under different rules. Between 2025 and 2030, an EU bank compares its internal-model figure with a rising percentage of its standardized figure while its source systems keep changing. FRTB arrives on its own schedule, now January 1, 2027, in the EU.¹⁴ A ratio reported in 2026 came from the 2026 percentage and the 2026 state of the data. When a supervisor asks in 2028 why that ratio moved, the bank has to reproduce the lineage as it stood in 2026, before two years of system changes rewrote it.

The ECB plans targeted on-site inspections of RDARR frameworks through 2028 for banks with severe or unresolved findings, which overlaps the middle of the EU phase-in.¹⁵ Most catalog and platform lineage records what their scanners last saw, so teams must rebuild an earlier state by hand from change logs. Solidatus stores lineage bi-temporally and keeps a version history of the lineage model, so a team can open the model as it stood on any reporting date and compare it with today’s. A supervisor’s questions about past ratios depend on that point-in-time lineage.

The version history also lets a team look ahead. Before an FRTB go-live, the team can model the data changes in a sandboxed copy of the lineage model and see which capital reports they touch before anything reaches production. One bank in a BCBS 239 program, anonymized in its published story, fed an Oracle data warehouse from 30 sources and cut change impact assessment from months to minutes once its lineage was mapped in Solidatus.

Where to start

Three steps let you use one lineage program to evidence both BCBS 239 and Basel IV.

1. Trace both calculation paths from the same source fields: Pick one portfolio, such as residential mortgages, and follow the exposure, counterparty, and collateral fields from source through the internal model and the standardized engine to the capital ratio. Map them at attribute level in one lineage model. Any field that reaches the two engines from different copies is the first thing to fix.
2. Link each Basel IV input to the BCBS 239 requirement it evidences: Attach business terms, owners, and the relevant principle or ECB expectation to the input fields in the same lineage model, so your capital team and risk data team work from one map. When a supervisor asks how an input is governed, the answer and the lineage are in one place.
3. Keep a dated version of the lineage for every reporting date: A versioned lineage model lets you reproduce the lineage behind each phase-in year’s ratio on request and test FRTB and other planned changes before they go live. The same history keeps BCBS 239 evidence reusable between exam cycles.

So does your BCBS 239 program already cover Basel IV? It covers the inputs, as long as its lineage reaches the capital ratio and records how that lineage looked on each reporting date. For the full set of supervisory expectations, including what an ECB targeted inspection examines, download our white paper, [Thirteen years of BCBS 239: what examiners are asking for]([WHITE PAPER LINK]). Our BCBS 239 page explains how Solidatus supports each of the principles.