Clarification on SEC Code Flexibility and Subsequent Entries Initiated at Electronic Terminals 

This will clarify that Subsequent Entries initiated at an “electronic terminal” (as that term is defined in Regulation E) must be identified using the Point-of-Sale (POS), Machine Transfer Entry (MTE), or Shared Network Entry (SHR) Standard Entry Class Code, as applicable, regardless of the manner in which the Standing Authorization for the Subsequent Entry was obtained.

• The POS, MTE, or SHR format is required in order to convey information to identify the location of the terminal 

• This change adds an additional exception to the new rules for SEC Code flexibility for Subsequent Entries.

RDFI Subsequent Request for Proof Of Authorization Must Be In Writing

This will clarify that, where an ODFI has accepted, or has agreed to accept, a Return Entry in lieu of providing the RDFI with proof of authorization, and the RDFI still subsequently requests proof of the Receiver’s authorization, the RDFI must make any subsequent request to the ODFI in writing.

Stop Payment Rules for Subsequent Entries

This will clarify an RDFI’s obligation with respect to stop payments for Subsequent Entries

• Requires an RDFI to honor a stop payment order on a Subsequent Entry that is provided by a Receiver to the RDFI in such time and manner that the RDFI has a reasonable opportunity to act on the stop payment order prior to acting on the Subsequent Entry

Other Clarifications on Subsequent Entries 

These will pull through references to the defined term Subsequent Entry in two additional places in the Rules:

Form of Receiver Authorization – Debit Entries to Consumer Accounts (Article Two, Subsection 2.3.2.2(a)

• Fine tunes existing language that requires an Originator to specify whether the authorization relates to a Single Entry, multiple Entries, or Recurring Entries

• Replaces the reference to “multiple Entries” with “Subsequent Entries initiated under the terms of a Standing Authorization”

General Rule for Prearranged Payment and Deposit (PPD) Entry (Article Two, Subsection 2.5.12)

• Aligns the description of a PPD entry within the General Rule with the updated definition of PPD in Article Eight

Other Clarifications on Subsequent Entries (continued)

This revises language within 2.5.15.2 and 2.5.17.2 to clarify how provisions related to routing number verification, annual security audits, and specific authorization requirements apply to TEL and WEB Subsequent Entries.  

Expiration of Stop Payment Order on Entries to Non-Consumer Accounts

This will clarify that the rules on the effective period for a stop payment order on a debit Entry to a Non-Consumer Account reflect the minimum time period that such a stop order will remain in effect.

• Expands the rule to make clear that an RDFI may establish a longer effective period for a stop payment on an entry to a Non- Consumer Account, at its discretion; this change also removes the requirement that a renewal of a stop order must be in writing, allowing the RDFI discretion to determine how it will accept a renewal notice from its customer

• Current wording is occasionally mis-interpreted as the maximum time permissible for a stop order to remain in effect and has resulted in audit findings against some RDFIs that leave stop orders in place for a longer period.

ACH Operator Edits – Effective Entry Date

This will revise the field description as it relates to Return Entries for clarity and to align the Rules language with current ACH Operator file editing practices.

Modifies the description of Effective Entry Date (as it relates to Return Entries) within Appendix Three to clarify that ACH Operators:

• Use the content of the Effective Entry Date field (as copied from the original Entry) to determine the appropriate Settlement Date for a Return Entry, dishonored Return Entry, and contested dishonored Return Entry

• May choose to verify proper formatting of the Effective Entry Date field and, potentially, replace an invalid Effective Entry Date with the current processing date

• Do not reject a Return Entry, dishonored Return Entry, or contested dishonored Return Entry because of an invalid date in the Effective Entry Date field