BankChangeGuard
Dashboard
← All posts

Vendor Bank-Change Fraud: The Out-of-Band Callback Workflow (and the Audit Trail to Keep)

In 2024, reported business email compromise (BEC) losses totaled $2.77 billion across 21,442 complaints, an average of roughly $129,000 per reported incident. That figure comes from the FBI's Internet Crime Complaint Center 2024 report (ic3.gov). A large share of those losses run through one specific moment in the accounts-payable process: a vendor changes its bank details, the change is accepted, and the next scheduled payment lands in the fraudster's account instead of the supplier's.

This post is about that single moment, and about a manual workflow a bookkeeper can run today with no software at all. We will also cover the evidence you should keep, and why a note in the QBO memo field is not the same thing as an audit trail.

Anatomy of the attack

The dangerous version of this fraud does not look like a crude phishing email. It looks like an ordinary message from a vendor you have paid for years.

A typical sequence:

  1. The attacker compromises a mailbox somewhere in the supplier's organization, often in billing or sales. This can happen weeks before anything else does.
  2. The attacker reads the existing email thread between that supplier and your firm. They learn the tone, the invoice numbers, the names, the payment cadence.
  3. At the right moment, they reply inside that same thread: "We've switched banks. Please update our details for the next payment." The new account and routing numbers are attached, sometimes on a letterhead that matches the real one.

Because the message arrives through the genuine, already-trusted thread, every surface signal checks out. The sender address is correct. The signature is correct. The history above the message is real. Nothing in the email itself tells you it is fraudulent, because the legitimate channel is the thing that was compromised.

This is why "the email looked completely normal" is the most common thing victims say afterward. It looked normal because it came from a real account, or was spoofed to sit inside a real conversation.

Why replying to the thread fails

The instinct is to reply: "Thanks, just confirming you've changed banks?" If the attacker controls or is monitoring that mailbox, they answer "Yes, confirmed," and you have verified the fraud against itself.

The principle that defeats this is called out-of-band verification. It means you confirm the request using a channel that is independent of the channel the request arrived on. If the change came by email, you do not confirm by email, and especially not by replying to the same thread. If it came by phone from a number you do not already have on file, you do not confirm by calling that number back.

The reasoning is simple. The requesting channel may be controlled by the attacker, so any confirmation that travels through it can be forged by the same party. Verification only means something when it reaches a contact point the attacker does not control.

The manual workflow you can run today

You do not need a tool to apply this. Here is the workflow a bookkeeper can run right now.

1. Treat every bank-change request as unverified until proven otherwise. This includes requests from vendors you have paid for years. Trust in the relationship is exactly what the attack exploits.

2. Identify the previously-verified contact. This is the person and contact channel you had on file before the change request arrived. Not the email that sent the request. Not a phone number included in the request. The contact you already knew and had used successfully in the past.

3. Reach out through a known channel, never the requesting channel. Call the phone number you already have on record for that vendor, from your own records, not from the new email or its signature block. Speak to the previously-verified contact and confirm both that the bank change is real and the new account details exactly as you received them.

4. Escalate high-value or unusual changes. For large payments, or anything that feels off (urgency, a brand-new contact, a request to pay before the usual cycle), add a second control: a verbal confirmation by a known phone number, plus a second person at your firm approving the release. Dual approval means the attacker has to defeat two independent people, not one.

5. Decide, then act. Once the change is confirmed out-of-band, update the vendor in QuickBooks Online and release the payment. If you cannot confirm it, hold the payment and escalate. A held payment is recoverable. A sent one usually is not.

One caution worth stating plainly: a callback confirms that someone at a contact point you trusted agrees the change is real. It is a workflow control, not independent proof that the new account is owned by your vendor. For high-risk changes, treat it as one layer among several.

What evidence to keep, and why a memo field is not enough

Running the workflow is half the job. The other half is being able to show, later, that you ran it.

Most bookkeepers capture this informally. A screenshot of the email. A line typed into the QuickBooks Online vendor memo field: "Called Maria 6/13, confirmed new bank, OK to pay." This is far better than nothing. But it is not a structured audit trail, and the difference matters.

