Nacha's Credit-Push Fraud Rules: Monitoring Duties, Not Liability

If you originate ACH in the United States, a rule that probably applies to you came fully into force this summer, and most of the coverage of it is wrong in the same direction.

Nacha's risk-management package now requires almost every non-consumer ACH originator, every ODFI, and every receiving bank to run fraud monitoring. Phase 1 landed on 20 March 2026. Phase 2 removed the volume threshold three months later. Both are behind us.

What the rules do not do is move liability. That distinction is the whole article.

What is actually in force

A small date trap worth knowing. Nacha's Phase 2 rule page gives the effective date as 19 June 2026, then notes that this is a federal holiday and that the practical effective date is the next banking day, Monday 22 June 2026. Nacha's own summary table of upcoming rule changes lists 22 June. If you are reconciling a compliance calendar against a vendor's, that is where the one-day discrepancy comes from.

Who is in scope

Phase 1 applied to all ODFIs with no threshold at all, plus:

• non-consumer Originators, Third-Party Service Providers and Third-Party Senders with 2023 ACH origination volume of 6 million entries or greater
• RDFIs with 2023 ACH receipt volume of 10 million entries or greater

Phase 2 eliminated the volume threshold. If you are a non-consumer Originator, a TPSP or a TPS, you are in scope regardless of how little you originate. If you are an RDFI, you are in scope regardless of how little you receive.

Note the qualifier that does the real work: non-consumer. The obligation runs to businesses originating ACH, not to consumers.

What the rule requires

The core obligation is one sentence, and it is worth reading carefully:

establish and implement risk-based processes and procedures, relevant to the role it plays in the authorization or Transmission of Entries, that are reasonably intended to identify Entries that are suspected of being unauthorized or authorized under False Pretenses

Plus: review those processes and procedures at least annually and update them to address evolving risks.

That is the entire technical requirement. There is no prescribed control, no mandated vendor, no threshold, no reporting obligation.

What the rule explicitly does not require

This is where most secondary coverage overreaches, and Nacha's own FAQ is unusually blunt about it.

It does not require screening every entry individually. Nacha's answer to that question is one word: "No."

It does not require monitoring before processing. Also "No" — though Nacha notes that pre-processing monitoring gives the greatest opportunity to detect and prevent fraud. It simply is not mandated.

It does not prescribe how. Nacha states the rules provide for a risk-based approach and do not specify processes and procedures that participants must use.

It does not let you conclude that nothing is needed. This is the limit on the previous point, and it is the sentence to quote at anyone arguing risk-based means optional:

A risk-based approach should not be used, however, to conclude that no monitoring is necessary at all. At a minimum, an entity applying a risk-based approach should conduct a risk assessment to identify and differentiate higher-risk from lower-risk transactions.

For debits, existing practice may already satisfy it. Nacha states that a robust return and return-rate monitoring programme in conformance with existing rules — together with any required compliance with the existing WEB debit and Micro-Entries fraud detection rules — is sufficient as a minimum level of fraud monitoring on the debit side.

Read together, the drafting history tells you the direction of travel. Between the May 2023 Request for Comment and the final rule, Nacha eliminated "commercially reasonable" as a standard, replaced "detection system" with "processes and procedures", scoped the duty "to the extent relevant to the role the entity plays", clarified that pre-processing monitoring is not required, and allowed an ODFI to consider steps other origination participants are taking. Every one of those changes moved away from prescription.

False Pretenses is a defined term, and it is narrower than you think

The rules introduce a newly defined term:

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.

Nacha says this covers business email compromise, vendor impersonation, payroll impersonation and other payee impersonations, and complements the existing language on unauthorized credits, which addresses account takeover.

Then the carve-out that matters:

It does not cover scams involving fake, non-existent or poor-quality goods or services.

So a purchase scam — goods advertised, paid for, never delivered — falls outside False Pretenses entirely. Under the UK's mandatory reimbursement scheme a purchase scam is squarely in scope. Under Nacha's definition it is not the thing you are required to monitor for. If your fraud taxonomy was built against a UK or EU framework, it does not map cleanly onto this rule.

This is not the UK model, and the rules say so

The single most important sentence in the package is a disclaimer.

