An automated claims pipeline processes personal data at every step: policyholder identity, booking records, travel dates, flight data matched to individuals, payment details for settlement. For a Swiss-based operation serving European insurers, this means navigating both the revised Federal Act on Data Protection (revFADP, in force September 2023) and the General Data Protection Regulation. Neither is optional; both apply in most of our deployments.
The compliance architecture for claims automation is not the same as the compliance architecture for a CRM or analytics platform. The specific constraints of insurance claims processing, the data flows involved, and the lawful basis framework all have characteristics that require specific treatment. This post explains how we approach those requirements and the choices we have made, not as a legal document, but as a working description for compliance and operations teams evaluating the platform.
Controller versus processor: the foundational question
Insurteam operates as a data processor under both FADP and GDPR. The insurer is the data controller: they hold the original relationship with the policyholder, define the purpose of the claims processing, and determine what data is collected. Insurteam processes that data on the insurer's behalf, under the insurer's instructions, as documented in a Data Processing Agreement (DPA).
This distinction matters practically because it determines who bears the primary obligations to data subjects. The insurer is responsible for providing the Article 13/14 GDPR transparency notices to policyholders that describe automated processing. Insurteam's obligations are to process only in accordance with documented instructions, to maintain appropriate technical and organisational security measures, to support the insurer in responding to data subject requests, and to notify the insurer promptly in the event of a data breach.
We do not act as a joint controller. We do not use policyholder claim data for any purpose other than processing the claims the insurer has submitted to the pipeline.
Lawful basis for automated decisioning
Under both FADP and GDPR, automated processing of personal data requires a lawful basis. For insurance claims, the primary basis is contractual necessity: the insurer processes personal data to perform the insurance contract with the policyholder. This is a strong foundation for most claims processing activities.
The constraint that matters for automated coverage decisions: Article 22 GDPR restricts purely automated decisions that produce legal or similarly significant effects on data subjects. A coverage determination is a legal effect. A fully automated claims decision that pays, denies, or reduces a benefit must satisfy one of three Article 22 exceptions: contractual necessity, explicit consent, or Union or Member State law authorising the processing.
The contractual necessity exception is applicable for standard parametric travel claims, but it requires that the automated processing is genuinely necessary for performing the contract, not merely convenient. It also requires the insurer to inform data subjects about the automated decision and the underlying logic, and to provide a means to request human review of any automated determination. Insurteam's pipeline is designed to support those obligations: every automated decision produces a structured audit record with the policy clause references used, the data sources queried, and the confidence scores on each extracted element. That record forms the basis for explaining the decision to a policyholder if they request it.
Data minimisation and retention architecture
The Insurteam pipeline is built around data minimisation. The extraction layer processes policy documents to extract the coverage logic relevant to the claim type; it does not retain full document text after extraction is complete. The flight data integration retrieves flight status against a specific booking reference; it does not build travel history profiles for policyholders. The claim record stores the structured data the claims process requires; enrichment data used during decisioning is not persisted beyond the processing event unless the insurer's retention configuration specifies otherwise.
This architecture serves compliance on two dimensions. It minimises the regulatory surface area for data subject access and deletion requests, because there is less data to locate and produce. And it limits the scope of a potential security incident, because the data present in the system at any point reflects only what active processing requires.
Retention periods are configured per deployment based on the insurer's legal and regulatory obligations. In Switzerland, claims records are typically subject to 10-year retention requirements under the Insurance Contract Act (VVG). EU deployments may have different jurisdiction-specific requirements. Insurteam's configuration layer allows retention periods to be set per data category, with automated deletion after expiry.
Cross-border transfers between Switzerland and the EU
In a deployment where the insurer client is based in an EU member state, policyholder claim data processed in Switzerland flows across a border subject to both FADP and GDPR transfer requirements. Switzerland holds an adequacy decision from the European Commission for transfers under GDPR, meaning EU-originated personal data can flow to Switzerland without additional transfer mechanism documentation under that specific legal basis.
From the Swiss side, the revFADP also requires appropriate safeguards when personal data is transferred abroad. For transfers to EU-based insurer clients where the data originates in Switzerland (for example, claims from Swiss policyholders processed by the pipeline and then returned to an EU-based insurer system), the revFADP adequacy assessment for EU member states provides the applicable safeguard.
Every deployment includes a DPA that documents the controller-processor relationship, the categories of data processed, the processing purposes, the technical and organisational security measures, and the cross-border transfer mechanisms. This documentation is reviewed and signed before any production data flows. For us, it is not a legal formality; it is the document that aligns both parties on exactly what data moves, where it goes, and who is responsible for what.
Data subject requests in a live claims context
Handling data subject access requests for claims data is operationally different from handling them for marketing or analytics data. Claims records carry retention obligations under insurance regulatory requirements that may conflict with a data subject's right to erasure. The right to erasure under GDPR Article 17 has explicit exceptions for processing necessary for the performance of a contract and for compliance with a legal obligation. Claims records typically fall within both exceptions for their full retention period.
The practical compliance approach is: pseudonymise where the process allows, retain only what regulatory requirements demand, and respond to access requests with a structured data export that makes the information understandable without requiring manual reconstruction from raw database records. Insurteam's claim record structure is designed to produce a readable subject access export directly, without interpretation by a developer.
The compliance picture for claims automation is manageable, but it requires deliberate architecture choices made at design time. Retrofitting data minimisation, retention controls, or automated decision transparency after a pipeline is deployed is expensive and incomplete. The choices we have described here reflect requirements we encoded from the start, not features added in response to a compliance audit.
