European agentic payment rails: PSD2, PSD3, EUDI and SEPA

Which layer answers which question?

“European rails” is useful shorthand, but not a single protocol. A system can use existing euro payment infrastructure while experimenting with agent mandates and wallet identity independently.

PSD2, PSD3 and PSR: rules, not transfer networks

PSD2 supplies the existing open-banking context for account information, payment initiation and Strong Customer Authentication. The PSD3/PSR revision develops the payment-services framework further. The European Commission's payment-services overview is a starting point for the legislation and its development.

A product roadmap saying “PSD3-ready” is not evidence of legal compliance. Engineering needs to track the relevant published texts, their legal status and application dates, then map actual obligations to actual behavior. A proposed requirement, an adopted rule and a requirement already applicable to a particular provider are different things.

Introducing an AI agent does not remove the underlying provider's obligations. Before a real-money deployment, establish who provides the regulated service, who holds or accesses credentials, what the customer authorizes and who handles incidents or disputes. A sandbox's technical behavior cannot answer those institutional questions on its own.

EUDI wallets: trusted identity with a defined purpose

The European Digital Identity Wallet payment-authentication use case connects wallet presentations to existing account-to-account and card payments. The Commission describes the relying party and trust infrastructure in its EUDI payment-authentication guide.

In a general design, the service verifies the credential's origin, integrity, validity and relationship to the current request. It should ask for the attributes needed for that purpose, not an entire identity profile. A presentation valid for sign-in should not silently become reusable authority for unrelated purchases.

Wallet authentication and agent delegation can work together: the wallet helps establish evidence about the person, while a reviewed mandate defines the agent's permitted actions. Real-wallet interoperability also involves the ecosystem's trust and relying-party requirements. Emulating credential verification is useful engineering work, but is not the same as qualifying as a production relying party.

SEPA, instant payments and payee verification

SEPA Credit Transfer and SEPA Instant Credit Transfer concern how euro payments are executed between participating providers. The European Payments Council's SCT Inst overview explains the instant-transfer scheme. Speed changes the time available to catch a mistake, so pre-execution checks matter.

Verification of Payee helps check a recipient name against the account identifier before payment. It is a useful signal, not proof that an invoice is legitimate or that an agent's purchase serves the owner's interests. The authority check still needs the reviewed recipient, final amount and purpose.

For an agent, a provider timeout is especially important. Reconcile the original instruction before submitting another transfer. Fast execution is valuable only if the system can also explain whether a payment was refused, accepted, pending or completed.

Build an adapter boundary, not a universal permission token

Keep the owner's intent and agent mandate separate from the provider-specific payment request. An adapter can translate a permitted action into the relevant API, but must not hide differences in authentication, recipient identification, cancellation or finality.

The same principle applies to future infrastructure. A digital euro integration would need its own supported interfaces and rules. Reusing a policy model does not guarantee that another rail accepts the same credential or permits the same unattended behavior.