Connect ► twitter| youtube|  Log In ► Members Only  |  Corporate One Safekeeping  |  Search

Are you ready for new ACH Rules coming in 2015?

By: Jennifer L. Kirk, AAP, EPCOR

January 21, 2015 -- The new year is in full swing and your financial institution could be left behind if it isn’t prepared for the new ACH Rules. More importantly, many of these new Rules may pack a hefty punch to those who aren’t complying.

Here’s a high-level overview of the most significant ACH Rules changes for 2015.

Understanding the unauthorized entry fee

To rid itself of unauthorized entries, the ACH Network plans to fine ODFIs who send those unauthorized entries. Simply put, for every ACH transaction returned as R05, R07, R10, R29 or R51, the ODFI will incur a fee ranging from $3.50 - $5.50. Presumably, the ODFI would then pass the fee off to its originator who sent the original transaction.

This rule provides an economic incentive to ODFIs to improve the quality of the ACH transactions its originators send into the network. Fees begin on October 3, 2016, for entries originated as early as August 1, 2016.

On the other side of the transaction, RDFIs will begin to see a refund in the amount of $3.50 - $5.50 for every return using the return-reason codes R05, R07, R10, R29 and R51. This refund to the RDFI partially compensates for the costs imposed when preparing and sending the ACH return.

Lowering the unauthorized return rate threshold

Another way NACHA (The Electronic Payments Association) plans to eliminate as much unauthorized activity as possible is by lowering the thresholds of unauthorized activity allowed by originators. Effective September 18, 2015, the unauthorized threshold per originator will be reduced from 1% to .5%. (And keep in mind that the current overall return rate for unauthorized transactions is .03%.)

Similar to the current Rules, when an originator exceeds the unauthorized threshold, NACHA will contact the ODFI and require the implementation of a plan to reduce the unauthorized return rate below the threshold for at least 180 days.

Examining administrative return levels

If an originator exceeds a return rate of 3% for administrative or account data error returns (R02, R03, R04), NACHA, through an industry review panel, will have the ability to begin an 8-step review process of that originator. Through this 8-step review process, NACHA will determine whether poor origination processes are to blame for excessive returns. This review process will begin September 18, 2015.

While a review will not automatically prompt rules-enforcement proceedings, the panel can require the ODFI to reduce the originator’s return level if it is determined that the originator is causing harm to the network.

Reviewing the overall return rate level

Along with an administrative return level, NACHA has also implemented an overall return rate level of 15%. Through the same 8-step process mentioned previously, NACHA will review any originator receiving more than 15% of their forward entries as returns. This will include returns for ALL return reason codes, such as NSF, stop payment, administrative returns and unauthorized returns.

The only standard entry class code exempt from this review is RCK, since the entry is being represented from a previously returned NSF item. As with the administrative return level, no automatic rules-enforcement proceedings will take place; however, the review panel has the ability to take action if the originator is, in fact, causing harm to the ACH Network. This review process becomes effective September 18, 2015.

Introducing “Unintended Credit to a Receiver”

If an originator sends an erroneous or duplicate entry (or file) into the ACH Network, the ACH Rules allow that originator to send an ACH reversal to correct the error. But what happens when the RDFI returns the erroneous entry as NSF at the same time the originator sends the reversing entry? Many times a reversal ends up as an “Unintended Credit to Receiver” (a phrase coined by NACHA).

To correct these situations in an automated environment, effective March 20, 2015, NACHA will introduce a new dishonored return code (R62) to allow the ODFI to dishonor a return for which it has already sent a reversal.

The following is a sample scenario:

Let’s say that Company X sends an ACH credit entry for $1000, but it was only supposed to send $100. To fix the problem, Company X sends a debit entry for $1000 to reverse the money sent in error (also sending a correcting entry of a $100 credit to make the receiver whole).

But in this situation, the receiver doesn’t have the $1000 in their account when the reversal hits, causing the RDFI to return the reversal as NSF. At this point, the receiver has received the erroneous $1000 credit AND the $100 correcting credit. The ODFI could dishonor the $1000 NSF return as R62, stating that the receiver has received an unintended credit to their account.

But as part of this rule, NACHA has also introduced a new contested dishonored return code (R77). So, if the money was still not in the receiver’s account when the RDFI received the dishonored return, the RDFI could contest the dishonored return, stating they were unable to recover the funds from the receiver.

Switching P2P payments to Web credits

On March 21, 2014, use of the WEB standard entry class code expanded allowing both credits and debits (instead of just debits only). While the debit Rules did not change, ODFIs could use the WEB credit standard entry class code to send a credit from one individual’s account to another person’s account (better known as a person-to-person, or P2P, payment). While ODFIs were permitted to send WEB credits as early as March 21, 2014, the mandatory compliance date to switch all P2P payments to the WEB credit standard entry class code is March 21, 2015.

The WEB credit standard entry class code is to be used for all P2P payments, regardless of how the authorization is obtained. Since most P2P payments are authorized on the Internet or a mobile device, the WEB credit standard entry class code was determined as the most reasonable code to use. The WEB credit can also be used in account-to-account transfers between financial institutions where the consumer on the originating side is also the consumer on the receiving side of the transaction.

As a result of this new rule, RDFIs must make mandatory changes to their account statements. Since most P2P services use a service provider to facilitate the payment, the service provider’s name will most likely appear in the “Company Name” field of the “Company Batch Header” record. The Individual sending the credit will be identified in the “Individual ID” field of the “Entry Detail Record.” This means RDFIs are required to post both the “Company Name” and “Individual ID” fields to the consumer’s statement for WEB credit entries. But since the “Individual Name” field in many other standard entry class codes contains private information (such as social security numbers), it is recommended that RDFIs post the “Individual ID” field to consumer statements for WEB credit transactions only.

It is also worth mentioning that only P2P payments should be transmitted through the ACH network as WEB credit transactions. The WEB credit standard entry class code is not intended for merchandise returns or corporate credit payments through the Internet.

Additional ACH Rules changes

  • POS Entries (Effective January 1, 2015)
  • Return Fee Formatting Requirements (Effective January 1, 2015)
  • Entry Detail Record for Returns (POP) (Effective January 1, 2015)
  • RDFI Obligation to Re-credit Receiver (Effective January 1, 2015)
  • Pre-note Clarification (Effective January 1, 2015)
  • Audit Clarification (Applicable in 2014 Audit)
  • P2P Company ID Clarification (Effective January 1, 2015)
  • Removal of Change Code C04 (Effective March 20, 2015)
  • ACH Operator Edit for Returns (Effective September 18, 2015)

Want to learn more? You may visit your regional payments association for additional learning opportunities. EPCOR annually hosts a seminar to help financial institutions understand their new compliance obligations as dictated by new payment systems rules and regulations. Visit to register for one of our 50+ Payment Systems Update classes in your area February - March.