{"id":6807,"date":"2026-08-18T09:42:13","date_gmt":"2026-08-18T09:42:13","guid":{"rendered":"https:\/\/www.devengo.com\/?p=6807"},"modified":"2026-08-18T09:56:52","modified_gmt":"2026-08-18T09:56:52","slug":"agent-identity-and-fraud-the-missing-piece-in-agentic-payments","status":"publish","type":"post","link":"https:\/\/www.devengo.com\/en\/blog\/agent-identity-and-fraud-the-missing-piece-in-agentic-payments\/","title":{"rendered":"Agent Identity and Fraud: The Missing Piece in Agentic Payments"},"content":{"rendered":"\n

A few weeks ago I wrote about what happens when an AI agent needs to pay<\/a>.<\/strong> 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?
<\/p>\n\n\n\n

\n\n\n\n

Two Different Questions, One Payment<\/h2>\n\n\n\n

<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Who is the money going to?<\/strong><\/h3>\n\n\n\n

That’s verifying the destination.<\/strong> It stops the fraud where a payment goes to the wrong place: <\/strong>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<\/strong>. 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.
<\/p>\n\n\n\n

Who is ordering this payment, and did they have permission?\u00a0<\/strong><\/h3>\n\n\n\n

That’s verifying the agent.<\/strong> 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.<\/p>\n\n\n\n

The key questions are: Is this software truly acting on behalf of the account holder<\/strong>? And is it operating within the limits<\/strong> and permissions<\/strong> they set?<\/p>\n\n\n\n

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<\/strong>. Knowing where the money is going and who is allowed to move it is what turns autonomous payments into trusted payments.<\/p>\n\n\n\n

\"agentic

<\/figcaption><\/figure>\n\n\n\n

Verification of Payee Already Solved the Destination<\/h2>\n\n\n\n

<\/p>\n\n\n\n

Since October 2025, the Instant Payments Regulation requires Verification of Payee (VoP)<\/strong><\/a> 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.<\/p>\n\n\n\n

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.<\/strong>

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.<\/p>\n\n\n\n

Which brings us to the part that isn’t routine yet.
<\/p>\n\n\n\n

Consent and Authorization: What Agentic Payments Still Lack
<\/h2>\n\n\n\n

<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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?<\/strong><\/p>\n\n\n\n

There is no “VoP for agents” today.\u00a0<\/p>\n\n\n\n

To trust an agent-initiated payment, three things need to be provable.<\/p>\n\n\n\n

    \n
  1. Proof of possession.<\/strong> 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.
    <\/li>\n\n\n\n
  2. Delegation and consent. <\/strong>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.
    <\/li>\n\n\n\n
  3. Bounded authorization.<\/strong> 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.<\/li>\n<\/ol>\n\n\n\n

    None of this is exotic cryptography. What’s missing is agreement on who issues it and how it plugs into a payment flow.<\/p>\n\n\n\n

    <\/p>\n\n\n\n

    Giving AI Agents Identity: Verifiable Credentials for Delegated Authorization<\/h2>\n\n\n\n

    <\/p>\n\n\n\n

    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.<\/p>\n\n\n\n

    The W3C VC Data Model<\/a> <\/strong>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.”<\/p>\n\n\n\n

    Mapped onto a real payment, the flow would look like this.<\/p>\n\n\n\n