ACH Fraud Monitoring: How to Build a Risk-Based Program (Nacha 2026 Implementation Guide)

The Nacha 2026 risk management rules are clear about what they require: documented, risk-based processes and procedures to identify ACH entries that are unauthorized or authorized under false pretenses, reviewed at least annually. Every Phase 2 originator — every non-consumer business that sends payroll, vendor payments, or disbursements via ACH — needs that program in place by Monday, June 22, 2026.

What the rule does not tell you is how to build it. And that is the gap most teams are sitting in right now.

Trustpair's 2026 Fraud Report makes the size of the problem hard to miss. 71% of US companies say AI-powered fraud attempts are accelerating. Only 32% of companies validate vendor bank account details continuously or in real time. 13% have no validation process at all. And 45% were unaware of the Nacha 2026 deadlines as recently as January.

The pattern is consistent across every survey: organisations have a fraud monitoring policy, but the policy is not a program. A policy is a paragraph in a compliance manual. A program is a documented assessment, a set of controls aligned to that assessment, an escalation procedure, an audit trail, and an annual review. Examiners will ask to see all five.

This guide walks you through how to build each one. If you have already read MonitorPay's earlier piece on what Nacha 2026 actually requires, this article is the implementation companion to it.

The Five Components Every Compliant Program Must Have

Nacha is technology-neutral. It does not mandate a specific tool, vendor, or threshold. But it is not flexibility-neutral. Every compliant program contains the same five components. Skip any of them and the program will not survive an examiner review.

The rest of this article is one section per component, in build order.

Component 1 — The Risk Assessment (with Sample Table)

Every compliant program starts here. The risk assessment is the document an examiner will ask for first, and it is the foundation everything else points back to. A monitoring control is only defensible if it is tied to a specific risk identified in the assessment.

A risk assessment is not a generic compliance template. It is a written analysis of your payment flows, scored on inherent risk, with the controls that mitigate each one named explicitly.

The four-step framework

Step 1 — Map every ACH payment flow. List every flow your organisation originates: payroll credits, vendor payments, refunds, disbursements, marketplace payouts, intercompany transfers, tax payments. Treat each one as a separate row. If you do not know all your flows, you cannot risk-assess them.

Step 2 — Score each flow on inherent risk. Use four factors:

• Volume — how many transactions per month
• Average transaction size — small recurring or large one-time
• Bank detail change rate — how often beneficiary banking information is updated
• Authorisation strength — how the change request is received and verified today

Score each on a low / medium / high scale. The combined score gives you the inherent risk for that flow.

Step 3 — Identify the False Pretenses entry points. For each flow, name the specific attack pattern most likely to land. Vendor email compromise on a bank detail change? Payroll redirection through HR portal? Fake new vendor onboarding? Be specific. "Payment fraud" is not a risk — it is a category.

Step 4 — Document the controls that mitigate each risk. Name the control and the owner. Generic descriptions ("we have controls") will not survive scrutiny.

Sample risk assessment table

This is what a defensible row looks like. Build one for every payment flow you originate.

This is a sample structure, not your assessment. Yours must reflect your actual flows, volumes, and controls. The point is the format: every row is a risk you can defend to an examiner.

The test: hand the document to your CFO. Could they explain in one sentence why each control mitigates each risk? If not, the assessment is not done.

Component 2 — Monitoring Controls by Payment Type

Risk-based means controls scale with risk — heavier scrutiny on higher-risk flows, lighter checks on routine low-risk activity. Nacha is explicit: a risk-based approach should not conclude that no monitoring is necessary at all. Even on lower-risk flows, some level of monitoring is required.

The four payment types below cover most of what non-consumer originators send. Each one gets a minimum control tier and a stronger control tier. Pick based on your volume and inherent risk score from Component 1.

Payroll credits

Minimum control: require multi-factor authentication on the HR portal where employees update direct deposit details. Apply a 24-hour hold and email confirmation to the prior account before any first deposit to a new account.

Stronger control: independent account ownership verification on every direct deposit change, matching the new account number against the employee's name in real time. This catches payroll redirection fraud before the payroll run, not after.

Vendor payments

Highest-risk flow for most originators. Vendor email compromise routinely defeats manual checks because the fraudster controls the supplier's mailbox.

Minimum control: out-of-band callback to a known number from your vendor master file (not from the change request itself) for every bank detail change. Dual approval above a threshold.

Stronger control: real-time account ownership verification on every new vendor and every bank detail change, regardless of amount. The verification is independent of the email channel that the fraudster has compromised. This is the control specifically designed to defeat the four False Pretenses attack patterns Nacha names.

Marketplace and platform payouts

Different risk profile because volume is higher and onboarding happens at scale. The threat is less about the existing supplier base and more about new accounts entering the system.

