NACHA: Request for Comment on Compliance and Operational Topics

​ABA Contact: Steve Kenneally
Published Proposal: See NACHA’s website; August, 15, 2012
Comments Due: September 24, 2012
Disposition: Filed

Summary of the Proposed Rule

The NACHA proposal would make changes in four topic areas at the request of the industry to resolve outstanding challenges to ACH participants. NACHA’s Compliance and Operations Standing Rules Group has reviewed the proposed rule changes. The four challenges addressed by the rule change are proof of authorization for non-consumer debit entries, stop payments, reversals resulting in a Receiver being re-credited twice, and notifications of change for single entries.

Proposed Rule Changes

  1. Proof of Authorization for Non-Consumer Debit Entries

    This amendment would permit an RDFI to request proof of a non-consumer Receiver’s authorization for a CCD or CTX entry, or an Inbound IAT entry; and require that, upon receipt of an RDFI’s written request, the ODFI must provide an accurate record of the Receiver’s authorization to the RDFI within 10 banking days without charge.

    In a related 2010 Request for Information, 68.8% of respondents were in favor of the concept that and RDFI should be able to request proof of authorization. The following Request for Comment (RFC) in 2011 found that a majority of respondents continued to be in favor of allowing the RDFI to request proof of authorization. However, the 2011 RFC contained a prescriptive format requirement for the authorization. This current RFC does not contain that requirement and would allow the ODFI to provide the authorization in whatever form is available.
    Proposed Effective Date: September 2014

  2. Stop Payments

    This proposed amendment would add a new Return Reason Code to be used for the return of entries relating to a stop payment order from the Receiver requesting a to stop on “all future entries;” and limit the use of current R08 (Payment Stopped) to stop payment orders on an individual transaction.

    This proposal follows a 2010 RFI and 2011 RFC on the handling of stop payments. In comments on those proposals, ABA recommended against the creation of a new Return Reason Code and using Return Reason Code R10, Customer Advises Not Authorized as an alternative.

  3. New Dishonor Code to Account Re-credited Twice Due to Reversal, and New Contested Dishonor

    The proposed rule would permit an ODFI to dishonor a return entry relating to an erroneous transaction provided that it can substantiate that it had also originated a reversing entry to correct the erroneous transaction. To support this ability, the rule would define a new dishonored return reason code for use by the Originator/ODFI when the reversal process has resulted in an unintended payment to and enrichment of the Receiver.  The rule would also define a new contested dishonored return reason code for use by the RDFI, when appropriate, in response to such dishonored returns when the RDFI has returned both the erroneous entry and the reversal. The new code is intended to reduce confusion when erroneous transactions are identified and both the Receiver and Originator try to correct the problem resulting in an unfair exchange of funds.

    In response to a 2011 RFC, ABA noted that it was not clear that these situations happened often enough to justify creating a new Return Reason Code. ABA asked NACHA to provide information the prevalence of these transactions in order to conduct an economic analysis of the proposed change.

  4. Notifications of Change for Single-Entries

    This proposed rule change would revise the Rules to make optional the Originator response to Notification of Change (NOCs) for Single Entry payments. The proposed rule change would not disallow an RDFI’s initiation of an NOC for a Single Entry, nor would it mandate the Originator make the changes provided in such NOCs. The following SEC codes would be affected by this proposal: ARC, BOC, POP, POS, RCK, and XCK entries, as well as, TEL and WEB entries bearing a single entry indicator (“S” or “blank” for TEL and “S” for WEB).

    In response to a 2011 RFI, ABA favored this position as it related to NOCs affecting Single-Entries. ABA favored allowing the RDFI to initiate the NOC, but would not require the Originator to respond.