Zurück zu The LedgerCompliance

nFADP and AML files: what actually changed for Swiss FIs in 2023

The revised Federal Act on Data Protection has been in force since 1 September 2023, with no transition period. For an AML stack already built around 10-year retention, the headline question (destroy or retain?) has a clear answer. The harder questions are the ones nobody asks.

Antoine Bedaton
Antoine Bedaton
03. Dez. 20259 Min. Lesezeit
nFADP and AML files: what actually changed for Swiss FIs in 2023

Part of our complete guide to negative news screening for Swiss banks. This post is the deep dive on Swiss data protection and AML retention; the guide covers the end-to-end picture.

The revised Federal Act on Data Protection (FADP / DSG, SR 235.1) entered into force on 1 September 2023, with no transition period. The revision is often referred to as the nFADP or revFADP. Swiss financial intermediaries already had ten-year retention obligations under AMLA Art. 7 and reconstruction obligations under AMLO-FINMA Art. 22 (covered in What Swiss AML rules actually require for screening evidence). On the surface, the new regime asks them to delete data when it is no longer needed, at the same time AML rules require them to keep it for a decade.

The conflict is more apparent than real. The interesting parts of the nFADP for an AML stack are not about retention at all.

What the nFADP actually requires

Five obligations matter for an AML system. None of them are exotic.

Art. 6: processing principles

Article 6 lists the principles that govern every processing operation: lawfulness, good faith, proportionality, purpose limitation, data quality. Two of them deserve attention in an AML context.

Proportionality (Art. 6 para. 2) says processing must not exceed what is necessary for the purpose. In practice this is a constraint on scope creep. A sanctions screening run does not authorise the operator to also retain the entire browsing trail of the analyst, or the full HTTP responses of every page they happened to look at, unless those are part of the evidence file.

Data lifecycle (Art. 6 para. 4) requires personal data to be destroyed or anonymised as soon as the purpose of processing no longer requires it. This is the article that appears to collide with AMLA Art. 7. It does not, but more on that below.

Art. 12: register of processing activities

Article 12 requires controllers and processors to keep a register of their processing activities. The exemption (fewer than 250 employees and no high-risk processing) does not apply to a financial intermediary screening clients for AML purposes. PEP and sanctions screening qualifies as high-risk processing on its face, regardless of headcount.

Art. 16-17: cross-border transfers

Article 16 lets the Federal Council designate countries with adequate data protection. The list lives in Annex 1 of the Data Protection Ordinance (DPO). Notably, the Federal Council added the United States to the list on 15 September 2024, but only for entities certified under the Swiss-US Data Privacy Framework. EEA states and the United Kingdom are listed separately. The Swiss list does not match the European Commission's adequacy list one-for-one.

For everywhere else, Article 17 lays out the alternatives: standard contractual clauses, binding corporate rules, FDPIC-approved data protection clauses, or specific derogations. A Swiss FI that screens clients against an OFAC list hosted on AWS US-East-1, or that pulls adverse-media results through an API terminating in a non-adequate jurisdiction, has to be able to show which mechanism it relies on.

Art. 22-23: data protection impact assessment

A DPIA is required when processing is likely to lead to a high risk to the personality or fundamental rights of the data subject. Article 5(m) defines high-risk profiling as automated processing leading to particularly high risk. Sanctions and PEP screening (automated matching of an individual against lists that materially affect whether they can open an account) sits squarely in that definition. Article 23 adds that if a residual high risk remains after mitigations, the controller must consult the FDPIC before processing begins.

Art. 24: breach notification

The breach notification regime is deliberately less prescriptive than GDPR. The controller must notify the FDPIC as soon as possible if the breach is likely to result in a high risk to the data subject. There is no 72-hour clock. The FDPIC has published guidelines explaining how the reporting form works and what level of detail to include. The absence of a fixed deadline is not a licence to wait. The criminal provisions (below) apply to wilful failure to notify, and "as soon as possible" is interpreted in light of when the controller had enough information to file something useful.

The retention conflict, resolved

Article 6(4) requires destruction. AMLA Art. 7(3) requires ten years of retention. This is not a conflict the nFADP leaves unresolved.

Article 31 nFADP lists the justification grounds that legitimise processing which would otherwise breach personality rights: consent, an overriding private or public interest, or legislation. AMLA's retention obligation is legislation. So is AMLO-FINMA Art. 22. So is the SBA self-regulation (CDB 20) to the extent it has been recognised under Art. 7 AMLO-FINMA. A Swiss financial intermediary keeping AML-related records for the duration the AML legislation requires is processing on a statutory basis. The retention itself is lawful.

What the nFADP changes is everything around that core. The Article 31 justification covers the AML-required content for the AML-required period. It does not cover:

  • Material outside the AML scope that an analyst happened to capture during a screening session: speculative searches, dropped leads, documents that were never relied on for a decision.
  • Retention beyond the ten-year period unless a separate legal basis applies (litigation hold, tax, contract).
  • Wider use of the same data for unrelated purposes (analytics, marketing, model training) without a fresh justification under Art. 31.

