FCA says payment resilience now depends on shared infrastructure
The FCA says operational resilience is now a network problem, not just a firm-level one, because banks and payment firms rely on common third-party providers.

The UK Financial Conduct Authority said on 28 July 2026 that operational resilience is no longer just a question for one bank or one payment firm. It is now a network issue, because banks, insurers, payment firms and financial market infrastructures increasingly depend on a small number of shared third-party providers. The FCA said that matters because a failure in common infrastructure can affect many firms at once.
That is the core shift in the regulator’s message. Most users never think about the infrastructure behind a payment, a transfer or a banking login until something breaks. But the services that support those everyday actions often sit on top of the same technology, data and operational providers. As the FCA put it, this is about “strengthening resilience across the wider network” source.
The FCA also said the UK government granted powers for a new oversight regime and designated the first critical third parties. In practice, that means the Bank of England, PRA and FCA will directly oversee those providers with a targeted focus on resilience. The regulator said the aim is to address system-level risks and improve coordination and information-sharing during major incidents.
For fintech and payments teams, the practical takeaway is simple. Vendor due diligence is not a one-time procurement exercise. If a product depends on banking rails, hosted infrastructure, cloud services, payment processors or data providers, the real question is how many downstream workflows rely on the same external layer. That matters for settlement timing, reconciliation, payout processing and customer communications when an outage hits.
What operators should watch
The main limitation in the FCA’s framing is that stronger oversight of critical third parties does not remove concentration risk. The regulator is explicit that many firms rely on the same services from common providers, which means an incident can still cascade across the market. The practical response is to map dependencies, define fallback procedures and make sure finance, operations and engineering know who owns each part of the response.
That is especially relevant for businesses that move money across multiple rails. A team may think it has separate controls for collections, settlement and payouts, but those functions can still share the same upstream provider or operational dependency. If the shared layer fails, the business needs clear rules for pausing flows, reconciling balances and informing customers or counterparties.
The FCA also pointed to a broader trade-off. Shared providers can support innovation, efficiency and better services, but they also create a common failure domain. Recent incidents have shown how interconnected modern services have become, which is why resilience planning now has to include third-party concentration and incident coordination, not just internal uptime targets.
Why this matters for payment and treasury teams
For businesses that operate across fiat and digital asset rails, resilience is part of product design. Virtual accounts, settlement workflows and payout systems are only as reliable as the infrastructure beneath them. If a finance team cannot attribute incoming funds, move balances or trigger payouts during an incident, the problem quickly becomes operational and commercial, not just technical.
That is why teams increasingly evaluate payment infrastructure on control as much as speed. Radom’s virtual accounts product is built around attributable fiat collection and crypto settlement workflows, which is one way to keep reconciliation cleaner when funds move across multiple rails.
The next watchpoint is whether regulators push further on how common providers are supervised and how firms evidence resilience across shared dependencies. For operators, the useful response is already clear: know your upstream concentration, test failure paths and keep treasury and payout operations visible enough that one provider outage does not become a business-wide outage.
Sources
Want more analysis like this?
