ACH Fraud Filters Rule Library: How a Modesto Credit Union Turns Alerts Into Decisions

When a Modesto credit union’s AP lead releases a $25,000 ACH vendor batch, the right fraud filter does more than say “high risk.” It identifies the rule, pauses the batch, routes it to a named approver, and leaves evidence someone can defend at the next review.

The decision at 8:57 a.m.

The batch is already assembled in the online banking portal. It contains 42 payments to familiar vendors, but one account number changed yesterday. The batch is also 2.8 times larger than the vendor’s recent average, and the Standard Entry Class code does not match the payment pattern the credit union normally sees.

The AP lead should not have to remember which dashboard to open, which analyst is on call, or whether “high risk” means pause, reject, or simply document. The filter should answer those questions immediately.

That is the purpose of an ACH fraud filters rule library: a governed catalog of rules that connects a signal to an action, an owner, an exception path, and evidence. It is not just a list of thresholds inside an ACH platform. It is the operating model around those thresholds.

For financial institutions, the timing matters. Federal Reserve Financial Services describes 2026 ACH risk-management changes that require risk-based processes intended to identify ACH entries initiated due to fraud. The Phase 2 schedule applies to other non-consumer originators, third-party service providers, third-party senders, and RDFIs beginning June 19, 2026. ¹ As of August 2026, a filter library should be an active operating control—not a future project.

What should an ACH fraud filter rule contain?

A useful rule has enough structure that an analyst can understand and defend it without asking the person who built it. At minimum, each rule should record:

• Rule ID and purpose: for example, ACH-014 Vendor Banking Change plus First Payment.
• Data fields used: amount, velocity, account age, SEC code, originator, receiver, operator, IP address, device, return reason, or settlement date.
• Trigger logic: the precise condition that creates an alert or hold.
• Action: allow, alert, step-up verification, queue for review, hold, return, or escalate.
• Owner: the AP manager, ACH operations, fraud analyst, information security team, or executive approver.
• Exception path: what legitimate business reason can override the rule and who may authorize it.
• Evidence: approval record, callback notes, ticket number, batch ID, and final disposition.
• Review date: when the rule, threshold, and false-positive rate must be reassessed.

This metadata is what turns a technical control into accountability. If the credit union cannot explain why a $25,000 batch was stopped—or why it was released—it does not have a mature filter library. It has an alert generator.

A practical ACH fraud filters rule library

The following is a starting design for a mid-market financial institution. The numeric values are illustrative operating thresholds, not universal fraud standards. They should be calibrated against the institution’s customers, transaction volumes, risk appetite, and historical activity.

Rule ID	Signal or trigger	Recommended action	Primary owner	Evidence to retain
ACH-001	Vendor or payroll account instructions changed within 24 hours of a payment batch	Hold the affected entry; require independent callback verification	ACH operations	Change ticket, callback record, approver identity
ACH-002	Batch velocity exceeds 3 times the originator’s 30-day median or includes more than 20 entries in 15 minutes	Route to analyst review; compare with scheduled business activity	Fraud operations	Baseline calculation, analyst decision, batch ID
ACH-003	Single entry or rolling two-settlement-day exposure exceeds the approved originator limit	Hold and escalate for limit approval or pre-funding decision	Credit risk and ACH operations	Limit record, approval, funding confirmation
ACH-004	SEC code does not match the expected transaction type, account profile, or authorization record	Alert; require transaction-purpose validation	Compliance and ACH operations	SEC code, authorization evidence, disposition
ACH-005	Unauthorized, invalid-account, or account-not-found returns exceed the originator’s normal baseline	Increase review intensity; investigate originator and related batches	Fraud and compliance	Return-rate trend, investigation notes, corrective action
ACH-006	Privileged user changes account numbers, users, limits, or filter logic without dual control	Block the change and alert security	Information security	Admin log, ticket, second approver, rollback record
ACH-007	Third-party sender batch cannot be reconciled to the named underlying originator	Quarantine the file; require originator-level detail	Vendor risk and ACH operations	File manifest, originator list, reconciliation result

The strongest libraries combine hard controls and investigative signals. A newly changed vendor account may justify an immediate hold. A modest increase in velocity may only create an alert. Treating every signal as a block will push staff toward workarounds; treating every signal as informational will leave the institution with a very expensive notification system.

Which signals deserve priority?

1. Payment-instruction changes

Account-number changes are powerful because they connect a cyber event to a payment event. The rule should not only inspect the final ACH file. It should correlate the payment with the identity and timing of the change: who changed the instructions, from which device, under which account, and whether a second employee approved the change.

For a vendor payment, the control should require an independent verification channel. A phone number copied from the change request is not independent. The callback should use a known contact record, and the evidence should capture who verified the account, when the verification occurred, and what was confirmed.

2. Amount, velocity, and exposure

A single large payment is not always suspicious. A series of individually ordinary payments can be more revealing when the total exceeds an approved exposure limit or crosses multiple settlement dates. OCC guidance recommends credit and debit exposure thresholds for ACH originators, regular monitoring of compliance with those limits, and separate monitoring practices for WEB entries. ²

That is why ACH-003 should not be a simple “amount greater than $X” rule. It should evaluate:

• The originator’s approved daily and rolling exposure.
• The amount already submitted but not yet settled.
• The number of settlement dates represented by open batches.
• Whether the payment is credit or debit.
• Whether the transaction is a WEB, TEL, or other higher-risk entry type.
• Whether a limit exception was approved before the file was released.

