Phase 1 of Nacha's Risk Management Rules took effect March 20, 2026. Phase 2 followed on June 19, 2026. Neither asked finance teams to buy anything specific. Both asked every non-consumer party in the ACH network to run risk-based processes that keep working after the deadline passes, not just on the day an auditor checks the box.
That's a harder thing to comply with than a technology purchase, and it's the part most finance teams are still underestimating.
Why this matters now
On a recent webinar with Nacha, Eftsure's Chief Product Officer Ramesh Menon and Amy Morris, Nacha's Senior Director of ACH network rules, walked through what's changed since Phase 1 landed. It's a follow-up to Eftsure's earlier briefing on these rules, recorded before Phase 1 took effect. This time, both deadlines are behind us, and the picture has sharpened.
The FBI's Internet Crime Complaint Center logged 24,768 business email compromise complaints in 2025, a rise of roughly 16% on the year before, with reported losses climbing past US$3 billion. Nacha built these rules because that growth curve kept climbing after the network's risk management focus had spent decades concentrated on debit-side fraud. Morris put the network's own exposure in perspective on the webinar: ACH processed 9.3 billion payments in the second quarter of 2026 alone, with same-day ACH volume growing between 20% and 30%. More volume moving faster means more surface area for exactly the kind of patient, well-researched attack Menon describes below.
Menon put it plainly on the webinar:
AI has not really created a new category of attack. What it's done is remove the cost for the fraudster. It used to be that a highly tailored attack was very expensive, but we only saw a few of them. Now that highly precise, tailored version is close to free.
Ramesh Menon, Chief Product Officer, Eftsure
That precision means attackers can afford to study a target's vendor relationships, payment cycles and approval hierarchy before making contact, and to spread that contact across weeks or months rather than compressing it into one urgent request. The Association for Financial Professionals' 2025 Payments Fraud and Control Survey shows the same shift in the data: classic executive impersonation dropped 8 percentage points to 49% of respondents, while vendor impersonation climbed to 60%. Most AP controls were built to catch a single suspicious transaction, not a campaign that unfolds patiently over months. That mismatch, patient attacker against point-in-time control, is the actual subject of these rules, not any specific technology.
The problem in practice
Nacha's rules require processes that catch two things: entries that are unauthorized, and entries authorized under false pretenses, meaning one party pretends to be, or represent, an organization it is not, in order to trick another party into approving a payment. Morris describes the second category plainly: the payment is real, the invoice is real, the approval might genuinely come from someone with authority to give it. The only thing wrong is who ends up on the receiving end.
Four structural gaps explain why that keeps happening even where controls exist on paper. Attackers now work across months, not minutes, so a contact change in April and a bank detail change in June can look unrelated to a system built to flag single transactions, even though they're the same attack. The vendor master record is both the highest-value target and one of the least governed datasets most businesses hold, split across procurement, AP and IT with no single team owning the risk in between. Migrating a known vendor from check to ACH gets mistakenly treated as lower risk because the vendor is already familiar, when the switch itself is exactly the kind of change fraudsters target. And callbacks, the control most finance teams already rely on, fail constantly for a reason Menon named directly:
Callbacks have to be done very carefully. A lot of people are susceptible to calling the number that's taken from the same document or email that requested the change in the first place.
Ramesh Menon, Chief Product Officer, Eftsure
The check-to-ACH problem is bigger than most finance teams treat it. Menon described organizations that have moved 60% of vendors onto ACH and are now working through the remaining 40%, a project with hundreds or thousands of payees to onboard, verify and reverify against a deadline. A control built to handle a handful of changes a month suddenly has to absorb a year's worth of change events in a single migration window, and that's exactly the pressure under which segregation of duties and other basic controls tend to collapse.
None of these are technology gaps. They're gaps in when and how often a business re-checks something it already believes it knows.
What good looks like
The rules don't prescribe a specific technology or a fixed checklist. What they require is a risk assessment that stays current against actual fraud patterns rather than one set at onboarding and left alone. Morris framed it this way on the webinar:
This isn't just a new implementation, it's an ongoing way of life.
Amy Morris, Senior Director, ACH Network Rules, Nacha
An account can be correct on the day it's verified and wrong six weeks later, so verification has to repeat at every change event, not just once at the start.
In practice that means two changes to how most AP teams currently operate. Check-to-ACH migration needs the same verification rigor as onboarding a new payee, not less, because it's a change event whether or not the vendor feels familiar. And callback discipline needs to be enforced as a rule, not a habit: done outside the channel the request arrived on, using a number pulled from a source the business already trusts. Menon called this the highest-yield control available to a finance team right now, precisely because it's cheap to fix and still gets skipped under time pressure. Nacha's own Credit-Push Fraud Monitoring Resource Center has checklists built specifically for standing this up, worth a look before drafting internal policy from scratch.
Build the trigger list before the next change shows up, not after
The single most effective move available to a finance team right now isn't a one-time compliance project. It's deciding, in advance, which internal events should force a re-verification: a vendor detail change, a new payment channel, a check-to-ACH migration, a new product line, a new customer segment with a different risk profile. Write that list into policy now, because the point of a risk-based rule is that it only works if the business already knows what it's watching for before the next change arrives, not after. Menon closed the webinar on the same point:
Fraud lives in the gaps.
Ramesh Menon, Chief Product Officer, Eftsure
The next attack won't announce itself as a compliance test. It'll look like a routine update to a vendor record. Eftsure, a Nacha Preferred Partner for account validation, fraud monitoring and risk and fraud prevention, builds continuous verification for exactly that moment, checking payee identity and bank account ownership again at every change event instead of once at onboarding. Book a walkthrough if your team is building that trigger list now.
