Most ACH entries settle. A small share comes back with a reason code, and another share comes back as a Notification of Change that someone must turn into a record update before the next payment goes out. For a payments-ops team, that residue is a daily queue with hard clocks attached.
This guide is for a US bank or fintech payments-ops lead on either side of the network: the ODFI that sends entries for originators, or the RDFI that receives them. For the wider banking picture, see our pillar guide to AI employees in banking and financial services.
How can you automate ACH returns and NOC handling?
What are ACH returns and Notifications of Change?
A return is an entry the receiving bank sends back through the network instead of posting it. A Notification of Change, or NOC, is different: the entry posted, but something in the payment instruction was wrong or out of date, and the receiving bank says what to correct. Nacha describes it as the Receiving FI having processed an item that has something incorrect or updated in the payment instruction, with a "C" code showing what needs to change (Nacha originator essentials).
Plain definitions are in our glossary entries on ACH payments and the ACH return.
Which return reason codes and NOC codes come up most?
Nacha publishes the full tables in the Operating Rules, and a Nacha mapping guide reproduces the definitions (Nacha ISO 20022 guide, return and change codes). The ones that fill most queues:
- R01, insufficient funds: The available balance does not cover the debit.
- R02, account closed: A previously active account was closed by the customer or the RDFI.
- R03, no account or unable to locate account: The account number is well formed but does not match the person named in the entry, or the account does not exist.
- R04, invalid account number structure: The number itself is not valid.
- R05, unauthorized debit to a consumer account using a corporate SEC code.
- R07, authorization revoked by the customer.
- R09, uncollected funds: The book balance would cover the debit, but the available balance does not.
- R10, customer advises the originator is not known or not authorized to debit: Nacha says R10 and R11 apply to consumer receivers, while R29 continues to be used for CCD and CTX entries to non-consumer accounts (Nacha on unauthorized return reasons).
- R29, corporate customer advises not authorized.
On the change side, C01 means an incorrect account number, C02 an incorrect routing number, C03 both, and C05 an incorrect transaction code, for example a savings code on a checking account.
What are the return deadlines?
Nacha's originator guidance describes a standard two-day return window for corporate SEC codes and an extended 60-day window for consumer SEC codes (Nacha originator essentials). For the extended consumer return, Nacha's text for improper reversals is specific: the RDFI must make the return available to the ODFI by the opening of business on the banking day following the 60th calendar day after settlement, and must first obtain the consumer's Written Statement of Unauthorized Debit (Nacha reversals and enforcement).
An unauthorized consumer return can therefore arrive two months after settlement, so your ledger and originator reporting have to expect late arrivals.
NOCs have a separate clock on the originator. In most cases the originator must make the requested change within six banking days or before initiating another entry, whichever is later (Nacha originator essentials).
When does Nacha start looking at an originator's return rates?
Nacha sets three return rate levels, all on debit entries (Nacha ACH network risk and enforcement topics):
Level | Threshold | Return codes counted | What happens above it |
|---|---|---|---|
Unauthorized | 0.5% | R05, R07, R10, R29, R51 | The ODFI faces the obligations and potential enforcement that apply to the unauthorized threshold |
Administrative | 3.0% | R02, R03, R04 | Not automatically a Rules violation; Nacha can open a preliminary inquiry |
Overall | 15.0% | All returns on debits, excluding RCK | Same: a preliminary inquiry, not an automatic violation |
Rates are calculated over the preceding sixty days or two calendar months. These numbers belong to each originator and third-party sender, so a healthy portfolio average can hide one originator well above 0.5%.
What changed in 2026 with Nacha's fraud-monitoring rules?
Nacha's risk-based fraud monitoring rules took effect in two phases. Phase 1 began March 20, 2026 and Phase 2 on June 19, 2026, which Nacha notes is a federal holiday, so the practical date was Monday, June 22 (Nacha fraud monitoring, phase 2). ODFIs, non-consumer originators and third parties must have risk-based processes reasonably intended to identify entries suspected of being unauthorized or authorized under false pretenses, and review them at least annually. RDFIs must do the same for incoming credits and include handling procedures for credits flagged as suspect. Nacha states that neither group has to screen every entry or monitor before processing.
Both phases are now in force, and a clean, classified returns history is useful input to those processes.
How does Reg E affect returns on consumer accounts?
When a consumer disputes an ACH debit with their bank, the RDFI is also running a Regulation E error investigation. The consumer's notice must arrive within 60 days of the statement that first shows the error, and the institution generally has ten business days to investigate and report, or may take up to 45 days if it provisionally credits the account (CFPB, 12 CFR 1005.11). A consumer's signed statement that a debit was unauthorized can feed both the Reg E file and the extended return. Our guide to Reg E dispute investigation automation walks through that side, and the glossary entry on Regulation E has the definition.
What can an AI employee take on in the returns queue?
The work is repetitive, rule-bound and evidence-heavy, which suits an agent that follows a written procedure:
- Classify and match.
Read each return file, group by reason code, and match every return to the original entry by trace number, originator and amount. - Apply NOCs.
Read the change code and corrected data, update the customer or payee record where the originator's own policy allows it, and flag the entries that would otherwise go out again with the old data. - Check re-presentment.
For R01 and R09 returns, check the entry against the reinitiation limits in the current Operating Rules and the originator's agreement before anything is queued again. - Track rates per originator.
Recompute unauthorized, administrative and overall rates over the rolling window, and raise an alert well before a threshold. - Draft notices.
Prepare originator notices that cite the entries, the codes and the dates, ready for a person to send. - Reconcile.
Post returned amounts against the ledger; our piece on bank reconciliation automation covers where that goes wrong.
How does a Zamp AI employee run an ACH returns queue?
We build the returns queue around an Agent Operating Procedure, the written document the AI employee follows. For this job it would hold the code-to-action mapping, the NOC fields the agent may apply, the sources of truth for matching, the rate thresholds to watch and the escalation paths. The agent's identity is limited by design: it can read return files and draft notices, but it cannot close an originator or send anything to a customer.
A case goes to Needs Attention when it cannot be resolved inside that scope, for example a return that matches no original entry, a NOC that conflicts with the record on file, or an originator whose rate is moving toward a threshold. The case reaches a person with the evidence already assembled. Before a case is closed, the validate step of our plan, execute, validate loop checks the output against the procedure, and the reasoning is written into the team's own case system, as it was inside SAP Ariba in one customer deployment, so a reviewer reads the why in the tool they already use.
Corrections are how the procedure improves. When a reviewer overrides the agent, the change goes onto a branch of the procedure, is tested against a set of known cases, reviewed and merged. Only the procedure changes, never the model. In a biopharma procurement deployment, the agent sent 64% of requests to manual review in its first week; as reviewed corrections accumulated, its decision rate rose from 36% to 85% and manual review fell to 15%. A high manual-review rate at launch is the safety mechanism working, and the same logic applies to a new returns queue.
Banks with data-residency requirements usually choose BYOC, where the platform runs inside their own cloud account, or on-premises. Details are in our deployment models guide and the glossary entry on Needs Attention.
Who signs off on what?
Return or NOC type | What the AI employee does | Who signs off |
|---|---|---|
R02, R03, R04 (account data errors) | Classifies, matches to the original, flags the payee record, tracks the 3.0% administrative level | Payments ops analyst reviews exceptions |
R01, R09 (funds) | Checks re-presentment eligibility against the Rules and the originator agreement, drafts the originator notice | Payments ops lead approves any reinitiated entry |
R05, R07, R10, R29 (unauthorized and revoked) | Matches the return, counts it toward the 0.5% unauthorized rate, assembles evidence | Risk or compliance reviews; originator contact stays with a person |
NOC C01, C02, C03, C05 | Reads the corrected data, updates the record where permitted, stops the next entry using stale data | Ops analyst reviews conflicts; originator confirms its own records |
Threshold alert (0.5%, 3.0%, 15.0%) | Recomputes rates per originator, drafts the escalation memo | Head of payments risk decides next steps |
Suspending or closing an originator, Rules violation response | Prepares the file, never acts | Senior risk or compliance officer; see four-eyes approval for AI agents |
Separating the reviewer from the approver is segregation of duties.
How should you start?
Pick one return family, usually R02 through R04 plus NOCs, because the actions are mechanical and the errors are cheap to catch. Run the agent beside your analysts, review every disagreement, and widen scope only when disagreements are rare. Closing an originator, ruling on a Rules violation and talking to an unhappy customer stay with staff throughout. Adjacent queues include duplicate payment detection and payment screening.
