If a Modesto credit union leaves ACH debits unrestricted, it may discover fraud only after money leaves; if it blocks everything, legitimate payroll, benefits, and vendor debits fail. The practical answer is a designed approval workflow: classify the account, set permitted transactions, route exceptions to named people, and test the controls.
At 8:17 a.m. in a Modesto credit union’s treasury office, the controller is reviewing the bank portal before the day’s ACH file goes out. A new debit from a software vendor is waiting in the exception queue. The amount is ordinary. The vendor name looks familiar. But the account number changed after a rushed renewal, and the credit union’s ACH debit filter has no matching authorization.
The controller has two bad options if the program was designed as a checkbox. Approve it and risk authorizing an account-takeover payment. Reject it and risk interrupting the vendor service that supports online banking or member communications. The real decision is not whether to “turn on ACH blocks.” It is whether the credit union has a controlled, documented way to decide which debits may post, who can approve an exception, and how the decision is reconciled afterward.
That distinction matters for Datapath customers in finance, local government, healthcare, and mid-market businesses across the Central Valley, Modesto, and California. ACH debit blocks and positive pay are not interchangeable products, and neither replaces identity protection, approval segregation, or monitoring. They are transaction-level controls that must fit the organization’s operating workflow.
What do ACH debit blocks and positive pay actually do?
The names are often used together, but they solve different problems.
An ACH debit block generally starts with a restrictive position: the account rejects or holds incoming ACH debits unless the transaction matches an approved rule. Depending on the bank’s service, the rule may identify an approved company ID, originator, account, transaction type, or dollar threshold. Some institutions offer an ACH filter that allows approved debits and returns or flags the rest. Others provide an exception workflow for daily review.
Positive pay is an exception-based verification process. A business supplies expected payment information, and the bank compares presented transactions with that information. For checks, the comparison may include check number, amount, and payee. For ACH, the comparable service is often called ACH positive pay, ACH fraud control, or an ACH filter. The exact matching fields and response deadlines depend on the financial institution’s service agreement.
FFIEC interagency guidance identifies positive pay, debit blocks, and other transaction blocks as tools available to business customers for monitoring and controlling transactions on their accounts.1 The guidance also describes dual-control transactions that require more than one employee to authorize and approve certain transactions.1
The useful way to think about the controls is this:
| Control | Primary question | Typical decision point | What it does not solve |
|---|---|---|---|
| ACH debit block | Is this debit permitted to reach the account at all? | Before posting or during the bank’s exception window | A compromised user who changes the bank rule |
| ACH filter | Does this debit match an approved originator or rule? | Automated match plus exception review | Poor vendor-master or authorization data |
| ACH positive pay | Does this presented debit match expected details? | Daily or scheduled pay/no-pay decision | A legitimate-looking but fraudulent setup |
| Check positive pay | Does the check match issued payment data? | Exception review before payment | ACH, wire, card, or instant-payment fraud |
| Dual control | Did two authorized people approve the action? | Setup, release, or exception approval | A shared account, weak identity controls, or collusion |
| Transaction alerts | Is activity unusual or outside the expected pattern? | Near-real-time notification and investigation | Blocking the payment automatically |
A control is valuable only if someone can act on its output. An alert that arrives after the bank’s decision deadline is a report, not a prevention control.
Where NACHA Operating Rules fit—and where they do not
NACHA Operating Rules govern the ACH network and the responsibilities of participants. They do not prescribe one universal bank portal configuration called “ACH positive pay.” Your financial institution’s product, account agreement, and operating procedures determine how a debit block or filter is implemented.
For online-initiated WEB debits, NACHA requires Originators to use a commercially reasonable fraudulent-transaction detection system. NACHA’s account-validation rule makes clear that account validation is part of that system for the first use of an account number or a change to the account number.2 In practice, a business that initiates online consumer debits should not treat an ACH debit block at its own bank as a substitute for validating the account information it sends to the network.
The distinction is important for a healthcare group collecting patient balances, a school district initiating authorized deductions, or a finance company collecting recurring payments. The organization may be both a bank customer receiving debits and an ACH Originator sending debits. The control obligations and risk decisions differ by role.
NACHA’s 2026 fraud-monitoring amendments add another reason to review the operating model. Phase 2 requires covered non-consumer Originators, Third-Party Service Providers, and Third-Party Senders to establish and implement risk-based processes and procedures reasonably intended to identify ACH Entries initiated due to fraud.3 NACHA states that the practical date for the June 19, 2026 effective date was June 22, 2026, because June 19 was a federal holiday.3
For debits, NACHA explains that a robust return and return-rate monitoring program, together with applicable WEB-debit and Micro-Entry fraud-detection requirements, can serve as a minimum level of fraud monitoring.3 That does not mean a business should settle for reviewing return reports once a quarter. It means the ACH program needs an accountable owner, defined thresholds, an investigation process, and an annual review of the procedures.
Should you block every ACH debit?
Usually, no—not without mapping the account’s actual payment behavior first.
A full debit block may be appropriate for a reserve account, a tax account, a dormant operating account, or an account that should never accept ACH debits. It may be counterproductive on an account used for recurring insurance, utilities, payroll-related services, loan payments, benefits, or critical software subscriptions.
Start with an account-by-account decision:
- No ACH debits expected: use a full debit block if the bank can support it, and document the rare exception path.
- A small number of recurring debits: use an ACH filter or allowlist with known originators and defined amount limits.
- Variable but legitimate debits: use ACH positive pay or exception review, with a documented reviewer and deadline.
- High-value or high-impact debits: require a second approver, a callback through a known number, or an independent vendor confirmation.
- Unclear payment behavior: pause configuration changes until finance, operations, and security reconcile the account’s expected activity.
The goal is not maximum friction. It is predictable friction at the moments when fraud risk is highest: a new originator, a changed account number, a new bank user, an unusual amount, a new company ID, or a payment outside the normal cadence.
What should the daily exception workflow look like?
A practical workflow can be simple enough for a small finance team while still producing evidence for review.
1. Prepare the expected-payment data
The source of truth should not be an informal spreadsheet saved on one employee’s desktop. It may come from the ERP, treasury platform, accounts-payable system, or a controlled payment file. At minimum, identify the originator, account, expected frequency, amount range, and business owner.
For a mid-market company, the list should distinguish recurring software from one-time vendors. For a county department, it should distinguish ordinary operating debits from specialized public-safety or dispatch vendors. For a clinic, it should account for the vendors supporting the EHR, clearinghouse, laboratory, and patient communications workflow.
2. Match automatically where possible
The bank control should reject, hold, or flag transactions that fall outside the approved criteria. Match rules should be narrow enough to matter. An allowlist that approves every debit from a broad corporate family or uses no dollar limit may create the appearance of control without much reduction in risk.
3. Route exceptions to named people
The reviewer should see the transaction, the reason it failed the rule, the expected business context, and the response deadline. “Someone in accounting” is not an owner. Name the primary reviewer and backup, especially around month-end, holidays, and staff leave.
4. Verify independently
If the exception involves changed banking details or a new originator, do not rely on the email that requested the change. Verify using a known vendor contact, an existing contract record, or another trusted channel. A help-desk ticket alone is not proof that the request is legitimate.
5. Record the decision
Keep the transaction details, reviewer, approver, reason, and timestamp. Retain rejected items and false positives, not only approved payments. Those records help identify repeated originator changes and show whether the control is creating too much operational noise.
6. Reconcile after posting
Compare the bank activity to the approved decisions and the originating system. A payment that passed the filter still needs reconciliation. The purpose is to detect rule drift, duplicate payments, unexpected returns, and unauthorized configuration changes.
What does FFIEC guidance mean for business customers?
The FFIEC guidance is not a promise that a particular product will stop every payment fraud event. It is a reminder that customer-side controls—positive pay, debit blocks, transaction alerts, and dual controls—are part of a broader authentication and access-risk program.4
That broader program should include at least four layers:
- Identity: unique users, strong authentication, and removal of former employees.
- Privilege: separate entitlements for preparing, approving, releasing, and administering bank transactions.
- Transaction control: debit blocks, filters, positive pay, dollar limits, and alerts.
- Recovery and evidence: reconciliation, return handling, incident escalation, and retained approval records.
The bank portal administrator deserves particular attention. If one person can add a new user, change the debit filter, release an exception, and alter alert recipients, the transaction control can be bypassed without touching the payment file. Dual control should apply to the sensitive administrative changes—not just the final payment approval.
For banks and credit unions, OCC guidance on ACH risk management also emphasizes exposure thresholds, regular monitoring of those limits, clearly defined duties, internal controls, and vendor-management oversight.5 For Datapath’s finance customers, that translates into a practical review of the bank relationship, the treasury platform, the ERP integration, and any third party that originates or transmits ACH files.
How Datapath helps make the control operational
Datapath does not sell an ACH filter as a magic switch. We help organizations connect the payment control to the systems and people around it.
Our managed cybersecurity team can help review identity, privileged access, alerting, and response procedures around banking platforms. For a finance organization, our finance IT team can help frame the discussion around treasury operations, segregation of duties, and vendor dependencies. For a county or public-safety organization, our government and public safety team can help account for departmental workflows and continuity requirements.
Where an internal IT department owns the systems but needs additional security leadership, co-managed IT and vCISO services can provide structured review without forcing a full outsourcing model. And if a payment-fraud event occurs, an incident response retainer gives the organization a defined escalation path before the crisis begins.
The deliverable should be more useful than a policy that says “use positive pay.” It should identify each account, the permitted debit behavior, the exception deadline, the people who can approve it, the administrative changes requiring dual control, the evidence retained, and the test date.
A 30-day review plan for ACH debit blocks and positive pay
Days 1–10: inventory and classify
List operating, payroll, reserve, tax, and collection accounts. For each account, document whether ACH debits are expected, which originators are legitimate, and what happens if a valid debit is held for one business day.
Days 11–20: configure and separate duties
Work with the bank to confirm whether the service is a full debit block, ACH filter, ACH positive pay, or another transaction-blocking product. Set allowlists and thresholds. Separate file preparation, exception approval, and portal administration. Enable alerts for configuration changes and unusual activity.
Days 21–30: test the exception path
Run a controlled test with the bank and the responsible staff. Confirm that an unapproved debit is blocked or flagged, that the right people receive the alert, that a backup reviewer can act, and that the decision is recorded. Test what happens when the primary reviewer is unavailable.
Then schedule an annual review. NACHA’s 2026 fraud-monitoring guidance specifically calls for review of the relevant processes and procedures at least annually.3 A review should also occur after a banking-platform change, ERP migration, merger, major vendor change, or payment-fraud incident.
ACH debit blocks and positive pay work best when they are treated as operating controls, not standalone banking add-ons. In Modesto or any market Datapath serves, the right question is not “Do we have positive pay?” It is “Can we prove that the right transaction reached the right account, through the right approval path, and that an exception would have been caught in time?” That is the conversation our named Datapath team is ready to help you have.
Footnotes
-
Authentication and Access to Financial Institution Services and Systems; Interagency Guidance ↩ ↩2
-
Supplementing Fraud Detection Standards for WEB Debits | Nacha ↩
-
RISK MANAGEMENT TOPICS – (Fraud Monitoring Phase 2) | Nacha ↩ ↩2 ↩3 ↩4
-
Automated Clearing House Activities: Risk Management Guidance | OCC ↩
