ACH account validation is the check a business runs to confirm that a customer’s bank account is real, open, and able to accept ACH entries before pulling money from it. NACHA, which governs the ACH network in the United States, requires this check for any debit authorized over the internet, and fines for noncompliance can reach $500,000 per occurrence. The rules do not tell you which technology to use; they tell you the result you have to achieve and leave the method to you.
What the WEB Debit Rule Requires
The obligation comes from NACHA’s WEB Debit Account Validation Rule, effective March 19, 2021. It applies to every business that originates WEB debit entries, meaning any payment pulled from a consumer’s bank account through an internet-based authorization. The rule does not distinguish between business-to-consumer and business-to-business transactions. If the entry carries the WEB standard entry class code, validation is required.1Nacha. Supplementing Fraud Detection Standards for WEB Debits
The originator must use a “commercially reasonable fraudulent transaction detection system” that includes account validation. The system has to verify the account number the first time it is used and again whenever the account number changes, and the validation must confirm that the account is legitimate, open, and capable of receiving ACH entries.1Nacha. Supplementing Fraud Detection Standards for WEB Debits
One detail catches businesses off guard: the rule applies going forward. Account numbers already in use for WEB debits before the effective date are grandfathered in. Any new account number collected after that date needs validation before the first debit runs.
What “Commercially Reasonable” Means
NACHA deliberately avoids prescribing a single technology or vendor. The right approach depends on your business model, transaction volume, and risk profile. What works for a large subscription platform processing millions of debits is not what a small nonprofit needs.2Nacha. Account Validation Frequently Asked Questions
Factors that go into the assessment include the risk profile of the transactions themselves, your history of returns for invalid account information, how often your validation service returns a “no hit” and what your fraud experience looks like on those unidentifiable accounts, and any other fraud controls you already have in place.2Nacha. Account Validation Frequently Asked Questions
A validation service does not have to cover 100% of possible accounts to qualify. NACHA has not set a specific coverage threshold. The expectation is that you have evaluated the gaps and have a defensible rationale for the choices you made, ideally documented with input from legal counsel or your risk team.2Nacha. Account Validation Frequently Asked Questions
Methods You Can Use
NACHA recognizes multiple approaches, and you can combine them. The rules are technology-neutral.2Nacha. Account Validation Frequently Asked Questions
Micro-Deposits
The oldest and most widely recognized technique. Two small credit entries, each less than $1.00, are sent to the customer’s bank account. The customer checks their statement, identifies the exact amounts, and reports them back through your payment portal to prove they control the account. It works, but it is slow. The credits typically take one to three business days to post, and then you are waiting on the customer to log in and confirm.3Nacha. Micro-Entries Phase 1
NACHA formalized the practice through its Micro-Entries rules. Entries must use the Company Entry Description “ACCTVERIFY,” and the sender’s name must be recognizable to the customer as the business they are dealing with.4Nacha. End-user Briefing: Micro-Entries The originator also has to monitor forward and return volumes of micro-entries for signs of fraud. That does not mean reviewing every single entry, but you need a baseline of normal activity and the ability to spot anomalies, such as a sudden spike in micro-entries to accounts that never validated successfully.5Nacha. Micro-Entries Phase 2
Instant Account Verification
Instant verification uses third-party APIs to connect directly to the customer’s bank. The customer logs into their online banking through a secure widget embedded in your payment flow, and the system confirms in real time that the account exists, is open, and matches the information provided. This eliminates the multi-day delay of micro-deposits and reduces friction; customers who do not have their routing number memorized can authenticate with their bank credentials instead of digging up a checkbook.
The trade-off is that some customers are uncomfortable entering bank login credentials into a third-party portal. Coverage also varies by bank, and smaller institutions and credit unions may not be supported. If you rely solely on instant verification and a customer’s bank is not connected, you need a fallback method.
Prenotifications
A prenotification is a zero-dollar ACH entry sent through the network as a test signal. It verifies that the routing and account numbers are valid without moving money. If the receiving bank does not return an error or a Notification of Change within the required window, the account is considered verified.6eCFR. 31 CFR Part 370 Subpart B – Credit ACH Entries
Prenotifications are commonly used for recurring payroll and vendor payments where a few days of setup delay is acceptable. They do not confirm account ownership the way micro-deposits do. They only verify that the routing and account numbers point to a real, open account. For low-risk, ongoing payment relationships where you have other ways to confirm the payee’s identity, that is often enough.
Third-Party Validation Services
Commercial services offered by banks, payment processors, and specialized vendors can check account status through direct database queries. They typically return a result in seconds and can confirm whether an account is open, closed, or unable to accept debits. NACHA explicitly recognizes these services as a valid validation method, whether provided by an Originating Depository Financial Institution or a third party.2Nacha. Account Validation Frequently Asked Questions
Return Codes That Signal a Failed Account
When a validation attempt or live ACH entry fails, the receiving bank sends back a return code that tells you what went wrong. The codes you will see most often during validation are:
- R02, Account Closed. The account existed but has been closed. You cannot debit it.
- R03, No Account or Unable to Locate. The receiving bank cannot find an account matching the number.
- R04, Invalid Account Number. The number itself is malformed.
- R13, Invalid ACH Routing Number. The routing number does not correspond to any participating financial institution.
- R16, Account Frozen. The account exists but access is restricted, either by the bank or by legal order.
R03 and R04 returns typically arrive within two banking days. Tracking your return rates by code matters both for spotting data quality issues and for showing NACHA, if asked, that your fraud detection system is doing its job.
Protecting the Account Data You Collect
Collecting and storing bank account numbers creates a security obligation that goes beyond validation itself. Any non-bank originator, third-party sender, or third-party service provider that handles more than 2 million ACH entries per year must render account numbers unreadable when stored electronically. Encryption, tokenization, and truncation are all acceptable. Putting the data behind a password is not enough; access controls alone do not satisfy the rule.7Nacha. Supplementing Data Security Requirements
The requirement applies to data at rest. If an employee needs to pull up a full account number for a legitimate business function such as customer service, the data is considered active and the unreadability requirement does not apply in that moment. Once the task is done, the data goes back to its protected state. Organizations that cross the 2-million-entry threshold in a calendar year must comply by June 30 of the following year.7Nacha. Supplementing Data Security Requirements
Non-bank financial institutions that fall under the FTC’s Safeguards Rule carry a separate set of obligations, including a written information security program, encryption of customer data in storage and in transit, multi-factor authentication for anyone accessing customer information, regular penetration testing, and an incident response plan. A breach exposing unencrypted information belonging to 500 or more consumers must be reported to the FTC within 30 days of discovery.8Federal Trade Commission. FTC Safeguards Rule: What Your Business Needs to Know
Penalties for Getting It Wrong
NACHA enforces its rules through the ACH Rules Enforcement Panel, which reviews reported violations and classifies them by severity. Willful or reckless conduct affecting at least 500 entries, or entries totaling $500,000 or more, can be designated as egregious and classified as a Class 2 or Class 3 violation.9Nacha. Nacha Operating Rules – Reversals and Enforcement
A Class 3 violation, the most severe category, carries fines of up to $500,000 per occurrence and can include a directive requiring the Originating Depository Financial Institution to suspend the offending originator or third-party sender entirely.9Nacha. Nacha Operating Rules – Reversals and Enforcement Less severe violations still draw fines and corrective action requirements. In practice, the accumulated return fees, chargebacks, and exposure to network suspension often cost more than the NACHA fines themselves.
What’s Changing in 2026
NACHA has been steadily expanding fraud prevention requirements beyond WEB debits. New rules taking effect in 2026 extend fraud monitoring obligations to a broader set of ACH originators. Entities processing 6 million or more ACH transactions annually face a March 20, 2026 deadline, with additional deadlines later that year for smaller-volume originators. Account validation and fraud screening are moving toward becoming baseline expectations across the entire ACH network, not just for internet-initiated consumer debits.