An ACH filter for business is valuable, but it is not a complete fraud strategy. The strongest design combines bank-side allowlists and limits with phishing-resistant identity controls, independent verification, dual approval, and a response plan. That turns an ACH filter from a checkbox into a controlled payment workflow.
At 4:47 p.m. on a Thursday in Modesto, a controller at a 120-employee distribution company is uploading the next morning’s payroll and supplier ACH file to the bank portal. One vendor’s bank account changed that afternoon. The email looks familiar, the invoice matches an open purchase order, and the payment batch contains 42 entries.
The bank’s ACH filter pauses the transaction because the originator details do not match the company’s approved rule. The controller now has a decision: approve the exception, reject it, or verify the change through a separate channel. If the team treats the alert as an inconvenience, the filter becomes a rubber stamp. If it treats the alert as a payment-control event, it may stop a costly mistake before funds leave the account.
That is the sharper business question: not whether your bank offers an ACH filter, but whether your people, systems, and bank rules agree on what a legitimate payment looks like.
What is an ACH filter for a business?
An ACH filter, sometimes called ACH positive pay, is a bank-side control that compares incoming ACH activity against rules established for a business account. Depending on the bank, those rules may include approved originators, company IDs, transaction types, dollar limits, frequency, or account-specific exceptions.
The filter is designed to answer a narrow question: does this ACH entry fit the profile we authorized?
It is not designed to determine whether:
- A real vendor was socially engineered.
- A legitimate employee’s mailbox was compromised.
- A familiar supplier intentionally sent a fraudulent request.
- A payment was approved by the wrong person.
- A workstation used to prepare the ACH file is infected.
That distinction matters. A fraudulent payment can still look technically valid. It may use the correct business account, a legitimate vendor name, and an amount that falls below a limit. The filter can identify an unexpected originator or unusual pattern, but it cannot replace approval discipline.
The FBI describes business email compromise as a scam in which criminals send messages that appear to come from known sources, including vendors changing payment details or executives requesting transactions.1 In other words, the payment can be unauthorized even when the email thread, invoice, and vendor relationship look genuine.
Why do ACH filters miss otherwise convincing fraud?
Most businesses think about ACH risk as a bad account number. Attackers often target the decision process around the account number instead.
A compromised mailbox may contain vendor invoices, payroll calendars, approval chains, bank contacts, and previous payment amounts. An attacker can wait for the right moment, send a realistic account-change request, and pressure an employee to approve the exception before anyone calls the vendor.
CISA has described business email compromise as payment fraud involving compromised or spoofed business accounts and unauthorized transfers. Its recommendations include limiting the number of employees who can approve or conduct transfers, using out-of-band verification, and requiring dual approval for new partners, new account numbers, or transactions above a defined threshold.2
An ACH filter therefore works best as the final checkpoint in a larger chain:
- The identity layer establishes whether the person signing in is really the controller, payroll manager, or treasury employee.
- The endpoint layer helps determine whether the computer and email account used in the process are trustworthy.
- The workflow layer defines who may create, review, release, and change payment instructions.
- The bank layer compares the transaction with approved ACH rules and presents exceptions for action.
- The response layer determines what happens when a suspicious payment is detected or released.
Remove any one of those layers and the remaining controls carry more risk than they were designed to handle.
How should a business design its ACH filter rules?
Start with the company’s real payment behavior rather than choosing the broadest possible allowlist. A rule that permits every originator and every amount may reduce alerts, but it also reduces the value of the filter.
Build the baseline before setting limits
Review at least several weeks of ACH activity and classify it by:
- Vendor or originator.
- Account receiving or sending the payment.
- Typical dollar range.
- Payment frequency.
- Payroll versus supplier versus tax or benefit activity.
- One-time and seasonal exceptions.
- Employees or service providers involved in preparation and release.
The purpose is not to freeze normal operations. It is to make unusual activity visible.
For example, a Central Valley manufacturer might permit payroll originators on a dedicated schedule, approve recurring suppliers within established ranges, and send all new originators to an exception queue. A $25,000 ceiling could be an internal approval threshold for that company, not a universal rule. The important point is that the amount is tied to a documented business decision, reviewed by leadership, and enforced consistently.
Use different rules for different payment types
Payroll should not necessarily have the same rule as supplier payments. A tax payment, benefits file, contractor batch, and recurring utility debit may each have different expected timing and originator patterns.
Separate rules make an alert meaningful. If every payment shares one permissive rule, the team cannot quickly tell whether an exception is routine or dangerous.
Treat account changes as high-risk events
A change to a vendor’s bank account should trigger more than an email reply. Require a callback using a known number from the vendor master record or contract, not a number supplied in the change request. Confirm the old and new details, record who verified them, and require a second employee to approve the update.
The FBI specifically recommends verifying changes in account numbers or payment procedures and contacting the party through a trusted number rather than relying on the communication that delivered the request.2
What should happen when an ACH filter creates an alert?
An alert is not a security outcome. It is an unfinished decision. Before enabling the filter, define the exception process in writing.
| ACH filter event | First action | Required verification | Release decision |
|---|---|---|---|
| New originator | Place the entry on hold | Confirm the vendor through a known contact and review the purchase record | Treasury manager approves or rejects |
| Existing vendor with a new account number | Do not approve from the email thread | Independent callback and second-person review | Release only after the vendor master is updated through the controlled process |
| Amount above the internal threshold, such as $25,000 | Hold the batch or entry | Confirm business purpose, invoice, and approver identity | Two authorized approvers release |
| Unexpected timing or frequency | Compare with the payment calendar | Review recent mailbox, endpoint, and bank activity | Escalate if the pattern cannot be explained |
| Unknown originator or unfamiliar company ID | Reject or hold | Identify the source and confirm the contract | Add to the allowlist only after documented approval |
The bank portal should not be the only place where the decision is recorded. Keep an audit trail showing the alert, evidence reviewed, people involved, final action, and time of release. That record helps management understand whether the control is working and helps responders reconstruct what happened if a payment later proves fraudulent.
The FDIC’s ACH examination guidance highlights the same operational themes: segregation of duties, exposure limits, identity and access management, anomaly monitoring, independent reconciliation, and customer transaction monitoring.3 Those are practical design requirements for a business payment process, even when the business is not itself a financial institution.
Which controls should sit around the ACH filter?
Protect the people who can release payments
Use separate accounts for payment preparation and approval. Do not let one employee create a vendor, change its bank details, upload the ACH file, and release the payment without an independent review.
Require multifactor authentication for the bank portal, Microsoft 365, email, password management, and remote access. Use conditional access or equivalent controls where available, and alert on unusual sign-ins. A filter cannot help if an attacker is operating inside a valid user session.
The FBI recommends multifactor authentication and independent verification of payment and purchase requests, especially when the requester is creating urgency.1
Protect the workstation and mailbox
The computer used for treasury activity should have endpoint detection and response, current patches, disk encryption, and restricted local administrator privileges. Email security should flag lookalike domains, suspicious forwarding rules, and unusual login activity.
Keep payment workstations and bank credentials out of ordinary browsing workflows where practical. A finance employee who uses the same session for vendor payments, personal webmail, and untrusted downloads has a larger exposure than the ACH filter can address.
Make approval authority explicit
Document who may:
- Add or modify a vendor’s payment instructions.
- Create an ACH batch.
- Approve an exception.
- Release a payment.
- Contact the bank to place a hold or request a recall.
CISA also recommends limiting the number of employees with authority over transfers and using out-of-band authentication for requests that appear to come from executives. For a mid-market company, that might mean a controller and CFO approve high-value exceptions, while routine payroll follows a separate, documented path.
Reconcile independently
Do not rely only on the same system that initiated the payment. Reconcile the bank activity against the enterprise resource planning system, payroll platform, accounts payable ledger, and approved payment register. An independent review can reveal a payment that passed a narrow filter but does not belong in the company’s books.
How does an ACH filter fit into a cybersecurity program?
ACH payment controls should be included in the company’s broader risk register, not left exclusively to the bank relationship manager. NIST CSF 24.0 organizes cybersecurity outcomes across Govern, Identify, Protect, Detect, Respond, and Recover; that structure maps naturally to payment operations.
- Govern: Assign an owner for ACH risk, define approval thresholds, and review the bank’s available controls.
- Identify: Map bank accounts, payment systems, vendor data, users, administrators, and third parties.
- Protect: Enforce multifactor authentication, least privilege, secure endpoints, and dual approval.
- Detect: Monitor filter exceptions, unusual sign-ins, mailbox rules, endpoint alerts, and payment patterns.
- Respond: Maintain a bank escalation process, preserve evidence, disable compromised accounts, and investigate the affected mailbox or workstation.
- Recover: Reconcile accounts, restore trusted access, review vendor records, and update the payment workflow.
NIST’s incident-response guidance emphasizes incorporating response practices throughout cybersecurity risk management so organizations can improve detection, response, and recovery activities5. For ACH fraud, that means knowing in advance who calls the bank, who preserves logs, who communicates with leadership, and who determines whether other accounts or vendors are affected.
The FDIC guidance also asks whether business continuity, disaster recovery, and incident response programs appropriately address ACH-related activity. A payment incident can happen while the finance director is traveling, the normal bank contact is unavailable, or the company is already dealing with a broader technology outage. The process needs backup personnel and alternate communication methods.
What should a business ask its bank and IT provider?
Before purchasing or enabling an ACH filter, ask the bank:
- Can rules be set by originator, company ID, account, transaction type, amount, or schedule?
- What happens when an alert is ignored or not reviewed before the cutoff?
- Can the bank require dual approval?
- Are exception decisions logged and exportable?
- How quickly can the bank place a hold, suspend ACH origination, or begin a recovery request?
- Can different accounts use different approval policies?
Ask the IT or cybersecurity team:
- Who has access to the bank portal and why?
- Is MFA enforced rather than merely available?
- Are bank users, vendor-master editors, and ACH approvers reviewed regularly?
- Are mailbox forwarding rules, risky sign-ins, and endpoint threats monitored?
- Can the team produce an incident timeline showing the email, vendor change, login, file creation, approval, and bank alert?
- Has the process been rehearsed with finance staff and the bank contact?
If the answers are unclear, buying a more sophisticated filter will not solve the underlying problem. The business needs a designed operating process first.
Where Datapath fits
Datapath helps organizations connect payment risk to the systems and people that actually operate the business. For a Modesto, Merced, Fresno-area, Modesto, or California company, that can include managed cybersecurity, Microsoft 365 protection, endpoint monitoring, identity controls, vendor-risk review, and a documented incident-response path.
Our managed cybersecurity services can support the technical controls around the bank portal, email, endpoints, and identities. If your internal team owns treasury and finance systems, co-managed IT can add the monitoring and operational coverage you do not have to build alone. A vCISO engagement can turn an informal approval habit into a clear payment-risk policy with assigned owners and measurable review points.
For finance organizations, our finance IT services approach is built around accountability and continuity rather than generic help-desk response. We can also help document the escalation path through an incident response retainer so the first call after a suspicious ACH alert is not a search through old email threads.
An ACH filter is worth having. But the business value appears when an alert produces the right pause, the right verification, and the right accountable decision. If your current process depends on one employee recognizing a suspicious email at 4:47 p.m., it is time to design the control around the workflow—not just turn on the bank feature. Start a conversation with Datapath about building that payment-control process around your actual team and systems.
