The Basel Committee published BCBS 239 — "Principles for effective risk data aggregation and risk reporting" — in January 2013, in direct response to the financial crisis exposing how little visibility large banks actually had into their own risk exposures. It came into force for Globally Systemically Important Banks in 2016, with equivalent expectations extended to Domestically Systemically Important Banks by national regulators, including the PRA in the UK.
Its core demand is deceptively simple: a bank must be able to trace any number in a risk report back to its original source, through every system and transformation it passed through along the way. In practice, that chain of traceability — data lineage — breaks most often not in the core banking systems it was designed for, but in the manual spreadsheets and offline processes sitting quietly between them.
A decade of implementation has not closed this gap. It has mostly relocated it.
Why data lineage became a regulatory requirement
Before the 2008 financial crisis, few regulators asked banks a question as basic as: can you show us exactly where this number came from? When the crisis hit, many large banks discovered they could not answer it quickly enough — risk exposures were aggregated from fragmented systems, reconciled manually, and reported with limited ability to trace a figure back to its origin under stress.
BCBS 239 was the Basel Committee's response. It sets out 14 principles across four areas — governance, risk data aggregation capabilities, risk reporting practices, and supervisory review — with the underlying expectation that a bank's risk data infrastructure should be accurate, complete, and fully traceable, especially when it matters most.
"Data lineage was never really about the technology. It was about being able to answer one question under pressure: where did this number actually come from?"
The principles were written with core banking and risk systems in mind — data warehouses, risk engines, regulatory reporting platforms. What they did not anticipate, or at least did not solve for, was how much of the "last mile" of risk reporting still runs through spreadsheets: manual adjustments, offline reconciliations, and bridge calculations sitting between the formal systems and the final report.
Where the lineage chain actually breaks
When you trace a risk report back through its lineage, the break rarely happens inside a core system. Core systems, whatever their flaws, are at least documented, owned, and subject to change control. The break happens at the handoff points — the moments where data leaves a governed system and passes through a human being with a spreadsheet.
None of these five points require a technology failure. Each one is a perfectly ordinary, well-intentioned human workaround — which is exactly why lineage tooling, built to trace systems rather than people, consistently misses them.
BCBS 239's data architecture and IT infrastructure principle expects banks to have systems capable of generating accurate risk data during business-as-usual and under stress, with minimal manual intervention. A January 2026 supervisory newsletter from the Basel Committee explicitly named data lineage as one of the recurring challenges raised in industry outreach sessions — more than a decade after the principles were first published.
For firms with material EUC assets sitting in the reporting chain, this is not a historic implementation problem that has been solved and moved past. It is a live, currently acknowledged supervisory concern.
Making the invisible handoffs visible.
A Greywood Analytics deconstruction engagement treats every EUC sitting inside a regulatory reporting chain as a lineage break point to be documented, not an inconvenience to be worked around. For each asset in scope, we deliver:
- Plain English Summary — what the asset does, what feeds it, and what it feeds into, in language a data governance team and a Board member can both use.
- Dependency Map — every upstream input and downstream output mapped explicitly, closing the exact gap that system-level lineage tools cannot see.
- Dependency Mapping Narrative — the reconciliation logic, manual adjustments, and version history written down in one place for the first time.
- Risk & Assumption Narrative — every undocumented assumption and manual intervention point identified and rated for materiality.
- Risk Register — a prioritised remediation plan your data governance and risk functions can act on immediately.
The result is a lineage record that actually reflects how the number got there — not just which systems it technically touched.
First deliverable pack typically received within 2–3 working days of engagement start.
Why this rarely gets fixed on its own
Nobody sets out to build an untraceable reporting chain. Each individual workaround was a reasonable response to a real, immediate problem — a system that didn't quite talk to another, a deadline that couldn't move, a reconciliation that had to happen somehow. The gap accumulates one small, sensible decision at a time.
That is precisely why it rarely gets fixed proactively. There is no single moment where someone decides to build an ungoverned reporting chain, so there is rarely a single moment where someone decides to fix it either — until an audit, a regulator, or a bad number forces the question.
"Lineage tooling tells you which systems a number passed through. It rarely tells you which person, and which spreadsheet, actually decided what that number would be."Greywood Analytics
If your data lineage documentation stops at the system boundary and starts trusting the humans in between, we should have a conversation. Every engagement begins with a no-commitment scoping discussion.
Start a Conversation