PSD3 and Agentic Payments: What the New EU Rulebook Changes (and What to Do Before It's Law)
_Last updated: 2026-06-07_
PSD3 and its companion Payment Services Regulation (PSR) will require spend-limit and transaction-blocking tools and harmonize liability across the EU. Two things they won't do: address AI-agent-initiated payments (the agreed texts are silent on agents) and arrive quickly (most provisions apply around 2028). That gap is the story, anyone deploying EU-facing agents today is operating under PSD2 rules written before AI agents existed, while the replacement rulebook works through its final formalities.
---
Key takeaways
- PSD3 + the PSR replace PSD2. The PSR is a regulation, it applies directly across all 27 member states, killing the multi-version implementation problem.
- The agreed texts don't specifically address AI-agent-initiated payments. Whether an agent paying on a user's behalf needs its own licensed category is still an open question.
- The PSR requires payment providers to give users tools to set transaction limits and block payment types, directly relevant to agents.
- The PSR applies roughly 21 months after entry into force, with Official Journal publication expected mid-to-late 2026. That puts most provisions around 2028. PSD2 remains the law in force until then.
- The smoothest transition belongs to builders implementing delegation controls, spend limits, and audit trails now.
---
What are PSD3 and the PSR?
PSD2 (live since 2018) gave Europe open banking, strong customer authentication, and third-party payment initiation. But it was a directive, each member state wrote it into national law, producing 27 implementations with real variation.
PSD3 and the PSR are the fix. The PSR is the structural change that matters: it's a regulation, not a directive, so it applies directly and uniformly everywhere. The Commission published the proposals in June 2023. Parliament and Council reached provisional political agreement on November 27, 2025, and the Council published final compromise texts on April 23, 2026. Official Journal publication is expected mid-to-late 2026, and the PSR applies roughly 21 months after entry into force. That puts most provisions around 2028, with PSD2 staying in force until then.
---
How does PSD3 treat delegated payment initiation?
Delegated payment initiation is when a third party, including an AI agent, is authorized to initiate payments for an account holder. The concept is old (direct debits, recurring billing, subscriptions). What's new is the actor: an agent paying for services, booking resources, or transacting autonomously.
PSD2 already recognized payment initiation service providers (PISPs) as a licensed category. PSD3 builds on that framework, but the agreed texts don't specifically address machine-initiated flows. They still assume a human initiates the payment. How agent-initiated payments map onto the PISP category is a question regulators haven't answered yet.
The obligation that matters: if your agent initiates payments from a user's account (rather than from a payment method you control), the entity enabling that is likely operating as a PISP or similar regulated service. Agents using their own scoped cards, issued to the operator, sit in a different regulatory bucket than agents pulling from user bank accounts. Knowing which you are determines which licenses apply.
---
What does the PSR mandate for spend controls?
The PSR specifically requires providers to give users tools to control how a payment instrument is used:
- Set transaction limits, and providers can't raise agreed limits without the customer's consent.
- Block specific payment instruments or payment types.
- Withdraw standing permissions, including open-banking access, through permission dashboards.
For agent deployments, that means the infrastructure behind agent payments has to expose spend limits and revocation to end users, not just operators. "The agent is authorized, trust it" won't cut it, users get real-time visibility and control over what the agent spends, where, and on what.
None of which is a PSD3 invention. It's a formalization of what good agentic design already does. The regulation is catching up to the architecture security-conscious builders ship anyway.
---
What changes on liability?
Because PSD2 was a directive, fraud liability, unauthorized-transaction handling, and refund rights vary across jurisdictions. The PSR harmonizes that into a single regime, and it more clearly specifies which party, provider, PISP, account-servicing institution, bears initial liability and the right of recourse.
For agents, where the chain runs user → operator → agent → provider, harmonized rules matter: they define who's on the hook when an agent executes an unauthorized transaction. The current PSD2 ambiguity around multi-party chains is expected to be clarified.
The practical takeaway: operators need audit trails that establish the full delegation chain, not "this card was charged" but "this user delegated authority to this agent for this task, and the delegation was valid at the time." That's how liability lands where it should.
---
The timeline, and the gap
| Milestone | Timing |
|---|---|
| Proposals published | June 2023 |
| Provisional political agreement | November 27, 2025 |
| Final compromise texts published | April 23, 2026 |
| Official Journal publication | Expected mid-to-late 2026 |
| PSR applies / PSD3 transposed | ~21 months after entry into force |
| Most provisions in effect | Around 2028 |
The gap: deploy EU-facing agents today and you're under PSD2, which wasn't written for them. PSD3/PSR tightens the general rulebook but stays silent on agents, so there's a window with no clear precedent, and frameworks built now will meet a rulebook change when it lands around 2028. Building to PSD3/PSR standards before they're mandatory is the lowest-friction path through that window.
---
What should builders do today?
Three things, in order.
Model your authorization chain explicitly. Know whether your agents initiate from user accounts (PISP territory) or from operator-issued instruments (a different category). The answer changes which licenses may apply.
Make spend limits and revocation first-class. The PSR is pointing exactly here. Build transaction-level limits and real-time revocation into the architecture now, not as a later retrofit, they also cut your exposure under current PSD2.
Capture delegation context in your audit trail, not just payment metadata. PSD3's liability harmonization rewards operators who can prove the chain: who authorized what, when, and whether the agent stayed in scope. A receipt isn't enough.
---
Frequently asked questions
What's the difference between PSD3 and the PSR?
PSD3 is a directive member states transpose into national law (like PSD2). The PSR is a regulation that applies directly across all member states with no transposition. The PSR is the structurally bigger deal for pan-EU products because it removes the 27-version problem.
When will PSD3/PSR apply to agent payments?
The PSR applies roughly 21 months after it enters into force, and Official Journal publication is expected mid-to-late 2026, so most provisions land around 2028. Until then PSD2 remains the law in force. And the texts don't single out agent payments; agents inherit rules written for human-initiated ones.
Does PSD3 require licensing for agent payment operators?
It depends on architecture. Agents initiating from user accounts are likely in PISP territory; agents on operator-issued scoped cards sit elsewhere. This is informational, get legal analysis specific to your deployment.
What is "delegated payment initiation"?
When a third party, including an AI agent, is authorized by an account holder to initiate payments for them. Under PSD2 that typically needs PISP registration. The agreed PSD3/PSR texts don't address AI-delegated flows specifically; agents inherit rules written for human-initiated payments.
---