How should a small business verify a supplier's new bank account before paying?

Why the payment should pause

A bank-detail change can arrive inside a perfectly ordinary purchasing conversation. The invoice may refer to a real delivery, the sender name may match previous mail, and the request may be phrased as a routine accounts update. None of those features proves that the new account belongs to the supplier. Hong Kong Police describe a scam in which attackers used knowledge from stolen commercial email, impersonated a seller, and asked the buyer to redirect payment to a changed account. The buyer discovered the deception only after speaking to the real seller. Treat the changed destination as a separate decision from whether the underlying invoice is due.

Start with a rule that any new beneficiary or change of account number pauses release of the affected payment until verification is complete. The pause should apply even if the invoice is overdue or a manager forwards the email with an urgent instruction. An urgent deadline is a reason to arrange the check promptly, not to omit it. Keep the original invoice in the payables queue with a visible hold reason; do not silently reject a genuine supplier or lose the due date. If several invoices share the changed beneficiary, mark every affected item. A team that only holds the newest invoice can still pay an older one through the altered supplier record.

Define the trigger broadly enough to cover a new bank, a changed branch or account number, a different beneficiary name, or a request to use another payment channel. The finance team should also notice a message saying that the old account is temporarily unavailable, because that is still a destination change. Do not ask staff to infer authenticity from spelling or formatting. Genuine suppliers make mistakes; convincing attackers can copy signatures and previous threads. A consistent trigger keeps the decision about evidence rather than whether a message merely feels suspicious.

Use a channel that the change request did not supply

The key check is to contact the supplier through a number or channel already trusted before the request arrived. Use the signed supplier agreement, an established contact entry that was previously verified, or a number confirmed through a separate procurement record. Do not call the number in the change email, its attachment, or a reply to that thread; the same attacker may control all three. The Police explicitly recommend confirming identities by telephone, fax or other means before remittance. HKCERT likewise warns that scammers can spoof a business partner to request a transfer to a new account. For a small firm, a recorded call to the existing contact is usually a practical starting point.

The caller should ask the established contact to confirm that a change was requested, who authorized it, the exact beneficiary name and account details, and which invoices it covers. Read details back from the proposed record instead of asking a broad yes-or-no question. If the established contact cannot verify the change, obtain another independently sourced contact within the supplier organisation; do not let the person who sent the email nominate their own verifier. Where the supplier's process requires a formal letter, collect it as supporting evidence, but recognise that a letter attached to a compromised thread does not replace the independent contact. Record the contact source, call date, person reached and result, while avoiding unnecessary personal information.

Split the work into intake, verification and approval when the team has enough people. One person can collect the request, another can use the existing contact channel, and an authorised approver can release the master-data change after reading the evidence. A very small team may not have three staff members. In that case, require at least a second person to review the original request, the independent contact source and the exact account details before the payment file is approved. The purpose is to catch a single person's mistake or a rushed override. Document who may make an emergency exception and what evidence they must still gather; an undocumented exception becomes the routine route around the control.

Make the record and the payment agree

A useful change record ties together the supplier identity, old and proposed beneficiary, request source, affected invoices, independent verification, approval and effective date. Keep the prior account visible in history rather than overwriting it without a trace. The payables screen should show whether verification is pending, rejected or approved. Only the approved details should flow to the bank payment file. Before release, compare the payment file's beneficiary and account with the approved record, not merely with the invoice PDF. If the system imports bank details from invoices automatically, require a human review at the change boundary; automation should not turn an unverified attachment into the authoritative supplier master.

Consider a worked case. A regular packaging supplier has delivered cartons and sends a genuine-looking invoice for HK$48,000. The email says its account has changed and asks for payment today. Accounts marks that invoice and other pending invoices to the supplier as held, retrieves the phone number from the signed onboarding file, and calls the known contact. The contact says the account has not changed. The team does not update the beneficiary and does not pay the account in the email. It records the discrepancy and contacts the supplier through the established channel to resolve the invoice. The amount is an illustrative scenario, not a reported loss or a threshold at which checking becomes optional.

Now change one fact: the established contact confirms a real change but says it applies only to invoices issued after a particular date. That answer is not a blanket approval for all open invoices. The team records the scope, checks whether the supplier wants existing invoices paid to the old account, and gets the authorised approver to accept the specific mapping. If there is doubt about ownership, beneficiary spelling or scope, keep the hold. Resolve the mismatch with the supplier before changing the record. This avoids a common operational failure: treating a verified conversation as permission for a broader change than was actually confirmed.

Test the control and handle a mistaken transfer

Test the process with a harmless sample change before relying on it. Ask a colleague to submit a request that looks plausible but contains a new account. Check whether the invoice is held, whether the verifier chooses the old contact record, whether the approval history survives an edit, and whether a second pending invoice stays held. Also try a request received by telephone or messaging rather than email. The system should apply the same change rule regardless of channel. Review rejected and approved changes periodically, especially any that bypassed normal sequencing. This is a process check, not a promise that every fraud attempt will be detected.

If a transfer has already gone to a suspect account, act on the incident rather than editing the master record and moving on. Contact the bank immediately with the payment reference and ask about available response options. HKCERT advises contacting the bank immediately where financial information and loss are involved and reporting financial loss to police. Preserve the original messages, payment instructions, verification notes and account-change log. Alert the real supplier through the established channel and check whether email accounts or rules were compromised. Restrict further payments until the destination is established. Record the incident timeline so staff can correct the specific gap without assuming that a later refund is certain.

The next action for an owner is small and concrete: list every place where supplier bank details can enter the business, name one independent contact source for each active supplier, and make a changed destination visible before payment approval. Then rehearse one request from arrival to bank-file release. A software team can help place the hold, preserve prior values and link approvals to affected invoices, but management must decide who is allowed to verify and approve. The useful outcome is an answer to a simple question at release time: who independently confirmed this exact destination for this exact payment?

There is one more boundary to test: a supplier can legitimately change its account while a payment is already queued. Decide whether an approved change takes effect for new payment batches only or also recalls a batch awaiting bank release. The payment approver should see both the approved master-data version and the version used when the batch was built. If they differ, stop and rebuild or explicitly resolve the difference with the supplier; never assume the newest record automatically describes an older invoice. Make the status visible to procurement as well as finance so a buyer does not reassure the supplier that payment has gone out when the bank file is still held. A weekly review of open holds can reveal legitimate suppliers waiting for verification, stale requests and duplicate attempts. The review should close each item with a reason, so the control remains usable during a busy payment cycle.