MCP in UK financial services: the FCA expects you to govern it under the rules you already have

If you are putting Model Context Protocol in front of core banking, trading, or customer systems in a regulated firm, the first thing to understand is that there is no AI rulebook coming — and the FCA has said so repeatedly. Its stance is technology-neutral: AI, and the MCP integrations that wire it into your systems, must be governed under the frameworks you already operate. That is not the relief it sounds like. It puts the onus on you to show that your existing controls already cover an autonomous system acting on regulated data — and the Treasury Select Committee's January 2026 report made clear the political patience for a light touch has limits.

This is not an argument against MCP. It is an argument for building it so that a named senior manager can stand behind it. The reassuring part: the secure build and the supervisable build are the same build. Here is the map.

"No new rules" is harder, not easier

Around three in four UK financial services firms already use AI, and the FCA, the Prudential Regulation Authority (PRA) and the Bank of England have held a principles-based line: no AI-specific regulation, govern AI under existing frameworks. In January 2026 the Treasury Select Committee published its report on AI in financial services and criticised the regulators for not doing enough — recommending the FCA publish practical guidance by the end of 2026 on how consumer-protection rules and senior-manager accountability apply to AI, alongside AI-specific stress testing. The FCA's own long-term "Mills Review," launched the same month, is examining whether the existing frameworks remain fit for an AI-enabled future.

The upshot for a deployment today: the compliance burden is already live. It is just expressed through rules written before MCP existed, which you are expected to apply yourself.

The four frameworks an MCP build has to satisfy

Operational Resilience. Firms in scope had to be able to operate their important business services within impact tolerances by 31 March 2025. An MCP server wired into a core service is now part of that service's resilience surface — a dependency that can fail, be overwhelmed by prompt storms or recursive requests, or behave unpredictably. It has to sit inside your impact-tolerance mapping, with failure and recovery planned. That is the same instinct as the NCSC's "plan for failure": design for reversibility and containment.

Senior Managers & Certification Regime (SM&CR) — personal accountability.The SM&CR is the FCA and PRA framework that ties named individuals to defined areas of a firm and makes them personally answerable for what happens there. This is the one that concentrates minds: a named senior manager is personally accountable for the systems within their remit. An MCP integration an agent uses to act on customer or trading data falls under someone's statement of responsibilities — which makes "we stood up an MCP server quickly" a personal-liability question, not merely an engineering one. Building it to evidence control is how that manager stays covered.

SYSC — the Systems and Controls sourcebook. SYSC is the part of the FCA Handbook that requires firms to maintain adequate risk management, governance, and record-keeping. For an MCP build, that means the audit trail the protocol does not produce by default.

Consumer Duty. Where the MCP-connected agent touches retail customers or their outcomes, the firm must be able to show it is delivering good outcomes and avoiding foreseeable harm.

Third-party concentration and the Critical Third Parties regime

In November 2024 the Bank, PRA and FCA published SS6/24, the policy for Critical Third Parties (CTP) to the UK financial system, aimed at concentration risk from providers that underpin the sector. The Treasury Committee has pushed for major AI and cloud providers to be designated under it by the end of 2026.

The practical implication is direct: handing your MCP layer and its data to an offshore third-party host adds exactly the kind of third-party dependency and concentration the regime exists to scrutinise. Keeping the MCP server in your own environment — with an integration partner that builds and hands over rather than hosts — keeps you out of that exposure entirely.

Cross-border: the EU AI Act

For firms operating on both sides of the Channel, the EU AI Act is now being enforced, and many are simply building to the stricter regime. An MCP deployment that serves EU customers or operations has to account for it as well as the UK frameworks.

The pattern that satisfies all of it

The secure pattern, with a supervisory overlay, is a single architecture:

• The MCP server runs in your own environment and jurisdiction — which keeps data in-jurisdiction, avoids adding a critical-third-party dependency, and sidesteps cross-border transfer questions.
• It is resilient and reversible — inside your impact tolerances, with human-in-the-loop approval for consequential actions and a way to stop and roll back.
• It is fully logged and auditable — the evidence base your accountable senior manager and your SYSC obligations require, and what incident response depends on.
• It supplies the authentication, RBAC, and token lifecycle MCP leaves optional, and scopes tools and data to the minimum.

In a regulated firm the quickest MCP server to stand up is precisely the one that creates operational-resilience gaps, concentration risk, and personal-accountability exposure. "We'll host it for you" is the wrong answer for the same reasons. The build that a senior manager can put their name to is the secure, in-house, evidenced one.

At Vitnis we build MCP integrations for regulated UK firms to be supervisable as well as secure: in your environment and jurisdiction, resilient and reversible, logged for SM&CR and SYSC evidence, and handed over clean so the accountable manager can stand behind it. Building to the FCA's existing frameworks from the start is far cheaper than explaining to a supervisor afterwards why you didn't.