GDPR, the EU AI Act, and PSD3: The Three-Law Squeeze on Agent Payments

_Last updated: 2026-06-10_

Every autonomous payment an AI agent makes inside the EU sits under three overlapping regulatory regimes: the EU payment rules (PSD2 today, with PSD3/PSR finalized and arriving around 2027-2028), the EU AI Act (in force as of August 2024), and GDPR. They don't fully agree with each other. And when they conflict, you can't satisfy all three by defaulting to the most restrictive one. You have to know exactly where each applies.

Key takeaways

---

What does each regime actually govern?

PSD3 and the PSR

PSD3 and the Payment Services Regulation will replace PSD2, which remains the payment law in force today. The Commission proposed the package in June 2023, co-legislators reached provisional agreement in November 2025, and the final compromise texts were published on April 23, 2026. Application is expected around 2027-2028; once it lands, the PSR applies directly in member states without national transposition. The substance is continuous with PSD2: rules for payment service providers covering strong customer authentication, liability allocation on unauthorized transactions, and open banking data access. They define who can authorize a payment and on whose behalf. For agent payments, the key question is whether the agent acts as the payer, as the payee's agent, or as a technical intermediary. The answer determines which SCA (Strong Customer Authentication) obligations apply and who holds liability when a charge goes wrong.

The EU AI Act

The AI Act became law in August 2024 with a phased enforcement timeline. It classifies AI systems by risk level. Systems used to evaluate creditworthiness or establish a credit score are listed in Annex III (point 5(b)) as high-risk. The same entry explicitly excepts AI used to detect financial fraud, so a fraud-scoring model is generally not high-risk on that ground. An agent that autonomously decides to execute a payment can still land in scope if it influences credit or financial eligibility decisions. High-risk AI systems require conformity assessments, technical documentation, human oversight measures, and automatically generated logs kept for at least six months (Article 19). The ten-year retention period in Article 18 applies to technical documentation and conformity records, not logs.

GDPR

GDPR governs any personal data touched during the payment process: the cardholder's identity, transaction history used for fraud scoring, behavioral data used to build spending profiles. The data minimization principle (Article 5(1)(c)) says you process only what's strictly necessary for the purpose. The purpose limitation principle says data collected for one purpose can't be reused for another without a fresh legal basis.

---

Where do the three laws overlap, and where do they conflict?

The overlap is substantial. All three require some form of audit trail. All three put accountability on the organization deploying the system, not just the software vendor. All three can trigger cross-border jurisdiction questions when the agent operates in multiple EU states.

The conflicts are more interesting.

Audit completeness vs. data minimization

Financial regulators, and courts in a dispute, want a complete record of every authorization decision: what data the agent had, what logic it applied, what it spent, and why. The AI Act's high-risk logging requirements reinforce this. GDPR's data minimization principle pushes the other way: retain only what you need for the stated purpose. "We might need it someday for a fraud investigation" is not a purpose. You need a documented legal basis (Article 6) and a retention schedule you can defend to a Data Protection Authority.

A transaction log detailed enough to satisfy a PSD2 dispute resolution process may include fields that violate GDPR minimization if they're not purpose-justified. This isn't theoretical: EU DPAs have fined financial institutions for retaining excessive transaction metadata.

AI Act transparency vs. commercial sensitivity

AI Act Article 13 requires providers of high-risk systems to give deployers transparent information about how the system works. The right to an explanation of a specific decision sits elsewhere: AI Act Article 86 gives affected individuals a right to an explanation of high-risk decisions, and GDPR Article 22 governs rights around automated decisions. But the exact logic of your fraud model is often proprietary. The law doesn't require you to expose the model — it requires you to explain the decision in plain language. The practical challenge is building that explanation layer into your authorization flow.

SCA delegation vs. GDPR consent

The EU payment rules permit delegated authentication: a business can authorize an agent to initiate payments on its behalf under defined conditions, under PSD2 today and PSD3/PSR once it applies. But if the agent processes the payer's personal data to do so, GDPR requires a legal basis. Legitimate interest works in many B2B contexts. It's harder to sustain in B2C flows where the end customer's data is involved.

---

How to build a compliance posture that satisfies all three

Step 1: Classify your AI system under the AI Act before you deploy. If the agent influences credit or financial eligibility decisions, assume high-risk until your legal team says otherwise. Fraud detection is generally carved out of Annex III, but confirm the carve-out actually covers your system before relying on it. Build the conformity documentation now; retrofitting it is expensive.

Step 2: Define your data purposes explicitly and in writing. For each field in your transaction log, document what it is, why you need it, your legal basis under GDPR Article 6, and how long you'll keep it. Where financial regulation requires longer retention than GDPR would prefer, document the conflict and the resolution. Generally, a specific legal obligation under PSD2 or anti-money-laundering rules overrides data minimization for the duration required.

Step 3: Scope your agents tightly. The narrower an agent's credential (one virtual card, limited merchant categories, a hard spend ceiling) the less personal data it touches per transaction. Less data in means less minimization exposure. Scoped credentials also shrink the blast radius if the agent behaves unexpectedly, which satisfies the AI Act's human oversight requirement more cleanly.

Step 4: Build the explainability layer. Every authorization decision the agent makes should be able to produce a human-readable reason code on demand, for any transaction, within a reasonable timeframe. This satisfies the AI Act Article 86 explanation right and GDPR Article 22.

Step 5: Engage your DPA early if you're processing at scale. Large-scale processing of financial personal data may require a Data Protection Impact Assessment under GDPR Article 35. A DPIA conducted before launch is a defensible record. One conducted after a regulatory inquiry is a liability.

---

Frequently asked questions

Does the EU AI Act apply to AI agents that just execute payments, not decide them?

Probably not as high-risk. If the agent is purely a mechanical executor following a human-defined rule (spend up to €50 at approved vendors), it's not making a substantive decision. The risk classification rises when the agent exercises judgment: choosing whether to proceed, selecting among options, or overriding a default. If there's real decision-making in the loop, get a legal opinion before assuming low-risk.

Does GDPR data minimization mean I can't keep a full transaction log?

No. It means you need a documented legal basis for every field you retain. Financial regulation (PSD2, anti-money-laundering directives) provides that basis for core transaction data. Where you run into trouble is retaining enriched data, like behavioral profiles, device fingerprints, or third-party-linked identifiers, beyond what the stated purpose requires.

Who is the "controller" under GDPR when an AI agent initiates a payment?

The company deploying the agent is the controller. The payment service provider (the bank or card issuer) is typically a separate controller for their part of the processing. If you're using third-party agent infrastructure, your data processing agreement with that provider needs to be in place before the first transaction.

---