Nacha 2026 rule changes: fraud monitoring phases and PAYROLL and PURCHASE descriptors

What the 2026 Nacha rules change, and when

Three Nacha rule pages describe the 2026 Risk Management amendments. The pages carry effective dates and no publication date; we re-read all three on 2026-09-22. The originating bank is the ODFI (Originating Depository Financial Institution) and the receiving bank is the RDFI (Receiving Depository Financial Institution).

• Fraud monitoring by originating parties, Phase 1. The Phase 1 rule page (effective 20 March 2026) applies to all ODFIs and to non-consumer Originators, Third-Party Service Providers (TPSPs), and Third-Party Senders (TPSs) "with annual ACH origination volume of 6 million or greater in 2023". Each must "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" and "review (at least annually) these processes and procedures and make appropriate updates to address evolving risks."
• Credit monitoring by receiving banks, Phase 1. The same page applies to RDFIs "with annual ACH receipt volume of 10 million or greater in 2023", which must "establish and implement risk-based processes and procedures designed to identify credit Entries initiated due to fraud." Nacha cites Subsection 3.1.10 of the Nacha Operating Rules for this RDFI obligation.
• Phase 2. The Phase 2 rule page sets 19 June 2026 as the date the volume thresholds end for all other non-consumer Originators, TPSPs, TPSs, and RDFIs. Because 19 June is a federal holiday, Nacha names Monday, 22 June 2026, the next banking day, as the practical effective date.
• False Pretenses. Both pages define the term 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." Nacha states that it covers business email compromise, vendor impersonation, and payroll impersonation, and "does not cover scams involving fake, non-existent or poor-quality goods or services."
• Company Entry Descriptions. The Company Entry Descriptions rule page (effective 20 March 2026) requires "PAYROLL" on PPD credits for wages, salaries, and similar compensation to consumer accounts, and "PURCHASE" on consumer debits for the online purchase of tangible goods. Those purchase debits use the WEB code, except where the Standing Authorization rule permits TEL. "PAYROLL" must sit within the leftmost 7 characters of the 10-character field, and "for the 'PAYROLL' description only" the remaining 3 characters are free. Services, installment loan payments, rent, and insurance premiums do not take "PURCHASE".

The file layout, return rate thresholds, and the rest of the rulebook are on our Nacha Operating Rules testing requirements page.

Why the 2026 rules widen ACH test scope

Before 2026, the Nacha fraud detection requirement covered WEB debits and Micro-Entries only. The Phase 1 page states that those requirements "did not apply to other types of debits or to any credits other than Micro-Entries." From 22 June 2026, a payroll platform sending PPD wage credits or an AP platform sending CCD vendor payments falls in scope at any volume. Credit-push fraud is the target: a changed employee or vendor bank account sends wages or an invoice payment to an account the fraudster controls.

Four statements in Nacha's FAQs decide what a test has to prove:

• No pre-processing requirement. The rules require neither screening each entry individually nor monitoring before processing. A test therefore verifies that the control runs where the client's written procedure says it runs, including a post-processing review.
• Debit minimum. For debits, "a robust return and return rate monitoring program in conformance with existing Rules (as well as any required compliance with other specific fraud detection Rules for WEB debits and Micro-Entries) is sufficient as a minimum level of fraud monitoring." Return handling tests become fraud monitoring evidence for a debit Originator. The NACHA return code testing guide holds the return matrix we run.
• Allocated controls. An ODFI's procedures may consider another originating participant's procedures, and the basis "should be reasonable and clear (e.g., allocated by contract and verified by appropriate oversight)." A sponsor bank that relies on a fintech Originator's controls needs that oversight evidence, and test results showing the allocated controls fire are part of it.
• New return paths. An RDFI that decides to return a suspect credit "may return the entry using Return Reason Code R17 'QUESTIONABLE' or, at the ODFI's request, using Return Reason Code R06." An Originator ledger that has no state for R17 on a credit leaves a payroll or vendor payment unreconciled.

