Skip to content

Cross-Border AI Data Transfers: GDPR Rules for Banks

Sotiris SpyrouUpdated on

Share this article

LinkedInXEmail
Cross-Border AI Data Transfers: GDPR Rules for Banks

To move personal or financial data across borders to train or run an AI system, a bank or fintech needs a lawful transfer route under GDPR Chapter V: an adequacy decision, an appropriate safeguard such as Standard Contractual Clauses, or, rarely, a narrow derogation. Pick the wrong one, skip the transfer risk assessment, and the transfer is unlawful, whatever the model does next.

This catches firms out because an AI deployment hides the transfer. A model hosted in the US, a vendor's training pipeline in India, a support team abroad reviewing flagged transactions. Each one can be a restricted transfer of personal data out of the EEA or the UK. The AI is new. The transfer rules are not. They've been litigated hard since 2020, and the financial sector sits on top of its own localisation and outsourcing rules too.

Here's what boards, data leaders, and compliance teams at banks and fintechs need to manage.

What counts as a cross-border data transfer in an AI system?

A restricted transfer happens when you send personal data to a country outside the EEA (under EU GDPR) or outside the UK (under UK GDPR), or you let someone in that country access it. With AI, the transfer often isn't obvious.

Three common patterns:

  • Training. You send customer records, transaction histories, or call transcripts to a model provider or a vendor's pipeline located abroad.
  • Inference. Live data leaves the region every time the model runs, because the model or API endpoint sits in another country.
  • Support and oversight. Staff or contractors abroad review model outputs, label data, or handle escalations, and so access the underlying personal data.

Article 44 GDPR sets the general rule: no transfer to a third country unless one of the mechanisms in Articles 45 to 49 applies, and the rest of the GDPR is still met. The model being clever doesn't change that.

GDPR Chapter V gives you a short list, in a rough order of preference.

Route GDPR basis When it fits Watch-outs
Adequacy decision Art. 45 Destination country (or framework) is deemed to offer essentially equivalent protection Can be challenged or withdrawn; check scope carefully
Standard Contractual Clauses Art. 46 No adequacy; you sign the Commission's clauses with the importer Requires a transfer risk assessment plus any extra safeguards
Binding Corporate Rules Art. 47 Intra-group transfers across a multinational Slow to get approved; suits large groups, not most fintechs
Derogations Art. 49 Explicit consent, contract necessity, one-off cases Narrow by design; not a route for routine AI data flows

The European Data Protection Board has been blunt that Article 49 derogations are exceptions, not a workaround for systematic transfers. If your AI runs the same flow every day, derogations almost certainly don't cover it.

Does the EU-US Data Privacy Framework solve the US problem?

Partly, and only if you check the detail. The European Commission adopted its adequacy decision for the EU-US Data Privacy Framework on 10 July 2023. A US importer that's actively self-certified to the framework can receive EU personal data without you needing SCCs for that transfer.

Two things to manage:

  • Certification is per-organisation and live. The receiving company must hold a current DPF certification covering the relevant data type. A model vendor that isn't certified gives you nothing here, and you fall back to SCCs.
  • The framework is under legal pressure. The EU General Court dismissed the first challenge, brought by French MP Philippe Latombe, on 3 September 2025 (Case T-553/23). He has appealed to the Court of Justice. The decision stands for now, but anyone who lived through Privacy Shield's collapse should keep SCCs ready as a fallback. Two earlier transatlantic frameworks were struck down.

That history is why this matters. The Schrems II ruling (Case C-311/18, July 2020) killed Privacy Shield and told controllers that SCCs aren't a rubber stamp. You have to check whether the destination's laws, including government surveillance powers, actually let the safeguards work, and add measures if they don't.

What does a transfer risk assessment actually require?

If you're relying on SCCs (or the UK equivalents), a transfer risk assessment isn't optional paperwork. It's the step that makes the safeguard valid.

The EDPB's recommendations on supplementary measures set out the logic: map the transfer, identify the tool, assess whether the destination's law undermines it, add supplementary measures if it does, and review. For AI, the assessment has to cover the model vendor, any sub-processors, and where the data actually rests and gets processed, not just the company you signed with.

Common supplementary measures for AI data flows:

  • Encryption in transit and at rest, with keys held in the EEA or UK.
  • Pseudonymisation before the data leaves, so the importer can't link records to individuals.
  • Keeping raw data in-region and sending only model outputs or aggregates abroad.
  • Privacy-preserving training such as federated learning, where the model trains where the data sits and only parameters move.

These aren't cures. A transfer risk assessment that finds genuine, unmitigated surveillance exposure should stop the transfer, not decorate it.

How is the UK different now?

The UK runs a parallel regime, and as of 2026 it's diverging on purpose.

