On 18 May the Bank of England, the Financial Conduct Authority, and HM Treasury put their names to a single sentence that does not usually appear in financial-stability literature: "the cyber capabilities of current frontier AI models are already exceeding what a skilled practitioner could achieve". The three named the risk together, which is the part that matters. When the central bank, the conduct regulator, and the Treasury all sign the same piece of paper, the next thing that happens is that supervised firms are asked what they have done about it.
If you sell software, payroll, professional services, or anything that touches data into a regulated firm, you are about to feel the consequence of that joint statement. The diligence questions and the contract clauses will change before the rules do.
What the three actually said
The joint statement frames frontier AI not as a future risk but as a present one. The capabilities are here, the cost of using them is low, the speed is high, and the people who currently struggle to defend their network are the same people who are now defending it against a faster attacker. The statement names four areas of exposure: firm safety and soundness, consumer protection, market integrity, and financial stability itself.
The actions it expects are not novel in isolation. What is new is that they are now grouped and asked for together.
- Boards understand the risk. Not the chief information security officer alone, not a one-off briefing, but a continuing board-level understanding of what frontier AI changes for the firm and its suppliers.
- Vulnerabilities are triaged and remediated faster. The statement is explicit that this needs to happen "at scale", which is regulator language for "with automation, because the attackers have it".
- Third-party and open-source risk is actively managed. Including the vendors of the vendors. The supply chain is back in scope.
- Access controls, network security, and data protection are layered, not single-point. And AI-enabled defences are expected, not optional.
- Response and recovery plans are tested. The October 2025 Bank of England guidance on disruption response is referenced as the baseline.
The Cross Market Operational Resilience Group is the venue the three will use to keep pressing on this. That is the same body that drove the recent operational-resilience and outsourcing rules. If you have already seen those rules turn into supplier questionnaires, expect this one to follow the same path.
Why this lands on SMEs that are not regulated
Most UK SMEs are not directly supervised by the Bank or the FCA. The route in is the customer.
A regulated firm cannot offload its risk by outsourcing it. If your software is part of how a bank, an insurer, a wealth manager, or a payment firm meets its obligations, then your security posture is part of theirs. That is already how operational resilience works. It is how the new statement will work too.
What this looks like in practice for a smaller supplier:
- The annual security questionnaire grows a section on AI use, AI risk management, and AI-related supplier risk. You will be asked which models you use, what you do with customer data inside them, and what controls you have on the answers.
- The "vulnerability management" section gets sharper. Time-to-patch starts being asked for as a number, not a yes/no, and the question is no longer "do you patch criticals quickly" but "do you patch what attackers actually exploit, quickly".
- A right-to-audit clause is more likely to appear, or to be exercised if it already exists. The clause was always there; nobody used it. That is changing.
- The contract starts naming "frontier AI" specifically, sometimes badly, alongside the usual confidentiality and data-protection terms. Read what you are being asked to sign.
None of this is a reason to refuse the work. It is a reason to have the answers ready before the questions arrive.
What to actually do
If you sell into financial services or to anyone who does, three things are worth doing this quarter.
Write down your AI use, even if it is short. A page covering: which AI tools the business uses, what data goes into them, who is allowed to use them for what, and what would happen if the answer they gave was wrong. The board-understanding ask in the statement is really an ask for "the board can describe this in plain English on demand". The page is for them, not for the regulator.
Sharpen your vulnerability process. Not "we run a scanner". The question worth answering is: when CVE-X is published on a Tuesday, who decides whether it affects you, and by Friday is it patched. If the answer is "we don't know", that is what the diligence cycle is going to surface. Our filing on the only SOC metric that matters covers this in more detail.
Pull together a short supplier list with risk notes. Who you use for hosting, identity, payroll, accounting, CRM. For each: what data they hold, how you would notice if they were breached, what your contract says about notice. The supply-chain ask in the statement is the one that turns into supplier-of-supplier questions, and the firms above you will start asking.
The point of getting ahead of this is not to pass the questionnaire. It is to not have to drop a project for two weeks to write fifteen pages of policy when a customer's procurement team asks. Spend a day now and have the answers ready.
How Steelwise can help
Drafting the short AI-use page, the vulnerability-triage process, and the supplier list, in a form that lands well with financial services procurement, is something we do with clients. Get in touch.
Further reading
- Bank of England: Operational resilience policy
- FCA: PS21/3 Building operational resilience
- NCSC: Guidelines for secure AI system development