ACH blocks and filters are most effective when they define a payment decision before money moves: what is automatically denied, what is matched against an approved rule, who reviews exceptions, and what happens at cutoff. For a Modesto finance team, the goal is controlled throughput—not simply blocking every ACH debit.

At 10:42 on a Tuesday morning, the treasury manager at a Modesto community bank is reviewing the day’s outgoing payments. Payroll is queued in the ERP. A recurring debit from the district’s payroll-tax provider is expected. Then an ACH exception appears: a familiar vendor name, but a company identifier the bank has never seen and an amount $18,000 higher than last month.

The manager has minutes to decide. Approve it, and a compromised vendor mailbox or altered account record may become a real loss. Return it, and payroll or a tax filing could fail. Leave it untouched, and the bank’s cutoff rule may make the decision automatically.

That is the real purpose of ACH blocks and filters. They are not just banking features. They are operating rules that connect your accounting system, bank portal, people, authentication controls, and incident-response process.

Financial institutions commonly offer positive pay, debit blocks, transaction alerts, and dual-control approvals to help business customers monitor and control account activity.¹ Those controls are related, but they do not make the same decision.

Control	Default decision	Best fit	Human workflow	Main failure mode
ACH debit block	Deny ACH debits unless a specific exception is permitted	Accounts that should rarely receive ACH debits	Review only legitimate exceptions	A legitimate recurring debit is returned or delayed
ACH debit filter	Allow transactions matching approved rules; flag or return mismatches	Vendor-heavy accounts with repeatable payment patterns	Treasury reviews new vendors, changed amounts, and unmatched items	An overly broad rule allows an unexpected debit
ACH credit control	Limit or require approval for outgoing ACH credits	Payroll, tax, vendor, and settlement files	Preparer creates the file; approver releases it	A compromised user sends a valid-looking file
Alert-only monitoring	Notify someone after activity meets a risk condition	Low-risk accounts or a second layer around other controls	Analyst investigates and escalates	The alert is ignored, arrives late, or lacks context

The choice should be account-specific. A tax-payment account with one known debit originator may justify a tight block-and-exception model. An operating account with dozens of utilities, benefits providers, and vendors may need a filter with approved company identifiers and amount ranges. A payroll account may need stronger credit controls than debit controls.

A block is not automatically safer if it interrupts the operating process that keeps a clinic open or employees paid. A filter is not automatically safer if nobody owns the exception queue.

What should an ACH filter actually inspect?

Start with the payment attributes your bank can receive and your team can maintain consistently. Depending on the bank and account configuration, useful rule inputs may include:

The receiving or originating company identifier.
The bank account to which the rule applies.
Debit or credit direction.
A maximum amount for one transaction and for a defined period.
Expected frequency, such as weekly, biweekly, or monthly.
The settlement window or permitted processing days.
The payment file source and submitting user.
The transaction type or Standard Entry Class code, where available.
Whether the vendor is active, suspended, or pending a second review.

Do not create a filter from a vendor name alone. Names can be abbreviated, reused, or altered. A stronger rule uses multiple attributes and has a documented owner. If the payroll-tax provider is allowed to debit up to $30,000 monthly, that limit should be visible in the rule record—not remembered by one person in treasury.

Use a narrow exception path

A practical exception path answers five questions:

Who receives the exception notification?
What evidence must they check before approving it?
Who can return the item?
What is the cutoff time?
What happens if nobody decides?

The last question is where many programs become ambiguous. Some organizations assume an undecided item will be held. Others assume it will be returned. The actual behavior depends on the bank service agreement and configuration. Document the default behavior and test it with the bank before relying on the control.

For our Modesto example, the treasury manager might establish a $25,000 per-file review threshold for outgoing ACH credits, require two approvals for files above that amount, and allow recurring debits only from approved company identifiers. Those are design decisions for that organization—not universal regulatory thresholds. The number matters because it forces the team to define who reviews what and when.

Why limits and filters must be designed together

A filter can stop an unauthorized vendor debit, but it may not stop an authorized employee from submitting a fraudulent credit file. Conversely, a transaction limit can reduce exposure while still allowing a compromised account to send many smaller payments.

