What Nacha’s 2026 fraud monitoring rules mean for software platforms

If your software lets businesses collect or send money by ACH, Nacha’s 2026 fraud monitoring rules almost certainly reach your platform and the customers who use it. Each rule below is stated as of October 2026.

What changed in 2026

Nacha brought in its fraud monitoring rules in two phases, both in 2026. As of October 2026, both phases are in effect, so treat these ACH fraud monitoring requirements as current, not upcoming.

Nacha’s stated goals are to reduce successful fraud, including business email compromise, vendor and payroll impersonation and account takeover, and to improve the recovery of funds.

The two phases cover ODFIs (Originating Depository Financial Institutions, the originating banks), non-consumer Originators, Third-Party Service Providers (TPSPs), Third-Party Senders (TPSs) and RDFIs (Receiving Depository Financial Institutions, the receiving banks). Phase 1 set volume thresholds for every party except ODFIs. Phase 2 removed them.

June 19, 2026 was the Juneteenth federal holiday, so in practice Phase 2 applied from Monday, June 22, 2026.

In practice, every software platform that acts as a TPS or TPSP, and every business Originator on it, now needs a fraud monitoring program.

Who the rules cover

After Phase 2, the rules reach these parties in the ACH Network:

• ODFIs, the banks that originate ACH entries for their customers.
• Non-consumer Originators, the businesses and organizations that start ACH payments, such as a company that collects invoices by ACH debit.
• Third-Party Service Providers, any party that performs ACH processing functions for another party.
• Third-Party Senders, the TPSPs that transmit entries for Originators with no direct agreement with the ODFI.
• RDFIs, the banks that receive ACH entries for their account holders.

Consumer Originators are not covered.

Which of these roles your platform plays depends on whose name is on the bank agreement, as explained under which role your platform plays. For short definitions of TPS, TPSP and the other roles, see our glossary of ACH and platform payment terms.

What the Nacha fraud monitoring rules require

Each covered party must have risk-based processes and procedures reasonably intended to identify entries suspected of being unauthorized or authorized under False Pretenses. It must review those processes and procedures at least once a year.

Two kinds of entries are in scope. Unauthorized entries are payments the account holder never agreed to. Entries authorized under False Pretenses are payments the payer did agree to, but only because someone lied about who they are, who they act for or who owns the account being paid.

Nacha defines False Pretenses as inducing a payment by misrepresenting one’s own identity, one’s association with or authority to act for another person, or who owns the account to be credited. A familiar case is an email that impersonates a supplier and asks for its invoices to be paid to a new bank account. Another is a message that poses as an employee and redirects their pay.

The obligations apply to every Standard Entry Class (SEC) code, not only WEB (internet-initiated) entries. They add to older rules rather than replacing them. For example, since March 19, 2021, WEB debits have required account validation on the first use of an account number, or a changed one, as part of a commercially reasonable fraudulent transaction detection system.

The wording leaves the design to you. The rules ask for processes reasonably intended to find these entries, scaled to the risk in your own ACH activity: who you originate for, what kinds of payments they send and where fraud has shown up before.

What the rules do not require

Two readings of the rules come up often, and both are wrong.

It is not per-transaction screening

The rules do not require you to screen every payment one by one, and they do not require monitoring before entries are processed.

That does not rule out checks before a payment goes out. A risk-based program can put extra checks on higher-risk moments, such as the first payment to a new or changed bank account. The difference is that you decide where those checks belong, based on your risk, instead of applying one test to every entry.

It is not only for large originators

Some summaries written before Phase 2 describe the rules as covering only parties with millions of entries a year. That was true only of Phase 1, and only for Originators, TPSPs, TPSs and RDFIs; every ODFI was covered from the start. Since Phase 2, volume no longer decides whether a non-consumer Originator, TPSP or TPS is covered.

Third-Party Senders: which role your platform plays

A platform that holds the ODFI agreement and sends entries for its customers is a Third-Party Sender. If its customers hold the bank agreement, it is a Third-Party Service Provider. If it sends through another Third-Party Sender, it is a Nested Third-Party Sender. Which applies depends on whose name is on the bank agreement.

In each case, the businesses that collect or send money through your software are the Originators.

A Third-Party Sender also carries its own audit, risk-assessment and data-security duties. They include an annual Rules Compliance Audit, a risk assessment of its ACH activities with a risk program based on it, and Origination Agreements with the ODFI and with the parties it sends for. ODFIs must register their Third-Party Senders with Nacha.

Since September 30, 2022, each Third-Party Sender must do its own ACH risk assessment. It cannot rely on another party’s assessment or Rules Compliance Audit. Nested Third-Party Sender relationships must be disclosed: origination agreements must cover them, and Nested TPSs are registered through the ODFI in Nacha’s Risk Management Portal.

Nacha’s debit return limits apply to Originators and Third-Party Senders alike:

• Unauthorized returns, 0.5% of debit entries. This is a threshold, and going over it can lead to Nacha enforcement.
• Administrative returns, 3.0% of debit entries. Going over triggers a preliminary inquiry into origination practices, not an automatic penalty.
• All debit returns, 15.0% of debit entries. Going over also triggers a preliminary inquiry.

Watch these rates for each business you originate for, not only across your platform. A healthy platform-wide rate can hide individual customers whose rates run much higher.

If you are still deciding how payments fit into your product, our overview of embedded payments for software platforms explains the common models and where your ACH role comes in.

