Area

Change

Reference(s)

Codifying the Expanded Use of Return Reason Code R17

Adds a new section to define False Pretenses and expands the use of the Return Code R17 for Receiving Depository Financial Institutions (RDFIs) and aims to give the RDFI the ability to put a spotlight on entries believed to have been initiated under questionable circumstances. R17 is already in use for entries received by the RDFI with an invalid account number. With this change, if the RDFI also believes the entry has been initiated under questionable circumstances, the RDFI may now return the entry “QUESTIONABLE” in the addenda. This is intended to differentiate these returns from those believed to be routine input errors and alerts the Originating Depository Financial Institution (ODFI) of the suspicion.

Article Eight, Section 8.42 (“False Pretenses”)

Appendix Three, Subpart 3.2.2 (Glossary of Data Elements – Addenda Information)

Appendix Four, Part 4.2 (Table of Return Reason Codes)

Expanding the Use of ODFI Return Reason Code R06

Updates the language for Return Code R06 to allow an ODFI to request a return from the RDFI for any reason. The RDFI is still not required to return the requested entry; however, they will now be required to communicate their decision to the ODFI within 10 banking days of receipt of the request.

Article Two, Subsection 2.10.1 (General Rule for Reversing Entries)

Article Two, Subsection 2.13.2 (ODFI Request for Return)

Article Two, Subsection 2.13.3 (Indemnification by ODFI for Requested Returns) – Updated to remove restrictive language for entries qualified as reasons to request a return.

Article Two, Subsection 2.13.6.1 (Dishonor of Return by ODFI) – Updated to remove reference to erroneous entry under list of qualified reasons to dishonor a return.

Article Three Subsection 3.8.6 (Response to ODFI Request for Return) – New subsection adding the requirement for the RDFI to advise the ODFI of its decision or the status of the ODFI’s request.

Appendix Four, Part 4.2 (Table of Return Reason Codes)

Funds Availability Exceptions

Currently, an RDFI may be exempt from the Funds Availability requirement if the RDFI reasonably suspects an entry was unauthorized. This change adds specific wording that an RDFI may also be exempt from the Funds Availability requirement if the RDFI suspects the entry was originated under False Pretenses.

Article Three, Subsection 3.3.1 (General Rules for Availability of Credit Entries to Receivers).

Article Eight, Section 8.42 (False Pretenses)

Timing of Written Statement of Unauthorized Debit (WSUD)

Change to allow the Receiver to sign and date a WSUD for an unauthorized transaction as soon as the entry is presented to the Receiver, even if the debit has not posted to the account.

Article Three, Subsection 3.12.4 (Form of Written Statement of Unauthorized Debit)

RDFI Timing for Returning Unauthorized Debits

The current Rules address when an RDFI must transmit an extended return entry for which it recredits a Receiver’s account; however, it does not mention a timeframe for returning unauthorized debits when the RDFI receives a WSUD. This Rule change establishes that when an RDFI receives a WSUD, they must return the entry no later than six business days following the completion of their review of the WSUD, and within 60 calendar days of the original settlement date of the entry.

Article Three, Subsection 3.13.1 (RDFI May Transmit Extended Return Entries)

Effective Date(s)

Area

Change

Reference(s)

March 20, 2026, early adoption allowed

Company Entry Descriptions

Adds “PAYROLL” and “PURCHASE” as new descriptions available for use in the 10-character field for ODFIs to describe a payment and also specifies when it is required to use each.

Appendix Three, Subsection 3.2.2 (Glossary of Data Elements)

March 20, 2026 (if ACH volume over 6 million entries in 2023)

June 19, 2026 for all others

Fraud Monitoring by Originators, Third-Party Service Providers/Third-Party Senders, and ODFIs *

Requires each non-consumer Originator, ODFI, Third-Party Service Provider, and Third-Party Sender to establish risk-based processes and procedures to reasonably identify ACH entries initiated due to fraud. These processes need to be reviewed at least annually to evaluate evolving risks.

Article Two, Subsection 2.2.4 (Identification of Unauthorized Entries or Entries Authorized Under False Pretenses)

March 20, 2026 (for RDFIs with ACH receipt volume over 10 million entries in 2023);

June 19, 2026 for all other RDFIs

RDFI ACH Credit Monitoring

This new Rule mirrors the Fraud Monitoring by Originators, Third-Party Service Providers/Third-Party Senders, and ODFIs Rule. It requires RDFIs to establish risk-based processes and procedures to reasonably identify credit ACH entries initiated due to fraud. These processes will need to be reviewed at least annually to evaluate evolving risks.

Article Three, Subsection 3.1.10 (Identification of Unauthorized Credit Entries or Credit Entries Authorized Under False Pretenses)

Area

Change

Reference(s)

General Rule/Definition of WEB Entries

Reworded the previous definition of WEB Entry to clarify that the SEC Code must be used for all consumer-to-consumer credits, regardless of how the transaction was communicated

Article 2, Subsection 2.5.17.1 (General Rules for WEB Entries); Article 8, Section 8.55 (“Internet-Initiated/Mobile Entry”); Appendix 3, Subpart 3.2.2 (Glossary of Data Elements)

Definition of Originator

Clarified the previous definition of Originator to add a reference to the Originator’s authority to credit or debit the Receiver’s account, including a notation that the Rules do not always require a Receiver’s authorization

Article Eight, Section 8.71 (“Originator”)

Originator Action on Notification of Change (NOC)

Allows Originators to act on NOCs received for any single entry regardless of SEC Code

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

Data Security Requirements

Clarified that once an Originator’s originator or volume transmission exceeds the annual two million entry threshold, it will always be subject to the Data Security Requirements in future years even if volume drops below the threshold

Article One, Section 1.6 (Security Requirements)

Use of Prenotification Entries

Allows Originators to transmit Prenotification Entries even after live entries have been transmitted

Article Two, Subsection 2.6.1 (General Rule for Prenotifications); Article Eight, Section 8.81 (“Prenotification Entry” or “Prenotification” or “Prenote”)

Clarification of Terminology – Subsequent Entries

Removes the term “Subsequent Entry” and replace it with clearer terms such as “future,” “additional,” or “another”

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