Customer story / Private banking and wealth management
One AI endpoint, three legal regimes: a Swiss private banking group routes Zurich, London and Frankfurt traffic by jurisdiction
A Swiss private banking group wanted one internal AI assistant for relationship managers and operations staff in Zurich, London and Frankfurt. Swiss banking secrecy, the UK GDPR and the GDPR each set different limits on where prompts may go. YTT Secunet resolves the employee's booking centre on each request and applies the matching policy pack.
- Customer
- Tier 1 Swiss Private Banking Group
- Industry
- Private banking and wealth management
- Headquarters
- Zurich, Switzerland
- Gateway
- Sovereign Dedicated
- Policy
- eu-gdpr-strict; uk-gdpr-idta; swiss-fadp-compliant
Results
- 3
- legal regimes served from one internal endpoint and one application build
- 0
- internal audit findings on data location for the assistant's first full quarter
- 6.4 ms
- p99 gateway overhead measured by the bank's own APM in Zurich
- 8 weeks
- from architecture sign-off to production for all three booking centres
The group's relationship managers draft client letters, summarise portfolio reviews and search internal research, and the bank wanted an AI assistant for all three. Its IT risk function set three hard rules before any rollout. Client-identifying data from Swiss booking centres had to be processed in Switzerland, in line with the bank's banking secrecy practice under Article 47 of the Banking Act. German entity data had to stay in the EEA. UK entity data had to stay in the UK under the London entity's contracts and its operational resilience mapping.
The first architecture proposal used three separate deployments with three API keys, three application builds and three audit trails. It doubled the effort for every new feature, and nobody could answer the question the bank's internal audit team asked first: how would you show, for any given quarter, that no Swiss client data was processed outside Switzerland?
FINMA Circular 2018/3 and FINMA Guidance 08/2024 also shaped the requirements. The bank needed an inventory of every model provider involved, audit rights over the routing layer, and a way to show that the model version used in production was the one that had been tested.
- 01Integrate
The bank deployed YTT Secunet as Sovereign Dedicated inside its own Zurich data centre, with signing keys held in the bank's HSM. The assistant calls a single internal endpoint. The gateway reads the user's booking centre from the identity token and applies swiss-fadp-compliant, eu-gdpr-strict or uk-gdpr-idta accordingly.
- 02Enforce
Swiss requests go to Swisscom capacity in Zurich, German requests to Azure OpenAI in Frankfurt and UK requests to AWS in London. Failover stays inside each regime: a Swisscom incident moves Swiss traffic to the bank's own vLLM cluster in Zurich, never to Frankfurt. The policy file is a single document under version control, and the bank's legal team reviews changes in the visual policy editor before the platform team merges them.
- 03Evidence
Client names, account numbers and IBANs are pseudonymized before any call that leaves the bank's own environment, with the token vault in Zurich. Internal audit received read-only access to the receipt ledger and ran the offline verifier against a full quarter of Merkle roots.
In their words
“Internal audit asked how we would prove that Swiss client data never left Switzerland. We gave them the verifier and a quarter of roots, and they checked it without our help. That is the conversation we wanted to have with FINMA as well.”
- Sovereign Dedicated (on-prem, Zurich)
- Swisscom Swiss AI Platform
- Azure OpenAI (Germany West Central)
- Amazon Bedrock (eu-west-2)
- vLLM fallback cluster
- Customer-held HSM keys
Sovereign route ready
Stop risking 4% global turnover GDPR fines on AI inference.
Deploy sovereign, cryptographically proven AI routing in 15 minutes.