ACH debit blocks stop unauthorized pulls by default; ACH positive pay adds a review path for exceptions. Under Nacha’s risk-based fraud-monitoring direction and FFIEC layered-security guidance, the stronger design is not choosing one blindly—it is matching the control to each account, documenting who can approve exceptions, and making the response work at 4:47 p.m. on a real operating day.
At 4:47 p.m. on a Thursday, the controller at a Modesto credit union is reviewing the next morning’s cash position when the bank portal flags an ACH debit from a payroll-tax processor. The company ID looks familiar, but the amount is 38% higher than the prior filing because a payroll correction was processed.
The controller has two choices. If the account has a hard ACH debit block, the debit may be rejected—even though it is legitimate. If the account uses ACH positive pay, the debit can enter an exception queue, where someone must decide whether to pay or return it before the bank’s cutoff.
That is the operational question many finance teams skip: not “Do we have fraud protection?” but “Who makes the pay/no-pay decision, using what evidence, within what time window, and what happens when that person is unavailable?”
For a Modesto healthcare organization, local government department, credit union, or mid-market company, that workflow matters as much as the bank product. A control that blocks fraud but interrupts payroll, vendor settlement, or a critical supplier payment can create a different kind of business incident.
What is the difference between an ACH debit block and positive pay?
An ACH debit block is primarily a prevention control. It tells the financial institution to reject ACH debits unless the account has been configured to permit them, often through an approved originator list or account-level exception. It is a good fit for accounts that should not receive routine ACH pulls.
ACH positive pay is primarily a detection-and-decision control. The bank monitors incoming ACH activity, identifies transactions that do not match the organization’s expected profile or authorization data, and presents exceptions for review. Nacha describes ACH positive pay as providing monitoring, reporting, and controls to identify unauthorized or high-risk transactions.1
The distinction is important:
- Debit block: “Do not let ACH debits through unless explicitly permitted.”
- Positive pay: “Show me the transactions that need a pay/no-pay decision.”
- Account validation and vendor controls: “Confirm that the payment instruction and counterparty are expected before release.”
- Dual control: “Do not let one compromised account or one employee complete the entire payment process.”
FFIEC guidance specifically identifies positive pay, debit blocks, transaction alerts, and dual-control transactions as customer controls that can help business customers monitor and control account activity.1 The guidance does not suggest that one control eliminates the need for the others. Its broader model is layered security: multiple preventative, detective, and corrective controls designed to compensate when one layer fails.
Which accounts should use a debit block?
A debit block is usually strongest where the legitimate ACH debit population is either zero or very small and predictable.
Examples include:
- A reserve account that should only receive credits.
- A bond, grant, or capital-project account with no recurring vendor debits.
- A school district account used for a narrow program where approved withdrawals are handled through a separate process.
- A healthcare organization’s account reserved for incoming reimbursements, not supplier payments.
- A municipal account where ACH withdrawals are not part of the normal operating workflow.
The design question is not simply whether the organization wants “maximum security.” It is whether the account’s legitimate activity can be described precisely enough to avoid unnecessary exceptions.
For example, a Modesto public agency might place a debit block on a restricted account used for incoming program funds. Its operating account, however, may need positive pay because approved debits include payroll taxes, benefits, utilities, software subscriptions, and vendor settlements. Applying the same setting to both accounts creates avoidable friction.
A debit block also needs an exception process. Someone must know which originators are authorized, who can add or remove an originator, how changes are verified, and how the bank is contacted when a legitimate debit is rejected. Those are access and change-management questions—not merely treasury settings.
When is ACH positive pay the better fit?
Positive pay is generally more practical when an account has recurring, legitimate ACH debit activity but the organization still wants an opportunity to stop suspicious transactions.
That describes many Datapath customers:
- A mid-market employer with several payroll and benefits providers.
- A clinic with recurring payments to clearinghouses, suppliers, and service vendors.
- A credit union or financial-services organization managing multiple operating accounts.
- A county department paying approved vendors through a central treasury workflow.
- A school district with recurring transportation, food-service, facilities, and payroll-related debits.
Positive pay only improves security if the exception queue is owned. The bank may identify the anomaly, but the organization still needs a documented operating procedure for reviewing it. That procedure should define the reviewer, backup reviewer, approval evidence, deadline, escalation path, and post-decision reconciliation.
A useful exception record should answer:
- Who is the originator?
- Does the company ID match the approved vendor record?
- Was a payment expected today?
- Does the amount fall within the normal range or an approved variance?
- Did anyone recently change the vendor’s bank or ACH instructions?
- Was the change verified through a known telephone number or another trusted channel?
- Who approved the pay or return decision?
The workflow should not rely on an email that says, “Yes, that debit is fine.” Business email compromise frequently uses messages that appear to come from a known source while requesting a legitimate-looking payment action.2 A safer process uses an independent verification path for unusual payment changes or high-risk exceptions.
What does NACHA compliance change in 2026?
The Nacha Operating Rules are the foundation for ACH payments and define responsibilities for participants in the ACH Network.3 Their fraud-monitoring direction reinforces a point that matters to operating companies: fraud controls need to be risk-based, documented, and reviewed as threats change.
Nacha’s published implementation material states that Phase 1 took effect on March 20, 2026, for ODFIs and certain high-volume originators, third-party senders, and third-party service providers. Phase 2 took effect on June 19, 2026, removing the volume threshold for non-consumer originators, third-party service providers, and third-party senders.3
The rules require covered participants to establish and implement risk-based processes reasonably intended to identify entries that are suspected of being unauthorized or authorized under false pretenses, and to review those processes at least annually.3 They do not prescribe one specific software product or require every ACH entry to be screened individually.
For a finance team, that means the control environment should be explainable. You should be able to show:
- Which accounts are protected by debit blocks, positive pay, or other controls.
- How authorized originators and vendors are established.
- How payment-instruction changes are verified.
- How unusual volume, velocity, dollar amount, or timing is detected.
- How exceptions are handled and documented.
- When the procedure was last reviewed and what changed.
Nacha also emphasizes that fraud threats often exploit gaps in processes and procedures rather than directly compromising the ACH Network.4 That is why a technically capable bank portal cannot substitute for clear ownership inside the organization.
What does FFIEC payment-fraud guidance expect from the workflow?
FFIEC’s authentication and access guidance points financial institutions toward layered controls, monitoring, logging, reporting, transaction limits, and least-privilege access. It specifically identifies positive pay, debit blocks, automated alerts, and dual-control transactions as available customer controls.1
For a finance or credit-union environment, the practical translation is a four-layer workflow:
| Layer | Control | Operating question | Failure it helps contain |
|---|---|---|---|
| Prevent | Debit block or approved-originator list | Should this account permit ACH debits at all? | Unauthorized originator pulls |
| Detect | ACH positive pay, alerts, and transaction monitoring | Does this debit match expected activity? | Amount, timing, velocity, or vendor anomalies |
| Approve | Dual control and separation of duties | Can one person create and release the decision? | Stolen credentials or insider error |
| Recover | Reconciliation, incident response, and bank escalation | What do we do when a suspicious debit is identified? | Delayed detection and incomplete response |
The NCUA examiner guidance provides a useful model for payment operations: timely posting, balancing and reconciliation; logical and physical access controls; dual controls; user limits and transaction thresholds; and exception handling. It also states that ACH origination files should be processed and approved by separate individuals.5
Even if your organization is not a credit union, the operating principle is broadly useful: separate payment preparation from payment approval, and make the system enforce that separation where possible.
How should a business design the exception decision?
Start with the account, not the product brochure. Build an inventory of every account that can send or receive ACH activity and classify its normal purpose.
1. Define the account’s expected behavior
Document whether the account should have no debits, a fixed group of recurring debits, or a wider vendor population. Record typical originators, expected frequency, normal amount ranges, and acceptable timing windows.
2. Choose the control combination
Use a debit block where the legitimate debit population is tightly constrained. Use positive pay where legitimate activity is routine but variable. Use both across different accounts when the organization’s cash structure supports it.
3. Protect configuration changes
Changing an approved originator, exception rule, user, alert recipient, or transaction limit can be as consequential as approving a payment. Require MFA, role-based access, logging, and independent review for those changes. The FTC’s Safeguards Rule guidance calls for MFA, monitoring authorized-user activity, detecting unauthorized access, and maintaining documented incident-response processes for covered financial institutions6.
4. Make the bank cutoff part of the procedure
Write down when exceptions arrive, when they must be reviewed, who is the backup, and how an urgent decision is escalated. A control that depends on one controller checking email at the end of the day is not a resilient control.
5. Test the process
Run a controlled test using a harmless exception or bank-approved test procedure. Confirm that the alert arrives, the reviewer can access the queue, the second approver is available, the decision is recorded, and the reconciliation report reflects the result.
Where does IT fit if the bank owns the payment portal?
The bank may provide the debit block or positive-pay capability, but your IT environment still controls many of the pathways attackers use to reach payment authority.
Datapath’s role is to help connect the treasury workflow to the rest of the organization’s security program. That can include:
- Protecting Microsoft 365 identities and administrator accounts with MFA and conditional access.
- Reviewing who can access banking devices, payment folders, shared mailboxes, and vendor records.
- Monitoring mailbox rules, suspicious sign-ins, and unusual access patterns.
- Separating payment workstations from general browsing where the risk justifies it.
- Documenting vendor-change verification and escalation procedures.
- Testing incident response when a credential, mailbox, or payment instruction may be compromised.
For a Modesto finance organization, that may mean working with our finance and financial-services team or using managed cybersecurity services to monitor the identity, endpoint, and email controls surrounding the bank portal. For a county or public-safety environment, the same workflow can be coordinated through our government and public-safety team, where accountability and continuity are part of the operating requirement.
We also help organizations turn a bank control into a repeatable process: named owners, documented evidence, escalation rules, and a tested recovery path. If a payment exception appears while the primary approver is out, the organization should not be improvising.
The practical decision
Choose an ACH debit block when the account should reject almost every debit and the approved exceptions are rare and tightly controlled. Choose ACH positive pay when legitimate debit activity is expected but the organization needs visibility and a pay/no-pay decision. In larger environments, use both controls across different account types.
Then connect the treasury setting to identity security, dual control, transaction limits, alerting, reconciliation, and incident response. That is the difference between buying a fraud feature and building an accountable payment-control system.
If your team is unsure which accounts should be blocked, which should use positive pay, or who owns the exception queue, Datapath can help map the workflow before a fraud event—or a rejected legitimate payment—forces the issue. Start with a conversation through our contact page and bring your bank’s current control options, account list, and approval workflow.
