A UK retail bank owned by a supermarket group: re-platforming regulated journeys onto governed Azure
A UK retail bank owned by a supermarket group ran its customer journeys and core supporting services on ageing on-premises infrastructure, integrated by overnight batch, with releases gated by manual provisioning and regression. Unolabs delivered the FCA-aligned Azure landing zone, re-platformed journeys onto AKS, replaced batch with event-driven integration and built a Purview-governed single customer view — without pausing regulated services. Named identity withheld; available to evaluators on request under NDA.
A concise view of impact and engineering focus.
FCA-aligned enterprise-scale Azure landing zone
Overnight batch replaced by event-driven integration
Purview-governed single customer view
Three constraints that shaped every decision
The bank offers personal loans, credit cards, savings, insurance distribution and travel money under a supermarket brand. Its customer-facing journeys and the services behind them ran on ageing on-premises infrastructure, integrated through overnight batch, with digital change held up by manual environment provisioning and regression cycles measured in weeks.
Three constraints set the shape of the work. Regulated change on live money journeys: payments, lending decisions and card servicing could not stop, so every step had to preserve continuity of a regulated service. Fragmented customer data: loans, cards, savings and insurance each held their own customer records, so there was no single view for service, marketing or risk. And a release path slow enough that the cost of change was itself a resilience concern — a control you cannot deploy quickly is a control you deploy late.
The landing zone was therefore designed against FCA and PRA operational-resilience expectations from the first decision rather than assessed against them at the end.
A control you cannot deploy quickly is a control you deploy late. Release speed is an operational-resilience concern, not only an engineering one.
Why event-driven integration, and what it replaced
Overnight batch is not merely slow. It sets the granularity at which the bank can know anything: a customer's position is accurate as of the last run, and every downstream decision inherits that staleness. For servicing that is inconvenient; for risk and fraud it is a control weakness.
Integration moved to Service Bus and Event Grid, with journeys re-platformed onto AKS behind API Management. The point of the change was not throughput but currency — a decision made on a customer's state can now be made on that state rather than on last night's copy of it.
The migration sequence mattered more than the target architecture. Each journey moved with its regulated service continuous, which meant running old and new paths together and cutting over on evidence rather than on a date. That is slower than a clean replacement and it is the only version of this that is available to a regulated lender.
Batch does not just slow a bank down. It sets the granularity at which the bank can know anything, and every downstream decision inherits that staleness.
A single customer view is a governance artefact before it is a data one
Loans, cards, savings and insurance each held their own customer records. Assembling one view across them is straightforward as an engineering exercise and difficult as a governance one, because the question is not how to join the records but who is permitted to see the joined result and for what purpose.
The view was built on Azure Databricks over ADLS Gen2 and governed in Microsoft Purview, with classification and lineage maintained as part of the platform rather than documented alongside it. UK-GDPR purpose limitation is the constraint that does the most work here: a customer record assembled for servicing is not automatically available for marketing, and the platform has to be able to demonstrate that distinction rather than assert it.
Machine learning services were aligned to SS1/23, which sets expectations for model risk management. That alignment is easier to hold when lineage already exists as a platform property — a model's inputs can be evidenced rather than reconstructed.
The hard part of a single customer view is not joining the records. It is demonstrating who may see the joined result, and for what purpose.
What the estate now supports
The bank runs on an enterprise-scale Azure landing zone with Entra ID, AKS and API Management carrying the journeys, Service Bus and Event Grid carrying integration, Databricks and ADLS Gen2 holding the data estate, and Purview governing it. Terraform and Azure DevOps carry provisioning and release; Microsoft Sentinel and Defender for Cloud carry the security posture.
The combination that matters is not any single service but that provisioning, governance and security are all expressed as code in the same delivery path. A regulated change now moves through one route with its evidence attached, instead of through a manual process that generates evidence afterwards.
What we would flag: a landing zone aligned to a regulatory expectation on the day it is built stays aligned only if the alignment is tested. Operational resilience expectations are assessed against behaviour under stress, not against architecture diagrams, and the value of this estate depends on the bank continuing to exercise it that way.
What we'd flag: resilience expectations are assessed against behaviour under stress, not against architecture diagrams. A landing zone stays aligned only if the alignment is exercised.
What to carry into the next sprint
Takeaway
In a regulated lender, migrate on evidence rather than on a date — old and new paths run together until the evidence exists.
Takeaway
Batch integration is a control weakness, not only a latency problem: every decision inherits last night's view.
Takeaway
A single customer view is governed before it is joined — purpose limitation decides what the join is allowed to serve.
Frequently asked questions
- How do you re-platform journeys that cannot be paused?
- By running the old and new paths together and cutting over on evidence rather than on a scheduled date. Payments, lending decisions and card servicing stay continuous throughout, which makes the sequence slower than a clean replacement. For a regulated lender it is the only available version.
- Why replace overnight batch if the bank was operating on it already?
- Because batch sets the granularity at which the bank can know anything. A customer's position is accurate as of the last run, and every downstream decision — servicing, risk, fraud — inherits that staleness. Moving to event-driven integration was about currency of state rather than throughput.
- What does Purview actually govern here?
- Classification and lineage across the data estate, maintained as a property of the platform rather than as documentation beside it. That matters most for UK-GDPR purpose limitation: a customer record assembled for servicing is not automatically available for marketing, and the platform has to demonstrate that distinction rather than assert it.
- How does SS1/23 alignment affect the data platform?
- SS1/23 sets expectations for model risk management, which in practice means being able to evidence what a model was trained and scored on. That is considerably easier when lineage already exists as a platform property, because a model's inputs can be evidenced rather than reconstructed after the fact.
- Are the programme's outcome figures published?
- Not here. The internal write-up is a draft and its quantified figures are pending verification, so they are not published on this page. The architecture, the regulatory frame and the delivery sequence described above are accurate; specific figures are available to evaluators on request, once confirmed.
Modernise without spending your regulatory posture
We will map your journeys against FCA and PRA operational-resilience expectations, identify which integration points are control weaknesses rather than latency problems, and sequence a migration that keeps regulated services continuous.
Book a Regulated Cloud Review