The WEB SEC code is the Nacha Standard Entry Class code used to identify ACH debits from a consumer’s bank account that the consumer authorized over the internet or through a wireless device such as a phone or tablet. Any time someone pays a bill, buys something, or sets up a recurring charge online and the money is pulled directly from their checking or savings account, that transaction is coded WEB in the ACH file. The code tells every bank in the chain how the payment was authorized, which in turn controls what the originating merchant had to do before sending it and what happens if the consumer later disputes the charge.
Who Uses the WEB Code and When
WEB applies only to debits from consumer accounts authorized online or by wireless device. Business-to-business payments use a different code, most commonly CCD (Corporate Credit or Debit).1Nacha. ACH Guide for Developers – ACH File Details If a consumer agreed to the payment on a website or in an app and you are pulling funds from their bank account, WEB is the correct code.
WEB entries split into two types. A single entry is a one-time debit tied to a specific purchase or bill. A recurring entry is a series of debits taken at regular intervals under a standing authorization, like a monthly subscription or a loan payment. Recurring authorizations have to spell out more, including how the consumer revokes consent and how much advance notice they need to give before a cancellation takes effect.2Nacha. WEB Proof of Authorization Industry Practices Coding a recurring charge as a single entry, or the reverse, can trigger processing errors and avoidable returns.
Authorization Requirements for WEB Debits
A valid WEB authorization has to collect the bank’s nine-digit routing number, the consumer’s account number, and the dollar amount of the debit. For a recurring charge, the amount can be a fixed figure, a range, or an amount determined by activity, but the authorization has to explain how it will be calculated.2Nacha. WEB Proof of Authorization Industry Practices It also has to say when the debit will occur and give the consumer a clear way to revoke consent.
No paper signature is required. The Electronic Signatures in Global and National Commerce Act (E-SIGN) allows digital consent methods such as clicking an “I Agree” button or entering a PIN.3Office of the Law Revision Counsel. 15 USC 7001 – General Rule of Validity Whatever method you choose, the system has to create a record of the authorization that can be reproduced later. You must keep that record for at least two years after the authorization is terminated or revoked.
Producing Proof of Authorization on Demand
When a consumer disputes a WEB debit, the consumer’s bank (the RDFI) can ask the originator’s bank (the ODFI) for proof the transaction was authorized. The ODFI has 10 banking days to produce it after the request.4Nacha. ACH Operations Bulletin 3-2020 If a clear authorization record isn’t available inside that window, the transaction is treated as unauthorized, the debit is reversed, and your ODFI may pass additional penalties through to you.
Account Validation and Fraud Detection
Nacha Operating Rules Subsection 2.5.17.4 requires originators of WEB debits to use a “commercially reasonable fraudulent transaction detection system.” At a minimum, that system has to validate the account number before the first debit. Validation means confirming the account is legitimate, open, and able to receive ACH entries at the receiving bank.5Nacha. Supplementing Fraud Detection Standards for WEB Debits The requirement applies to the first use of any account number and whenever the account number changes.
Most merchants meet this requirement through third-party verification services that check account status in real time by API. Skipping validation isn’t just a rules violation; it drives up administrative returns like R03 (no account found) and R04 (invalid account number), which count against your return rate thresholds and generate per-item fees.
Originators also have to use commercially reasonable encryption to protect consumer data as it moves, which in practice means current Transport Layer Security (TLS) protocols. The broader fraud detection system is expected to monitor for suspicious patterns, such as unusually large debits, rapid entries from the same IP address, or entries aimed at accounts flagged in prior returns. Nacha enforces violations through its National System of Fines, and the ODFI can pass those costs to the originator.
Return Rate Thresholds You Have to Stay Under
Nacha measures three return rates over the preceding 60 days or two calendar months. Crossing any of them triggers an inquiry from your ODFI and can lead to enforcement, including fines.
- Unauthorized Return Rate — 0.5%. Unauthorized returns (codes R05, R07, R10, R11, R29, R51) divided by total debits originated. This is the strictest threshold because these returns mean consumers are claiming they never agreed to the charge.6Nacha. How to Calculate Unauthorized Return Rate
- Administrative Return Rate — 3.0%. Covers R02 (account closed), R03 (no account/unable to locate), and R04 (invalid account number). These reflect data quality: closed, nonexistent, or wrong account numbers.7Nacha. Administrative or Overall Return Rate
- Overall Return Rate — 15.0%. All return reason codes combined. RCK entries and their returns can be excluded from the calculation.7Nacha. Administrative or Overall Return Rate
If you breach a threshold, the ODFI evaluates your activity and may require a corrective action plan. In serious cases Nacha can impose fines or ultimately restrict your access to the network.8Nacha. ACH Network Risk and Enforcement Topics The 0.5% unauthorized line is tight at volume. An originator running 10,000 debits in a rolling period can only absorb 50 unauthorized returns before crossing it.
Consumer Dispute Rights That Reach the Merchant
Consumers who see an unauthorized ACH debit on their bank statement have protections under Regulation E, which governs electronic fund transfers. ACH debits generally don’t involve an access device like a debit card, so the rules are relatively favorable to the consumer: if they report an unauthorized transfer within 60 calendar days of the bank sending the statement showing the charge, they face no liability.9Consumer Financial Protection Bureau. 12 CFR 1005.6 – Liability of Consumer for Unauthorized Transfers
If the consumer misses the 60-day window, they can still report the transfer, but they may be liable for unauthorized debits that occur after the 60 days pass and before they notify the bank, if the bank can show those debits would have been prevented by timely notice.
Once a dispute is filed, the bank has to investigate and decide within 10 business days. It can extend the investigation to 45 days only if it provisionally credits the consumer within 10 business days and lets the consumer use those funds during the investigation.10Consumer Financial Protection Bureau. 12 CFR 1005.11 – Procedures for Resolving Errors If the bank finds an error, it has to fix it within one business day. If it finds no error, it must provide a written explanation and tell the consumer they can request the supporting documents.
For the merchant, the practical consequence is that disputed WEB debits are often reversed through the ACH return process before the bank’s investigation even wraps up, and the provisional credit comes out of your settlement. The authorization record you captured at signup and the account validation you ran before the first debit are the evidence you fall back on when a consumer says the charge wasn’t theirs.