Project · Financial services
Regulatory reporting fabric
Replacing a nine-day spreadsheet reporting cycle with a governed data platform that made every reported figure traceable to its source.
The operating problem.
A financial services group produced a monthly regulatory return from eleven source systems. The process had evolved over a decade: extracts were pulled into spreadsheets, transformed by a small finance function and reconciled manually before submission.
The return was materially correct, but the control environment depended on individual knowledge. The finance function knew which adjustments were needed and why; the documentation did not. When a source system changed, the effect was discovered during the reporting cycle.
The organisation’s risk function wanted a reporting process that could be evidenced. The finance function wanted to stop spending the first week of every month on reconciliation. Both objectives pointed to the same solution: a governed data platform with explicit rules and lineage.
The challenge.
The visible problem was fragmented technology. The underlying problem was a process that depended on individual compensation.
- Eleven source systems had different definitions, period logic and data quality characteristics.
- Transformations and adjustments lived in spreadsheets with limited version control.
- The lineage from reported figure to source transaction was reconstructed manually for audit.
- A source-system change could alter the reported number without a clear impact assessment.
What we found
The largest risk was not calculation error. It was definitional drift: the same term meant slightly different things in different source systems, and the adjustment logic compensated for the difference without documenting it.
The finance function had strong knowledge of the rules but no single place to see them. The control was personal, not systemic. That is a fragile position for any regulated process.
A parallel run would be essential. The organisation needed to see that the new platform produced the same result before it could retire the spreadsheet process.
How the work was structured.
Each stage produced a decision or an artefact that the next stage could rely on.
Document the reporting chain
Map every source, transformation, adjustment and report line, including the informal steps that made the numbers reconcile.
Define the governed data model
Create conformed entities, period logic and versioned calculation rules with named business owners.
Build the platform
Ingest source data with contracts, validate quality, apply transformation logic and store lineage at each step.
Reconcile in parallel
Run the new and old processes together for two cycles, investigate every difference and document the explanation.
Transition ownership
Move rule ownership to the finance function with a controlled change process and evidence pack for audit.
Difficult problems and how we resolved them.
The delivery was not a straight line. These are the issues that required a design decision rather than a task.
The same term was defined differently across source systems.
We created a business glossary with explicit definitions and owners. Where definitions could not be reconciled, the platform stored the source-specific value and applied a documented mapping rather than forcing a false consistency.
Adjustment logic was held in spreadsheets and individual memory.
We reverse-engineered each adjustment, documented its purpose and converted it into a versioned rule with a test. The finance function reviewed and signed off each rule before it was used in the parallel run.
The first parallel run produced a material difference.
The difference traced to a period-cutoff rule that had been applied manually in the old process. The discovery validated the approach: the new platform made a hidden rule visible. The rule was documented, approved and added to the test pack.
Audit evidence was historically assembled after the fact.
We designed lineage, reconciliation results and sign-off records to be produced as part of the reporting run. The evidence pack became an output of the process, not a separate project.
The result in operational terms.
Measures were agreed with the client before delivery and compared against a baseline. The figures below are client-reported.
The reporting cycle fell from nine days to two. The finance function shifted from assembling and reconciling data to reviewing exceptions and signing off results.
The platform also reduced change risk. A source-system change now triggers an impact assessment against the documented contracts and tests, rather than being discovered when the next return is produced.
What we would do differently.
Every engagement produces lessons. A project page that only reports success is not useful to the next client.
- A parallel run is a control, not a delay. It is where hidden rules become visible.
- Business ownership of definitions is essential; a platform function cannot resolve meaning by itself.
- Audit evidence should be a by-product of operation, not a reconstruction exercise.
These lessons have been incorporated into how we scope and run similar engagements. They are part of the reason the approach pages are specific about decision points and exit criteria.
The disciplines behind the result.
Projects rarely use one capability in isolation. The links below show where the work sits.
A parallel run is an assurance product.
The parallel run was originally planned as a validation step. It became the most important assurance artefact of the programme. It exposed a period-cutoff rule that had been applied manually for years and gave the finance function evidence that the new platform produced the same result for explainable reasons.
Running two processes is expensive, but it is cheaper than discovering a hidden rule after the old process has been retired. The key is to treat every difference as a finding: document it, assign an owner and decide whether the new or old behaviour is correct.
The lesson applies beyond regulatory reporting. When a process has depended on individual knowledge, a parallel run is how the organisation converts that knowledge into a controlled, testable rule.
Have a similar constraint?
Tell us what is not working. We will help you define a first step that produces evidence, not just activity.