Supplier Bank-Detail Change Verifier: Stop Payment-Redirect Fraud Before the Money Moves

The problem this kills

An email lands from a supplier you've paid for years. New letterhead, a polite note, a fresh bank letter attached: "Please update our account details for future payments." It looks real. The signature matches. So someone in AP updates the banking record, and the next invoice — a real invoice, for real goods — gets paid into a fraudster's account. By the time the actual supplier calls asking where their money is, it's gone.

This is business email compromise, and bank-detail changes are its favorite door. The attacker doesn't need to break into anything. They just need one busy person to trust the email in front of them and skip the one step that would have caught it: independently confirming the change with the supplier using a number you already had on file — not the number in the email asking for the change.

The fix isn't a lecture about being careful. It's a workflow that makes the careful path the only path: no banking field changes until someone has called the supplier back on a known number and a second person has signed off. You do not need to be a developer to build that workflow.

What you'll build

A simple internal web tool for your AP and procurement controls team. When a supplier asks to change their bank details, you log the request — old details, new details, who asked, where it came from, and the supporting letter or bank confirmation as an attachment. The tool shows the old versus new side by side and clearly marks the source of the request (so nobody confuses "the supplier's email" with "the supplier"). It then forces two gates before anything is committed:

1. A verifier records an independent callback to the supplier's known, on-file contact number — never a number from the change request itself — confirming the change with a named person.
2. A second approver reviews the request, the evidence, and the callback record, and signs off.

The tool flags high-risk changes (anything that also changes the remit-to country or currency), requires attachment evidence, and blocks a second pending change for the same supplier so the same request can't be worked twice. Only after both gates pass are the new bank details committed, the change written to a permanent log, a confirmation emailed, and a clean CSV export produced in the exact columns your ERP expects.

What's inside the Implementation Plan

The downloadable plan is a step-by-step file you paste into an AI coding agent. It opens by interviewing you about your business — your current bank-change process and who touches it, the ERP or accounting system you maintain supplier banking in, the real fields and naming you use (supplier IDs, account formats, IBAN/SWIFT/routing, currency and country), your typical and peak request volumes, exactly who is allowed to verify and who is allowed to give second approval, and your messy edge cases (intermediary banks, factoring companies, suppliers who only answer email). It reads a short spec back to you for a thumbs-up, then builds the tool around your answers instead of a generic template — so the data model, the risk flags, and the approval rules match how your shop actually runs.

From there it walks the agent through login, the supplier and known-contact data, the change-request intake with attachment upload, the old-vs-new comparison and source labeling, the independent-callback record, the dual-approval gate, the high-risk flags, the duplicate guard, the commit-and-log step, the confirmation email, and the ERP CSV export. Every step ends with a ready-to-copy prompt.

The governance it includes (this is the point)

This tool is governance from the ground up — that's the whole reason it exists:

• Login so only your team can open it.
• Row-level security so a user only ever sees their own organization's suppliers and requests.
• A complete audit trail: who logged the request, who made the callback (and to which known number), who gave second approval, and exactly when — all permanent.
• Two hard human-in-the-loop gates: no banking field is written until an independent callback to a known number is recorded AND a second approver signs off. The AI helps organize and check; people decide.
• A duplicate guard keyed on supplier ID + new account number, blocking a second pending change for the same supplier so nothing gets processed twice.
• A high-risk flag that loudly marks any change that also moves the remit-to country or currency, and a hard requirement for attached evidence.

Who it's for

AP and procurement controls owners who already know — or have learned the hard way — that a single spoofed email can redirect a real payment, and who want a repeatable, auditable way to make the safe process the only process.

You've got this — paste the first prompt and let the agent interview you.