ACH debit blocks and positive pay are not interchangeable, and neither is a substitute for an approval workflow. A Modesto finance team needs to decide which transactions may reach the account, which exceptions require review, and who can release funds—then make those controls observable, tested, and accountable.

At 8:17 a.m. on a payroll Friday, a controller at a Modesto manufacturer opens the bank portal to release the ACH file. The file contains payroll, a tax payment, and a vendor update approved the previous afternoon. Before clicking “submit,” she notices a new debit exception: an unfamiliar originator is attempting to pull funds from the same operating account.

The question is not simply whether the bank offers an ACH block. The decision is whether the account should reject every unauthorized debit automatically, whether approved vendors and limits should be maintained in an ACH filter or positive-pay service, and whether a second person must review the payment file before funds leave. If those controls are split across a bank portal, an accounting application, and an email inbox, the organization may have tools without having a defensible process.

For Datapath customers in finance, local government, healthcare, and mid-market business, that distinction matters. We help organizations build the operating model around the control—not merely turn on a feature.

What does an ACH debit block actually do?

An ACH debit block is a broad preventive control. Working with the bank, an organization can block ACH debits on an account that should not receive them, or restrict the account so that only specifically permitted activity can proceed. The Washington State Auditor’s Office recommends using ACH blocks on accounts not authorized for ACH transactions and describes an ACH filter—also called ACH positive pay—as a way to screen activity before the bank deducts funds.¹

That makes a debit block particularly useful for account segmentation:

A payroll account may accept only payroll-related debits and credits.
A tax or benefits account may be funded for a specific run and otherwise remain lightly used.
A reserve account may have no reason to accept ACH debits at all.
A dedicated ACH account can be maintained with a low or zero balance except when a payment run is ready.¹

The control is strongest when the account’s purpose is narrow. A single operating account supporting payroll, vendor payments, tax withdrawals, loan debits, and miscellaneous subscriptions is harder to protect with a simple block because legitimate activity and suspicious activity share the same doorway.

A block also does not answer every question. It may stop an unauthorized debit, but it does not determine whether a legitimate-looking vendor change was approved, whether the ACH file was altered after the controller reviewed it, or whether the person releasing funds should have been able to edit the bank rule.

What does positive pay add?

Positive pay adds transaction-level decisioning. Instead of treating every debit as equally permitted—or equally forbidden—the organization provides the bank with rules such as authorized originators, dollar limits, effective dates, and payment frequency. The bank permits matching transactions and flags exceptions for review.¹

The important word is “exception.” Positive pay creates a queue that someone must own. A notification sent to a shared mailbox is not the same as an accountable review. The organization should decide:

Who receives the exception alert?
How quickly must an exception be reviewed?
What evidence is required before it is released?
Who can change an approved originator, limit, or date range?
How is the decision retained for later investigation?

For example, a finance team might authorize a recurring utility debit within a defined range while flagging a first-time vendor debit or an amount outside the expected limit. The exact thresholds should be based on the organization’s payment patterns and risk tolerance—not copied from a generic checklist.

Debit block vs. ACH positive pay

Control	Primary decision	Best fit	What it does not solve	Operational owner
ACH debit block	“Should this account accept ACH debits at all?”	Reserve, restricted, or purpose-specific accounts	File approval, vendor-change verification, and release accountability	Treasury and bank administrator
ACH positive pay/filter	“Does this debit match an approved rule?”	Active accounts with recurring but distinguishable ACH activity	Poorly maintained rules or unattended exceptions	Treasury or accounts-payable reviewer
Dual authorization	“Has a second authorized person approved release?”	Payroll, vendor batches, tax payments, and other high-impact files	A fraudulent request that both people fail to verify	Finance manager and approver
Transaction logging and monitoring	“What happened, who did it, and when?”	Organizations needing investigation, accountability, and audit evidence	Prevention by itself	IT/security plus finance

