By crossborderfees October 11, 2025
The General Data Protection Regulation (GDPR) reshaped how organizations collect, use, and move personal data across borders—especially financial details that travel through global payment rails.
For payment processors, gateways, acquirers, issuers, and merchants that touch “international payment data,” the GDPR introduces strict duties around lawful processing, security, transparency, and cross-border transfers.
The regulation applies not only inside the EU/EEA but also to many non-EU businesses that offer goods or services to people in the EU or monitor their behavior. That territorial reach means a card transaction in one country can instantly trigger GDPR obligations in another.
Understanding those obligations is essential to reduce regulatory risk, avoid fines, and maintain customer trust in a world where digital commerce is borderless but compliance is not.
What exactly counts as “international payment data” under GDPR’s territorial scope?
Under GDPR, “personal data” means any information relating to an identified or identifiable person. In payments, that routinely includes names, billing addresses, card tokens, transaction timestamps, IP addresses, device IDs, and sometimes location or ID document data used for KYC, AML, or fraud checks.
The moment a payment involves data subjects “in the Union,” the GDPR can apply—even if your company is established elsewhere. That extraterritorial rule flows from Article 3: the regulation covers processing by EU establishments, and also by non-EU businesses when they target EU residents or monitor their behavior.
For payment companies selling to EU consumers, or fraud teams profiling EU cardholders, GDPR territorial scope is typically triggered. Practically, “international payment data” is any payment-related personal data that crosses borders or is handled by non-EU providers while linked to EU data subjects.
This is why a subscription merchant in the U.S. servicing French customers, or a wallet in APAC evaluating EU transactions, must meet GDPR standards on lawful basis, transparency, and transfers.
Lawful basis and data minimization for payment processing
GDPR requires a lawful basis for every processing activity. In payments, “contract” often covers core processing needed to take and settle a transaction. “Legitimate interests” may support fraud prevention, chargeback handling, and risk analytics, provided you apply balancing tests and give clear rights information.
“Legal obligation” can cover AML/KYC retention. Whatever your basis, you must also apply data-minimization and purpose-limitation principles: collect what’s necessary, use it only for stated purposes, and store it no longer than required.
In practice that means tokenizing PANs, hashing emails used for risk signals, separating marketing profiles from payment records, and enforcing strict retention policies aligned to card scheme rules and statutory periods.
When you add new use-cases—like behavioral fraud models or network token optimization—conduct data protection impact assessments (DPIAs), update records of processing, and ensure transparency notices reflect each purpose and legal basis.
Because payment stacks rely on many subprocessors, ensure each vendor’s purpose/basis aligns with yours and is reflected in your data processing agreements (DPAs). Although these principles arise throughout GDPR, they become especially important when transactions cross borders and multiple entities touch the same personal data.
Cross-border transfers: Articles 44–49 and the toolbox for moving international payment data
When personal data leaves the EEA (or is remotely accessed from a third country), GDPR’s international transfer rules apply. Article 44 sets the general principle: transfers must maintain an essentially equivalent level of protection.
From there, Articles 45–49 define the tools: (1) adequacy decisions (the Commission decides a destination ensures adequate protection), (2) appropriate safeguards like Standard Contractual Clauses (SCCs) or Binding Corporate Rules (BCRs), and (3) narrow derogations (Article 49) such as explicit consent or necessity for contract performance.
For most payment flows to non-adequate destinations, organizations rely on the Commission’s 2021 modernized SCCs, which consolidate modules for controller-to-controller, controller-to-processor, and processor-to-processor transfers and address Schrems II requirements (e.g., assessments and supplementary measures).
BCRs remain valuable for large groups moving data internally, but require supervisory authority approval and robust enforceable rights. Derogations, like “necessary for performance of a contract,” are not suitable for repetitive, large-scale transfers common in payment processing and must be used restrictively.
Payment providers should map transfers, choose the right tool per path, and document the reasoning.
The EU–U.S. Data Privacy Framework (DPF) and UK extension: where things stand now
In July 2023, the European Commission adopted an adequacy decision for the EU–U.S. Data Privacy Framework, enabling certified U.S. companies to receive EU personal data without SCCs for those transfers.
In September 2025, the EU’s General Court upheld that adequacy decision against a legal challenge, reinforcing short-term certainty for transatlantic data flows—including payments, fraud analytics, and support services.
Separately, the UK implemented the “UK Extension to the EU–U.S. DPF,” also called the UK-U.S. “data bridge,” effective 12 October 2023, allowing certified U.S. recipients to lawfully receive UK personal data.
For payment companies, DPF certification by U.S. vendors can simplify transfer compliance, but it’s not automatic: you must verify the recipient’s active listing and scope, and maintain vendor governance.
Keep in mind that activist challenges may continue, so transfer risk management (e.g., TIAs and technical controls) remains best practice even under adequacy routes. Where U.S. partners are not DPF-certified, fallback to SCCs with supplementary measures is still expected.
Schrems II, Transfer Impact Assessments, and supplementary measures you’ll actually use
The Court of Justice’s 2020 Schrems II ruling invalidated the old EU-U.S. Privacy Shield and tightened expectations when using SCCs. Controllers and processors must verify—case by case—whether foreign law and practices might impinge on EU-level protections, and implement “supplementary measures” where needed.
The EDPB’s Recommendations 01/2020 provide a practical roadmap: map transfers, identify transfer tools, assess third-country surveillance and redress risks, and adopt technical, contractual, and organizational safeguards.
For payment data, effective technical measures often include end-to-end encryption, robust pseudonymization before export, strict key management under EU control, and data-in-use protections where possible.
Contractually, you should require transparency commitments, challenge policies for government access, and notice obligations. Organizationally, apply need-to-know access controls, logging, and independent oversight.
Most teams formalize this via a Transfer Impact Assessment (TIA) per vendor and per data flow. Even with the new EU–U.S. DPF, TIAs remain useful to continuously document risk posture, especially for non-adequate destinations and complex processor chains used in global acquiring, risk scoring, or support operations.
UK GDPR transfers: IDTA and the Addendum you can’t ignore
Since Brexit, the UK requires its own transfer instruments. The ICO introduced the International Data Transfer Agreement (IDTA) and a UK Addendum to the EU SCCs, effective February 2022. If you move UK personal data to third countries, you must use either UK adequacy, the IDTA, or the Addendum attached to the EU SCCs.
Many payment providers pair the EU SCCs for EEA data with the UK Addendum for UK data in a single contracting package. Others deploy the standalone IDTA for UK-only flows. This matters in real payment stacks where a UK merchant routes to an EU gateway that then relies on U.S. fraud services or cloud support.
Your transfer register should differentiate EU and UK paths and confirm that each path has the corresponding instrument. Also watch the UK’s evolving adequacy regime and any divergence in guidance, but note that BCRs remain available under UK GDPR too, with approval by the Commissioner.
Operational impacts for payment teams: PCI DSS, PSD2/SCA, and security baselines
GDPR is not a security standard, but Article 32 requires “appropriate” technical and organizational measures. In card environments, PCI DSS remains a critical baseline. PCI DSS v4.0 strengthens requirements like multi-factor authentication across the cardholder data environment and continuous risk analysis.
While PCI compliance doesn’t equal GDPR compliance, it supports security of processing, especially when combined with tokenization, encryption, and least-privilege access.
On the regulatory side, PSD2’s Strong Customer Authentication (SCA) reduces fraud and protects customers, complementing GDPR’s principles of integrity and confidentiality.
Payment providers should ensure that security controls meet PCI DSS 4.0 by the 2025 deadlines, while translating those controls into GDPR risk assessments, DPIAs, and data protection by design.
In cross-border contexts, adopt EU-controlled key management and ensure your cryptographic posture spans data at rest, in transit, and in use. Link these controls to your TIAs so they are not just technical wins but documented GDPR safeguards that support lawful international transfers.
Binding Corporate Rules vs. SCCs for international payment data
BCRs are internal codes of conduct for multinational groups, approved by EU supervisory authorities, that permit intra-group transfers globally when they embed GDPR-level protections and confer enforceable rights on data subjects.
They suit large processors with many entities—such as global acquirers, card networks, or cloud infrastructure groups—who want a durable, group-wide mechanism. SCCs are faster to deploy and fit best for external transfers between distinct businesses (e.g., a merchant and a fraud-detection vendor).
Many payment ecosystems use both: BCRs for internal hops between EU and non-EU affiliates, and SCCs for third-party providers. Regardless of the tool, you still need TIAs and—where required—supplementary measures.
Choose the tool based on your organizational structure, the number of entities involved, and your long-term vendor strategy. Document your rationale in your transfer register and DPAs so auditors and regulators can follow the decision path.
Adequacy, SCCs, or derogations: choosing the right path for recurring payment flows
For recurring payment flows—like processing EU card transactions via a non-EU risk engine—rely on stable mechanisms. If the destination has an EU adequacy decision (or DPF for certified U.S. entities), use adequacy because it reduces ongoing overhead.
If no adequacy applies, SCCs are typically the default, paired with TIAs and supplementary measures. Reserve Article 49 derogations for exceptional, non-repetitive situations.
For example, “necessary for performance of a contract” could allow a one-off cross-border booking payment, but it’s inappropriate for routine settlement flows. Explicit consent is hard to use in payments because it must be specific, informed, and revocable, and you must still provide an adequate level of protection.
Build internal playbooks that classify each cross-border route (authorization, clearing, settlement, chargebacks, refunds, fraud analytics, support) and assign the correct transfer tool. Doing this once and maintaining it quarterly is far less painful than scrambling during an audit or incident.
Fraud prevention, profiling, and data subject rights in the payments journey
Fraud prevention often involves profiling and behavioral analytics, which can raise questions under GDPR’s rules on automated decision-making and data subject rights.
While fraud checks are usually necessary and in the legitimate interests of controllers, you still owe transparency, the ability to contest certain automated decisions, and meaningful information about the logic involved.
For payments, a balanced approach includes layered models with human review paths for high-impact outcomes (e.g., persistent declines), explainable risk features where possible, and clear notices in your privacy policy.
If you rely on third-country fraud services, ensure transfers rest on adequacy or SCCs/IDTA and that pseudonymization is applied before export when feasible. The EDPB has emphasized pseudonymization as an important safeguard, clarifying its definition and advantages in 2025 guidance—use it to reduce re-identification risk while preserving analytical utility.
Educate support teams to recognize and route access/erasure requests that touch multiple processors, and build APIs or workflows with vendors so you can fulfill rights across the chain within deadlines.
Pseudonymization, anonymization, and data protection by design for cross-border flows
For international payment data, the most durable control is architectural: minimize raw identifiers and keep re-identification keys inside the EEA. Pseudonymization replaces identifiers with tokens so that additional information is needed to re-identify the person; anonymization goes further and irreversibly removes linkability.
The EDPB’s work program and subsequent guidance have elevated pseudonymization as a practical tool to meet Schrems II expectations when paired with encryption and strict key custody.
A robust pattern is: tokenize PANs and emails; hash device or network identifiers; store cryptographic keys and token vaults in EU-controlled HSMs; and send only the pseudonymized payloads to third-country analytics or support teams.
Combine this with access controls, event logging, and differential retention for EU vs. non-EU environments. Embed these choices in your DPIAs and TIAs to show why remaining risks are acceptable.
This is how “data protection by design and by default” becomes real in global payment stacks rather than a checkbox.
Vendor management, DPAs, and audits across the payment chain
International payment data rarely stays with one party. Gateways, acquirers, processors, fraud engines, CRMs, hosting, and support desks all touch it. Your DPAs must reflect GDPR Article 28 requirements, define subprocessors and locations, and link to the appropriate transfer mechanism.
Build a vendor inventory that shows which tools handle EU and/or UK data, the legal bases for each processing activity, and the exact transfer route. Where vendors rely on the EU–U.S. DPF, record their certification status and scope; for SCCs/IDTA, store signed modules and annexes.
Schedule periodic audits or assurance reviews, focusing on encryption, pseudonymization, incident response, and government-access policies. If enforcement trends show sector-specific risks—like driver data transfer issues or location data misuse—adjust your controls.
Visibility matters: when a regulator asks how a French customer’s refund data reached a U.S. help desk, you should be able to show the transfer map, instrument, TIA, and technical measures within minutes.
Enforcement trends and what they mean for your payment program
EU regulators continue to scrutinize international transfers, transparency, and profiling—areas common in payments. High-profile cases have emphasized that “borderless” product designs do not excuse weak safeguards.
Expect questions about whether your transfers rely on adequacy, SCCs, or BCRs; whether your TIAs are tailored and current; and whether supplementary measures genuinely reduce surveillance risk.
Where companies claimed regulatory uncertainty, authorities have still required evidence of risk assessments and the use of technical measures like strong encryption and pseudonymization.
For payment teams, that means enforcement readiness is operational readiness: up-to-date TIAs, data maps, breach playbooks, and rights-handling workflows across vendors.
As courts uphold new frameworks like the DPF, momentum favors structured, well-documented programs. But challenges remain possible, so resilience comes from engineering controls and documentation rather than relying solely on a legal mechanism.
A practical blueprint for GDPR-compliant international payment data flows
- Map your data: Identify EU/UK data subjects, data types, and every system and vendor touching them. Label cross-border hops and whether remote access from third countries occurs.
- Pick the lawful basis: Contract for core processing; legitimate interests for fraud and chargebacks; legal obligation for AML/KYC—record each in your RoPA and notices.
- Choose a transfer tool per route: Prefer adequacy/DPF where available; otherwise, SCCs (with the UK Addendum for UK data) or IDTA; use BCRs for intra-group; avoid over-reliance on Article 49 derogations.
- Run TIAs: Evaluate recipient laws, vendor controls, and surveillance risk; adopt supplementary technical, contractual, and organizational measures.
- Engineer safeguards: Tokenization, encryption, EU-controlled keys, and pseudonymization before export; restrict access and log every touch.
- Align with PCI DSS and PSD2 security: Map PCI DSS 4.0 and SCA controls to GDPR Article 32 to demonstrate “appropriate” measures.
- Operationalize rights & retention: Automate DSAR routing to processors; set tiered retention for payments vs. marketing; delete or archive per legal need.
- Monitor frameworks: Track DPF listings and legal challenges; refresh TIAs; audit vendors annually; update annexes when subprocessors or geographies change.
FAQs
Q.1: Is PCI DSS compliance enough to satisfy GDPR for international payment data?
Answer: No. PCI DSS focuses on cardholder data security, while GDPR governs all personal data processing, transparency, rights, and transfers. PCI helps with Article 32 (“security of processing”), but you still need lawful bases, notices, TIAs, and transfer tools like SCCs, BCRs, or adequacy routes.
Q.2: Do we still need SCCs if our U.S. vendor is certified under the EU–U.S. DPF?
Answer: If your transfer falls within the vendor’s active DPF certification scope, adequacy covers that flow and SCCs are not required for it. However, maintain vendor governance, confirm listing/scope, and consider TIAs as good practice.
For non-certified vendors or out-of-scope processing, use SCCs (and the UK Addendum for UK data) or IDTA.
Q.3: Are Article 49 derogations a viable way to run recurring cross-border payment operations?
Answer: Generally, no. Derogations like “necessary for performance of a contract” or “explicit consent” are intended for occasional, non-repetitive transfers. Payment processing typically involves systematic, ongoing transfers, which should use adequacy, SCCs, or BCRs.
Q.4: What are Transfer Impact Assessments and when are they required?
Answer: TIAs document whether the law and practices of a destination country may undermine GDPR-level protections and what supplementary measures you apply. They became essential after Schrems II for SCC-based transfers and remain helpful even with adequacy to evidence risk management across complex vendor chains.
Q.5: How do pseudonymization and encryption help with international transfers in payments?
Answer: They reduce exposure by ensuring third-country recipients cannot easily link data to individuals. The EDPB’s guidance highlights pseudonymization as a key safeguard; combined with strong encryption and EU-held keys, it materially lowers risk and supports Schrems II compliance expectations.
Q.6: What changed with the 2021 SCCs and why does it matter to payment processors?
Answer: The 2021 SCCs introduced modular clauses for different controller/processor roles, aligned them with GDPR, and required more detailed annexes and assessments. This matters because payment chains often include multiple processors and sub-processors across borders; the modular SCCs fit those complex realities better than the old clauses.
Q.7: How should we handle UK data versus EU data in the same payment flow?
Answer: Treat them under parallel regimes. Use EU transfer tools for EEA data; for UK data, use UK adequacy, the IDTA, or the UK Addendum to the EU SCCs. Many companies attach the UK Addendum to their SCCs so one contract covers both. Keep a transfer register that distinguishes EU and UK flows.
Conclusion
GDPR’s impact on international payment data is both legal and architectural. Legally, you must ground each processing purpose on a valid basis, provide transparency, honor rights, and choose the correct transfer mechanism—preferably adequacy or SCCs/BCRs—backed by TIAs and supplementary measures.
Architecturally, you need “data protection by design”: tokenize aggressively, encrypt thoroughly, pseudonymize before export, and hold keys in the EU/UK where feasible.
Operationally, align PCI DSS 4.0 and PSD2/SCA controls to Article 32; keep a living data-flow map and transfer register; and continuously audit vendors. With courts currently upholding the EU–U.S.
DPF and regulators reinforcing expectations around TIAs and safeguards, the organizations that thrive will be those that combine sound legal instruments with strong engineering and clear documentation. Do that, and your cross-border payment operations can remain fast, global, and GDPR-compliant—without sacrificing customer trust.