- All operational data sat in SQL Server; every report was pulled into Excel and assembled by hand, every month.
- Every figure was “as of now” — no way to see the book as it stood at a past date, so nothing could be tracked month on month.
- Definitions varied between spreadsheets, so every new question from the board, a client or the FCA meant starting again.
- A nightly automated feed into Google BigQuery, in their own cloud environment.
- 30+ governed views encoding the business's definitions once — revenue, collections, contact, service, Consumer Duty.
- Point-in-time history across the whole book: any figure, reconstructed at any month-end.
- A reporting suite on top: an FCA Consumer Duty board report, a monthly client pack with a full audit trail, an operations pack that generates its own board PDF, and per-client reports — all in DRA's own brand.
- Claude wired into the governed layer, with personal data kept out of it, so the reporting suite is prompt-driven and the team change their own reports.
- Monthly packs that took days to assemble are produced in minutes, and every figure traces to a governed definition.
- Consumer Duty MI went from a once-a-year exercise to standing monthly measurement across roughly 60 metrics per client.
- New questions are answered from the platform in hours — including ones the old reporting could not see at all.
- Claude is now used across the organisation rather than in development alone, because it finally has governed data and business context to reason over.
“As of now” is not a reporting position
The Digital DRA manages customer accounts at scale for energy, telecoms and consumer-finance clients. All of the operational data sat in SQL Server, and every report came out of it into Excel, by hand, every month.
The bigger problem was not the assembly work. It was that every figure was as of now. There was no way to see the book as it stood at a past month-end — so nothing could be tracked month on month. Not arrears movement, not collections performance, not whether a treatment was working.
That is a reporting gap that quietly becomes a regulatory one. Consumer Duty asks you to demonstrate outcomes over time. If your systems only hold today, you cannot show a trend, because the trend was never stored.
A system that holds today's position holds no history. There is nothing to trend, because nothing was kept.
The definitions were the real work
Definitions varied between spreadsheets. So every new question — from the board, a client, or the FCA — started from scratch, and the answer depended on which workbook you asked.
This is where reporting projects actually fail, and it is not a tooling problem. We encoded the definitions once, as 30+ governed views: revenue, collections, contact, service, Consumer Duty. One place where “an account in arrears” means one thing.
Then the part that made it trustworthy on day one: every figure was validated against the client's existing board numbers before go-live. Not reconciled afterwards — matched first, so nobody had to take the new platform on faith.
Point-in-time history for the whole book
A nightly feed lands the data in their own BigQuery environment, with snapshot history behind it, so any figure can be reconstructed at any month-end.
That single capability is what turned a monthly assembly job into a platform. Once the past is stored properly, “how did this look in March” stops being an archaeology project.
Seven reporting products now run on top of it: an FCA Consumer Duty board report, a monthly client pack with a full audit trail, an operations pack that generates its own board PDF, and per-client reports — all in DRA's own brand.
It was built with their team, not around them
DRA's team built the nightly feed and supplied the operational knowledge. We designed the data model, encoded and reconciled the definitions, and shipped the reporting suite iteratively.
That split matters. The operational knowledge — why a number moves, which exception matters, what a client needs to see — was already in the building. It usually is. What was missing was somewhere to put it.
Then we gave it to Claude
A governed layer with the definitions written down and personal data stripped out is exactly what an AI assistant needs and almost never gets. Point a model at a folder of spreadsheets and it answers confidently from whichever one it was handed. Point it at a layer where “an account in arrears” has one meaning, and it reasons over the business.
So the reporting suite became prompt-driven. Tom Hill, their COO, changes his own reports — no ticket, no developer, no waiting for us. Claude is now used across the organisation rather than in one corner of it.
The technology was available to them before we arrived. What was missing was the layer underneath it.
What we handed over
We showed our work throughout, validated every number against what they already trusted, and handed over a platform they own outright in their own cloud environment.
That is the model. We set it up properly, and you take it as far as you want — with us, or on your own. The measure of the engagement is not how long we stay.
If your regulatory reporting is assembled by hand every month, and your systems only hold today's position, the problem is not the spreadsheet. It is that nothing underneath it was ever built. Three months is a realistic timeline for fixing that.