Building ACH Detection Rules for NACHA 2026: A Step-by-Step Guide for ODFIs and RDFIs

The NACHA 2026 operating rules don't just expand what counts as fraud. They expand what your institution is expected to catch. If you're a fraud analyst or ops manager at an RDFI or ODFI, that means your detection rules need to cover new ground: mule account velocity, payee name mismatches, payroll redirection, and business email compromise patterns on ACH.

‍

This post walks through four detection rules you can build today, each mapped to a specific NACHA 2026 risk. We'll show you exactly how to configure them (conditions, thresholds, and SEC code filters) and test them safely before they go live.

‍

Two Roles, Two Sets of Rules

Before building anything, it's worth noting that NACHA 2026 creates different obligations depending on where you sit in the ACH network.

‍

RDFIs (Receiving Depository Financial Institutions) need to detect suspicious activity on incoming ACH credits, particularly patterns that indicate a receiving account is being used as a mule. The two rules below target the most common behavioral indicators.

‍

ODFIs (Originating Depository Financial Institutions) need to detect fraud at the point of origination, especially payroll redirection and business email compromise, both of which exploit changes to payment routing information. The NACHA 2026 requirement for the PAYROLL entry description field creates a direct detection opportunity here.

‍

RDFI Rule 1: Multi-Originator Velocity

What it detects: A receiving account credited by three or more distinct ACH originators within a seven-day rolling window. This is the most reliable behavioral signal for mule accounts under NACHA 2026.

‍

Mule accounts are the plumbing of ACH fraud. They receive funds from multiple compromised sources and move them out quickly. The pattern is consistent: a single account, multiple unrelated originators, short time window.

‍

Here's how to configure it:

• Rule name: RDFI: Multi-originator velocity
• Condition: COUNT DISTINCT originator company names on the same receiving account, within the last 7 days, >= 3
• Dollar threshold: Amount per transaction >= $200 (filters out micro-deposits and low-value noise)

‍

‍

The $200 floor is important. Without it, you'll flag every account that receives a mix of micro-deposits and legitimate small credits. The originator count threshold of 3 is a starting point; some teams tighten it to 2 after reviewing initial alert volumes in testing.

‍

RDFI Rule 2: Payee Name Mismatch

What it detects: An incoming ACH credit where the payee name in the transaction doesn't match the account holder name on file. This is a signal for misdirected payments and account takeover patterns.

‍

This is one of the simpler rules to build, but one of the more impactful ones to run. Name mismatches on inbound credits often indicate that either the originating party's account has been compromised (and payments are being rerouted to a controlled account) or the funds are intentionally misdirected.

• Rule name: RDFI: Payee name mismatch
• Condition: Payee name similarity score below 80% (fuzzy match threshold)
• Dollar threshold: Amount >= $500

‍

The fuzzy match threshold matters. Setting it too tight (e.g., 95%) will flag every "Robert" vs. "Bob" mismatch. At 80%, you catch meaningful discrepancies (different last names, completely unrelated names) while allowing for common abbreviations and formatting differences.

‍

Including WEB transactions in this rule is worth noting. WEB entries represent internet-initiated ACH debits and credits, and they're a common vector for authorized push payment fraud, in which social engineering leads to misdirected payments.

‍

ODFI Rule 3: PAYROLL Destination Change

What it detects: Any ACH origination with the PAYROLL entry description where the receiving account or routing number changed within seven days of the payroll run date.

‍

This rule directly takes advantage of NACHA 2026's new mandatory PAYROLL field. Before this rule change, payroll transactions were buried in a sea of generic CCD and PPD entries with no reliable way to distinguish them. Now, with the required PAYROLL entry description, ODFIs can build targeted detection logic for one of the highest-value fraud typologies: payroll redirection.

‍

The attack is straightforward: a fraudster gains access to an employer's payroll system (or impersonates HR) and changes the direct deposit destination for one or more employees. The payroll runs on schedule, but the money goes to a controlled account.

• Rule name: ODFI: PAYROLL destination change
• Condition 1: Entry description equals PAYROLL
• Condition 2: Receiving account number or routing number changed within the last 7 days
• Logic: AND (both conditions must be true to trigger)
• Dollar threshold: None. Flag all amounts.

