The cloud providers your regulator just started watching

Here's a small exercise. Pick one critical business service your bank runs — real-time payments, say, or your credit decisioning engine. Now trace it back: which cloud provider hosts it? Which region? If that provider had a multi-region outage at 2pm on a Tuesday, how long before your service is back? Who in your organisation knows the answer without checking?

If you paused on any of those, you're in good company. Most mid-market banks I've worked with can name their cloud provider. Fewer can map which critical services sit on it. Almost none can tell you, quickly, what happens when it goes down.

As of 13 July, that gap has a regulator-shaped spotlight on it.

HM Treasury designated four cloud hyperscalers — AWS, Google Cloud, Microsoft Azure, and Oracle — as the UK's first Critical Third Parties to the financial system. The Bank of England, PRA, and FCA now have direct joint oversight of these providers. That means the regulators can require resilience testing, demand self-assessments, and expect incident reporting — powers they've never had over technology suppliers before.

This isn't a consultation. It's live.

The regime has been coming for a while — the Financial Services and Markets Act 2023 created the legal framework, and the regulators published their final rules in November 2024. But designation makes it real. The four providers are now, formally, part of the supervisory perimeter.

The obvious read is that this is about the cloud providers. They're the ones being regulated. Your ops-resilience team files it under "third-party risk management," updates a policy document, and moves on.

That's the wrong read.

The CTP regime doesn't just regulate the providers — it creates an implicit expectation that you know your own dependency chain. When your supervisor asks how exposed you are to a single designated CTP, "we use Azure" is not an answer. They want to know which of your important business services — as defined under SS1/21 — run on which provider, in which region, with what failover, and what your recovery time looks like if that provider is degraded for 48 hours.

Many mid-market banks I've spoken to don't have that mapping in a single place. They have pieces of it — a vendor register here, an architecture diagram there, a contract summary somewhere in procurement. But nobody has stitched it together into something a supervisor could look at and say "right, I understand your concentration."

That's the actual work this designation creates. Not a new policy. A map.

I keep coming back to the same pattern. A problem that looks like it needs a platform turns out to need a spreadsheet and someone who knows where the architecture docs live.

The dependency map for a typical mid-market bank — in my experience, usually 15–25 important business services — is not a massive data engineering exercise. It's a structured inventory: for each important business service, list the underlying technology components, the hosting provider, the region, the contractual SLA, and the internal recovery-time objective. Cross-reference against your designated CTPs. The thing that usually works is flagging any service where a single CTP failure would breach your impact tolerance, and then working backwards from there.

In most cases, yes. The information exists. It's just scattered across teams who don't normally talk to each other — infrastructure, procurement, operational resilience, and the business owners of each service. The hard part isn't the analysis. It's getting four people in a room.

Once you have the map, the uncomfortable finding is usually concentration. Not "we use one cloud provider" — everyone knows that already. The uncomfortable finding is that your payments service, your credit engine, your regulatory reporting pipeline, and your customer portal all sit on the same provider, in the same region, with no tested failover to a second provider.

I'll be honest: I've been part of producing exactly this kind of map before, and the moment you lay it out on a whiteboard the room goes quiet. Not because anyone is surprised — most people in the room already suspected the answer. They just hadn't wanted to see it written down, because once it's written down somebody has to do something about it. The real obstacle to dependency mapping isn't technical complexity. It's organisational embarrassment.

HM Treasury noted that over 65% of UK financial firms rely on these four providers. That's not surprising. What matters is whether you know how much of your operation depends on one of them, and whether you've tested what happens when it isn't there.

The regulators aren't going to tell you to move off your cloud provider. That's not the point. The point is that you should be able to articulate the risk, demonstrate you've tested your resilience against it, and show you have a credible plan if things go wrong. If you can't do that today, the CTP designation just made it more urgent.

This week, ask your head of technology or your operational resilience lead one question: do we have a single document that maps each of our important business services to its hosting provider, region, and recovery-time objective? If the answer is no — or "sort of, but it's out of date" — that's your Monday morning task. Not buying a tool. Not commissioning a project. Getting the four people who collectively hold this information into a room, with a whiteboard, and producing a map you could hand to a supervisor. It won't be pretty. It doesn't need to be. It needs to exist.

— Aksel

The Analytical Banker is a weekly note on data, analytics, and AI inside corporate banking — written for finance leaders who actually have to make this stuff work. Reply to this email if something here resonates, or forward it to a colleague who'd benefit.