The receiving side: R17 and QUESTIONABLE

For RDFIs, the monitoring duty is focused on credits: incoming credit entries suspected of being unauthorized or authorized under False Pretenses.

RDFIs also have a return option for suspected fraud. Since October 1, 2024, they may use return code R17 with the descriptor QUESTIONABLE to return any entry they believe is fraudulent. Since January 1, 2026, they may do so before or after the entry posts. Using R17 this way is optional for the RDFI, and it follows the two-banking-day return window.

For your platform, an R17 QUESTIONABLE return means the receiving bank believed that payment was fraudulent. Review the customer and the payment before any new payment to that account. Our guide to ACH return codes and what to do after each one covers R17 alongside the other codes.

Other Nacha rule changes in 2026

Three other 2026 changes affect the payments your software creates.

PAYROLL. Since March 20, 2026, PPD (prearranged payment and deposit) credits to consumer accounts for wages, salaries and similar pay must use the Company Entry Description PAYROLL. It covers wages, salaries, tips, bonuses and commissions, but not pensions, expense reimbursements, tax refunds or insurance payouts. RDFIs may use the PAYROLL description, for example when deciding on early funds availability, but they are not required to act on it.

PURCHASE. Since March 20, 2026, consumer WEB debits for online purchases of tangible goods must use the Company Entry Description PURCHASE. It covers debits a consumer authorizes online for hard goods, including recurring purchases of goods first authorized online. It does not cover services, licenses or recurring bill payments.

If your software sets the Company Entry Description for your customers’ payments, check it against each payment type. For the consent your customers need before they debit an account, see our guide to ACH authorization requirements.

Funds availability. Since September 18, 2026, RDFIs must make non-Same Day ACH credits available by 9:00 a.m. RDFI local time on the Settlement Date, whenever the file arrives. The earlier 5:00 p.m. receipt condition is gone. A companion exception gives some RDFIs, such as those in Guam and the Northern Mariana Islands, alternate deadlines rather than a full exemption.

This is a rule for receiving banks about the credits they receive. A payment provider’s own funding schedule is a separate matter.

Data security for stored account numbers

An older Nacha rule covers stored account numbers. Large non-consumer Originators, TPSPs and TPSs must make stored bank account numbers unreadable. Since June 30, 2022, that has applied to any party with more than 2 million ACH entries a year.

A party that crosses 2 million ACH entries in a year must comply by June 30 of the following year. Encryption, truncation, tokenization and destruction are all acceptable ways to make the numbers unreadable, and so is letting the bank store or tokenize them. If your software stores bank account numbers so payers can pay again later, know which method applies and who is responsible for it.

What comes next: Banking Day and later rules

Several approved rules take effect after October 2026, and one significant change is still only a proposal.

The Banking Day proposal

Since January 1, 2026, a Banking Day has meant a day the ACH Operators are open, whether or not an individual bank is open. After a Request for Information in May 2026, Nacha issued a Request for Comment, with comments due October 23, 2026.

It proposes to redefine a Banking Day as any calendar day other than a Saturday, Sunday or US federal banking holiday, with a proposed effective date of June 18, 2027. The proposal says settlement would still occur when an ODFI or RDFI is closed. As of October 2026, it is proposed, not adopted.

Approved rules with later dates

The key-dates table below lists the approved rules that take effect from January 1, 2027 to March 17, 2028. They cover accepted characters, international ACH (IAT) entries, the Same Day ACH dollar limit and a new return code for sanctions. Check Nacha’s new rules page for the current status before you plan around any of these dates.

Key Nacha rule dates, 2022 to 2028

The dates below cover the rules in this guide, plus the 2022 Third-Party Sender rule that still shapes a platform’s duties.

What a risk-based approach can include

The items below are examples of what a platform and its business customers can build into a program. Apart from the annual review, they are not Nacha mandates, and none of them means screening every payment.

• Know the businesses you originate for, by verifying who they are (know your business, or KYB), screening them against sanctions lists and learning what they sell and how they collect payments.
• Watch for changed payee bank details, such as a vendor or employee whose bank account changes by email, and for other False Pretenses signals, such as pressure to pay a new account quickly or a first payment to an account never used before. Confirm changes through a contact you already trust.
• Monitor return rates for each customer, against Nacha’s limits and not only in total, and act on fraud returns such as R17 QUESTIONABLE.
• Write the procedures down, including who reviews which signals, what triggers a hold or a call to the customer, and how issues reach the originating bank.
• Review the procedures at least once a year, as the rules require, and record what you changed and why.

This guide is general information, not legal or compliance advice, as our website terms and conditions explain. For decisions about your own program, talk to your originating bank and your legal counsel.

Sources

1. Nacha, Fraud monitoring (Phase 1)
2. Nacha, Fraud monitoring (Phase 2)
3. Nacha, New rules
4. Nacha, Third parties in the ACH Network
5. Nacha, Third-Party Sender roles and responsibilities
6. Nacha, Third-Party Sender registration
7. Nacha, Company Entry Descriptions
8. Nacha, Risk management topics (October 1, 2024)
9. Nacha, Funds availability requirements for non-Same Day credit entries
10. Nacha, Supplementing data security requirements
11. Nacha, Request for Comment: definition of the term Banking Day
12. Nacha, Three new Nacha rules approved
13. Nacha, Registration of IAT contacts in the ACH Contact Registry
14. Nacha, ACH Network risk and enforcement topics