Agentic Payments Need a Verified Payee Layer Before AI Can Move Money

The industry has spent the last eighteen months building trust infrastructure for AI agents that pay: mandates, agent identity, verifiable intent, cryptographic credentials. All of it authenticates the buyer’s side of the transaction. None of it verifies who gets paid. Until that layer exists, an AI agent can shop — but it cannot safely pay a supplier.

Agentic payments crossed from demo to production this year. In March 2026, Banco Santander and Mastercard completed what they described as Europe’s first live end-to-end payment executed by an AI agent on production infrastructure; Visa had already reported hundreds of agent-initiated transactions with partners by late 2025. Card networks, protocol consortia, and fintechs are now racing to standardise how an agent proves who it is and what it’s allowed to spend. What almost no one is standardising is the other half of the transaction: whether the account the agent is about to pay actually belongs to the business it thinks it’s paying. That gap is survivable in consumer checkout. In B2B payments — where the losses come from misdirected funds, not stolen cards — it is the difference between automation and acceleration of fraud.

Where we areThe year the agent got a wallet

For most of the AI cycle, agents could look but not touch: they browsed, compared, summarised, and then handed a human a link. That’s over. Visa’s Intelligent Commerce and Mastercard’s Agent Pay now run agent-initiated purchase flows in production pilots. Stripe built an Agentic Commerce Protocol with scoped payment tokens so an agent can check out without ever holding raw card credentials. Google assembled more than sixty organisations behind AP2, a protocol in which cryptographically signed “mandates” prove a human authorised the agent’s purchase. The IMF published a note in April 2026 mapping how agentic AI will reshape payment orchestration end to end, from initiation and routing through compliance checks and settlement.

The direction of travel is unambiguous: agents are moving from recommending payments to making them. And the moment an agent can make a payment, the industry’s oldest question returns in a new form — not can the money move, but should it.

The stackWhat everyone is building — and what it actually verifies

The remarkable thing about the 2025–2026 protocol race is how much agreement it contains. Five-plus competing standards, and they are all answering the same three questions.

Even the vocabulary gives it away. The category term the industry converged on in 2026 is Know Your Agent — a deliberate echo of KYC, and by April every major network had shipped a KYA primitive. KYA answers who the agent is and who it represents. It says nothing about who the agent is paying. The KYC analogy has a missing twin: the payments world has spent two decades building Know Your Customer and, more recently, Verification of Payee for humans — and the agentic stack has rebuilt the customer side while leaving the payee side out entirely.

The gapThe question the stack never asks

Walk through what the stack proves at the moment an agent releases a B2B payment. The agent is registered and credentialed (KYA). The human principal authorised the spend, within scope (mandates). The instruction wasn’t altered in flight (verifiable intent). Every signature checks out — and the money can still land in a fraudster’s account, because none of those proofs touch the destination.

This asymmetry isn’t an accident of engineering priorities — it reflects where the protocols came from. They were designed for consumer checkout, where the merchant is discovered through a marketplace and card rails carry chargeback protection. B2B supplier payments invert every one of those assumptions: the payee is a bank account on an invoice, the rails are push payments with little or no recourse, and the dominant fraud is not a stolen credential but a manipulated destination — an intercepted invoice, a spoofed supplier email, a bank-detail change request that looks exactly like the real thing.

Why it’s worse with agentsAutomation without verification is acceleration

Payment fraud already works by defeating the human approver — and it works at industrial scale. The FBI logged $2.77 billion in reported business email compromise losses in 2024 alone, and AFP’s 2026 survey found 76% of organisations were hit by payment fraud attempts or attacks. Vendor email compromise and authorised push payment fraud succeed by placing a legitimate-looking instruction in front of someone with the authority to pay it. Replace that human with an autonomous agent, and three things change — all for the worse:

• Speed. A human might sit on a suspicious change request overnight. An agent executes in seconds. If the destination is wrong, the money is gone before anyone looks.
• Scale. An agent processing a payment run touches hundreds of payees in one pass. A single poisoned vendor record propagates instantly instead of waiting for the next manual review.
• Absent intuition. The informal tells a seasoned AP clerk notices — odd phrasing, unusual timing, a supplier who “suddenly” banks offshore — don’t exist unless they’re encoded as checks. An agent doesn’t get a bad feeling. It gets data, or it gets nothing.

There are company-level red flags a bank match alone won’t catch, and a human is at least capable of stumbling onto them. An agent will not — unless verification is a tool it holds and a step it cannot skip. An agent that can schedule payments but cannot verify payees doesn’t reduce exposure; it industrialises it.

LiabilityWhen the agent pays wrong, you own it

The question every deployment plan should answer first: who eats the loss when an agent pays a fraudster? The direction of law is already clear. California’s AB 316, in force since 1 January 2026, bars anyone who “developed, modified, or used” an AI system from arguing that the AI autonomously caused the harm — the “the AI did it” defense is gone, and the deploying company answers as principal. It doesn’t create strict liability; causation and foreseeability defenses remain — and that’s exactly the point. When the question becomes was the loss foreseeable and did you exercise reasonable care, an agent that moved money with no payee verification and no audit trail is a hard position to defend, while logged, blocking payee checks are precisely the documented care a defense is built on.

Add the recourse problem: B2B supplier payments are push payments. There is no chargeback to invoke when an authorised transfer lands in a fraudster’s account, and recovery after settlement — especially cross-border — is rare and slow. On card rails, the network absorbs structured dispute risk. On B2B rails, the payer absorbs it. Which means the economics of the payee layer aren’t a compliance line item; they’re self-insurance against the one loss category automation multiplies.

PrecedentRegulation already decided this — for humans

