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.

Once the credit has settled: recovery is a request, not a right

Point four in that list — contacting the RDFI to check the receiving account, or to ask for a freeze or the return of funds — is the step most origination teams have never actually run. It is worth being precise about what it is, because Nacha has a named mechanism for exactly this situation, and the defining feature of that mechanism is that the other bank can decline.

What R06 actually buys you. A rule change titled Expanded Use of ODFI Request for Return/R06 became effective 1 October 2024. Nacha's description is that it "expands the permissible uses of the Request for Return to allow an ODFI to request a return from the RDFI for any reason", and that the rule "is intended to improve the recovery of funds when fraud has occurred."

Then comes the pair of sentences that should shape how you resource this:

The ODFI would indemnify the RDFI for compliance with the request. Compliance by the RDFI would remain optional.

Read them in that order. The originating bank carries the risk of having asked. The receiving bank keeps the discretion to refuse. Nothing in the published material obliges an RDFI to send funds back because you have told it a credit was fraudulent.

Since 1 April 2025 you are owed an answer, and only an answer. A follow-on amendment requires an RDFI to advise the ODFI of the status of a Request for Return "within ten (10) banking days of receipt of the ODFI's request". Nacha draws the boundary of that duty in a single sentence:

An RDFI's only obligation to the ODFI would be to respond to the ODFI's request.

Nacha adds that regardless of whether the RDFI complies, it must advise the ODFI of its decision or the status of the request inside those same ten banking days — and that if it has already processed the requested return within them, nothing further is required of it. The method of contact is not stipulated by the rule; Nacha's examples are the method named on the request itself, its Risk Management Portal, and the ACH Contact Registry.

So what a Request for Return reliably produces is an answer within ten banking days — its decision, or the status of the request. What it does not produce is funds.

Why the indemnity is the term that does the work. Nacha's Risk Management Advisory Group published credit-push fraud response checklists in 2023. Treat them as guidance rather than rule — Nacha's own caption on them reads: "The lists offer good starting points, but they are not written in stone." Both the RDFI checklist and its companion ODFI checklist carry the same step in the same position, two steps before any money moves: "Determine the need for an indemnification agreement."

That is the operational shape of an optional-compliance regime. The receiving bank is not deciding whether you are right about the fraud. It is deciding whether it is safe to move its own customer's money on your say-so, and the indemnity is the instrument that makes a yes possible. If your fraud playbook carries no pre-agreed indemnity language and no legal sign-off path that runs in hours, your request queues behind the ones that do.

A Reversal is a different mechanism, and fraud is not on its list. The common error is to reach for a Reversing Entry instead. When Nacha published its 2021 Reversals rule change, it stated the permissible grounds this way:

In addition to existing reasons for the origination of a Reversing Entry (i.e., duplicate entry, incorrect receiver, incorrect dollar amount, or certain PPD credits related to termination/separation from employment), an Originator or ODFI may now also initiate a Reversal when it has transmitted a debit Entry that orders payment on a date earlier than intended, or when it has transmitted a credit Entry that orders payment on a date later than intended.

Nacha flags that page as an archived rule change, so read it as how Nacha stated the permissible grounds when it published that change, not as a certified current list. Fraud is absent from it either way.

Our reading of why that is coherent — this is PaymentBrief's inference, not Nacha's wording — is that a reversal exists to correct an erroneous entry, and a scam-induced credit is not erroneous. The amount is right. The receiver is the party the Originator named. The date is the one intended. The deceived Originator instructed exactly the payment that was sent, which is what makes this class of fraud hard to unwind, and it is why a correction tool cannot double as the recovery tool.

The timing rules out most fraud cases regardless. A Reversal must reach the RDFI "within 5 banking days following the Settlement Date of the Erroneous Entry" — a window that can close before an impersonation scam has even been noticed by the party that was deceived.

An improperly originated Reversal also comes back at you. Nacha's published statement of that rule change is that an RDFI may return one using R11 for a consumer account, on an extended timeframe running to the opening of business on the banking day following the 60th calendar day after the improper Reversal's settlement date, and only after obtaining the consumer's Written Statement of Unauthorized Debit. For a non-consumer account — or where the RDFI identifies the improper Reversal itself rather than being told by its customer — the code is R17, with the return due by the opening of business on the second banking day. Nacha adds that an improper Reversal may also draw a rules enforcement proceeding. Used as a fraud tool, a Reversal is not merely ineffective; it is a returnable entry with an enforcement tail.

