Nacha Fraud Monitoring Phase 2 Controls

If you originate ACH credits or debits as a lender, servicer, payroll provider, or payments company, the important change is simple. Since June 2026, Nacha expects you to have a documented, risk-based process to identify entries that look fraudulent or were authorized under false pretenses, and to review that process at least annually.

For most operators, that does not mean buying a black-box fraud tool and hoping it satisfies a bank questionnaire. It means being able to show who changed a bank account, when they changed it, how you verified the change, whether the first payment was held or reviewed, what your normal payment patterns look like, and who signed off on the annual review. If you cannot produce that evidence from your own systems, you are likely not ready for an ODFI review.

This is an operations guide, not a legal opinion, so your counsel and ODFI should confirm how the rule applies to your specific program. In this guide, we translate the rule into controls, a payee change log, payment baselines, and the evidence an ODFI will ask to see.

What Changed in Nacha Fraud Monitoring Phase 2

Phase 2 extended the fraud-monitoring requirement to all remaining non-consumer Originators and Third-Party Senders, regardless of volume. Phase 1 covered larger organizations first, and Phase 2 brought in the rest of the non-consumer population.

• Phase 1 took effect March 20, 2026 for non-consumer Originators and Third-Party Senders with 6 million or more ACH originations in 2023.
• Phase 2 took effect June 19, 2026, with a practical compliance date of June 22 and no volume threshold.

The Nacha standard is risk-based. That matters because it does not prescribe one mandatory tool or one exact report. It asks for processes reasonably intended to identify entries that are unauthorized or were authorized under false pretenses. The Jack Henry summary of the rule quotes the new definition, which covers a payment induced by someone misrepresenting their identity, their authority to act for another person, or the ownership of an account to be credited. In plain English, that is a transaction the user approved because they were tricked or impersonated.

The rule also does not shift liability for ACH fraud by itself, and it does not require you to stop every payment before it runs. It requires controls that fit your business model and evidence that those controls are operating. We treat that evidence as the real deliverable.

Translate the Rule Into Controls You Can Actually Run

The easiest way to fail this rule is to treat it as a policy problem. The controls have to sit in the places where bank details and payment instructions actually change, which means the servicing system, the payroll workflow, the exceptions queue, the bank portal, and the spreadsheet someone uses when operations is busy.

The table below maps the rule to the controls most lenders and payments operators need.

Commentary on the rule points to the same places. A DefenseStorm explainer lists new or changed payment instructions and SEC code among the factors examiners may weigh, and a Sardine write-up adds transaction velocity and historical account behavior. That is a strong clue about where we would expect auditors and ODFIs to look first.

The Payee Change Log Is the Artifact That Matters

Most ACH fraud in smaller operating teams starts with a payment instruction change. A vendor emails new banking details. A payroll contact asks for a direct deposit update. A borrower or tenant claims they changed accounts and needs the next payment routed differently. If those changes live in email and spreadsheets, you have no reliable control record.

What you need is a payee change log that becomes the system of record for the control, even if the payment itself still flows through a core system or bank portal.

Minimum Fields to Record

• Payee or customer identifier
• Old bank account reference and new bank account reference
• Who requested the change
• Channel used to request it, such as portal, phone, email, or signed form
• Verification method used, such as callback, known-contact confirmation, or dual approval
• Who performed the verification
• Timestamp of request, verification, and effective change
• Status of the first payment, held, reviewed, or released automatically
• Who approved release if a hold was applied
• Any exception or override reason

This log is the difference between saying “we check bank changes” and proving it. It also lets you answer the most common fraud question. If a payment went to the wrong account, who changed the instructions and who signed off on the change?

That matters in business email compromise, where an attacker impersonates a vendor or executive, and in payroll diversion, where an employee or contractor’s direct deposit is redirected. In both cases, the weakness is usually not the ACH file. It is the change process upstream of the file.

Build Baselines From Your Own Payment History

The Nacha risk-based standard does not mean “watch for anything unusual” in the abstract. It means define what normal looks like for your own program, then compare new activity against that baseline.

For a lender or servicer, the right baseline is usually local to the payee and the transaction type. A vendor who gets paid twice a month for roughly the same amount should look different from a borrower repayment stream that varies with delinquency or a payroll file that spikes on pay cycle days. A new payee should be treated differently from a long-standing payee with stable history. A dormant payee that suddenly reactivates should also get extra review.

A practical way to do this is to baseline by:

• Payee
• Customer or account
• SEC code, the ACH standard entry class code that describes the payment type
• Amount range
• Payment cadence
• Change history

As an illustrative example, if a vendor normally receives two ACH credits per month in the low thousands, a request to move the bank account and immediately accelerate the next payment to a much larger amount should trigger review. You do not need a perfect model to catch that. You need a rule that compares the new request to the vendor’s own pattern and forces a human check when the pattern changes.

This is where many teams overreach. They buy a fraud feed that looks impressive but does not know their own payee history. We favor a simpler internal baseline tied to your system of record, because it often produces better control evidence and you can explain it.

