4.2 WEB (Internet-Initiated Entries): Authorization, Authentication & Validation

4.2 WEB (Internet-Initiated Entries): Authorization, Authentication & Validation

Core Principle: Standard Entry Class code WEB (Internet-Initiated/Mobile Entry) governs electronic funds transfers where the consumer's authorization or payment instruction is captured or transmitted via the internet, a mobile application, or any wireless electronic network. Due to the open, remote nature of the web, Nacha enforces stringent risk management, authentication, and validation mandates for WEB debits to safeguard the network against cyber fraud and unauthorized account draining.

---

1. WEB Transaction Architecture: WEB Debit vs. WEB Credit

While historically envisioned primarily for e-commerce checkouts, the modern WEB SEC code encompasses both consumer pull debits and consumer push credits.

                                  WEB Entry Architecture
         ┌──────────────────────────────────┴──────────────────────────────────┐
         ▼                                                                     ▼
    WEB DEBITS (Consumer Pulls)                                           WEB CREDITS (Consumer Pushes)
  • E-Commerce Online Checkout                                          • Person-to-Person (P2P) Transfers
  • Online & Mobile Bill Payment Portals                                • Account-to-Account (A2A) Push Transfers
  • Digital Wallet Stored Value Funding                                 • Brokerage & Investment Account Funding
  • Recurring SaaS & Subscription Billing                               • Marketplace Seller & Gig Economy Payouts

WEB Debit (Consumer Pull Payment)

• Mechanics: A consumer provides bank account details (RTN and account number) on a merchant's website or mobile app to purchase goods, pay a utility bill, or fund a digital wallet. The merchant (Originator) pulls funds from the consumer's account.
• Risk Profile: Elevated risk vector due to potential account takeover (ATO), identity theft, synthetic identities, and stolen bank account credentials.

WEB Credit (Consumer Push Payment / P2P & A2A)

• Mechanics: A consumer initiates an instruction through an online banking platform, mobile wallet, or fintech app (e.g., Venmo, PayPal, Zelle ACH clearing) to push credit funds to another consumer's account (P2P) or to another account owned by the same consumer at a different institution (A2A).
• WEB Credit Identification: The SEC code and required party-identification fields distinguish WEB credits. P2P and A2A describe business use cases; they are not universal standard values for the Batch Header Company Discretionary Data field.

---

2. Payment Type Code: Current Treatment of S and R

WEB and TEL Entry Detail records have a two-character Payment Type Code in positions 77–78. Historically, R identified recurring entries and S identified single entries. Effective September 17, 2021, Nacha relaxed the universal requirement for these specific values: the ODFI may determine whether and how the field is populated. An RDFI therefore cannot assume that a blank or nonstandard value proves an entry is single, recurring, or a Subsequent Entry under a Standing Authorization.

The legal classification still matters. A Recurring Entry occurs at substantially regular intervals without a new affirmative act by the Receiver; a Single Entry is one-time; and a Subsequent Entry requires a later affirmative action under a Standing Authorization. The authorization and risk rules—not an assumed S/R code—control the classification.

• Single WEB Debit (S): Used when the consumer authorizes a single, stand-alone debit entry. Subsequent transactions require fresh authorization and separate timestamp logging.
• Recurring WEB Debit (R): Used when the consumer authorizes an ongoing series of debits recurring at regular intervals (e.g., monthly gym membership, cloud software subscription). The initial authorization governs subsequent entries until revoked.

---

3. The 5 Core Compliance Pillars for WEB Debit Originators

Because WEB debits carry the highest unauthorized return risk in the ACH Network, Nacha Operating Rules establish an exhaustive, multi-layered compliance framework for Originators and ODFIs:

                             The 5 Pillars of WEB Debit Compliance
  ┌─────────────────────────────────────────┼────────────────────────────────────────┐
  │                                         │                                        │
  ▼                                         ▼                                        ▼
1. Fraud Detection System        2. Account Validation Mandate     3. Annual Security Audit
  • Commercially reasonable        • Verify routing & account        • Article One 1.2.2 audit
    fraud screening engine           before initial debit              of data security
  • Velocity & device tracking     • Micro-entries, IAV, APIs,       • AES-256 / TLS 1.2+
  • Geolocation & anomaly scoring    prenotes, or consortium           encryption standards
  │                                                                                  │
  ├──────────────────────────────────────────────────────────────────────────────────┘
  ▼                                         ▼
4. E-SIGN Authorization & Disclosures    5. IP & Timestamp Logging
  • Express debit assent terms             • Capture consumer IPv4/IPv6 address
  • Conspicuous screen display             • Precise UTC/local authorization timestamp
  • Clear revocation mechanism             • Device fingerprinting metadata

Pillar 1: Commercially Reasonable Fraudulent Transaction Detection System

Under Article 2.5.17.4, every Originator of WEB debits must establish and implement a commercially reasonable fraudulent transaction detection system to screen each debit entry prior to origination. Key capabilities include:

• Device Fingerprinting: Tracking hardware MAC hashes, browser user-agents, and OS environments.
• Velocity Monitoring: Flagging anomalous spikes in transaction frequency or dollar volume from a single IP, account, or user profile.
• Behavioral & Geolocation Scoring: Detecting high-risk IP ranges (e.g., TOR exit nodes, commercial proxies, high-fraud foreign jurisdictions).

Pillar 2: Mandatory Account Validation Rule

Effective March 19, 2021 (with full enforcement effective March 19, 2022), Nacha requires Originators of WEB debits to use a commercially reasonable method of account validation prior to originating the first WEB debit to a consumer account, or whenever a consumer updates their routing transit number or account number.

Pillar 3: Annual Information Security Audit (Article One, Subsection 1.2.2)

Originators and Third-Party Senders originating WEB entries must undergo an annual information security audit validating that financial information (account numbers, routing numbers, SSNs) is protected using robust encryption:

• Data in Transit: TLS 1.2 or higher for all web sessions and API endpoints.
• Data at Rest: AES-256 encryption or secure tokenization for all stored customer banking data.

Pillar 4: E-SIGN Authorization Disclosures

In compliance with the federal E-SIGN Act (15 U.S.C. § 7001), online authorization screens must be clearly displayed and require an affirmative click or digital signature. Disclosures must include:

1. Clear identification of the Originator/Merchant.
2. Specification of the consumer's bank account to be debited.
3. Debit amount (or calculation formula) and effective transaction date.
4. Whether the payment is single or recurring (including frequency and duration).
5. Revocation instructions and customer service contact info.

Pillar 5: IP Address and Timestamp Capture

The Originator must log and retain complete technical audit trails of the authorization event, including the consumer's IPv4/IPv6 address, date/time timestamp, and session session identifiers, retained for at least 2 years from the revocation date.