Nacha’s 2026 ACH rules make payment fraud a shared control

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Socure's blog post: Nacha’s 2026 ACH fraud rules broaden monitoring duties across more participants and add standardised company entry descriptions to improve fraud detection.

Why it matters: This matters to banking, payments and identity practitioners because ACH fraud controls now depend on shared detection, account verification and governance across originators, senders and receiving institutions.

By the numbers:

• Consumers reported losing more than $12.5 billion to fraud in 2024, which represents a 25% increase over the prior year.
• Phase 1, effective March 20, 2026, applies to all ODFIs and to those Originators, Third-Party Senders, and Third-Party Service Providers whose 2023 origination or transmission volume exceeded 6 million entries.
• Phase 2 started June 19, 2026, with the practical effective date falling on Monday, June 22, 2026.

Context

ACH fraud has moved beyond a sender-only problem because scammers increasingly rely on legitimate accounts, deceptive requests and payment redirection rather than obvious technical compromise. In that model, validation that an account exists is not enough, because the control gap is in intent and transaction context.

The 2026 Nacha rule changes push monitoring into a shared governance model across originators, banks and third-party service providers. That is the right direction for payment fraud, and it is also a reminder that verification controls have to sit inside the transaction flow, not outside it.

Key questions

Q: How do ACH networks detect false pretenses fraud?

A: ACH networks detect false pretenses fraud through rule-based screening, risk-based transaction monitoring, anomaly detection, and account validation that look for mismatched names, unusual payment patterns, and abnormal originator behaviour. Filters, velocity checks, return-code analysis, and step-up review help identify payments induced by deception before settlement, while escalation paths let operators block or reverse suspicious entries.

Q: Why do valid bank accounts still create payment fraud risk?

A: Valid bank accounts still create payment fraud risk because the account can belong to the wrong person, be newly opened, or be controlled through social engineering rather than theft of credentials. Fraud controls therefore rely on beneficiary verification, account ownership checks, sanctions screening, and step-up approval for changed payment instructions, not just account validity.

Q: How should banks govern ACH monitoring across originators and receivers?

A: Banks should govern ACH monitoring with shared responsibility across origination, receiving, and exception handling, so each party validates its own customers, files, and return activity. That means defined control ownership, monitoring thresholds, call-back or out-of-band verification for instruction changes, and case management for suspicious returns, misdirected credits, and account takeover indicators.

Q: What should teams do first when payroll diversion is suspected?

A: The first step is to verify the report through a known contact and pause any payment changes until the request is authenticated. Teams should use a trusted call-back number, confirm the employee and pay details, preserve evidence, and notify payroll, finance, and fraud responders so diversion instructions can be stopped quickly.

Technical breakdown

Risk-based ACH fraud monitoring across the network

The rule change replaces a narrow, sender-centric model with a broader risk-based expectation across ACH participants. Risk-based monitoring means controls are tuned to the payment’s context, such as amount, payee history, channel, timing and unusual account changes, rather than applying one static check to every transaction. In practice, this shifts the control objective from validating a record to detecting suspicious behaviour across the lifecycle of the payment. That matters because a legitimate account can still be used for fraud, especially when the request is socially engineered rather than technically compromised. See the Real-Time Payments Fraud Guide.

Practical implication: Build transaction-scoring and exception workflows that inspect both originator and recipient risk before an ACH payment is released.

False pretenses fraud and the limits of account validation

False pretenses fraud is payment deception, not account non-existence. The account can be open, active and technically valid while the instruction to pay is fraudulent, which is why account validation alone cannot resolve the risk. This is the same structural weakness seen in vendor impersonation, payroll diversion and authorised push payment scams. The control problem is not whether the account exists. It is whether the payment instruction is genuine, whether the account belongs to the intended recipient and whether the transaction fits the expected pattern. See the Authorised Push Payment (APP) Fraud Guide.

Practical implication: Combine ownership checks with behavioural and contextual signals so valid accounts do not become blind spots.

Standardised company entry descriptions as fraud context

Company entry descriptions are metadata, but they matter because payment labels create a shared language for detection. When a payroll credit is clearly labelled, a receiving institution can compare the payment against expected payroll behaviour and notice deviations such as rerouted salary deposits or abnormal payee patterns. Standardisation does not stop fraud by itself. It improves the quality of downstream monitoring by making suspicious entries easier to classify consistently across participants. That is especially useful when one organisation’s review queue is trying to interpret what another organisation initiated.

Practical implication: Use consistent ACH descriptions and file controls so receiving-side monitoring can detect deviations from expected payment purpose.

Threat narrative

Attacker objective: The attacker wants to move money into a controlled account by making a legitimate payment process approve a fraudulent instruction.

