Sardine[CON] SF/2026

Register now

Phase 2 of Nacha's fraud monitoring rules is here: What community financial institutions need to know

Hailey Windham
Hailey Windham
bg-image
bg-image
Sardine.AI article titled "Nacha fraud monitoring phase 2: What's changing for community FIs" next to a geometric 3D cube illustration.
SUBSCRIBE
Share

Back in March, we published a deep dive on Nacha's new fraud monitoring rules and what they meant for community banks and credit unions. We covered the difference between ODFI and RDFI responsibilities, what "reasonable monitoring" looks like in practice, and why these rules are less about buying technology and more about being intentional and prepared.

If you missed it, I recommend starting there first.

At the time, many community institutions may have read that article and thought, "This doesn't apply to us just yet."

Well, as of June 22, 2026 (the practical effective date due to the Juneteenth holiday), that changes.

Phase 2 of Nacha's Risk Management Rule amendments extends fraud monitoring requirements to the remaining non-consumer Originators, Third-Party Service Providers (TPSPs), Third-Party Senders (TPSs), and RDFIs that were not captured under Phase 1.

In other words: if you weren't in scope before, there's a good chance you are now.

That doesn’t mean that you need to start panicking. Nacha still isn't asking community banks and credit unions to become something they're not. The focus remains the same: implement risk-based processes and procedures reasonably intended to identify fraud, document your approach, and review it regularly.

This blog builds on our earlier discussion and focuses on what Phase 2 means now that these expectations apply across the broader ACH ecosystem.

What's different about phase 2?

When Nacha proposed these changes in 2023, many institutions worried that new fraud monitoring requirements would translate into expensive systems and one-size-fits-all expectations.

The final rule took a different approach. Several important changes were made between the original proposal and the final rule:

  • The term "commercially reasonable" was removed.
  • "Detection systems" became "processes and procedures."
  • Monitoring only applies "to the extent relevant to the role the entity plays."
  • Monitoring is not required pre-processing.
  • Institutions must review their processes and procedures at least annually.

Those changes matter. Nacha intentionally created flexibility for institutions to implement controls that fit their size, complexity, and risk profile. This isn't about having the most sophisticated technology in the market. It's about having a thoughtful approach that is reasonably intended to identify fraud.

Translation: This rule is less about buying a system and more about being able to explain your process.

Fraud monitoring: Now for everyone

Phase 2 extends fraud monitoring requirements to all remaining non-consumer Originators, Third-Party Service Providers (TPSPs), and Third-Party Senders (TPSs) that were not captured under Phase 1.

The expectation is straightforward:

Establish and implement risk-based processes and procedures reasonably intended to identify ACH entries initiated due to fraud.

Notice what the rule doesn't say.

  • It doesn't require real-time monitoring.
  • It doesn't require pre-processing review.
  • And it doesn't prescribe a specific technology or vendor.

Instead, Nacha recognizes that institutions manage fraud in different ways and allows for layered controls that may include upstream due diligence and third-party monitoring.

Layered controls are allowed

An ODFI's fraud monitoring program may rely on multiple layers of controls, including:

  • Originator onboarding and due diligence
  • Processor or TPSP monitoring activities
  • Transaction metadata and risk scoring
  • Historical fraud events and alert thresholds
  • Exception reporting and periodic reviews

No single layer is expected to stand alone. The expectation is that layered controls work together to form a reasonable, risk-based approach and that reliance on those controls is understood and documented.

This is especially important for institutions working with third-party senders and processors.

Nacha explicitly allows ODFIs to consider steps that other participants in the origination process are taking to monitor for fraud when designing their own processes and procedures. Institutions are not expected to duplicate controls that already exist elsewhere in the payment flow.

However, relying on those controls requires understanding them. Blind trust without documentation is not the same as risk-based oversight.

Layered doesn't always mean more

When we talk about layered controls, it's easy to assume that means adding more tools, more alerts, and more vendors. But layered doesn't always mean more.

We can't continue piling technology on top of technology when an existing solution provider isn't delivering what the institution needs. Sometimes the answer it taking a hard look at the layers you already have, not just adding more.

If the vendor you onboarded 5, 10, or even 20 years ago isn't keeping pace with today's fraud landscape, it's okay to reevaluate that relationship. The goal isn't to collect technology; it's to build an intentional, effective program that works for your institution.

Complacency won't work in today's environment. Fraud evolves, and our controls (and vendor partnerships) must evolve with it.

RDFI ACH credit monitoring: Now applies to everyone

March's Phase 1 requirements applied only to RDFIs with annual ACH receipt volumes greater than 10 million entries in 2023.

As of June 22, those requirements now apply to all remaining RDFIs.

If you're an RDFI, one of the most important clarifications remains unchanged: The rule does not require pre-posting monitoring of ACH credit entries.

