Nacha is implementing a major update to how financial institutions must monitor ACH transactions.

For the first time, both originating and receiving institutions will be responsible for detecting transactions authorized under false pretenses.

Scams like business email compromise, payroll impersonation, and vendor fraud often involve the victim approving the payment. These scenarios have traditionally fallen outside Nacha’s fraud framework, limiting recovery and monitoring options. The new rules explicitly include these inducement-based scams and assign accountability across the ACH flow.

Covered institutions will need risk-based controls that detect deception, not just unauthorized access. This includes monitoring for behavioral anomalies, social engineering patterns, and misrepresented identities.

In this post, we’ll explore the new rule changes, and what risk teams need to do to prepare.

What the new Nacha rules require from ACH participants

Nacha is introducing new monitoring requirements that apply to both the origination and receipt of ACH transactions. These rules expand the requirements and capabilities to include payments authorized under false pretenses, such as scams involving impersonation or social engineering.

The Nacha rules apply in phases based on ACH transaction volume:

These changes formalize the expectation that all ACH participants must be able to detect fraud risk across the full transaction lifecycle. That includes cases where a payment was initiated by the customer but based on misrepresented information. This scenario is now explicitly covered under Nacha’s definition of false pretenses.

What “false pretenses” means in practice

Nacha defines false pretenses as “the inducement of a payment by a person misrepresenting (a) that Person’s identity, (b) that Person’s association with or authority to act on behalf of another Person, or (c) the ownership of an account to be credited.”

This definition covers common fraud scenarios such as:

• Business Email Compromise (BEC)
• Vendor impersonation
• Payroll impersonation
• Account takeovers

Important: This definition does not cover scams involving fake, non-existent, or poor-quality goods and services.

Operationally, this new language means risk teams must adapt fraud programs to detect transactions that are authorized but inconsistent with historical behavior, recipient profiles, or known trust relationships.

What ACH fraud monitoring now requires

The new rules assign explicit fraud detection responsibilities based on an institution’s role in the ACH transaction. Nacha does not mandate real-time screening of every transaction, but it does expect institutions to implement structured, risk-based monitoring procedures that are reasonably intended to detect unauthorized entries and payments induced under false pretenses.

New Nacha rules for ODFIs, Originators, TPSPs, and TPSs

Participants involved in originating ACH entries must:

• Establish and implement risk-based processes and procedures relevant to their role in authorizing or transmitting entries
• Ensure those procedures are designed to identify entries suspected of being unauthorized or authorized under false pretenses
  
• Review and update those processes at least annually to account for evolving risks

Institutions are not required to screen every transaction individually or in real-time. The rules allow for layered controls that factor in third-party processes and upstream due diligence, not just per-entry decisioning. 

For example, an ODFI’s program may rely on KYC practices by the originator, risk scoring based on transaction metadata, and alert thresholds informed by historical fraud events.

New Nacha rules for RDFIs

Receiving Depository Financial Institutions (RDFIs) must apply similar standards to the receipt of ACH credits:

• Establish and implement risk-based procedures that are reasonably intended to identify credits suspected of being unauthorized or authorized under false pretenses
  
• Review and update monitoring controls at least annually to ensure they remain effective as fraud patterns evolve

These procedures do not require screening every credit individually or in real-time. RDFIs may assess entries after posting using behavioral analytics, velocity checks, or alert-based workflows, as long as the system is reasonably designed to surface and respond to fraud risk.

Best practices for the new Nacha fraud monitoring rules

To meet Nacha’s expectations, fraud programs must evolve from reactive controls to a structured, risk-based monitoring framework that addresses both unauthorized and socially engineered payments. 

Here are five best practices to help your fraud and payment operations teams meet Nacha’s requirements.

1. Monitor across the customer lifecycle

Monitoring the transaction alone is not sufficient. Many scams, like payroll diversion or vendor impersonation, look clean at the point of transfer but show warning signs earlier. Use onboarding data, behavioral changes, and account metadata to detect mismatches in ownership or destination before the payment is sent.

For example, if the account provided during onboarding differs from the account used in a payroll file, that could indicate redirection by a fraudster. Lifecycle monitoring helps you detect these changes early.

2. Use device and behavioral signals to catch early signs of fraud

Device and behavior signals are the earliest and most effective indicators of fraud across ACH flows. They help surface risk well before transaction-level anomalies appear.

These signals are critical for detecting:

• Unauthorized transfers, such as account takeovers, where the user is logging in from a new device, using remote access software, or failing behavioral authentication checks
  
• Social engineering scams, where a customer is manipulated into initiating a payment under false pretenses, often marked by changes in typing cadence, navigation patterns, or hesitation during payment setup
  
• Suspicious counterparties, such as mule accounts receiving funds after a session that shows signs of scripted behavior, spoofed devices, or identity mismatch
  Used together, device and behavior signals help identify risk during login, profile updates, or file uploads, not just at the moment a transaction is submitted.

2. Establish and maintain role-specific fraud procedures

Nacha requires institutions to implement fraud monitoring procedures tailored to their role in the ACH flow. That means your controls, signals, and escalation paths should look different depending on whether your institution is originating or receiving funds.

Across both roles, institutions should maintain documented procedures that describe how alerts are generated, how cases are escalated, and who has authority to approve returns or hold funds. Although Nacha only requires these procedures to be reviewed and updated annually,  teams in high-risk environments may need to iterate daily, weekly or monthly.

3. Leverage ACH tools for handling flagged entries

If a transaction appears fraudulent or suspicious, Nacha provides optional tools that allow RDFIs and ODFIs to take action:

• Delay funds availability by using the exemption for entries suspected to be originated under false pretenses. This provides time to investigate the transaction and assess the risk associated with the receiving account.
  
• Consult the ACH Contact Registry through Nacha’s Risk Management Portal to identify and contact the ODFI. This can support fact-gathering before deciding how to proceed.
  
• Return the entry using Reason Code R17 with the descriptor “QUESTIONABLE” if the RDFI believes the entry is unauthorized or was induced under false pretenses. This must be done within the standard return timeframe.

These options are voluntary, but they give RDFIs tools to act when a transaction looks suspicious but has not yet been formally disputed by the customer.

4. Coordinate between fraud and payment ops teams

Fraud detection under these rules spans both front-line detection and back-office response. Your fraud team may catch the signal, but payment ops often handles timing, returns, and counterparty communication. Without shared visibility and coordination, key actions can be missed or delayed.

Create standing workflows between fraud and ops for reviewing flagged entries, confirming return criteria, and updating shared procedures. Make cross-team communication a regular part of how fraud is managed.

How Sardine helps you detect and stop ACH fraud

Sardine helps financial institutions meet Nacha’s fraud monitoring requirements by detecting risk early, before an ACH transaction is submitted or cleared. We combine device intelligence and behavioral biometrics to identify signs of account takeover, social engineering, or mule activity during login, account changes, and payment setup.

We offer machine learning models fine-tuned to detect various forms of ACH fraud. We help you predict the likelihood of a return, including unauthorized return codes like R05, R07, R10, R11, and R29, as well as non-sufficient funds returns like R01 and R09. These models also identify fraudulent payouts, giving you advanced warning before a loss occurs.

In addition to return risk scoring, we apply anomaly detection across your ACH flows to flag emerging fraud attacks. That includes spikes in transaction velocity, unusual origination patterns, or deviations from normal counterparty behavior. Together, these tools help your fraud and operations teams stay compliant, reduce losses, and respond to new threats faster.

Contact Sardine to explore how our platform can help you reduce chargebacks and stay below VAMP thresholds.