The practical answer is often layered: use a block or filter at the bank, dual approval for release, and logging and monitoring around the users and systems that administer the process.

How do NACHA Operating Rules fit into the control design?

The NACHA Operating Rules establish roles and responsibilities for ACH Network participants and are organized by effective date.² That is important context, but it does not mean NACHA prescribes one universal bank configuration for every organization. The organization still has to determine how its account structure, authorization process, fraud monitoring, and bank services work together.

For WEB debit entries, NACHA requires Originators to use a commercially reasonable fraudulent-transaction detection system. The rule specifically makes account validation part of that system, including validation before an account number is used for the first time and before an account number is changed.³

That requirement points to a broader operational lesson: a control that checks whether an account is open and can accept ACH entries is not necessarily the same as a control that verifies the legitimacy of the person requesting the change. NACHA’s guidance states that the minimum validation standard is determining whether the account is valid, open, and able to accept ACH entries; it also explains that an Originator may need to consider its own business model and risk profile when deciding whether additional verification is appropriate.³

In a real workflow, that means an account-number change should not be treated as a clerical update. It should trigger a verification path, management review, and a record of what was checked before the change reaches the payment file.

What does FFIEC payment-fraud guidance expect from a financial institution?

FFIEC guidance describes layered security controls for business customers, including transaction alerts, business-customer system-administrator controls, dual-control transactions, transaction and audit logs, fraud and anomaly detection, and suspicious-behavior monitoring⁴.

The key idea is not that every business must deploy a named product. It is that controls should address different failure points:

Prevention: block or filter unauthorized debits.
Detection: alert on unusual originators, amounts, velocity, or user behavior.
Approval: require more than one person to authorize selected transactions.
Accountability: record who changed a rule, submitted a file, approved it, or released funds.
Response: define what happens when an exception is suspicious or a credential is compromised.

FFIEC’s description of transaction and audit logs is especially relevant to a managed IT and cybersecurity program: logs help identify unauthorized activity, detect intrusions, reconstruct events, and promote customer and user accountability. A bank portal may retain its own history, but the organization should also understand how identity, endpoint, email, and administrative events are monitored around the payment workflow.

For a credit union or bank, this may be part of a wider financial-institution control environment. For a mid-market business, it is still a material fraud-risk process even when the organization is not itself a regulated financial institution. In both cases, the question is whether the control can be demonstrated after an incident—not merely whether the feature appears in the bank’s product menu.

Who should approve ACH payments?

Segregation of duties is where many otherwise sensible configurations fail. The Washington State Auditor’s Office recommends requiring two people to send ACH payments: one submits the ACH file, and a second—preferably a supervisor or manager—authorizes the bank to release the funds after verifying the batched transactions.¹

It also recommends separating accounts-payable or payroll duties from ACH-payment duties, so a person who processes payroll or accounts payable cannot also process ACH payments or alter banking information.¹

A workable approval sequence might look like this:

Accounts payable prepares the payment batch in the accounting system.
A designated reviewer compares the batch to invoices, payroll records, or approved payment schedules.
The file is uploaded by a different user.
The approver signs in through a separate account and confirms the total, count, date, and exception status.
The bank releases the file only after the second approval.
The organization retains the approval record and reconciles the account afterward.

For a county IT department or public-safety organization, the same logic applies even if the payment workflow is not part of dispatch operations. Access to a bank rule, payment file, or vendor record should be treated as a privileged business function. A person who can edit the ACH filter should not quietly be the same person who reconciles the resulting transactions and approves the payment run.

Datapath can help an in-house IT or finance team map those roles, tighten privileged access, and connect the workflow to a broader managed cybersecurity program.

Where do ACH controls commonly break?

The “everything is blocked” configuration

A block is enabled, but legitimate transactions fail because no one documented which account is allowed to receive which debits. Finance then disables the control during an urgent payment run and forgets to restore it. The result is a control that exists on paper but is unreliable under pressure.

The stale positive-pay list

