A few weeks ago I wrote about what happens when an AI agent needs to pay. The short version: the payment rails we have were built for humans, and agents are already running into that friction. Since then, one question keeps coming back in every conversation: if an agent can pay, how do we know it’s allowed to, and more importantly, who is it actually acting for?
Two Different Questions, One Payment
Every time an agent initiates a payment, there are really two separate checks happening, even if we tend to blur them together. Think of them as two different ways a payment can go wrong, and two different kinds of fraud each check is designed to stop.
Who is the money going to?
That’s verifying the destination. It stops the fraud where a payment goes to the wrong place: an attacker swaps the recipient’s account details, and your money ends up with them instead of the real supplier or business. Concretely, this means checking that the account receiving the funds is actually held by the person or company the payer thinks it is. In agentic commerce, the agent might only see a merchant’s website or API, but the destination that actually matters is always the legal entity behind it, the account holder tied to the IBAN.
Who is ordering this payment, and did they have permission?
That’s verifying the agent. Here fraud looks a little different: not money reaching the wrong destination, but an agent acting for the wrong person, or a real person’s authorization pushed past the limits they actually set.
The key questions are: Is this software truly acting on behalf of the account holder? And is it operating within the limits and permissions they set?
In agentic commerce, trust cannot rely only on the transaction itself. It requires verifying both sides of the interaction: the destination of the payment and the agent initiating it. Knowing where the money is going and who is allowed to move it is what turns autonomous payments into trusted payments.
Verification of Payee Already Solved the Destination
Since October 2025, the Instant Payments Regulation requires Verification of Payee (VoP) before every payment in SEPA. The payer’s PSP checks whether the beneficiary name matches the actual account holder, and returns a match, close match, or no match.
Here’s the part that’s easy to miss: VoP was never about proving someone exists behind an account, that’s KYC’s job, done back when the account was opened. VoP asks something more specific: is that someone actually who the payer thinks it is. It ties the IBAN to an expected identity, in real time, on every single transfer.
For an account-to-account (A2A) payment inside SEPA, that means the destination side is already covered. We don’t have to invent anything there. VoP works because it’s a live query between two regulated PSPs inside the same scheme, and that root of trust between PSPs already exists. That’s precisely why verifying a destination has become routine rather than a research problem.
Which brings us to the part that isn’t routine yet.
Consent and Authorization: What Agentic Payments Still Lack
VoP tells you who you’re paying. It says nothing about who ordered the payment or with what authority. In classic SEPA flows, consent was never a separate question, because the initiator was always a human, authenticated by their bank through SCA under PSD2. Authorization and identity were the same event.
An agent acting by delegation breaks that assumption, and current infrastructure has no answer for the question it raises: did this agent have the account holder’s consent to order this specific payment, and within what limits does its authorization hold?
There is no “VoP for agents” today.
To trust an agent-initiated payment, three things need to be provable.
- Proof of possession. The agent has to prove it holds the private key tied to that credential at the moment it signs the payment, so a stolen credential can’t simply be replayed by whoever grabbed it.
- Delegation and consent. The account holder, who is strongly verified, signs a credential stating that a given agent acts on their behalf. The strong identity lives in the person or company; the agent only inherits a slice of that authority, and only for what was actually consented to.
- Bounded authorization. The credential carries limits: a maximum amount, a daily cap, an expiry date. A payment of 2,000 euros gets rejected if the credential caps the agent at 500, even if that credential is perfectly authentic.
None of this is exotic cryptography. What’s missing is agreement on who issues it and how it plugs into a payment flow.
Giving AI Agents Identity: Verifiable Credentials for Delegated Authorization
A Verifiable Credential (VC) is a digitally signed digital credential that contains trusted claims about a person, organization, or device. It can be cryptographically verified without contacting the issuer, ensuring the information is authentic and hasn’t been altered.
The W3C VC Data Model standardizes exactly this, and it’s the same technology that already underpins the destination side of the equation. Only the claim changes: instead of “this IBAN belongs to this name,” it becomes “this agent acts for this account holder, within these limits.”
Mapped onto a real payment, the flow would look like this.
- The account holder has a strongly verified identity.
- They sign a delegation credential for their agent, with explicit limits attached.
- The agent, when it initiates a payment, presents that credential and proves it holds the matching key.
- Our system verifies the agent side: permission, limits, and validity.
- VoP verifies the destination side: IBAN against name.
- The payment executes only if both sides check out.
One more detail matters more here than it ever did with human identity: revocation. Agents are ephemeral. They get spun up, do their job, disappear, or get compromised. Short lived credentials combined with fast revocation aren’t a nice to have, they’re the whole safety mechanism.
The Institutional Gap, Not a Technical One
The cryptography behind Verifiable Credentials is mature. What’s missing is institutional, and it concentrates entirely on the agent side.
Who certifies the delegation, and from what root identity? On the destination side, that root of trust already exists: a federation of regulated PSPs inside SEPA. On the agent side, that root simply hasn’t been built yet.
There’s no mature standard for the “agent” link in the chain. eIDAS and the EU Digital Identity Wallet are designed for people and companies proving who they are, not for software proving it’s allowed to act on someone else’s behalf. The account holder’s identity problem is solved. The delegated agent’s identity problem is brand new territory.
Adoption and privacy cut both ways. Nobody demands agent credentials if almost nobody issues them yet, and a poorly designed credential scheme can leak a trail of everything an agent does. There are mitigations for that, but they add complexity, not less.
Where We’re Taking This at Devengo
We operate A2A (account to account) payments inside SEPA, so the destination side is already handled by VoP. Our focus now is the agent side, and we’re starting conservatively on purpose.
For corporate account holders, we already have a corporate exemption model to build from, something that wouldn’t apply the same way to individuals. From there, the idea is simple: an agent never gets free disposal of funds. It operates against strong limits set by the account holder and a whitelist of possible recipients. No open-ended spending, no arbitrary destinations, ever.
We’re already testing pieces of this hands-on, including a prototype of an agent paying over HTTP 402.
We’ll keep sharing what we learn as we build it, so stay tuned!
If you’re exploring agentic payments and want to learn how to integrate them into your products, get in touch with us.
