Wecan
Back to blog
Insights9 min read· October 3, 2026

Data Protection in KYC: Where the FADP and GDPR Collide with AML

KYC requires collecting and keeping sensitive personal data. Data protection requires minimising and deleting it. Where the two regimes genuinely conflict, how Swiss law resolves it — and the detail that puts a named individual, not the bank, on the hook.

by Wecan

A KYC file is, from a data protection standpoint, close to a worst case. It contains identity documents, residential addresses, family relationships, political exposure, source of wealth narratives, adverse media findings and a risk judgement about a named human being. It is retained for a decade. It is shared with group entities, correspondents and auditors. And a meaningful part of it is collected without the subject's meaningful consent, because declining is not a realistic option if you want a bank account.

Two bodies of law therefore apply to the same folder and pull in opposite directions. AML law says collect, verify, retain, and in some cases do not tell the subject what you are doing. Data protection law says minimise, be transparent, delete when the purpose ends, and let the subject see their file.

They are reconcilable, but not by instinct. This article sets out where the genuine conflicts are, how Swiss law resolves them, and the one feature of the revised FADP that should change how a compliance function thinks about accountability.

1. The Swiss starting point, and the detail everyone misses

The revised Federal Act on Data Protection (revFADP/nFADP) entered into force on 1 September 2023, with no transition period: existing processing had to comply from day one. It modernised a 1992 statute and moved Swiss law substantially towards the GDPR — records of processing activities, data protection impact assessments, breach notification, privacy by design.

But one feature is unlike the GDPR, and it matters more for compliance officers than any of the procedural changes.

Criminal fines of up to CHF 250,000 fall on the responsible natural person, not on the company. Only wilful violations are punishable. The company itself can be fined up to CHF 50,000 only where identifying the responsible individual would require disproportionate investigative effort. And the Federal Data Protection and Information Commissioner cannot levy fines at all: the FDPIC investigates and issues binding orders, while criminal prosecution runs through cantonal authorities.

Read that again in operational terms. Under the GDPR, a data protection failure is a corporate financial risk, insurable and budgetable. Under Swiss law, it is a personal criminal exposure for the individual who decided. That changes who in an institution should care, and how. A head of compliance signing off on a data transfer to a group entity abroad is not exposing a cost line. They are exposing themselves.

Breach notification is also lighter in form but not in substance: notification to the FDPIC is required as soon as possible, with no fixed 72-hour deadline. The absence of a number is not a relaxation — it removes the comfortable fiction of a countdown and leaves a standard of promptness that will be judged after the fact.

2. Where the regimes genuinely conflict

Most of the supposed conflicts dissolve on inspection. Four do not.

Retention versus erasure. AML law requires retention — ten years in Switzerland after the end of the relationship. Data protection requires deletion when the purpose is fulfilled. The resolution is that the legal obligation to retain is the purpose and the legal basis, so a deletion request does not reach AML records within the retention period. But two things follow that institutions get wrong. First, the retention basis covers what the law requires you to keep, not everything that accumulated in the folder — the relationship manager's notes, the duplicate scans, the screening noise from eight years ago are not automatically protected by an AML retention clause. Second, you must be able to state which data is retained on which basis, which presupposes that the file is structured enough to answer that question. See client offboarding, where this becomes acute.

Access rights versus tipping off. A data subject has a right to know what data you hold about them. AML law prohibits informing a person that a suspicious activity report concerning them has been filed. These collide directly, and the resolution is a statutory restriction on the access right rather than a judgement call by whoever receives the request. The operational implication is that subject access requests cannot be handled by a generalist privacy process — a request touching a client with an open or historic report must route to a path that knows what cannot be disclosed, and the routing rule must exist before the request arrives.

Minimisation versus risk-based due diligence. Minimisation says collect what is necessary. Enhanced due diligence on a high-risk relationship requires collecting a great deal, including family circumstances and wealth narratives. These are compatible — necessity is measured against the purpose, and the purpose is set by law — but only when the institution can explain why this particular client's risk justified this particular collection. A blanket enhanced questionnaire applied to everyone fails that test. A risk-driven requirement set passes it, which is one of the less obvious arguments for the conditional data requirements described in digital onboarding.

