ACH risk management software helps an originating bank keep each business it sends ACH entries for inside a reviewed exposure limit and under Nacha's return rate lines, and keep the evidence that it did. Banks do this work in one of three ways: a spreadsheet and a memo, a rules module that raises alerts inside the payments or origination system, or agents that gather, measure and draft while people decide. All three can compute a return rate. They differ in what they notice between reviews, how much of the file they assemble, and what an examiner can trace afterwards. Botminds' ACH Originator Risk Assessment takes the third approach; this guide runs one sample originator through all three and is plain about where each, including ours, stops.
The originator is fictional: Pinecrest Membership Clubs, a 112-club fitness chain debiting 204,000 members a month through a fictional bank, Corvane. Its figures are sample data from the solution; the time estimates are the product's own, described as estimates where they appear.
One originator, three approaches: what each produces on the day the rate crosses
| Spreadsheet and memo | Rules module | Agents with sign-off | |
|---|---|---|---|
| What starts the review | The calendar: next annual review March 2027 | An alert when a rate passes a set line | A nightly re-measure of every originator, at the bank's own warning level and at Nacha's |
| The return rate | Rebuilt by hand from exported reports when someone looks | Computed, with the code mix | Computed, with window, denominator and codes shown, and the cause named: a trial launched May 4 |
| The exposure limit | Last year's number, retyped | Last year's number, enforced | Proposed from ninety days of files with the arithmetic, a prefunding rule and a return reserve |
| The financials | A statement, often a year old, re-spread | Not read | Spread with every value cited; the late interim requested |
| The originator's controls | A questionnaire read weeks later | Not read | Each answer quoted and compared with last year's |
| The decision | An email reply | Outside the tool | Reason code and signature; a second person checks; the limit goes to the payments hub untouched |
| What an examiner gets | Files and emails gathered for a fortnight | Alert logs | One indexed pack per originator, or a sample of twenty-five |
What should ACH risk management software do?
It should do the five things examiners test, and hold the evidence that it did them. The FFIEC's examination procedures for an originating bank ask whether it monitors originators' creditworthiness on an ongoing basis, whether it has limits based on credit rating and activity, whether it reviews them periodically, and whether it monitors entries against them across multiple settlement dates (FFIEC IT Handbook, Retail Payment Systems, Appendix A). The handbook's control guidance adds the step most tools leave out: "Breaches in limits should be reported to the appropriate levels of management" (FFIEC, ACH risk management controls).
Five jobs ACH risk management software has to do, as examiners test them
- Monitor each originator's credit, independently of operations
Ratings assigned, periodic financial information required and actually received, monitoring by credit people.
- Set a limit from credit and activity
Reasonable against the client's exposure across all services, with a separate limit for internet and other higher-risk entries where warranted.
- Review the limit on a cadence and on triggers
Adjusted when the rating or activity changes, and re-evaluated when debit returns rise.
- Enforce it across settlement dates
Entries accumulated over the return period; over-limit entries approved in advance by a credit officer.
- Measure returns and report what crosses
Rates at the originator level, breaches reported to management, and evidence of what was done about them.
Read that list against a tool's brochure and one question sorts most of them: does it read the inputs, or does it expect someone to type them? A limit check at release is enforcement. Setting the limit, reviewing it and proving why it is the right number is assessment, and that is where most of the hours go.
Spreadsheet vs software for ACH risk: what a spreadsheet gets right
A spreadsheet is cheap, transparent and under the analyst's control, and for a bank with a few dozen low-risk payroll originators it can be enough. Every formula is visible, the method can follow the policy exactly, and nothing has to be bought or validated. Its failure is not arithmetic; it is time. A spreadsheet knows what it was last given.
Pinecrest shows the failure. Its unauthorized return rate passed the sample bank's 0.35% warning level on September 2 and Nacha's 0.50% line on October 19; its next annual review was due in March 2027. In the product's own estimate for a regional bank, an off-cycle review by hand takes about eleven days from trigger to loaded limit: a day and a half to build the ninety-day file history out of daily reports, a day to rebuild three return rates, two to chase and spread statements, three to send the controls questionnaire and read the answers, two and a half to write the memo and chase the approval, and one to load the limit and assemble the evidence. Then the approved number is retyped into the payments hub.
Where eleven days of an off-cycle review go by hand, and the 0.8 left with agents
The rules module: alerts on time, the file still by hand
A rules module closes the spreadsheet's biggest gap: it watches every originator and raises an alert when a rate or a file crosses a line. If it holds the limits, it also enforces them at release, which is the control the FFIEC's procedures test. For the narrow job of noticing, it is a large step up.
What it does not do is assemble the assessment the alert calls for. An alert that says Pinecrest's unauthorized rate is 0.62% does not say that 1,673 of its 2,560 unauthorized returns came through a seven-day trial launched on May 4, that its interim statements are fifty-one days late, or that its controls answers got worse since last year. The analyst still exports, rebuilds, chases and writes. A rules module also tends to know only the Nacha lines; the bank's own earlier warning level, its tier bases and its approval ladder live in a policy document, and the module does not read policies.
Agents: the gathering done, the decisions left alone
Agents take the part of the review that is reading and arithmetic, and stop where judgment starts. In the solution, a Returns agent re-measures every originator's three rates every night and names the cause; an Exposure agent reads ninety days of files and proposes a limit, a prefunding rule and a reserve with the arithmetic shown; a Financials agent spreads statements and cites each value to its page; a Monitoring agent quotes the originator's controls answers against the rules and last year's. On the sample, seven agents gathered from five systems and assembled one recommendation in four minutes and twelve seconds.
The limits on them are as important as the work. Nothing the agents are less sure of than a confidence floor of 0.90 is asserted; it goes to a person as a question. No agent approves a limit, checks one, releases it to the payments hub, sends a client letter or closes a remediation action. The analyst prepares, a named credit officer approves within authority with a reason code, and a risk manager who did not prepare the assessment checks and releases it.
The desk: every originator measured overnight, the seven over a line first
What an examiner can trace in each approach
The examiner's questions do not change with the tool: why this limit, measured how, approved by whom, checked by whom, and enforced from when. What changes is whether the answer is in one place. The comparison below sets the spreadsheet approach against the agents on the questions an ACH examination actually asks.
The same five examiner questions, answered from a spreadsheet file and from the agents' record
Spreadsheet, memo and email: A memo paragraph; the volume figures in a tab whose source report is no longer saved.
Agents, with sign-off: The ninety days, the peak, the returns in flight and the basis, each opening the settlement day or rule it came from.
Spreadsheet, memo and email: A formula the next analyst may build differently.
Agents, with sign-off: Window, denominator and numerator by code on the page, so two analysts get one answer.
Spreadsheet, memo and email: An email reply, found again at exam time.
Agents, with sign-off: A typed signature with a reason code, inside the approver's authority from the policy.
Spreadsheet, memo and email: Often skipped on a limit cut, when the client is calling.
Agents, with sign-off: Released only by a person who did not prepare it; a cut is checked like an increase.
Spreadsheet, memo and email: Retyped into the payments hub; compare the two by hand.
Agents, with sign-off: Released to the payments hub as approved, with its confirmation time on the trail.
What should an ACH risk management policy include?
The policy is the part of an ACH risk program a tool should obey rather than replace. The OCC's guidance lists what adequate policies generally contain: the program's objectives and place in the bank's strategy, board-approved risk tolerances, clearly defined duties that keep internal controls strong, an ACH credit-risk management program, and vendor management for third-party service providers. It leaves the depth to the bank: "Each bank should use this guidance to develop an ACH risk management program that reflects the nature and complexity of the bank's activities" (OCC Bulletin 2006-39).
For originator risk, the credit-risk part of the policy should carry the numbers a tool needs: risk tiers and what moves a client between them, the limit basis and cap for each tier, the review cadence and the off-cycle triggers, the bank's own warning levels below Nacha's lines, the approval ladder by limit size, the deadlines for each step, retention and masking. Software that holds those as versioned settings, with a preview of what a change would do before it is saved, keeps the policy and the practice from drifting apart. At the sample bank, setting the unauthorized warning level at 0.35% brings 286 originators onto the desk for an off-cycle review this quarter; the settings screen shows that number before anyone saves.
The ACH risk policy as settings, with Nacha's lines locked
Can agents be used for ACH risk management under model risk guidance?
The revised interagency model risk guidance of April 2026 does not answer that question, by design. OCC Bulletin 2026-13 places generative and agentic AI outside its scope as novel and fast-changing, notes that the agencies plan a request for information on banks' use of AI, including agentic AI, and keeps spreadsheet arithmetic and deterministic rule-based software out of its definition of a model (OCC Bulletin 2026-13). It also describes itself as guidance, not enforceable standards or prescriptive requirements. The bulletin's own wording on each point is quoted in the guide to whether a customer risk rating is a model.
Until the agencies say more, the defensible position is to govern agents with controls an examiner already understands: every value cited to its source so it can be checked by a person; a confidence floor below which nothing is asserted; separation of duties between preparer, approver and checker; and no agent with authority to approve, release or close anything. Those controls do not depend on how the guidance eventually classifies the agents, which is why the solution was built around them.
What ACH Originator Risk Assessment covers, and what it leaves to other tools
ACH Originator Risk Assessment does the assessment half of ACH risk management: measuring, deriving, reading, drafting and keeping the evidence for each originator's limit and tier, and for third-party senders reviewed as clients. It works with the systems a program already runs on (the payments hub, the origination platform, the core, the commercial credit system and case management) and replaces none of them.
It is not a fraud monitoring system for individual entries; that obligation under Nacha's 2026 rules (Nacha, Fraud Monitoring Phase 1) is the subject of the guide to the 2026 Nacha fraud monitoring rules. It does not process returns or notifications of change, register third-party senders with Nacha, or run the annual rules compliance audit. And it does not originate files: how assessment work divides from ACH origination software is set out separately. A bank with a handful of payroll originators and no consumer debits may reasonably stay with a well-kept spreadsheet.
How do you switch from spreadsheets to ACH risk software?
Prove it on your own history before you rely on it. The usual first step is a sample: run the tool over a set of past originators' files and returns and compare the limits and tiers it derives with the ones the bank approved. Disagreements are the useful output; each one is either a policy the bank applies but never wrote down, or an approval the bank would now make differently.
A switch plan from spreadsheets to assessed limits
- Write the policy as settings first
Tiers, bases, caps, warning levels, approval ladder and clocks. Whatever cannot be written down cannot be applied consistently by a person either.
- Run a sample of past originators
Include clients that breached a line, clients with late statements and clients with a limit increase. Compare derived limits with approved ones.
- Settle every disagreement in writing
Change the setting, or record why the past approval stands.
- Go live tier by tier
Start where reviews are most frequent and the exposure is highest; that is where hours and risk both concentrate.
- Retire the retyping
Approved limits released straight to the payments hub after a second person's check, so the approved and enforced numbers cannot differ.
- Build the first examiner pack before the examiner asks
A sample of twenty-five assessments with their arithmetic, approvals and evidence is the test of whether the switch worked.
Every action on one trail, and the examiner pack built from it
The template the assessment fills, element by element, is in the ACH originator risk assessment template. To run the sample on your own originators, start from ACH Originator Risk Assessment.
Questions people ask
What is an ACH risk management program?
It is the board-approved framework under which a bank originates ACH: policies, risk tolerances, a credit-risk program for originators, monitoring, audit and reporting to the board. The OCC's guidance describes it as starting with clearly defined objectives, a business strategy and clear risk parameters, with the board setting risk limits and management running the controls. Software supports the program; it does not constitute one.
Is ACH origination software the same as ACH risk management software?
No. Origination software builds, approves and transmits files and can hold or reject a file over its limit. Risk management software decides what the limit should be, keeps it under review and holds the evidence. Some platforms do a little of both; the test is whether the tool reads the inputs to a limit or only enforces a number someone typed.
Does ACH risk management software satisfy Nacha's 2026 fraud monitoring rules?
Not by itself. The 2026 rules require risk-based processes and procedures, reviewed at least annually, from the bank and from each non-consumer originator. Assessment software can test and document an originator's processes, but the processes have to exist and run, and entry-level fraud monitoring is a separate job.
How many originators can a team cover with a spreadsheet?
There is no regulatory number; the limit is the team's hours. At the product's estimate of about three analyst hours a review, the sample bank's 2,450 reviews a quarter would need some 7,350 analyst hours a quarter by hand, before any off-cycle review, which is why reviews get thinned when volume grows.
What should an examiner sample from ACH risk software?
A set of originator assessments chosen by the examiner or at random, each with its limit basis, the arithmetic, the approval and who checked it. The sample bank's pack for twenty-five assessments runs to 318 pages; the point is that it is built from the record in one step, not gathered from mailboxes.