Nacha fraud monitoring phase 2: what operators need to build

If you originate ACH credits or debits as a lender, servicer, payroll provider, or payments company, the important change is simple: since June 22, 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.

Not legal advice: this is an operations guide, not a legal opinion. Your counsel and ODFI can confirm how the rule applies to your specific program.

What changed in Nacha phase 2

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

• Phase 1: took effect in 2025 for larger non-consumer Originators and Third-Party Senders.
• Phase 2: took effect June 22, 2026, with no volume threshold.

Nacha’s 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 - in plain English, a transaction the user approved because they were tricked, impersonated, or otherwise manipulated.

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.

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: 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.

• Nacha language: identify entries unauthorized or authorized under false pretenses
  Control: verify any new or changed bank account out of band before first use
  Evidence: verification method, verifier, timestamp, and approval record
  Owner: operations or risk
• Nacha language: risk-based process
  Control: maintain baselines for normal payment behavior by payee, customer, and SEC code
  Evidence: periodic exception reports and baseline assumptions
  Owner: payments operations or data
• Nacha language: identify potentially fraudulent entries
  Control: hold or review the first payment to a new account, changed account, or newly reactivated payee
  Evidence: hold status and release approval
  Owner: operations
• Nacha language: risk-based process for Third-Party Senders and TPSPs
  Control: monitor volume, velocity, amount, and SEC-code patterns across the program
  Evidence: anomaly reports and escalation logs
  Owner: risk or compliance
• Nacha language: ongoing review
  Control: monitor ACH return rates and unusual return codes, then escalate outliers
  Evidence: monthly return-rate review and follow-up actions
  Owner: treasury, operations, or compliance
• Nacha language: risk-based process documented and reviewed annually
  Control: formal annual review memo with changes, incidents, and control gaps
  Evidence: dated review, approver, and action items
  Owner: compliance or control owner

Nacha has specifically pointed to change controls on vendor and payroll payment instructions as a good fit for Originators, and to volume, velocity, amount, and SEC-code review for Third-Party Senders and their service providers. That is a strong clue about where auditors and ODFIs will 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
• Whether the first payment was 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

Nacha’s 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

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. A simpler internal baseline tied to your system of record often produces better control evidence because you can explain it.

What to show your ODFI and what to write in the annual review

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

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, whether 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.

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 this: 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. Better Software has described fintech engineering work 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. Fintech software case study

Buy, build, or extend what you already have

You do not need to custom-build a 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 whether you can produce a coherent control record from the systems you already use. If the answer is no, then a small workflow layer, not a big fraud suite, is often the simplest adequate fix.

A practical next step

If you want to know whether 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, whether 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.

FAQ

Who is liable for ACH fraud under the new rules?

Nacha’s fraud-monitoring rule does not rewrite liability rules by itself. It sets 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. That is a management review of the process and its effectiveness. It is not the same thing as an external audit requirement unless another party imposes one.

Do we have to screen every ACH entry before processing?

No blanket pre-screening mandate is the wrong way to read the rule. 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; 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 is appropriate to your role and risk profile, not a one-size-fits-all scanner. The key is that the process must be documented, operate on your actual payment flows, and be capable of surfacing unusual or suspicious activity in time for action.