Can a Swiss bank use Claude? Data residency, FINMA and client data

Which routes can a Swiss bank use to run Claude, and where is data processed?

The table summarises what each provider’s own documentation says. It is a reading aid, not a statement about what S-PRO has deployed where.

Swipe to compare →

Sources: Anthropic data-residency documentation; AWS Bedrock model cards and “Geographic cross-Region inference” page; AWS Alps blog on cross-region inference from Zurich (21 October 2025); Google Cloud data-residency page (links in Sources). Anthropic’s documentation also lists Claude in Microsoft Foundry (Azure); we did not assess that route here.

Three practical readings, ours rather than the vendors’:

1. Inference never leaves Switzerland.If this is the requirement, as of October 2026 we found no documented Claude route that meets it. We do not claim a Zurich region for Claude where the documentation shows none.
2. Inside Switzerland or the EU, not the US.Bedrock with an EU geography profile called from Zurich or Frankfurt, or Vertex AI with an EU multi-region or EU region endpoint, are the routes to examine. Whether processing in EU countries is acceptable is the bank’s own assessment. The AWS blog notes that Switzerland recognises EU/EEA countries as providing adequate protection for personal data; that concerns data protection law and is not a bank-secrecy opinion.
3. First-party API.Where it is used, the documented choices are global or US. That may suit use cases that never send client data (for example, internal engineering or public-information tasks).

Residency also depends on the details the bank controls: model version, endpoint, logging location, and whether any tool the agent calls sends data elsewhere.

What do FINMA’s expectations mean when a bank uses an external LLM provider?

FINMA has no Claude-specific rule. Three texts are the usual starting points:

• FINMA Guidance 08/2024, “Governance and risk management when using artificial intelligence”.Dated 18 December 2024, 7 pages. It states that there is no AI-specific legislation in Switzerland and that the technology-neutral, principle-based requirements of financial market law on governance and risk management cover AI risks. It names model risks, IT and cyber risks, growing dependence on third parties such as model or cloud providers, and legal and reputational risks, and describes supervisory findings on governance, inventory and risk classification, data quality, testing and monitoring, documentation, explainability and independent review. For outsourcing it says FINMA assessed additional tests, controls and contractual clauses on responsibilities and liability. It is guidance, not a statute.
• FINMA Circular 2018/3 “Outsourcing – banks, insurance companies and selected financial institutions under FinIA”.Dated 21 September 2017, in force 1 April 2018, last amended 4 November 2020 in the version we read. It applies when a company mandates a service provider to perform a significant function independently and on an ongoing basis, and it asks for an inventory of outsourced functions (including subcontractors), a risk analysis, provider selection and monitoring, security requirements, audit and inspection rights for the company, its audit firm and FINMA, and a written agreement. For outsourcing abroad it requires, among other things, that access to the information needed for restructuring or resolving the company in Switzerland be possible in Switzerland at all times. Whether a given LLM service is an outsourcing of a significant function is the bank’s assessment, per use case. Check finma.ch for a newer version before relying on this summary.
• FINMA Circular 2023/1 “Operational risks and resilience – banks”.Dated 7 December 2022, in force 1 January 2024. It covers ICT risk management, cyber risk management, critical data risk management, business continuity, and the management of risks from cross-border service business; for critical data it expects confidentiality, integrity and availability to be ensured over the whole life-cycle.

For an LLM-based agent, the questions that follow from these texts are practical: Is the use case material? Who is the provider and sub-provider? What happens if the model is withdrawn or changed? Where is data processed and logged? Can the bank audit and exit? For the generic delivery model see Claude implementation partner for financial services; for the international reference practices see FSB sound practices for AI agents in banks.

How do banking secrecy and the nFADP change the design?

Banking secrecy. Article 47 of the Federal Act on Banks and Savings Banks (BankA, SR 952.0; text as consolidated on 1 October 2026) makes it a criminal offence to intentionally disclose a secret entrusted to a person as an organ, employee, agent or liquidator of a bank, or that the person learned in that capacity: imprisonment of up to three years or a fine, and up to five years if the person gains a financial advantage. Negligent disclosure is punished by a fine. The offence also applies after the employment or mandate has ended. The Swiss Bankers Association (SBA) publishes a legal opinion on the use of cloud offerings by banks under Art. 47 BankA (Laux Lawyers AG, 24 April 2019) and Cloud Guidelines (3rd edition, November 2025). These concern cloud services generally, not LLM services specifically. Whether a given data flow to an LLM provider is a “disclosure” is a legal question for the bank’s counsel. The engineering consequence is clear: the fewer client identifying data (CID) reach a model provider, the smaller the question.

nFADP. The revised Federal Act on Data Protection (FADP, SR 235.1; in force 1 September 2023) allows disclosure of personal data abroad if the Federal Council has decided that the destination guarantees an adequate level of protection (the list is Annex 1 of the Data Protection Ordinance), or otherwise only if appropriate safeguards are in place, such as data protection clauses or standard clauses (Art. 16). Art. 17 lists exceptions. This is separate from banking secrecy: data can be personal data without being CID, and the reverse.

