Picture this: it is 4:40 on a Friday when your biggest vendor emails new bank details and asks you to update them before next week's payment run. The invoice looks right, the logo looks right, and the sender's name matches the contact you have paid for two years. You update the routing and account numbers, and Monday's five-figure ACH credit posts without a hitch — to an account your vendor has never seen. By the time anyone notices, the money is gone, and because you authorized the push, your bank has very little obligation to get it back.
That scenario is not exotic anymore. It is the modal way small businesses lose money to payments fraud. The Association for Financial Professionals found that 76% of organizations experienced attempted or actual payments fraud in 2025. The FBI's Internet Crime Complaint Center logged 24,768 business email compromise complaints that same year, totaling $3.05 billion in reported losses — and business email compromise is the polite name for tricking your payables process into redirecting a legitimate payment.
The defense is less glamorous than AI fraud detection and far more effective: validate every bank account before you send money to it or pull money from it. Here is how that works, what the rules already require, and the lightweight process a small team can actually follow.
What "Account Validation" Actually Proves
Account validation answers one narrow question: is this routing-plus-account-number combination real, open, and able to receive this type of ACH entry? A thorough check can also confirm the account's status (open vs. closed), its type (checking vs. savings), and in some cases whether the name on the account matches the name your payee gave you.
Just as important is what it does not prove. A validated account is not automatically your payee's account. If a fraudster hands you the routing and account numbers of an account they control, validation will happily confirm the account is real — because it is. Validation catches typos, closed accounts, transposed digits, and accounts that cannot accept debits. Catching impersonation takes one more step — confirming the instructions came from the real payee — which is why the vendor-change playbook later in this article pairs validation with out-of-band callbacks.
Think of it as two independent questions you must answer "yes" to before the first payment: is the account real, and is the instruction genuine?
The Rule That Already Requires It: Nacha's WEB Debit Validation
If your business pulls money from customer bank accounts through a website or app — subscription billing, rent collection, invoice autopay, donation processing — you are originating WEB debits, and account validation is not optional. Since March 2021, Nacha's Operating Rules have required originators of consumer WEB debits to include account validation in their commercially reasonable fraud-detection system, applied on the first use of an account number and again whenever the account number changes.
Note the scope limits, because they are exactly where small businesses get hurt:
- The rule covers consumer debits initiated over the internet. Payroll credits to your employees, vendor payments, B2B debits, and phone- or paper-authorized debits are outside its letter.
- Existing accounts that have already been used successfully are grandfathered; the rule targets first use and changes.
- Nacha does not prescribe one method. It names acceptable approaches — prenotification entries, micro-entry verification, commercially available validation services — and holds you to a "commercially reasonable" standard.
Nacha's own guidance has been pushing businesses to go further for years: apply validation to credits as well as debits, to employees and vendors as well as customers. The reasoning is simple. A failed payroll deposit is an administrative mess; a successful payment to a fraudster's validated-but-stolen account is a permanent loss. ACH credits you authorize are extraordinarily hard to reverse, which makes the moment before the first payment the cheapest control point you will ever get.
Four Ways to Validate an Account
Every method below confirms the account through a different channel. Pick based on how fast you need the answer and how much friction your payee will tolerate.
1. Prenotification entries (prenotes)
A prenote is a zero-dollar ACH entry sent through the network to the receiving account at least three banking days before the first live entry. If anything is wrong — bad account number, closed account, account that cannot take that entry type — the receiving bank returns it with a notification-of-change or return code, and you fix the data before real money moves.
Prenotes are the old reliable: cheap (often pennies or bundled into your bank's ACH service), fully inside the ACH network, and explicitly blessed by Nacha. Their weakness is speed and silence. Three banking days of lead time kills same-week onboarding, and a prenote that draws no return only proves deliverability — not that the person who gave you the numbers owns the account.
Best for: payroll enrollment with lead time, recurring vendor payments set up in advance, any flow where you control the calendar.
2. Micro-deposit verification
You send one or two tiny credits (typically a few cents each) to the account, and the payee proves access by reporting the exact amounts back — from their bank statement or online banking — usually within one to two business days. Some services follow with a small debit to net the test amounts back out.
Micro-deposits prove something prenotes cannot: the person completing verification can see inside the account. That is meaningfully stronger for customer enrollment. The cost is friction and delay. Legitimate customers abandon flows while waiting for test deposits to land, and support tickets spike around "I can't find the deposits."
Best for: customer bank-account enrollment where you need proof of access, especially when instant verification is unavailable.
3. Instant verification through open banking
The payee logs into their bank through a verification provider's secure flow, which confirms account ownership, status, balance sufficiency, and account details in seconds. This is the "connect your bank" button you have seen at checkout and in payroll apps.
Instant verification wins on conversion and speed, and it validates ownership directly rather than inferring it. The trade-offs are cost (per-verification fees, commonly well under a dollar each at volume but real at scale), coverage gaps at small banks and credit unions, and the reality that some of your vendors and employees will refuse to enter bank credentials into a third-party screen no matter how legitimate it is. Keep a fallback method for them.
Best for: customer-facing enrollment where drop-off costs you revenue, and any same-day onboarding.
4. Database checks and manual review
Routing-number validation against the Federal Reserve's directory, account-status lookup services, and old-fashioned document review (a voided check, a bank letter) form the lightest tier. These checks are fast and cheap, and you should run the automated ones on every account as a matter of hygiene — a routing number that does not exist should never reach your payment file.
But treat them as a floor, not a control. A routing number can be valid while the account number is fiction, and a voided check image is trivially forged. Use database checks to reject obvious garbage early, then validate for real with one of the first three methods before the first payment.
Where Small Businesses Should Use Validation (Beyond What the Rules Demand)
The WEB debit rule covers one corner of your payment activity. Fraud does not respect that corner. Extend validation to every first payment and every changed instruction:
Payroll and contractor direct deposit. New-hire enrollment is a typo farm: handwritten routing numbers, transposed digits, savings accounts entered as checking. Validate before the first pay run and you convert a failed deposit — plus an off-cycle correction, a stressed employee, and possibly a state wage-timing violation — into a quiet data fix. Re-validate whenever an employee updates their deposit details, because "I changed banks" is also one of the simplest social-engineering scripts against payroll.
Vendor onboarding and bank-detail changes. This is the highest-value application. Every new vendor's account gets validated before the first payment, and every change to existing banking details restarts the clock: treat the new account as a brand-new payee. AFP data shows ACH credits targeted in BEC schemes at 50% of organizations, with vendor-imposter fraud cited by 45% — up 11 points in a single year. A fraudster who cannot get you to skip validation has to beat your callback process too — most move on to an easier target.
Customer debits outside the WEB rule. Phone-authorized, paper-authorized, and B2B debits are not covered by the first-use validation mandate, but returns cost you the same returned-entry fees and the same collection headache either way. Validating these accounts is cheap insurance against the two most common return reasons: nonexistent accounts and accounts that cannot be debited.
One-time credits and refunds. Refunds to a customer-supplied account deserve the same treatment as a vendor payment. "Please refund to this new account instead" is a known fraud script, and a credit you push out is far harder to recover than a debit you never pulled in.
The Vendor Bank-Change Playbook: Six Steps That Stop Most BEC Losses
Bank-detail changes are where validation meets impersonation defense. Adopt this as written policy — auditors, insurers, and your bank all look more kindly on a documented process than on good intentions.
- Freeze changes arriving by email alone. Any new vendor account or changed banking detail enters a pending state. No payment file, no "rush wire," no exceptions for urgency or seniority — urgency is the attacker's favorite tool.
- Call back on a number you already hold. Confirm the change by phone using a number from your vendor master file, a signed contract, or the vendor's known website — never a number from the email requesting the change. If you cannot reach a known contact, the payment waits.
- Require a second approver. Changes to vendor banking records always need two sets of eyes, regardless of amount, because one changed record redirects every future payment to that vendor. Dual approval on the record change matters more than dual approval on any single payment.
- Validate the new account before first use. Run the new routing and account numbers through a prenote or a validation service. This catches both fraudster typos and the attacker's occasionally sloppy account data.
- Restrict who can edit the vendor master. Limit write access to vendor banking fields to named users, log every change with before-and-after values, and review that log monthly. An attacker who compromises one email account should not be able to quietly rewrite your system of record.
- Send a small test payment first for large relationships. For high-value vendors, a small initial payment that the vendor confirms by phone before you release the full amount adds a final, hard-to-fake checkpoint.
Steps 2 and 3 alone defeat the overwhelming majority of vendor-impersonation attempts, because those attacks depend on exactly one person acting on email instructions without an independent check.
Five Mistakes That Quietly Defeat Validation
Validating once and never again. Accounts close, get frozen, and change status. Re-validate on every change notification from your bank (notification-of-change codes are your bank telling you the data drifted — process them rather than filing them), and re-check dormant payees before waking them up.
Trusting a voided check image. A PDF of a check proves someone can make a PDF of a check. Accept it as a data-entry aid, then validate the numbers through the network or a service like any other new account.
Validating the account but not the owner. This is the gap described at the top: deliverability is not identity. Pair every validation with instruction verification — a callback, a signed form, an authenticated portal change.
Skipping validation for small payments. Fraudsters know about approval thresholds and test new payee records with small amounts before the big invoice. Apply the same first-use validation to a $40 payment as a $40,000 one; the cost is nearly identical and the small payment is often the probe.
Letting email own the change process. If banking-detail updates can be requested, approved, and confirmed entirely within email, your control is one compromised mailbox away from zero. The callback and the second approver must live outside the email thread.
The Bookkeeping Side: Keep Validation Visible in Your Ledger
Validation activity generates small money movements and administrative events that deserve proper books, not mystery entries:
- Book prenotes and micro-deposits explicitly. Even zero-dollar prenotes appear on bank activity reports, and micro-deposits move real cents. Route them through a clearing or bank-charges account so month-end reconciliation does not surface unexplained lines. Net the test amounts back where your process allows.
- Log verification events as part of the vendor or employee record. Who validated, when, by which method, and who approved the change is your audit trail. If a payment is ever disputed, that history is the difference between "we followed our process" and "we think someone checked."
- Reconcile notification-of-change codes promptly. When your bank tells you an account number or routing number needs correction, update the master record and note the correction. Unprocessed change notices compound into return fees and stale data.
- Track validation costs per channel. Per-check fees for instant verification belong in your cost of payment acceptance alongside processing fees. If one channel's verification cost exceeds its fraud and return savings, that is a pricing or process decision you can only make with the numbers in front of you.
Clean records here do double duty: they keep reconciliation quiet, and they document the "commercially reasonable" standard Nacha expects if your WEB debit practices are ever questioned.
Keep Your Payment Records Organized From Day One
Account validation keeps bad payments from leaving your bank account — but the verification logs, micro-deposit entries, and vendor-change approvals still need a home in your books. Beancount.io provides plain-text accounting that gives you complete transparency and control over your financial data, so every test deposit, fee, and correction is version-controlled and auditable instead of buried in a black box. Get started for free and see why developers and finance professionals are switching to plain-text accounting.
