A fintech company that moves customer data outside the European Economic Area needs a lawful transfer mechanism for every flow, and after the Court of Justice of the EU's Schrems II judgment the standard toolkit narrowed. Standard contractual clauses remain the workhorse, but they no longer work on their own: exporters must assess the destination country's laws and add supplementary measures where the assessment fails. Adequacy decisions, where they exist, remove that assessment burden entirely.
This article explains the three mechanisms in practical terms, which one applies in which situation, and what an audit trail has to show when a regulator asks. It is information, not legal advice; firms should take their own facts to qualified counsel.
What is a cross-border data transfer under GDPR rules?
A transfer occurs whenever personal data leaves the EEA and someone outside it can access it — not only when data is copied to a server abroad. A support engineer in a third country opening a European customer's account record is a transfer. So is cloud storage where an administrator sitting abroad can, in principle, read the data, even if no one ever does. Readers following this should also see What the CFPB's Personal Financial Data Rights Rule Requires, and When Compliance Deadlines Hit.
The GDPR's transfer chapter applies to controllers and processors alike. A fintech processor running KYC checks from a delivery centre outside the EEA is making transfers, and its client, as controller, shares responsibility for the mechanism. The definition is broad because the law targets access, not geography alone.
How do standard contractual clauses work?
Standard contractual clauses, or SCCs, are pre-approved contract templates issued by the European Commission. The parties execute the relevant module — controller-to-controller, controller-to-processor, processor-to-processor, or processor-to-controller — and the clauses become the legal basis for the transfer. Nothing needs to be filed with a regulator beforehand.
The mechanism is contractual, and that is both its strength and its weakness. It is fast to deploy and works for any destination country. But a contract binds only the parties that signed it. It cannot bind a third-country government that demands access to the data, which is precisely the problem the Schrems II judgment put at the centre of the analysis.
Since the Commission's updated SCCs replaced the older sets, firms using legacy clauses have had to move to the current templates for new contracts and to transition existing ones. The clauses also now carry a built-in obligation to assess third-country law and to implement supplementary measures where needed. A signature alone is no longer the compliance event; the assessment is.
When does an adequacy decision remove the extra work?
An adequacy decision is a formal European Commission finding that a third country's legal framework protects personal data to an essentially equivalent standard. Where one exists, data can flow to that country as if it were inside the EEA: no SCCs, no transfer impact assessment, no supplementary measures for that route.
The list of covered countries is limited and can change, because adequacy decisions can be reviewed, amended, or invalidated. A country that holds adequacy today may not hold it after the next review, which means a compliance team cannot treat the list as permanent infrastructure. Checking the current Commission list before relying on a route is part of the job, not a one-time setup step.
Adequacy also covers the country, not every recipient in it. A recipient in an adequate country still has to comply with its own obligations, and a transfer onward from that country to a non-adequate one needs its own mechanism.
What did Schrems II change in practice?
In Schrems II, the Court of Justice invalidated one transatlantic transfer mechanism and confirmed that SCCs are valid only if the exporter verifies that the law and practice of the destination country do not prevent the importer from honouring the clauses. Where government access rights undermine that protection, the exporter must add supplementary measures or suspend the transfer.
The practical consequence is the transfer impact assessment. Before relying on SCCs, the exporter documents the data categories, whether they will be encrypted and by whom, the destination country's access regime, and whether the chosen measures actually protect the data in a worst-case scenario. Encryption where the exporter holds the keys, pseudonymisation, and contractual transparency commitments are the standard supplementary measures, but none is a magic fix. If the data in the clear would be accessible and the data is sensitive, the honest answer may be that the transfer cannot proceed.
For fintech, the stakes are concrete. Transaction data, KYC files, and credit information are exactly the categories regulators expect to see assessed carefully, and a generic template assessment that copies the same paragraphs for every vendor will not survive an audit.
What audit trail should a compliance team maintain?
The defensible record is a transfer register plus the assessments behind it. At minimum, teams should be able to produce the following for each flow:
- The mechanism relied on: the executed SCC module, the adequacy decision relied on and its date, or another recognised tool.
- The transfer impact assessment: data categories, destination, local access laws considered, and the reasoning.
- Supplementary measures in place, and evidence they are operating — not just described.
- Vendor due diligence showing the importer's role, sub-processors, and onward transfers.
- Review dates, so the file shows when the assessment was last revisited.
Regulators do not grade elegance. They ask whether the exporter knew the risks and can show what it did about them. A file that answers those two questions in order is the deliverable.
What this means in practice
Three operational consequences follow from the sourced record above. First, map the flows before choosing tools: most firms discover that cloud administration access, support tooling, and analytics pipelines create transfers nobody inventoried. Second, budget for the assessment as recurring work, not paperwork — adequacy lists shift, vendors add sub-processors, and courts revisit mechanisms. Third, treat encryption key control as a design decision, because it determines whether a supplementary measure is real or decorative.
Firms building compliance programmes around adjacent regimes face overlapping duties: the EU's operational-resilience rules for ICT third parties, covered in How DORA Classifies Critical ICT Third-Party Providers and What That Means for Fintech Contracts, and open-banking data duties under What the CFPB's Personal Financial Data Rights Rule Requires, and When Compliance Deadlines Hit, both touch the same vendor files. Broader rulemaking context sits in the site's regulation coverage, and day-to-day programme material in compliance. We covered a connected angle in How DORA Classifies Critical ICT Third-Party Providers and What That Means for Fintech Contracts.
The evidence establishes the mechanisms and the assessment duty. What remains genuinely uncertain is the long-term shape of transatlantic data policy, which has been reworked more than once and depends on future court review. Firms should build the audit trail so that when the framework shifts again, the register shows which flows need re-papering — and which already survive on adequacy alone.
Sources: en.wikipedia.org · britannica.com · rulings.cbp.gov