What to Show Your ODFI and What to Write in the Annual Review

ODFIs usually want to know two things, namely what controls exist and if they are actually being used. Your annual review should answer the same questions.

We would keep the following evidence ready:

• A short control map showing each fraud-monitoring control and its owner
• The payee change log for a sample period
• Examples of verification records for changed bank instructions
• First-payment hold or review reports
• Baseline or anomaly reports for amount, volume, and cadence
• ACH return-rate monitoring reports and escalation notes
• Training or operating instructions for staff who approve changes
• The annual review memo, dated and signed

The annual review memo does not need to be long. It should say what changed in the program, what incidents or exceptions occurred, how well the controls worked, what gaps were found, and what follow-up actions were assigned. If you had no incidents, say how you know the controls were still tested or observed. For the return-rate line, our post on ACH return rules and monthly reconciliation covers the reconciliation side.

That review is not an audit in the formal sense for most operators. It is a documented management review of the fraud-monitoring process. But if you cannot explain what was reviewed, by whom, and when, it will be hard to satisfy an ODFI asking for evidence.

Where Your Bank Portal and Core System Stop

It is tempting to assume your bank already handles this. Banks do monitor their own exposure, and many offer tools around returns, payee validation, or positive-pay style controls. Those are useful, but they do not replace your own control over the payee data you originate.

The clean division is simple. The ODFI monitors the bank’s side of risk, while you monitor the instruction changes and payment behavior inside your business. If the change starts in your servicing platform, your payroll admin queue, or an operations spreadsheet, the evidence has to live there too.

That is also where a separate internal control layer may be needed. If your core system records the new account but not who verified it, or your bank portal shows the payment but not the reason it was released, you have a gap. A lightweight workflow layer can close that gap without replacing the whole system.

For teams that need to thread this into a larger financial platform, the hard part is usually integration, not policy. We have worked on fintech engineering that handles high-volume transactions under strict regulatory controls in a high-growth setting, including embedded engineering on Valon’s mortgage servicing platform. The lesson is not “build everything.” It is to put the control where the data already moves, so the evidence is created as part of the workflow rather than reconstructed later. That is the approach behind our fintech software development work, and our guide to building a fintech app that banks will trust covers the bank-facing side.

Buy, Build, or Extend What You Already Have

You do not need to custom-build an ACH fraud platform if a treasury tool or vendor service already gives you the records you need. But you should be cautious about tools that only produce alerts and do not preserve the underlying approval trail.

Buying makes sense when:

• You already use a treasury or payables platform that can store verification and approval events
• Your payment workflows are fairly standard
• You mainly need better monitoring and reporting

Building or extending makes more sense when:

• Payment instructions live in your own lending, servicing, payroll, or property-management system
• Your staff still changes bank details through email, ticket notes, or spreadsheets
• You need a payee-level change log and first-payment hold workflow that your current tools do not provide

The build threshold is usually not about scale alone. It is about being able to produce a coherent control record from the systems you already use. If the answer is no, then in our view a small workflow layer, not a big fraud suite, is often the simplest adequate fix.

A Practical Next Step for Nacha Fraud Monitoring

If you want to know if you are ready, start with a simple test. Pick one recent bank-account change and trace it end to end. Can you show who requested it, how it was verified, who approved it, if the first payment was held, and where the record sits today?

If the answer is yes, you likely have the skeleton of a defensible process. If the answer is no, focus first on the payee change log and the release workflow. Those two pieces usually do the most to turn a vague fraud policy into a control you can show. To see how we approach this kind of work, start with Better Software.

Frequently Asked Questions

Who Is Liable for ACH Fraud Under the New Rules?

The Nacha fraud-monitoring rule does not rewrite liability rules by itself. We read it as setting expectations for risk-based monitoring and annual review. Liability for a specific fraud event still depends on the transaction facts, the contracts in place, the ACH rules, and any other applicable law.

How Often Does Nacha Require a Review or Audit to Be Performed?

The rule requires the fraud-monitoring process to be reviewed at least annually. We treat that as a management review of the process and its effectiveness. It is not the same thing as an external audit requirement unless another party, such as your ODFI, imposes one.

Do We Have to Screen Every ACH Entry Before Processing?

No. We do not read the rule as a blanket pre-screening mandate. Nacha requires risk-based processes reasonably intended to identify suspicious or fraudulent entries. For some programs that may mean pre-payment holds for certain changes, and for others it may mean monitoring and escalation after release.

Do We Have to Monitor Every ACH Entry for Unauthorized Activity?

You need a process that fits your role and risk profile, not a one-size-fits-all scanner. We look for a process that is documented, operates on your actual payment flows, and can surface unusual or suspicious activity in time for action.

What Does False Pretenses Mean in the Nacha Rule?

It describes a payment that someone approved because the other party misrepresented who they are, their authority to act for another person, or who owns the account being credited. We read it as covering business email compromise, vendor impersonation, and payroll diversion.