An ACH fraud filter should not simply block “large” payments. For a Modesto credit union, it should compare each batch with approved originators, users, timing, destination, and exposure limits—then pause the exception for a named human decision without disrupting payroll or leaving an unreviewed trail.
At 8:04 on a Monday morning, a payroll specialist at a Modesto credit union signs in to the online banking portal and uploads a batch for 184 employees. The file looks familiar: the same payroll processor, the same settlement account, and nearly the same total as the previous pay period.
The ACH fraud filter still pauses it.
The batch is $428,600—about $76,000 higher than the recent baseline. The upload is coming from a newly enrolled workstation. One employee’s direct-deposit account was changed late Friday afternoon, outside the credit union’s normal approval window. None of those signals proves fraud. Together, they make automatic release irresponsible.
That is the operating moment a good filter is designed for. It should not merely return a red warning. It should route the payment to a documented decision: hold, verify, release, or escalate. The objective is to protect member funds while keeping legitimate payroll moving.
What should an ACH fraud filter actually evaluate?
A weak filter asks one question: “Is this transaction over the threshold?” A useful filter evaluates whether the transaction fits the organization’s established behavior and approval process.
For a finance organization in Modesto, that means comparing several layers of context:
- Who initiated the payment: user identity, role, authentication method, and whether the user normally creates or approves ACH files.
- Where the request came from: managed workstation, browser session, device posture, network location, and unusual sign-in activity.
- What is being sent: total value, individual entries, routing information, SEC code, destination-account changes, and new recipients.
- When it is being sent: normal processing window, day of week, holiday or weekend timing, and proximity to the settlement cutoff.
- How it compares with history: ordinary payroll range, vendor-payment cadence, return patterns, and approved exposure limits.
- What happens next: whether a second person verifies the exception and whether the decision is recorded for later review.
This is why an ACH fraud filter is not a standalone appliance. It is a control layer connecting the banking portal, identity provider, endpoint monitoring, email security, ticketing system, and human approval workflow.
The filter does not need to prove that a transaction is malicious before it acts. It needs a defensible way to identify activity that requires additional verification.
NIST CSF 2.0 describes the Detect function as finding and analyzing anomalies, indicators of compromise, and other potentially adverse events so that the organization can respond and recover effectively.1 That maps well to ACH operations: detection should create a useful decision, not simply generate another alert.
Why a dollar-only rule fails
A dollar threshold is easy to explain and easy to configure. It is also easy for an attacker to work around.
If the rule blocks every batch over $250,000, a fraudster may submit several smaller batches. If the rule only looks for new recipients, an attacker who changes an existing payee may pass through. If the rule only watches the finance application, a compromised employee account can appear legitimate inside that application.
Dollar limits still matter. They provide a clear control boundary and a useful escalation trigger. But they should be one signal in a risk decision, not the entire decision.
For example, Datapath might help a Central Valley finance client define an illustrative policy like this:
| Signal | Illustrative decision | Required human action | Evidence to retain |
|---|---|---|---|
| Batch exceeds $250,000 | Hold for review | Treasury manager confirms purpose and settlement account | Batch ID, amount, reviewer, timestamp |
| New destination account added within 24 hours | Hold and verify out of band | Confirm through a known phone number or previously approved channel | Verification method and result |
| Upload from an unmanaged or newly enrolled device | Deny or quarantine session | Security team validates device and account activity | Identity, device, sign-in, and ticket records |
| Payment submitted outside the normal processing window | Step-up approval | Second authorized employee reviews the exception | Approval chain and reason code |
| Several signals occur together | Escalate to incident workflow | Preserve evidence and investigate before release | Alert history, endpoint data, email context, and disposition |
The figures in this matrix are examples for designing a policy, not universal limits. A credit union’s thresholds should reflect its transaction volume, member risk, staffing, bank configuration, and tolerance for false positives.
The important design choice is the distinction between alerting and release authority. An alert can be automated. Release should remain tied to an authorized person and a documented business reason.
Which ACH controls belong in the filter, and which belong around it?
The filter should be part of a control system with four connected layers.
1. Identity and session controls
Start before the ACH file is created. Require phishing-resistant or strong multi-factor authentication where supported, restrict privileged roles, and separate users who prepare files from users who approve them.
For covered financial institutions, the FTC Safeguards Rule requires an information security program with administrative, technical, and physical safeguards. Its guidance also addresses periodic access-control review, multi-factor authentication, authorized-user activity logs, service-provider oversight, and written incident response planning.2
That does not mean MFA alone makes an ACH workflow safe. A valid employee account can still be abused, and an approved user can still be socially engineered. The filter should therefore consume identity and session signals rather than treating successful login as proof of legitimacy.
2. Batch and transaction controls
At the file level, inspect the originator, total value, entry count, settlement date, SEC codes, and changes from the prior approved pattern. At the entry level, look for new account numbers, unusual destinations, duplicate payments, unexpected geographic patterns, or changes to recurring payment instructions.
Do not make “unusual” synonymous with “fraud.” A school district’s payroll may spike before the academic year. A healthcare clinic may make an unusual insurance payment. A mid-market manufacturer may issue a legitimate bonus run. The filter should pause those exceptions and ask the right person to validate them.
For financial institutions, FFIEC guidance says ACH programs should use policies and processes to monitor and identify unusual activity, supported by customer due diligence and risk-based suspicious-activity monitoring.3 That supports a broader view of the batch, the originator, the relationship, and the surrounding activity—not just a single transaction value.
3. Dual approval and separation of duties
An ACH filter cannot compensate for a workflow in which one compromised account can create a recipient, upload a file, approve an exception, and change the transaction limit.
The person who prepares the batch should not be the only person who releases it. Changes to users, account numbers, limits, and approval rules deserve stronger protection than routine data entry. Administrative access should be limited, reviewed, and logged.
OCC ACH risk-management guidance specifically discusses dual control, minimizing and monitoring employee access, segregating ACH staff, limiting maintenance functions, and monitoring entries against exposure limits.4 Those are practical design requirements even when the technology stack differs from one financial institution to another.
4. Response and recovery
When the filter identifies a high-risk batch, the next step should already be defined. The employee should know whom to call, what not to do, what evidence to preserve, and who can authorize release or cancellation.
A useful response workflow might be:
- Place the batch in a hold state without deleting the original record.
- Open a ticket with the batch ID, user, device, amount, settlement date, and triggered signals.
- Contact the preparer through a known channel—not by replying to the email that requested the payment.
- Confirm whether any recipient, account, user, or approval rule changed recently.
- Review identity, endpoint, email, and banking-portal activity for related events.
- Escalate to the institution’s incident-response contact when compromise is plausible.
- Release only after a named approver records the reason and supporting verification.
- If fraud is suspected, follow the institution’s bank, legal, regulatory, and law-enforcement notification procedures.
The objective is not just to stop one bad batch. It is to determine whether the same compromised account, mailbox, device, or vendor relationship could affect the next batch.
How do you reduce false positives without weakening the control?
A filter that stops every unusual payment will eventually be bypassed, disabled, or ignored. The answer is not to remove the filter. It is to improve the quality of the decision it creates.
Start with a baseline for each payment type. Payroll, vendor payments, member refunds, loan disbursements, and internal transfers should not all share the same thresholds or approval paths. Then define an exception reason for legitimate deviations.
Measure the workflow every month:
- Number of ACH alerts by rule and payment type
- Percentage released after verification
- Percentage rejected or escalated
- Average time from alert to decision
- Repeated alerts involving the same user, device, recipient, or vendor
- Changes made to thresholds, roles, and approval policies
- Whether reviewers had enough context to make a decision
A high false-positive rate may indicate that the baseline is too narrow, the rule is duplicative, or the organization lacks useful context. A low alert count is not automatically good news. It may mean the filter is too permissive, the telemetry is incomplete, or the rules are not being evaluated against the right fields.
Datapath can help connect these signals through managed cybersecurity, endpoint monitoring, identity controls, security information and event management, and a documented escalation path. For a finance team with internal IT staff, co-managed IT can add monitoring and engineering capacity without taking ownership away from the people who know the payment operation.
What should a buyer ask before purchasing an ACH fraud filter?
The product demo should be the last step, not the first. Begin with the workflow and ask:
Can it explain why a transaction was flagged?
A score without contributing signals is difficult for a reviewer to trust. The system should show which conditions changed: amount, timing, user, device, recipient, account, or prior behavior.
Can it enforce a hold, or only send an email?
An email alert is useful, but it is not the same as preventing release. Confirm whether the platform can integrate with the bank or payment workflow to pause, reject, or require a second approval.
Can it distinguish preparation from approval?
Ask how roles are mapped, how emergency access works, and whether changes to user permissions and transaction limits require independent approval.
Can it preserve an audit-ready record?
The record should include the original alert, triggered rules, reviewer, decision, timestamp, verification method, and any changes made afterward. Avoid a system where staff must reconstruct the decision from scattered email threads.
Can it support an incident investigation?
If an account is compromised, the team needs more than the transaction itself. The investigation may require sign-in records, endpoint telemetry, mailbox activity, administrative changes, and related alerts.
Who owns the response at 2 p.m. and 2 a.m.?
Technology does not define accountability. Name the operations owner, security owner, backup approver, bank contact, and incident-response contact before the first alert occurs.
A practical Datapath starting point for Modesto finance teams
We would begin with a payment-flow review rather than a product recommendation. Map who creates ACH files, who approves them, which systems are involved, how recipient changes are requested, and what happens when a batch is held near cutoff.
Then establish a small set of high-confidence controls:
- Separate preparation and approval roles.
- Require MFA and review privileged access.
- Define normal ranges by payment type instead of using one universal threshold.
- Protect recipient and settlement-account changes with out-of-band verification.
- Send high-risk alerts to a named queue with a response target.
- Record every release, rejection, override, and policy change.
- Test the hold-and-escalate workflow with a harmless sample batch.
From there, we can tune rules against real operating data. Datapath’s finance and credit-union technology team can coordinate with internal operations, the banking relationship, and existing security providers. If the organization needs executive-level security ownership, vCISO services can help turn the filter into a governed program rather than another console that nobody owns.
An ACH fraud filter earns its place when it makes the right payment easier to approve and the wrong payment harder to release. For a Modesto finance organization, that means protecting payroll and member funds while giving reviewers clear evidence, clear authority, and a clear next action.
If your current process is “watch the amount and call someone when it looks strange,” talk with Datapath about mapping the workflow, strengthening the approval boundary, and building an ACH response process your team can operate under pressure.