For financial institutions and other organizations with substantial ACH activity, OCC guidance describes approved exposure limits for daily and multi-day settlements, separate monitoring for WEB entries, and regular review of whether limits remain appropriate.² The operating lesson applies more broadly: set limits around the way money actually moves, not around a convenient round number.

Consider three different limits:

Per-transaction limit: the largest single ACH item a user, vendor, or account may submit.
Daily limit: the total allowed during one processing day.
Rolling or multi-day exposure limit: protection against splitting a suspicious file across settlement dates.

Then define who may change those limits. If the same person can add a vendor, modify its amount ceiling, create the payment file, and approve the exception, the filter is not providing meaningful separation of duties.

OCC guidance specifically calls for dual control during initial customer setup, protection of authenticators, and segregation of ACH staff access to functions such as changing account numbers, adding users, and changing transaction limits.² For a mid-market business, that can translate into a simple operating model:

Accounts payable prepares the vendor or payment file.
Treasury reviews the vendor details and exception evidence.
A separate authorized approver releases the file or approves the exception.
IT or the security team administers access but cannot approve payments.
Every rule and approval change produces an auditable record.

How an ACH block or filter fits into the real workflow

1. Build the payment inventory

List every account that can send or receive ACH transactions. Include payroll, tax, operating, benefits, loan, merchant-settlement, and escrow accounts. Record the normal direction, frequency, vendors, dollar ranges, file source, and business owner.

This inventory frequently reveals the first design problem: one general operating account is being used for incompatible payment types. Separating payroll or tax activity may make a block or filter easier to operate and limit the blast radius of an error.

2. Establish the baseline

Review at least several normal processing cycles. Identify recurring company identifiers, ordinary amount ranges, seasonal spikes, and unusual but legitimate events such as annual insurance premiums. A rule that is too narrow creates constant exceptions; a rule that is too broad loses its value.

For banks, FFIEC examination guidance emphasizes reports that track ACH volume, dollar values, originations, returns, customer risk ratings, and exposure limits.² Even a nonbank treasury team should borrow that discipline: establish a baseline before deciding what counts as anomalous.

3. Authenticate the person and the transaction

The bank portal login is only one part of the control. Use appropriately strong authentication, restrict privileged access, and require stronger approval for high-risk actions such as adding an account, changing a company identifier, or increasing a limit.

The control should also verify the transaction context. A familiar user submitting an unfamiliar file from a new device at an unusual time deserves a different response from that same user submitting the normal payroll file from the normal workstation.

4. Route exceptions to a named owner

An exception should create a case, not merely an email. The case should contain the account, company identifier, amount, settlement date, submitting user, rule that failed, and decision deadline. The reviewer should be able to compare the item with the ERP vendor record and recent payment history.

If the item is returned, record why. If it is paid, record who approved it and what evidence supported the decision. That accountability is more valuable than a vague rule that says “monitor ACH activity.”

5. Reconcile independently

Do not treat a successful bank login or a green status in the ERP as proof that the right payment occurred. Reconcile the bank activity against an independent source, such as the approved payment register, settlement report, or general ledger.

For a Central Valley healthcare clinic, the workflow may include payroll, medical-supply vendors, insurance premiums, and patient-refund activity. A filter that works for a predictable payroll account may be unsuitable for a refund account with variable amounts. The control needs to match the workflow.

6. Review the exceptions and returns after settlement

A returned item may be an isolated typo, a stale vendor record, a compromised account, or evidence of a broader campaign. FFIEC guidance notes that ACH monitoring should identify unusual activity, and that individual ACH transactions may not be reviewed one by one in batch processing.³ That makes post-settlement trend review important.

For a bank, suspicious activity procedures may also apply. FinCEN instructs financial institutions that an account takeover involving an ACH transfer should be characterized using the account-takeover and ACH-fraud categories on the SAR⁴. Datapath does not make that filing decision for a financial institution, but we can help ensure that the technical evidence—authentication events, endpoint logs, approval records, and transaction data—is available to the people who must investigate and report.

What should you test before calling the control effective?

A configuration screenshot is not a test. A useful test follows the payment from creation through decision, settlement, reconciliation, and escalation.

Test at least these scenarios:

