CH zone / swiss-fadp-compliant
Swiss revFADP and FINMA ready AI inference, routed inside Switzerland
Route Swiss prompts to Swiss facilities, enforce revFADP transfer rules as code, and evidence FINMA outsourcing controls per request.
Route card / CH
base_url https://ch.yttsecunet.com/v1
X-YTT-Policy swiss-fadp-compliant
endpoints 4 certified, 4 providers
primary Zurich
failover Geneva or Swiss customer DC
never Frankfurt, for Swiss-only tenants
plans Enterprise, Dedicated
| Instrument | Citation | What it means for an inference call |
|---|---|---|
| Revised Federal Act on Data Protection (revFADP / nDSG) | SR 235.1, Articles 16 and 17, in force 1 September 2023 | Disclosure abroad is allowed to states the Federal Council lists as adequate (Art. 16(1)), with safeguards such as FDPIC-recognised SCCs (Art. 16(2)), or under the exceptions in Art. 17. Wilful breaches can lead to criminal fines of up to CHF 250,000 against the responsible individuals. |
| Data Protection Ordinance (DPO / DSV) | SR 235.11, Annex 1 | Annex 1 lists the states the Federal Council considers adequate. The EEA states and the UK are listed; the US is adequate only for organisations certified under the Swiss-US DPF. |
| Swiss-US Data Privacy Framework | Federal Council adequacy recognition, effective 15 September 2024 | Allows transfers to certified US organisations without further safeguards. Uncertified recipients still need SCCs adapted for Swiss law and a transfer risk assessment. |
| Banking Act, banking secrecy | Banking Act (BankG), Article 47 | Disclosure of client-identifying data by bank staff and agents is a criminal offence. Most Swiss banks treat foreign processing of client identifying data as needing client consent or strong technical anonymisation. |
| FINMA outsourcing and AI supervision | FINMA Circular 2018/3 Outsourcing; FINMA Guidance 08/2024 | Circular 2018/3 sets requirements for material outsourcing, including inventory, audit rights and access for FINMA. Guidance 08/2024, published 18 December 2024, sets out FINMA's supervisory expectations for AI governance and risk management. |
revFADP transfers and what they mean for prompts
The revised FADP came into force on 1 September 2023 and brought Swiss law close to the GDPR on transfers, with two differences that matter for engineering teams. First, liability under the criminal provisions attaches to individuals, so a CISO or head of data can be personally exposed for a wilful breach of the duty of care around disclosure abroad. Second, the Swiss list of adequate states lives in Annex 1 of the Data Protection Ordinance, and the Swiss-US DPF only took effect on 15 September 2024, so US processing for Swiss data is lawful only for certified recipients.
The swiss-fadp-compliant pack treats a Swiss tenant as Swiss-only by default. A tenant can widen the allowed zone to the EEA, which Switzerland recognises as adequate, but the default matches what most Swiss banks, insurers and cantonal bodies write into contracts: client identifying data is processed in Switzerland.
Swisscom and Zurich zones
Swiss routing targets two kinds of capacity. The first is a Swiss provider: Swisscom's Swiss AI Platform runs in Swisscom data centres in Switzerland and serves managed inference endpoints, including the Swiss open model Apertus. The second is a hyperscaler's Zurich region: Azure OpenAI in Switzerland North and Amazon Bedrock in eu-central-2. Both are physically in Switzerland, but their parents are US companies, which matters to banks assessing foreign access; that is why many private banks prefer the Swiss provider for client-identifying prompts and use the Zurich regions for pseudonymized or non-client workloads.
One detail catches teams out. Bedrock's EU cross-region inference profiles can route a request that starts in Zurich to an EU region. That is lawful under Swiss adequacy for the EEA, but it is not Swiss processing. The policy engine only accepts in-region model IDs for Swiss-only tenants and flags any profile whose region list leaves Switzerland.
- Client-identifying data (CID): Swiss provider or customer on-prem only.
- Pseudonymized prompts: Zurich hyperscaler regions allowed, with the token vault in Switzerland.
- Public or internal non-personal content: any approved endpoint the tenant lists.
FINMA outsourcing evidence without a spreadsheet project
FINMA Circular 2018/3 expects a bank to keep an inventory of material outsourcing, to choose and monitor providers carefully, to secure audit and inspection rights, and to make sure that client data abroad remains accessible to FINMA. FINMA Guidance 08/2024 adds supervisory expectations on AI governance, inventory, data quality, testing and explainability, and singles out reliance on third-party models as a risk to manage.
YTT Secunet turns several of those expectations into artefacts. The endpoint registry is an inventory of every model provider a tenant can reach. Each receipt names the provider, region and facility, so the bank can show that no client data was processed outside Switzerland in a given quarter. For the strictest posture, Sovereign Dedicated runs in the bank's own environment with customer-held signing keys, so YTT Secunet staff have no access to traffic or keys.
Cross-border banking groups
Swiss groups with booking centres in London, Frankfurt or Singapore run one assistant across several legal regimes. A single YTT Secunet endpoint resolves the tenant's domicile and applies the matching pack per request: Swiss clients go to Zurich, German clients to Frankfurt, UK clients to London. The policy is one file under version control, reviewed by the bank's legal team in the visual editor, and every change is itself recorded in the proof ledger.
Where our responsibility stops
YTT Secunet enforces where inference runs and signs a receipt for it. It does not give legal advice and does not replace your DPIA or transfer impact assessment.
Each entry is a specific deployment, not a provider as a whole. The registry pins region and deployment type, and refuses a route to a model the region does not serve instead of falling back to another zone.
Swisscom Swiss AI Platform
Swisscom data centres, Switzerland
Swiss-operated managed inference, including the Apertus open model.
Microsoft Azure OpenAI
Switzerland North, Zurich
Regional Standard deployments only; model list narrower than in large EU regions.
Amazon Bedrock
eu-central-2, Zurich
In-region model IDs only; EU cross-region profiles can leave Switzerland.
vLLM on customer infrastructure
Customer data centre, Switzerland
Open-weight models for client-identifying data under the bank's own control.
This is the rule set the gateway evaluates for Switzerland traffic. Your application names it in the X-YTT-Policy header, pinned to a version, and the decision is made before the request is forwarded to any provider.
- Evaluated by Open Policy Agent in the regional data plane, under 3 ms median (YTT Secunet production telemetry)
- Pack id and version are written into every signed receipt, so an auditor can match traffic to the rule that allowed it
- A denial returns HTTP 451 with the decision id and reason; there is no silent reroute
- Legal teams review changes in the visual policy editor before engineering merges them
package yttsecunet.swiss_fadp_compliant
default allow := false
# Client-identifying data stays on Swiss-operated capacity.
allow if {
input.tenant.domicile == "CH"
input.classification.client_identifying
input.endpoint.jurisdiction == "CH"
input.endpoint.operator_hq == "CH"
}
# Pseudonymized prompts may use any Swiss region.
allow if {
input.tenant.domicile == "CH"
not input.classification.client_identifying
input.pii.masked
input.pii.vault_jurisdiction == "CH"
input.endpoint.jurisdiction == "CH"
input.endpoint.deployment_type == "regional"
}
deny contains "Swiss data routed outside Switzerland" if {
input.tenant.domicile == "CH"
input.endpoint.jurisdiction != "CH"
}Zurich to another Swiss facility or the customer's Swiss cluster, never to Frankfurt for Swiss-only tenants. Resilience comes from a second facility or provider inside the zone. If none is healthy the gateway refuses the request rather than sending it to the nearest region across the border.
- Client app, tenant domicile CH, calls ch.yttsecunet.com
- Primary: Zurich
- In-zone failover: Geneva or Swiss customer DC
- Never: Frankfurt, for Swiss-only tenants. With no healthy in-zone endpoint the gateway fails closed with HTTP 503.
Is the EU adequate under Swiss law?
Yes. The EEA states are listed in Annex 1 of the Data Protection Ordinance. Swiss tenants can therefore allow EEA processing, but most banks and insurers keep client-identifying data in Switzerland by contract and by banking secrecy practice.
Does the Swiss-US DPF cover AI providers?
Only those that are certified under the Swiss-US DPF, which took effect on 15 September 2024. The policy checks the specific recipient.
Is an Azure or AWS region in Zurich enough for a private bank?
It satisfies physical residency. Whether it satisfies your bank's view of foreign access is a risk decision; many banks route client-identifying prompts to a Swiss-operated provider or their own cluster and use Zurich hyperscaler regions only for pseudonymized traffic.
Does YTT Secunet satisfy FINMA Circular 2018/3 for us?
No product satisfies the circular on its own. YTT Secunet provides inventory, residency evidence and audit access that support your outsourcing assessment, and Sovereign Dedicated can run entirely inside your environment.
Sovereign route ready
Route CH inference inside the CH zone, with proof.
Change the base URL, name the policy pack, and every response carries a signed residency receipt your DPO can verify offline.