Nacha states that the requirements do not impose obligations to prevent wrongful activity and do not change the allocation of liability between parties. The rules carry express disclaimers of modification of Uniform Commercial Code Article 4A rights and obligations, and of the creation of any duty other than the commitment to Nacha to comply with the Rules. Nacha's stated reason is that this allows it to manage compliance through existing enforcement mechanisms "without upsetting the allocation of liability among Nacha participants under otherwise applicable law."

Contrast that with the UK, where the Payment Systems Regulator's mandatory reimbursement scheme creates an actual entitlement for the victim to be repaid. This article does not restate that scheme's parameters — its cap, its liability split and its exclusions are set out, with their own sourcing, in authorized push payment fraud and the real-time rail liability problem. The point here is only the shape of the two answers.

The US has taken the opposite structural route. Nacha has expanded who must look, not who must pay. A firm that fails here faces a rules-compliance process with Nacha. It does not face a new statutory route for a defrauded counterparty to recover from it.

That distinction should change how you resource this. It is a compliance-and-controls programme, not a loss-reserve question.

The receiving side: what an RDFI is now expected to see

RDFI credit monitoring is the genuinely new obligation, because receiving banks historically had no fraud duty on inbound credits at all.

Nacha's guidance on what to look for is concrete, and it maps onto data an RDFI already holds:

• a Standard Entry Class code that does not align with the receiving account type — Nacha's example is a corporate CCD entry landing in a consumer account
• a high-dollar transaction that is atypical for the receiving account
• a series of similar credit entries received in a short period, such as multiple payroll or benefit payments
• any of the above to a new account, a dormant account, or an account acting as a mule

Where an RDFI concludes an entry is unauthorized or authorized under False Pretenses and decides to return it, Nacha points to return reason code R17 "QUESTIONABLE", or R06 at the ODFI's request.

Nacha also notes that a flagged entry can be held using what it describes as the voluntary exemption from funds availability requirements for credit entries, buying time to examine an outlier transaction and the receiving account. This is a different provision from the September 2026 funds-availability change below. Do not conflate the two — one is a fraud tool, the other is a timing rule with a narrow geographic carve-out.

The origination side: what an ODFI can do with a hit

Nacha gives a deliberately open list. Its wording is that actions "may include, but are not limited to" the following — so treat these as worked examples, not as the complete set of sanctioned responses:

1. stop further processing of the flagged transaction
2. consult the Originator to determine the transaction's validity
3. consult other internal monitoring teams or systems for additional flags
4. contact the RDFI to check whether the receiving account raises red flags, or request a freeze or the return of funds

Point four is the one that requires infrastructure you may not have. Contacting an RDFI you have no relationship with means using Nacha's ACH Contact Registry, which is what it exists for.

There is also a delegation provision worth knowing: an ODFI's processes may expressly consider the processes and procedures implemented by other participants in origination. Nacha's caveat is that the basis for relying on another party "should be reasonable and clear (e.g., allocated by contract and verified by appropriate oversight)". If you are a platform relying on your TPS, or a TPS relying on your ODFI, put it in the contract and audit it. The reliance runs only in one direction, though — receiving-side procedures do not reduce an originating party's obligations, and originating-side procedures do not reduce an RDFI's.

The data change most operators missed

Buried in the same package, and effective the same day as Phase 1, are two mandatory Company Entry Descriptions. This is a file-format change with a compliance deadline that has already passed.

PAYROLL must be used on PPD credits for the payment of wages, salaries and similar compensation. The purpose is to let RDFIs identify compensation payments — Nacha's stated target is payroll-redirection fraud, and a standard descriptor lets a receiving bank apply logic about early funds availability when a new or duplicate payroll credit hits an account.

Nacha adds a careful disclaimer: using PAYROLL is for fraud-mitigation classification only, "without regard to how the payee is classified by the employer for legal or tax purposes", and makes no representation about the receiver's employment status. It is not a tax signal.

PURCHASE must be used for consumer e-commerce purchases, on WEB debits (or TEL where the Standing Authorization rule permits). The scope is narrower than "e-commerce" suggests, and Nacha's own page states it two ways. The rule's Details section says "the online purchase of goods". Its FAQ gives the operative definition and is more specific:

For purposes of this rule, an e-commerce purchase is a debit entry authorized online by a consumer Receiver (i.e., a WEB debit) for the purchase of tangible, hard goods, including recurring purchases of tangible goods first authorized online.

