ACH Fraud Detection in 2026: How the Schemes Work and How to Stop Them

ACH fraud detection has traditionally focused on unauthorized transactions: cases where someone moves money without the account holder’s knowledge. The 2026 NACHA rule changes expand that scope significantly: institutions are now required to monitor for fraud even when the customer authorized the payment, provided they were deceived.
‍

That changes what your detection program actually needs to catch. This guide covers the four fraud patterns now in scope under the 2026 amendments, and what effective monitoring looks like for ODFIs and RDFIs today.

‍

Why ACH Fraud Detection Is Harder in 2026

The challenge with detecting authorized fraud is that the transaction itself looks legitimate. The customer hit approve. The payment went to an account they directed. There’s no credential theft signal, no device anomaly, no failed authentication.

The fraud is in the context: a spoofed vendor email, a redirected payroll deposit, an investment scheme that convinced the victim to wire their savings. Detecting it requires looking beyond the individual transaction to the entity history, behavioral patterns, and account relationships surrounding it.

That’s a meaningfully different detection problem than catching unauthorized ACH debits, and it’s what the 2026 rules are asking institutions to build for.

‍

The Four Fraud Patterns Your ACH Monitoring Needs to Cover

Business Email Compromise (BEC)

A company receives an email, apparently from a trusted vendor or executive, requesting a change to payment instructions. The accounts payable team updates the ACH template and the next payment goes to a fraudster-controlled account. From the originating institution’s perspective, everything looks normal: an authorized customer sending a payment to a new destination.

BEC is now explicitly covered under the 2026 ACH fraud rules. ODFIs need detection logic that flags changes to ACH payment destinations, particularly for high-value recurring payees before the next payment originates.

‍

Payroll Redirection

An employee’s credentials are compromised through phishing. The attacker logs into the payroll portal and updates the direct deposit routing to a mule account. The ODFI originates the payroll credit as normal. The RDFI receives it. Neither institution had a transaction-level signal that anything was wrong.

Detection here lives upstream: in the velocity of account changes, the timing of routing updates relative to payroll cycles, and the behavioral profile of the receiving account.

‍

Mule Account Activity

Fraudulently obtained funds need somewhere to go. Mule accounts, opened with stolen or synthetic identities to receive and redistribute fraud proceeds, are the infrastructure. RDFIs are the primary line of defense, and the 2026 rules put them explicitly on the hook for monitoring inbound ACH credits for mule patterns.

Detection signals include accounts receiving credits from multiple originators within a short window, immediate outbound movement upon receipt, payee name mismatches with the account on file, and transaction patterns inconsistent with the account’s stated purpose.

‍

Authorized Push Payment (APP) Fraud

A victim is manipulated, through romance scams, fake investment platforms, or impersonation schemes, into voluntarily sending money to a fraudster-controlled account. The customer behavior is indistinguishable from a legitimate transfer at the transaction level. Context is everything: has this customer ever sent a payment this size? To this type of counterparty? At this time of day?

APP fraud is the hardest category to detect and the one institutions have the least historical infrastructure for. It’s also the one driving the largest fraud losses in 2025–2026 across the industry.

‍

ACH Fraud Detection by Role: ODFIs vs. RDFIs

Detection requirements and detection approaches differ significantly by role. Building a single generic monitoring program without separating ODFI and RDFI logic is a common mistake that leaves gaps on both sides.
‍

ODFI Detection: Outbound WEB Debit Monitoring

• Account change velocity: flag ACH templates or routing details that changed recently before a high-value payment originates. BEC attacks almost always include a destination change event before the fraudulent payment.
• Origination pattern anomalies: first-time large payments to new counterparties, unusual timing relative to the customer’s history, or new SEC codes for established customers.
• Payroll-specific controls: for transactions using the new PAYROLL entry description, flag routing or account number changes close to a payroll run date.
• BEC typology rules: rules targeting the mechanics of common BEC scenarios: payments above threshold to recently changed destinations, changes to longstanding payment templates, and new payee additions for established originators.
  ‍

RDFI Detection: Inbound ACH Credit Monitoring

• Fuzzy name matching: compare the payee name on the incoming ACH entry against the account holder name on file. Exact matches across the ACH network aren’t always realistic, but significant discrepancies signal mule activity that warrants review.
• Mule account behavioral rules: entity-level rules that look across transactions, not just individual entries. Multiple credits from different originators in a short window, followed by rapid outbound movement, is the mule account pattern.
• Velocity checks: unusual credit volume relative to account history. An account that has received $300/month for 18 months, suddenly receiving $18,000 in a week, warrants review.
• New account monitoring: recently opened accounts receiving significant ACH credits are a higher-risk population. Time-since-opening is a useful signal in any RDFI rule set.

‍

Building Detection Rules Without an Engineering Dependency

One of the practical barriers institutions face is the gap between what their fraud teams know needs to be detected and what they can actually configure to detect. Writing detection logic that spans entity history, payment patterns, and account behavior has traditionally required engineering involvement that fraud operations teams don’t have direct access to.

The shift toward no-code detection platforms changes that equation. A rule like “flag any inbound ACH credit where the payee name match score is below threshold AND the account has received credits from 3 or more different originators in 7 days” should be something a fraud analyst can build and deploy without a development sprint.

That operational independence matters specifically because the 2026 rules require annual review and update of your monitoring procedures. A detection program that requires engineering involvement for every rule adjustment is going to struggle to meet that standard in practice.

‍

What “Reasonably Designed” Means in Practice

The practical test isn’t whether your controls catch every instance of fraud, that’s not a realistic standard and not what the rules require. The test is whether your detection is calibrated to your institution’s risk profile, documented, and defensible when an examiner asks how you made your decisions.

That means: your rules are written down and tied to specific fraud typologies, your thresholds have documented rationale, you’re tracking alert volume and false positive rates, and you’re updating your controls when fraud patterns shift. The annual review requirement makes that last point mandatory, not optional.

‍

What Comes Next

Detection is the front end. What happens after an alert fires, how cases get built, how decisions get documented, when a SAR is required, is where most institutions have more work to do and where regulatory exposure tends to be highest.

Part 3 covers the full ACH fraud investigation workflow: from first alert through case management, returns decisions, and SAR filing.

‍

For the entity-specific breakdown of what each institution type needs to monitor, see the NACHA 2026 overview.

For a question-and-answer breakdown of the 2026 ACH fraud rules, including how they apply to each institution type, whether data sharing is required, and what the rules say about specific fraud typologies, the 2026 NACHA Operating Rules FAQ is a useful companion to this piece.