This is also where a rule library can prevent a common failure: an analyst sees that every individual batch is below the limit while the combined exposure is already above it.

3. Return behavior and SEC-code mismatches

Returns are not just a post-processing report. They are feedback about the quality of the originator, authorization process, and account data. OCC guidance specifically calls for monitoring unauthorized returns, identifying variances from established parameters such as origination volume, and periodically verifying appropriate SEC-code use. ²

Build return rules at the originator level, not only at the institution level. A large, stable originator can hide a smaller high-risk program inside an aggregate return-rate report. Track return reason, originator, receiver, SEC code, batch, and related complaints together.

A rising invalid-account rate may indicate stale files. A sudden increase in unauthorized returns may indicate a compromised process, a deceptive originator, or a change in customer behavior. The action does not always need to be immediate termination. It may be enhanced review, temporary exposure reduction, pre-funding, or a targeted audit.

4. Third-party sender and data-provenance rules

A batch is harder to evaluate when the bank sees only the third-party sender and not the underlying originators. FFIEC guidance notes that batch processing can obscure originator identities and that banks need policies and processes to monitor unusual activity involving ACH transactions and third-party providers. ³

The rule library should therefore include a data-provenance check. Before release, the institution should be able to answer:

1. Who submitted the file?
2. Which originators are represented?
3. Do the originators match the approved roster?
4. Are the amounts and transaction types within contracted limits?
5. Can the institution retrieve the underlying detail if the file is returned, separated, or investigated?

If those answers are unavailable, the failure is not merely a fraud-detection gap. It is a vendor-governance gap. The response should route to the relationship owner and vendor-risk process, not just to an analyst who can clear the next file.

How do you prevent the rule library from becoming a source of risk?

Separate rule administration from payment approval

The person who can change a filter should not be the only person who can approve a payment that the filter flags. Separate permissions for rule creation, rule activation, payment release, and exception approval. Log every change, including the old logic, new logic, reason, approver, and effective time.

This matters because a fraudster does not need to defeat every filter if a compromised administrator can quietly disable the one that matters. The FTC’s Safeguards Rule guidance calls for change management, logging authorized-user activity, monitoring for unauthorized access, and regularly testing safeguards for covered financial institutions. ⁴

Measure false positives and missed cases

Every rule needs performance measures. Track:

• Number of alerts generated.
• Number of alerts escalated.
• Number of legitimate payments delayed.
• Number of confirmed fraud attempts.
• Average time to disposition.
• Rules bypassed through manual override.
• Returns or complaints connected to previously cleared transactions.

A rule that generates 3,000 alerts and catches no confirmed fraud is not necessarily useless, but it is not ready to remain unchanged. The owner should tune the signal, narrow the population, combine it with another condition, or change the action from a hard hold to a risk-based review.

Test the complete workflow, not only the rule expression

A tabletop test should start with a realistic event: an AP employee’s credentials are compromised, a vendor’s bank account is changed, and a payment batch is created before the normal callback window. Then walk through the entire path:

• Does the rule see the change event?
• Does it attach the correct batch and user?
• Does the hold prevent release?
• Does the assigned analyst receive the alert?
• Is the backup approver known?
• Can the vendor be contacted through an independent channel?
• Is the decision recorded in a retrievable case?
• Can the institution explain what happened after the event?

For a Modesto credit union, this test should include the actual online banking portal, ACH processor, identity provider, ticketing system, SIEM or security-monitoring platform, and escalation contacts. A rule that works in a demonstration but loses its evidence when the transaction moves between systems is not operationally complete.

What should leadership review each month?

The board or executive risk committee does not need a dump of every alert. It needs a concise view of whether the control is working and whether risk is changing. A monthly packet can include:

• Top five rules by alert volume and confirmed-fraud yield.
• Originators with unusual return-rate or velocity changes.
• Exposure-limit exceptions and over-limit approvals.
• Manual overrides, including who approved them.
• Rule changes and overdue reviews.
• Open cases past the institution’s response target.
• Third-party sender reconciliation failures.
• Backup and recovery results for the ACH monitoring workflow.

This turns an ACH fraud filter library into a management control. It also gives the named team responsible for the system a way to show outcomes: fewer unexplained exceptions, faster holds, cleaner audit evidence, and clearer ownership.

Where Datapath fits

Datapath does not replace your bank’s ACH processor, fraud platform, compliance officer, or legal counsel. We help connect the operating pieces around them.

For a Modesto, Fresno, Modesto, or California financial institution, our finance technology team can help document the workflow from payment instruction to approval, monitoring, investigation, and recovery. Our managed cybersecurity team can help centralize relevant identity, endpoint, administrative, and application logs so an ACH alert is not isolated from the account-takeover activity that may have caused it.

Where an internal IT team owns the banking environment, co-managed IT can add implementation capacity without taking away institutional ownership. For executive-level control design, a vCISO engagement can help define rule ownership, exception authority, testing cadence, and reporting expectations. If a suspected compromise reaches the payment workflow, an incident response retainer gives the organization a defined path for containment and investigation.

The outcome we want is not another dashboard. It is a payment operation where a suspicious ACH batch stops for a reason, reaches the right person, and produces evidence of what happened. If your current filters cannot answer who owns the alert, what action follows, or when the rule was last tested, talk with Datapath about building a rule library that your operations, security, and leadership teams can actually use.

---

Footnotes

1. FedACH Services Tools and Nacha Risk Management | Federal Reserve Financial Services ↩

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

3. FFIEC BSA/AML Risks Associated with Money Laundering and Terrorist Financing - Automated Clearing House Transactions ↩

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