ACH Debit Blocks and Positive Pay: The Payment-Control Decision a Modesto Finance Team Cannot Leave to the Bank

Bottom line: ACH debit blocks and positive pay are not interchangeable switches. A Modesto finance team needs to decide which accounts should reject ACH activity outright, which should allow preauthorized debits, who can change those rules, and how exceptions are approved. The technology matters—but the operating workflow determines whether the control works.

At 8:47 a.m., the controller of a fictional Modesto manufacturer opens the bank portal before the morning payroll file is released. An unfamiliar ACH debit is waiting in the exception queue. The amount is only $18,400, but the payee name resembles a legitimate benefits vendor, and someone changed the vendor’s banking profile late the previous afternoon.

The controller has two choices: approve the item because it looks familiar, or reject it while payroll and accounts payable investigate. That decision is not just a banking task. It depends on whether the account uses a full ACH debit block, a rules-based ACH filter, or a positive-pay-style review; whether the person reviewing the exception is independent of the person who changed the vendor record; and whether the business can reconstruct who did what.

That is the sharper question behind ACH fraud controls: what should happen when a transaction is unusual, and can your team prove that the right person made the decision?

What is the difference between an ACH debit block and positive pay?

An ACH debit block is the stricter control. It tells the bank to reject ACH debits on an account unless the business has separately authorized them. It is a strong fit for an account that should not receive recurring electronic withdrawals at all—for example, a reserve account, a tax account, or an operating account used only for ACH credits.

An ACH filter—often called ACH positive pay—is more selective. The bank compares incoming debit activity against rules such as:

• Authorized vendor or originator names
• Permitted dollar limits
• Approved start and end dates
• Expected payment frequency
• Items that should be permanently blocked

Transactions that match the rules can clear. Exceptions are held for review before the account is charged. A Washington State Auditor’s Office guide describes this approach as screening ACH activity and allowing the organization to establish authorized vendors, dollar limits, dates, and payment frequency.¹

The distinction is operational, not merely technical:

Control	Default behavior	Best fit	What your team must operate	Primary failure mode
ACH debit block	Rejects ACH debits unless specifically permitted	Accounts that should not have ACH withdrawals	Maintain an approved exception process	A legitimate debit is rejected because no exception was created
ACH filter / ACH positive pay	Compares debits with defined rules and flags exceptions	Payroll, benefits, utilities, lenders, and recurring vendors	Maintain accurate vendor and transaction rules	A fraudulent item resembles an approved vendor or falls within a permissive rule
Positive pay for checks	Compares issued-check information with presented checks	Organizations still issuing paper checks	Upload issued-check files and review exceptions	A check exception is approved without validating the underlying request
Dual-control approval	Requires more than one person to authorize a transaction	High-value or high-risk payment workflows	Separate file creation from release approval	Two people share credentials or approve without independent verification

FFIEC guidance identifies positive pay, debit blocks, transaction alerts, business-customer administrator controls, and dual-control transactions as available customer controls.² The practical takeaway is that no single control replaces the others. A debit block limits what can enter an account; positive pay decides which expected activity is acceptable; dual control limits who can release money or change the configuration.

Which account should use each control?

Start with the account’s purpose, not the bank portal’s feature list. A simple account-by-account decision is usually more reliable than enabling every control everywhere.

Use a debit block when the account should be quiet

A debit block is appropriate when the account is intended to receive funds, hold reserves, or support a narrow process without routine ACH withdrawals. The fewer legitimate debits an account should have, the more useful a default-deny control becomes.

For example, a Modesto organization might maintain:

• A payroll funding account that receives an internal transfer and sends one controlled payroll file
• A tax reserve account that should not accept vendor withdrawals
• A capital account used only for scheduled bank-approved transfers

The key question is not “Can the bank turn on a block?” It is “Who is allowed to create an exception, how long does it last, and how is that exception removed?” A permanent exception for a vendor that was needed once is a control failure waiting to happen.

Use an ACH filter when recurring debits are part of normal operations

Healthcare clinics, school districts, local governments, and mid-market businesses often have recurring ACH debits that are legitimate but not identical every time. A filter can allow known utilities, lenders, benefit administrators, or service providers while sending unusual activity to a reviewer.

The rules should be narrow enough to be meaningful. “Allow anything from this vendor” may be convenient, but it does not answer whether the amount, frequency, account, or date is expected. A better rule might authorize a known originator, define a reasonable amount range, limit the account relationship, and require review when the pattern changes.

The Washington guidance also recommends segregating the people who can add or edit ACH blocks or filters from people involved in sending ACH payments or reconciling the account.¹ That separation matters because the person who can weaken the filter can otherwise make the later exception review meaningless.

What changed under the 2026 NACHA fraud-monitoring rules?

As of the current date, the relevant practical deadline has passed: Nacha states that the fraud-monitoring rule amendments became effective June 19, 2026, with Monday, June 22, 2026, as the practical banking-day date because June 19 was a federal holiday.³

That does not mean every business should treat a debit block or positive pay configuration as proof of compliance. The Nacha Operating Rules define obligations for Network participants, especially financial institutions and other ACH participants. Your bank may provide the control, but your organization still needs a documented process for payment initiation, approval, vendor changes, exception handling, and investigation.

Nacha also describes current fraud as exploiting weaknesses in processes and procedures—not necessarily compromising the ACH Network itself. The threat examples include business email compromise, account takeover, social engineering, ransomware, and vendor impersonation.⁴ That is why a technically correct filter can still fail when an attacker changes a vendor record before the payment file is created.

