ACH Fraud Detection Methods and Best Practices

Last updated: October 2026

ACH fraud detection methods each test one thing about a payment: whether the account exists, whether the name matches, whether the amount is normal, whether the payee's bank details just changed, who was logged in, what came back, and where the money goes next. No single check covers all of them. This guide takes seven methods in turn and sets out what each one catches, what it misses, and which role and entry type it fits, so an ODFI, an RDFI, an Originator or a Third-Party Sender can build the combination that covers its own exposure.

TL;DR

• No single method covers ACH payment fraud. Each of the seven methods here catches one failure mode and misses others.

• Choose methods by role and entry type. Originators and ODFIs run most of the origination checks; RDFIs run name matching and inbound credit monitoring.

• Account validation proves that an account is open and can accept entries. It does not prove who is behind the account.

• Verify every change to a payee's bank details before the next payment, whatever the amount. Business email compromise and vendor impersonation get through when that step is skipped.

• Run each check as early as the entry allows, and keep a record of what it did. Returns arrive after settlement, and Nacha's rules name no method or product.

How is ACH fraud detected? The short answer

ACH fraud is detected by layering several methods, each matched to the role an institution plays and the type of entry it handles: account validation, name matching, velocity and amount anomalies, payee and destination-change checks, device and session signals on origination, return-rate and return-code analytics, and inbound credit monitoring. Each method catches one failure mode and misses others. The best practice is the combination, run as early in the life of an entry as the entry allows, with a record of what each check did.

Each method runs at a different point in the payment:

• Before the first payment: account validation and payee and destination-change checks.

• When the entry is created: device and session signals, plus velocity and amount rules.

• When the entry arrives: name matching and inbound credit monitoring.

• After settlement: return-rate and return-code analytics.

This guide assumes the basics; for what ACH fraud is and the forms it takes, see our overview of ACH fraud detection and prevention.

Which method fits which role and entry

ACH debit fraud and ACH credit fraud call for different checks, so the table maps each method to what it catches, what it misses, the role that usually runs it and the entries it applies to. Read across a row for a method's limits, and down the Role column for the methods that sit with your institution.

Most of what one method misses, another catches, so the methods are meant to run together.

Both phases of Nacha's fraud monitoring rules are in force: Phase 1 since 20 March 2026 for every ODFI and for the largest non-Consumer Originators, Third-Party Service Providers, Third-Party Senders and RDFIs by 2023 volume, and Phase 2 since 19 June 2026 (in practice 22 June), which removed the volume thresholds. Each originating party must run risk-based processes and procedures, relevant to its role, "reasonably intended to identify Entries that are suspected of being unauthorized or authorized under False Pretenses", RDFIs must do the same for the credits they receive, and every party reviews its processes at least once a year. The rules name no method or product, and an RDFI's monitoring of incoming credits does not have to happen before posting or entry by entry; our explainer on the 2026 Nacha fraud monitoring rules covers who is covered and what changed. What each role has to have in place under those rules is set out in our readiness guide to the 2026 Nacha fraud rules.

Account validation