Nacha also states that the fraud monitoring rules do not change the allocation of liability between parties under UCC Article 4A. A redirected payroll credit remains a loss for someone under existing law and contracts; the rules only add the duty to look for it.

The descriptors have a money effect too. Nacha writes that "PAYROLL" "can help support RDFI logic to provide or suppress early funds availability." For payroll platforms, earned wage access products, and neobanks that release wages early, a batch still labelled "SALARY" removes that signal from the receiving bank.

What to test after the 2026 changes

This is our test list for an Originator, TPS, or TPSP after Phase 2. It is our practice, and the Nacha rules do not prescribe it.

1. Payee change controls. Change the bank account on a synthetic employee or vendor record, then trigger a payment. Assert that the alert, hold, or callback in the client's written procedure happens, and record the alert trace. Nacha names "change controls regarding payment information and instructions for vendor and payroll payments" as an Originator procedure.
2. Volume, velocity, amount, and SEC code rules. Nacha lists reviews of "the volume, velocity, dollar amounts and SEC Codes of their originated ACH Entries" for TPSs and TPSPs. Seed synthetic batches above each documented threshold and assert one alert per breach.
3. RDFI red flags, for BaaS and business banking programmes that receive entries. Nacha lists "a corporate CCD entry to a consumer account", an atypical high-dollar credit, and "multiple payroll or benefit payments" to a new, dormant, or mule account. Build one received-entry case per flag.
4. R17 and R06 handling. Post an R17 and an R06 return against a synthetic credit. Assert the ledger state, the customer notice, and that no automatic retry is sent.
5. Descriptor assertions. Parse every generated batch header and compare positions 54 to 63 with the purpose the test case declares.
6. Annual review evidence. Rerun the suite when the written procedure changes and file the dated report with the annual review record.

Step 5 as code. The batch headers are synthetic 94-character records; the SEC code sits in positions 51 to 53 and the Company Entry Description in positions 54 to 63.

# Synthetic batch headers (record type 5), each paired with the payment purpose
# the test case declares. Positions follow the Nacha batch header layout.
BATCHES = [
    ("wages",        "5220SYNTH PAYCO                         1234567890PPDPAYROLL         260626   1091000010000001"),
    ("wages",        "5220SYNTH PAYCO                         1234567890PPDSALARY          260626   1091000010000002"),
    ("online_goods", "5225SYNTH GOODS                         9876543210WEBPURCHASE        260626   1091000010000003"),
    ("online_goods", "5225SYNTH GOODS                         9876543210WEBONLINE ORD      260626   1091000010000004"),
]

def check(purpose, header):
    assert len(header) == 94, "batch header must be 94 characters"
    sec = header[50:53]          # positions 51-53, Standard Entry Class Code
    desc = header[53:63]         # positions 54-63, Company Entry Description
    if purpose == "wages" and sec == "PPD":
        return desc[:7] == "PAYROLL", desc
    if purpose == "online_goods" and sec in ("WEB", "TEL"):
        return desc.rstrip() == "PURCHASE", desc
    return True, desc

for purpose, header in BATCHES:
    ok, desc = check(purpose, header)
    print(f"batch {header[87:94]}  {purpose:<12}  '{desc}'  {'PASS' if ok else 'FAIL'}")

Output with Python 3.13.1:

batch 0000001  wages         'PAYROLL   '  PASS
batch 0000002  wages         'SALARY    '  FAIL
batch 0000003  online_goods  'PURCHASE  '  PASS
batch 0000004  online_goods  'ONLINE ORD'  FAIL

The purpose comes from the test case, because the file alone cannot show whether a PPD credit is a wage or a pension. Nacha lists pension payments, expense reimbursements, and insurance payouts as payments that do not use "PAYROLL", so the suite includes those purposes too.

Every generated ACH file holds receiver account numbers, so we build these files from synthetic data only. Bank transfers and payment rails testing delivers the file validation suite and return test cases these steps rely on.