Nacha 2026 ACH Fraud Rules: What “Risk-Based Monitoring” Actually Means

The ACH Network is the backbone of US electronic payments. Payroll, vendor payments, supplier disbursements, marketplace payouts, insurance claims — they all run on it. And for years, the fraud monitoring rules governing it were narrow, vague, and easy to satisfy on paper without changing anything in practice.

The old rule required Originators to use a "commercially reasonable fraudulent transaction detection system" — but only for a small subset of transactions: WEB debits (e-commerce) and micro-entries. Credit payments — the kind used for payroll, vendor payments, and B2B disbursements — had almost no active monitoring requirement.

That's exactly what fraudsters exploited. Business email compromise, vendor impersonation, and payroll redirection all work by targeting credit-push flows — payments that look authorized because the victim was tricked into approving them.

This is not a paperwork exercise. Nacha and bank examiners will treat weak or absent fraud programs as a direct rules violation — with fines, corrective action, and potential suspension of ACH origination privileges for persistent non-compliance.

The rules roll out in two phases based on transaction volume. Phase 1 is already in effect. Phase 2 applies to everyone else — and the practical deadline is Monday, June 22, 2026, not June 19 (Nacha has confirmed June 19 is a federal holiday).

The rules apply far more broadly than most compliance guides suggest. They are not limited to US banks. They apply to any non-consumer entity that originates ACH payments — regardless of where they are headquartered.

This is the most overlooked category in all existing Nacha content. If your company is headquartered outside the United States — in the UK, EU, Canada, or anywhere else — but you send ACH payments to US vendors, contractors, or employees, you are an Originator under Nacha's rules.

Payments involving a financial institution outside the US are processed as IAT (International ACH Transaction) entries, which carry additional data element requirements and are subject to OFAC screening. The broader fraud monitoring requirements still apply to the originating entity. Nacha has also confirmed that IAT contacts must be registered in the ACH Contact Registry by January 1, 2027 — a deadline that specifically affects non-US originators.

This is the most significant legal concept introduced by the 2026 rules — and the most misunderstood. Every guide defines it. Almost none translate it into the fraud attacks that actually happen to AP teams and finance departments every day.

The critical distinction: the payment was authorized. The customer or employee genuinely clicked "approve." But they were deceived into doing so. Under previous rules, these payments were almost impossible to catch because traditional fraud systems looked for unauthorized transactions. Nacha is now explicitly requiring organizations to monitor for authorized-but-deceptive payments too.

Here are the four attack types that trigger "False Pretenses" — and what your monitoring must now catch:

This is the question every compliance and finance team is asking — and the answer every existing guide avoids. "Risk-based" sounds flexible. It is. But "flexible" does not mean optional, and it does not mean a policy document that has never been tested.

Nacha does not prescribe specific tools or thresholds. You have genuine flexibility in how you implement controls — but those controls must be appropriate to your risk profile, documented, and reviewed annually. Here is what "risk-based" specifically requires:

• 1 A written risk assessment — identifying where ACH fraud risk is most likely to arise in your specific payment flows. Not a generic template. Specific to your payment types: payroll, vendor payments, disbursements, marketplace payouts. Which payment types are highest risk? Where do bank detail changes come from? What approval process exists?
• 2 Monitoring and exception-handling steps aligned to your volume and payment types. What triggers a manual review? Who reviews it? What happens when a bank account detail changes? How are new vendor accounts validated before first payment? These steps must be written, not assumed.
• 3 A defined response process — named owners, escalation path, when processing is paused, and how your ODFI is contacted if a suspicious entry is identified. "Someone in finance deals with it" is not a compliant response process.
• 4 Annual review and update — your procedures must be reviewed at least once per year, updated to reflect new fraud tactics, and the review must be dated and documented. Examiners will ask for the review log, not just the current policy.

An auditor reviewing your Nacha compliance will want to see: a dated document showing who reviewed the procedures, what changed since the prior review, evidence that your monitoring was tested, and a named responsible owner. A policy that has no date, no author, and no revision history will not pass scrutiny.

Two new standardized entry descriptions became mandatory on March 20, 2026. These apply to the Company Entry Description field in ACH batch headers and are designed to help financial institutions apply targeted fraud monitoring to specific payment types.

This is the most underreported requirement in all existing Nacha 2026 content. The fraud monitoring rules are, at their core, a mandate to verify that bank account information comes from a trusted, independent source — not from an email, a phone call, or a vendor's own submission.

Nacha's guidance is explicit: organizations must confirm bank account information using validated data sources instead of relying on unverified communications. The reason is direct — the False Pretenses attacks described earlier all succeed because organizations trust account details without verifying that the account belongs to the entity claiming to own it.

Micro-deposits and pre-notifications confirm that an account exists and is formatted correctly. They do not verify that the account belongs to the vendor or employee named in your records. That distinction is precisely what the False Pretenses requirement is designed to close.

Real-time account ownership verification — checking that account number + routing + entity name match against independent banking data — is the only method that directly satisfies both the account validation requirement and the False Pretenses monitoring requirement simultaneously. It also produces an auditable record of every check, which is what Nacha's annual review requirement demands.

Nacha enforces its rules through a structured escalation system. Most violations are resolved without fines when corrected promptly. But for the 2026 fraud monitoring rules specifically, regulators and bank examiners have made clear that "no monitoring in place" is not a correctable minor infraction — it is a direct rules violation that will trigger formal proceedings.

The financial penalties are only part of the exposure. The more immediate risk for most businesses is operational: if your ODFI determines your fraud controls are inadequate, they can restrict or suspend your ACH origination access. For any business that runs payroll or vendor payments via ACH, that is an existential operational problem — not a compliance fine.

Bank examiners are also being directed to treat weak ACH fraud programs as evidence of broader deficiencies in operational risk, consumer protection, and governance. That creates a secondary regulatory exposure beyond Nacha itself — particularly for fintechs and financial institutions operating under FRB, OCC, or FDIC supervision.

---

The steps differ depending on your role in the ACH transaction. Below is a practical action plan for each type of organization. If Phase 1 already applied to you (March 20), treat this as a gap review. If Phase 2 applies, June 22 is your hard deadline.

Your exposure is higher than a standard corporate AP team because you originate ACH on behalf of others, which makes you a TPSP or TPS. Your compliance documentation must cover your own monitoring and also demonstrate that you have frameworks in place for the originators using your platform. Nacha holds TPSPs responsible for the risk management quality of their origination programs.

Key requirements: automated account validation at point of seller/vendor onboarding, anomaly detection for velocity spikes or account changes, documented escalation procedures, and annual review. If you're a marketplace or gig platform with 1,000+ vendors, manual verification is not viable — a real-time account ownership API is the only scalable path to compliance.

Your payments travel as IAT entries and are subject to additional OFAC screening requirements. For fraud monitoring compliance, you need the same documented risk-based processes as any US originator — but you also need to ensure your account validation covers US routing number + account number + entity name matching. Verifying a US EIN alongside bank account ownership is the dual-layer control that directly satisfies what Nacha's False Pretenses rules require from international originators.