Four questions hidden inside one green check
A customer enters routing and account numbers and a payment application announces that the account is verified. That label can conceal four different questions. Does the account exist? Can it accept the intended payment type? Does this person have access to information about it? Is this person legally entitled to authorize the proposed transaction? A method may answer one question convincingly and provide little evidence about the others. The quality of onboarding depends on preserving those distinctions after the interface reduces the result to a status badge.
Nacha's WEB-debit account-validation rule became effective March 19, 2021. Its minimum concerns a legitimate, open account that can accept ACH entries; it does not independently require verification of ownership. Validation applies before first use of an account number for WEB debits and before a change to that number. Commercial reasonableness depends on the originator's circumstances, so satisfying that minimum is not equivalent to proving that a particular business has controlled every relevant fraud risk. [1]
This article examines the evidence collected before payment. It does not treat validation as a substitute for ongoing transaction monitoring, ACH return handling or a company's broader customer-identification process. A successful onboarding test and a successful payment are different events, and the second can fail even when the first was performed correctly.
Who produces the evidence
The originator is the party initiating an ACH entry. Its originating depository financial institution, or ODFI, sends entries into the network, potentially through processors and other intermediaries. An ACH operator routes them to a receiving depository financial institution, or RDFI, which handles the receiver's account. Nacha's developer guide distinguishes these roles and the credit and debit directions. A technology vendor can supply the interface or verification evidence without becoming the account-holding bank. [2]
This separation matters when interpreting a response. A processor can confirm that it accepted a file without confirming that the destination account accepted an entry. An operator's successful processing status is not a statement about the customer's legal rights. A bank-data service can return account attributes without having authorized a debit. Good operational records therefore retain the issuer of each status, its timestamp, what it means and the account or instruction to which it applies. Collapsing these into one undifferentiated success field creates avoidable uncertainty when a payment later returns.
Prenotes test a route rather than a person
A prenotification, commonly called a prenote, is a zero-dollar ACH entry. Its function differs from a small transfer that a customer must read and confirm. Under the applicable prenote process, an originator considers returns and notifications of change during the required waiting period before proceeding. Nacha explains that the absence of a response through that period can support treating the account as open and capable of receiving entries. That is a specific network procedure, not a general principle that silence always equals consent. [1, 3]
The distinction is easiest to see through a hypothetical payroll change. A worker submits new bank details and the employer's prenote produces no adverse response. The employer now has better evidence about the routing of future entries. It does not follow that whoever submitted the change was the worker. The personnel system's authenticated change workflow and independent handling of suspicious requests answer a different question. Combining the evidence can produce a stronger process, but neither check should be described as doing the other's job.
What micro-entries add
Nacha micro-entries include credits below one dollar and associated offsets. Phase 1 took effect September 16, 2022; Phase 2 followed March 17, 2023. They use ACCTVERIFY. Corresponding credits and debits travel together for the same settlement timing, with aggregate debits no greater than credits. These are real entries. [3]
A confirmation workflow obtains evidence of access to the posted details. Unlike a prenote, no receiver response and no return do not complete verification. Future entries must await the completed validation process, adverse returns must be addressed and micro-entries themselves require authorization. [3]
Consider an invented example with credits of $0.17 and $0.29 and a simultaneous offset of $0.46. The credits sum to $0.46, leaving a net zero verification transfer after all entries post. Correct confirmation supports the proposition that the confirmer could obtain those details. It does not establish whether access came through sole ownership, joint ownership, a legitimate delegated role or unauthorized access. This is a logical limit of the observation, not a criticism of the usefulness of micro-entries.
Bank data can answer a different question
Nacha's account-validation resource center lists methods that include prenotes, micro-entry verification and commercial validation services. It distinguishes data-consortium providers, open-banking providers and combined approaches; inclusion is not an endorsement. These services may draw on pooled records, bank connectivity or other data. A buyer should therefore ask what the actual response establishes rather than assuming that every vendor's product called account verification returns equivalent evidence. [4]
For example, a result that an account was observed as open recently differs from a current bank response. A name-match result differs from proof that a specific individual may sign for a corporation. A connection that permits reading transactions differs from permission to initiate a transfer. These distinctions should be visible in the service's response definitions and the customer's own decision rules. An unavailable name field is an information gap; it should not quietly become a positive match or an automatic accusation of fraud.
Coverage also matters. Suppose Service A can instantly return evidence for 85% of a hypothetical customer base while Service B covers 95% but returns a less specific account status. A higher headline coverage rate is not sufficient to rank them. The business needs to know which customers are unserved, what fallback is offered and whether the successful response supports the action being contemplated. An account-validation method is best evaluated as part of a workflow, including its unresolved cases.
Authorization remains a separate record
A validated destination does not authorize a withdrawal. A payment instruction needs the appropriate authorization for its account type, initiation channel and transaction, independently of the fact that a validation test succeeded. Nor does confirmation promise that enough money will remain when a debit arrives. An account can be open and reachable while having insufficient available funds, restrictions on the relevant debit or a later change in circumstances. The validation result is evidence with a time and a purpose, not insurance against future failure.
The practical data model should separate customer identity records, account evidence, the payment mandate or authorization and each payment's result. That makes revocation, account changes and investigations easier to handle. If a customer revokes a debit authorization, an old verified-account flag should not override that revocation. If the account number changes, copying the former flag onto the replacement record defeats the purpose of validating the account actually used. These are design consequences of separating permissions from observations.
The economics of friction and false confidence
A hypothetical service onboards 10,000 people a month. Method A costs $0.20 per attempt and 80% complete it; Method B costs $1.00 per attempt and 95% complete it. Direct monthly validation expense is $2,000 versus $10,000. Completed onboardings are 8,000 versus 9,500. The incremental direct cost is $8,000 for 1,500 additional completed onboardings, or about $5.33 each. These are invented inputs, not prices or performance claims for any provider.
That calculation still does not establish which method is better. If each additional legitimate active customer produces $12 of contribution over the chosen measurement period, the additional 1,500 completions would generate $18,000 before other costs, leaving $10,000 after the incremental validation expense. But if many of those completions never activate, or if their fraud and support costs are higher, that result changes. The useful comparison is incremental legitimate activity and loss-adjusted contribution, rather than the cheapest lookup or highest completion percentage alone.
There is also a selection problem. Customers taking a slow fallback path may differ from those completing an instant path. Comparing their losses without accounting for those differences can unfairly credit or blame the method. A careful evaluation follows similar cohorts, captures why the fallback occurred and measures later outcomes over the same period. It should record uncertainty instead of presenting correlation as proof that one verification technique caused a lower loss rate.
Failed tests need meaningful destinations
An unsuccessful check can mean an invalid account, unavailable data, customer abandonment, a service outage or a completed test with an inconsistent response. Treating all of these as fraud inflates alert counts and burdens legitimate users. Treating all of them as harmless technical failures does the opposite. A useful exception taxonomy separates failure to obtain evidence from evidence that contradicts the proposed payment details, with controlled routes for correction and review.
A business should measure time to completion, unresolved cases, support contacts, later administrative returns and later unauthorized-payment reports separately. An observed increase in returns might reflect a product change, a customer mix change or degraded source data. The investigation needs enough provenance to distinguish these explanations. Retaining only the final green badge makes the metric easy to display but leaves the operator poorly equipped to understand a change.
Nacha also requires commercially reasonable fraud detection for micro-entry origination, including monitoring forward and return volumes. This is an obligation concerning the validation activity itself, distinct from the first-use WEB-debit rule. [3] The larger principle is that a safety control can create operational activity that needs its own oversight. Small dollar amounts do not make careless access, excessive retries or unexplained volumes economically irrelevant.
What a credible verification claim sounds like
A precise statement might say that an account accepted a test and the user confirmed specified information on a given date. Another might say a named provider returned a particular account-status result. Both are more informative than an unqualified ownership guarantee. The evidence should support a bounded conclusion, be refreshed when relevant facts change and feed a wider payment-risk decision appropriate to the business.
The central tradeoff is between speed, coverage, cost and the strength of the question answered. Better validation can reduce routing errors and improve onboarding, but the benefit disappears if the business uses the answer for a different question. Reachability, access, identity, authorization and available funds should remain separate concepts from the first account-entry screen through the eventual payment investigation.
Sources
- Nacha, Supplementing Fraud Detection Standards for WEB Debits; effective March 19, 2021SourceBack to text: ↑1↑2
- Nacha, How ACH Works; checked October 4, 2026SourceBack to text: ↑1↑2
- Nacha, Micro-Entries Phase 1 and FAQs, including Phase 2 effective March 17, 2023SourceBack to text: ↑1↑2↑3↑4
- Nacha, Account Validation Resource Center; June 5, 2025SourceBack to text: ↑