UK exporters use the ICO's International Data Transfer Agreement (IDTA), or the Addendum to the EU SCCs, as their appropriate safeguard, and must complete a transfer risk assessment first.

Two 2026 changes matter for any UK bank or fintech:

  • The Data (Use and Access) Act 2025 brought in a new test for transfers. Instead of the EU's "essential equivalence" standard, the destination's protection must be "not materially lower" than the UK's. Key data protection provisions began commencing from 5 February 2026, and the ICO said it would update the IDTA, the Addendum, and its TRA guidance through 2026. UK and EU assessments of the same transfer can now reach different answers.
  • EU-UK adequacy was renewed. The UK's decision was due to lapse on 27 December 2025. On 19 December 2025 the European Commission renewed it, out to 27 December 2031, so EEA-to-UK data still flows freely for now. That renewal isn't permanent, and a wider UK-EU divergence could reopen it.

Run a UK firm with EU customers and you're managing both rulebooks at once. They no longer move in lockstep.

What financial-sector rules sit on top?

Data protection is the floor, not the ceiling. Banks and fintechs carry extra constraints that shape where AI data can go.

  • Outsourcing and third-party risk. Supervisors expect firms to govern AI vendors as outsourced providers: due diligence, audit rights, exit plans, and clarity on where processing happens. In the EU, the Digital Operational Resilience Act (DORA) hardens this for ICT third parties, cross-border ones included.
  • Confidentiality and banking secrecy. Some jurisdictions restrict moving customer banking data abroad on top of GDPR. The transfer can be lawful under data protection law and still blocked by sector rules.
  • AML data sharing. Cross-border sharing of anti-money-laundering intelligence has its own legal gateways, and they don't override transfer rules. Both have to be satisfied. See our note on AML compliance requirements for AI systems.
  • Data localisation. A handful of countries require certain financial or personal data to stay onshore, which can rule out a foreign-hosted model outright.

These threads tangle. A transfer that clears GDPR can still fail on outsourcing governance, secrecy law, or localisation. Map all of them before you sign the vendor.

Frequently asked questions

Does GDPR apply if we only use anonymised data to train AI?

If the data is genuinely anonymous, so no one can be re-identified by any reasonable means, GDPR doesn't apply and the transfer rules fall away. The bar is high. Most "anonymised" datasets are actually pseudonymised, especially rich financial records, and pseudonymised data is still personal data under GDPR. Test the claim before you rely on it.

Can we use a US AI model provider after the Data Privacy Framework?

Yes, if that specific provider holds a current DPF certification covering your data, or you put SCCs (plus a transfer risk assessment) in place. Check the certification on the official register rather than taking a sales claim at face value, and keep SCCs ready given the live legal challenge to the framework.

Is sending data to a cloud AI API a "transfer"?

Usually, yes, if the endpoint or the underlying processing sits outside the EEA or UK, or staff there can access the data. Region selection in a cloud console doesn't always pin every sub-process in-region. Confirm where inference runs, where logs land, and where support teams sit.

What's the difference between an EU TIA and a UK TRA in 2026?

They share a purpose, judging whether a safeguard gives enough protection, but the legal tests now differ. The EU applies "essential equivalence". The UK, under the Data (Use and Access) Act 2025, applies "not materially lower". The same US transfer can pass one and not the other, so UK firms with EU data should run both.

The bottom line

Most cross-border AI compliance failures in financial services won't come from a dramatic new rule. They'll come from a transfer nobody mapped: a model API quietly hosted abroad, a vendor's sub-processor in a third country, an offshore support desk reading flagged accounts. The AI made the data flow invisible, and the transfer assessment never happened.

My view: treat the data map as the deliverable, not the model. Before any AI project touches personal or financial data, write down where the data starts, every place it travels, who can see it, and which lawful route covers each hop. Do that and the Chapter V analysis nearly does itself. Skip it and you're hoping a vendor's defaults happen to be legal, which is no position for a regulated firm.

The transfer rules aren't the obstacle here. The blind spot is. For the wider risk picture, see our analysis of AI threats facing banking and the EU AI Act compliance checklist by industry.

Part of VerityAI's cross-border AI data compliance for financial services.

This is the kind of work our AI governance and compliance handles.

Share this article

LinkedInXEmail
Sotiris Spyrou - Author

Sotiris Spyrou

Sotiris Spyrou is the founder of VerityAI, a Responsible AI advisory for boards and AI-deploying businesses. With 27 years across agencies, global in-house roles, and the C-suite, he advises leaders on AI governance and risk, and on answer-engine visibility engineered without the dark patterns the rest of the industry is getting penalised for. He is the author of TRANSFORM, AI Moats, and Ethical AI.

Founder at VerityAI