Agentic payments are only as safe as the supplier record underneath them

Three announcements landed inside five days, all of them about agentic payments — AI agents that choose a supplier and move the money. Sunrate and Mastercard published a framework paper on the category on 23 July. Visa and Lianlian ran what they called Greater China’s first live agentic business-to-business payment on 24 July. Lianlian and UnionPay International announced a procurement partnership on 27 July. Not one of them is a story about a better model. Read the verb lists and they’re all stories about a record.

TL;DR: An agentic payment system doesn’t decide who gets paid. Your vendor master does — the agent just executes against it, without a person reading the remit-to line. That record is already the most attacked object in enterprise finance: AFP’s 2026 survey found 74% of organizations were hit by business email compromise in 2025, which in accounts payable almost always means a forged bank-detail change. Automating the payment doesn’t create the exposure. It removes the last human who might have caught it.

What actually shipped

Worth being precise about, because the details are the argument.

Sunrate and Mastercard released Beyond Automation: Defining Agentic Global Payments at the World Artificial Intelligence Conference on 23 July. It maps 16 pain points across the B2B payment lifecycle and 13 agent use cases — supplier onboarding, payables and receivables, virtual cards, payment routing, FX management, compliance screening, fraud detection, reconciliation. Anouska Ladds, Mastercard’s EVP for Commercial and New Payment Flows in Asia Pacific, put a sharper line on it than most vendor copy manages: “Agentic commerce is changing how businesses make and execute payment decisions, but speed without accountability creates new categories of risk.”

The next day Visa and Lianlian executed a live one. Lianlian’s LoopXPay agent, running on Visa’s Trusted Agent Protocol and Agentic Directory, identified a purchasing requirement, recommended suitable suppliers, compared the options, placed the order and executed the payment — inside pre-defined spending controls and approval parameters. Then on 27 July, Lianlian and UnionPay International announced they’d signed a cooperation agreement to put agents through global procurement end to end: supplier matching, product selection, payment execution, with the user keeping final approval.

Now look at what those agents are actually doing. Recommended suitable suppliers. Supplier matching. Payment routing. Compliance screening. Every one of those is a query against a table you already own, answered by whatever that table happens to say. The model isn’t sourcing your vendors. It’s reading your vendor master and acting on it.

The record the agent reads

Here’s the mapping, step by step, for a procurement flow like the ones announced this month.

What the agent does	The record it reads	Who owns that record in most companies	What goes wrong
Matches a need to a supplier	Vendor master + category codes	AP or procurement ops, as a queue	Duplicate rows for one supplier; the agent picks the stale one
Checks the supplier is approved	Vendor status flag	Set at onboarding, rarely revisited	Terminated suppliers still flagged active
Screens for sanctions/compliance	Legal entity name, tax ID, country	Whoever created the record	Name mismatch against the screening list; the check passes on a wrong string
Routes the payment	Remit-to bank details	Nobody — a form-driven field update	Fraudulent or superseded bank details, silently applied
Reconciles against the PO	PO, receipt, invoice lines	Split across three systems	Unit-of-measure and terms mismatch resolved by whoever’s closest
Books the spend	GL and cost-center mapping	Finance, decided years ago	Miscoded spend nobody catches until close

Six steps, six records, and only one of them — the GL mapping — has a clear owner in a typical mid-size company. The rest are maintained the way most reference data is maintained: reactively, by whoever caught the error, through a form.

Humans absorb all of that. A senior AP clerk knows that “Northline Industrial LLC” and “Northline Ind. L.L.C.” are the same company, that the second one has the bank account from before they were acquired, and that anything from that supplier over $40K should really go past the plant manager first. None of that is in the system. It’s in her.

The most attacked object in enterprise finance

The supplier record isn’t just messy. It’s targeted.

AFP’s 2026 Payments Fraud and Control Survey — the 22nd edition, drawing on 465 corporate finance practitioners and covering activity in 2025 — found that 76% of organizations experienced attempted or actual payments fraud, and that 74% were affected by business email compromise. In accounts payable, BEC is not an abstract email-security category. It is one specific move: a message that appears to come from a real supplier, asking to update where their money goes. The documentation looks right. The request follows your process. The field gets changed.

The same survey found only 17% of organizations use AI to combat payments fraud. Set those two numbers next to each other and the asymmetry is the whole story. The industry is racing to put agents on the spending side of the transaction while the control side is still overwhelmingly manual. We are automating the release of funds faster than we are automating the verification of who receives them.

There’s a second-order effect nobody has priced yet. Today, a forged bank-change has to survive one human somewhere in the chain who might squint at it. That human is a weak control — the AFP numbers show how weak. But they are a control, and the fraud economics assume they exist. An agentic flow that resolves a supplier and releases payment without a person reading the remit-to line removes the last check, and it does so for every transaction at once rather than one at a time.

Approval is not verification

The reassurance in all three announcements is the same: the agent runs within pre-defined spending controls, the user retains final approval on commercial decisions. That’s a genuine control, and it’s worth having. It bounds the amount.

It does not bound the payee. An approver looking at a queue sees a supplier name, an amount, a PO reference. They do not see the bank account. They have no independent basis to know whether that remit-to was updated last year by procurement or last Tuesday by someone with a convincing email domain. Approving a payment is not the same act as verifying a payee, and treating the first as coverage for the second is how BEC has worked for a decade. A control you can’t actually exercise is a control on paper only — and the volume an agent generates makes cursory approval more likely, not less.

The detail that decides this is unglamorous. In most ERP configurations a supplier’s banking data is a mutable field on the vendor record, not an effective-dated child object with its own change history. Update it and the previous value is simply gone. So when an agent resolves the supplier and reads the remit-to, there is no version to compare against, no “this changed 11 days ago” signal to raise, and no clean way to answer where was this supplier being paid last quarter without going to the database logs. The agent isn’t being reckless. It’s reading the only value the schema keeps.

What the working version looks like

The sequence isn’t complicated, it’s just unfashionable.

Give the vendor master a named owner — an actual person accountable for what a supplier record asserts, not a shared queue that processes change requests. Make a banking change a distinct, out-of-band verified event rather than a field update: the channel that requests the change can never be the channel that confirms it, and the confirmation goes to a contact already on file, not one supplied in the request. Make the record effective-dated so there is one authoritative answer to where a supplier gets paid today and a history of every prior answer. Then reconcile the duplicates, because an agent has no way to know that two rows are one company unless someone has told the system so.

Only after that does the agent become interesting. Point it at a vendor master with a clear owner, verified banking, and deduplicated entities, and the announcements from this month describe something genuinely useful — the routine spend runs itself and the exceptions get a person. Point it at the vendor master most companies actually have and you’ve built a faster path from a forged email to a cleared wire.

Every one of these launches is being read as a payments story. It isn’t. It’s a master-data story wearing a payments announcement, and the part being automated was never the hard part. Deciding who a supplier is, and who gets to say so, was always the job.