NACHA’s 2026 Fraud Rules: ACH Is Growing Up, Whether You Like It or Not

ACH has always had a reputation problem.

Not because it is broken. Actually, ACH works incredibly well for the amount of money and volume it moves. It is reliable, familiar, relatively inexpensive, and deeply embedded in payroll, vendor payments, bill pay, account funding, insurance, subscriptions, and every other corner of financial life where money needs to move without everyone paying card fees.

But ACH also has a vibe.

And that vibe is “back office.”

Cards feel like checkout. Wires feel dramatic. Real-time payments feel shiny. ACH feels like something that happens in a batch file while someone named Denise reconciles reports before lunch.

That perception is part of the problem.

Because fraud does not care that ACH feels operationally boring. Fraud goes where the money is, where controls are inconsistent, and where people are still treating payments like an admin function instead of a risk surface.

Nacha’s 2026 fraud-monitoring rules are a pretty clear signal that the ACH Network is done pretending fraud is someone else’s housekeeping issue.

ACH is growing up.

Some companies are ready for that.

A lot are not.

The Big Shift: Fraud Monitoring Is Becoming Everyone’s Problem

The headline version is simple: Nacha is expanding fraud-monitoring expectations across more of the ACH ecosystem.

The practical version is more interesting.

This is not just about banks doing bank things. The new rules reach into the broader chain of ACH activity, including ODFIs, RDFIs, non-consumer Originators, Third-Party Senders, and Third-Party Service Providers, depending on role and phase. The point is not subtle: if you are involved in sending, transmitting, receiving, or enabling ACH activity, you may not get to treat fraud monitoring as optional background noise anymore.

For platforms, payroll providers, billing systems, marketplaces, vertical SaaS companies, treasury teams, and payment operations groups, that matters.

ACH fraud is not only “someone stole credentials and originated unauthorized debits.” The modern fraud problem includes business email compromise, vendor impersonation, payroll redirection, account takeover, fake payment instructions, and all the ways a perfectly authorized person can be tricked into sending money to the wrong place.

That last part is important.

Fraud is not always a hacker in a hoodie. Sometimes it is a realistic email, a rushed approval, a vendor bank-account change, a fake executive request, or an employee payroll update that looked normal enough to pass through a weak process.

The rules are pushing the ecosystem toward a more serious standard: risk-based processes designed to identify ACH entries that may be unauthorized or authorized under false pretenses.

Translation: “We processed the file correctly” is no longer the flex people think it is.

Phase 1 and Phase 2 Are Closer Than They Look

The rule rollout happens in phases, which sounds comforting until you look at a calendar.

Phase 1 hits on March 20, 2026. It applies to all ODFIs, as well as non-consumer Originators, Third-Party Service Providers, and Third-Party Senders with annual ACH origination volume of 6 million or greater in 2023. On the receiving side, Phase 1 applies to RDFIs with annual ACH receipt volume of 10 million or greater in 2023.

Phase 2 follows on June 19, 2026, and removes the volume threshold for remaining covered non-consumer Originators, TPSPs, TPSs, and RDFIs.

In other words, this is not a “big banks only” story.

It may start with larger-volume players, but the direction of travel is obvious. The ACH Network is moving toward broader risk-based monitoring expectations, and companies that wait until the last minute are going to discover that “risk-based” still requires actual work.

A policy document is not a fraud program.

A vendor demo is not a control environment.

A spreadsheet of suspicious transactions that nobody reviews is not monitoring.

And “we’ll have operations look at it” is not a strategy. It is a calendar invite wearing a disguise.

Risk-Based Does Not Mean Vibes-Based

One of the most important parts of the rule language is the phrase “risk-based.”

That sounds flexible, and it is. But flexible does not mean optional, vague, or hand-wavy.

A risk-based approach means the organization understands its ACH activity well enough to distinguish between lower-risk and higher-risk patterns, then applies controls that make sense for the role it plays in the payment chain. It means different organizations may have different monitoring programs because they have different customers, payment types, transaction sizes, velocity patterns, account-change workflows, and exposure.

