There is a rule that has been on the books for over a decade, and almost nobody outside of risk and compliance teams has ever heard of it: BCBS 239. It is not a catchy name. But the idea behind it is one of the more sensible things to come out of the post-2008 regulatory response: banks should be able to explain where their risk numbers come from.
Not approximate. Not eventually. Be able to trace a number back to its source, on demand, and show the path it took to get there.
That standard came into force for the world’s largest banks in January 2016. Almost ten years later, only a handful of the 31 global systemically important banks (G-SIBs) have reported full compliance. And the cost of falling short is no longer theoretical: the penalties for BCBS 239 failures now run into the billions. The ECB’s RDARR Guide, published in May 2024, named data lineage as one of seven priority areas still holding institutions back, and said it expects remediation work to continue through 2027.
I want to make the case that this isn’t a story about banks dragging their feet, or regulators failing to enforce something. It’s a story about a rule that was right, running into a technical wall that was real.
The wall was real
If you’ve spent time around a bank’s core systems, you already know what the wall looks like. Decades of COBOL or RPG, written and rewritten by people who retired years ago, running calculations that nobody currently on staff can fully explain. Ask a team to trace how a specific risk figure was derived, and the honest answer is often: we’d need a few months, and a few of our most senior mainframe engineers — who are also the people we can least afford to pull onto this.
That’s not a compliance excuse. It’s a real description of how these systems work. Logic gets buried inside modules that branch into other modules, which branch into more, written in a language most engineering schools stopped teaching in the 1990s.
So banks have been stuck between a standard they understand and largely agree with, and infrastructure that makes meeting it genuinely hard. Regulators have been patient about this — I think correctly — because the alternative, demanding visibility into systems that were close to a black box, wasn’t realistic.
What’s changed
I run a company called Zengines. We built technology specifically to deal with this wall: parsing legacy code at scale, tracing how data moves through mainframes and AS/400 applications, and surfacing the business logic that’s been buried inside them for decades — with the context needed to make it usable.
At one Fortune 100 financial institution, we’re currently working through hundreds of thousands of COBOL modules, some of them tens of thousands of lines deep, netting out to tens of millions of lines of code. Questions that used to take a mainframe specialist months to answer — tracing a variable by hand through branch after branch — can now be answered in seconds. An analyst can ask the system directly where a number came from, instead of opening a ticket and waiting. That same self-service access lets teams build their own understanding, and answer questions from regulators and transformation programs directly.
I’m not suggesting this solves everything BCBS 239 asks for. Governance, and the behavioral discipline of actually using data management tools once you have them — those still take sustained organizational effort, and always will.
But the specific claim that legacy mainframes are too opaque to document fully? That claim is no longer true, at least not in the way it used to be.
Why this matters beyond one regulation
I’d guess most people reading this don’t work in regulatory compliance.
If you’re a CDO, a CIO, or a risk leader at a bank with a mainframe at its core, BCBS 239 is probably one item on a long list. But the underlying question — can we actually explain how our own systems work? — isn’t a regulatory question. It’s a basic operational one. It’s the same question that determines whether you can trust the data going into a new AI initiative, whether you can defend a number in front of your own board, and whether the next system migration breaks something nobody saw coming.
Lineage has quietly become a prerequisite for almost everything banks are now trying to do with their data. Most executives don’t ask for it directly, because they don’t think to ask — they ask for the AI use case, or the modernization roadmap, or the faster reporting cycle, and lineage turns out to be the thing standing between them and any of it.
Where I land
I don’t think this is a story that needs villains. The standard was right. The barrier was real. What’s changed is narrower, and more hopeful: the wall that made the standard so hard to meet has a way through it now.
If you’re a regulator, I’d offer this as something worth knowing: the technical excuse has less weight than it used to. If you’re an executive at a bank still living with this problem, I’d offer something more direct — this is more solvable, and more quickly, than you’ve been told.
Either way, the goal was never the regulation itself. It was being able to look at your own systems and actually understand them. That’s now a lot closer than it’s been in years.
Sincerely,
Caitlyn Truong
CEO, Zengines