ACH Debit Blocks and Positive Pay Under NACHA Rules: Designing the Approval Path, Not Just Flipping a Switch

ACH debit blocks and positive pay are most effective when they are part of a controlled payment workflow: authorized vendors are defined, exceptions are reviewed by the right people, account changes are validated, and every decision is logged. NACHA and FFIEC guidance support layered controls—not a single setting that replaces judgment.

At 8:02 a.m. on a Monday, a fictional Modesto credit union’s accounts-payable manager opens the treasury portal before the first branch opens. The overnight ACH batch from the accounting system is waiting for release. One debit is familiar: the organization’s payroll processor. Another is not. It uses a vendor name that looks nearly identical to a medical-supply company the credit union paid last month.

The manager’s first instinct is to reject the item. Then she notices that the amount is part of a recurring batch, the vendor’s bank account changed last week, and the change request came through an email thread rather than the vendor-management system. If she approves it, a fraudulent debit may settle. If she rejects every unfamiliar item, a legitimate payment may fail—and the operations team may spend the morning untangling a preventable outage.

That is the real ACH control decision. The question is not simply, “Do we have positive pay?” It is: Can the organization distinguish an expected debit from a suspicious one, route the exception to an accountable reviewer, and prove what happened afterward?

What do ACH debit blocks and positive pay actually do?

An ACH debit block generally prevents ACH debits from posting unless the account is configured to allow them. It is the bluntest control: useful for accounts that should never receive debits, such as a restricted collection or payroll account, but disruptive when legitimate vendors need to pull funds.

ACH positive pay is more selective. The organization or its bank establishes an allowlist, filter, or expected-payment profile. Incoming ACH debits are compared against criteria such as:

• Originator or company identification number
• Approved account or vendor relationship
• Expected transaction type
• Dollar or aggregate amount limits
• Frequency and timing
• A preapproved file or notice of intent

An exception is then held for review, returned, or approved according to the bank’s workflow. The exact capabilities vary by financial institution, so we recommend treating the bank’s feature set as an implementation detail—not as the entire control design.

Federal banking guidance identifies positive pay, debit blocks, fraud monitoring, dual authorization, and out-of-band verification as examples of controls that can be combined in a layered security program. ¹ That distinction matters. Positive pay can identify an unexpected debit, but it does not decide whether an unusual debit is fraudulent. A debit block can stop unauthorized activity, but it can also stop a critical payment. The business process around the control determines whether it protects operations or merely creates noise.

Which control should a Central Valley organization use?

The right answer depends on the account’s purpose and the consequences of a missed or delayed payment. A Modesto financial institution may need several control patterns across different accounts rather than one universal setting.

Account or payment use	Better starting control	Review model	Operational trade-off
Account should never receive ACH debits	Full ACH debit block	Exception requires deliberate bank intervention	Strongest prevention, but legitimate debits will fail
Account has a small, stable vendor set	ACH positive pay with originator allowlist	Daily exception review by treasury or AP	Good balance of prevention and usability
Account supports variable recurring debits	Positive pay with amount and frequency thresholds	Exception review for changes and outliers	Requires accurate vendor records and escalation rules
High-value or sensitive operating account	Positive pay plus dual approval and out-of-band verification	One person prepares; a second approves	Slower release, stronger resistance to account takeover
Payroll or time-critical settlement account	Narrow allowlist, schedule controls, alerts, and tested fallback	Named primary and backup reviewers	Requires coverage during leave, weekends, and holidays

A common mistake is to put every operating account on the same policy. A restricted account may be appropriate for a debit block. A supplier account may need positive pay. A high-value account may need a second approver and a transaction limit. The control should follow the account’s purpose, not the convenience of the initial setup.

How should an ACH exception move through the organization?

A control is only as reliable as the workflow behind it. We suggest documenting the path from the bank alert to the final disposition in a way that a new employee, auditor, incident responder, or vCISO can understand.

1. Identify the expected payment

Maintain a current vendor and originator register. It should record the vendor’s legal name, approved ACH company ID, business owner, contract or invoice relationship, expected cadence, and the person responsible for changes.

Do not rely on a display name alone. A fraudulent originator can use a familiar-looking name while changing the underlying company ID, account details, amount, or timing. The register should distinguish “known vendor” from “known and currently authorized debit profile.”

2. Detect the exception

Configure the bank portal to alert on events such as:

• A new ACH originator
• A changed company ID or account relationship
• A debit outside the expected amount range
• Multiple debits that exceed an aggregate limit
• A payment outside the normal schedule
• A failed or unanswered approval
• Repeated returns, invalid-account activity, or other unusual patterns

FFIEC examination guidance describes tracking, reviewing, and investigating customer complaints and unauthorized or duplicate ACH returns as part of ACH risk monitoring. ² For a business, that translates into a practical requirement: exception handling should not end when someone clicks “return.” The organization should record why the item was suspicious, who reviewed it, what evidence was checked, and whether related activity needs investigation.

3. Verify through a trusted channel

If the exception involves a vendor change, do not validate it by replying to the email that requested the change. Call a known number from the vendor record, use an established procurement portal, or require confirmation through another controlled channel.

For higher-risk payments, use dual control. One employee prepares or reviews the item; another independently approves it. Federal guidance specifically identifies dual customer authorization, transaction monitoring, and positive pay or debit blocks as examples of layered controls. ¹

4. Decide and document

The reviewer should have clear decision options:

• Approve because the payment matches an authorized profile
• Return because the debit is unauthorized
• Hold pending independent verification
• Escalate because the amount, timing, or vendor change exceeds policy
• Disable or revise the originator profile

The approval record should include the decision, timestamp, reviewer, reason, evidence used, and any follow-up ticket. This is where accountability becomes operational rather than aspirational.

