With electronic money transfers, return codes exist to signal that something is wrong with a transaction. Return codes can be frustrating, but there are things you can do to keep your rates of return codes low, infrequent, or better managed.
To help you navigate return rates, this article will go over: what return codes are, common return codes, and best practices for keeping return rates low for NACHA.
What are ACH Return Rates?
In money transfer technology, ACH return codes apply to each ACH bank transfer if applicable. These transactions are known as ACH debits or ACH credits. ACH payments stand for Automated Clearing House (ACH) transfers and they move through the U.S’s automated clearing house and Federal Reserve Bank as a way of approving transactions in the U.S. money market system.
Because of how the system is set up, return codes exist to inform originating and returning banks that the transaction didn’t work or that something else is up. In this case, that means that the ACH Network couldn’t collect funds from the receiver account. The different codes issued suggest what the problem is and these are sent to the Originating Depository Financial Institution (ODFI) from a Receiving Depository Financial Institution (RDFI) or ACH Operator.
Unfortunately, high rates of ACH return codes result in more fees for the lender and customer and can result in a hit to the lender’s reputation. Higher than threshold return rates (for unauthorized and administrative returns) can trigger an inquiry by NACHA. This does not mean that the ACH Operator is fined, but it could result in a fine, or worse. This is why it’s extremely important to stay well below the threshold allowances for return rates.
Monitoring ACH Return Thresholds
The three main types of ACH return categories are unauthorized returns (reason codes R05, R07, R10, R11, R29), overall return rate level, and administrative return rates. Each type isn’t allowed to pass a given threshold.
Note that Sila users need to stay below Sila’s threshold limit:
Return TypeNACHA LimitSila LimitAdministrative Return3%2.50%Unauthorized Return0.50%0.40%Overall Return Rate15%14.00%
ODFIs are required to follow NACHA’s reporting rule to reduce the incidences of return entries, exceptions, and costs of these unauthorized returns. NACHA regularly posts guides on managing return rates and calculating an unauthorized return rate.
Unauthorized return rates include:
- R05 – Unauthorized debit to consumer account using corporate SEC code
- R07 – Authorization revoked by customer
- R10 – Customer advises not authorized
- R29 – Corporate customer advises not authorized
- R51 – Item Related to RCK (Re-Presentation Check Entry) entry is ineligible or RCK entry is improper; The RCK format is used to represent a returned check, through the generation of a single entry ACH debit.
In general, their return rate threshold for unauthorized returns is 0.5% based on:
- The number of debits returned divided by the number of debits originated for the preceding 60 days or two calendar months.
- The number of debits returned for the preceding 60 days or two calendar months divided by the number of debits contained within the files in which the original forward entries were transmitted
Administrative Return Codes
Administrative return rates include:
- R02 – Account closed
- R03 – No Account/unable to locate account
- R04 – Invalid account number
- All payments returned due to the return reasons above divided by the total count of payments will equal the administrative return rate.
A NACHA inquiry is established when Originator or Third-party sender exceeds a rate of 3.0% for administrative returns.
To calculate, the administrative returns:
- Take the number of administrative debit returns or all returns (for overall) divided by the number of debits originated for the preceding 60 days or two calendar months.
- Take the number of administrative debit returns or all returns (for overall) for the preceding 60 days or two calendar months divided by the number of debits contained within the files in which the original forward entries were transmitted
Overall Return Codes
All returned payments divided by the total number of your payments, equal the overall return rate.
The overall return rate cannot be higher than 15%.
NSF Returns have no specific threshold by themselves; however, these returns contribute to the Overall Return rate and make up the largest number of returns, by volume. NSF Returns include R01 and R09.
Reasons for ACH Returns
An ACH return is the equivalent of a bounced check. There are many reasons for returns, but the most common include:
- Insufficient funds (being the most dominant reason)
- A stop payment
- Incorrect account information
So, if the registrant provides the wrong bank account information when issuing an ACH transaction request, payment is returned by the bank.
These mistakes, such as submitting an ACH credit to an account where there are not enough funds, are normal and part of life. While these types of returns are normal, they could also be indicators of fraudulent activity.
OFDIs and ACH Originators don’t want too many ACH returns as this will signal to NACHA that something is going on.
6 Ways to Keep Return Codes Low
While avoiding ACH returns altogether sounds nice, it’s not realistic. Here are recommendations for handling return codes:
1. Require the Linked Account Name to Match KYC Credentials
When a client signs up, they’re required to fill out KYC. If their KYC credentials don’t line up to the names listed on their linked bank accounts, then this could trigger a return code (R03).
While this can become a little cumbersome for the client, especially at the start, they are required to use the name that appears on their government ID and any linked accounts. Requiring this upon the KYC check, and with proper execution, will eliminate the return code altogether because it won’t clear the user to send any money. The check can also be performed upon bank account linking through code or with document verification and manual verification.
2. Auto-freeze for Frozen Accounts, Excess Insufficient Funds Requests (2+ within 30 days), and Fraud
When unchecked, some returns could keep popping up. However, if it is an issue like a frozen account, fraud, or too many insufficient funds requests, these should be stopped so that the issue can be fixed. Include an auto freeze user function with an automated request to fix the appropriate issue, or a manual check. This is especially important for recurring payments.
Insufficient funds requests may require some downtime, where the account remains frozen, to allow time for the account to be funded. Similarly, frozen accounts require that account to be reconnected. Once reconnected, the unfreeze can be issued.
3. Create a Zero-Tolerance for Fraud
Some users may be negatively impacted by fraud-related return codes. However, when it comes to money transfers, it’s better safe than sorry. At each fraud-related return code, create an auto-freeze and manual investigation. Flag accounts that prompt more return codes and more than two fraud requests so that they can be dealt with appropriately.
4. Improve Response Management for Insufficient Funds Requests
ACH debits regularly experiencing insufficient funds should not be allowed to continue. If this request occurs at a certain high frequency within a short period, issue an auto freeze and offer communication via email.
You should request bank account balance data before initiating an ACH debit using the get_balance endpoint and available_balance before notifying the user they have an insufficient balance. Be sure to provide a solution, like funding the account or linking a new account.
Too many insufficient funds return codes could prompt ongoing manual review to avoid the return code.
5. Regularly Prompt for Bank Account Linking
Regularly prompting for bank account linking could reduce return codes associated with unlinked bank accounts. Consider this approach for those accounts that regularly experience linking errors.
6. Improve Email Communication for Insufficient Funds
You can consider providing regular email updates around insufficient funds, as this is the most common return code in NACHA. Provide additional information on why ACH processing may be experiencing hangups, common issues with ACH debit transactions, your NFT fees, and how to avoid these in the future.
Sources for Handling Common ACH Return Codes
Here are some of the best practices for handling returns on your ACH transfers.
You can reference our ACH return code list in our documentation.
Also bookmark our Sila transaction error codes guide.
6 Advantages of Using Payment APIs
Adding payment APIs into your business model is easy with Sila. Read on to learn how.
Outsource your US Financial Compliance with Sila
Financial compliance is tedious and costly, and it’s even worse if you fail it. Outsource your US financial compliance with Sila.
Sending ACH Payments with Sila
With secure solutions like Sila, you can move ACH payments and money internationally faster (and more affordably) than ever before.
Understanding Financial Platforms: Dwolla vs Sila
Dwolla is a financial platform entrepreneurs can use for fintech innovation. Here’s the breakdown of Dwolla vs. Sila.
Using an International Money Transfer API
Sila’s innovative international money transfer API can expedite international payments and open up global financial systems.