These minor changes will become effective June 21, 2024.

General Rule for WEB Entries (Article Two, Subsection 2.5.17.1)

All consumer-to-consumer credits must be originated using the WEB SEC Code, “regardless of whether the authorization is communicated via the Internet or Wireless Network.”

• That is, no matter what the consumer Originator’s communication channel is for the payment instruction, the entry must be coded as a WEB credit.

The current reference to the Internet or Wireless network in the context of P2P WEB credits is confusing to some industry participants. Some ODFIs and P2P service providers are coding consumer-to-consumer credits as PPD entries when the consumer’s instruction has been communicated through non-internet means (e.g., via phone, in person).

This change would re-word the WEB general rule to make clear that WEB must be used for ALL consumer-to-consumer credits, regardless of how the consumer communicates the payment instruction to the ODFI or P2P service provider.

Definition of Originator (Article Eight, Section 8.71)

Current rules define an Originator only by the relationship it has with the ODFI - "a Person that has authorized an ODFI (directly or through a Third-Party Sender) to Transmit...an entry to the Receiver’s account at the RDFI."

The existing definition is silent with respect to the Originator’s obligation to have obtained the Receiver's direct authorization to credit or debit the Receiver’s account. By contrast, Receiver is defined as the party that has authorized the Originator.

Current language is confusing to some industry participants when analyzing Originator versus Third-Party Sender relationships.

This change would expand the definition to identify the Originator as the party authorized by the Receiver to credit or debit the Receiver’s account at the RDFI.

ODFI and Originator Action on Notification of Change (Article Two, Section 2.12.1)

The Rules currently allow the Originator discretion on whether it will act on NOCs received with respect to ARC, BOC, POP, RCK, single-entry WEB, single-entry TEL, XCK. This list identifies SEC Codes that, by definition, are one-time entries, and those that previously required a single/recurring indicator within the entry.

Current wording of this section is out of date and requires minor modification for clarity and reflection of current business practice.

• Current NOC rules are silent as to whether an Originator has discretion to make NOC changes related to single entries bearing other SEC Codes (e.g., PPD, CCD, CTX, IAT); nevertheless, in practice and in enforcement situations, Originators and Nacha have supported uniform treatment of NOCs for any one-time entries, regardless of SEC Code.
• A previously-required flag to identify certain TEL and WEB entries as single entries is no longer required by the Rules, rendering any perceived difference between single-entry TELs and WEBs and other SEC Codes (PPD, CCD, CTX, or IAT entries) moot.

This change would give Originators discretion to make NOC changes for any Single Entry, regardless of SEC Code.

Security Requirements (Article One, Section 1.6)

Current rules require each non-consumer Originator that is not a participating DFI; each Third-Party Service Provider; and each Third-Party Sender to protect DFI account numbers by rendering them unreadable when stored electronically.

This requirement is threshold-based and begins to apply to non-covered entities once those participants’ annual ACH origination or transmission volume exceeds 2 million entries for the first time.

• The rules include a grace period for newly-covered parties to address implementation issues (must comply by June 30 of the year after triggering the 2 million entry threshold)

As currently worded, the reference to the grace period can be misinterpreted as giving relief from compliance for parties already covered by the rule.

This change would revise wording of this section to separate out compliance obligations for parties already covered by the rule from those meeting the threshold for the first time.

General Rule for Prenotifications (Article Two, Subsection 2.6.1) & Definition of Prenotification Entry (Article Eight, Section 8.81)

The Rules currently allow Originators to transmit prenotification entries for account validation prior to initiating the first credit or debit entry to the Receiver’s account.

Originators indicate a need to re-validate that certain accounts are open and can accept ACH entries, even after live entries have been transmitted (ex: re-validation of inactive or dormant accounts before renewed ACH activity).

• Originators want the ability to use ACH Network-based account validation methods for this purpose.
• In practice, many Originators already use prenotes for re-validation, regardless of language limiting use to prior to the first live entry.
• The recent Rule on Micro-Entries does not limit validation to before first use.

This change would align the prenote rules with industry practice by removing language that limits prenote use to only prior to the first credit or debit entry.

Clarification of Terminology – “Subsequent Entries”

With the adoption of defined terms and rules for Standing Authorization and Subsequent Entries, minor changes are needed to prenote and NOC language to remedy now-ambiguous references to the use of the term “subsequent entry.”

• Exceptions to ODFI Warranties for Entries Originated Using Corrected Data from Notification of Change (Article Two Subsection 2.4.2)
• Waiting Period Following Prenotification Entries (Article Two, Subsection 2.6.2)
• ODFI and Originator Action on Notification of Change (Article Two, Subsection 2.12.1)

This change would replace references to "subsequent entry" in these sections with synonymous terms to avoid any confusion with the now-defined term.