NACHA 2026 Fraud Rule Changes: A Readiness Guide

Last updated: October 2026

The NACHA 2026 fraud rules are in force. Phase 1 took effect on 20 March 2026 and Phase 2 on 19 June 2026, so every ODFI, non-Consumer Originator, Third-Party Service Provider, Third-Party Sender and RDFI in the ACH Network now has a fraud-monitoring obligation. The rules say what each participant must be able to do and leave the method to the participant. This guide turns that into a working program, role by role: the control, the record that shows it ran, the person who owns it and the annual review.

TL;DR

• Both phases are in force. Phase 1 (20 March 2026) covered every ODFI, plus non-Consumer Originators, Third-Party Service Providers and Third-Party Senders that originated 6 million or more ACH entries in 2023, and RDFIs that received 10 million or more in 2023. Phase 2 (19 June 2026, in practice 22 June) removed the thresholds.

• The obligation is risk-based and depends on your role: processes reasonably intended to identify entries that are unauthorized or authorized under False Pretenses, reviewed at least annually.

• False Pretenses is not new in 2026. The definition and the R17 return changes took effect on 1 October 2024.

• Readiness comes down to four things for each role: a control, a record that it ran, a named owner and a dated annual review.

• A common gap is ownership. Fraud, operations, treasury management and BSA each hold a piece, and often nobody holds the whole.

What do the 2026 NACHA fraud rules require?

The 2026 NACHA fraud rules require each ODFI, non-Consumer Originator, Third-Party Service Provider and Third-Party Sender to run risk-based processes and procedures, suited to its role, that are reasonably intended to identify ACH entries that are unauthorized or authorized under False Pretenses. RDFIs carry the same obligation for the credits they receive. Every party must review those processes at least annually and update them as risks change.

For the originating side, Nacha's text says each party must "establish and implement risk-based processes and procedures, relevant to the role it plays ... reasonably intended to identify Entries that are suspected of being unauthorized or authorized under False Pretenses". The words "relevant to the role it plays" are why this guide is organized by role. An ODFI, an Originator and an RDFI see different parts of the same payment, so each needs its own controls.

The rules set the outcome and leave the method open. That gives each institution room to fit monitoring to its own risk, and it also means each institution has to show its reasoning. For the full list of what changed in the 2026 package and when, see what changed in the 2026 Nacha rules. This guide covers how to run the controls.

Who is covered, and when each obligation began

Phase 1 of the fraud-monitoring rule took effect on 20 March 2026. It applied to every ODFI regardless of volume, to non-Consumer Originators, Third-Party Service Providers (TPSPs) and Third-Party Senders (TPSs) with annual ACH origination volume of 6 million or more in 2023, and, for credit monitoring, to RDFIs with annual ACH receipt volume of 10 million or more in 2023. Phase 2 took effect on 19 June 2026 and removed the volume thresholds for everyone else.

The 6 million threshold never applied to ODFIs. Every ODFI has been covered since 20 March 2026.

Because 19 June 2026 was a federal holiday, Nacha gave Monday, 22 June 2026 as the practical effective date for Phase 2. Both phases are now in force, so the open question for most institutions is whether the program works, not when it has to start.

Scope still confuses some participants. A director of treasury and compliance at a payments company that does not let its clients push credits said: "I don't really know how it applies to us, right?" The rule's first prong is entries suspected of being unauthorized, and Nacha's text for originating parties refers to Entries in general, not only to credits. A party that originates only debits still plays a role in the authorization or transmission of entries.

Third-party senders also answer to the bank that sponsors them. A compliance lead at a fintech described having to show its sponsor bank a credible plan, and was blunt about what that meant: "you better have an executed contract not just a pipe dream". The sponsor bank can end the relationship, so the third-party sender's readiness is the ODFI's problem too.

Two related changes sit alongside the fraud-monitoring rule. The definition of False Pretenses, and the changes to the R17 return reason code that go with it, took effect on 1 October 2024. Since 20 March 2026, Originators must use the Company Entry Description "PAYROLL" for PPD credits that pay wages and "PURCHASE" for consumer e-commerce purchase debits.