Treat the payee layer as speculative and you run into an awkward fact: for human-initiated payments in Europe, it’s already law. Under the EU’s Instant Payments Regulation, Verification of Payee became mandatory for euro-area PSPs on 9 October 2025 — every SEPA credit transfer now gets a name-match check against the account before the payer confirms, precisely because misdirected and manipulated payments had become intolerable at instant-payment speed. The UK reached the same conclusion earlier with Confirmation of Payee. The regulatory logic was: faster payments require payee verification in the flow.

Agentic payments are that same logic at higher velocity, and an agent doesn’t get an exemption because it’s software. If anything the bar is higher: a human payer sees the VoP result and decides; an autonomous agent must consume it — and go beyond it, because the name-match schemes regulation mandates stop at the account layer, while the frauds that defeat agents are increasingly entity-level. The direction of travel is one-way. The only open question is whether payment agents ship with the payee layer built in, or retrofit it after the losses.

The missing layerWhat a verified payee layer looks like

The payee side needs the same properties the payer side already has: machine-readable, cryptographically attributable, sub-second, and auditable. Agents don’t open registry portals or call banks; they call tools and consume structured answers. A verified payee layer, built for agents, answers three questions in sequence — each one deeper than the last:

The third layer is what separates a verified payee layer from a name-match API. Verification of Payee schemes confirm that a name matches an account number — necessary, and mandated across Europe for good reason — but a match against a fraudulent or hollow company is still a match. Ownership and entity verification is what tells the agent it’s paying a real business, not a well-named shell.

IntegrationHow it plugs into the stack that exists today

The delivery mechanism matters as much as the data. The reason MCP is the right vehicle for the payee layer is the same reason the rest of the stack is converging on open protocols: the agent discovers the tools, decides when to call them, and consumes the result inside its own decision loop — no bespoke integration per provider, no portal a human was supposed to open. MonitorPay’s MCP server for bank account verification makes the payee check a native capability of whatever agent framework a team already runs, and because MCP is model-agnostic, the verification layer survives a change of AI provider.

In practice, the layers compose cleanly. A mandate authorises the spend; agent identity makes the agent accountable; verifiable intent protects the instruction; and the payee layer clears the destination. A finance copilot assembling a payment run calls the payee checks on every line before anything is scheduled; an onboarding agent runs the entity check the moment a supplier submits details; a treasury agent re-verifies on any bank-detail change — the single highest-risk workflow in accounts payable, and the one that should never execute unverified.

ObjectionsTwo pushbacks, answered

“Won’t AP2 or the card networks just add payee verification in v2?”

Unlikely soon, and not by accident. The consumer-checkout protocols were built for a world where the merchant is discovered through a marketplace, onboarded by an acquirer, and disciplined by chargebacks — merchant trust is someone else’s solved problem. B2B payee verification is a different data problem entirely: bank-account validity and name-matching across dozens of domestic schemes, plus registry-sourced entity and ownership data across hundreds of jurisdictions. That’s not a field you add to a mandate schema; it’s an infrastructure layer with its own sources. The realistic architecture is composition — mandates and agent identity from the protocols, the payee layer from verification infrastructure — the same way the stack already composes today.

“Isn’t VoP already the payee layer?”

It’s the first third of one. VoP and CoP confirm that a name matches an account number — necessary, regulated, and geographically bounded to the schemes that run them. They don’t confirm who owns the account, and they say nothing about the company behind it: a match against a freshly incorporated shell with a plausible name is still a match. A payee layer fit for autonomous payments is three checks deep — account and name, then ownership, then the entity — and global, because agents don’t stop paying at the SEPA border.

In practiceWhat to build before your agents move money

For teams deploying payment agents — finance functions automating AP, or platforms shipping agentic payment products — the pre-launch checklist is short and unforgiving:

1. Scope the mandate. Spending limits, permitted counterparties, expiry. No agent gets open-ended authority over the corporate account.
2. Make payee verification a blocking step. Account, name, ownership, entity — verified before scheduling, not sampled after settlement. Failures quarantine the payment; they don’t warn and proceed.
3. Re-verify on every change. A bank-detail change, an ownership change, a status change — each one resets trust to zero and triggers the full check again, automatically.
4. Monitor continuously. Verified once is not verified forever. Webhook alerts on account or entity changes keep yesterday’s verification from silently going stale.
5. Log everything. Every check, result, and reason code, tied to the payment it gated — the audit trail that regulators, auditors, and your own post-incident review will ask for.

One design decision deserves explicit policy rather than improvisation: what the agent does with ambiguity. Verification isn’t binary — a check can return match, no_match, or cannot_verify, with a confidence score attached. A sane default policy is three-tiered: clean match at high confidence passes; a close match or a cannot_verify holds for human review with the reason code attached; a no-match or any entity-level red flag escalates and freezes the payee record until resolved out-of-band. Set the thresholds deliberately, tune them on your own payment population, and never let “cannot verify” silently default to “pay anyway.”

The bottom lineThe stack completes, or the losses scale

Every payments era has ended the same argument the same way: velocity wins, and the controls move into the flow. Cards got 3-D Secure. Faster payments got Confirmation of Payee. Instant payments in Europe got mandatory Verification of Payee. Agentic payments will get a verified payee layer — the only question is whether the industry builds it before or after the first wave of agent-executed misdirected-payment losses makes the case in headlines.

The payer side of the agentic stack is nearly done, and it is genuinely good work. But a transaction has two ends, and today only one of them is verifiable. Before AI can move money at B2B scale, the other end needs its layer: the account, the owner, and the entity — verified, in the loop, on every payment. That layer is not a feature of some future protocol revision. It exists, it speaks MCP, and agents can call it today.