The ACH Network is a powerful option for financial transactions with $43 trillion moving across it each year. However, payments that appear ready to join the 24 billion transactions the ACH Network handles annually can be returned days or even months after they were initiated. Why?
The ACH Network supports the ability to return entries for specific reasons.
A transaction that was not properly authorized or has inaccurate information can be defined as an ACH return. The ACH return process allows participants in the ACH Network to not accept an entry and to return that entry to the Originator, through the ACH Network.
The Difference Between Returns, Disputes and Chargebacks
ACH returns are sometimes referred to as “ACH disputes” or “ACH chargebacks” but while those terms might seem like synonyms, they are crucially different. “Disputes” and “chargebacks” are terms heavily used in the credit card space and imply that there is a third-party arbiter looking at evidence from all parties to a transaction and determining a fair outcome.
That does not happen during the ACH return process.
An ACH payment is not “disputed,” which hints that it may be resolved, nor is it “charged back,” it is simply returned.
Here’s how it works:
The ODFI (Originating Depository Financial Institution) issues a debit or credit entry to the ACH Network. The RDFI (Receiving Depository Financial Institution) receives that entry and moves funds to or from the appropriate account. In most cases the RDFI then has 2 days in which to issue an applicable return code but in some cases the RDFI has as many as 60 days for certain return codes related to unauthorized activity. The ODFI receives these return codes and funds are sent back to the RDFI.
ACH returns can only be initiated from two sources, the ACH Operator or RDFI.
Codes of All Kinds
- RO1 – Insufficient funds; the available cash reserve balance is not sufficient to cover the dollar value of the debit entry.
- RO2 – Account closed; A previously active account has been closed by the RDFI or customer.
- RO3 – No account/unable to locate account; the account number structure is valid and it passes the check digit validation, but the account number does not correspond to the individual identified in the entry or the account number designated is not an open account.
- RO4 – Invalid account number; the account number structure is not valid. The entry may fail the check digit validation or may contain an incorrect number of digits.
- RO5 – Unauthorized debit to consumer account using corporate SEC code; A business debit entry was transmitted to a member’s consumer account and the receiving member had not authorized the entry.
- R29 – Corporate customer advises not authorized; the RDFI has been notified by receiver (non-consumer) that a specific transaction is unauthorized.
Read more about ACH return codes here.
Best Practices to Avoid ACH Return Codes
Additional integrations can help decrease the likelihood your users or business will receive an ACH return code.
Businesses can take advantage of additional integrations within the Dwolla Platform to decrease the chance of ACH return codes. Leveraging bank account verification or balance checks can help with the RO1 return code by doing balance checks to make sure enough funding is available for a transaction.
A Sift integration can tell you session data about the person interacting with your site as another layer of fraud prevention. The Sift integration—through the Dwolla Platform—can help identify bad actors and prevent these bad actors from initiating unauthorized debit transactions.
Simple techniques also include having a user enter in their bank account number twice, to avoid “fat fingering” when a user inputs their banking information.
The Dwolla Platform offers a suite of solutions for problems businesses face when trying to move money through their application.