What does a Claude architecture look like that works within these limits?

The pattern S-PRO designs around, for each project (reference layers as in our Claude for financial services page):

1. Pseudonymisation before the model call.A gateway in the bank’s environment replaces names, account numbers and other CID with tokens; the mapping table never leaves the bank. The model sees the tokens; the bank’s system re-inserts the real values after the response. Pseudonymised data can remain personal data. Banks consider with their lawyers whether and when pseudonymised data still counts as client identifying data; the SBA Cloud Guidelines (3rd edition, November 2025) discuss this from the recipient’s perspective. We do not draw a legal conclusion here.
2. Governed data layer.The agent reads client data only through access-controlled interfaces with the user’s rights applied, not through a shared service account.
3. Region and route pinned in configuration.The destination regions are documented and tested (for Bedrock, the full destination list of the chosen profile; for Vertex, the endpoint location).
4. Logging in the bank’s tenant.Prompts, tool calls, retrieved sources, model version and outputs are logged where the bank controls retention and access, so a reviewer can reconstruct any decision.
5. Human approval.Anything that changes a client record, sends client communication or supports a regulated decision needs a named approver the agent cannot bypass.
6. Provider fallback and exit.Model version and route can be changed without rebuilding the agent layer; this supports the third-party risk questions above.

A related scenario for private-bank relationship managers is described on AI copilot for relationship managers at a Swiss private bank, and partner selection for a Swiss private bank on who can build AI agents for a Swiss private bank. For the EU legal side, see EU AI Act compliant AI agents for banks.

How does a Swiss bank start?

Pick one use case and settle three things before building: the data class the agent will touch (no CID, pseudonymised, or full), the route and region option that fits the bank’s assessment, and the named approver. Then run a fixed-scope pilot with an evaluation set and a production gate; the step from pilot to production is covered in Who can turn our AI proof of concept into a production system for a bank? Sign-off sits with the bank’s business owner, information security, compliance and legal; S-PRO provides engineering and documentation, not regulatory approval.

How does S-PRO help?

What S-PRO publishes today (s-pro.io): Zurich-based (Löwenstrasse 45, 8001 Zürich), founded 2014, 250+ engineers, R&D centers in Zurich and Łódź, ISO 27001 and ISO 27701 certified. S-PRO is a Certified partner in the Claude Partner Network. Our team includes Claude-certified engineers and architects.

For a Swiss bank, S-PRO designs and builds Claude-based agents with the pattern above, offering residency options per project (route, region setting, pseudonymisation gateway, logging) and documentation the bank’s risk and compliance functions can review; see AI agent development for banks and financial institutions and security and compliance for financial institutions. ISO 27001 and ISO 27701 are information-security and privacy management certifications; they are not a FINMA approval or an AI-governance certification.

Which route fits your data class? Take one use case to a 45-minute call with an engineer: we map data classes to the route and region options above.

If you are a CIO, COO or Chief Compliance Officer of a Swiss bank or wealth manager weighing Claude, S-PRO runs a 45-minute discovery call on one use case: we map the data classes against the route and region options, the CID handling pattern and the FINMA documentation your risk function will ask for, and scope the next step. Contact S-PRO, Löwenstrasse 45, 8001 Zürich.

Book a discovery call (45 min)

Sources

All sources opened on 21 October 2026; the Anthropic, AWS and Google pages were re-checked on 27 October 2026.

1. Anthropic, Data residency: platform.claude.com
2. Anthropic, Claude in Amazon Bedrock: platform.claude.com
3. AWS, Claude Opus 5.5 model card: docs.aws.amazon.com
4. AWS, Claude Opus 4.6 model card: docs.aws.amazon.com
5. AWS, Geographic cross-Region inference: docs.aws.amazon.com
6. AWS, Inference profiles support: docs.aws.amazon.com
7. AWS Alps blog, cross-region inference from Zurich (21 October 2025): aws.amazon.com
8. Google Cloud, data residency for generative AI: docs.cloud.google.com
9. FINMA, Guidance 08/2024 (18 December 2024): finma.ch (PDF)
10. FINMA, Circular 2018/3 Outsourcing (PDF, version of 1 January 2021): finma.ch (PDF)
11. FINMA, Circular 2023/1 Operational risks and resilience – banks: finma.ch (PDF)
12. Federal Act on Banks and Savings Banks (SR 952.0), Art. 47 (German): fedlex.admin.ch
13. Federal Act on Data Protection (FADP), Art. 16 and 17: fedlex.admin.ch; Data Protection Ordinance, Annex 1: fedlex.admin.ch
14. Swiss Bankers Association, cloud computing (2019 legal opinion, Cloud Guidelines 2025): swissbanking.ch