The ACH Network serves as a reliable system for businesses to facilitate digital bank transfers seamlessly. It plays a vital role in supporting payment operations as businesses strive to scale.
Returns and Reversals are two prominent aspects associated with ACH and the ACH Network. Returns occur when a business mistakenly sends a payment to the wrong account or when a customer fails to authorize the payment. On the other hand, Reversals happen when customers request their banks to cancel payments they have already made.
Given that ACH Returns and Reversals are commonplace in Account-to-Account (A2A) payments, businesses must familiarize themselves with the applicable rules. Despite implementing multiple safeguards, the potential for errors, unavailability of funds, or account closures without prior knowledge remains. By understanding these key aspects of ACH payments, businesses can effectively navigate such scenarios and safeguard against potential financial losses.
What is ACH?
ACH stands for the Automated Clearing House network, which manages billions of electronic monetary transactions yearly throughout its network of financial institutions—supporting both ACH credit and debit payments in the United States. The National Automated Clearing House Association (NACHA) governs this network, setting its rules and regulations.
ACH Participants
As a high level overview, there are five main participants involved in an ACH transaction:
- Originator: Submits transfer instructions to ODFI.
- Originating Depository Financial Institution (ODFI): Receives the payment instructions and then transmits the ACH Entries to the ACH Operator.
- ACH Operator: The central facility for the clearing, delivery and settlement of entries between or among participating Financial Institutions.
- Receiving Depository Financial Institution (RDFI): Receives ACH Entries from the ACH Operator and posts the Entries to the accounts of its depositors (Receivers).
- Receiver: Individual or business whose account is receiving the credit or debit who has authorized an Originator to initiate an ACH entry to the Receiver’s account held at the RDFI.
ACH Returns
An ACH Return is a communication that indicates why the Entry could not be completed as intended. Typically, an ACH Return comes from the RDFI, but in some instances the ODFI or even the ACH Operator might send such a message. ACH Returns must be sent within time frames established by Nacha operating rules.
ACH Returns are not unusual in ACH processing and standard practices exist to manage them efficiently. As mentioned earlier, the reason for returns are communicated as a message to the Participant receiving the return. These are called return codes and they consist of an R followed by two numeric digits (i.e., R01).
There are around 70 unique return codes, don’t worry, you don’t have to know them all. Return codes come for a myriad of reasons dependent on several factors. Some of the considerations would be if the transaction is a Debit or Credit, the type of account it settles (posts) to, if there are funds available for withdrawal or if the information in the ACH file that transmitted the Entry was incorrect. Each return code follows a specific set of Rules that include a time frame for which the return can happen.
Back to Top
Common ACH Return Codes
Reason for Return | Return Code | Description | Entry Type | Time Frame |
---|---|---|---|---|
Insufficient Funds | R01 | Available balance is not sufficient to cover the dollar value of the debit entry. | ALL | 2 banking days |
Account Closed | R02 | Previously active account has been closed. | ALL | 2 banking days |
No Account / Unable to Locate Account | R03 | The account number structure is valid, but doesn’t correspond to the individual identified in the Entry or the account number designated is not an existing account. | ALL | 2 banking days |
Invalid Account Number | R04 | The account number structure is not valid. | ALL | 2 banking days |
Unauthorized Debit to Consumer Account Using Corporate SEC Code | R05 | A debit entry was transmitted to a consumer account that was not authorized by the Receiver. Written Statement of Unauthorized Debit is required. |
CCD, CTX (consumer only) | 60 calendar days |
Authorization Revoked by Customer | R07 | Consumer who previously authorized entries has revoked authorization with the Originator. Written Statement is required. |
PPD, TEL and WEB | 60 calendar days |
Payment Stopped | R08 | The Receiver has requested the stop payment of a specific ACH debit entry. | ALL | 2 banking days |
Uncollected Funds | R09 | A sufficient balance exists to satisfy the dollar amount of the transaction, but the available balance is below the dollar value of the debit entry. | ALL | 2 banking days |
Customer Advises Originator is Not Known to Receiver and/or Originator is Not Authorized by Receiver to Debit Receiver’s Account | R10 | The RDFI has been notified by the Receiver that the Receiver does not know the identity of the Originator; has no relationship with the Originator; or has not authorized the Originator to debit their account. Written Statement is required. |
ALL DEBIT ENTRIES (except CCD, CTX and RCK) | 60 calendar days |
Customer Advises Entry Not in Accordance with the Terms of the Authorization | R11 | The RDFI has been notified by their Receiver that a relationship with the Originator does exist, however, the Entry was not in the amount or on the date that was authorized. Written statement is required. |
ALL DEBIT ENTRIES (except CCD, CTX and RCK) | 60 calendar days |
Account Frozen / Entry Returned per OFAC Instruction | R16 |
Access to the account is restricted due to specific action taken by the RDFI or by legal action. OFAC has instructed the RDFI or Gateway to return the the Entry. |
ALL | 2 banking days |
Non-Transaction Account | R20 | ACH Entry to a non-Transaction Account. | ALL | 2 banking days |
Corporate Customer Advises Not Authorized | R29 | The RDFI has been notified by the Receiver (Non-Consumer) that a specific Entry has not been authorized by the Receiver. | CCD, CTX | 2 banking days |
*Clarification on the 2 banking day return time frame. The true return period is by opening of business on the 2nd banking day following settlement.
**Clarification on the 60 calendar day return time frame. The true return period is by opening of business on the 60th calendar day following settlement.
Entry Types and Time Frames for Return
Another way to classify ACH transactions is by a Standard Entry Class (SEC) Code. This is a three-letter code that enables a Financial Institution (FI) to identify the purpose of a transaction. Dwolla processes transactions with one of the following three SEC Codes:
- WEB (Internet Initiated/Mobile Entries): A Credit or Debit entry initiated online or via mobile device to a consumer’s account.
- CCD (Corporate Credit or Debit Entries): A Credit or Debit entry used to facilitate business-to-business payments.
- PPD (Prearranged Payment and Deposit Entries): A Credit or Debit entry originated by an organization to a consumer’s account, based on a standing or single entry authorization.
As you can see, some of the return codes apply to all SEC codes, while others are specific to certain types.
Time Frame for Returns
The typical time frame for an RDFI to return a transaction is two banking days. Certain situations (such as unauthorized transactions) allow for an extended time frame of 60 calendar days for the RDFI to initiate a return when the transaction involves a consumer account.
Back to Top
Proof of Authorization to Debit
Returns must follow the time frame as set forth in the Rules & Regulations by Nacha. There are instances though, that an extended return outside of the permissible window may be requested. This brings us to the request for Proof of Authorization/Permission to Return, these requests may be made for up to 2 years from the settlement date of the original debit transaction. Therefore, the Originator has the responsibility to retain all appropriate documentation showing authorization to debit. Dwolla works with our clients to ensure that these obligations are met.
Typically, we see a request for Proof of Authorization when the Receiver (Consumer or Business) goes to their bank and declares that one (or more) transaction(s) is unauthorized. The RDFI may request sufficient proof from the Originator that the Entries in dispute were valid.
If the provided proof of authorization does not meet the Nacha Rules and Guidelines, the ODFI may be required to permit the RDFI to return the transaction. An authorization must include the full name of the Receiver, match the individual’s name authorized on the bank account and:
- Be readily identifiable as an authorization.
- Have clear and readily understandable terms.
ACH Return Penalty
When an ACH transaction is returned, it means that the transaction cannot be processed successfully, and it is sent back to the originator. Yes, there are penalties for having ACH transactions returned, as Nacha rules require that each Originator maintain a percentage of ACH debit returns under specific thresholds:
Administrative Returns must stay below 3%. This percentage is calculated based on ACH debit returns for the preceding 60 days on the following return reason codes: R02, R03 and R04.
Unauthorized Returns must stay below 0.5%. This percentage is calculated based on ACH debit returns for the preceding 60 days on the following return reason codes: R05, R07, R10, R11, R29 and R51.
Overall Returns must stay below 15%. This percentage is calculated based on ACH debit returns for the preceding 60 days and includes all return reason codes. This includes NSF (non-sufficient funds) returns.
The specific penalties and fees depend on the policies of the financial institution and the reason for the return.
Back to Top
Dishonoring ACH Returns
Dwolla can request the ODFI send back (or dishonor) a return if it is:
- Untimely (not within the proper time frames for return)
- Contained incorrect information
- Misrouted
- Duplicated
- Resulted in an unintended credit to the Receiver related to the reversal process.
A dishonored return must be transmitted within five banking days of the settlement date of the return. Please be aware that the RDFI is able to contest a dishonored return, in which case recovery of the funds would need to happen outside of the ACH Network.
Back to Top
ACH Reversals
Dwolla can also request our ODFI send a reversing entry to attempt to reverse an erroneous or duplicate file. The following ACH transfers qualify as an erroneous entry:
- A duplicate of an entry previously initiated by the Originator.
- Payment to or from a Receiver different than the Receiver intended to be credited or debited by the Originator.
- Payment in an amount different than was intended by the Originator.
- Orders payment of a debit entry on a date earlier than the Receiver was intended to be debited by the Originator, or payment of a credit entry on a date later than the Receiver was intended to be credited by the Originator.
- A PPD credit entry satisfying each of the following criteria:
- The PPD credit is for funds related to a Receiver’s employment.
- The value of the PPD credit is fully included in the amount of a check delivered to the same Receiver at or prior to the Receiver’s separation from employment.
- The PPD credit entry was transmitted prior to the delivery of the check to the Receiver.
Reversing entries must be transmitted to or made available to the RDFI within five banking days following the settlement date of the erroneous entry. Eligible entries for reversals must clearly fit into the categories outlined above, claims of fraud are not eligible.
It’s important to note that ACH reversals are not a guarantee that funds will be returned because the funds may have already been withdrawn. Once a reversal request has been sent, the RDFI has two banking days from the settlement date to return the entry.
Back to Top
Preventing ACH Returns and Reversals
Return codes can happen regardless of the number of safeguards in place. Depending on the type of returns you are receiving, there are several best practices you can implement to help lower returns, prevent losses due to returns and eliminate the need for reversals.
- Monitor for excessive returns by end users within your platform.
- Have a fraud monitoring/prevention process in place to combat unauthorized returns and malicious users.
- Establish transaction limits and tiered onboarding for users (ex: customers onboard for less than 30 days, repeat NSF offenders, low transaction volume).
- Give your end users the option to cancel a transaction within a set time frame. This can help prevent them from submitting a payment they didn’t intend to and then disputing it as unauthorized.
- Conduct balance checks and use name returns when verifying bank accounts to ensure your user’s name matches the account holder’s and there are funds in the account.
- Monitor IP address usage. An end user signing in from a new IP or multiple IP addresses at the same time could indicate fraud.
- Build out your own robust CIP/KYC. Onboarding with additional information from your end users can help you understand who they are and what they’re trying to do. Asking for additional documentation such as bank statements and photo IDs can help ensure the person who signed up on your platform is who they say they are.
Navigating the intricacies of the ACH Network can be time-consuming, but partnering with experts can bring undeniable value to businesses. While the responsibility of managing ACH Return or Reversal lies with the business, Dwolla's payment technology streamlines many aspects of the returns and reversals process. So, although you don't have to become an expert on returns and reversals, learning how your team can leverage the tools provided in the dashboard will simplify your team's experience. Embrace the power of automation and optimize your operations.