This is the engineering point. The headline answer (AMLA wins, keep the records) is correct only for the records AMLA actually requires. Treating the entire investigation workspace as if it were AML-required loses the protection of Art. 31 at the edges and turns proportionality into a defect.

Right of access, and where it stops

Article 25 nFADP gives the data subject the right to request a copy of their personal data and information about how it is processed. The right is not absolute. Article 26 lets the controller restrict, defer, or refuse access where a formal law provides for confidentiality, where the rights of third parties require it, where the request is manifestly unfounded, or, relevantly, where overriding interests of the controller outweigh disclosure, provided the data is not passed to third parties.

For AML, the bounded part is the suspicious activity report. AMLA Art. 9 requires reporting to MROS, and Art. 10a prohibits the financial intermediary from informing the person concerned or third parties about the report. That prohibition is a formal-law confidentiality rule. The Article 25 right of access does not pierce it. The rest of the investigation file (identification documents, the entity record, non-suspicious findings) is in scope of access requests, subject to the standard balancing.

This is worth getting right at the system level. A right-of-access endpoint that exports the full investigation workspace is a leak of the MROS report; a right-of-access endpoint that refuses everything is a violation of Art. 25. The disclosure layer has to be aware of the report-confidentiality boundary.

What this means in code

The compliance team can read the act. The engineering question is what to build.

Retention is per-category, not blanket. An AML stack built around "keep everything for ten years" satisfies AMLA but fails Art. 6(4) on the parts that AMLA does not require. The retention layer needs to distinguish records held under a statutory obligation (AMLA, AMLO-FINMA, tax) from records held for operational convenience (analyst notes that were never adopted into the evidence file, draft sessions abandoned before completion, browsing artefacts captured by the workspace but not saved as evidence). The first category retains; the second deletes when the purpose ends.

Destruction has to actually happen, on a clock. Article 6(4) is not satisfied by a deleted_at flag. Anonymisation is satisfied by removing or coarsening identifiers such that re-identification requires disproportionate effort. The FDPIC has been clear that pseudonymisation under a key the controller still holds is not anonymisation. A defensible implementation either physically deletes the row, or overwrites the identifying fields and severs the link to any keying table. The deletion event itself becomes an audit entry (what was deleted, when, under which retention rule), and that audit entry survives the data.

Cross-border has to be documented. A sanctions data feed hosted abroad, a screening API run by a non-Swiss vendor, a backup written to a foreign region: each of these is a cross-border disclosure under Art. 16-17. The processing register required by Art. 12 has to list them. The transfer mechanism (adequacy, SCCs, derogation) has to be on file. The 15 September 2024 addition of the US to the adequacy list, limited to DPF-certified entities, narrows the question for some vendors but does not eliminate it: a Swiss FI relying on US adequacy needs to verify the specific vendor's DPF certification status, not infer it from the country listing.

The DPIA is a written artefact, not a posture. Article 22 requires the assessment to exist. For sanctions and PEP screening, an artefact that names the screening function, the data categories, the matching logic, the false-positive disposition flow, and the residual risks after mitigation is the minimum. The output feeds Art. 23: if residual risk is still high, the FDPIC must be consulted. Most AML-screening DPIAs do not need to escalate, but the assessment has to make that finding explicit rather than skip it.

Right-of-access disclosure is a permissioned export. The system needs to know which fields are subject to MROS confidentiality, which are subject to third-party rights, and which are routinely disclosable. This is a configuration problem more than a permissions problem. The defaults should be wrong-on-the-safe-side, with the legal team able to broaden disclosure case-by-case rather than narrow it under pressure.

Penalties, and who pays

Articles 60-63 nFADP carry criminal sanctions of up to CHF 250,000 for wilful violations. Two features matter for engineering decisions.

First, the sanctions are criminal, not administrative. They run against natural persons by default, not the legal entity. Where a legal entity is the addressee, the responsible natural persons within it carry the liability. Article 64 lets the prosecution authority fine the company directly, but only up to CHF 50,000, and only where identifying the responsible natural person would require disproportionate effort.

Second, only wilful acts and omissions are punishable, not negligence. The line between the two often turns on whether the controller had a process in place and ignored it, or never had one. This is one of the few places where having a written, dated DPIA, a maintained processing register, and a documented retention matrix is genuinely protective, not because they prevent breaches, but because they place the controller on the negligence side of the line rather than the wilful side.

Bottom line

For an AML stack already built around ten-year retention, AMLO-FINMA Art. 22 reconstruction, and a hash-chained audit trail, the nFADP is not a redesign. It is a set of obligations that sit alongside AML: the processing register, the DPIA, the cross-border transfer documentation, the breach notification path, the right-of-access disclosure layer.

The mistake to avoid is treating "AMLA wins" as the whole answer. AMLA wins on the records AMLA requires. Outside that scope, the nFADP applies in full, and the system has to know the difference.

#nFADP#FADP#privacy#AMLA#swiss