ACH software for banks falls into five jobs: originating entries for business clients, processing files with the ACH operator, monitoring for fraud, assessing originators' risk, and handling the exceptions that come back, meaning returns, unauthorized-debit claims and notifications of change. Most banks run the first two on their core or a dedicated ACH platform; the exceptions are where work still runs on reports, email and spreadsheets, against deadlines measured in banking days. Botminds' ACH Returns & NOC Management is software for that last job: agents read the bank's ACH files and core exceptions, propose each return, claim and correction with its rule and deadline, and forecast originators' return rates, while specialists and managers approve. Going live on it, or on any tool for the same job, is mostly a matter of gathering what the bank already holds. This guide lists what that is.
Examples come from a fictional sample bank, Tessaly Community Bank, as it runs through the solution in October 2026. Settings quoted for it are the sample bank's choices, not recommendations.
The operator's clock the bank's software has to meet
10:30a.m. ET
first FedACH deadline for electronic returns that settle the same day
4:45p.m. ET
last same-day deadline for electronic returns, settling at 6:00 p.m. ET
2:15a.m. ET
deadline for returns that settle at 8:30 a.m. ET on the next business day
What ACH software do banks use, and where do returns fit?
Banks use an ACH processing platform, usually part of or attached to the core, to build, send and receive files with the ACH operator, and an origination channel for business clients; returns and corrections arrive through that same platform. The return work itself, deciding codes, taking customers' statements, following corrections through and watching originators' rates, is often handled outside it in queues and spreadsheets. ACH is not a niche to staff thinly: the Federal Reserve's 2025 payments study found ACH's share of all U.S. noncash payments by value rose "from 72 to 74 percent" between 2021 and 2024 (Federal Reserve Payments Study).
Five jobs ACH software for banks does, and which one this guide is about
| Job | What it covers | Typical home | Botminds solution |
|---|---|---|---|
| Origination | Business clients send payroll and collections; limits, prefunding, file intake | Online banking and the ACH platform | — |
| Processing | Files to and from FedACH or the private operator; settlement | ACH processing platform and core | — |
| Fraud monitoring | Nacha’s credit and debit fraud-monitoring rules, alerts, holds | Fraud systems | ACH Fraud Monitoring |
| Originator risk | Underwriting, exposure limits, third-party senders, annual reviews | Treasury management and credit | ACH Originator Risk Assessment |
| Returns and corrections | Return codes and deadlines, unauthorized-debit claims, notifications of change, dishonors, originator return rates, Nacha inquiries | Exception reports, queues, spreadsheets | ACH Returns & NOC Management |
The fraud and originator-risk jobs border on returns but are different work. A bank evaluating credit monitoring under Nacha's 2026 rules should look at ACH Fraud Monitoring; one setting exposure limits or reviewing third-party senders should look at ACH Originator Risk Assessment. The rest of this guide is about returns and corrections.
What do we need to implement ACH returns software? The inputs you already hold
To implement ACH returns software a bank needs its operator files, its core's posting exceptions, its customers' claims and signed statements, its originator data, its calendar and cutoffs, its approvers, its letter templates and its last audit. Almost all of it exists today. The work is naming who owns each input and agreeing the format, not creating anything new.
Eleven inputs for going live on ACH returns, and who usually owns each
| Input | What it is used for | Usual owner |
|---|---|---|
| Return and correction files from the ACH operator | Every return and notification of change on entries the bank sent | ACH operations; the ACH platform team |
| Core posting exceptions and account status | Balances at posting, closed or frozen accounts, stop payments | Deposit operations; core team |
| Customer claims and signed statements | Unauthorized-debit claims, the written statements and their attachments | Contact center, branches, case management |
| Originator master | Company IDs, entry codes allowed, channels, agreements, partner relationships | Treasury management; fintech partner risk |
| Sixty days or more of returns and originations | Each originator’s return rates from the first morning, not after two months | ACH operations; data team |
| Banking-day calendar and cutoffs | Deadlines counted on Reserve Bank holidays, the bank’s file cutoff and escalation hour | ACH operations manager |
| Approval matrix | Who approves in-window returns, late returns, R17, dishonors, restrictions, Nacha replies | ACH operations manager; risk |
| Override reason codes | The bank’s own reasons for changing or rejecting a proposal | ACH operations manager; quality |
| Letter and notice templates | Returned-item notices, claim letters, correction notices to clients, Nacha replies | Compliance; legal |
| Claim review policy | How the bank reviews a signed statement before returning, which Nacha’s rules leave to the bank | Deposit operations; fraud |
| Last Nacha Rules compliance audit and exam findings | The first test set: every finding becomes a check the software must pass | Internal audit; compliance |
Two of the eleven are often missing in writing. The approval matrix lives in people's heads, and the claim review policy may not exist at all. Nacha noted in July 2026 that its rules set no requirements for how a receiving bank reviews a customer's signed statement, and that a 2025 survey by its risk advisory group found wide variation in practice (Nacha, July 2026). Software can apply a policy consistently; it cannot supply one.
Does ACH returns software connect to FedACH?
Usually through the bank's ACH processing platform, not directly. The platform exchanges files with FedACH or the private operator; returns software reads the incoming return and correction files from it and writes approved returns, corrections and dishonors back for the next transmission. That keeps a single connection to the operator, with its credentials and controls, and keeps the operator's deadlines in one place.
Where returns software sits between the operator and the bank
Agent
Operator files arriveFedACH distributes return and correction files to the bank’s ACH platform on its published schedule; the agents read them as they land.
Never: opens a connection of its own to the operator.
Agent
Core and claims readBalances, status, stop payments and posting exceptions from the core; claims and signed statements from case management and imaging.
Agent
Proposals with deadlinesEach return, claim, correction and dishonor proposed with its code, rule, deadline and sources, in trays by deadline.
Never: sends a return or changes a template.
A person decides
Specialist and manager approveIn-window work approved by the specialist; late returns, R17s, dishonors and Nacha replies by the manager.
Agent
Written back for transmissionApproved items go back to the ACH platform for the next operator window; losses and recoveries to the general ledger.
The operator's rules sit underneath. FedACH's terms are in the Reserve Banks' Operating Circular 4, whose current edition is listed as "effective 01/05/26" (Federal Reserve Financial Services, Operating Circulars). A bank's return deadlines are the Nacha deadlines expressed against that schedule: an item due by opening of business on the second banking day has to leave in a window that settles before then.
Your rules as settings: clocks, levels and approvers
Nacha's timeframes and return-rate lines are the same for every bank; everything around them is the bank's choice and should be a setting, versioned and approved, not code. At the sample bank, the administrator proposes a change and the ACH operations manager approves it before it takes effect, and the change is on the audit trail.
The sample bank's settings: what Nacha fixes and what the bank chooses
| Setting | Sample bank | Whose rule |
|---|---|---|
| Return-rate lines | 0.5% unauthorized · 3.0% administrative · 15.0% overall, over 60 days or two calendar months | Nacha |
| Early warning | 0.40% · 2.4% · 12.0% | The bank |
| Forecast horizon | 8 days, counting returns still to come on debits already sent | The bank |
| Bank file cutoff | 4:00 p.m. ET, ahead of FedACH’s 4:45 p.m. window | The bank, inside the operator’s schedule |
| Escalate items due in today’s file | 2:00 p.m., to the ACH operations manager | The bank |
| Bulk approval floor | 95% confidence; below it an item needs a person | The bank |
| Any return over | $25,000 goes to the manager | The bank |
The early-warning row is where a bank's risk appetite shows. Why the 0.5% unauthorized line sits at 16 times the network norm argues for setting it well below the line, and for watching the trend as well as the level.
The calendar the clocks count on
Every ACH deadline is counted in banking days, so the calendar is an input, not a detail. The Federal Reserve publishes the holiday schedule its services follow, five years ahead, with a simple rule: a holiday that falls on a Saturday leaves the Reserve Banks open the Friday before, and one that falls on a Sunday closes them the Monday after (Federal Reserve Financial Services, Holiday Schedules; Federal Reserve holidays in 2026 lists the year). In 2026 that put Columbus Day on October 12 and Veterans Day on November 11, both inside the 60-day window of any debit that settled in September.
The rules that count those days change too. Nacha lists approved rule changes taking effect in March 2026, June 2026, July 2026, September 2026, January 2027, March 2027, September 2027 and March 2028 (Nacha, New Rules), including a new R90 return code for sanctions-related returns. A returns tool whose clocks are hard-coded will be wrong after the next one; the ACH return time frame, clock by clock shows which ones a bank has to hold.
Last year's audit as the first test
The bank's last Nacha Rules compliance audit, and any examination findings on ACH, are the best test set a bank owns: every finding is a case the new process must handle. Nacha requires the audit every year, and its 2019 restructuring of the rule left that annual duty in place (Nacha, ACH Rules Compliance Audit Requirements; the evidence an ACH rules compliance audit asks for). The OCC adds that the rules audit is only one part of an ACH audit program and no substitute for a full, risk-based one (OCC Bulletin 2006-39; see the ACH fraud risk assessment).
The evidence the next audit will ask for, kept as the work happens
How long does implementation take?
It depends on how many of the eleven inputs already exist in usable form, so the honest first step is a pilot on the bank's own past returns rather than a promised date. Take a closed month: its operator files, its core exceptions, its claims with their signed statements, and what the team actually sent. Run the software over it and compare, family by family, the codes it proposes with the codes sent, the deadlines it computes with the dates items left, the corrections it would have followed up, and the originators it would have flagged against what happened next.
That comparison answers the implementation question better than a vendor's timeline. Inputs that load cleanly are done; inputs that do not show where the bank's own data needs work, which it would need for any tool. It also produces the first evidence for the examiner and the auditor that the new process is at least as good as the old one, which is the bar a bank should hold any change to before it relies on it. For ACH Returns & NOC Management, that pilot on a sample of the bank's own past returns, claims and notifications of change is how every evaluation starts.
What a first run of ACH Returns & NOC Management over the bank's own files produces
What to compare in ACH processing software for returns
Compare tools on what they prove, not on what they list. The checklist below turns each claim a vendor might make into something a bank can see on its own files during a pilot. It applies to ours as much as to anyone's.
Questions that separate ACH returns tools, answered on your own files
- Show me the deadline for this item, and how you counted it
Settlement date, banking days, holidays and the window it must leave in.
- Show me why you chose this code
Each check, and the source behind it, opening in place.
- Show me the signed statement behind this unauthorized return
With the box the customer ticked and the date, and what you did when the claim form disagreed.
- Show me a correction you followed through
Matched to the entry sent, passed on, and checked in later files for the old account data.
- Show me a return you would dishonor
Untimely or duplicate, found on the day it arrived.
- Show me an originator before it crossed a line
Rates at the level Nacha measures, a forecast, and the likely cause.
- Show me what a person approved, and what your tool may never do
Separation of duties in the screen, overrides with reasons, and actions the tool cannot take.
What ACH Returns & NOC Management does, and what stays elsewhere
It does: Proposes the code, file and deadline for every exception and claim, with sources; flags items due today.
It does not: Send returns, or transmit to the ACH operator.
It does: Reads the signed statement and attachments and says which code it supports.
It does not: Sign or complete a statement for a customer, or return a 60-day claim without one.
It does: Matches, posts to bank-held templates or partner systems, proposes refusals, finds clients still using old data.
It does not: Change a routing number on a bank-held template without a second person, or edit a template without the client’s consent on file.
It does: Measures three rates daily with a forecast and cause, and drafts controls and Nacha replies.
It does not: Restrict or suspend an originator, set exposure limits, or write to Nacha.
It does: Routes suspected-fraud returns to the manager and keeps any referral in the BSA officer’s view only.
It does not: Run Nacha fraud monitoring, which is ACH Fraud Monitoring’s job.
One more comparison matters for buyers: what changes for the people. The eleven tasks behind ACH returns sets out which move to agents and which never do. The solution's full description is at ACH Returns & NOC Management.
Questions people ask
Who owns the ACH procedures at a bank?
Usually the ACH operations manager owns the return and correction procedures, with compliance owning the policies they implement and internal audit testing them. The OCC expects board-approved risk tolerances and clear duties for each role, so that controls over transactions hold, as part of an ACH program (OCC Bulletin 2006-39), the same expectation written ACH fraud monitoring procedures have to meet.
What files does the core produce for ACH returns?
Typically a posting exceptions report of incoming entries it could not post, with the reason, plus account status and balance data. The return and correction files themselves come from the ACH operator through the bank's ACH platform; claims and signed statements come from case management or document imaging.
Does returns software need the bank's FedLine connection?
Not if the bank's ACH platform already exchanges files with FedACH; the software reads and writes through that platform. Banks that derive returns manually on FedLine Web can keep doing so for exceptions, since the Federal Reserve's tool creates "one return or NOC at a time."
Can the software take signed statements electronically?
The software reads statements however the bank takes them. Since 2021 Nacha has made explicit that a statement may be obtained "electronically or orally" and signed with an electronic signature, provided it can be stored and reproduced and a copy given to the ODFI on request (Nacha, Meaningful Modernization).
Is ACH software for banks different from ACH software for businesses?
Yes. Business ACH software sends payments and collections through a bank; bank ACH software processes everyone's files, receives the returns and answers for them under the Nacha Rules. Returns and corrections software is used only on the bank's side, by the RDFI for returns and the ODFI for what comes back.