Vendor Bank-Account Change Fraud: Verifying Payment-Detail Change Requests
Here is the scam, in one sentence: an email arrives that appears to come from a subcontractor or supplier you already pay, saying their bank details have changed and asking you to send the next payment to a new account. There is no malware, no breach of your systems, no hacked password. The attacker simply asks — politely, professionally, on what looks like the vendor's letterhead — and accounts payable, trying to be helpful, updates the record and pays.
This is the most common and most expensive form of business email compromise, and construction is squarely in its sights. A general contractor pays the same subcontractors month after month against AIA pay applications and draw schedules; the rhythm is predictable, the dollar amounts are large, and the relationships often run by email. A single redirected progress payment can be six or seven figures, and once an ACH or wire lands in the fraudster's account, recovering it is difficult and frequently impossible. This post is about the one control that defeats the attack: verifying every payment-detail change request, properly, before a single dollar moves.
Business email compromise covers several schemes — fake invoices, executive-impersonation wire requests, payroll diversion — but the vendor bank-account change is the one that drains the most money. The reason is structural. A fake invoice has to survive matching against a PO and a receipt. An executive wire request is unusual enough that a careful AP clerk may pause. But a banking-detail change on a real, established vendor slots neatly into normal business: vendors genuinely do change banks, switch from check to ACH, or get acquired. The request is not anomalous. It is routine — which is exactly what makes it dangerous.
Roughly 0 in 5
Share of organizations that reported actual financial loss to payments fraud in a recent year (AFP Payments Fraud and Control Survey)
The attacker is not breaking your technology. They are exploiting a process gap — the absence of a hard, mandatory verification step between 'a change was requested' and 'the change was made.' Close that gap and the attack fails regardless of how convincing the email is.
The attack is methodical and patient. Understanding the sequence makes the warning signs obvious.
The typical anatomy of a bank-change fraud
- Reconnaissance — the attacker learns who your vendors are and who in AP pays them, often from a compromised email mailbox on either side, or from public project announcements and bid records
- Setup — they register a lookalike domain (swapping a letter, adding a word) or compromise the vendor's real email account so the message genuinely comes from the vendor's address
- The request — a professional email announces updated banking details, often citing a bank merger or a new treasury policy, and attaches a change form on convincing letterhead
- Pressure — the message is timed to a known draw or pay-application date and adds mild urgency so the new account is in place before the next payment
- The follow-through — the attacker may reply to questions in the same thread, supply a phone number that rings to them, and even produce a forged voided check or bank letter
- The payment — AP updates the vendor master and the next progress payment routes to the fraudulent account; the real vendor only notices when they ask where their money is
Note what is missing from that list: any technical compromise of your systems. The most dangerous version uses the vendor's real, compromised mailbox, so the email passes every authentication check and survives scrutiny of the sender address. You cannot rely on the email looking legitimate, because sometimes it genuinely is legitimate — sent from a real account that is no longer in the right hands.
Construction adds details that make the attack easier to land. Project teams are large and fluid — a draw can involve a PM, a project accountant, a controller, and a subcontractor's office staff, several of whom may not personally know one another. Email is the default channel, banking forms and voided checks circulate routinely as part of subcontractor onboarding, and the public nature of construction work means an attacker can often learn from bid results or project announcements exactly which subs are on which job. The fraudster does not have to guess; the relationships are advertised.
The hard rule that anchors everything else: a payment-detail change is never verified using any contact information contained in the request itself. Not the phone number in the email, not a number on the attached form, not a reply to the thread. All of it can be controlled by the attacker.
Verification is not a feeling that the request seems fine. It is a defined procedure that produces independent confirmation from the real vendor, performed the same way every time, by someone other than the person who received the request.
The core of the procedure is an outbound phone call to a number you already had on file for that vendor before the change request arrived — a number from the signed subcontract, the original vendor onboarding packet, or your master vendor record. Never a number from the email, the attached form, or anything in the request thread. Call that known number and speak to a known contact at the vendor: confirm that they did request the change, and have them read back the new account and routing numbers to you so you are matching their words against the request, not reading the request to them.
The direction matters. If you read the new numbers aloud and ask 'is this right?', a fraudster on the line just says yes. Make the vendor state the details independently. And if the vendor's known phone number has supposedly also changed, that is not a coincidence to work around — it is a red flag that the relationship may be compromised, and verification should escalate, not proceed.
Standardize how banking changes are requested. A proper change-request form, completed and signed by the vendor, with the old and new details and an authorized signatory, gives you a consistent artifact to verify against and to retain. The form does not replace the callback — a form is just paper and can be forged — but it disciplines the process and creates a clean audit record. Supporting documents such as a bank letter or voided check add weight but are likewise never sufficient on their own.
The callback confirms that the vendor requested the change. A second, separate check confirms that the new account actually belongs to that vendor. The account name should match the vendor's legal business name — not an individual, not a slightly different entity. A new account at a bank in a region where the vendor has no presence deserves a harder look. Some teams use bank-account validation services that confirm the account is open and that the name on it matches the expected business. None of this substitutes for the callback; it is a parallel layer, and the two together are far stronger than either alone.
Get AP insights in your inbox
A short monthly roundup of construction AP + accounting posts. No spam, ever.
No spam. Unsubscribe anytime.
No single person should be able to change a vendor's banking details unchecked. Separate the duties: the person who receives and records the request is not the person who performs the verification callback, and a second authorized person reviews and approves the change in the vendor master before it takes effect. Dual control means a fraudster has to defeat two independent people following a defined procedure, not one helpful clerk under time pressure. It also protects against the insider version of this fraud, where the change request originates inside your own organization.
Treat the first payment after any banking change as elevated risk. Some teams hold that first payment briefly, or send a small verifying amount first, so that even a verification miss surfaces before the full progress payment goes out.
A few specific actions defeat verification entirely. Train every person who touches AP to recognize them as non-negotiable.
Actions that must be off the table, every time
- Never confirm a change by replying to the request email — the reply may go straight to the attacker
- Never call a phone number found in the email, on the attached form, or anywhere in the request thread
- Never accept a voided check, bank letter, or signed form as sufficient proof on its own — documents are easily forged
- Never let urgency override the procedure — 'we need this before Friday's draw' is a pressure tactic, not a reason to skip verification
- Never allow one person to both receive the request and approve the change in the vendor master
- Never update the banking record first and verify afterward — verification is a precondition, not a follow-up
Verification is the hard gate, but recognizing the warning signs helps your team treat a request with appropriate suspicion before the callback even begins.
Patterns that should raise the alert level
- A banking change that arrives just before a scheduled draw or pay-application date
- A sender domain that is subtly off — an added word, a swapped or doubled letter, a different top-level domain
- Urgency or pressure language, or a request to keep the change quiet or handle it quickly
- A new account at a bank in a different region than the vendor operates, or an account name that does not match the vendor's legal name
- A change request accompanied by a new phone number or new contact, so every channel you might verify through has conveniently moved
- Slightly off tone, grammar, or formatting compared to that vendor's normal correspondence
These signals raise suspicion; they do not decide the outcome. A request with none of them still gets the full callback verification, because the most dangerous attacks — those sent from the vendor's genuinely compromised mailbox — show none of these signs at all.
A verification policy that depends on people remembering to follow it will eventually fail, on a busy week, under a tight draw deadline. The control has to be structural: a banking-detail change should be impossible to complete in your AP system until the verification step is recorded and a second approver has signed off. The change request, the form, the callback record, and the second approval all belong in the audit trail.
This is where the workflow tooling earns its place. A platform like Covinly can hold any vendor banking change as a controlled event that cannot take effect — and cannot reach a payment run — until verification and dual approval are logged, so 'we forgot to check' simply stops being a possible outcome. The fraud succeeds only when verification is optional. Make it mandatory and enforced, and the most expensive attack in accounts payable runs into a wall.
“We caught one because the procedure caught it, not because anyone was clever. The email looked perfect. But the policy says call the number from the signed subcontract, and when we did, the PM said he had never asked us to change anything. The procedure did the work.”
— AP Manager, mid-market general contractor
Vendor bank-account change fraud is the highest-loss form of business email compromise — and one of the most preventable, because it is defeated by a single discipline rather than by sophisticated technology. Verify every payment-detail change with an outbound call to a number you already had, have the vendor state the new details, require a signed change form, and enforce dual control. Never reply to the email, never call a number it provides, never let urgency win. Build that verification in as a hard gate that a banking change cannot bypass, and the scam fails no matter how convincing the email looks. This control pairs naturally with a broader business email compromise program covering fake invoices and executive-impersonation wires, but the bank-account change is the one to lock down first, because it is where the largest losses happen.
Written by
Alex Kim
Engineering Lead, AI
Engineering lead for Covinly's AI and ML systems. Previously built fraud detection at a B2B fintech. Writes about how AI actually reads invoices — the math, the edge cases, and why OCR alone isn't enough.
View all posts