ACH Funding Fraud
Funding a brokerage, neobank or fintech account by ACH debit from a bank account the actor doesn't own or will dispute, then extracting value before the return arrives.
What it is
ACH funding fraud exploits the gap between when a platform lets money be used and when the ACH network can still take it back. A pull (debit) from an external account is the most common way to fund a brokerage or neobank account. Like a card payment, it is initiated by the party receiving the value. Unlike a card, there is no real-time authorization from the paying bank and no issuer fraud screen. The platform, as Originator (through its ODFI), warrants that the debit was authorized, and eats the loss when it wasn't.
Three distinct populations commit it, and they need different controls:
| Population | Owns the funding account? | Typical return | What actually stops it |
|---|---|---|---|
| Third-party, using ATO of the victim's bank login or stolen account and routing numbers | No | Unauthorized (R10, R05, R11) after the victim sees their statement | Bank Account Ownership Verification; closed-loop withdrawals |
| Mule / synthetic, a real bank account controlled by the fraud operation, linked to a fintech account under the same or a fabricated identity | Yes (on paper) | NSF or account closed after value is out; or later unauthorized claims | Exposure limits and holds; Entity Link Analysis; account aging |
| First-party, where the genuine customer debits their own account, uses the value, then disputes or lets it bounce | Yes | Unauthorized (R10) via their bank, or NSF (R01) | Holds sized to history; Dispute and Return History; recovery and offboarding |
Ownership verification is powerful against the first row and close to irrelevant against the other two. Many programs over-invest in it and under-invest in exposure management.
Related but distinct: Instant Funding Abuse (Kiting) is the exposure-window economics of any provisional credit (ACH, check, card); this note focuses on the ACH rail itself. Payout Redirection is the outbound mirror image (ACH credits to an account that isn't the customer's).
How it works
Conceptually, the actor acquires a usable funding account (stolen credentials, account numbers, a mule's account, or their own), links it to a fintech account, initiates a debit, waits only as long as the platform requires before value is usable, and extracts it. The return arrives after the value is gone.
The two return windows
Nacha return timeframes define the platform's exposure horizon (EPCOR return code resource):
| Return family | Common codes (conceptual meaning) | Timeframe | What it tells you |
|---|---|---|---|
| Administrative / account data | R02 closed, R03 no account, R04 invalid number | 2 banking days | Account wasn't real or usable; often a validation failure |
| Funding | R01 insufficient funds | 2 banking days | Account real, money absent; common in kiting and first-party |
| Consumer unauthorized | R10 not authorized / originator unknown, R11 not per authorization terms, R05 consumer debited with a corporate SEC code, R07 authorization revoked | 60 calendar days | The account holder says they didn't authorize it; third-party fraud or first-party denial |
| Corporate unauthorized | R29 | 2 banking days | Business account holder says not authorized |
| RDFI-initiated | R16 frozen, R17 questionable circumstances | 2 banking days | Receiving bank flagged the entry itself |
Since the October 1, 2024 risk management rules, RDFIs may use R17 (with the descriptor QUESTIONABLE) to return an entry they believe was unauthorized or made under False Pretenses; the 2026 fraud monitoring rules point RDFIs to that option for flagged credits (Nacha, Risk Management Topics (Oct 1, 2024); Nacha, Fraud Monitoring Phase 1). See Nacha Rules and ACH Risk.
The 60-day consumer window is measured from settlement, so an exposure tail exists well after a platform has "settled" a deposit and released the funds. And because Regulation E gives consumers 60 days from the statement to report unauthorized transfers (CFPB, 12 CFR 1005.6), a victim's bank can still be obligated to the consumer after the ACH return window has closed. At that point recovery moves outside the network.
Transaction footprint
| Stage | What you see in the data | Decision point |
|---|---|---|
| Account opening | New account; identity elements that don't fit together; device or contact data shared with other accounts | Onboarding risk tier sets funding limits |
| Bank link | Link method (credential-based vs. manual account and routing entry vs. micro-deposits); name on bank account vs. customer name; bank account age and balance (when available); same bank account linked to many platform accounts | Ownership and quality check; reject, limit or step up |
| First deposit | Amount large relative to declared income, account balance or tenure; deposit immediately after link; many deposits in a short window | Availability decision: how much is usable now vs. after the return window ages |
| Use of funds | Instant withdrawal attempt; P2P send to new counterparty; card spend on resale goods; crypto purchase and on-chain withdrawal; securities buy then sell then withdraw | Exit decision: is this value backed by settled, aged funds? |
| Withdrawal destination | Withdrawal to a different bank than the funding source; recently added destination | Closed-loop rule: withdraw only to the funding source while funds are unaged |
| Return | Return code, days since settlement, amount vs. balance | Recovery: restrict account, debit other balances, liquidate positions, collections |
| Post-return | Same identity, device or bank account reappears | Negative Lists and Deny Lists; Graph Analytics |
Almost every ACH debit will be "approved", because the network doesn't authorize in real time. The fraud decision that matters is how much of the credit to let the customer use, for what, and when.
Common variants
| Variant | What's different | Where it shows up |
|---|---|---|
| Bank ATO funding | Fraudster logs into victim's bank via a credential-based link and pulls funds into their own fintech account | Brokerages, neobanks, crypto |
| Account-number funding | Stolen account and routing numbers entered manually; validation confirms the account exists but not who owns it | Platforms allowing manual entry |
| Mule-funded bust-out | Real accounts with little money; deposits made available instantly, value out, R01 returns | Neobanks, P2P, brokerages with instant buying power |
| First-party unauthorized claim | Customer pulls from own account, spends, then tells their bank it was unauthorized | All; see First-Party Fraud |
| Multi-platform kiting | The same bank account funds several fintechs at once, each extending provisional credit | See Instant Funding Abuse (Kiting) |
| ATO at the fintech | Attacker takes over a fintech account, links a new external bank, and redirects withdrawals | See Account Takeover (ATO), Payout Redirection |
| Pay-by-bank merchant fraud | Goods ship on an ACH debit that later returns unauthorized | Ecommerce and marketplaces using bank payments |
| Credit-push abuse (receiving side) | ACH credits under False Pretenses (payroll or vendor impersonation) land in mule accounts | RDFIs; neobanks receiving fraudulent credits |
Where it shows up
- Brokerage and Investing: ACH is the dominant funding rail. Brokerages often extend instant buying power before settlement, so a customer can trade immediately. Exit paths include withdrawal after the sale, options or leveraged positions that magnify loss, and ACATS transfers out. If the deposit returns, the broker may have to liquidate positions, taking market risk as a second loss on top of the fraud. A brokerage's exposure is deposit amount + adverse market movement.
- Neobanks and Consumer Fintech: external account "add money" plus instant availability plus a debit card and P2P means value can leave in minutes. Neobanks also receive ACH credits as RDFIs, so the Nacha 2026 credit-monitoring rules apply to them on the receiving side.
- Payments and P2P: wallet funding by ACH, then P2P out. The receiving P2P user may be a mule; see Real-Time Payment Rail Fraud.
- Cashback, Coupons and Rewards: usually push-only (ACH credits for payouts), so ACH funding fraud is rare. The analogous risk is paying out to bank accounts that don't belong to the account holder (see Payout Redirection and Loyalty and Rewards Redemption Fraud).
- Retail and Ecommerce and Online Marketplaces: pay-by-bank is growing; merchants who ship before the unauthorized window ages carry the same exposure a brokerage does, without the balance to offset it.
Impact
- Direct loss: negative balances after returns, net of recovery. First-party and mule losses are often booked as operational or credit loss rather than fraud, which hides the true rate (see Loss Taxonomy and Attribution).
- Network standing: an Originator's unauthorized return rate (R05, R07, R10, R11, R29, R51) above 0.5% triggers ODFI inquiry and potential enforcement; administrative returns (R02–R04) above 3.0% and overall returns above 15.0% trigger inquiries (Nacha: ACH Network Risk and Enforcement; Nacha unauthorized return rate guide). For a fintech, losing its ODFI relationship is an existential risk.
- Victim harm: third-party victims lose access to funds until their bank resolves the claim.
- Downstream: funds extracted via ACH fraud frequently move through Money Mules and can trigger SAR obligations; see BSA-AML and SAR Filing.
Red flags
- Name on the bank account doesn't match the customer; bank account linked to multiple platform accounts → Funding Source Signals, Identity Element Consistency
- New account, new bank link, large first deposit, immediate withdrawal attempt → Customer Tenure and History, Fast In Fast Out Patterns
- Withdrawal destination differs from funding source, or was added just before the withdrawal → Account Change Events
- Many deposits from one bank account across accounts, or many bank accounts per user → Velocity Signals, Entity Link Analysis
- Devices, IPs or contact details shared with previously returned accounts → Device Reputation and Linkage
- Prior returns or disputes on the customer or bank account → Dispute and Return History
Prevention and detection at a glance
| Layer | Control or signal | What it does here |
|---|---|---|
| Prevent | Bank Account Ownership Verification | Confirms the customer owns the funding account; strongest against third-party fraud, weak against mules and first-party |
| Prevent | Velocity and Exposure Limits | Caps how much unaged ACH credit any customer can use; scale by tenure and history |
| Prevent | Funds Availability Holds | Delays usable funds or restricts what they can be used for |
| Prevent | Withdrawal and Payout Controls | Closed-loop withdrawals; holds on new destinations |
| Detect | Real-Time Transaction Risk Scoring | Scores the availability and exit decisions, not just the deposit |
| Detect | Transaction Monitoring | Return-rate monitoring by cohort, bank, link method and acquisition channel |
| Respond | Return handling and recovery | Restrict account, recover from other balances, liquidate positions where agreements allow |
| Respond | Negative Lists and Deny Lists | Block returned bank accounts, devices and identities |
Emerging variants and adversary adaptation
- Nacha fraud-monitoring rules. Phase 1 took effect March 20, 2026 for all ODFIs, for non-consumer Originators, Third-Party Service Providers and Third-Party Senders with 2023 origination volume of 6 million entries or more, and for RDFIs with 2023 receipt volume of 10 million or more. Phase 2 (dated June 19, 2026, practically June 22) extends the rules to all remaining parties regardless of volume (Nacha Phase 1; Nacha Phase 2). Parties must have risk-based processes to identify entries that are unauthorized or made under False Pretenses, reviewed at least annually. For debits, Nacha says a thorough return and return-rate monitoring program meets the minimum. The rules require neither per-entry screening nor pre-processing monitoring, and they don't change liability.
- New standard descriptors. From March 20, 2026, consumer WEB debits for online purchases of goods must carry the "PURCHASE" Company Entry Description, and payroll credits must carry "PAYROLL". The descriptors give RDFIs a signal for spotting new or multiple payroll deposits and goods-purchase debits (Nacha: Company Entry Descriptions).
- Account validation scope. WEB debit Originators have had to validate accounts before first use since March 19, 2021, but the rule only requires confirming the account is open and can take ACH entries. It says nothing about ownership (Nacha: WEB debit account validation). Fraud programs that treat "validated" as "verified owner" are exposed.
- Displacement toward mules. As credential-based and name-match verification spreads, third-party funding fraud shifts toward accounts that actually belong to the person linking them: recruited mules, synthetic identities with real bank accounts, and first-party abuse. The compensating controls are exposure limits, account aging and graph linkage rather than more identity checks.
- Faster funds availability. Nacha has eliminated the 5:00 p.m. receipt condition so non-Same Day ACH credits must be available by 9:00 a.m. on settlement day (effective September 18, 2026), and will raise the Same Day ACH per-entry limit from $1 million to $10 million on September 17, 2027 (Nacha new rules). Faster rails compress the time between deposit and exit.
- Instant exits. The ACH return window hasn't changed, but extracted value now becomes irrevocable much faster through RTP, FedNow, push-to-card and crypto, which multiplies the exposure. See Real-Time Payment Rail Fraud.
Related mechanisms
- Instant Funding Abuse (Kiting): exposure economics of provisional credit
- Account Takeover (ATO): at the victim's bank (funding source) or at the fintech (destination)
- Money Mules and Synthetic Identity Fraud: who owns the "owned" accounts
- Bust-Out Fraud: when ACH limits are built up, then maxed
- First-Party Fraud: when the account holder disputes their own debit
- Check and Mobile Deposit Fraud: the parallel funding rail with its own return windows
Real-world examples
- Nacha's 2026 rules were adopted to reduce fraud (including credit-push fraud via business email compromise, vendor impersonation and payroll impersonation) and to improve recovery of funds (Nacha Phase 1; Nacha news).
- See Case Study - Chase Infinite Money Glitch (2024) for how provisional-credit exposure plays out at scale on a parallel rail (checks).
Sources and further reading
- Nacha: Fraud Monitoring Phase 1: scope, thresholds, False Pretenses, R17, March 20, 2026 effective date
- Nacha: Fraud Monitoring Phase 2: June 19/22, 2026 extension to all parties
- Nacha: New risk management rules now in effect: Phase 1 announcement
- Nacha: Company Entry Descriptions: PAYROLL and PURCHASE descriptors
- Nacha: Supplementing fraud detection standards for WEB debits: account validation scope (confirms an open account; ownership not covered)
- Nacha: ACH Network risk and enforcement topics: 0.5% / 3.0% / 15.0% return thresholds
- EPCOR: Return reason code resource: return timeframes by code
- Nacha: Differentiating unauthorized return reasons: R10 vs R11 definitions
- Nacha: New rules: 2026–2027 funds availability and Same Day ACH limit changes
- CFPB: Regulation E § 1005.6: consumer liability and the 60-day statement window
- See also Nacha Rules and ACH Risk and Regulation E and Unauthorized Transfers