Thirteen Years After BCBS 239, Why Is Bank Risk Data Still so Hard to Trust?

In January 2013, the Basel Committee on Banking Supervision published a set of principles on how banks should aggregate and report risk data. The document became known as BCBS 239. It grew out of an uncomfortable lesson from the 2008 crisis, when many large banks could not tell their own boards, quickly and accurately, how exposed they were to a single counterparty.

Global systemically important banks were expected to comply by 2016. When the Basel Committee published its progress report in November 2023, it found that only two of the 31 banks it assessed were fully compliant. No single principle had been fully implemented across all of them.

So what is going wrong? These are some of the best-funded institutions in the world. Money is clearly not the missing ingredient.

The Problem Sits Underneath the Reports

The Basel Committee pointed to fragmented IT estates, legacy systems and manual processes as the main reasons for slow progress.

A risk report is only the last link in a long chain. Data starts life in a loan origination system, a trading book, a card processor or a treasury application. Each of these systems was usually bought or built at a different time, for a different purpose, by a different team. They often define a borrower, a counterparty or an exposure in slightly different ways. And every time data moves from one of them into a central store, somebody has written a transformation that decides how those differences get resolved.

Multiply that by hundreds of source systems and a few decades of mergers. You end up with a data estate where nobody can say with confidence why a figure in a board pack differs from the same figure in a regulatory return.

Where the Gaps Usually Show Up

Banks that struggle with risk data tend to share a few patterns.

Lineage is missing, or it lives in people's heads. When an auditor asks where a figure came from, the answer depends on which analyst happens to be on leave that week.

Reconciliation is done by hand. Spreadsheets bridge the gap between systems that were never designed to agree, and each spreadsheet quietly becomes a small, undocumented system of its own.

Ownership is unclear. The business assumes technology owns data quality, while technology assumes the business owns the definitions. So nobody owns the outcome.

Timeliness suffers under stress. A report that takes days to assemble in normal conditions is of little use in a crisis, which is exactly when supervisors want it.

What Good Data Engineering Changes

This is where disciplined data engineering services earn their keep. It involves building pipelines that record lineage automatically, so every figure can be traced back to its source without a detective hunt. It means agreeing on shared definitions for critical data elements and enforcing those definitions in code rather than in policy documents that few people read.

It also means running quality checks at the point where data enters a pipeline, not at the end where a report fails. A missing counterparty identifier is cheap to fix at ingestion. By the time it reaches a capital calculation, it has already done its damage.

Does all of this require rebuilding the data estate from scratch? Usually it does not. A more practical route is to pick the handful of risk measures that matter most to the board and the supervisor, trace every input behind them end to end, and fix what turns up.

Why This Matters Beyond Compliance

Banks now want to use machine learning in credit decisions, fraud detection and liquidity forecasting. Every one of those models depends on the same data that BCBS 239 was written to protect. A model trained on inconsistent and poorly traced data will produce decisions that are hard to explain, and supervisors are unlikely to accept that for long.

The groundwork BCBS 239 asks for turns out to be the same groundwork that any serious AI program inside a bank will need. Banks that have already done it will find the next few years a lot less painful than the ones that treated it as a reporting exercise.

Author - Shefali Vasave

Shefali manages content marketing at Opus Technologies, a domain-native engineering partner for banks, payment providers, and fintechs, and writes on the various aspects of financial institutions navigating change in a real-time, digital-first world.