ACH Filter vs ACH Block Explained: Choose the Control That Matches Your Payment Workflow

An ACH block stops incoming debits by default, while an ACH filter allows trusted transactions that match defined rules and sends exceptions for review. Choose a block when exceptions are rare; choose a filter when recurring vendors need predictable, controlled access. Many organizations use both.

At 4:40 p.m. in a 130-person distributor in Manteca, the controller and accounts-payable lead are in the bank’s treasury portal before tomorrow’s first payroll. The new payroll processor will pull $42,600 by ACH. The account currently has a blanket ACH block. The team must decide: add the processor to an approved list with a $45,000 ceiling, or leave the block in place and manually approve the exception?

Approve the wrong debit and a fraudulent withdrawal can settle. Return the legitimate one and payroll or a tax payment may fail. That is the practical decision behind ACH filter vs. ACH block—not which feature sounds more secure, but which control fits the organization’s actual payment workflow.

What is the difference between an ACH filter and an ACH block?

An ACH block is the more restrictive default. It prevents ACH debits from posting unless the organization explicitly permits them through the bank’s process. Depending on the bank, that may mean approving individual exception items, maintaining an approved-payee list, or configuring an account-level rule. J.P. Morgan, for example, describes its ACH Debit Block as protecting selected accounts by allowing customers to manage approved payees for authorized ACH debits.¹

An ACH filter—often marketed as ACH Positive Pay or ACH Debit Filter—compares incoming debits against rules such as:

• Company ID or originator name
• Approved vendor or payee
• Maximum amount
• Frequency
• Effective date range
• Account or transaction type

A matching transaction may be paid automatically. A transaction that does not match may appear as an exception for a user to pay or return. Some bank platforms also support blocked lists, alerts, dual approval, and a default action when no one makes a decision before the bank’s cutoff.²

The crucial distinction is this:

• Block: “Do not let ACH debits through unless we say yes.”
• Filter: “Let known, correctly patterned debits through; stop or flag the rest.”

Neither feature replaces account review, identity protection, or a clear approval process. An attacker who compromises an authorized user’s bank credentials may still be able to alter an approved list or approve an exception. The payment control must therefore be designed alongside access controls and monitoring.

ACH filter vs. ACH block: side-by-side comparison

Option	How it handles incoming ACH debits	Best fit	Operational strength	Buyer-relevant tradeoff
ACH Block	Rejects or holds debits unless they are explicitly permitted or approved	Dormant, reserve, tax, escrow, or low-activity accounts; organizations with very few ACH debits	Strong default-deny posture and a small approval surface	More manual work; a missed decision can return a legitimate payment
ACH Filter	Automatically pays transactions matching approved rules and routes exceptions for review	Businesses with recurring payroll, benefits, utilities, lenders, and vendor withdrawals	Reduces repetitive approvals while enforcing payee, amount, date, and frequency rules	Badly maintained rules can approve an unexpected transaction or create false exceptions
Block plus filter	Uses a restrictive account posture with approved recurring rules and exception review	Finance teams that need both automation and tight control over high-value accounts	Separates routine payments from unusual activity and supports escalation	Requires ownership, documented changes, alerts, and a tested cutoff procedure

The third row is often the most practical design for a mid-market organization. A company may use a filtered operating account for ordinary recurring debits while keeping a full block on a reserve or settlement account. The right arrangement depends on how many legitimate debits occur, how quickly exceptions must be handled, and whether the finance team can review them every business day.

When should a business choose an ACH block?

Choose a block when the account should not normally receive ACH debits. Examples include:

• A reserve account used only for transfers initiated by your own treasury team
• A tax account with scheduled activity on only a few known dates
• An account holding funds for a specific project or acquisition
• A newly opened account whose legitimate debits have not yet been documented
• An account where the cost of a false positive is lower than the cost of any unauthorized debit

A block is especially useful when the organization can name the few legitimate debits in advance. The smaller the expected transaction population, the easier it is to investigate every exception.

The tradeoff is operational discipline. Someone must know which person receives the alert, which bank cutoff applies, how a legitimate exception is verified, and who can authorize a change. Do not assume that “blocked” means “nothing can ever happen.” Bank products differ: some return items automatically, some hold them for decisioning, and some allow an approved-payee list under the block service.

Ask the bank these questions before enabling the control:

1. Are unmatched debits returned automatically, held, or paid by default?
2. What happens if no one makes a decision before the cutoff?
3. Can the organization approve an individual item without changing the standing account rule?
4. Can one employee add a payee and approve the first debit?
5. Are alerts sent by email, text, treasury portal, or a monitoring system?

The last two questions matter because a strong default can be weakened by a weak administration process.

When is an ACH filter the better choice?

A filter makes more sense when the business has a predictable set of recurring debits and the finance team wants automation without opening the account broadly. A payroll processor might be approved for a maximum of $45,000, once per pay cycle, during the active date range. A benefits administrator might have a different amount and frequency. A utility provider might have a wider amount tolerance but still be limited to a known company ID.

The point is not to create one long list of vendors. It is to describe the expected payment pattern precisely enough that an unusual debit becomes visible.

For each approved originator, document:

• The exact company ID the bank will match
• The account that may be debited
• The normal amount or maximum amount
• Expected frequency and settlement timing
• Start and end dates, if the authorization is temporary
• The business owner responsible for reviewing changes
• The verification method for any requested update

Some platforms match an approved company using the ACH company ID in the incoming batch. A transaction may still become an exception when the amount, frequency, or date falls outside the approved parameters.² That is why a filter should not be treated as a vendor-name list alone.

The filter also creates a maintenance obligation. When payroll changes processors, when a lender refinances a loan, or when a vendor changes its ACH company ID, the finance team must update the rule through a controlled process. An old approved entry can become a blind spot if no one reviews it.