Followed by: "E-commerce purchases do not include the purchase of services."

Take the narrower reading, because Nacha's own examples are unambiguous about where the line falls:

Nacha notes its own list is not exhaustive. The practical test is whether a physical object is being bought, not whether the payment happened on a website. A subscription is not automatically in scope, and a digital-only purchase is not a "tangible, hard good".

The field itself is positions 54–63 of the Company/Batch Header Record, with a maximum of 10 characters.

One asymmetry to plan around: the ODFI has no obligation to verify the presence or accuracy of the word PURCHASE. Nobody downstream is policing your descriptor. That means nobody will tell you it is wrong, and it also means the data quality of this field across the network will be uneven for some time — so if you are on the receiving side, treat it as a signal, not a fact.

The next date: 18 September 2026

Three weeks from this article's publication, and it is not a fraud rule.

From 18 September 2026, an RDFI must make a non-Same Day credit entry available for withdrawal no later than 9:00 a.m. in the RDFI's local time on the settlement date. This eliminates the previous 5:00 p.m. receipt condition — availability no longer depends on when the file reached the receiving bank.

Nacha's own impact assessment is that this aligns the rule with what most RDFIs already do. The exposure sits with RDFIs that currently post late-arriving next-day credits after 9:00 a.m., including credits arriving in the 6:00 a.m. ET operator file.

A narrow exception applies to RDFIs east of the Atlantic Time Zone and west of the International Date Line — Nacha names Guam and the Northern Mariana Islands. Where an entry reaches such an RDFI after 8:00 a.m. local time on settlement date, availability moves to end of settlement date, or to 9:00 a.m. the next banking day if the file arrives after the RDFI finished processing.

What is not in force yet

Two changes circulate in vendor material as though they were current. They are not.

Same Day ACH at $10 million takes effect 17 September 2027. The per-payment limit today remains $1 million. Nacha's stated rationale is parity with rails that already moved: it notes RTP raised its per-payment limit from $1 million to $10 million in June 2025, and FedNow did the same in November 2025. If you are sizing a same-day treasury flow, the $1 million cap is the one that binds you now.

Return reason code R90, for entries an RDFI returns to meet its sanctions compliance obligations, arrives 17 March 2028. At that point R16 loses its OFAC framing and reverts to "Account Frozen". Until then, an R16 return still carries both meanings, which is precisely the ambiguity the new code exists to remove — an R16 today may mean a sanctions determination or may mean a garnishment, and the two demand different responses from you.

What an operator actually does differently

• Write the risk assessment down. The rule is judged on processes and procedures, and "risk-based" without a documented assessment differentiating higher- from lower-risk transactions is the one posture Nacha explicitly rules out.
• Diary the annual review. The at-least-annual review is an express requirement, not guidance. A programme with no review record fails on its face.
• Do not buy per-transaction screening because a vendor says the rule demands it. It does not. Screening every entry and pre-processing monitoring are both explicitly not required.
• Check your descriptors now if you originate payroll or e-commerce debits. PAYROLL and PURCHASE have been mandatory since March 2026, and nobody downstream will reject a file for getting them wrong.
• Re-map your fraud taxonomy. If it was built to a UK or EU definition, purchase scams sit outside Nacha's False Pretenses definition and account-takeover sits under a different existing heading.
• Get the contract right if you are relying on someone else. ODFIs may consider other origination participants' procedures, but Nacha wants that allocation clear and overseen — and it does not work across the origination/receipt boundary in either direction.
• Treat 18 September 2026 as an operations change, not a compliance one. It affects posting windows and customer expectations on next-day credits, not your fraud programme.

The honest summary

Nacha has done something more conservative than the headlines suggest. It expanded the population of parties who must look for fraud to essentially everyone originating or receiving non-consumer ACH, and it did so while explicitly refusing to prescribe how, refusing to require per-entry or pre-processing checks, and expressly disclaiming any change to who bears the loss.

For a US operator that already runs return-rate monitoring on debits, the incremental work on the origination side may be genuinely modest — documenting it and reviewing it annually. The real new obligation lands on receiving institutions, which had no inbound-credit fraud duty before, and on the definitional work of separating impersonation fraud from purchase scams that this rule deliberately leaves out.

For the mechanics of ACH debits themselves — SEC codes, authorization requirements, returns and return-rate thresholds — see direct debit payments explained.