The Nacha ACH return reason taxonomy — and why it matters for retry logic
Nacha provides a return reason code for every failed ACH debit. The codes are not all the same — and treating them all identically with a single retry schedule wastes retries on accounts where a retry will certainly fail, and fails to use the right resolution path for each bounce type. A return code R01 (insufficient funds) is resolved by waiting for the borrower's next salary credit and retrying. A return code R29 (do not honour) is a broad decline that may indicate a fraud flag on the account — retrying immediately will fail again and may create additional bank charges for the borrower. A return code R02 (account closed) cannot be retried on this account at all — the mandate needs to be modified to the new account number. Each return reason requires a different response.
The return reason codes and the Repayment AI's response to each
| Nacha Code | Reason | Frequency | Repayment AI Response | Retry? |
|---|---|---|---|---|
| 01 | Insufficient funds | Most common · ~55% of all bounces | WhatsApp + SMS notification to borrower · Retry on Day 3 (after typical salary date) · Second retry on Day 7 if first fails | Yes · Day 3 + Day 7 |
| 02 | Account frozen / dormant | ~8% | Borrower notified to activate account · Retry on Day 5 · If second failure: escalate to tele-collections for alternate payment method | Yes · Day 5 only |
| 05 | Do not honour (generic decline) | ~12% | No immediate retry · Borrower contacted for explanation · Tele-collections team assigned Day 2 · Retry only after borrower confirms account issue resolved | After confirmation only |
| 10 | Account closed | ~6% | No retry on this account · Borrower contacted to provide new account details · Mandate modification request submitted once new account verified · Bridge payment via ACH / Zelle requested immediately | No retry · Mandate modification |
| 11 | Account number incorrect / invalid | ~3% | Mandate data review triggered · If routing number changed (bank merger or branch migration): auto-update routing number and retry · If account number wrong: contact borrower for correction · Mandate modification required | After correction only |
| 17 | Debit not permitted by user (borrower instructed bank to block debit) | ~5% | Escalate immediately — borrower has actively blocked the mandate · Tele-collections priority contact Day 1 · Legal team notified if pattern repeats · No retry until mandate reinstated | No retry · Legal alert |
| 21 | Technical failure (bank or ACH network issue) | ~8% | Automatic retry next working day · No borrower notification required (technical failure, not borrower issue) · If second attempt also fails with code 21: ODFI / sponsor bank support ticket raised | Auto-retry next day |
| 25 | Mandate not registered / ACH trace number invalid | ~3% | Mandate status check triggered · If mandate pending: collection via bridge method, retry once mandate activates · If mandate cancelled: new mandate registration initiated | After mandate check |
The bounce resolution sequence: 7-day playbook for code R01 (insufficient funds)
Nov 5
Bounce received and classified — WhatsApp and SMS notifications sent
Nacha return code R01 received at 14:32. monthly payment marked as unpaid in CBS. Penal charge $500 accrued per the loan agreement. Borrower notified immediately via WhatsApp: "Your monthly payment of $9,200 due on November 5 could not be debited from your account — it looks like the account balance may have been insufficient. We'll try again in a few days. If you'd like to pay now, tap here: [ACH / Zelle link]." SMS sent as backup.
→ Notification: WhatsApp + SMS · ACH / Zelle self-payment link provided · DPD clock starts Day 1Nov 6–7
Self-payment window — borrower can pay via ACH / Zelle link · No collection call yet
For code R01, the first 48 hours are a self-resolution window. Many borrowers pay voluntarily via the ACH / Zelle link before any tele-collection is made — salary credits typically arrive in the first few days of the month for salaried borrowers. The Repayment Agent AI monitors for any incoming ACH / Zelle credit against this loan account. If payment received: monthly payment marked paid, penal waiver assessed per the institution's policy (first bounce = penal waived on same-month payment), DPD counter reset.
→ 28% of code R01 bounces self-resolve in this 48-hour window via ACH / ZelleNov 8
Retry 1 submitted — Day 3 after bounce, after typical salary credit window
Day 3 is the optimal first retry date for code R01 bounces: most salaried borrowers have received their November salary by this point, and the account balance is most likely to be sufficient. The Repayment Agent AI submits the ACH debit presentation for $9,200 (the monthly payment only — penal charge is not included in the ACH debit; it is accrued separately and collected in the next monthly payment or on prepayment). A "heads up" WhatsApp is sent the previous evening: "We'll try your monthly payment again tomorrow — please ensure your account has $9,200 available."
→ 54% of code R01 retries succeed on Day 3 · Pre-debit WhatsApp sent Day 2 eveningNov 9–10
If Retry 1 succeeds: monthly payment posted, DPD reset. If fails: tele-collections assigned, Retry 2 scheduled.
If Retry 1 succeeds: monthly payment posted to CBS, DPD counter reset, penal charge waived per first-bounce policy (if account is in good standing). Case closed. If Retry 1 fails with code R01 again: the borrower's account does not have funds on Day 3. Tele-collections is assigned the case with the bounce history. A tele-collections call is made to understand when funds will be available. Retry 2 is scheduled for Day 7 (or for the date the borrower commits to having funds available, whichever is earlier).
→ Retry 1 fail: tele-collections assigned · Borrower call Day 4 · Retry 2 scheduled per borrower commitmentNov 12
Retry 2 — final ACH retry · If fails, alternate payment method required
Retry 2 is the final automated ACH retry for a code R01 bounce. If Retry 2 also fails, the ACH track for this month's monthly payment is exhausted. The Repayment Agent AI triggers the Early Bucket Caller AI: the account enters the DPD 7 bucket with two failed ACH attempts and one unsuccessful tele-collections call. The Early Bucket Caller initiates the standard early-bucket contact sequence, with the outstanding monthly payment + penal charge flagged as the priority collection target.
→ Retry 2 fail: case passed to Early Bucket Caller AI · DPD 7 · Two ACH failures logged · Penal: $500 accruedEscalation
Early Bucket Caller takes over — ACH suspended until borrower confirms account availability
From Day 8, the repayment track shifts from automated ACH collection to the collections AI agents. A third ACH debit attempt is not made until the borrower explicitly confirms (via a call or WhatsApp response) that their account has sufficient funds. An unsolicited third retry that fails would add unnecessary bounce charges, worsen the borrower relationship, and provide no collection benefit. The Repayment Agent AI suspends further ACH presentations until the Early Bucket team secures a specific payment commitment.
→ No further ACH until borrower commitment confirmed · Early Bucket Caller owns the case from Day 8A bounce is a signal — and different signals require different responses
An institution that retries every bounce on the same schedule — Day 3 and Day 7, regardless of the reason code — is treating code R01 (insufficient funds, likely temporary) the same as code R08 (payment stopped the mandate, likely intentional) and code 10 (account closed, definitely unresolvable by retry). The code R01 retry may succeed. The code 17 retry will fail and alert the borrower that the institution is not reading their signal. The code 10 retry will fail three times and generate three sets of bank charges on a closed account. The Repayment Agent AI reads the return code, selects the response protocol matched to that specific signal, and routes cases that cannot be resolved by ACH to the collections teams that can resolve them — rather than exhausting ACH attempts on accounts where a different approach is needed.