Supplier bank details: why checking once at onboarding isn't enough

Vendor fraud through bank changes happens when someone posing as a real supplier gets you to pay a new account. It usually starts months after onboarding, with a change request that most teams verify far less carefully than the original details.

Onboarding is a checkpoint everyone takes seriously. Banking details get collected, matched to the company and approved. Then the record sits there, and the next time those details change it often happens through an email and a quick edit in the ERP.

Why are bank changes riskier than onboarding?

A change request arrives with trust already attached. The supplier is real, the invoices are real, and the email looks like it came from the usual contact. That trust is exactly what an attacker borrows.

In the AFP's 2026 Payments Fraud and Control Survey, 76% of U.S. organizations reported attempted or actual payments fraud in 2025, and 74% were affected by business email compromise. The survey's key highlights say fraudsters "primarily impersonate vendors or executives to request changes to payment instructions." The FBI's 2025 Internet Crime Report counted 24,768 business email compromise complaints and about $3 billion in reported losses.

What should happen before a bank change is accepted?

Treat a bank change as a task with its own checks. In practice that comes down to four steps.

1. The request comes through the supplier's own account. Email is the channel a business email compromise attacker already controls.
2. The supplier gives both the old and the new account details. The GFOA recommends this, and an impostor is unlikely to know the old details.
3. Someone confirms the change with a contact already on file. GFOA's advice is blunt. "Do not call a new phone number to verify changes." The FBI gives the same advice.
4. A named person on your team approves it, and payments to the new account wait until they do.

In our system, a supplier can't simply edit their bank details. They submit a change request from their own account and type both the old and the new account. The form doesn't show the current one on purpose, so someone who gets into the login still has to know it. Until someone on the buyer's team confirms the change with the contact on file and approves it, payments keep going to the old account and nothing new syncs to the ERP. Every step, from the request to the approval, also lands in an activity log that can't be quietly edited afterwards. We built it that way because an email is easy to fake and a quick edit is easy to miss, so a bank change should never take effect on one person's word or through one channel.

Which checks can a system run, and which need a person?

The strongest automated check is a bank account verification service. It checks the new account against bank data before anyone approves the change, confirming that the account exists and is open and that the name on it matches the supplier. Many of these services also return a risk score. That catches the most common pattern, a new account that belongs to someone else, and the approver sees the result on the request instead of having to look it up.

A system is also good at the other mechanical checks. It can confirm the request came through the supplier's authenticated login, flag a bank change that follows a recent change to the contact email or address, and hold any payment run that includes a newly changed account. GFOA also warns about requests that change several fields at once, which is easy for software to spot and easy for a busy person to miss.

A person still has to make the call when something looks off. Software can flag a request as unusual, but only someone who picks up the phone can find out whether the supplier really switched banks last month.

Why isn't checking once at onboarding enough?

A one-time check proves the account was right on the day you approved it. It says nothing about the account in next Friday's payment run, because the record keeps changing after onboarding and every change is a new chance to redirect money.

Two habits close that gap. First, run every banking change through the same verification as onboarding. Second, recheck banking details on a schedule across your active suppliers, so a change made outside your process gets caught before it costs you.

What makes a change history hold up later?

When someone asks who approved a payment change, the answer has to come from the record itself. Each change should show who requested it, what it replaced, who verified it, who approved it and when. If that history can be edited after the fact, it won't settle much in an audit or a dispute.

This is how we built the supplier record in Clover. Sensitive changes like banking details can require your team's approval before they take effect, and every change records who made it, what it replaced and who reviewed it in a hash-linked audit log. Clover's API connectors work with a range of bank verification services, so the check runs automatically on each change request and its result sits on the request when your team reviews it.

Yearly recertification can go out to your whole supplier base at once, the same way a compliance campaign does. For the bigger picture of why this work needs its own home, read the work between you and your suppliers deserves its own system.

Frequently asked questions

What is vendor fraud? Vendor fraud is any scheme that uses a real or fake supplier to take money from a buyer, such as fake invoices, inflated billing or redirected payments. Bank change fraud, where someone poses as a real supplier and asks you to pay a new account, is the form this post covers.

How do you verify a vendor bank account change? Run the new account through a bank account verification service to confirm it's open and in the supplier's name. Then confirm the change with a contact already on file, using a phone number from your own records rather than one in the request, and have a named person approve it before any payment goes to the new account.

How often should you recheck supplier bank details? There is no fixed standard. A practical cadence is a yearly recheck for every active supplier, plus an immediate check whenever banking, contact or address details change.

See how Clover keeps supplier bank details verified. Book a demo