What should the approval workflow look like?

Start with the payment, not the product. Map how a legitimate debit moves from a business need to settlement:

1. The business owner requests the debit

The payroll, benefits, treasury, or procurement owner documents the vendor, expected amount, frequency, and reason for the debit. A bank-change email alone should not be enough to create or modify an ACH rule.

2. A second person verifies the request

Use an independently obtained phone number or an established vendor contact—not the contact information in a suspicious message. The second person confirms the company ID, account, amount range, and effective date.

3. A designated treasury user updates the bank rule

The user should have permission to manage only the necessary account and rule. The bank portal should require strong authentication, and the organization should record who made the change, when, and why.

4. The team tests the exception path

Create a tabletop scenario: an unfamiliar debit appears at 8:30 a.m.; the controller is unavailable; the bank cutoff is approaching; the vendor says the debit is legitimate. The team should know who can hold, return, or approve the item and who contacts the bank.

5. The rule is reviewed after settlement

Confirm that the debit matched the intended company ID, amount, and frequency. Review exceptions and rule changes, not just successful transactions.

This is where ACH protection becomes an operating control rather than a setting. OCC guidance for ACH risk management emphasizes written procedures, strong internal controls, and risk-based auditing.³ It also recommends setting ACH exposure thresholds and monitoring whether transactions remain within those limits.³

How do dual approval and least privilege fit in?

ACH filtering can reduce fraud exposure, but it does not answer the question of who may change the filter. Separate these permissions where the banking platform allows it:

• One user prepares a new approved-payee entry.
• A second user approves the entry.
• A different role reviews exceptions and returns.
• Treasury leadership receives a report of changes and overrides.

NIST’s access-control guidance describes least privilege, separation of duties, dual authorization, and logging privileged functions as ways to limit misuse and improve accountability.⁴ You do not need to copy a federal control catalog line for line to apply the idea: the person who adds a new ACH originator should not be able to approve the first high-value debit without independent review.

Set a threshold that reflects the payment, not an arbitrary round number. In the Manteca example, a $45,000 ceiling for a normal $42,600 payroll debit leaves only a modest tolerance. A $250,000 ceiling would make the rule convenient but would weaken its value. For a vendor with variable invoices, use a documented maximum and require human review above it rather than quietly increasing the limit after every exception.

Is an ACH filter a compliance control?

An ACH filter is a payment control, not proof of compliance by itself. For banks, credit unions, and other covered financial institutions, the FTC’s GLBA Safeguards Rule requires a written information security program with administrative, technical, and physical safeguards.⁴ An ACH rule can support that program, but the organization also needs documented ownership, access controls, monitoring, testing, and incident response.

The FTC specifically points to logging authorized-user activity, watching for unauthorized access, and regularly testing safeguards. That maps directly to ACH administration: retain filter-change records, review unusual access to the treasury portal, and periodically test whether an unauthorized payee would be blocked or escalated.

Do not claim that an ACH block alone satisfies GLBA, FFIEC, audit, or bank examination expectations. Instead, connect the control to the broader risk process. OCC guidance also calls for minimizing and monitoring personnel access to ACH systems and segregating sensitive functions such as changing account numbers, adding users, and changing transaction limits.

What other controls should sit beside ACH filtering?

Treat the filter or block as one layer in a payment-protection stack. At minimum, review:

• MFA for treasury, email, payroll, and administrator accounts
• Phishing-resistant authentication where practical
• Dual approval for payee, limit, and account-rule changes
• Out-of-band verification for bank-detail changes
• Alerts for new payees, unusual amounts, and portal logins
• Daily reconciliation of ACH activity
• A documented return and bank-notification procedure
• Tested backups for accounting and payment records
• An incident-response playbook for suspected account takeover

CISA recommends enforcing MFA with technical controls, maintaining an incident response plan, conducting tabletop exercises, and performing and testing backups⁵. Those practices matter because a fraudulent ACH debit may begin with a compromised mailbox or stolen treasury credentials rather than with a weakness in the bank’s filtering engine.

How Datapath helps make the control usable

A bank can enable the feature, but your organization still has to make it work on a Tuesday morning when the controller is out, a payroll file is late, or a vendor calls about a changed account.

Datapath works with finance teams in the Central Valley—including Manteca—to connect payment controls to identity, endpoint, email, monitoring, and response processes. For a bank or credit union, our finance IT team can help document who owns treasury access, how exceptions are verified, and which events should reach a named escalation team.

Depending on the environment, that may include managed cybersecurity, vCISO guidance, or an incident response retainer. The objective is not to sell a generic “ACH security package.” It is to make the decision path accountable: who can create the rule, who can approve it, who monitors the exception, and who responds if the account is compromised.

The practical decision

Use an ACH block when legitimate debits are rare and a manual approval is acceptable. Use an ACH filter when recurring debits need to flow automatically but must remain constrained by originator, amount, frequency, and date. Use both when different accounts have different risk profiles.

Before choosing, write down three numbers: the normal transaction amount, the maximum acceptable amount, and the bank’s decision cutoff. Then name the primary reviewer and backup reviewer. If the organization cannot answer those questions, the problem is not yet filter versus block—it is ownership.

For a payment workflow that affects payroll, vendor continuity, or customer funds, that ownership should be documented, tested, and supported by a team that can see the identity and security context around the transaction. That is the difference between turning on a treasury feature and building a payment-control process that protects uptime and accountability.

---

Footnotes

1. How to use ACH debit block | J.P. Morgan Private Bank U.S. ↩

2. Heartland ACH Debit Filter User Guide ↩ ↩²

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

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

5. Cyber Guidance for Small Businesses | CISA ↩