Two Laws, One Integration Layer.

Every Swiss company with customers, partners, or subsidiaries in the European Union is, right now, operating under two distinct data protection regimes simultaneously. The Swiss Federal Act on Data Protection (FADP), which came into force on 1 September 2023, and the EU General Data Protection Regulation (GDPR) are not the same law. They overlap significantly. They also diverge in ways that matter operationally.

Most of the conversation around FADP versus GDPR has focused on legal departments: privacy notices, consent models, breach notification timelines. That is the right conversation to have. But it is only half the picture. The other half lives in the systems that move data between Switzerland and the rest of Europe, every hour of every working day.

Two regimes, not one

Switzerland is not an EU member state. The GDPR does not apply within Switzerland as domestic law. The FADP does. However, any Swiss company that processes the personal data of EU residents, regardless of where that company is based, falls within GDPR jurisdiction too. The result is a dual compliance obligation that is entirely real and largely underestimated.

The two laws share a common architecture: they both derive from the same European tradition of data protection, and companies already compliant with the GDPR will need minimal adjustments to meet the FADP. The deviations, however, are precisely where integration complexity hides.

Beyond sanctions, the two laws differ on consent thresholds, breach notification timelines, data portability rights, and the scope of data that qualifies as sensitive. Genetic and biometric data received explicit protection under the revised FADP. Any system that processes this category of data across the Swiss-EU border must satisfy both frameworks simultaneously, with different standards in each.

Where integration architecture carries the weight

Every time a Swiss company processes personal data that originates in an EU member state, a question arises: which rules apply? The technical answer lives in the integration layer, specifically in how data flows are designed, where data is routed, and what classification logic governs how records are handled in transit and at rest.

Cross-border APIs are the most immediate pressure point. An API connecting a Swiss core banking system to a German CRM platform must enforce both FADP residency requirements and GDPR data transfer standards, often in real time and at scale. Getting this wrong is not an edge case. It is the default state for any organisation that has not explicitly designed its integration layer around dual compliance.

The same logic applies to ETL pipelines pulling customer data from EU subsidiaries into Swiss headquarters, to message queue architectures routing sensitive data across jurisdictional boundaries, and to any cloud-native integration that routes payloads through hyperscaler infrastructure without explicit data residency controls.

The architectural questions that must be answered for every cross-border data flow are:

• Data residency configuration: where is each category of data stored, and under which law?
• Data lineage tracking: can you demonstrate, on demand, exactly how personal data moved through your systems?
• Consent propagation: when a data subject exercises rights under the GDPR, does that action cascade correctly to Swiss-held records?
• Breach notification routing: when an incident occurs, which regulator must be notified first, on what timeline, and through which system?

The sectors most exposed

This is not a problem for multinational conglomerates alone. Any Swiss company with EU customers, EU suppliers, or EU employees is in scope.

Banking and financial services face the highest complexity. Cross-border wealth management, FATCA and CRS reporting obligations, and FINMA requirements layer on top of FADP and GDPR to create a multi-framework compliance environment that cannot be managed manually.

Pharmaceutical companies exporting to the EU operate under Swissmedic domestically and the European Medicines Agency abroad, with data flows connecting both jurisdictions throughout the product lifecycle. Manufacturing companies in supply chains that cross the Swiss border move operational and commercial data back and forth across regulatory boundaries, often in automated EDI pipelines designed before either the revised FADP or the GDPR existed.

Insurance companies writing policies that span Swiss and EU risks maintain policyholder data under Solvency II norms on the EU side and Swiss Solvency Test requirements domestically. Each of these sectors has the same core integration problem, expressed in different business contexts.

Integration as the compliance engine

The organisations managing dual compliance well are not doing so through legal review alone. They have rebuilt their integration layer to enforce compliance rules as a property of the data flow itself, not as an audit applied after the fact.

In practice, this means:

• Metadata-tagged payloads that carry jurisdiction classification at the record level.
• API gateway policies that evaluate consent status before routing.
• Event-driven architectures where data residency is a configurable parameter, not a hardcoded assumption.
• Structured logging that captures data provenance for regulatory reporting without embedding personal data in log streams.

The revised FADP came into force without a transition period. GDPR enforcement has been active since 2018. The window for organisations to treat this as a future problem has closed. What remains is the engineering work of getting integration architectures to reflect the legal reality that already exists.

What this means for your IT roadmap

If your organisation moves personal data across the Swiss-EU border, the question is not whether your integration architecture needs to address dual compliance. It is whether it already does, whether you can prove it, and whether the proof would satisfy regulators on both sides of the border simultaneously.

That assessment starts with a clear map of every data flow that crosses jurisdictions: the APIs, the pipelines, the batch jobs, the shared databases. From there, the gap between current architecture and compliant architecture becomes the engineering work to be done.

At Ampleshift, we build integration architectures for organisations operating in exactly this environment. We work with Swiss and European companies across banking, pharma, manufacturing, and insurance to design systems where compliance is built in, not retrofitted. Senior expertise from day one. No billing games. Every engagement ends with systems that work and a client that stays.