Readiness by role: controls, evidence and owner

Readiness under the 2026 NACHA fraud rules means four things for each role an institution plays: what it watches, the control that does the watching, the record that shows the control ran, and the person who owns it. Many institutions play more than one role. A bank that originates for business clients and receives credits for consumers is both an ODFI and an RDFI, and needs both rows.

Each row should match a written procedure. If a row has no named owner or produces no record, that is the gap to close first.

Originating side: watch what changed, not only how much

Amount thresholds catch unusual amounts, and False Pretenses fraud often keeps the amount normal. A head of treasury management product at a bank described an originator who fell for a business email compromise and changed where his janitorial payments went: "he changed, the payment destination but not the amount, and it didn't trigger the rule." The payee was long established, so nothing looked unusual except the account the money went to.

That is why the originating-side control should treat a change to a payee's account details as an event to verify, whatever the amount. The same executive pointed to a second risk on the originating side: vetting an Originator does not cover a rogue employee inside that Originator's business. ODFI monitoring has to cover the entries, not only the clients who send them.

Receiving side: monitor the credits that arrive

RDFIs are covered for the credits they receive. A director of deposit and branch operations at a bank put monitoring of incoming ACH on its list of vendor questions because the bank had to be able to monitor incoming entries for fraud. A loss prevention manager at a bank described the starting checks: make sure the name on an incoming credit matches the account, and watch large dollar amounts.

Nacha's rule is risk-based for RDFIs too. It does not require an RDFI to monitor credits before posting them. What it requires is a process that is reasonably intended to identify suspect credits, plus a way to handle the ones it finds.

Third-party senders: two sets of expectations

A TPS or TPSP has its own obligation for the role it plays. It also has to satisfy its ODFI, which answers for the entries it sends into the ACH Network. In practice that means a TPS should keep its client reviews and alert records in a form it can hand to its sponsor bank on request.

One program, several clocks

Payment rails do not run on the same schedule. A fraud manager at a credit union described ACH and checks screened in batches several times a day, wires and online banking monitored in real time, and debits reviewed in an end-of-day batch. An ACH control sits inside that wider picture, and a fraud score that treats each rail on its own can miss the same customer moving money across two of them. For how to test that, see our guide to evaluating fraud scoring across card, ACH and wire.

What False Pretenses monitoring looks for

False Pretenses is the fraud pattern the rule names alongside unauthorized entries. Nacha defines it as "the inducement of a payment by a Person misrepresenting (a) that Person's identity, (b) that Person's association with or authority to act on behalf of another Person, or (c) the ownership of an account to be credited." The definition took effect on 1 October 2024, together with changes to the R17 return reason code.

In practice, False Pretenses covers business email compromise, vendor impersonation, payroll impersonation and false claims about who owns the account being credited. Business email compromise alone accounted for $3.05 billion in losses reported to the FBI's Internet Crime Complaint Center in 2025. In each of these cases a real customer authorizes the payment, so controls built to catch stolen credentials often miss it.

The signals differ by side of the payment:

• Originating side: a request to change an established payee's account details, especially one that arrives by email; a payroll change requested shortly before a pay run; a payment to a beneficiary account the Originator has never paid before.

• Receiving side: an incoming credit whose name does not match the account holder; a newly opened account receiving large credits; credits from several unrelated originators arriving at one account.

The definition has limits. A scam in which nobody misrepresents their identity, their authority or who owns the receiving account, such as a fake-goods, investment or romance scam, is outside it. Detecting those scams is covered in our guide to authorized push payment fraud.

On the receiving side, the account collecting the money is often a mule account. For how these accounts are found, see our guide to detecting mule accounts.

Who owns it: fraud, compliance, operations and treasury

Ownership is where many programs stall. The rule touches ACH operations, treasury management, fraud and BSA, and each of those teams can reasonably think another one owns it.

A director of deposit and branch operations at a bank described how it worked there: "We have a fraud committee, but no one specifically, that manages fraud. Each department does certain things with fraud." At that bank, ACH was not yet being watched for fraud at all. A BSA director at a bank said the Nacha work was managed by the operations team, and that BSA was looking at it only because of its compliance overlap.

