ACH Fraud Monitoring Controls: How Datapath Helps Central Valley Finance Teams Turn NACHA Rules Into an Operating Workflow

ACH fraud monitoring is not simply a matter of buying a transaction-screening tool. For a Modesto credit union or other Central Valley financial institution, the defensible approach is a documented, risk-based workflow that connects payment authorization, anomaly detection, return-rate analysis, escalation, vendor oversight, and annual review to named owners.

At 9:07 a.m. on a Tuesday, a Modesto credit union’s treasury manager is approving the payroll ACH file for a regional healthcare employer. The file looks routine: familiar company ID, familiar settlement account, familiar payday. But the employee who normally releases it is on vacation, and a recently changed workstation is now being used to upload the file.

The file contains a new batch total, an unusual concentration of payments to recently added accounts, and a last-minute change to the originating account. The decision is not theoretical. Someone must determine whether to release the file, hold it for verification, or escalate it to the credit union’s fraud and operations teams. If the control fails, the institution may have to investigate unauthorized entries, contact receiving institutions, manage returns, explain the event to the customer, and defend why its monitoring process did—or did not—identify the warning signs.

That is the practical problem behind ACH fraud monitoring controls under the NACHA Operating Rules and FFIEC examination guidance¹. The goal is not to inspect every entry manually. It is to build a repeatable control system that can recognize unusual activity, assign accountability, and create evidence that the process works.

What changed under the NACHA fraud-monitoring rules?

The most important shift is from a narrow focus on selected transaction types to a broader, role-based risk-management obligation. Nacha’s Phase 2 fraud-monitoring rules became effective June 19, 2026, for non-consumer Originators, Third-Party Service Providers, and Third-Party Senders that were not covered by Phase 1.²

Phase 2 also removed the earlier volume threshold for those non-consumer participants. In practical terms, a smaller business sending payroll, vendor, or healthcare-related ACH files cannot assume that low volume means no control responsibility.²

The rule does not prescribe one specific software product, algorithm, alert threshold, or screening architecture. Instead, each participant must establish and implement risk-based processes and procedures relevant to its role and reasonably intended to identify entries that may be unauthorized or authorized under false pretenses. Those processes must be reviewed at least annually and updated as risks evolve.²

That distinction matters to a buyer. A vendor may promise “AI-powered ACH fraud detection,” but a tool by itself does not answer the operational questions:

• Who owns the payment-risk decision?
• Which changes require out-of-band verification?
• What happens when a file is flagged after the normal approval window?
• How are exceptions documented?
• Which party monitors the customer, the file, the receiving account, and the return activity?
• When does the organization review and update the procedure?

A strong control program answers those questions before the suspicious file arrives.

What does FFIEC guidance add to the NACHA framework?

NACHA establishes network rules and participant responsibilities. FFIEC examination guidance adds a broader risk-management lens, particularly around due diligence, suspicious-activity monitoring, third-party relationships, and management reporting.

For ACH activity conducted through third-party service providers, FFIEC guidance highlights the importance of understanding the originator, the payment activity, transaction volumes, and the provider’s controls. It also recognizes that batch processing can obscure the identity and behavior of individual originators, which makes customer due diligence and pattern-based monitoring especially important.³

This is where ACH monitoring becomes more than a transaction-screening problem. The institution needs visibility across several layers:

Control layer	What to monitor	Example decision owner	Evidence to retain
User and payment authorization	New users, changed entitlements, unusual release behavior, dual approval exceptions	Treasury operations or payment administrator	Approval record, authentication event, exception reason
File and batch behavior	Dollar amount, velocity, company ID, SEC code, settlement date, account changes	ACH operations and fraud team	Alert details, disposition, supporting verification
Originator profile	Expected volume, business activity, account age, payment purpose, seasonal patterns	Relationship manager, compliance, or risk team	Risk rating, review notes, updated profile
Third-party processor	Merchant base, transaction mix, complaints, return patterns, due diligence	Vendor-risk and compliance owner	Contract, review packet, remediation plan
Returns and post-processing signals	Unauthorized, NSF, invalid-account, account-not-found, and other return categories	ACH risk committee or designated analyst	Trend report, escalation record, corrective action
Response and recovery	Hold, release, return request, receiving-bank contact, customer notification	Incident lead with operations	Timeline, communications, final resolution

The FFIEC BSA/AML guidance specifically warns that ACH transactions originated through a third-party service provider can increase risk when the ODFI cannot directly assess the originator⁴. It calls for appropriate customer due diligence and monitoring for unusual activity, recognizing that individual ACH transactions are typically not reviewed one by one.

For a financial institution, that supports a risk-based design: establish normal activity baselines, identify meaningful deviations, and investigate the exceptions that deserve human attention. For an organization using ACH through its bank, it means understanding which controls belong to the business and which belong to the ODFI or payment provider. Responsibility should be assigned contractually and operationally—not assumed.

Which ACH signals deserve attention first?

A useful monitoring program begins with signals that map to real operating decisions. The exact thresholds should reflect the organization’s risk appetite, customer base, transaction types, and historical activity. The following are control categories, not universal NACHA thresholds:

1. Payment-instruction changes

A change to a vendor’s bank account, an employee’s direct-deposit details, or the account used to fund an ACH file should trigger a separate verification path. The person who enters the change should not be the only person who approves the resulting payment.

For a Modesto credit union, that could mean verifying a high-risk change through a known phone number, requiring two authorized employees to approve the release, and preserving the verification record in the case-management system.

2. Deviations from the originator’s baseline

Monitoring should compare current activity with the originator’s normal profile. Useful dimensions include:

• Dollar value and total batch count
• Payment velocity and settlement timing
• New receivers or unusually concentrated destinations
• SEC-code and account-type mismatches
• Sudden changes after a credential reset or administrator change
• Activity outside normal business hours
• A new device, location, or network path used for payment release

The objective is not to block every unusual transaction. It is to identify the unusual activity that requires verification before the organization accepts the risk of release.

3. Return-rate and return-reason trends

A program that only counts unauthorized returns is incomplete. FFIEC guidance recommends examining other return categories—including insufficient funds, invalid account, and account-not-found activity—because unusual levels may also indicate fraud or suspicious activity.

The OCC has also cited a 2.5 percent ACH return rate as well above the acceptable rate for normal business purposes, while warning that fraud analysts should not rely exclusively on excessive unauthorized returns. That figure should not be treated as a universal safe harbor or an automatic violation trigger. It is a decision point for deeper investigation, especially when the rate is rising, concentrated in one originator, or accompanied by other anomalies.

A better dashboard therefore shows return rates by originator, return reason, time period, transaction type, and third-party relationship. It should also explain meaningful variances rather than displaying a percentage without context.

What should happen when monitoring flags an ACH entry?

Nacha does not require every entry to be screened individually or require monitoring to occur before processing. However, it recognizes that earlier monitoring provides the best opportunity to detect and prevent potential fraud. When an ODFI identifies a suspicious entry, possible actions include stopping further processing, consulting the Originator, checking other internal monitoring systems, contacting the RDFI, or requesting a freeze or return of funds.

Datapath recommends turning those possibilities into a written response playbook with four decision stages:

Stage 1: Triage the alert

Record the alert reason, affected account or originator, dollar amount, settlement timing, and related activity. Avoid allowing an alert to sit in an unowned queue while the settlement window closes.

Stage 2: Verify through an independent channel

Do not confirm a changed payment instruction by replying to the same email thread or calling a number supplied in the suspicious request. Use a previously verified contact method and document who confirmed what.

Stage 3: Decide and escalate

The authorized decision-maker should choose among release, hold, additional review, return request, or incident escalation. The decision should include a reason—not merely “approved” or “declined.”

Stage 4: Close the loop

Capture the final disposition, customer communication, evidence reviewed, control gap, and any required change to the originator profile or procedure. A closed alert without a lessons-learned step is a missed opportunity to improve the baseline.

How should a bank or credit union govern ACH monitoring?

The operational controls need management oversight. OCC guidance describes a mature ACH risk program as including board-approved risk tolerances, clearly defined duties, ACH credit-risk management, vendor due diligence, and oversight of third-party service providers.

In practice, that means management should be able to answer questions such as:

• Which originators are prohibited, restricted, or subject to enhanced review?
• What transaction volume and return-rate trends reach the risk committee?
• Which alerts were overridden, by whom, and why?
• How quickly are suspicious files investigated?
• How are changes to payment credentials or bank instructions controlled?
• What evidence shows the annual review occurred?
• Which vendors can access payment data or initiate files, and how are they assessed?

A centralized security-information-and-event-management platform can help correlate identity, endpoint, and payment-system events, but it should support—not replace—the ACH operating procedure. The useful outcome is a traceable chain from an event to an alert, from an alert to a decision, and from the decision to a retained record.

For a mid-market organization, a co-managed model may be appropriate: internal finance staff retain payment authority while an external security team helps monitor identity events, endpoint changes, alert queues, and escalation coverage. Datapath’s co-managed IT services can support that division of responsibility without taking payment approval away from the business.

What should non-bank businesses do now?

A business does not need to operate an ACH network to improve its side of the control environment. Start with the payment workflow rather than the product shortlist:

1. Inventory every ACH initiation path, including bank portals, payroll platforms, accounting software, APIs, and third-party processors.
2. Assign a named owner for payment-file creation, approval, release, and post-settlement reconciliation.
3. Separate entry from approval wherever practical; use dual control for higher-risk changes and releases.
4. Define what counts as an unusual payment for your organization.
5. Require independent verification for changes to vendor, employee, or funding-account information.
6. Review return activity by reason and counterparty, not just total dollars.
7. Test the escalation path with a realistic scenario, such as a payroll file created from a new device at 8:55 a.m.
8. Review the procedure at least annually and after major changes to banking, payroll, staffing, or vendors.

Datapath can help a Central Valley finance team connect these controls to identity management, endpoint security, Microsoft 365 audit data, vendor-risk reviews, and incident response. Our managed cybersecurity services are designed around accountable monitoring and escalation—not a generic alert feed.

Why this matters beyond the audit file

The strongest reason to formalize ACH monitoring is not to produce a better binder. It is to shorten the time between a suspicious change and a controlled decision.

For a credit union, that can mean a clearer conversation between ACH operations, fraud analysts, the relationship team, and the receiving institution. For a healthcare organization, it can protect payroll and critical vendor payments while the clinical operation is already under pressure. For a local government department, it can make finance approvals more resilient when staffing changes or urgent payments create exceptions.

Datapath serves finance organizations, healthcare and clinics, local government, public safety, K-12 districts, and mid-market businesses across Modesto, Fresno and the wider Central Valley, as well as Modesto and California communities including Modesto. We bring a named team to the control conversation: the people responsible for monitoring, documenting, escalating, and improving the workflow.

If your ACH process depends on one person noticing one suspicious file at the right moment, it is time to map the process. Start with Datapath’s finance solutions team or contact us to discuss where payment controls, cybersecurity monitoring, and accountable response should meet.

---

Footnotes

1. FFIEC BSA/AML Risks Associated with Money Laundering and Terrorist Financing - Third-Party Payment Processors ↩

2. RISK MANAGEMENT TOPICS – (Fraud Monitoring Phase 2) | Nacha ↩ ↩² ↩³

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

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