Minimum control: identity verification at signup; account validation before first payout; velocity thresholds that flag unusual inflow / outflow patterns.

Stronger control: registry-sourced entity verification (does this business actually exist?) plus account ownership verification (does this account belong to the entity that signed up?) at the point of onboarding. For US payouts, EIN verification adds entity-level confirmation. See MonitorPay's KYB guide for marketplaces for the full workflow.

Refunds and disbursements

Often overlooked, but a real attack vector — particularly when refunds can be redirected to a different account than the original payment.

Minimum control: refund only to the original payment account. Manual review and dual approval for any deviation.

Stronger control: account ownership verification on the refund destination if it differs from the original; threshold rules that escalate any disbursement above a defined value to treasury or CFO approval.

Component 3 — Exception Handling and Escalation

This is where most programs fail an examiner review. The monitoring catches an anomaly, and then nothing is documented about what happens next. "Someone in finance deals with it" is not a procedure.

A defensible exception-handling procedure has four named elements:

1. The reviewer. A named role — not a person, not "the team." If your AP Manager is on leave, who reviews? That is part of the procedure.
2. The escalation path. Level 1: AP / Payroll. Level 2: Finance Manager or Controller. Level 3: CFO and ODFI contact. Each level has a named owner and a defined trigger.
3. The decision options. What can the reviewer do? Hold the payment? Pause processing on the entire batch? Contact the supplier through an independently sourced number? Contact the ODFI? Each option must be written down.
4. The log. Every flagged transaction, decision, and outcome must be recorded — date, time, reviewer, action taken, resolution. This is your audit trail.

Sample escalation matrix

The matrix is not the policy. The policy explains what each level does, how decisions are recorded, and how the ODFI is contacted when needed. The matrix is what gets pinned next to the AP Manager's screen.

Component 4 — The Annual Review Process

Nacha is explicit on this: processes and procedures must be reviewed at least annually, with documentation. Most current articles mention the requirement and stop there. The reason it matters is that the review log is the single artifact that proves your program is current. Without it, even a strong policy looks stale.

What the annual review must contain

• Date of the review — not "annual review 2026," a specific date
• Author — named individual who conducted the review
• What changed since the prior review — new payment flows, new threats, new controls added or removed
• What was tested — evidence that the controls were exercised, not just documented
• Findings and remediation — gaps identified, what was changed in response
• Next review date — calendared, owned

Sample annual review log entry

Build the annual review into your compliance calendar. The first review can be the same document you use to certify compliance for June 22 — but every subsequent year must add a new entry. A policy with no revision history will not satisfy the rule.

Component 5 — Account Validation as the Operational Backbone

The False Pretenses attacks Nacha names — vendor email compromise, vendor bank detail change fraud, payroll redirection, fake new vendor onboarding — all succeed for the same reason. The organisation accepts bank account information without independently verifying that the account belongs to the entity claiming to own it.

Independent account validation is the control that closes that gap. It is also the control that produces the audit trail your annual review needs.

How the three validation methods compare against the False Pretenses test

For most non-consumer originators, the path forward is layered. Use account ownership verification at the two highest-risk events — vendor onboarding and bank detail change — where the False Pretenses risk is concentrated. Use lower-cost methods (pre-notes, micro-deposits) where they fit the risk profile, but do not rely on them alone for high-value flows or change requests.

The integration is operational, not strategic. Two API call points cover most of the risk:

• At point of vendor or employee onboarding — before the bank account enters the ERP
• At point of bank detail change — every time, regardless of who submits or how

Both points produce an auditable record — timestamp, query, response, matched entity. That record is what satisfies the documentation requirement Nacha will check for in 2027 and every year after.

For a deeper view on why one-time verification at onboarding is not sufficient, see MonitorPay's analysis of continuous monitoring for payment accounts.

The 60-Day Build Calendar

If you are starting from zero today, this is the path to examiner-ready by June 22. The calendar assumes one named compliance owner working with AP, payroll, treasury, and IT. Compress where you can; do not skip steps.

What Examiners Actually Look For

The difference between a program that scores Class 1 and one that triggers Class 3 is rarely the technology. It is the documentation. Examiners are not looking for the most sophisticated fraud monitoring platform on the market. They are looking for evidence that you have done four things:

1. You can show them the risk assessment. Dated, signed, specific to your flows. Not a template downloaded from the internet.
2. You can show them the controls aligned to that assessment. Each control points back to a risk in the assessment. Each control has an owner.
3. You can show them the exception log. Real flagged events from the past year. What was flagged, who reviewed, what happened next, how it resolved.
4. You can show them the annual review. Dated. Authored. With a list of changes since the prior review. With evidence that controls were tested.

The fastest way to fail is to present a polished policy document with no underlying activity. The fastest way to pass is the opposite — clear documentation of small ongoing decisions, all logged, all traceable.

Frequently Asked Questions