What Is Vendor Bank Change Verification?
Vendor bank change verification is the process of confirming that a supplier’s request to replace the bank account used for payments is legitimate before money is sent to the new destination. It is more than checking whether the email address, invoice, or portal account looks familiar. The business must verify the identity of the requester, the authority of that person to change payment instructions, the supplier’s relationship to the account, and the authenticity of the new banking information through a trusted channel. A strong procedure combines independent contact, dual approval, account matching, transaction monitoring, and a temporary hold on payment changes. Verification matters because business email compromise can turn an apparently valid internal request into a convincing payment diversion. The core rule is simple: never use contact details contained only in the change request to verify that request. As of 29 September 2026, organizations should treat every payment-detail change as a separate transaction risk, especially when it involves a new account, a new country, urgent instructions, confidentiality requests, or an altered payment method.
Also worth reading: What Are the Best Third-Party Risk Controls for Business Utilities and Vendor Operations? · How Do You Build a Vendor Automation Business Case in 2026? · How Should Organizations Govern Virtual Utility Vendors and Vendor Operations?
The danger is not limited to large companies. Attackers often target vendors, payroll teams, and accounts-payable employees because those roles can move money or alter payment records. A fraudulent request may imitate a supplier’s branding, reference a real invoice, quote real project details, and arrive from a genuine but compromised mailbox. The fact that a request passes ordinary email authentication does not prove that the sender authorized the bank change. Even a link or token delivered through multi-factor authentication can create false confidence if the underlying mailbox or session was already compromised. Verification therefore needs controls that operate outside the untrusted request itself. For facilities and workplace teams managing recurring utility, maintenance, cleaning, security, and other vendor payments, the control should be integrated into vendor operations rather than left to memory or a one-time phone call.
Why a Legitimate Bank Change Can Still Be Fraudulent
Business email compromise succeeds partly because genuine information can be copied. A scammer may know the vendor’s legal name, invoice number, account manager, payment schedule, and approximate invoice value. The request may say that the supplier changed banks because of an acquisition, internal reorganization, regional banking issue, or “enhanced fraud protection.” Such explanations are plausible and do not by themselves indicate fraud. The organization must judge the request by its verification evidence and behavioral anomalies, not by whether its story sounds convincing. A request from an established vendor should still trigger the same verification workflow as a new vendor onboarding request. Repeated prior payments to the old account do not authenticate the new account; they only show that the relationship existed before the suspicious event.
Attackers also exploit time pressure. They may ask the accounts-payable employee to process the change “before today’s payment run,” claim that the old account will be closed that afternoon, or state that delays will trigger penalties. Urgency is not proof of misconduct, but it reduces the time available for independent checks and should increase the level of scrutiny. Similar warning signs include a new payment address using free email, a mismatch between the account name and supplier’s legal entity, a request to pay a personal account, a changed beneficiary country without a documented project reason, and a request not to call because the vendor is “in a meeting.” Research and reporting have documented cases in which compromised business email was used to authorize fraudulent transfers, including a reported loss of $913,839 after scammers hijacked a city email account.
The financial institution may detect unusual activity, but it cannot be expected to know whether the business intentionally authorized a supplier’s account change. Similarly, a supplier’s bank may verify that its customer supplied correct account information while remaining unable to determine whether the person supplying it was tricked. Prevention belongs primarily in the customer’s process. Banks and payment providers are useful controls after a request reaches them, not substitutes for verifying the request at the originating business.
A Practical Verification Procedure for Accounts-Payable Teams
Begin by recording the request in the approved vendor or invoice system and freeze the next payment to the affected vendor. Do not delete the original message, alter the pending invoice manually, or allow the requester to bypass the normal queue. The employee receiving the request should notify a second authorized person and preserve relevant email headers, attachments, invoice copies, and account-change history. A temporary payment hold of one to five business days is usually easier to manage than attempting to recover money after an irreversible wire or electronic transfer. The hold should be recorded with a reason, owner, review date, and approval decision so that it becomes an auditable control rather than an informal delay.
Next, identify a trusted contact for the supplier using records that predate the change request. That means the vendor master file, a previous invoice, a signed contract, the company’s official website obtained independently, or a known number already stored in the system. Call a main switchboard or known facility-management contact and ask for the accounts-receivable or treasury team. Do not call a number supplied in the suspicious message, even if it appears to be an official vendor number. Ask the verified contact to confirm the change, the new account holder’s legal name, the bank location, the account identifier, the effective date, and the person authorized to make the request. Some organizations require the supplier to send a letter on company letterhead or a digitally signed document, but those documents should be validated against known details and should not become the sole control.
A second person should independently compare the new beneficiary information with the vendor contract, tax records, purchase order, and supplier profile. At minimum, check the legal entity name, payment currency, payment method, country, remittance address, and any intermediary bank instructions. Confirm that the vendor’s master-data record was not silently changed by the same compromised account that requested the change. If the vendor uses a payment platform, confirm whether that platform requires its own beneficiary verification and whether the platform is entitled to issue instructions directly. Once all evidence is consistent, approve the change through the system, require dual authorization, and notify the supplier through a verified channel.
What Makes Verification Stronger Than a Phone Call?
A phone call is useful when it reaches a trusted person, but it is not automatically a complete control. Voice calls can be spoofed, compromised accounts can receive calls, and a caller may rely on information supplied by the attacker. A stronger procedure uses at least two independent factors: a trusted communication channel and a record or authorization method controlled by the supplier. Examples include calling a pre-existing number and receiving confirmation from a known finance contact, or verifying an account through a supplier portal accessed with a new authentication session. Some teams require a callback after a defined waiting period, allowing time for a newly created or compromised mailbox to be recognized. Others use out-of-band confirmation by SMS or a voice call to a number on file, while recognizing that MFA does not protect against every form of session or mailbox compromise.
The organization should choose controls according to risk rather than use the same lightweight process for a $50 recurring invoice and a $500,000 construction disbursement. A low-value payment still deserves basic verification, but higher-risk changes should receive stronger review, such as direct treasury contact, two internal approvers, account-title matching, and a 24-hour hold. A request involving a new vendor, new country, changed currency, or unusual payment rail should receive enhanced due diligence. Payment thresholds should be set before the request arrives; setting them during an urgent investigation creates pressure and inconsistency. A practical starting point is immediate independent verification for every bank change, enhanced review above a defined amount, and senior approval for exceptions, with the exact figures determined by the business’s exposure and margins.
| Feature | Basic email or portal request | Strong vendor bank-change control |
|---|---|---|
| Requester identity | Assumed from the login or email address | Confirmed through a previously trusted channel |
| Contact channel | Number or link supplied in the request | Number, portal, or contact already on file |
| Internal approval | One employee may update the record | Two authorized reviewers approve the change |
| Payment timing | Immediate if the request appears urgent | Temporary hold, commonly 1–5 business days |
| Account matching | Beneficiary name may not be checked | Legal entity, currency, location, and payment method compared |
| Audit evidence | Original email retained | Email, callback, approvals, documents, and effective date recorded |
| Ongoing control | No post-change review | First payment and subsequent transactions monitored |
| Suitable use | Low-risk, tightly controlled workflow | New vendors, large payments, or unusual changes |
Organizations can use manual procedures, vendor-master controls, payment platforms, bank controls, and managed fraud services. A manual process is inexpensive and appropriate for a small company with a limited vendor base, provided the employee follows the independent-callback and dual-approval rules. It becomes weak when one person receives the request, contacts the vendor, updates the record, and releases payment. Vendor-master software can provide role-based access, approval thresholds, immutable change logs, and duplicate-account checks. Those features help only if permissions are configured correctly and the requester cannot approve their own change. B2B virtual-utility and vendor-operations platforms can also centralize invoices, approvals, and vendor records, but software should not be treated as proof of identity merely because it contains a workflow.
Payment platforms such as supplier portals or embedded accounts can reduce the need to expose bank details in email. They may verify the supplier as a business, authenticate users, and restrict destinations to accounts that the supplier has independently registered. That can be safer than sending a wire instruction, but it introduces platform and account-takeover risks. A business should confirm whether the platform authenticates the legal entity or only an individual, whether users can add new beneficiaries, and whether transaction approval is separate from profile editing. Bank controls such as callback procedures, positive pay, payment holds, account monitoring, and restricted transfer destinations can provide another layer. They are not a replacement for vendor verification because a bank may have no visibility into the business relationship behind the payment.
Exceptions need a documented owner and expiry date. For example, a vendor involved in an emergency utility repair may justify a same-day response, but the emergency should not waive identity checks. The business can place the payment in a controlled escrow arrangement, pay through a verified procurement card or platform, or require a senior finance approval before release. If the vendor genuinely cannot complete a callback, consider a contractually authorized alternate method, such as an existing supplier portal with multifactor authentication or a payment to an account already on file. The relevant question is whether the business can prove that the beneficiary is the contracted supplier, not whether the exception is labeled “urgent.”
Common Mistakes and Weak Controls
The most common mistake is replying to the same email thread. If the thread was compromised, replying confirms that the compromised mailbox remains in control and may disclose additional information. Another error is relying on visual familiarity: an accurate logo, familiar signature, correct invoice number, and plausible banking reference can all be copied. Some teams accept a vendor’s PDF letter without calling a known contact, while others treat a new portal account as automatically trusted even though the portal may have been created in response to the fraud. Using only an email-based approval is also risky because the approver may be reading the attacker’s wording rather than seeing verified source data.
Technical controls need careful interpretation. Multi-factor authentication can protect a login, but it does not invalidate an email verification link; the user’s own authenticated session may still process the attacker’s request. A verification token sent through a GET request may be exposed in browser history, logs, referrer information, or copied links, depending on implementation. Organizations should avoid assuming that MFA eliminates vendor-change fraud. Secure web practices still matter, including TLS, secure session handling, phishing-resistant MFA where available, and monitoring for unexpected changes in vendor-master data. For a B2B operations platform, a useful design should display the requester, original account, proposed account, source domain, verification status, approvals, and any changed contact details in one review screen.
A further mistake is failing to monitor the first payment after approval. Fraudsters sometimes submit a plausible change, wait for the hold to expire, and then rely on teams to stop checking once the vendor record is marked “verified.” Compare the first payment with the confirmed invoice and contract, and alert the business when a vendor changes banks twice in a short period. Organizations should also review whether the old account, new account, requester, and device were associated with suspicious login events. A control that creates a clean audit trail but never triggers an alert is documentation, not active fraud prevention.
When Should a Business Act Immediately, and What Does It Cost?
Immediate escalation is warranted when a supplier asks for a bank change through an unexpected channel, when a senior executive is copied without a normal business reason, when a payment is requested to a personal or unrelated account, or when the requester asks for secrecy or a bypass of procurement policy. Act quickly but do not make the original requester the only person investigating. Preserve evidence, stop scheduled payments, alert finance leadership and information security, and contact the supplier through a trusted route. If a payment has already been sent, contact the bank and receiving institution immediately, request a recall or freeze where available, and report the incident through applicable legal, insurance, and law-enforcement channels. The bank’s recall options depend on the payment rail, timing, jurisdictions, and whether the funds have already been withdrawn; no recovery is guaranteed.
The cost of basic verification is primarily staff time. A short call and dual approval may take 10–30 minutes per change, while a high-risk review may take several hours. Manual controls can be inexpensive for a small business, but they are exposed to turnover, inconsistent execution, and human error. Vendor-master or AP-automation software may be priced per user, transaction, site, or enterprise contract, with small-business tools often beginning at tens or hundreds of dollars per month and enterprise deployments costing substantially more. The figures vary widely and should not be treated as market-wide quotes. Payment-platform, bank, and managed fraud services may add transaction fees, implementation costs, subscription fees, or premium support. Compare the total annual cost against the potential loss from one diverted payment, including operational disruption, investigation, legal fees, and reputational damage.
The right implementation is not necessarily the most expensive one. A business with 20 suppliers may be well served by a documented callback rule, a known-contact directory, two-person approval, and a five-business-day hold. A company paying thousands of suppliers across multiple countries may need centralized master data, role-based controls, automated anomaly alerts, bank integration, and formal incident response. Regardless of scale, the organization should test the process with a simulated change request and measure how long verification takes, whether employees use trusted contacts, how often exceptions occur, and whether every change has evidence. A control that adds 20 minutes to legitimate changes but prevents a $100,000 diversion may be economically rational; a cheaper system that takes nine days and encourages workarounds is not.
The Recommended Standard for September 2026
For 29 September 2026, the recommended standard is independent, dual-controlled verification of every vendor bank-account change. Freeze the affected payment, preserve the request, identify the vendor through a pre-existing trusted channel, and confirm the requester’s authority and the complete beneficiary record. Require two authorized internal approvers, record the evidence and effective date, and monitor the first payment. Apply stronger checks to new vendors, high-value payments, new countries, changed currencies, unusual intermediary instructions, and requests that bypass normal processes. MFA should be enabled, but it should be described as one layer rather than a guarantee. Email authentication, a valid portal login, or a document with a genuine company logo should likewise support, not replace, independent confirmation.
The practical standard also includes what happens when verification fails or cannot be completed. Do not release the payment merely because the supplier insists that the old account is closed. Keep the hold active, escalate to the vendor’s contract owner or finance leadership, and use a previously authorized payment method where possible. If a breach is suspected, preserve logs and contact the bank and security team without publicly accusing the vendor. After resolution, review access permissions, remove compromised sessions, rotate credentials where appropriate, and document the control failure. Vendor bank change verification is most effective when it is tested before an incident and embedded into routine vendor operations, not introduced only after a suspicious email appears.