For a finance team, the 2026 question is therefore broader than “Did we enable fraud monitoring?” Ask instead:

1. Which systems can create or edit vendor banking details?
2. Which users can submit the ACH file?
3. Which users can authorize the bank to release it?
4. Who receives an exception alert, and how quickly?
5. What evidence shows that a payee was independently verified?
6. How are temporary exceptions expired and reviewed?

Where does FFIEC guidance fit for banks and credit unions?

FFIEC guidance is especially relevant to financial institutions and to businesses using digital banking services. It identifies transaction and audit logs as controls that record system and account activity to help identify unauthorized activity, reconstruct events, and promote accountability.

For a bank or credit union, that points toward more than a customer-facing toggle. The institution should consider privileged access, administrator changes, transaction velocity, login anomalies, third-party access, and timely fraud response. OCC ACH risk-management guidance likewise discusses written policies, strong internal controls, risk-based auditing, exposure thresholds, and ongoing monitoring⁵.

For the business customer, the implication is practical: ask your bank what it logs and what it alerts on, then make sure your internal records tell the same story. If the bank shows that an exception was approved but your ticketing system cannot identify the reviewer or the verification call, the organization has an accountability gap.

A useful evidence trail includes:

• The original vendor-change request
• Independent callback verification using a trusted phone number
• The person who approved the change
• The ACH file creator and file-release approver
• The exception decision and time
• Any temporary rule created in the bank portal
• The reconciliation result after settlement

Can positive pay stop a business-email-compromise payment?

Not by itself. Positive pay is strongest when the fraud produces a transaction that differs from an established rule. It is weaker when the attacker successfully changes the rule, compromises an authorized user, impersonates a legitimate vendor, or creates a payment that falls inside an overly broad amount range.

Consider a fictional example: an accounts-payable employee receives an email appearing to come from a long-standing supplier. The request changes the supplier’s bank account. The employee updates the vendor record, and the next ACH file contains a normal-looking amount. If the bank filter is based only on the originator name and a generous dollar ceiling, the fraudulent payment may pass.

The control design must therefore extend upstream of the bank portal:

Protect the vendor-master workflow

Require a second person to review changes to vendor banking data. Verify the change through a trusted channel, not a phone number or email address supplied in the request. Keep the approval record with the vendor-change ticket.

Separate payment creation from payment release

One employee can prepare or submit the ACH file, while another independently reviews the batch and authorizes release. The state auditor’s guidance specifically describes this two-person process and recommends keeping accounts-payable or payroll duties separate from ACH payment authority.

Make exceptions expire

A temporary exception for a one-time payment should have an owner, purpose, amount, and expiration date. Review the bank’s exception and filter list at a defined interval. A stale exception is not a convenience; it is an undocumented permission.

Alert on configuration changes

A transaction alert is useful, but an alert when a user adds an administrator, changes a limit, edits an originator rule, or disables a block may be even more valuable. FFIEC guidance recognizes supplementary controls for business-customer administrators who can change digital-banking configurations.

What should a Central Valley organization document before turning on the control?

We recommend a short control record for each bank account. It should answer five questions:

1. Purpose: What payments or receipts belong on this account?
2. Default: Should ACH debits be blocked, filtered, or routinely permitted?
3. Rules: Which originators, amounts, dates, and frequencies are allowed?
4. People: Who may edit rules, submit files, approve releases, and reconcile activity?
5. Evidence: Where are approvals, callbacks, alerts, and exception decisions retained?

For a school district, this may connect to payroll and recurring service vendors without disrupting the bell schedule. For a clinic, it should account for payroll, insurance-related vendors, and EHR or facility-service payments while preserving a clear approval trail. For a county or public-safety organization, the workflow may need to remain available during an incident without allowing emergency access to become permanent administrative access.

This is where an internal IT team may need more than a bank contact. The bank owns the payment feature; your organization owns identity, endpoint security, administrator access, logging, vendor workflows, and recovery when an account or user is compromised.

How Datapath helps make the control operational

Datapath does not treat ACH protection as a checkbox or as generic “IT support.” For finance organizations and credit unions, our finance IT team can help connect payment controls to identity management, administrator access, endpoint protection, logging, and vendor-risk processes.

For a local government or public-safety environment, our government and public-safety team can help document who can access sensitive systems and how an emergency workflow is reviewed afterward. Organizations that need an ongoing security operating layer can also evaluate managed cybersecurity services or a vCISO engagement to give ownership to the policy, evidence, and review cadence.

The outcome we aim for is specific: when a questionable ACH debit appears at 8:47 a.m., the right person knows whether to reject it, the bank control enforces the decision, and the organization can demonstrate how the decision was made. That is the difference between purchasing a payment feature and building accountable payment operations.

If your team is unsure whether an account needs a full debit block, a rules-based filter, or both, start with the account inventory and the people-and-permissions map. Then bring the bank, finance leadership, and IT/security team into the same conversation. You can contact Datapath to discuss that control design across your Modesto, Central Valley, Modesto, or California operations.

---

Footnotes

1. Best Practices for ACH Electronic Payments ↩ ↩²

2. Authentication and Access to Financial Institution Services and Systems ↩

3. Nacha Operating Rules - New Rules | Nacha ↩

4. Protect Your Organization From Current Fraud Threats | Nacha ↩

5. Automated Clearing House Activities: Risk Management Guidance | OCC ↩