What it is. Account validation confirms that an account is open and can accept ACH entries before money moves to or from it. Institutions validate with a prenote, with Micro-Entries (ACH credits of less than $1 used to verify a Receiver's account), or through an account validation service.

What it catches. Account validation stops payments to closed, invalid or mistyped accounts the first time those accounts are used. For WEB debits it is also the floor that Nacha's account validation rule sets: since 19 March 2021, an Originator's fraud detection system for WEB debits must at minimum validate the account the first time an account number is used and whenever the account number changes. Nacha's minimum is that the account is open and can accept entries; the rule does not require confirming who owns the account, and it leaves the method to the Originator.

What it misses. Account validation proves that an account exists, and with some services who it is registered to, but not who is behind it. A product manager for treasury account validation services at a large bank described the gap: "they passed account validation. If we had done identity verification? He would have been red flagged instantly."

The identity in that case was synthetic, and the same product manager said fraudsters now understand how routine validation works and are finding ways around it. Micro-Entries have a related limit: a Micro-Entry proves that someone can see the account, so it proves nothing when the fraudster controls the account on the other side. Validation is also one control rather than monitoring, and an SVP of payments at a bank noted that the account verification service the bank already used does not do transaction monitoring by itself.

Where it fits. Account validation belongs with Originators and ODFIs on debits, WEB debits especially, with anyone setting up a new payee before sending credits, and with Third-Party Senders onboarding merchants whose settlement accounts they will pay.

Name matching

What it is. Name matching, also called account name verification, compares the receiver name on an ACH entry with the name on the account the entry is going to. For an RDFI, that means reading the name on the incoming file and checking it against its own customer record.

What it catches. Name matching catches credits headed into an account in someone else's name: diverted payroll, refunds sent to a fraudster's account and deposits feeding mule accounts. A chief compliance officer at a consumer prepaid fintech described name matching on direct deposits as a way to make sure customers are only depositing into their own account. A head of fraud and security at a credit union called name mismatching the team's biggest win, because it stops the payment before it happens.

What it misses. Name matching depends on data. When an Originator or ODFI checks a new payee's name, the check works only where the receiving bank shares account-holder information, and the same credit union fraud head noted that not every bank does. Joint accounts, business names and trade names produce mismatches that are not fraud, so a rule that treats every mismatch as suspicious floods the review queue. A mule account opened in the right name passes the check altogether.

Where it fits. Name matching sits with RDFIs on inbound credits, payroll and direct deposit especially, and with ODFIs and Originators when a new payee is set up. Mule accounts that pass a name check are a job for inbound credit monitoring, covered below.

Velocity and amount anomalies

What it is. Velocity and amount checks are rules, and models built on the same signals, that compare the count, value and timing of entries with an account's or an Originator's own history and stated business.

What it catches. Velocity and amount checks catch bursts of entries, amounts out of line with an Originator's normal file, and credits that do not fit what a customer said it does. A head of fraud prevention at a bank wanted to be told when a new business customer receives an ACH credit far out of line with the business it said it runs, such as a grocery store receiving a construction company's payment.

What it misses. Fraud that keeps the amount normal and changes only the destination looks fine to an amount rule; payee and destination-change checks, below, cover that case. Fraud spread thin stays under any single threshold, and the product manager at the large bank quoted above described distributed fraud where not enough comes through one channel to trigger a red flag, whatever rules are in place. Untuned rules also alert on payments nobody needs to review, as a VP who runs deposit operations and owns fraud at a community bank put it: "if you do a transfer every week at the same time, I don't want that to keep showing up to a fraud team".

Where it fits. ODFIs set limits per Originator, because Originators differ widely. A head of treasury management product at a bank described Originators ranging from pre-funded small businesses with little risk beyond fraud to professional firms, hospitals and universities that move very large amounts every day. Third-Party Senders set limits per merchant and RDFIs per receiving account, because a single network-wide threshold fits none of them.

Payee and destination-change checks

What it is. A payee or destination-change check treats a new payee, or a change to an existing payee's bank details, as an event that needs verification before the next payment goes out, whatever the amount.

What it catches. Payee and destination-change checks are the main control for business email compromise and for vendor and payroll impersonation. Since 1 October 2024, Nacha has defined False Pretenses as the inducement of a payment by someone misrepresenting their identity, their association with or authority to act for another person, or the ownership of the account to be credited, which covers these schemes. Regulators treat the pattern as a fraud signal too: the OCC's July 2026 bulletin on information sharing lists newly added payees followed by large transfers among the fraud indicators institutions may share.

A BSA officer who oversees the BSA and fraud teams at a bank said this is where the bank's business customers are getting hit: "they get an email that says, hey, we changed this or we did this", and nobody checks with the people who could say the change never happened. Repeated changes to the same payee's bank account are a red flag in their own right.

What it misses. A callback to the phone number in the fraudulent email confirms nothing, so payee verification has to use a contact already on file. A payee's first payment has no history to compare against. A payment sent by a fraudster who has taken over the customer's online banking is unauthorized rather than False Pretenses, and session and device signals are the control for that case.

Where it fits. Payee and destination-change checks belong with Originators' accounts payable and payroll teams, with the ODFI's treasury management team that supports those Originators, and with Third-Party Senders whose merchants change payout accounts.

Device and session signals on origination

What it is. Device and session checks examine the online or business banking session, and the device behind it, before an entry is built into a file.

What it catches. Device and session signals catch account takeover before origination. The same credit union fraud head described the common path: customers give out one-time passcodes, fraudsters log in, and once inside online banking they can send ACH and wire transfers and see account numbers. When an entry is flagged, a VP, compliance and BSA officer who also owns fraud at a bank described reviewing the session in the online banking platform for anything curious, then the device and fingerprint data, to judge whether the activity is legitimate.

What it misses. A takeover on the customer's own device looks normal, and the credit union fraud head noted that the IP address and device details then match the customer's usual ones. Entries that arrive in a file transmitted by an Originator or a Third-Party Sender carry no session for the ODFI to inspect. A customer coached by a scammer into sending a payment is authorized rather than taken over, and the session is genuine.

Where it fits. Device and session signals belong with ODFIs for entries created in online and business banking, and with the portals Originators and Third-Party Senders use to build files.

Return-rate and return-code analytics

What it is. Return analytics, or ACH return rate monitoring, watch returns by Originator, merchant and reason, and act on the trend rather than on a single return.

What it catches. Return analytics find Originators and merchants whose unauthorized or administrative returns are climbing. Nacha's unauthorized return rate threshold is 0.5% of debit entries, and its administrative (3.0%) and overall (15.0%) return rate levels trigger a preliminary inquiry rather than an automatic violation, all measured over the preceding 60 days or two calendar months. What each return code means, and which codes count toward each threshold, is covered in our guide to ACH return codes. Since 1 October 2024, an RDFI that believes an entry was fraudulent or sent under False Pretenses may also return it with R17 and the descriptor QUESTIONABLE, within the standard return timeframe.

Returns are also how a team measures a change. A head of product at a pay-by-bank fintech wanted to see a rule set's effect as the payment acceptance rate and the return rate before the rules went in, and again after. At many banks the treasury management team that onboards and trains Originators is the one that receives their return codes, as a VP of operations at a community bank described, so that team needs the analytics as much as the fraud team does.

What it misses. Return analytics are late, because returns arrive after settlement, when the money has already moved. Returns do not always close the loss either: the deposit operations VP quoted above noted that a customer can still file a dispute after the money has gone back to the account, and collect twice.

Where it fits. Return analytics belong with ODFIs and Third-Party Senders monitoring their Originators and merchants, and with Originators monitoring their own debits.

Inbound credit monitoring

What it is. Inbound credit monitoring screens incoming credits for accounts that receive money and move it on, before or soon after the funds are made available.

What it catches. Inbound credit monitoring catches new accounts used as pass-through accounts and credits into mule accounts. The same deposit operations VP described new accounts being used this way before the bank had a fraud team, and said that without insight into the ACH files and the ability to act on them, the institution takes the loss. The response has to stop the money, as the credit union fraud head put it about a suspicious incoming payment: "Do something with it. Don't give me an alert."

Some institutions also change when funds are released. An SVP and director of fraud risk management at a bank described moving deposits from immediate to next-day funds availability, a decision taken for fraud risk reasons.

What it misses. Once funds leave, recovery is slow. The BSA officer who oversees the BSA and fraud teams, quoted above, said ACH moves too fast for the bank to get money back, and described finally reaching the receiving bank and sending the forms, only to find almost nothing left in the account. A mule account can also look like a normal customer for a while before it is used.

Reaching the other institution quickly matters. FinCEN's updated Section 314(b) Fact Sheet of 12 June 2026 clarifies that financial institutions may share information about suspected fraud, including in real time, under section 314(b). Detecting the mule accounts themselves is a wider problem, and our guide sets out what to require from a mule account detection platform.

Where it fits. Inbound credit monitoring sits with RDFIs, all of them since Phase 2, and each RDFI also needs procedures for what it does with the credits it flags.

Batch or real time: when each method can run

Nacha's rules do not require real-time monitoring, but prevention depends on acting before settlement and before funds are available. An SVP and director of deposit and branch operations at a bank welcomed the fact that the rule does not demand real time, and added that the goal was still to prevent fraud. A check that runs before the file leaves can stop a payment; a check that runs after settlement can only start a recovery.

Many institutions still work in batches. The VP, compliance and BSA officer mentioned above described the end of the day this way: "we scramble at that end of the day to try and, you know, figure out what is or is not bad" and then pull entries out of the ACH file before it leaves at settlement. Real time on origination means reaching the entry before it becomes a file, and the same SVP of deposit and branch operations pointed out that this needs an integration with the online banking platform.

The earlier a method runs in this sequence, the more of the loss it can still prevent.

Best practices for combining the methods

The ACH fraud prevention best practices below concern how the methods fit together.

1. Start from your role and entry types. An ODFI whose Originators send WEB debits starts with account validation and return analytics; an RDFI that receives a large share of payroll and direct deposit starts with name matching and inbound credit monitoring. No method on its own is a monitoring program.

2. Layer methods so each covers another's blind spot. Account validation does not show whose account it is, so add name matching. Amount rules miss a changed destination, so add payee and destination-change checks. Device signals miss entries that arrive in a file, so watch those Originators through velocity rules and returns.

3. Tune for noise before adding rules. The aim, in the words of the SVP of deposit and branch operations, is to make sure "we're preventing fraud and not stopping a ton of transactions". Codes that look suspicious are often wrong for ordinary reasons: the same SVP said many of the bank's clients use the wrong code for reasons that have nothing to do with fraud, probably because they do not use the dropdown. Our guide to cutting false positives without raising losses goes further.

4. Review Originators, not only entries. The same SVP said the bank was not really reviewing Originators for fraud, and relied on allowing only PPD and CCD originations. Restricting entry types limits exposure, but a periodic review of each Originator's returns, volumes and payee changes is what finds the one that has gone wrong.

5. Measure every change before and after. Track return rates and approvals of good payments before and after each new rule, and keep the record of which checks ran, what they flagged and what changed. Nacha requires originating parties and RDFIs to review their fraud monitoring processes at least once a year, and that record is the evidence the review needs.

6. Score the indicators that recur across methods. No single indicator proves fraud, but these are worth checking on every entry:

   • first use of an account number;

   • a new payee, or a change to a payee's bank details;

   • a receiver name that does not match the account;

   • credits out of line with a customer's stated business;

   • a new account that receives money and moves it on quickly;

   • rising unauthorized returns for an Originator;

   • a new device or session behind an origination.

If you are choosing software to run these checks, our guide to the best ACH fraud detection software sets out the criteria to compare.

Gaps that recur across institutions

• Validation treated as monitoring. An account that passed validation at setup is not checked again when its use changes.

• Changes verified through the request itself. A new bank account is confirmed by replying to the email, or calling the number, that announced it.

• One threshold for every Originator. A network-wide limit flags the large, steady Originator and misses the small one that has changed.

• Alerts without a hold. A flagged credit is reviewed after the funds were already available.

• Returns as the only signal. By the time the return rate moves, the money has settled.

Where Oscilar fits

Oscilar is a Nacha Preferred Partner for Account Validation, Fraud Monitoring, and Risk and Fraud Prevention. Oscilar's approach is a unified platform: real-time data fabric, device and behavior intelligence, rules, and case management in one stack. The signals behind a decision, the rules that act on them and the case record an analyst works from sit in one system. As published on oscilar.com, "Fluz implemented Oscilar's platform and achieved a 20% increase in ACH approval rates".

For a plan to build the monitoring program these methods belong to, phase by phase, read the 2026 ACH risk operations playbook.

Frequently asked questions

What are good indicators of risky accounts in ACH workflows?

Seven indicators recur: first use of an account number, a new or changed payee, a receiver name that does not match the account, credits out of line with a customer's stated business, a new account that receives money and moves it on quickly, rising unauthorized returns for an Originator, and a new device or session behind an origination. Each is weak alone and strongest when scored together on the same entry, before funds move.

How can treasury teams detect ACH payments authorized under false pretenses?

Treasury teams detect False Pretenses payments by treating every new payee, and every change to a payee's bank details, as an event that needs verification before the next payment, whatever the amount. The verification has to use a contact already on file, never the details in the request. Since 1 October 2024, Nacha has defined False Pretenses as a payment induced by someone misrepresenting their identity, their authority to act for another person, or the ownership of the account to be credited, which covers business email compromise and vendor and payroll impersonation.

How should companies monitor ACH payments for vendor impersonation?

Companies monitor for vendor impersonation by keeping a verified record of each vendor's bank details, holding the first payment after any change until someone confirms it through a known contact, and watching for repeated changes to the same vendor's account. A new payee followed by a large payment deserves a second look; the OCC's July 2026 bulletin lists newly added payees followed by large transfers among the fraud indicators institutions may share. A bank's treasury management team can reinforce the habit when it onboards and trains business customers as Originators.

How is ACH fraud investigated?

An ACH fraud investigation starts with the entry and the accounts on both sides, then moves quickly to the other institution: FinCEN's June 2026 Section 314(b) Fact Sheet clarifies that financial institutions may share information about suspected fraud, including in real time. Since 1 October 2024, an RDFI that believes an entry was fraudulent or sent under False Pretenses may return it with R17 and the descriptor QUESTIONABLE, within the standard return timeframe. In September 2026 five agencies clarified that SAR confidentiality does not stop an institution from talking to a customer about potentially fraudulent transactions or an account closure, provided it does not reveal that a SAR exists. Those are the agencies' statements, not legal advice; each institution applies them through its own counsel and procedures.

Does account validation stop ACH fraud?

No. Account validation confirms that an account is open and can accept entries, and it stops payments to closed, invalid or mistyped accounts. It does not confirm who is behind the account, so a synthetic identity or a mule account can pass it. Pair validation with name matching, payee and destination-change checks, and monitoring of how the account is used.

Do the Nacha rules require real-time ACH fraud monitoring?

No. The rules require risk-based processes and procedures reasonably intended to identify entries that are unauthorized or authorized under False Pretenses, and an RDFI's monitoring of incoming credits does not have to happen before posting or entry by entry. Real time matters for prevention rather than for compliance: a check that runs before the file leaves or before funds are available can stop a payment, while one that runs after settlement can only start a recovery.