A debit from an approved company identifier within its expected amount range.
A debit from an unknown identifier.
An approved vendor with an amount above its limit.
A legitimate vendor whose identifier or account details changed.
A file submitted by a user who should prepare but not approve payments.
A file that exceeds the daily limit across multiple settlement dates.
An exception left undecided until the bank’s cutoff.
A bank portal or network outage during the approval window.
A suspected account takeover followed by an urgent request to disable the filter.

Measure the result. How long did the alert take to arrive? Did the right person receive it? Could the reviewer see enough context to make a decision? Did the system return, hold, or pay an undecided item? Did the event appear in the audit log? Could a backup approver complete the process?

The continuity test matters because ACH is tied to payroll, vendor obligations, and customer service. OCC guidance says ACH activities should be included in business-continuity planning, with dependencies mapped and testing aligned to the criticality and complexity of the supporting operations.

Common ACH filter mistakes we help organizations avoid

Treating the bank feature as the whole security program

A debit block cannot protect against a fraudulent outgoing credit file. A filter cannot compensate for an administrator with excessive privileges. An alert cannot help if nobody is accountable for reviewing it.

Allowing permanent exceptions

A temporary exception should have an expiration date, business justification, and second review. Otherwise, the exception list becomes an undocumented allow list.

Forgetting the vendor-change process

A vendor’s bank account or company identifier can change for legitimate reasons. Route the change through an independently verified process. Do not update the filter solely because a new banking detail appeared in an email or invoice.

Ignoring the service provider boundary

If an ERP provider, payroll processor, treasury platform, or third-party sender touches the ACH workflow, document exactly where validation occurs and who owns the logs. OCC guidance warns that third-party ACH arrangements add complexity and require effective oversight.²

Failing to plan for the cutoff

The most sophisticated rule is useless if the only reviewer is unavailable at 11:00 a.m. Build coverage, escalation, and an emergency return procedure into the operating plan.

Where Datapath fits

Datapath does not replace your bank’s ACH service or decide which transactions your organization should approve. We help make the surrounding operating system dependable: identity and access management, endpoint protection, logging, alert routing, backup communications, vendor-risk review, and incident response.

For a Modesto or Fresno-area financial organization, our managed cybersecurity team can help connect ACH-related alerts with the rest of the security picture. If your internal IT team owns the bank relationship, co-managed IT can add engineering capacity without taking control away from treasury or finance. A vCISO engagement can turn the rules into documented ownership, review evidence, and an executive-level risk decision.

Financial institutions can also use our finance IT services approach to align payment controls with the broader environment: privileged access, secure workstations, third-party oversight, and tested response procedures. When a suspicious debit appears, the question should not be “Who knows how this works?” It should be “Which named person follows the documented decision path, and can we prove what happened?”

An ACH blocks and filters readiness checklist

Before enabling or revising the control, confirm that you can answer each question:

Which accounts send ACH credits, receive ACH debits, or do both?
Which vendors or company identifiers are expected on each account?
What are the per-item, daily, and multi-day limits?
Who can create files, approve files, change rules, and administer users?
What authentication is required for each high-risk action?
Who owns the exception queue during every cutoff window?
What is the default decision for an unresolved exception?
How are vendor changes verified independently?
Which logs prove the user, device, rule, decision, and time?
How are returns, anomalies, and suspected account takeovers escalated?
When was the last end-to-end test, including an outage and an unavailable approver?

ACH blocks and filters should reduce uncertainty at the moment a payment decision matters. The right design will not make every transaction frictionless. It will make legitimate payments predictable, unusual payments visible, and high-risk decisions accountable. If your team in Modesto, or California is relying on a bank portal feature without a documented workflow around it, contact Datapath to map the control from the workstation to settlement—and identify where the decision can still fail.

Healthcare

K-12 Districts

Financial Services & PE

Government

Solutions Overview

Managed IT Services

Co-Managed IT

Local Managed IT

Cybersecurity

Managed IT in Modesto

Managed IT in Fresno

Managed Cybersecurity

Continuous Protection

Operational Stability

Strategic Accountability

ACH Blocks and Filters: Designing the Payment Decision Before Money Moves

Block, filter, or alert: which decision do you need?