How Do You Verify a Vendor Payment Request Is Real Before Your VA Processes It?
A vendor email arrives asking to update banking details before the next invoice gets paid. The message uses the vendor's real logo, references a real recent order number, and reads exactly like the vendor's usual correspondence. A virtual assistant processes the change and routes the next payment to the new account. Three weeks later, the actual vendor calls asking why an invoice went unpaid. That sequence, not a hacked password or a broken firewall, is how most vendor-payment fraud actually succeeds, and it succeeds specifically because nobody built a verification step that doesn't depend on the email looking convincing.
Secure Bookkeeping: Permissions, NDAs, and Best Practices for Financial Data names Vendor Email Compromise as the threat growing fastest against bookkeeping operations. This article covers the specific, practical protocol that stops it: what a verification step actually looks like, which controls a bank already offers for free, and how to build a process a virtual assistant can run without a security background.
Why Does a Convincing Email Beat Every Technical Control?
Vendor Email Compromise doesn't touch a login, a firewall, or a password, which is exactly why MFA and strong credentials don't stop it. The attacker either compromises the real vendor's email account or builds a convincing lookalike domain, then times a payment-detail change request to arrive alongside a real invoice cycle. Every technical signal looks normal because, from the system's perspective, nothing abnormal happened. A legitimate-looking email requested a change, and someone with the authority to process it did.
The fix isn't a better spam filter. It's a verification step that exists independently of whatever channel the request arrived through, because the entire point of this fraud is that the channel itself has been compromised or spoofed.
What Does an Actual Verification Protocol Look Like?
Never verify a banking change using the contact information in the request itself. A fraudulent email that includes a phone number will, unsurprisingly, connect to the fraudster if called. Verification requires pulling the vendor's phone number from an independent source: a prior contract, the vendor's official website typed directly into a browser, or a previous invoice from before the suspicious request arrived.
Require a callback, not a reply email, for any payment-detail change. A reply to the same email thread just confirms the request with whoever controls that thread, which may be the attacker. A phone call to an independently sourced number reaches an actual person who can confirm or deny the change in real time. This single step, a callback before acting on any banking change, closes the gap that stops most Vendor Email Compromise attempts cold.
Build a waiting period into anything urgent. Fraudulent requests routinely carry manufactured urgency, "the payment must go out today or we'll be in breach of contract," specifically because urgency pressures people into skipping verification. A documented rule that any banking change requires 24 hours and a completed callback before processing, no exceptions for urgency, removes the fraudster's most reliable lever.
Route every vendor-detail change through the Movement lane, never Production. Secure Bookkeeping's Lane System draws a hard line between drafting a payment and releasing one. A vendor banking change should sit in that same category: a virtual assistant can update the record after verification, but the actual payment execution stays behind a separate approval that the VA cannot grant alone.
What Free Bank Tools Actually Catch This Before It Happens?
Positive Pay, a service most business banks already offer, gives a business a technical backstop behind the human verification process. The business sends the bank a list of issued checks or approved ACH payments before they go out, and the bank matches every incoming payment request against that list, flagging anything that doesn't match for a same-day decision rather than paying it automatically. A fraudulent payment routed to a changed account, or an altered check amount, gets caught at the bank level, even if it slipped past the human review.
Dual authorization on electronic transfers adds a second, independent check inside the business's own systems: one person initiates a payment, and a different person has to separately approve it before it is released. A virtual assistant drafting and scheduling a payment inside Bill.com or Melio, without the authority to release funds alone, is a dual authorization applied to the exact role most exposed to this fraud. Neither control costs extra in most cases; both sit unused at most small businesses simply because nobody set them up.
What Happens When the Protocol Actually Gets Tested?
A fifteen-person architecture firm's bookkeeping VA received an email, seemingly from a longstanding contractor, requesting an updated bank account ahead of a US$34,000 project milestone payment. The email matched the contractor's usual tone, referenced the correct project name, and arrived from a domain one character off from the real one, close enough that nobody caught it at a glance. Following the firm's verification protocol, the VA looked up the contractor's number from a signed contract on file rather than the email signature, called, and reached the actual contractor, who confirmed no such request had been sent. The firm's dual-authorization setup on Bill.com meant the fraudulent change, even if it had slipped through, still required a second person's approval before any payment actually moved. The fraud attempt cost the firm roughly twenty minutes of a VA's time and nothing else. The same attempt against a business with no callback requirement and no dual authorization is the version that shows up in the FBI's billion-dollar annual BEC loss figures.
Who Should Actually Own This Verification Step?
The verification protocol works only if one specific person owns it, rather than existing as a general policy that everyone assumes someone else is following. A virtual bookkeeping assistant trained specifically on this protocol, with the authority to pause any payment pending callback verification without needing permission to pause it, closes the gap that a general "be careful" instruction leaves wide open. That authority matters as much as the training: a VA who feels obligated to process an urgent-sounding request rather than delay it for verification defeats the entire protocol, regardless of how well trained that VA is on paper.
Building this into onboarding, rather than treating it as an occasional reminder, is what makes it actually stick. A new bookkeeping VA should review the firm's real vendor list, confirm independently sourced contact details for the highest-value vendors before ever processing a live payment, and walk through at least one simulated verification call during training. That upfront investment runs for a few hours. The alternative, discovering the gap during an actual fraud attempt, runs considerably longer and costs considerably more.
Writing the protocol down matters as much as running it once. A one-page vendor verification policy, listing which changes require a callback, whose approval releases a flagged payment, and where independently sourced contact numbers get stored, turns the process into something a new VA can follow on day one rather than something only the most experienced team member remembers to apply.
How Does This Fit Into a Broader Financial Security Setup?
Vendor verification is one piece of a system, not a replacement for the access controls and monitoring Secure Bookkeeping covers in full. Role-based permissions limit what a compromised account can do. MFA closes the credential-theft door. Vendor verification closes the door that those controls structurally cannot, since the fraud never tries to breach anything. A business that has all three running, tight permissions, MFA everywhere, and a callback requirement on every payment-detail change has closed the three most common paths bookkeeping fraud actually takes, rather than defending well against one and leaving the others wide open.
A business evaluating a staffing partner for a bookkeeping placement should ask directly whether vendor-verification training is part of standard onboarding or something the client has to request and build separately. Aristo Sourcing places bookkeeping and finance-support virtual assistants across South Africa and the Philippines; any placement partner, this one included, should be able to answer that question specifically rather than with a general assurance that the VA "takes security seriously."