That is reasonable.

It is also harder than buying a generic fraud tool and calling it a personality trait.

A serious risk-based ACH monitoring program should be able to answer questions like:

• What types of ACH entries do we originate, transmit, receive, or support?
• Which transaction types are most exposed to impersonation, account takeover, or payment redirection?
• What does normal activity look like for our customers, merchants, vendors, or users?
• What changes should trigger review: new bank account, unusual amount, new receiver, unusual timing, odd velocity, mismatched SEC code, or a sudden volume spike?
• Who reviews alerts, what evidence do they use, and how quickly can they act?
• What happens when a transaction looks suspicious but operations is under pressure to keep money moving?
• How often do we review the monitoring program and update it as fraud changes?

This is where “risk-based” gets real.

It forces organizations to know their own payment behavior. Not theoretically. Not in a deck. Actually know it.

False Pretenses Are the Wake-Up Call

The new rules also bring focus to entries authorized under “False Pretenses,” which Nacha describes as situations where a person is induced into a payment because someone misrepresented identity, authority, association, or account ownership.

That language matters because it reflects how fraud actually works now.

A lot of modern payments fraud is not about breaking through the front door. It is about convincing someone inside the house to open it politely and maybe offer coffee.

Business email compromise is the classic example. A fraudster impersonates a vendor and asks for bank details to be updated. Or someone pretends to be an executive requesting an urgent payment. Or an employee payroll account gets changed after a fake communication. The payment may be technically authorized by someone with access, but the authorization was manipulated.

That is the nightmare zone for old-school controls.

Traditional operations teams often check whether the format is right, whether the file is submitted by an authorized user, whether the account has funds, whether the batch passes validation, and whether the process was followed.

Fraudsters love processes that only ask whether the right boxes were checked.

False pretenses force a better question:

Does this payment make sense?

That is a different standard. It requires context, history, behavior, controls around change management, and escalation when something looks off.

ACH Credit Monitoring Changes the Receiving-Side Conversation

The receiving side matters too.

RDFIs are being pulled more directly into ACH credit monitoring, with risk-based processes designed to identify credit entries suspected of being unauthorized or authorized under false pretenses. That is a meaningful change because receiving institutions often see things the originator cannot see, including account profile information, historical activity, velocity, anomalies, account characteristics, and whether incoming credit behavior makes sense for the receiver.

That does not mean every RDFI has to stop every suspicious payment before posting. The rules do not require pre-posting monitoring for every entry.

But it does mean the receiving side cannot simply shrug and say, “Funds arrived, good luck everybody.”

Incoming credits can be part of fraud. Mule accounts exist. Recently opened accounts receiving unusual credits deserve attention. SEC code mismatches, sudden velocity, abnormal balances, and receiver behavior may tell a story.

The receiving side has a role in making the network harder to exploit.

And for platforms that rely on ACH payouts, account funding, vendor settlement, or marketplace disbursements, this means more scrutiny can show up downstream. Payments that used to move quietly may now trigger questions, delays, returns, or escalation if something looks wrong.

That may frustrate users.

It may also save money.

Both things can be true.

This Is an Operations Problem, Not Just a Compliance Problem

The easiest way to get this wrong is to treat the rule change as a compliance memo.

Compliance matters, obviously. Someone needs to read the rule, interpret obligations, update policies, and make sure the organization can demonstrate what it is doing.

But ACH fraud monitoring is not going to work if it lives only in compliance.

This touches operations, product, risk, treasury, customer support, legal, engineering, vendor management, and relationship teams. The monitoring process needs actual data. Alerts need actual workflows. Suspicious activity needs actual decision-making. Customers need actual communication. Contracts may need actual updates. Systems may need actual changes.

A rule sitting in a binder does not detect fraud.

A cross-functional operating model might.

