Documenting Your ACH Fraud Detection Program for Nacha 2026

Building detection rules is the first step. Investigating the alerts they generate is the second. But neither matters to an examiner if you can’t prove it.

‍

This is Part 3 of our Nacha 2026 series. In Part 1, we built four ACH detection rules. In Part 2, we followed an analyst from alert through investigation to SAR filing. Now we cover the layer that ties the whole program together: documentation.

‍

Nacha’s updated operating rules don’t just require you to detect fraud. They require you to demonstrate that your detection program is actively maintained, regularly reviewed, and producing measurable results. That means rule inventories, performance data, and audit trails. Examiners aren’t looking for a one-time build. They’re looking for evidence of an ongoing program.

‍

The good news: if your detection and investigation workflows are already running in a single platform, most of this documentation generates itself. The challenge is knowing what examiners expect to see and making sure it’s accessible when they ask for it.

‍

What Examiners Actually Review

Nacha examiners conducting annual assessments typically focus on three areas of program documentation:

• Rule inventory. A complete list of all active detection rules, including their status, when they were created, and when they were last modified.
• Performance analytics. Data showing how each rule is performing over time: alert volume, disposition breakdowns (confirmed fraud, not fraud, inconclusive), and false positive rates.
• Audit trails. A record of every change made to a rule: who changed it, what changed, and when. This is the evidence that rules are being tuned and reviewed, not just deployed and forgotten.

‍

These three artifacts, taken together, tell a story. The rule inventory shows what you’re detecting. The performance data shows whether it’s working. The audit trail shows that you’re actively managing and improving it. An examiner who sees all three has what they need to confirm your program meets the Nacha 2026 standard.

‍

Let’s walk through each one.

‍

Rule Inventory: What You’re Running

The rule inventory is the simplest of the three, and it’s where examiners start. They want to see every active detection rule in one place, with enough metadata to understand what each rule does and whether it’s current.

‍

At a minimum, the inventory should show:

• Rule name: What the rule is called and, ideally, a brief description of what it detects.
• Status: Whether the rule is live, in shadow/testing mode, or disabled.
• Last modified date: When the rule was last updated. A rule that hasn’t been touched in two years raises questions.
• Created by / modified by: Who built or last edited the rule. This supports accountability and makes it clear that rule management isn’t orphaned.

‍

Here’s what this looks like in practice:

‍

‍

In this view, you can see the ACH detection rules built in Part 1 of this series (RDFI: Multi-originator velocity, RDFI: Payee name mismatch, ODFI: PAYROLL destination change, ODFI: BEC destination change) alongside your other active rules. Each entry shows the rule name, its current status, and when it was last modified.

‍

The value of this view goes beyond compliance. It’s also how your fraud operations team manages its own detection program. If an analyst notices alert volumes spiking, the rule inventory is the starting point for figuring out which rule is responsible. If a new team member joins, it’s how they get oriented to what’s already in place.

‍

A practical note: If your rule inventory lives in a spreadsheet that someone manually updates, it’s going to drift out of sync with reality. The rules list should be generated directly from the platform, so it’s always current. Any rule that’s active in your system should automatically appear in the inventory.

‍

Performance Analytics: Whether It’s Working

A rule inventory tells examiners what you’re running. Performance analytics tell them whether it’s working. This is typically the centerpiece of the annual review, because it’s where you demonstrate that your detection program produces real results.

‍

The core metrics examiners look for:

• Alert volume over time. How many alerts each rule generated over a given period. Trends matter here: a sudden spike might indicate a new fraud pattern or a misconfigured threshold.
• Disposition breakdown. Of the alerts generated, how many were confirmed fraud, how many were cleared as legitimate, and how many were inconclusive. This is the most direct measure of rule quality.
• False positive rate. The percentage of alerts that turned out to be legitimate activity. A false positive rate that’s too high means the rule is creating noise. A rate that’s too low might mean the rule is too narrow.

‍

‍

This view shows performance data for the ACH detection rules over time. The disposition breakdown is especially important: it tells you (and the examiner) whether the rule is catching real fraud or mostly generating noise that your analysts have to work through.

