Stopping vendor bank-change fraud before the payment run

One of the most damaging frauds a finance team faces is an email, apparently from a real vendor, asking to update bank details. AI can examine every change request and payment batch for warning signs and make sure the verification steps actually happen before funds are released.

01the problem and who owns it

Business email compromise schemes often start with a compromised vendor mailbox or a lookalike domain. The fraudster sends a convincing request to change remittance details, often timed just before a large invoice is due. AP, under deadline, updates the vendor record, and the next payment goes to the fraudster.

The controller owns the control environment, but the control usually rests on a busy clerk remembering to call the vendor, using a phone number that is not taken from the suspicious email. When that habit slips once, the loss can be significant and difficult to recover.

02what the AI does, step by step

1. Intercept change requestsAny message or form asking to change bank details, remittance address, or payment method is detected and routed into a controlled workflow, regardless of which mailbox it lands in. No one edits banking fields directly in the vendor master.
2. Analyze the requestThe system checks sender domain against the domain on file, flags lookalike spellings, compares reply-to addresses, examines email headers for authentication failures, and notes urgency language and timing near a large pending payment.
3. Compare against historyIt checks how long the vendor has used the current account, whether the new bank is in a different country or institution type, and whether other vendors recently requested changes to the same destination account.
4. Require independent verificationA task is created to call the vendor using contact details from the original onboarding records, not from the request. The person records who confirmed, when, and how before the change can proceed.
5. Apply dual approvalThe banking change is entered by one person and approved by another with vendor master authority. A cooling-off period can hold first payments to new details for review.
6. Screen the payment batchBefore each payment run, payments are checked for recently changed bank details, unusual amounts for the vendor, duplicate invoices, and first-time payees, and flagged lines are held for the payment approver.

03systems it connects to

• Email security. Microsoft 365 or Google Workspace, with header and authentication results available for analysis.
• ERP vendor master. NetSuite, Sage Intacct, QuickBooks, or similar, with change logging enabled.
• Payment platform. The bank portal or AP payments tool used to release funds.
• Task tracking. A simple verification log or ticketing tool that auditors can review.

04human checkpoints

• Callback confirmed by a person. No bank change becomes active without a recorded independent verification call.
• Two people for every change. Entry and approval of vendor banking changes are done by different people, enforced by system permissions.
• Held payments. The payment approver decides on every flagged payment before the run is released.

05what to measure

• Verification completion. Share of bank changes with a recorded callback before activation. The target is all of them.
• Flag volume and outcomes. Requests and payments flagged, and how many turned out to be fraudulent, mistaken, or legitimate.
• Time to verify. How long legitimate changes take, so the control does not become a reason vendors go unpaid.
• Attempted fraud caught. Count and value of fraudulent attempts stopped, recorded as they occur.

06risks and guardrails

• Overreliance on detection. Signals miss sophisticated attacks from a genuinely compromised vendor mailbox. The callback and dual approval are the real control; detection decides how carefully to look.
• Control fatigue. Too many false alarms train people to click through. Tune thresholds and keep the verification step quick for legitimate vendors.
• Sensitive data. Bank details and email content are highly sensitive. Keep the workflow in a restricted environment and log every access.

07build vs buy

AP platforms and payment providers increasingly include bank account validation and fraud screening, and email security products catch many lookalike domains. Turning those on is the first step.

A custom control layer is useful when payments flow through several systems, when the ERP does not enforce dual approval on vendor master changes, or when you want detection, verification, and payment holds tied together in one auditable workflow.

08related playbooks

Browse every finance and accounting playbook or the full library.