Agentic Vendor Payment Fraud Detection: Catching a Banking-Detail Change Before the Wire Goes Out
written by Cooter:Labs
published on August 19, 2026
Introduction
Business email compromise fraud aimed at accounts payable follows a predictable script: someone impersonates a vendor, a company executive, or even the bank itself, and asks for a vendor's payment banking details to be updated — new account number, new routing number, sometimes a plausible reason like 'we're switching banks' or 'our old account is under audit.' If the request looks legitimate enough and reaches someone with the authority to update vendor master data, the next invoice that vendor sends gets paid to an account the real vendor never controlled. The invoice is real, the PO matches, the three-way match clears — the fraud isn't in the transaction, it's in the payment destination underneath it. Agentic workflows can't replace the judgment call of whether a request is legitimate, but they can make sure that judgment call actually gets made, every time, instead of getting skipped because someone was busy and the email looked fine.
Most AP fraud controls are built to catch problems in the transaction: does the invoice match the PO, does the PO match the receipt, is the vendor a duplicate or a shell entity. Banking-detail change fraud doesn't touch any of that. The vendor is a real, long-standing, already-approved vendor in the master file. The invoice amount is normal for that relationship. The only thing that changed is a field that most ERPs treat as routine vendor-master maintenance — updated the same way you'd update a mailing address — rather than as a payment-integrity event that deserves its own scrutiny. An agent watching specifically for that field change, and treating it differently from every other vendor-record edit, closes a gap that transaction-level matching was never designed to cover.
The first step is separating banking-detail changes from the rest of vendor master maintenance in how the system reacts to them, not just in how they're logged. Most ERPs record a change to a vendor's bank account or routing number the same way they record a change to a phone number or a contact name — an audit-log entry, no different workflow. An agent sitting on top of vendor master changes should treat a banking-field edit as a distinct trigger: hold the change in a pending state rather than applying it immediately, and kick off a verification step before it becomes live for the next payment run. This alone changes the economics of the fraud — instead of a single approval click silently updating where money goes, the change has to survive an independent check before it takes effect.
The core control is callback verification: confirming the change through a phone number or contact already on file for the vendor before this request arrived — never a number, email address, or portal link supplied in the change request itself, since that's exactly the channel a fraudster controls. An agent can automate the mechanical parts of this — pull the verified contact number from the vendor's existing record, generate a verification task with the old and new banking details side by side, and route it to AP for someone to actually make the call — but it should not be able to complete the verification on its own. Confirming a human at the vendor's known number said yes is a control that has to end in a person doing the confirming, and the agent's job is making sure that step never gets silently skipped because it's inconvenient this week.
While the callback verification is pending, an agent can run cheap checks that narrow down how urgently a human needs to look at this one: does the new routing number resolve to a real, active bank; does the new account number match a pattern seen in other recent change requests across unrelated vendors (a strong indicator the same fraud ring is targeting multiple vendors on the same company's books); does the request's timing correlate with an unusually large invoice recently submitted or expected from that vendor, which is a common setup where fraud is timed to a known payment. None of these checks alone proves fraud — a routing number can be real and a large invoice can be legitimate — but a request that trips two or three of them should get escalated ahead of the routine verification queue instead of waiting its turn.
A pending banking-detail change and a payment run shouldn't be allowed to pass each other unnoticed. If a payment to that vendor is already scheduled while a banking change sits in verification, an agent should hold that payment out of the run rather than letting it execute against whichever account happens to be on file at run time — old or new. This is a narrow, mechanical rule, but it closes the specific timing gap fraud attempts are often built around: a change submitted right before a known payment date, betting that the payment process won't notice the change is still unverified.
Looking Ahead: Challenges and Innovations
Callback verification only works if the 'known good' contact is actually known good
The whole control depends on the phone number or contact used for verification being one that was captured through a trustworthy process in the first place — during vendor onboarding, from a signed contract, from a previous verified interaction — not one that itself arrived by email at some point and was never checked. If a fraudster compromised the vendor record earlier and changed the on-file contact information before ever requesting a banking change, callback verification calls a number the fraudster controls and confirms nothing. This means the control's real foundation is vendor onboarding and contact-data integrity, not the banking-change check itself; an agent flagging banking changes is only as good as the contact data it calls back to.
AP teams have real pressure to move fast, and holds create friction that gets pushback
Holding a payment or delaying a banking-detail change for callback verification is, from the vendor's side, a delay in getting paid — and vendors call, and internal stakeholders who want that vendor relationship kept smooth push back on the friction. An agent that holds every single change with equal rigor regardless of amount or vendor history invites exactly the kind of workaround pressure that erodes a control over time — someone eventually gets authority to override the hold for 'trusted' vendors, and that override path becomes the new gap. Calibrating hold severity to transaction size and vendor risk profile, while never letting the highest-risk cases get overridden without a documented reason, is an ongoing tension, not a one-time setting.
This control only protects money leaving through AP — it doesn't cover every fraud vector
Vendor banking-change verification protects one specific attack path: legitimate invoices being redirected to a fraudulent account through a compromised or spoofed change request. It does nothing for a completely fabricated invoice from a vendor that never existed, or for fraud that happens upstream in procurement before an invoice is ever cut. Treating this control as comprehensive AP fraud protection rather than one layer addressing one specific, well-documented attack pattern is a mistake — it needs to sit alongside three-way matching, master-data governance, and segregation-of-duties monitoring, not replace any of them.
The metaverse
As more AP workflows move toward continuous, agent-monitored processing, banking-detail change verification is likely to converge with the broader master-data governance layer rather than stay a separate bolt-on check — the same agent watching for duplicate or conflicting vendor records is well positioned to also own payment-destination integrity, since both are ultimately about trusting what's in the vendor master before money moves against it. The open question for most mid-market ERPs isn't whether this kind of check is technically feasible — the logic is straightforward — it's whether the organization has already captured trustworthy vendor contact data to verify against, which is a data-governance problem years older than any agentic workflow.
Conclusion
Banking-detail change fraud works because it targets a gap between systems: a change that looks like routine vendor-master maintenance to the ERP, verified against a payment control system that's checking invoices, POs, and receipts for something else entirely. What an agent adds isn't a new idea — callback verification on banking changes has been standard fraud-prevention advice for years — it's consistency: making sure the check happens on every single change, every time, instead of depending on whoever processes the request that day to remember to make the call. The control still ends with a human confirming a vendor's identity through a channel the fraudster doesn't control, and it still needs trustworthy contact data to call back to. The agent's job is closing the gap where that step quietly gets skipped.
Share this post:
Curious what this means for your business?
Get a personalized ROI estimate, or book a free discovery workshop with our team.