ACH Debit Blocks and Positive Pay: The Payment Controls Central Valley Organizations Actually Need

When a Modesto healthcare clinic approves an ACH file, the critical question is not simply whether the bank can send it. The question is whether the file, account, vendor, dollar amount, and approver match the clinic’s intended payment workflow. ACH debit blocks and positive-pay-style controls provide that checkpoint—but only when they are designed, monitored, and owned by named people.

At 8:42 a.m. on a Tuesday, a Modesto clinic’s accounts-payable coordinator is preparing the payroll and vendor ACH file in the accounting system. A vendor’s bank account was changed the afternoon before after an email that appeared to come from the vendor’s controller. The file is ready to upload to online banking. The clinic’s controller is about to approve it from a different workstation.

That is the moment where payment security becomes an operating decision. Should the bank accept every debit presented to the account? Should the new vendor account be allowed immediately? Who confirms the change, and who has authority to release the file if the bank flags a transaction?

A payment control that merely exists in a banking portal will not answer those questions. The control has to fit the workflow.

What do ACH debit blocks and positive pay actually do?

An ACH debit block is a bank-side control that prevents unauthorized ACH debits from posting to an account unless the transaction is permitted under the bank’s configuration. An ACH filter or ACH positive-pay product generally adds more granularity: authorized vendors, transaction limits, payment frequency, effective dates, or exception decisions.

The terminology varies by bank. Some institutions call the control ACH positive pay; others use ACH filter, debit filter, ACH fraud control, or a similar product name. Before comparing features, ask the bank to explain exactly what happens when a transaction does not match the rules:

• Is the transaction automatically returned or held for review?
• Who receives the exception alert?
• How long is the decision window?
• Can an employee approve an exception alone?
• Are credits and debits treated differently?
• Can the bank enforce vendor, amount, date, and frequency rules?
• Is there an audit record of the decision?

FFIEC guidance identifies positive pay, debit blocks, and other techniques as controls available to business customers to monitor and control transactions on their accounts.¹ That wording matters. These tools are not a substitute for access governance or transaction review; they are one layer in a broader control system.

Positive pay can also mean traditional check positive pay. In that model, the organization sends the bank a file containing issued checks, and the bank compares presented checks against that file. For ACH, the comparable question is whether the bank’s product can compare incoming debits against approved counterparties and rules. Do not assume that a bank’s “positive pay” label means the same thing for checks, ACH debits, and commercial-card transactions.

Why a debit block is not enough against a vendor-change scam

A debit block is strongest when the organization already knows which debits should be allowed. It is weaker when the attacker changes the vendor record before the payment file is created.

Consider the Modesto clinic again. If the attacker’s new account is added to the accounting system and then included in an otherwise legitimate ACH file, a bank control that only asks whether the transaction came from the clinic’s account may not detect the fraud. The payment is authorized from the bank’s perspective, even though the vendor change was fraudulent.

That is why the payment process needs two separate checkpoints:

1. Vendor-master verification: Is the requested bank-account change legitimate?
2. Bank transaction control: Does the resulting payment match an approved account, vendor, amount, timing, and frequency?

The FBI recommends verifying payment and purchase requests in person or by calling the requester, and specifically says to verify changes in account numbers or payment procedures.² The verification should use a trusted phone number or previously established contact method—not the phone number included in the change request.

Nacha’s account-validation rule for WEB debits likewise focuses on validating an account before its first use and before a change to the account number. The minimum described by Nacha is determining that the account is legitimate, open, and able to accept ACH entries; depending on the organization’s risk profile, verifying account ownership may also be appropriate.³

For a mid-market business, a practical policy is simple: no vendor banking change becomes payable merely because an employee updated the ERP record. The change needs independent confirmation, documented approval, and—where appropriate—account validation before the first payment.

What does NACHA require in 2026?

Nacha’s 2026 fraud-monitoring amendments create a broader operational expectation for non-Consumer Originators, Third-Party Service Providers, and Third-Party Senders. For entities covered in the second phase, the effective date is June 19, 2026, with the practical banking date identified as June 22, 2026. The rule requires risk-based processes and procedures reasonably intended to identify ACH Entries initiated due to fraud, with processes reviewed at least annually.³

