The code behind a regulatory figure should be something the business can question

The business owns the regulatory outcome. It rarely built the systems that produce it. The rules that turn source data into the reported figure sit in code repositories, spread across applications and languages, written over years by engineers who are seldom in the room when the regulatory process is discussed.

So every question about how a figure was produced goes back to the developers. When confidence thins, the institution pays a third party to explain its own estate to it, and the answer is out of date as soon as the code changes.

Reading the code is not the hard part

Code-reading and rule-extraction tools exist and are improving. What they produce is a document about the code: rules with no owner, no version and no approval, and none of what was never written down. The spreadsheet a team has maintained for years, the adjustment applied at quarter end and the judgement that never became a rule are all part of how the process runs, and a parser cannot see them.

Joining the code to the process

xflow's engineers start from the repositories, take the transformations out of the code and join them to the picture the institution already holds: its lineage, business terms, catalogue and documented process. The gaps the join exposes are located, assessed and closed, and the corrections are written back to the catalogue.

At a G-SIB, the first code repository was read in a day, and executable end-to-end regulatory lineage from policy to process to code to data followed in under two weeks. The code became something the business could question in its own terms: which applications and tables are involved, what each transformation does, and where the code applies a rule differently from the approved definition.