Historically, RDFIs were not expected to actively monitor ACH credits before posting. If a credit did not hit an exceptions report and was not force-posted or altered, liability generally rested with the ODFI.

That principle hasn't changed.

What has changed is visibility.

RDFIs have a unique view into incoming transactions, account characteristics, and historical behavior that may reveal fraud after funds have posted.

A risk-based approach may consider factors such as:

  • Transaction velocity
  • Account age
  • Average balances
  • SEC code anomalies
  • Historical account behavior

If those concepts sound familiar, they should. Many institutions already perform similar monitoring today through AML, suspicious activity monitoring, or fraud operations.

This rule isn't necessarily creating a new function. In many cases, it's formalizing one that already exists. A change in mentality

I'll be honest: I actually love this rule update. I think it gives proactive fraud fighters an advantage by creating more consistent visibility into received ACH files and account activity. That visibility gives us the opportunity to identify risk earlier and potentially prevent fraud before funds disappear.

More importantly, it helps move us away from the mentality of:

"If we aren't liable, it's not our problem."

I remember during the height of PPP loan fraud in the COVID era, reviewing incoming ACH files for unusually large deposits. There were business accounts with average balances of less than $1,000 over the prior 12 months, suddenly receiving PPP deposits well into six figures.

Sure, my institution might not have been liable for those transactions. But how could I, in good conscience, ignore activity that so clearly didn't align with the account's history?

I knew our BSA team would monitor, investigate, and report suspicious activity. But reporting fraud after the fact isn't the same as preventing it.

That's what I appreciate about this rule. It doesn't ask institutions to become fortune tellers. It gives fraud fighters the ability to be more proactive; to recognize when something doesn't make sense and take appropriate action before fraudsters have the chance to move the money.

False pretenses: A new definition for a familiar problem

And speaking of “when something doesn't make sense,” one of the more notable additions to the rules is the introduction of a newly defined term:

False pretenses

"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."

This definition captures many of the fraud scenarios institutions are already seeing every day, including:

  • Business Email Compromise (BEC)
  • Vendor impersonation
  • Payroll impersonation
  • Other payee impersonation schemes

Importantly, this definition does not extend to scams involving fake or poor-quality goods and services. We wrote a guide that goes deeper into this concept here.

In many ways, Nacha is codifying what fraud professionals have known for years: fraud isn't always unauthorized access. Sometimes it's an authorized payment made under deception.

But how does an RDFI identify transactions that may have been authorized under false pretenses when they don't know the circumstances under which the payment was initiated?

According to Nacha, institutions may consider characteristics of both the entry and the receiving account, such as:

  • A Standard Entry Class (SEC) Code that doesn't align with the receiving account type (for example, a corporate CCD entry to a consumer account)
  • A high-dollar transaction that is atypical for the account
  • A series of similar credits received within a short period of time, such as multiple payroll or benefit payments
  • Any of the above occurring in a new account, dormant account, or potential mule account

If these scenarios sound familiar, they should. They're often the same indicators fraud teams have been monitoring for years.

The difference now is that Nacha has explicitly recognized these types of patterns as part of a reasonable, risk-based approach to ACH credit monitoring.

Importantly, identifying an outlier doesn't automatically mean returning the transaction.

An RDFI may choose to take advantage of the voluntary exemption from funds availability requirements for credit entries, allowing additional time to examine the transaction and account activity. Institutions may also leverage Nacha's Risk Management Portal and ACH Contact Registry to communicate with the ODFI when questions arise.

And when an RDFI determines that an entry may be unauthorized or authorized under false pretenses, the institution may return the entry using Return Reason Code R17 ("QUESTIONABLE") or, at the request of the ODFI, Return Reason Code R06.

The common thread across all of these examples is simple:

Fraud rarely announces itself with certainty. More often, it shows up as activity that simply doesn't make sense.

One of the biggest impacts may be internal communication

Buried within these rule updates is an important operational reality: Fraud rarely fits neatly into one department.

ACH monitoring increasingly sits at the intersection of:

  • Fraud
  • Operations
  • Compliance
  • Product
  • Treasury management
  • Relationship teams

The institutions best positioned for success won't necessarily be those with the most sophisticated technology.

They'll be the ones with clear ownership, repeatable processes, documented decisions, and strong communication between teams.

The real takeaway

Phase 2 doesn't fundamentally change what community banks and credit unions do. Instead, it formalizes what many institutions have already been doing and encourages others to become more intentional.

Nacha isn't asking institutions to catch every fraudulent transaction.

They're asking institutions to understand their risks, implement reasonable controls, document their approach, and review those processes regularly.

For many institutions, the building blocks already exist.

The opportunity now is to connect them.

Because when fraud happens, the question isn't whether your institution had the perfect system. It's whether you understood your risks, had a process, and knew what to do next.