Adverse media and accuracy. Screening ingests press reporting, which is unverified by nature. Data protection requires personal data to be accurate. An allegation stored as a fact in a client file is a data protection problem as well as a compliance one. The resolution is in how it is recorded: an adverse media hit is accurately recorded as an allegation reported by a source on a date, not as a characteristic of the person. The distinction sounds pedantic until a client exercises their access right and reads what you wrote about them. See adverse media screening.

3. Cross-border, which is where it gets expensive

Three transfers happen constantly in Swiss private banking, and each raises a distinct data protection question.

To group entities abroad. Routine, and routinely under-documented. Intra-group transfer needs a legal basis and, for countries without adequate protection, appropriate safeguards. The common failure is treating group membership as if it were itself a basis.

To correspondent banks. A correspondent asking about an underlying client is asking for personal data. The answer may be necessary and lawful — but necessity is assessed per request, and a standing arrangement to answer whatever is asked is not a legal basis.

To foreign authorities. This is the one with the sharpest Swiss edge, because transmitting information to a foreign authority outside the proper channels engages Swiss criminal law independently of data protection. The rule is procedural: requests go through the channels provided for them. An institution answering a foreign regulator directly because the question seemed reasonable has a problem that no privacy policy will solve.

And a general point that applies to all three: the GDPR does not stop at the Swiss border. A Swiss institution serving EU-resident clients may fall within its scope, in which case both regimes apply to the same file — with the GDPR's corporate fines and the FADP's personal criminal exposure stacked rather than alternating.

4. The AI layer makes this sharper

Automated processing of personal data in a compliance context raises additional duties — transparency about automated decision-making, the right to human intervention in certain cases, and an impact assessment where processing presents a high risk.

Note that this applies regardless of how the EU AI Act classifies the system. An institution concluding that its screening tool is not a high-risk AI system has not thereby concluded anything about its data protection obligations. The two analyses are independent, and the data protection one usually bites first.

The practical requirement is the same one that good compliance already demands: be able to explain, for a specific person, what was processed, by what logic, and who decided.

5. What a compliant KYC data practice looks like

Six things, none exotic.

A record of processing that reflects reality. Not the document produced for the audit, but an accurate map of what is collected, why, on what basis, where it goes and how long it stays. The test is whether a new joiner could use it to answer a client question.

Retention rules attached to data, not to folders. Different elements of a KYC file have different retention justifications. A single ten-year rule applied to everything is simple and wrong — it over-retains, and over-retention is itself a breach.

A subject access procedure that knows about AML. With a routing rule for clients subject to reporting, and a defined decision-maker. Built before the first request.

Adverse media recorded as allegation with provenance. Source, date, what was alleged, what was assessed, what was concluded. This satisfies accuracy and makes the file defensible on the compliance side at the same time.

Transfer documentation per flow. Each recurring transfer with its basis and safeguards written down once, rather than reasoned afresh each time by whoever is asked.

Named accountability. Given that Swiss sanctions fall on individuals, who decides what should be explicit. Diffuse responsibility is normally an organisational inefficiency; here it is a personal risk allocated by default to whoever can be identified.

6. The structural answer

Almost every difficulty above is harder in proportion to how unstructured the client file is.

If beneficial ownership is a PDF, you cannot say which data is retained on which basis. If adverse media hits are pasted into a notes field, you cannot distinguish allegation from fact. If the client record is scattered across systems, a subject access request becomes an archaeology project with a statutory deadline, and a deletion request becomes a guess. If automated processing leaves no log, you cannot explain the logic to the person it concerned.

Conversely, where the client is one structured record — with each element carrying its purpose, basis, source and retention clock, and every automated contribution logged — data protection compliance stops being a separate programme and becomes a property of how the file is kept. That is the same conclusion that remediation, periodic review and exit all reach from their own direction, which is itself worth noticing: these are not four problems but one, seen from four sides.

Wecan's CLM platform holds the client as a structured record precisely so that these questions have answers rather than reconstructions. In a regime where the fine lands on a named individual, being able to answer is not an administrative nicety.


This article is provided for information purposes and does not constitute legal advice. The revFADP, its ordinance, the GDPR and applicable AML law should be consulted in their authoritative versions, and institution-specific questions addressed with qualified counsel.

See Wecan in action. In 30 minutes.

A live walkthrough on real KYC scenarios — no slides, no commitment. Just see if it fits your context.