‍

No dollar threshold here. Payroll redirection fraud can involve any amount, and even small test redirections are worth catching early. The AND logic ensures you're only flagging payroll-specific transactions with recent destination changes, not every account update across all ACH activity.

‍

Why this matters now: Before NACHA 2026, detecting payroll redirection required parsing company batch headers and making assumptions about entry descriptions. The mandatory PAYROLL field eliminates that guesswork. If your platform doesn't yet expose the entry description field in the rule builder, this is the time to confirm it's available.

‍

ODFI Rule 4: BEC Destination Change

What it detects: An ACH payment to a known counterparty where that counterparty's receiving account or routing number was recently updated. This is the classic business email compromise pattern applied to ACH.

‍

BEC on ACH works like this: an attacker impersonates a vendor or counterparty (usually via email) and instructs the originating company to update the vendor's payment details. The next scheduled payment goes to the attacker's account instead. The key behavioral signal is the combination of an established relationship and a recent change to payment routing.

• Rule name: ODFI: BEC destination change
• Condition 1: Payee is a known/existing counterparty (previously seen in transaction history)
• Condition 2: Receiving account number or routing number changed within the last 14 days
• Logic: AND (both conditions must be true)
• Dollar threshold: Amount >= $2,500

‍

‍

The 14-day lookback window is wider than the payroll rule because BEC attacks don't follow a payroll cycle; they can target any payment at any time. The $2,500 threshold focuses the rule on payments large enough to warrant investigation while filtering out low-value recurring charges that might naturally change routing.

‍

This rule pairs well with a structured case management workflow. Confirmed BEC cases often involve mule networks that warrant deeper investigation and potential SAR filing.

‍

Test Before You Deploy: Shadow Mode

Building rules is the first step. Deploying them responsibly is the second.

‍

Every new rule should go through a testing period before it goes live. In Unit21, this means toggling the rule into shadow mode: the rule evaluates against real transaction traffic and records what it would have flagged, but doesn't generate alerts that hit analyst queues.

‍

This is more than operational caution. It's a trust-and-confidence mechanism. A rule that accidentally flags 10% of your good customers does real damage, not just operationally, but to customer experience and revenue. Shadow mode lets you see projected alert volumes, review the types of transactions being caught, and tune thresholds before anything goes live.

‍

For the rules in this post, we recommend a 2 to 4-week shadow period. During that window, review:

• Volume: Are you generating a manageable number of alerts, or is the rule too noisy?
• Quality: Are the flagged transactions genuinely suspicious, or are they catching legitimate activity?
• Thresholds: Do the dollar amounts and lookback windows need adjustment based on your institution's transaction patterns?

‍

‍

Only after shadow testing confirms the rule is performing as expected should you move it to live deployment.

‍

Monitoring Rules in Production

Once your ACH detection rules are live, the work shifts from building to monitoring. Your alert queue should show alerts generated by the rules you've deployed, each tied to a specific rule, entity, and transaction.

‍

A well-configured alert queue gives your analysts immediate context: which rule fired, what account or entity triggered it, the transaction amount, and the current status. This is the starting point for the investigation workflow covered in Part 2 of this series.

‍

Over time, monitoring your alert queue is also how you gather the performance data you'll need for annual program reviews: alert volume trends, disposition breakdowns, and false positive rates. We'll cover that in detail in Part 3.

‍

What's Next

This post covered four detection rules aligned to NACHA 2026: two for RDFIs (mule velocity, payee mismatch) and two for ODFIs (payroll redirection, BEC destination change). Each addresses a specific fraud typology that the new operating rules expect you to detect.

‍

But detection is only the first step. In Part 2, we follow an analyst from alert to SAR: investigating a mule account alert, reviewing transaction history, uncovering linked entities, creating a case, and filing. In Part 3, we cover the program documentation that NACHA examiners actually review: rule inventories, performance analytics, and audit logs.

‍

If you want to see these rules in action or build your own for your institution's specific ACH patterns, request a demo, and we'll walk through it together.

‍