Investigating ACH Fraud Alerts for NACHA 2026: From Alert to SAR

Detection rules generate alerts. But alerts don’t stop fraud; investigations do. A rule that fires on a suspicious pattern is only useful if your analysts can quickly confirm what happened, connect it to broader activity, and act on it.

‍

This is Part 2 of our NACHA 2026 series. In Part 1, we built four detection rules for mule accounts, payee mismatches, payroll redirection, and BEC. Now we follow what happens after those rules fire: an analyst picks up an alert, investigates the underlying activity, links related entities, escalates to a case, and files a SAR, all within a single workflow.

‍

We’ll walk through two investigation tracks that map to the most common NACHA 2026 scenarios: an RDFI mule account alert and an ODFI business email compromise alert. The mechanics are different, but the workflow is the same.

‍

Starting from the Alert

When a detection rule fires, it creates an alert in your queue. The alert carries context from the rule that generated it: what condition was met, which entity triggered it, the transaction amount, and when it happened.

‍

This is the analyst’s starting point. A well-structured alert tells you enough to decide whether to investigate further or close it out, without having to jump between systems to piece together what happened.

‍

Here’s what an analyst sees when opening a mule account alert fired by the multi-originator velocity rule from Part 1:

‍

‍

The key elements on this screen: the rule that fired (so the analyst knows what pattern was detected), the entity and account involved, the transaction that triggered the alert, and the amount. If the platform provides a condition breakdown and a plain-language explanation of why the rule fired, that’s even better. It saves the analyst from having to mentally reconstruct the logic.

‍

From here, the investigation branches depending on what type of fraud the rule flagged. We’ll start with the RDFI mule account track.

‍

Track 1: RDFI Mule Account Investigation

The multi-originator velocity rule flagged a receiving account that was credited by three or more distinct ACH originators within seven days. That’s the behavioral signal. Now the analyst needs to answer a simple question: Is this a mule account, or is there a legitimate reason multiple companies are sending money here?

‍

Reviewing Transaction History

The first step is pulling up the entity’s full transaction history. The analyst needs to see not just the transaction that triggered the alert, but the complete picture: every ACH credit this account has received, from whom, and over what period.

‍

What you’re looking for is the mule pattern: multiple credits from unrelated originators, often in similar amounts, concentrated in a short window. Legitimate accounts receive credits from multiple sources too (think: someone with two jobs and a side gig), but the originator mix and timing look different.

‍

‍

‍

In this view, the analyst can see multiple ACH credits from different originator companies all hitting the same account. The originator names are varied and unrelated: across different industries and geographies. That’s a strong mule signal. A legitimate account might receive credits from an employer, a tax refund, and a family transfer. A mule account receives credits from a payroll company, a small business, and a healthcare provider, none of which have an obvious connection to each other or to the account holder.

‍

The transaction history also shows the outflow side. Mule accounts typically don’t hold funds. Look for rapid outbound transfers: wire transfers, P2P payments, or cash withdrawals, shortly after the credits land. If the money is moving out as fast as it comes in, that’s the second half of the mule pattern.

‍

Finding the Ring: Linked Entities

A single mule account is rarely isolated. Fraud rings operate networks of accounts, and those accounts often share attributes: the same phone number registered across multiple accounts, the same device fingerprint, overlapping IP addresses, or matching email domains.

‍

This is where entity linking becomes critical. From the flagged account, the analyst navigates to the linked entity view to see whether this account shares attributes with others.

‍

‍

This is the ring detection moment. The graph (or table, depending on your platform’s visualization) shows that the flagged account shares a phone number with two other accounts, one of which shares a device fingerprint with a fourth. Suddenly, the investigation isn’t about one suspicious account; it’s about a connected network.

‍

This changes the scope of the investigation and, ultimately, the SAR. Instead of filing on a single account, you may be documenting a coordinated mule operation. The linked entity view gives the analyst the evidence to make that call without manually cross-referencing account attributes in spreadsheets.

‍

Why this matters for NACHA 2026: The updated operating rules put explicit emphasis on detecting mule account patterns at RDFIs. A single-account investigation might satisfy the letter of the requirement, but identifying the full ring demonstrates a mature fraud detection program, exactly what NACHA examiners are looking for during reviews.

‍

Track 2: ODFI BEC Investigation

The second investigation track follows a BEC destination change alert. This one came from the ODFI side; the rule flagged an ACH payment to a known vendor where the receiving account or routing number was recently updated.

‍

The investigation flow is structurally similar to the mule account track, but the analyst is looking for different signals. Instead of a pattern across many originators, you’re looking at a single relationship where something changed.

‍

