ACH Fraud Investigation: From First Alert to SAR Filing

ACH fraud investigation is where most compliance programs have their biggest gap. Detection capabilities have improved significantly across the industry, including rule engines, entity monitoring, and velocity checks. But the workflow that converts an alert into a documented case, a return decision, and a defensible regulatory filing is often underdeveloped.

‍

The NACHA 2026 rules don’t prescribe investigation workflows explicitly. But they require documented procedures and annual review, which implicitly requires a program that handles cases consistently, records decisions, and produces audit-ready evidence. Here’s how to build it.

‍

Triage: The First Step in Every ACH Fraud Investigation

Not every alert warrants a full investigation. A program that escalates every flagged transaction uniformly will either overwhelm fraud operations or build in so much tolerance for false positives that real fraud moves through undetected.

Triage is the first decision: does this alert have enough signal to escalate to a case, or can it be resolved on available context? Common triage criteria include:

• Alert score or rule confidence level
• Transaction size and counterparty type
• Entity history — new accounts and first-time originators warrant closer review
• Whether related alerts have fired on the same entity recently

The most common mistake at this stage isn’t the triage decision itself, it’s the lack of documentation. An alert closed without investigation needs a recorded reason. “Cleared, customer profile consistent with transaction” is defensible. “Dismissed” with no rationale isn’t, particularly in a post-exam environment where every closure is potentially reviewable.

‍

ACH Fraud Investigation: Building the Case

When an alert escalates, the investigative workflow matters more than the tool. The core question is consistent: is there enough context here to reach a determination, and if not, what additional information would change that?

‍

For ACH fraud, the most useful context is almost never limited to the transaction in question. It’s the entity history: how long the customer has been with the institution, what their activity baseline looks like, whether they have prior alerts, and whether related accounts or counterparties have also been flagged.

‍

Linking related cases is especially important for the fraud typologies the 2026 rules target. Mule account networks involve many accounts with similar behavioral patterns. An investigation scoped to a single account will miss the broader scheme. Case management tooling that surfaces and links related entities automatically is not a luxury in a post-2026 environment, it’s a program requirement.

‍

Time pressure is real. ACH return windows are limited: for ODFI-requested returns, typically 5 banking days from settlement. For customer-reported unauthorized transactions, RDFIs have longer windows but only if their process can move quickly. Investigation workflows that take weeks don’t fit ACH timelines.

‍

Using NACHA’s Own Tools in ACH Fraud Response
‍

Return Codes

Return codes let RDFIs return transactions with a coded reason. Using the right return code for fraud-related returns matters for two reasons: it helps your institution track fraud accurately over time, and it protects your return rate metrics. Reflexive use of non-specific codes, or using no-reason returns as a default, creates a data quality problem that obscures your fraud picture and can attract NACHA scrutiny on return rates.
‍

The ACH Contact Registry

NACHA maintains a registry of contact information for ACH participants. When coordination with the originating institution is needed, flagging a mule account, requesting an ODFI return, or sharing pattern information about an emerging scheme, the Contact Registry is the right channel. Most institutions have access and rarely use it systematically. Building Contact Registry lookups into your investigation workflow, rather than relying on informal relationships, creates a faster and more consistent path to cross-institution coordination.
‍

Fund Delay Options

RDFIs have tools available to place holds on ACH credits when fraud is suspected. Applying these options requires understanding when they’re appropriate and documenting the basis for the hold. As with all discretionary decisions in a fraud investigation, the documentation is as important as the action: what triggered the hold, what the basis for suspicion was, and how it was resolved.

‍

The SAR Decision: What ACH Fraud Cases Require

Many ACH fraud cases will trigger a SAR obligation. The threshold is transactions at or above $5,000 (or $25,000 if the subject cannot be identified) where there’s reason to suspect illegal activity and no legitimate explanation has emerged. The filing window is 30 calendar days from initial detection, extendable to 60 if additional investigation is ongoing.

Three mistakes appear consistently in SAR filings for ACH fraud cases:
‍

Weak Narratives

A SAR narrative that says “suspicious ACH activity” satisfies the technical filing requirement and provides essentially no value to examiners or law enforcement. The narrative should describe the fraud typology, the transaction amounts and timing, what the investigation found, what action was taken, and what made the activity suspicious. It’s the place where investigative work product gets summarized. It matters.
‍

Undocumented No-File Decisions

Not every ACH fraud investigation results in a SAR, and that’s appropriate. But the decision not to file requires documentation: what information resolved the suspicion, why the activity was determined not to meet the threshold. “Reviewed and closed” without a rationale creates audit exposure. The no-file decision is still a decision.
‍

Missed Continuing Activity Obligations

For ongoing situations: accounts showing repeated mule-pattern behavior, customers with recurring suspicious originations, one SAR doesn’t satisfy the obligation. Continuing activity SARs should follow on a regular cadence until the activity stops or the relationship is exited. Many institutions file the initial SAR correctly and lose track of the follow-up.

‍

Managing the Operational Impact

The 2026 ACH fraud rules will increase alert volumes for many institutions, particularly RDFIs that haven’t previously monitored inbound credits at this level of granularity. Planning for that volume increase is part of implementation, not an afterthought.

‍

Cross-team coordination is unavoidable. ACH fraud investigations touch fraud operations, payment operations, compliance, and often customer service. Institutions with clear escalation paths and documented handoffs between these teams close cases faster with less friction. Those relying on informal norms will feel the increase in volume disproportionately.

‍

Workflow automation: routing alerts by rule type, pre-populating case context, automatically surfacing related entities, is what separates a program that absorbs volume from one that drowns in it.

‍

What Comes Next

Detection and investigation are the operational core of ACH fraud compliance. Part 4 covers the program layer: what to document, how to structure the annual review the rules require, and what examiners actually look for when they evaluate your NACHA compliance posture.

‍

For the entity-specific breakdown of ODFI, RDFI, TPS, and TPSP obligations, see the NACHA 2026 overview.

‍

For quick-reference answers to common NACHA 2026 questions, including effective dates, entity-specific obligations, mule account identification, and privacy considerations in ACH fraud monitoring, the 2026 NACHA Operating Rules FAQ covers the practical questions teams are working through right now.

‍