The important distinction is between a product and a process. Nacha does not turn an ACH debit block into a complete fraud program. A block or filter may help detect an unexpected debit, but the organization still needs to decide:

• What behavior is unusual for this account?
• Which payment changes require enhanced verification?
• What transaction amounts or frequencies require dual approval?
• How are exceptions investigated and documented?
• How quickly are controls adjusted after a fraud attempt?

A small school district, clinic, county department, or business may not need the same rules as a national payment processor. It does need a defensible risk-based process that reflects its payment volume, staffing, systems, vendors, and exposure.

How FFIEC guidance changes the control conversation

FFIEC guidance is directed at financial institutions, but it offers a useful design reference for any organization working with its bank. It calls for risk assessment, identification of users who may need enhanced authentication, layered security, monitoring, logging, and reporting.¹

It also describes controls relevant to business customers, including transaction limits, positive pay, debit blocks, transaction alerts, system-administrator controls, and dual-control transactions.¹

That gives us a more useful model than “turn on positive pay.” A bank-payment workflow should have several independent layers:

Control layer	What it checks	Example operating decision	Owner
Identity and access	Who can enter online banking or the ERP?	Require MFA and remove access immediately when a finance employee changes roles	IT/security and finance leadership
Vendor change control	Is the new account information legitimate?	Verify through a known phone number and retain evidence of the callback	Accounts payable manager
ACH account rule	Does the debit match an approved counterparty or rule?	Allow recurring utilities but hold a new vendor or unusual amount	Bank administrator and controller
Transaction approval	Is the file accurate and independently approved?	One employee uploads; a second authorized person reviews and releases	Controller or treasurer
Monitoring and alerting	Did activity depart from the baseline?	Escalate a new payee, unusual velocity, or unexpected debit	Security operations and finance
Response and recovery	What happens when fraud is suspected?	Freeze access, contact the bank, request recall, preserve logs	Incident lead and bank contact

FFIEC describes layered security as multiple preventative, detective, and corrective controls that compensate for weaknesses in any one control. It also emphasizes least privilege, transaction limits, monitoring, and stronger controls for higher-risk activity.¹

For Datapath customers, this is where managed cybersecurity and finance operations should meet. A security team may see a suspicious mailbox rule or login. Finance may see a new vendor account or a changed payment amount. Neither team has the complete picture alone.

What should an ACH exception workflow look like?

A good workflow is short enough to follow during a busy payment run and specific enough to create accountability.

1. Establish account purpose

Use a dedicated account for ACH activity when appropriate. Define whether it is used for payroll, vendors, tax payments, or another purpose. Separate payment functions where the bank and accounting design allow it. A dedicated account with clear limits makes unexpected activity easier to identify.

2. Build the approved rule set

Start with the organization’s real payment behavior. Identify recurring vendors, normal payment ranges, expected frequency, and seasonal exceptions. Do not create an allowlist nobody maintains. Assign an owner and a review cadence.

For example, a county department might allow recurring software and utility vendors but require review for a newly added contractor. A healthcare clinic might use different rules for payroll, medical suppliers, rent, and insurance payments. A K-12 district may need to account for predictable payroll cycles, transportation vendors, and annual spikes in curriculum or facilities purchases.

3. Separate file creation from release

One employee should prepare or submit the ACH file. A second person should verify the batch and authorize release. FFIEC identifies dual-control transactions as an available business-customer control.¹

The second approver should not simply click “approve.” The review should compare the bank file or batch summary against the accounting report, including total amount, number of entries, new payees, changed payees, and unusual amounts.

4. Handle exceptions deliberately

An exception should not become an automatic approval because the deadline is approaching. The reviewer should document the decision, the evidence used, and the person who approved it. If the payment is legitimate but outside the existing rule set, update the rule through a controlled process rather than bypassing the control indefinitely.

5. Reconcile and investigate

Reconciliation should identify both unauthorized transactions and control failures. A payment may be legitimate but still reveal that an employee bypassed a required approval or that a vendor record changed without documentation.

How should organizations prepare for a suspected fraudulent transfer?