The key questions for a BEC investigation:

• Was the account change requested through a verified channel?
• Does the new routing number correspond to the same bank the vendor previously used, or did it shift to an entirely different institution?
• Were there recent communications (email, phone) requesting the change that could indicate impersonation?
• Is the payment amount consistent with the established pattern for this vendor, or is it unusually large?

‍

BEC investigations often require outreach beyond the platform, calling the vendor to confirm the account change, checking email headers, or coordinating with the originating company’s finance team. But the starting point is the same: the alert gives the analyst the context to know something changed, and the entity and transaction history provide the evidence to assess whether that change was legitimate.

‍

From here, both tracks converge on the same workflow: case creation and SAR filing.

‍

Escalating to a Case

When an alert investigation confirms suspicious activity, the analyst escalates it to a case. A case is a container for the full investigation; it groups the triggering alert, the analyst’s findings, linked entities, supporting evidence, and any actions taken.

‍

The distinction between alerts and cases matters operationally. Alerts are high-volume, automated signals. Most get reviewed and closed. Cases represent confirmed investigations that require documentation, approval workflows, and potentially regulatory filings. Keeping them separate prevents your investigation queue from being buried under alert noise.

‍

‍

In this view, the analyst creates a case (or attaches the alert to an existing one), assigns it, and adds initial notes. For the mule account track, the case might be titled something like “ACH mule ring - Q2 2026” and contain multiple alerts if the linked entity analysis uncovered additional accounts. For the BEC track, it’s typically a single-alert case tied to a specific vendor payment.

‍

The case becomes the single source of truth for the investigation. Everything that happens from here: additional analysis, internal escalation, SAR filing, is documented within it. This matters for two reasons: it gives your compliance team an auditable record, and it ensures nothing falls through the cracks during handoffs between analysts or shifts.

‍

Filing the SAR

‍

When a case warrants a SAR filing, the analyst initiates it directly from within the case. This is a deliberate design choice, SAR creation shouldn’t be a separate, disconnected process that requires the analyst to re-enter information from scratch in a different system.

‍

‍

The SAR form pulls in context from the case: the subject entity, the date of detection, the associated transactions, and the investigation timeline. The analyst enters the filing reason (BSA/AML violation or ACH fraud) and drafts the narrative.

‍

The narrative is where the investigation comes together. For the mule account case, it describes the behavioral pattern (multiple unrelated originators crediting the same account), the linked entity analysis (shared attributes across accounts suggesting a coordinated ring), and the transaction evidence (rapid movement of funds after credits land). For the BEC case, it documents the destination change, the vendor relationship, and any confirmation that the change was unauthorized.

‍

A note on SAR narratives: The quality of your narrative depends directly on the quality of the investigation record. If your case includes the alert context, transaction history, linked entity analysis, and analyst notes, writing the narrative is simply a matter of organizing the existing evidence. If those artifacts live in different systems, or worse, in the analyst’s memory,  the narrative becomes a reconstruction exercise that takes longer and produces weaker filings.

‍

The Full Workflow, End to End

Here’s what the analyst just did, from start to finish:

• Alert triage. Opened the alert, reviewed the rule that fired, and assessed the initial context.
• Transaction review. Pulled the entity’s full transaction history to confirm the suspicious pattern.
• Entity analysis. Used linked entity views to identify connections to other accounts and assess the broader scope.
• Case creation. Escalated the alert to a case, attaching all evidence and notes.
• SAR filing. Initiated the SAR from within the case, with context auto-populated and the narrative built from investigation artifacts.

Every step happened within a single platform. No switching between a transaction monitoring system, a case management tool, and a SAR filing application. No re-keying data. No evidence lost in the handoff.

‍

That’s not a convenience feature. It’s an operational requirement for teams handling the volume of ACH alerts that NACHA 2026 will generate. If your investigation workflow has friction, it doesn’t scale, and the new operating rules are about to increase alert volumes across the board.

‍

What’s Next

This post covered the investigation workflow from alert to SAR: how to triage ACH fraud alerts, confirm suspicious patterns through transaction and entity analysis, escalate to cases, and file SARs, all within a connected workflow.

‍

But investigations and SARs are only part of what NACHA examiners review. They also look at how your program is documented: your rule inventory, rule performance data, modification history, and evidence that your detection program is actively maintained and improved over time.

‍

In Part 3, we cover program documentation: the rule inventories, performance analytics, and audit logs that NACHA examiners actually review during the annual assessment. These aren’t just compliance artifacts; they’re what prove your detection rules aren’t just built, but managed.

‍

If you want to see this investigation workflow in action with your own ACH data, request a demo, and we’ll walk through it together.