The thesis: ACH fraud monitoring now belongs inside the payment workflow.
The lazy reading is that Nacha changed bank compliance. The operationally correct reading is that every business originating ACH payments now needs payment controls that can prove they are risk-based, role-relevant, reviewed, and actually connected to how money leaves the company.
Nacha says the Phase 2 fraud-monitoring amendments were effective June 19, 2026, with the practical effective date moved to Monday, June 22, 2026 because June 19 was a federal holiday. Phase 2 covers the remaining non-consumer Originators, Third-Party Service Providers, Third-Party Senders, and RDFIs that were not in Phase 1.
The rule language is deliberately not a product checklist. It requires risk-based processes and procedures "reasonably intended to identify" suspicious ACH entries. That is exactly why CFOs and controllers should not wait for a bank to hand them a template. The evidence has to come from the systems where payees, approvals, files, returns, and exceptions are created.
What changed, exactly.
Nacha's public summary lists March 20, 2026 for Phase 1 fraud monitoring by ODFIs, large Originators, TPSPs, TPSs, and large RDFIs, plus new Company Entry Descriptions for PAYROLL and PURCHASE. It lists June 22, 2026for fraud monitoring by all other covered Originators, TPSPs, TPSs, and RDFIs.
The Phase 2 page is more specific: all non-consumer Originators, Third-Party Service Providers, and Third-Party Senders that did not meet Phase 1 thresholds must establish and implement risk-based processes and procedures intended to identify ACH entries initiated due to fraud. RDFIs get a parallel credit-monitoring obligation for incoming credit entries.
Nacha also defines the problem domain in practical finance language. The rule discussion includes False Pretenses, covering scenarios such as business email compromise, vendor impersonation, payroll impersonation, payee impersonation, and account-takeover-related unauthorized credits. Those are not abstract banking cases. They are AP, payroll, procurement, HR, treasury, and ERP master-data cases.
Why the ERP is the right control point.
ACH is a batch, store-and-forward network. By the time a bank receives a file, the company has already decided who gets paid, which account receives funds, who approved the release, which invoices or payroll runs were included, and whether any exception was ignored. A bank can detect anomalies. The ERP can prevent many of them from becoming payment instructions in the first place.
That does not mean the ERP must do everything. Banks, payment hubs, treasury workstations, payroll providers, and third-party senders all have roles. But a mature control design starts with one canonical payment command. Every downstream system should enrich, transmit, monitor, acknowledge, or return that command. None should create an unaudited side path for money movement.
The data model finance actually needs.
Most payment-control failures are not caused by missing dashboards. They are caused by missing lineage. The payment file exists, the vendor exists, the invoice exists, and the approval exists, but nobody can prove which version of each fact created the ACH entry that left the bank account.
Example ACH payment-command record
{
"payment_command_id": "paycmd_01k1e8ach2026",
"entity_id": "us_parent",
"payment_rail": "ACH",
"sec_code": "CCD",
"company_id": "1234567890",
"company_entry_description": "VENDORPAY",
"receiver_type": "vendor",
"receiver_id": "vendor_48291",
"bank_account_version_id": "acctver_2026_06_28_002",
"amount_minor": 1842500,
"currency_code": "USD",
"source_documents": ["bill_10491", "bill_10508"],
"risk_signals": [
{ "type": "NEW_BANK_ACCOUNT", "age_days": 4, "score": 45 },
{ "type": "AMOUNT_ABOVE_VENDOR_BASELINE", "score": 28 }
],
"fraud_monitoring_decision": "REVIEW_REQUIRED",
"approval_chain": ["ap_manager", "controller"],
"ach_file_hash": "sha256:42a1...",
"bank_acknowledgement_id": "fedach_ack_763819",
"evidence_ref": "s3://payment-evidence/2026-07/paycmd_01k1e8ach2026/"
}The key design choice is versioning. A vendor account is not a string on the vendor record; it is an effective-dated account version with a verification trail. A payment batch is not a PDF approval; it is a locked set of payment commands with a file hash. A fraud alert is not an email; it is an exception case that changes the release state or records why release was still appropriate.
Control design for ACH fraud monitoring.
| Risk | Control | Evidence |
|---|---|---|
| Vendor bank change | Route all supplier account changes through a controlled master-data workflow with out-of-band verification and payment hold logic. | Change request, verified contact method, account-validation result, approver, effective date, released-by user. |
| Payroll direct-deposit change | Separate employee self-service edits from payroll-release approval; flag first payroll after account change. | Employee change event, MFA status, payroll reviewer sign-off, first-run exception review. |
| First payment to a new account | Require a risk score before ACH file generation and force higher-friction review for first-time payees or dormant payees. | Risk score inputs, exception decision, release timestamp, payment batch ID. |
| Payment file changed after approval | Lock ACH batch contents after approval; any regenerate action invalidates prior approval and restarts review. | Original file hash, regenerated file hash, approval reset, reason code, user trail. |
| Third-party sender dependency | Define by contract which fraud-monitoring controls live in the ERP, payment hub, bank portal, and TPSP; verify evidence annually. | Responsibility matrix, SOC report mapping, test results, annual review memo. |
| RDFI or bank inquiry | Preserve enough payment lineage to answer account, receiver, SEC code, company ID, addenda, approver, and source-document questions quickly. | ACH file record, payment instruction, vendor/payroll source, GL entry, communication log. |
| False-positive fatigue | Tune rules with feedback loops rather than blanket suppression; false positives should be dispositioned, not deleted. | Alert disposition, reviewer notes, suppression rule owner, tuning history. |
The control owner cannot be reduced to treasury. AP owns supplier identity and invoice release. Payroll owns employee bank changes. Treasury owns funding, bank connectivity, and returns. Controllership owns GL completeness and reconciliation. IT owns integration integrity. Internal audit owns whether the process is designed, operating, and reviewed at the required cadence.
Implementation checklist for finance operators.
Inventory every ACH origination path: ERP payment run, payroll provider, expense platform, treasury workstation, bank portal upload, API, and third-party sender.
Classify ACH flows by risk: vendor payments, payroll, tax payments, customer refunds, intercompany funding, collections, and one-off emergency disbursements.
Create a single payment-command object before file generation so every channel carries the same payee, account, approval, risk, and evidence fields.
Enforce bank-account change controls before the payment run, not as a report after the NACHA file has already been transmitted.
Hash and retain generated ACH files, approvals, source invoices, bank acknowledgements, returns, and exception decisions in one evidence packet.
Add annual control review as a calendarized finance operation with test cases for vendor impersonation, payroll diversion, account takeover, and duplicate release.
Make third-party sender oversight concrete: map their controls to your payment lifecycle and retain proof that the allocation is reasonable.
Test response playbooks for suspect payments: stop release, contact bank, contact payee, request return, freeze vendor record, and document final disposition.
Start with paths, not tools. If a vendor payment can originate from invoice automation, an ERP batch, a bank portal upload, and an emergency treasury process, then all four paths need the same control vocabulary: payee version, risk decision, approval state, file hash, bank response, and case record.
Audit evidence is the product.
Nacha's resource center says the 2026 rule changes are neutral about the exact methods or technologies used to identify fraudulent credit transactions. It gives examples such as velocity checks, anomaly detection, behavioral tolerances, and pattern recognition. That neutrality is useful, but it creates a documentation problem: finance must show why its controls are reasonable for its payment flows.
The annual review should not be a meeting note. It should include transaction samples, alert samples, account-change samples, third-party sender evidence, false-positive analysis, missed-event analysis, rule changes, owner sign-off, and open remediation. If the company uses a bank or payment provider for anomaly detection, keep the bank evidence next to the ERP payment command, not in a separate compliance folder.
Failure modes that will show up after the first bad payment.
Assuming the bank owns the problem because the ACH file eventually leaves the ERP.
Letting vendor-bank updates bypass AP controls through imports, support tickets, or integration syncs.
Approving a payment batch before the final file exists, then allowing silent regeneration.
Treating payroll account changes as HR profile edits rather than payment-instruction changes.
Using anomaly detection that cannot explain which source fact, account change, or approval made a payment risky.
Relying on a third-party sender without contractually clear control ownership and retrievable evidence.
Keeping return reports, bank portal alerts, vendor files, and GL postings in separate systems with no case ID.
The most expensive failure is not a false positive. It is a real suspect payment that nobody can reconstruct. If the ERP cannot answer who changed the bank account, who approved the payment, what file line was transmitted, what the bank returned, and how the GL was affected, the company has a control gap even if every individual system has logs.
What ERP buyers should ask vendors now.
Can every ACH payment, regardless of UI, API, import, or scheduled batch, flow through one canonical payment-command path?
Can the ERP block or risk-score a payment when the payee account changed recently, the payee is new, the amount is atypical, or the approver changed?
Does file generation create immutable hashes, batch IDs, and line-level traceability back to invoices, payroll runs, employees, vendors, and GL entries?
How are third-party sender controls represented in the product: as evidence attachments, workflow gates, API callbacks, or manual compliance notes?
Can finance disposition alerts with reason codes and use those outcomes to tune the monitoring model without deleting the audit trail?
A credible answer will mention state machines, versioned payee accounts, immutable file hashes, exception disposition, idempotent payment APIs, bank acknowledgement ingestion, return handling, and annual review evidence. An answer centered on "we export NACHA files" is not enough.
Market signals.
These public X posts are useful as timing and implementation-context signals. The operative claims in this article rely on the cited Nacha, Federal Reserve, ACH operator, developer-guide, and AFP sources.
Nacha post on 2026 rule technology and anomaly-detection context
Nacha post on preparing for 2026 fraud rules
Federal Reserve Financial Services post on FedDetect and Nacha 2026 rules
Practical takeaway.
Nacha 2026 should force finance teams to stop treating ACH as a file export. ACH is a controlled money movement workflow. The ERP needs to know which payee account version was used, why the payment was considered normal or abnormal, who approved it, what file was transmitted, what the bank said, what exception was dispositioned, and how the accounting records tie back. Build that payment-command layer once, then let banks and third-party providers enrich it. Anything else turns fraud monitoring into a forensic exercise after the cash is gone.
Sources.
- Nacha: Risk Management Topics - Fraud Monitoring Phase 2
- Nacha: Summary of Upcoming Rule Changes
- Nacha: Credit-Push Fraud Monitoring Resource Center
- Federal Reserve Financial Services: FedACH tools and 2026 Nacha risk management rules
- Nacha ACH Developer Guide: How ACH Works
- The Clearing House: ACH Services from EPN
- Association for Financial Professionals: 2026 Payments Fraud and Control Survey Report