If your bank receives ACH transactions, the June 2026 rule change puts new monitoring obligations squarely on you as the RDFI. Here’s what’s changing, why it matters, and what you can do about it.
The Buck Stops With the RDFI
As Amy Morris, Sr. Director of ACH Network Rules at NACHA, put it directly:
“The buck does stop with the RDFI. There aren’t other parties in the chain through a receiving process and the rules, and so this responsibility is set with the RDFI to have these processes and procedures reasonably intended to be able to identify these situations.”
The rule language itself is equally plain:
“Each RDFI must: (a) establish and implement risk-based processes and procedures relevant to the role the RDFI plays in connection with the receipt of credit Entries that are reasonably intended to identify credit Entries that are suspected of being unauthorized or authorized under False Pretenses, including processes and procedures for responding when credit Entries are identified as potentially unauthorized or authorized under False Pretenses; and (b) at least annually review such processes and procedures and make appropriate updates to address evolving risks.”
— NACHA Operating Rules, ACH Credit Monitoring (Phase 2, effective June 22, 2026)
No new warranties or liabilities. But the obligation is now explicit and in writing. The question is whether your current monitoring meets it.
It’s About the Originator, Not Just the Amount
Here’s where most banks get tripped up. They think their existing monitoring covers them because their core system flags large or unusual ACH transactions. It doesn’t.
Under the new rules, the standard isn’t whether a transaction amount looks unusual for a given customer. The standard is whether the bank is monitoring at the originator level, or tracking what a specific originator is sending to specific customers, and catching patterns that don’t belong.
This is a fundamentally different question, and it’s one core systems aren’t built to answer.
NACHA’s own guidance identifies the signals RDFIs should be looking for. What’s notable about each one is that none of them can be evaluated by looking at a single transaction in isolation. They all require knowing something about the originator, the account history, or both.
| Signal | What it looks like in practice | What a transaction-level system misses |
|---|---|---|
| Originator-level pattern recognition | Credits from this originator to this account typically run $1,200–$1,800. This one is $1,195 — but the originator has not sent to this customer consistently across recent months. | Static dollar thresholds don’t account for the history between a specific originator and a specific customer. Detecting the anomaly requires tracking that relationship over time. |
| Name matching | The credit arrives labeled for “Apex Logistics LLC” but the receiving account belongs to an individual. | Name matching is only useful if you have something to match against. Without originator-level context, the mismatch is invisible. |
| First-time originator detection | A credit posts to a customer’s account from an originator the bank has never processed before. | A transaction-level system treats a credit from an unknown originator the same as a recurring payroll deposit from a long-established sender. |
These are three of the detection vectors the rule is designed to address. Every one of them requires originator-level context to evaluate, not just a transaction-level threshold.
What Compliant Monitoring Looks Like: Pass/Fail Scoring
Meeting the June 2026 standard doesn’t have to be complicated. The right system scores every flagged ACH transaction against a set of risk attributes and gives your team a simple Pass or Fail for each one. Your team works the Fails first, same day, before the return window closes. No interpretation required. You get a clear daily queue.
The risk attributes fall into three categories. The first is originator behavior: what this originator has done before with this account, and whether the current transaction fits that history. The second is transaction context: how this transaction compares to what’s normal for the receiving customer — not just the dollar amount, but the relationship between sender and receiver. The third is institutional signals: information about where the transaction is coming from that your core system doesn’t surface on its own.
What makes the framework useful in practice isn’t complexity, it’s consistency. The same criteria apply to every flagged transaction, every day, regardless of who’s reviewing it. That’s what “reasonably intended” looks like when an examiner asks.
We put together a one-page RDFI Compliance Checklist, here. It has eight elements present in a compliant program.