I have watched two sentences end an AI conversation in a regulated firm before it had a chance. The first is “Anthropic does not allow Claude for regulated workloads.” The second is “we cannot, because of EU data residency.” One of them is false and quietly poisons good options. The other is true and routinely surfaces too late, after someone has built a plan that assumes a residency control that does not exist. A regulated buyer needs to know which is which, because the cost of getting them backwards is either a banned tool that was never banned or a compliance gap discovered in the worst possible meeting.

So let me take them in order, with the facts checked against Anthropic’s own pages rather than the folklore.

The myth: “Claude is not allowed for regulated finance”

This one is straightforwardly wrong, and it is worth being blunt about because it gets repeated by people who should know better.

Anthropic sells Claude for Financial Services as a named product. Its own page lists Bridgewater, Commonwealth Bank of Australia, and AIG as customers, with AIG describing a workflow that “compressed the timeline to review business by more than 5x” and lifted data accuracy “from 75% to over 90%.” You do not put a global insurer’s underwriting review on your launch page if your terms forbid regulated use.

The terms themselves say the same thing. Anthropic’s usage policy places finance, legal, healthcare, and insurance under “High-Risk Use Cases,” and high-risk is not banned. It is permitted subject to two safeguards, and the scope of those safeguards is the single most misread clause in this whole debate. A qualified professional must review the output “prior to dissemination or finalization” when you are providing “advice, recommendations, or in subjective decision-making directly affecting individuals or consumers,” and you must disclose AI use “if model outputs are presented directly to individuals or consumers.” Read the trigger carefully. Both obligations attach to outputs that reach an individual or a consumer. A bank analyst using Claude to summarise a data room, draft an internal memo, or pressure-test a model is not presenting output to a consumer, so the consumer-facing safeguards do not automatically fire. The kernel of truth the myth grows from is real but narrow: the consumer Team plan runs under consumer data terms, and someone who tests there, sees their inputs treated as consumer data, and concludes “Claude is unsafe for regulated data” has confused the tier with the platform.

So the fair answer to “are we allowed” is yes, with safeguards that are lighter than the myth implies for internal B2B work and that you would want anyway. That clears the objection that should never have been an objection. Now the one that should.

The real catch: there is no EU home for first-party Claude

Here is the fact almost nobody volunteers, and the one a UK or EU regulated firm has to build around. First-party Claude Enterprise has no EU data residency. Not “limited” residency. None.

Anthropic’s data residency docs make it plain in two settings. Inference geo, which controls where the model actually runs, accepts exactly two values, and the limitations section says so outright: “Only "us" and "global" are available.” There is no "eu". Workspace geo, which controls where your data is stored at rest, is blunter still: “"us" is the only available workspace geo,” and it “can’t be changed” after the workspace is created. So on the first-party platform your data is processed in the US or globally, and it rests in the US, full stop. The only residency dial you are given is “US-only,” which costs 1.1x and is the opposite of what a Frankfurt or London data-protection officer is asking for.

It is worth separating two ideas that get fused here, because the confusion sells false comfort. Zero data retention is not data residency. Anthropic offers ZDR on the commercial API and Enterprise arrangement, and it is real: your data is not stored after the response returns. But “not stored” says nothing about “where it ran,” and a ZDR contract does not conjure an EU region into existence. You can have zero retention and still have every token processed on US infrastructure. A buyer who hears “zero data retention” and files it under “EU residency, sorted” has merged two different controls into one wrong conclusion.

The only EU route runs through someone else’s cloud

There is a way to keep Claude’s processing in the EU, and it is the part every serious 2026 guide gets to eventually: you do not buy it from Anthropic, you rent it from a hyperscaler. The same docs note that “on Amazon Bedrock, Vertex AI, and Microsoft Foundry, the inference region is determined by the endpoint URL or inference profile,” so the inference_geo parameter “is not applicable” there. Translated: when you run Claude through AWS Bedrock in an EU region or Google Vertex in an EU region, the region is a property of the cloud endpoint you chose, and your data stays in that region because AWS or Google keeps it there, not because Anthropic offers a setting. Microsoft Foundry is the trap inside the workaround, because it currently runs Claude on Anthropic-hosted US infrastructure rather than Azure’s EU regions, so “we use Claude through our Microsoft tenant” is not the EU answer it sounds like.

And even the working route is necessary, not sufficient. EU residency through Bedrock or Vertex puts the processing in-region, but the operator is still a US company subject to US law, so a complete posture pairs residency with the contractual and technical measures your own counsel will insist on: the data processing addendum, the standard contractual clauses, a transfer impact assessment, the supplementary controls. Residency is one variable you can now control. It was never the whole control.

What this means if you are FCA-regulated

Put the two facts together and the shape of the work is clear, which is the point of stating them plainly.

You are allowed to use Claude. Banks demonstrably do. The compliance objection that gets weaponised into a blanket ban does not survive contact with Anthropic’s own product page and usage policy, and letting it stand just pushes your people toward the personal accounts you cannot see. At the same time, if your data cannot leave the EU, buying Claude Enterprise does not give you that, and discovering it after you have socialised a rollout plan is the kind of surprise that ends programmes. Call it what it is, allowed but not turnkey. The permission is free. The residency is an architecture you assemble, almost certainly on Bedrock-EU or Vertex-EU, with your data and legal teams mapping it to your own obligations.

That changes the question, too. “Is Claude GDPR-compliant?” is the wrong thing to ask, because compliant is a posture you build, not a label a vendor grants. The right questions are narrower and answerable: where does inference run, where does data rest, which cloud endpoint pins the region, and what does our transfer analysis require on top. Those have concrete answers, and the architecture deep-dive for them lives in running Claude in compliance-heavy environments, with the finance-specific version in Claude for financial services compliance.

None of this is a reason not to deploy. It is the floor under doing it without a nasty surprise, the compliance half of the same phase-zero groundwork every other control in this cluster sits on. Kill the myth that costs you good options. Respect the constraint that is actually there. Then build the EU posture on purpose, early, where you can see it, instead of finding out in front of the regulator that the residency you assumed was never on offer.