When the attack isn't on the bank

Ask most people to picture a cyberattack on a bank, and they'll think of something dramatic: a hacker breaking into a mainframe, customer accounts drained overnight or a headline about millions of records stolen. That picture isn't wrong, but it's increasingly incomplete. Some of the most serious risks facing UK retail banks in 2026 don't involve anyone breaking into the bank at all. They involve someone breaking into, or simply disrupting, the handful of companies the bank depends on to function.

On 13 July this year, the Bank of England, the Prudential Regulation Authority and the FCA began jointly overseeing the first firms designated as Critical Third Parties under new powers granted by the Financial Services and Markets Act. The first four names on that list are familiar to anyone in IT: Amazon Web Services, Google Cloud, Microsoft and Oracle. For the first time, UK regulators have formal oversight not just of banks, but of the infrastructure providers underneath them.

That's a significant moment, and it’s worth pausing to consider why it happened. The regulators’ own reasoning is refreshingly blunt: so many financial firms now rely on the same small group of technology providers that a serious outage or compromise at one of them could ripple across the whole sector simultaneously, hitting multiple banks, markets and millions of ordinary customers at once. In other words, the concentration itself has become the risk. It doesn't take a sophisticated nation-state actor exploiting some coordinated flaw. It just takes one bad day at one supplier.

How banks got here

Retail banking hasn't looked like a single, self-contained institution for a long time. Behind the app on your phone sits a tangle of cloud infrastructure, outsourced payment processors, open banking APIs, fraud-detection vendors and fintech partnerships, often layered on top of core banking platforms that were never designed with any of this in mind. It's a sensible way to build a modern bank. It's also a much bigger attack surface than the one a bank had twenty years ago, and a lot of it sits outside the bank's own walls.

Attackers have clearly noticed this shift too. Where cybercriminals used to focus mainly on stealing data or money directly from a bank, there's a growing pattern of activity aimed at disrupting the underlying machinery instead: payment systems, core banking infrastructure, the messaging layers that let banks talk to each other. Some of this is criminal, some of it looks distinctly geopolitical, with financial infrastructure increasingly treated as a strategic target in wider conflicts between states. Either way, the target has moved up the stack, from the account to the plumbing.

And you don't even need malicious intent for that plumbing to fail. https://www.crowdstrike.com/en-us/blog/channel-file-291-rca-available/ in the summer of 2024 is the example everyone in IT remembers, not because anyone attacked anything, but because a single faulty update took down services across airlines, hospitals and, yes, banks, all at once. A concentrated supply chain doesn't need an attacker to become a single point of failure, it just needs a bug.

What the new rules actually change

It would be easy to read the Critical Third Parties (CTP) regime as something that only affect AWS, Google, Microsoft and Oracle. It doesn't. The regulators have been clear that CTP oversight complements a bank's own responsibilities for managing third-party risk rather than replacing them. Being designated doesn't let a bank off the hook for knowing what it's exposed to.

There's a more immediate deadline worth having on your radar too. The FCA published its policy statement on operational incident and third-party reporting back in March, and the rules attached to it come into force on 18 March 2027. From that point, in-scope firms will need to maintain and submit annual registers of their material third-party arrangements. If you don't already have a clear, current picture of which suppliers your critical business services actually depend on, eighteen months isn't as long as it sounds, especially once you factor in how tangled some of these dependency chains turn out to be once you start mapping them properly.

Firms with any EU exposure are dealing with a parallel set of obligations under DORA, and while UK and EU regulators have set up a memorandum of understanding to coordinate oversight of shared third parties, it's a coordination mechanism rather than mutual recognition. The two regimes stay separate. That's more work, not less, for anyone straddling both.

What good actually looks like

None of this means panicking about cloud concentration or trying to single-handedly solve a sector-wide structural issue. It means treating third-party resilience as seriously as you treat your own perimeter, because increasingly they're the same problem.

A few things are worth prioritising:

• Start by mapping which of your important business services actually depend on which suppliers, all the way down the chain, not just the ones you contract with directly.
• Build (or dust off) a register of material third-party arrangements now rather than in the eighteenth month of a twenty-four month deadline.
• Test your failover and exit plans properly rather than leaving them as documents nobody has actually rehearsed, because a plan that's never been tested tends to fall apart at exactly the moment you need it.
• Extend your scenario planning beyond the usual phishing and ransomware drills to include the boring but plausible stuff: your primary cloud region goes down, your payment processor is compromised, a critical supplier suffers an outage with no attacker in sight.

The uncomfortable truth is that a modern retail bank's resilience is only as good as the resilience of the suppliers it has quietly become dependent on. Regulators have finally said as much in law. The question for every bank now is whether their own risk register says the same thing.

If you’d like to find out more about our retail banking solutions, please click here.