An old vendor remains authorized after the relationship ends. A new vendor is added by email without independent verification. A recurring debit amount changes, but the rule remains broad enough to accept it. Positive pay is only as useful as the quality and review discipline behind its rules.

The shared administrator account

A bank administrator account is shared by treasury, an IT generalist, and an outside service provider. When a rule changes, the organization cannot establish who made the change or whether the session was legitimate. FFIEC’s emphasis on system-administrator controls and audit logs is directly relevant here.

The approval that verifies only the total

A second person approves the batch because the total appears normal, but does not inspect the vendors, account changes, or unusual entries. Dual control becomes a second click rather than an independent check.

The alert nobody owns

An exception notification reaches a distribution list during a holiday or payroll deadline. No documented escalation path exists, and the transaction is released by default. Detection without a response owner is not a complete control.

How should a Modesto organization choose the right combination?

Start with the account, not the product. For each account, document its purpose, expected ACH activity, permitted originators, normal dollar range, review window, and emergency procedure. Then classify the account:

No ACH purpose: block ACH debits and monitor for attempted activity.
Limited recurring purpose: use a narrow filter with named originators and defined limits.
High-volume payment purpose: use positive pay, dual authorization, and exception review.
High-impact or time-sensitive purpose: add tested escalation, alternate approvers, and incident-response procedures.

Next, test the process. A useful exercise is a controlled exception: ask the bank how an unapproved debit appears, who receives the alert, how it is rejected, and what evidence is generated. Separately, test whether a departing employee’s access is removed from the bank portal, accounting platform, password manager, and notification channels.

For organizations with roughly 100 or more employees, this is often the point where informal knowledge stops scaling. A named owner, documented runbook, privileged-access review, and recurring test provide more accountability than a one-time configuration project. Datapath’s vCISO services can help leadership turn the payment workflow into an owned security program, while co-managed IT can augment an internal team that needs help with monitoring, documentation, and access reviews.

The buyer’s checklist for a bank and MSP conversation

Bring these questions to the bank, finance leadership, and IT/security team:

Can this account accept ACH debits, and should it?
Is the account protected by a full block, a filter, or transaction-level positive pay?
Which originators, amounts, dates, and frequencies are authorized?
Who can add or edit those rules?
Does the bank require dual approval, and are approvers using individual accounts?
Who owns exception review, and what is the response deadline?
Are payment-file creation, upload, approval, and release separated?
How are vendor banking changes independently verified?
Where are bank, identity, endpoint, and administrative logs retained?
When was the last controlled test of an exception and an access-removal process?

The goal is not to buy the most complicated package. It is to make an unauthorized debit difficult to execute, an unusual transaction visible, a legitimate exception reviewable, and every material decision attributable to a named person.

Build the control around accountability

ACH debit blocks and positive pay are valuable because they move fraud prevention closer to the account. NACHA’s account-validation and fraud-detection expectations, FFIEC’s layered-control guidance, and public-sector payment-control recommendations all point toward the same practical design: prevention, independent approval, monitoring, and evidence must work together.

For a Modesto finance team—or a healthcare clinic, school district, county department, credit union, or Central Valley business—the right configuration depends on how money moves through the organization. We can help you document that workflow, identify where a single user has too much authority, and coordinate the technology and operating procedures around it.

Start with a conversation about your accounts, approval paths, and exception process through Datapath’s contact page. You should leave with more than a product recommendation: you should know who owns the control, how it will be tested, and what happens when the screen shows something that does not belong.

Healthcare

K-12 Districts

Financial Services & PE

Government

Unified Platform Overview

Managed IT Services

Co-Managed IT

Local Managed IT

Cybersecurity Services

Managed IT in Modesto

Managed IT in Fresno

Managed Cybersecurity

Continuous Protection

Operational Stability

Strategic Accountability

ACH Debit Blocks and Positive Pay: Where NACHA Guidance Meets the Approval Screen