A memo field is free text in a live record. It can be edited or overwritten later, by anyone with access, with no history of who changed what or when. It captures that a note exists now, not when it was written, and it does not link to the underlying evidence in a tamper-evident way. It does not produce anything you can hand to an auditor, an insurer, or a bank as a standalone record.

A structured audit record, by contrast, captures the facts as discrete fields at the time they happened:

  • The vendor and the specific change requested (for example, the new account's last four digits).
  • The channel the request arrived on, and the channel used to verify it.
  • The timestamps for each step.
  • The attestation text confirming who verified the change and how.
  • A cryptographic hash (SHA-256) of the evidence, so you can later prove the record has not been altered.

The test to apply is simple. If a payment to that vendor were disputed eighteen months from now, could you produce a record of exactly what you checked, when, and through which channel, in a form that cannot quietly have been edited after the fact? A memo field does not pass that test. A structured, timestamped, hashed record does.

Why Nacha Phase 2 raises the bar on this

Until recently, an out-of-band callback was good practice that few firms had to document. Under the 2024 Nacha Risk Management rules, the expectation to have a documented control reaches every non-consumer originator.

Nacha's 2024 Risk Management rules add fraud-monitoring obligations aimed at reducing credit-push fraud, including payments authorized under false pretenses, which is precisely what vendor-impersonation BEC is. The rollout has two phases:

  • Phase 1, effective March 20, 2026, applies to all ODFIs and to larger non-consumer Originators, Third-Party Service Providers, and Third-Party Senders, those with 2023 ACH volume of 6 million entries or more (nacha.org, Phase 1).
  • Phase 2, with a practical effective date of Monday, June 22, 2026 (June 19 is the Juneteenth federal holiday, so the next banking day applies), removes that volume threshold entirely. All non-consumer Originators, TPSPs, and TPSs must establish and implement risk-based processes and procedures reasonably intended to identify ACH entries initiated due to fraud, regardless of size (nacha.org, Phase 2).

Two points are worth being precise about. First, the obligation sits on the originator side, the business sending the ACH credit and its bank, not only on the receiving institution. If your firm originates payments for clients, this reaches you. Second, the rules are technology-neutral. Nacha does not mandate a specific method or tool, and it does not certify third-party fraud-monitoring products. You are expected to tailor a control to your own risk profile, and to be able to show that you have one (nacha.org, new rules now in effect; credit-push fraud resource center).

June 22 is the date the obligation turns on for everyone, regardless of volume, and then stays on. It is not a deadline that expires after the fact. The practical consequence is that the out-of-band callback you may already do informally now needs to be a documented, repeatable process, with evidence you can retain and produce. The work shifts from "we usually call to check" to "here is the record of every change we verified and how."

Where BankChangeGuard fits

You can run the entire workflow above by hand, and if you do it consistently you are already ahead of most firms. The cost is that doing it consistently, and keeping defensible evidence for every change across every client, is tedious, and tedium is where controls quietly lapse.

BankChangeGuard automates the parts that are easy to skip. It connects to QuickBooks Online with read-only access on vendor and bill scopes (it does not touch bank credentials, does not originate ACH, and does not move money). When a bank-change request comes in, you log it against the synced vendor and enter the new account's last four. The system emails a one-time code to the previously-verified contact on file, the contact known before the change was requested, rather than to the channel that asked for the change. It then produces a structured, exportable audit record (PDF): timestamps, channels, attestation text, and a SHA-256 evidence hash, the kind of documented control and evidence an auditor would expect to see.

To be clear about scope: the email callback is a workflow control, not independent verification of bank-account ownership, so for high-value or suspicious changes you should still add a known-number phone call or dual approval. BankChangeGuard supports your Nacha Phase 2 fraud-monitoring obligations; it does not make you "Nacha-compliant," and it does not replace your bank's own obligations. The decision to release, hold, or escalate a payment, and the ACH origination itself, stay with you and your bank.

It is $99 per month, flat: single seat, one QBO company. If you already run the callback by hand, this is the same control, made routine and documented.

This article is informational and does not constitute legal, accounting, insurance, or compliance advice. Confirm your obligations with your bank and your professional advisors.