5. Reconcile and learn

After the payment window closes, reconcile exceptions, returns, and approved items against the accounting system. Review trends monthly. A rise in invalid-account returns, unusual originators, or repeated manual overrides may indicate a process weakness even if no loss occurred.

OCC guidance cautions that fraud analysts should not rely only on excessive unauthorized returns; unusually high returns for other reasons, including nonsufficient funds, invalid accounts, or accounts not found, may also indicate fraud. ³ A dashboard that reports only “fraud losses” can therefore miss the early warning signs.

What does NACHA require for WEB debits?

ACH debit blocks and positive pay protect the receiving account. NACHA’s account-validation rule addresses a different point in the chain: the organization originating certain consumer WEB debits must use a commercially reasonable fraud-detection system that includes account validation for first use or a change to the account number.

Nacha states that the WEB Debit Account Validation Rule became effective March 19, 2021, and that account validation must be part of the commercially reasonable fraud-detection system for applicable WEB debits. ⁴ The rule is not a mandate to buy one particular product. Nacha identifies options such as prenotification, micro-entry verification, a commercial validation service, or an API-enabled validation capability.

The minimum validation question is whether the account is legitimate, open, and able to accept ACH entries. That is not automatically the same as proving account ownership. The appropriate level of validation depends on the originator’s business model, risk profile, return history, and compensating controls.

This distinction is important for Datapath customers. A bank or credit union may be both:

1. A receiver trying to prevent unauthorized debits from its own accounts; and
2. An originator sending debits to customers’ accounts.

Those are related but different control problems. Positive pay helps protect the organization’s account from incoming debit activity. Account validation helps reduce the chance that an organization originates a fraudulent or misdirected WEB debit in the first place.

How much monitoring is enough?

There is no single threshold that makes a payment-control program effective. The program should define risk-based thresholds that reflect the account and the business process.

For example, a finance team might define:

• A $0 tolerance for new originators on a restricted account
• A $10,000 manual-review threshold for a routine operating account
• A same-day escalation for any vendor bank-account change
• A two-person approval requirement for a high-value debit or aggregate batch
• A 15-minute review target during the bank’s exception window
• A monthly report of overrides, returns, new originators, and unresolved alerts

Those numbers are examples of internal policy choices, not NACHA requirements. They should be approved by management, tested against actual payment volume, and revised when the organization changes vendors, systems, or staffing.

The technology should also preserve evidence. Keep bank alerts, approval records, configuration changes, vendor-verification notes, and reconciliation results according to the organization’s record-retention policy. Ensure that logs identify the user, action, time, and affected account. If an employee’s credentials are compromised, the investigation should be able to reconstruct whether the attacker added an originator, changed a limit, approved an exception, or bypassed a review.

Where does an MSP fit into ACH fraud prevention?

An MSP should not pretend to be the bank, payment processor, legal adviser, or treasury-policy owner. Datapath’s role is to help make the surrounding technology and accountability dependable.

For a finance organization in Modesto, Fresno, Modesto, or one of our California markets, that can include:

• Reviewing identity and access controls around treasury portals and accounting systems
• Separating preparation, approval, and administration privileges
• Requiring phishing-resistant or otherwise stronger authentication where supported
• Monitoring unusual sign-ins, privilege changes, and administrative activity
• Protecting integration servers and payment-file locations
• Testing alert delivery and backup reviewer coverage
• Preserving logs for investigation and audit
• Coordinating with the bank, software vendors, leadership, and incident-response contacts

Our finance IT team can help define the operating model, while managed cybersecurity services can provide ongoing monitoring and escalation. If the organization already has an internal IT department, co-managed IT may be the better fit for tightening identity, logging, and endpoint controls without displacing the team that owns treasury operations.

The highest-risk failure is often not a missing feature. It is an alert that reaches nobody, a backup reviewer who cannot access the portal, an administrator who can both change the allowlist and approve the payment, or a vendor change that cannot be independently verified.

A practical review checklist

Before enabling or revising ACH debit blocks and positive pay, we recommend asking:

• Which accounts should never accept ACH debits?
• Which originators are authorized on each operating account?
• Does the bank filter by company ID, name, amount, account, or another attribute?
• Who receives exceptions, and who is the named backup?
• What requires two-person approval?
• How is a vendor change verified outside the initiating email or ticket?
• What happens if an exception is missed before the bank’s cutoff?
• Can the organization export approval and configuration-change logs?
• How are returns, invalid accounts, and repeated overrides reviewed?
• Has the workflow been tested with a simulated exception recently?

We also recommend an annual review after major changes such as a new ERP, bank, treasury portal, payment processor, acquisition, or staffing change. The control may still be enabled, but the people, integrations, and assumptions around it may no longer be accurate.

The outcome: fewer silent failures and clearer accountability

NACHA Operating Rules and FFIEC payment-fraud guidance point toward the same practical lesson: payment security is a system of controls and decisions. Debit blocks reduce exposure. Positive pay narrows what can post. Account validation helps applicable WEB debit originators verify account usability. Monitoring, dual control, independent verification, and usable logs make those controls workable in the real world.

Datapath helps regulated and mid-market organizations turn those pieces into an operating process with named owners, tested escalation paths, and technology that supports—not obscures—accountability. If your current process depends on one treasury employee noticing every exception before a cutoff, start there. A conversation with our vCISO or vCIO team can help map the bank control to the people, systems, and evidence needed to keep the payment workflow dependable.

^{1 2 3 4}

---

Footnotes

1. Fetched web page ↩ ↩² ↩³

2. FFIEC BSA/AML Risks Associated with Money Laundering and Terrorist Financing - Automated Clearing House Transactions ↩ ↩²

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

4. Supplementing Fraud Detection Standards for WEB Debits | Nacha ↩ ↩²