Nacha False Pretenses in ACH Fraud

Have you come across the term “False Pretenses” while reading through Nacha’s 2026 rule updates? If you have, you’re likely trying to understand what it actually means and what your organization needs to do about it.

On March 20, 2026, Nacha formally introduced False Pretenses as an official ACH fraud classification. It was a direct response to a fraud pattern that had been growing for years but had no formal name in the ACH rulebook: payments that were fully authorized, internally approved, and routed through legitimate accounts but still completely fraudulent.

Here’s a plain-language breakdown of what the Nacha False Pretenses classification covers, why it exists, and what it means for how your organization manages ACH payments.

What False Pretenses Means for ACH Fraud

False Pretenses, as Nacha defines it, is any ACH payment that is technically authorized but was induced through the misrepresentation of identity, authority, or account ownership. In other words, a real person with real approval authority signed off on the payment, but they were deceived into doing so. What makes False Pretenses fraud particularly difficult to detect is that there is often no clear technical compromise involved. There may be:

• no unauthorized system access
• no malware or malicious code
• no obvious anomaly within the payment data itself

This is what the IT industry typically calls social engineering: manipulation rather than system intrusion. And it’s a growing concern in ACH payments.

Why False Pretenses Work

alse Pretenses is specifically designed to exploit the conditions where careful, experienced people move quickly. The most effective attacks don’t rely on sophisticated technology—they rely on a powerful combination of familiarity, authority, and urgency.

• Familiarity makes the request seem routine. Attackers reference real vendors, invoices, contacts, or ongoing conversations, arriving already embedded in a trusted relationship.

• Authority discourages scrutiny. The request appears to come from someone with the standing to make it—such as a CFO or executive—making verification feel unnecessary or even inappropriate.

• Urgency compresses decision-making. A looming deadline, financial consequence, or time-sensitive situation creates pressure to act before normal approval or verification processes can occur.

What generative AI has done is make all three easier to deploy at scale, with greater fidelity, against more targets. Tools like FraudGPT, for instance, help remove the friction that used to make social engineering attempts detectable. 

What False Pretenses Look Like in Practice

False Pretense attacks tend to follow one of three patterns. Each of these patterns targets a different entry point in the payment process:

1. Vendor Impersonation

This is quite common, and it produces the highest losses. For vendor impersonation, an attacker identifies a supplier that your organization pays regularly—usually one easy security controls to bypass. This identification always begins by monitoring a compromised email account or scraping publicly available information. 

The attacker then spends time learning the relationship: how the vendor communicates, what their invoices typically look like, and when payments are usually due. Then, at a moment calculated to minimize scrutiny, they submit a banking detail change request. By the time your actual vendor follows up on the missing payment, the window to recover the funds has largely closed. 

2. Business Email Compromise

The entry point in BEC attacks is usually a real but compromised email. In fact, 85% of B2B payment fraud attacks start in email—and bypass email security. Often, how they bypass detection is that the attacker gains access to a vendor’s or employee’s legitimate account and uses it to redirect a payment mid-conversation. 

Since the email is genuinely coming from the right address, it bypasses every filter designed to catch spoofed domains, and the recipient has no technical signal to act on. The only thing that would catch it is behavioral: something about the timing or the account change that does not fit the established pattern of how that relationship works. 

For a closer look at how this plays out in practice, this breakdown of how attackers leverage compromised infrastructure shows exactly how BEC moves through legitimate channels undetected. 

3. Executive Impersonation

This third pattern targets the authority structures that organizations rely on to move money quickly when it matters. And 93% of B2B payment fraud attacks today use some form of impersonation, vendor, executive, or both.  An attacker often impersonates a senior executive through a spoofed email, a cloned voice, and increasingly through deepfake video. 

The senior executive then contacts someone in finance with an urgent, confidential payment request. The combination of seniority and urgency is specifically designed to make verification feel like insubordination. In 2024, a finance employee at Arup wired $25 million after a video call in which every participant, including the CFO, was a deepfake. 

Why This Type of Fraud Was Slipping Through Every Control

To understand why Nacha had to classify False Pretenses formally, you have to understand the specific gap it was falling through. Most payment controls were built for a different type of threat, including bad data, unauthorized access, and suspicious translation patterns. 

Interestingly, False Pretenses (the social engineering of ACH payments) passes every one of those checks, cleanly, every time:

• Bank Account Validation: This confirms a bank account exists, is active, and is registered under a name. It doesn’t ask whether the person who submitted that account update had any right to do so. A fraudster who convinces your AP team to swap a vendor’s banking details has just passed account validation without raising a single flag.
• Approval Workflows: This confirms that the right people reviewed and signed off on a payment. But they had no way to confirm that the underlying request was genuine. If your CFO’s email has been compromised or if someone is impersonating your CFO convincingly enough, approvals go through exactly as planned. 
• Email Security Tools: They scan for malicious links, spoofed domains, and known threat signatures. They will not flag a legitimate email coming from a real vendor’s email account that has been quietly compromised by an attacker. 

Nacha noticed that the deception happened in the human interactions that created the payment request. That is why False Pretenses is now a formal compliance category. 

How to Protect Against False Pretenses

To stay protected, you need your controls to ask if the payment request that produced it makes sense, given all you know about that vendor relationship. 

This means a few specific things, including:

• Banking detail change requests should never be verified using contact information included in the request itself. Verification has to go through independently stored contact information from your vendor records, not the one in the email. 
• Treating behavioral deviation as a signal to investigate. A vendor who has never changed their banking details in three years, submitting an update the week before a large payment is due, is not automatically fraudulent. However, it is a deviation from an established pattern and it deserves scrutiny before the payment moves. 
• Introducing a behavioral AI that monitors signals across email, ERP activity, vendor records, and payment workflows.  

What Nacha Now Requires Organizations to Do About False Pretenses

False Pretenses became a compliance issue because the problem was already significant enough that the regulatory framework governing ACH payments needed to formally account for it.

Nacha’s 2026 rule changes require ACH participants to implement documented, risk-based processes specifically designed to detect False Pretense payments. Understanding what those requirements actually demand from your organization is necessary. 

For more information, we have the full breakdown of Nacha’s 2026 rule changes that covers every requirement in plain language, including what False Pretenses detection looks like in a compliance-grade program.