1. Entry occurs when a fraudster impersonates a vendor, bank or internal contact to induce an ACH payment request or account change.
2. Credential_harvested happens when the attacker gains trust through a legitimate-looking email thread, altered payment instructions or payroll diversion request.
3. Escalation follows when the payment is accepted by a valid account that fits validation checks but not the intended business relationship.
4. Impact is the transfer of funds to a mule account or the redirection of payroll, refunds or vendor payments with limited recovery time.

NHI Mgmt Group analysis

Shared fraud governance is now the correct model for ACH. The old sender-only mindset assumed the party originating a payment had the best chance to stop fraud, but deceptive payment flows routinely surface signals on the receiving side as well. Nacha’s rule shift formalises what payment fraud teams have already learned operationally: detection has to be distributed across the network. The practical consequence is that banks, originators and third-party processors all become part of the same control plane.

False pretenses is the right named concept for this change. The article’s key governance failure is not weak validation alone, but the assumption that a valid account implies a legitimate payment. That assumption breaks as soon as social engineering, vendor impersonation or payroll diversion enters the flow. A useful control design starts by recognising that account validity and payment legitimacy are different questions, and they must be answered separately.

Standardised labels improve detection only when they are tied to enforcement. PAYROLL and PURCHASE descriptions help create consistent context, but metadata without monitoring discipline becomes decorative compliance. The important governance point is that common labels make cross-participant review more reliable, especially when reviewing deviations from normal payment purpose. Teams that rely on labels alone will still miss deceptive instructions; teams that pair labels with behavioural screening can use them as a detection accelerator.

ACH fraud is now an identity problem as much as a payments problem. The scams described here succeed because the system cannot tell who is truly behind the instruction, not because the transfer rail is inherently weak. That places identity verification, beneficiary ownership checks and risk-based review inside the same governance conversation as payments operations. Practitioners should treat payment authentication and payment authorisation as distinct controls, then align both to the same fraud response model.

What this signals

ACH fraud governance is shifting from static validation to dynamic transaction assurance. That change matters because payment legitimacy depends on intent, context and beneficiary history, not just whether an account exists. Payment teams that keep treating validation as a one-time check will miss the highest-value deception patterns.

Shared responsibility is now the operational model that matters. Originators, sender banks and receiving banks each see different parts of the risk, so fraud detection has to move with the payment rather than stop at the first checkpoint. Practitioners should expect monitoring, exception handling and callback verification to become more tightly linked across the ACH lifecycle.

False pretenses detection will increasingly sit alongside identity verification. The useful control question is no longer only whether an account is live, but whether the instruction came from the right party and matches expected behaviour. That means payment governance will borrow more from identity assurance, out-of-band verification and behavioural analytics.

For practitioners

• Implement network-wide ACH fraud monitoring Extend fraud detection to both origination and receipt workflows, with risk-based review for amount, beneficiary change, new payee setup and unusual timing.
• Separate account validity from payment legitimacy Require ownership and intent checks before release, so a valid account does not automatically pass approval when the payment context is suspicious.
• Standardise entry descriptions in ACH templates Use the required PAYROLL and PURCHASE labels consistently in files and internal templates, then verify that monitoring logic consumes those labels.
• Add hold-and-call controls for high-risk changes Pause first-time payments, bank-detail changes and off-cycle payroll requests until a known-contact callback confirms the request out of band.
• Review third-party monitoring responsibilities Confirm which controls sit with the originator, the sender bank and any third-party service provider, then document the handoffs in the payment workflow.

Key takeaways

• The Nacha rule changes reflect a broader shift from sender-only fraud control to shared ACH monitoring across the network.
• The core risk is deceptive payment intent, where legitimate accounts and valid instructions can still be used to redirect funds.
• Practitioners need risk-based monitoring, ownership checks and standardised payment labels to reduce false pretenses fraud without slowing routine payments.

Related NHI Mgmt Group resources: Real-Time Payments Fraud Guide · Authorised Push Payment (APP) Fraud Guide · Deepfake and Payment Fraud Executive Briefing · AML programme and transaction monitoring

Key terms

• Authorised Push Payment Fraud: A payment scam in which the victim is persuaded to authorise the transfer themselves. The transfer is technically authorised, but the decision is corrupted by deception, which makes liability, evidence, and prevention harder to separate from standard transaction controls.
• ACH Network: ACH Network is the electronic payment system used in the United States for batch processing of bank-to-bank credit and debit transfers. It moves payments through standardised files, routing rules, settlement windows, and return processes that let originating and receiving institutions exchange low-value transactions.
• Company Entry Description: Company Entry Description is the descriptive text attached to an ACH entry that explains the purpose of the transaction to the receiver. It appears on statements and notifications, and is used for context, reconciliation, and fraud review, although it does not by itself authorise the payment.
• False Pretenses Fraud: False pretenses fraud is a deception offence in which someone obtains money, goods or services by knowingly making a false statement of fact. In cyber and identity abuse, it often appears as impersonated requests or fraudulent claims that persuade a victim to transfer funds or reveal credentials.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity controls to the broader security programmes they operate.