‍

The Nacha 2026 annual review expects 12 months of performance data. If you’re building new rules now, that means the data you start collecting today is what you’ll present at your next review. There’s no way to backfill it, which makes starting the data collection process early a practical necessity, not just a best practice.

‍

Performance data also drives rule tuning decisions. If a rule’s false positive rate is above 70%, that’s a signal to adjust thresholds or add conditions. If a rule is generating zero alerts, it might be too restrictive or the underlying fraud pattern might not be present in your transaction mix. Either way, the data tells you what to do next.

‍

Why 12 months matters: Examiners aren’t just looking for a snapshot. They want to see trends. A rule that started with a 60% false positive rate and dropped to 30% after threshold adjustments tells a story of active management. A rule that’s been at 60% for the full year tells a very different story.

‍

Audit Trails: Proof of Active Management

The audit trail is the third piece of the documentation triad, and in many ways it’s the most revealing. Rule inventories and performance data show what you have and how it’s performing. The audit trail shows that someone is paying attention.

‍

What examiners want to see in the audit log:

• What changed. Every modification made to a rule: threshold changes, condition updates, status changes (shadow to live, live to disabled).
• Who changed it. The name or role of the person who made the change.
• When it changed. The date and time of the modification.

‍

Here’s what a rule change history looks like:

‍

‍

In this view, you can see the modification history for a single rule. Each entry shows what was changed (for example, the dollar threshold was adjusted from $200 to $300), who made the change, and when. Even two or three log entries are enough to demonstrate that the rule is being actively maintained.

‍

The audit trail serves a dual purpose. For examiners, it’s evidence that your annual review cycle is functioning and that rules are being tuned based on performance data. For your own team, it’s a record of institutional knowledge. When an analyst adjusts a threshold, the next person who reviews that rule can see why the change was made and what the previous value was.

‍

Without an audit trail, rule changes are invisible. An examiner has no way to distinguish between a program that’s been actively managed for 12 months and one that was set up once and never touched. The audit log is the difference.

‍

Putting It Together: The Annual Review

Nacha 2026 requires an annual review of your ACH fraud detection program. When that review happens, the examiner is going to ask for three things:

• Show me your rules to confirm you’re running detection rules that cover the required fraud typologies.
• Show me their performance to confirm those rules are producing results and that you’re measuring their effectiveness.
• Show me the change history to confirm you’re actively managing and improving the program over time.

‍

If those three artifacts are generated from the same platform where your rules run, your investigation workflows execute, and your SARs are filed, producing them is a matter of pulling up the right views. There’s no assembly required, no reconciliation between systems, and no risk that the documentation doesn’t match what’s actually running.

‍

If they live in separate systems, or worse, in manually maintained documents, the annual review becomes a multi-week project to collect, reconcile, and format the required artifacts. That’s time your compliance team could spend on actual program improvement instead of documentation logistics.

‍

The Three-Part Picture

This series has covered the full lifecycle of an ACH fraud detection program under Nacha 2026:

• Part 1: Detection. Building detection rules for mule accounts, payee mismatches, payroll redirection, and BEC, with shadow testing before deployment.
• Part 2: Investigation. Following an analyst from alert triage through transaction review, linked entity analysis, case creation, and SAR filing.
• Part 3: Documentation. Documenting the program with rule inventories, performance analytics, and audit trails for the annual review.

‍

Each part builds on the previous one. The detection rules generate the alerts. The investigation workflow resolves them. The documentation layer proves the whole system is working. Miss any one of the three, and you have a gap that an examiner will find.

‍

The common thread across all three parts is that they work best when they’re connected. Detection rules that generate alerts in one system, investigations that happen in another, and documentation that’s assembled in a third create friction at every handoff. A single platform that handles rules, alerts, cases, SARs, and program documentation eliminates that friction and makes compliance a byproduct of doing the work, not a separate project layered on top of it.

‍

If you want to see how this works for your institution’s specific ACH patterns, request a demo, and we’ll walk through it together.