The Nacha Deadline That Makes B2B Payment Fraud Everyone's Problem

A June 22 rule change shifts ACH fraud responsibility directly onto the companies sending payments — and most mid-market AP teams aren't ready.

For years, the implicit assumption in B2B payments was that fraud prevention was largely the bank's job. Your organization sent the payment. Your bank watched the rails. If something went wrong, there was a protocol. That assumption is now formally incorrect.

A Nacha rule change taking effect June 22, 2026 establishes that every organization originating ACH payments — regardless of volume or company size — must have documented, risk-based processes to detect and prevent fraud before payments leave the building. This includes a new obligation to verify that a vendor's bank account actually belongs to the vendor you're paying before the ACH credit is sent. The rule also explicitly names business email compromise, vendor impersonation, and payroll diversion as fraud categories that these controls must address. Ramp

For most enterprise finance teams, that sentence lands somewhere between "we probably handle this" and "let me check with AP." The honest answer, for a significant portion of mid-market organizations, is that the controls in place are informal, manual, and not audit-ready.

The gap Nacha is targeting

The processes many teams rely on today — spreadsheets, email attachments, and ad hoc verification — are the same weak points fraudsters exploit. When a vendor submits a bank account change via email, what is the documented procedure for validating that request? When a new supplier is onboarded, what confirms their banking details belong to them and not to someone impersonating them? These are not hypothetical edge cases. They are the most common entry points for vendor fraud, and they happen in AP workflows every week. PaymentWorks

Nacha is explicit that manual two-person approval alone is no longer sufficient — organizations need automated controls that operate across their full payment volume. For finance teams running hundreds or thousands of vendor payments per month, that is a meaningful operational shift. Ramp

What "risk-based" actually means

The rule does not mandate a specific technology. It requires documented processes that are reasonably designed to catch fraud — and that those processes are reviewed and updated at least annually. Account validation, ongoing monitoring for bank account changes, and screening for suspicious activity are all components Nacha expects to see in place. Trustpair

For CFOs evaluating their exposure, the relevant question is not just whether the controls exist, but whether they scale. A finance team that manually reviews 200 vendor records can document that process. A team with 2,000 active suppliers across multiple ERPs needs something more systematic.

The supplier onboarding problem hiding in plain sight

The most common failure point is not payment execution — it's what happens before the payment. Supplier onboarding is where bank account details are collected, where verification is supposed to happen, and where the record of that verification should live. In practice, many organizations treat onboarding as an administrative function with light controls: a W-9 form, a bank detail email, and a note in the vendor master.

That posture is now a documented compliance gap. More importantly, it's a gap that bad actors have been exploiting for years. The Nacha rule change is, in one sense, just a formal acknowledgment of what mid-market finance teams already know: that the weakest link in B2B payment security is usually the moment a new vendor banking record is created or changed.

The broader question for CFOs

Missing the June 22 deadline exposes organizations to fines, operational disruptions, and fraud liability. But the more durable question is what a compliant, scalable supplier verification process actually looks like — and whether your current AP infrastructure can deliver it. National Payment

Finance teams that take this deadline seriously will find it prompts a useful broader review: which vendors are on which rails, what verification exists for each, and where the documentation gaps are. That review, done well, tends to surface both fraud risk and supplier enablement opportunities that were previously invisible.

Finexio was built for exactly this layer — verifying supplier banking details, onboarding vendors to the right digital rails, and backing that process with a $2M fraud loss guarantee that no traditional AP platform offers. The Nacha deadline is a forcing function. The underlying infrastructure question was always worth asking.

‍