Finance Index
How does bank account verification for vendors work, and which method should we use?
Reference guide to vendor bank account verification methods, including vendor records, onboarding requirements, compliance checks, fraud controls, and payment readiness.
Bank account verification confirms a vendor's payment destination is real - and ideally theirs - before money moves. The main methods: micro-deposits (small test amounts the vendor confirms), instant verification via bank login through a data aggregator, account-validation database services, and prenotes. A voided check verifies nothing - anyone can fabricate one - which is why verification became a discipline.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Bank account verification for vendors | Bank account verification confirms a vendor's payment destination is real - and ideally theirs - before money moves. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Related terms | Micro-deposits: one or two sub-dollar amounts land in the account; the vendor reports them back, proving they can see the account's activity - slow (days) but universal. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| Vendor impact | Distinguish the two claims. | Keeps vendor records and payment decisions reliable. |
| Risk check | Verification proves the requester controls the destination account - it cannot prove the requester is your vendor. | Keeps evidence clear and reduces control risk. |
| How do micro-deposits work | Small amounts (under a dollar) post within 1 - 3 banking days; the vendor reports the values to confirm. | Keeps vendor records and payment decisions reliable. |
Micro-deposits vs instant verification vs validation services - how does each work?
Micro-deposits: one or two sub-dollar amounts land in the account; the vendor reports them back, proving they can see the account's activity - slow (days) but universal. Instant verification: the vendor authenticates into their bank through an aggregator, proving access in real time - fast and strong, but some vendors refuse the bank-login step. Validation services: database checks confirming the account exists and its status, sometimes with ownership-name matching - frictionless but verifying validity more than ownership. Risk-tier them: instant or micro-deposits for new vendors and changes, database checks as a floor.
Does verification prove the vendor owns the account, or just that it exists?
Distinguish the two claims. Account validity (it exists, it's open, it accepts ACH) is what database checks prove. Account ownership/access (the entity you're dealing with controls it) is what micro-deposit confirmation and bank-login verification demonstrate. The fraud-relevant question is ownership - a fraudster's account is perfectly valid. Best practice pairs an ownership-class method with name matching between the account holder and the vendor's legal name.
Verification passed but the account belonged to a fraudster - what does verification actually protect against?
Verification proves the requester controls the destination account - it cannot prove the requester is your vendor. If a fraudster has compromised the vendor's email and passes your verification with their own account, every check passed and the money is still gone. That's why verification and *identity confirmation through a known channel* (the call-back) are separate, non-substitutable controls: verification authenticates the account, the call-back authenticates the counterparty.
How do micro-deposits work - amounts, timing, what if the vendor never confirms?
Small amounts (under a dollar) post within 1 - 3 banking days; the vendor reports the values to confirm. If they never confirm, the account stays unverified and unpayable - set an expiration, send reminders, and re-initiate if needed. Unconfirmed micro-deposits are an unfinished control, not a soft pass.
Vendor says they never received the micro-deposits - causes and how long to wait?
Usual causes: wrong account details (the deposits went somewhere else - re-collect), deposits landed but are hard to spot on a busy statement (tell them the descriptor to search), or normal banking lag. Give it 3 - 4 banking days before re-initiating; repeated failure on the same details is a data problem, not a patience problem.
Some vendors refuse bank-login instant verification - what are the fallbacks?
Reasonable refusal - fall back in order of strength: micro-deposits (no credentials shared), a validation-service check plus a verified bank document, and always the call-back to a known contact. Offer the menu rather than waiving verification; refusal of *every* method is itself a signal.
What is a prenote and is it still useful?
A prenote is a zero-dollar ACH test entry; if no return arrives within the waiting period, the account details are presumed valid. It's cheap and still worth using before first payments - but it only tests validity, not ownership, so it supplements rather than replaces real verification.
Should bank verification be required for every vendor or risk-based?
Verify every account before first electronic payment - the cost is trivial against a misdirected payment. Where you risk-tier is the *strength* of method: ownership-class verification plus call-back for high-value vendors, international vendors, and every banking change; baseline validation for small low-risk payees.
What is the nacha account validation rule for web debits - does it apply to vendor payments?
Nacha requires account validation for first-use accounts on WEB debits - consumer-initiated debit entries. Standard vendor disbursements are credits, so the rule doesn't technically bind them - but it set the industry's expectation that unvalidated accounts shouldn't receive first transactions, and it's the right standard to voluntarily apply.
Stampli perspective
Stampli treats verification as a workflow, not a checkbox: vendor banking details arrive through the authenticated portal, changes require review and approval before becoming payable, and validation failures or pending approvals can block payments from being scheduled. Risk signals are surfaced where payment decisions actually happen, and high-risk changes still warrant independent vendor confirmation through a trusted channel - Stampli's controls are designed to enforce that pause, not replace it.