What the published material does not give you. Three absences are worth stating plainly, because vendor material tends to fill them in. There is no published deadline by which an RDFI that agrees to return funds must complete the return — the ten banking days is a deadline for the answer, not for the money. There is no published window inside which a defrauded Originator must invoke the Request for Return. And nothing in this package makes funds reappear once they have left the receiving account. At that point what is left is the post-mortem rather than recovery, and Nacha's guidance reflects it: the ODFI checklist turns to a Suspicious Activity Report, the AML team, a decision on notifying law enforcement, and internal and external grey lists. Those are containment steps, not remedies.

None of this was changed by the 2026 monitoring rules. They expanded who must look for fraud, not who must give the money back. Recovery still runs through a mechanism whose central feature is that the receiving bank may say no — and whose only firm guarantee is an answer within ten banking days.

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 rules land that morning, and none is a fraud rule. Two are the funds-availability change and its time-zone exception. The third rewrites what counts as an international ACH transaction, and it is the one more likely to reach a payment flow you thought you understood.

Funds availability by 9:00 a.m.

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.

The same date rewrites the IAT definition

Article Eight section 8.55 gets new language on 18 September 2026. Nacha's stated reason is not subtle: "Industry participants have indicated difficulty in understanding the existing definition of IAT."

The replacement makes an IAT "an Entry that is the U.S. ACH network component of an international payment transaction." That pushes the work into a second definition: an international payment transaction is a transfer of funds or monetary value that "(a) originates with, transits through, or is delivered to an account at an office of a financial agency located outside of the U.S., or (b) otherwise is received from a sender or delivered to a receiver, in each case, via a facility of a financial agency located outside of the U.S." A financial agency is "an entity that is authorized by applicable Legal Requirements to provide financial asset accounts, including deposits, or to conduct the business of issuing general purpose payment instruments or transferring funds or other monetary value for third parties." Section 8.44 "Removes the formal definition of a Financial Agency", so the term is no longer a standalone Article Eight defined term — its meaning now lives inside 8.55 itself.

The replacement text also carries the sentence "An IAT Entry cannot be a Same Day Entry." That exclusion is not new — Nacha's Same Day ACH dollar-limit rule already recorded that "IATs would remain ineligible for SDA" — and moving it inside the definition changes nothing about eligibility. It matters here only because of what the definition change can do, which is the next paragraph.

Why this is not housekeeping. A definition change with no new obligation attached can still move payments between categories. Nacha puts it conditionally — the new definition "could result in" some payments "previously treated as domestic being identified as IATs, or vice versa", where parties had been unclear about the previous definition — and sets out what could then be required of an originator whose volume shifts: new IAT originator onboarding, agreement updates, due diligence requirements, and "Receiver information provision requirements". On the receiving side it expects "Potential alteration of IAT volume based upon new IAT understanding," which lands as a change in compliance screening volume rather than a new duty.

The trap is the interaction, and it is the reason a definitional tidy-up is worth an operator's attention. If a flow you currently originate as Same Day ACH turns out to meet the new international test, you do not simply re-code the SEC field — IATs have never been eligible for Same Day, so that flow loses same-day settlement. The exclusion is old; what is new is that the boundary deciding who falls inside it has moved. A reclassification is therefore a product decision about settlement speed, not just a mapping change. The transactions most exposed are the ones where a leg touches a non-US financial agency without the payment looking international at origination: payouts routed through a foreign-domiciled intermediary, funding legs behind a cross-border wallet, or collections where the receiving institution's office sits outside the US.

One connection worth making, because this article already carries the other end of it. Nacha describes the definition rewrite as "one of several IAT-related Nacha Operating Rules changes taking effect over the next two years." From 1 January 2027 institutions must maintain IAT contacts in the ACH Contact Registry, and "Additional changes follow in March 2027 and March 2028, including a new return reason code for sanctions compliance obligations." That last item is R90, covered below as a 2028 date. Nacha groups it with its IAT-related changes, but the code itself is not IAT-specific: it applies to any entry an RDFI returns on sanctions grounds, across all SEC codes.

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.
• 18 September 2026 is two different jobs, and only one of them is operations. The funds-availability change affects posting windows and customer expectations on next-day credits. The IAT redefinition is a compliance and product review — whether any flow reclassifies, and what that costs you in settlement speed. Neither touches 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.