The organizations that handle this well will probably do boring things consistently. They will map ACH flows. Identify high-risk scenarios. Review vendor and payroll change procedures. Define alert thresholds. Train teams. Clarify escalation paths. Document investigations. Test whether controls work. Review the program at least annually and update it as fraud patterns change.

That is not glamorous.

Neither is explaining to leadership why the company sent money to a fraudster because nobody wanted to inconvenience a vendor-change workflow.

Software Platforms Need to Pay Attention

This rule change is especially relevant for software platforms that have quietly become payments infrastructure.

A lot of platforms do not think of themselves that way. They think they are payroll software, property management software, church management software, fitness software, field service software, insurance software, marketplace infrastructure, invoicing tools, billing platforms, or back-office automation.

Cute.

If your software initiates, transmits, supports, or manages ACH activity, the ACH risk conversation may involve you whether your homepage says “payments” or not.

Platforms should be asking:

• Are we an Originator, Third-Party Sender, Third-Party Service Provider, or acting in support of one?
• What ACH volumes did we process or transmit in 2023, and which phase applies?
• Where do ACH instructions enter the system?
• How do users update bank accounts, vendor details, payroll details, or payout instructions?
• What controls prevent account takeover or payment redirection?
• Can we detect unusual transaction size, velocity, receiver changes, or suspicious patterns?
• Who owns ACH fraud alerts: product, risk, compliance, operations, or the group chat of doom?
• Can we prove what controls were in place if a bank, partner, auditor, or customer asks?

That last question is the one that tends to separate grown-up operations from wishful thinking.

If you cannot prove the control exists, it may not exist in the way you need it to.

The Business Impact Is Bigger Than a Rule Date

The 2026 Nacha changes are not just about checking a box by March or June.

They are about the direction of ACH as a payment system.

ACH is getting pulled into the same reality as the rest of payments: faster movement, more fraud pressure, more sophisticated scams, more interconnected providers, and less patience for “not my problem” risk management.

That has business consequences.

Weak fraud monitoring can lead to losses, customer harm, operational disruption, strained banking relationships, delayed payments, returns, investigations, reputational damage, and uncomfortable questions from partners who expected more mature controls. For software platforms, the bigger danger is that payments trust starts to erode quietly. Customers do not care whether the fraud happened because of a rule gap, workflow gap, vendor gap, or human error. They care that money went somewhere it should not have gone.

Trust does not usually collapse all at once.

It leaks.

One bad payroll redirect. One vendor impersonation. One suspicious payout. One delayed return. One support ticket where nobody can explain what happened.

Then suddenly the platform that was supposed to make payments easier looks like it made payments riskier.

ACH Is Still Worth It

None of this means ACH is bad.

ACH remains one of the most important payment rails in the country. It is efficient, useful, and deeply necessary. For many businesses, it is the right rail for payroll, recurring payments, vendor disbursements, account funding, loan payments, subscriptions, tuition, dues, reimbursements, and countless other use cases where cards are too expensive or not the right fit.

But important rails need grown-up controls.

That is the real message.

The ACH Network is not saying, “Stop using ACH.” It is saying, “Stop treating fraud monitoring like optional cleanup after the file is processed.”

For companies that already understand payment risk, this is manageable. For companies that have been coasting on basic controls, it may feel like a rude awakening.

Good.

Some awakenings are overdue.

The Takeaway

Nacha’s 2026 fraud rules are not just another compliance deadline. They are a signal that ACH fraud prevention is becoming more distributed, more explicit, and more operationally serious.

The companies that respond well will not be the ones that panic-buy software in February. They will be the ones that understand their ACH flows, know their risk points, align teams, update procedures, document controls, and treat fraud monitoring as part of the payments operating model.

The ones that struggle will probably say some version of, “We thought our bank handled that.”

Maybe your bank handles part of it.

Maybe your processor handles part of it.

Maybe your vendor handles part of it.

But if your platform, company, or payments workflow is part of the ACH chain, you need to know exactly which part is yours.

ACH is growing up.

The only real question is whether your operations are growing up with it.

Want to get featured on the Cents Chat podcast? Complete our survey.