The fix is to name one accountable owner and list the contributors:

• Accountable owner: one person who signs off the procedures and the annual review, often the head of ACH or payments operations, or the head of fraud.

• Contributors: fraud (detection logic and alert handling), operations (entry handling, returns and holds), treasury management (Originator onboarding and client communication) and BSA (overlap with suspicious activity monitoring).

• Reviewer: risk management or internal audit, who test that the program runs as written.

The next decision is whether to run this as its own program or fold it into the wider fraud and risk plan. A head of treasury management product at a bank framed the question: "can we work this into the bank's overall plan and just be a small part of it or do we need to focus on a dedicated solution?" Either answer works if the ACH controls still have a named owner and their own records.

Staffing shapes the answer too. The director of deposit and branch operations quoted above said the bank was not looking to add staff for ACH and wanted to avoid reviewing entries by hand. A control that depends on someone reading every alert by hand is hard to sustain as volumes grow.

The evidence an examiner or auditor will ask for

A risk-based rule gives the institution room to choose its controls, and it puts the burden on the institution to defend them. A head of fraud and resilience at a bank described the non-prescriptive approach as welcome: "Which is great until you have to talk to our internal auditors and our risk managers." The evidence below is what lets that conversation go well.

1. A risk assessment that names each role the institution plays in the ACH Network, the fraud risks in each role and why the chosen controls fit them.

2. Written procedures for each role: what is monitored, how alerts are raised, who reviews them and what happens to a flagged entry.

3. Alert and disposition records showing that monitoring ran and that each alert was resolved, with the reason.

4. Records of action on flagged entries: holds, returns, recalls and contact with the other financial institution.

5. The annual review, dated, with what was reviewed, what changed and why. Nacha requires a review at least annually, with updates to address evolving risks.

6. Training records for the people who run the controls.

Many teams built this as they went. The director of deposit and branch operations quoted above said the bank had an ACH risk assessment and would update its policies and procedures, but was not reviewing originators for fraud. A project manager at the same bank said the team was still defining requirements and learning them as it went.

Gaps that show up in practice

• Amount-only rules. A changed destination at a normal amount passes straight through.

• A risk assessment that stops at ACH volumes. It covers the payments and never reviews the Originators who send them.

• No single owner. A committee meets, but nobody signs off the procedures or the annual review.

• An undated annual review. If there is no record of what changed and why, the review is hard to show.

• One side of the payment only. An institution that is both an ODFI and an RDFI monitors what it sends and not what it receives, or the reverse.

Where Oscilar fits

Oscilar is a Nacha Preferred Partner for Account Validation, Fraud Monitoring, and Risk and Fraud Prevention. Oscilar's approach is a unified platform: real-time data fabric, device and behavior intelligence, rules, and case management in one stack, with agents native to it. That puts the monitoring and the case record for each alert in the same system.

For a step-by-step version of this work, from planning through operating the controls, read the 2026 ACH risk operations playbook.

Frequently asked questions

Do the NACHA fraud monitoring rules require RDFIs to monitor credits before posting?

No. The rule requires RDFIs to run risk-based processes reasonably intended to identify incoming credits that are unauthorized or authorized under False Pretenses, and to handle the ones they find. It does not require that monitoring to happen before a credit posts.

How often must a NACHA fraud monitoring program be reviewed?

At least once a year. Every covered party must review its fraud-monitoring processes and procedures at least annually and update them to address evolving risks. Keep a dated record of each review, what it covered and what changed.

Does the rule cover debit entries?

For ODFIs, Originators and third-party senders, Nacha's text refers to Entries suspected of being unauthorized or authorized under False Pretenses, not only to credits. An unauthorized debit falls under the first of those two prongs. The RDFI obligation is the one framed around the credits an RDFI receives.

Is False Pretenses new in 2026?

No. Nacha's definition of False Pretenses, and the related changes to the R17 return reason code, took effect on 1 October 2024. What 2026 added is the requirement to monitor for entries authorized under False Pretenses, in two phases on 20 March and 19 June 2026.