If a suspicious ACH debit or payment is discovered, speed matters. The organization should maintain a current bank-fraud contact, escalation list, and decision authority before an incident occurs.

The FBI advises organizations to contact their financial institution immediately when a BEC scam occurs and request that the receiving institution be contacted.⁴ IC3 likewise advises victims to contact the financial institution immediately and request a recall of the funds; it also recommends filing a complaint regardless of the amount lost.⁴

A response checklist should include:

• Stop or suspend additional payment files if compromise is suspected.
• Disable or restrict affected banking and email accounts.
• Contact the originating bank’s fraud team using a known number.
• Request a recall and ask what indemnification or recovery documents are required.
• Preserve email headers, vendor-change records, approval logs, bank alerts, and endpoint evidence.
• Identify whether other vendors, employees, or accounts may be affected.
• Document the timeline for management, counsel, insurers, and law enforcement.

This is also why evidence retention belongs in the payment-control design. If the organization cannot show who changed a vendor record, who approved the file, what the bank flagged, and what verification occurred, it will be harder to investigate and improve the process.

Where do MFA, monitoring, and service providers fit?

ACH controls should not be isolated from the rest of the security environment. FFIEC guidance emphasizes monitoring, logging, reporting, transaction controls, and stronger authentication for high-risk activity.¹ The FTC Safeguards Rule, for covered financial institutions under its jurisdiction, describes risk assessment, safeguards, MFA, activity logging, monitoring, testing, employee training, and service-provider oversight.⁵

That does not mean every Datapath customer is subject to the FTC Safeguards Rule. It does mean the control pattern is familiar: identify the risk, assign safeguards, monitor whether they work, and review the people and providers operating them.

For a finance organization, Datapath can help connect the pieces through managed cybersecurity, a vCISO engagement, or vendor risk management. For a clinic, the payment workflow may need to be coordinated with the broader healthcare IT environment. For a city or county handling public-safety operations, the same accountability model can support a broader government and public-safety IT program.

The goal is not to sell a generic checklist. It is to make sure the bank control, accounting system, identity platform, email, endpoint monitoring, and incident-response process agree about who may do what.

Is positive pay worth the operational effort?

Usually, the better question is not whether positive pay is “worth it” in the abstract. Ask whether the organization can operate the exception process consistently.

Positive pay or an ACH filter is a strong candidate when the organization has recurring payments, meaningful exposure, multiple finance users, or limited tolerance for an unauthorized debit. It is less useful when alerts go to an unattended inbox, no one knows the decision deadline, or staff routinely bypass exceptions.

Before enabling a control, document five decisions:

1. Which accounts will be protected?
2. Which transactions should be automatically allowed?
3. Which transactions require human review?
4. Which two people can approve or release payments?
5. What evidence must be retained after each exception or vendor change?

Then test the process with a controlled, authorized exception. Confirm that the alert arrives, the right people receive it, the decision is recorded, and the transaction behaves as expected. A control that has never been tested is an assumption.

The Datapath standard: payment accountability, not a portal setting

For organizations in Modesto, Fresno and the Central Valley, Modesto, and communities such as Modesto in California, payment security has to work across local teams, banks, vendors, and business systems.

Datapath helps customers build that operating model around outcomes: uptime, accountability, regulated-industry readiness, and a named team responsible for follow-through. Depending on the environment, that may involve co-managed IT for an in-house finance or IT department, managed IT services for broader operational coverage, or an incident response retainer for rapid escalation.

ACH debit blocks and positive pay are valuable controls. They become materially stronger when they are tied to independent vendor verification, dual approval, least-privilege access, monitored exceptions, documented evidence, and a tested response plan. That is the difference between buying a banking feature and building a payment process that can withstand a real Tuesday morning.

---

Footnotes

1. Fetched web page ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. Business Email Compromise — FBI ↩

3. http://nacha.org/rules/risk-management-topics-fraud-monitoring-phase-2 ↩ ↩²

4. Internet Crime Complaint Center (IC3) | Business Email Compromise: The $55 Billion Scam ↩ ↩²

5. FTC Safeguards Rule: What Your Business Needs to Know | Federal Trade Commission ↩