How should merchants manage ACH fraud without blocking legitimate payments?

Why ACH Fraud Needs Its Own Policy Tier

ACH fraud behaves differently from card fraud because the payment rail is slower, settlement is less immediate, and bank-account changes often matter more than classic card signals. That means merchants need a policy that weighs account age, recent payment-detail edits, session behaviour, and the likely cash-out window together, instead of applying a single hard block. NIST Cybersecurity Framework 2.0 is useful here because the control problem is really about risk-based decisioning, not just payment review.

The practical goal is to separate normal ACH use from suspicious sequences such as a new account, a recent bank-detail change, and a first large order routed to fast fulfilment. Merchants usually lose money when they either trust ACH too much or treat every ACH payment like a high-risk exception. In practice, the failures show up when the fraud signal is distributed across the account lifecycle rather than concentrated in the transaction itself.

How It Works in Practice

A workable ACH policy starts by treating transaction review as a layered decision, not a yes-or-no fraud score. The merchant should combine signals that describe the customer relationship, the payment instrument, and the current session. A new customer with unchanged bank details and a stable device history may deserve light-touch processing, while an established customer who just swapped bank accounts and is placing an unusually large order may deserve a hold or step-up check.

• Account age helps distinguish first-touch risk from repeat behaviour.
• Recent bank-detail changes are a strong indicator because ACH fraud often follows a fresh account or routing-number update.
• Session behaviour, including velocity, device consistency, and checkout path changes, helps identify scripted or account-takeover driven activity.
• Settlement exposure matters because loss is usually tied to fulfilment timing, not just payment initiation.

That is why ACH should usually have different review thresholds from cards. Card controls are often tuned around authorisation-time denial patterns, while ACH loss frequently emerges when goods ship before the return, reversal, or dispute window is fully understood. Merchants should therefore place review, delay, or step-up checks before fulfilment when the pattern matches a known cash-out path, especially for inventory that is easy to resell or services that are immediately consumable. NIST SP 800-53 Rev. 5 Security and Privacy Controls is a good reference point for structuring monitoring, account-change checks, and risk-based access decisions.

Good practice also means tuning the review queue so analysts see the combinations that matter, not every isolated anomaly. A single recent bank update is often ordinary; a recent bank update plus a new shipping address, high order value, and a fast-fulfilment request is much more actionable. These controls tend to break down when fulfilment teams override review holds for speed, because the merchant loses the only point where ACH fraud can still be intercepted before shipment.

Common Variations and Edge Cases

Tighter ACH controls often increase checkout friction and manual review cost, so merchants have to balance fraud reduction against conversion loss. The right threshold depends on product type, fulfilment speed, customer repeat frequency, and how quickly losses become unrecoverable.

Recurring payments are a common edge case. A low-risk repeat customer can become high-risk after a bank-account change, but the same customer should not be forced through full review on every cycle. Best practice is evolving toward change-based scrutiny, where the merchant looks harder at account transitions than at the recurring debit itself. Another edge case is mixed-risk baskets, where digital items and physical goods are purchased together. In those cases, the merchant may need to separate fulfilment timing so the highest-loss component is not released before the payment pattern is sufficiently trusted.

Merchants also need to be careful with blanket ACH blocks for new customers. That may reduce fraud, but it pushes legitimate buyers to alternate rails and can bias the policy toward the easiest payments to approve rather than the safest ones. The better approach is to reserve stronger friction for situations where the combination of signals actually suggests cash-out intent or synthetic account use.

Risk and Threat Considerations

ACH fraud risk is concentrated in delayed loss discovery, account-change abuse, and fulfilment timing. Because ACH settlement and reversal timing differ from card payments, a merchant can approve a transaction that later proves abusive after the goods or services have already been delivered.

Failure mechanism: Attackers and fraud rings commonly abuse newly added bank details, account takeover, and rapid fulfilment. They rely on merchants over-weighting the payment rail itself and under-weighting the surrounding behavioural signals, which lets them move from order placement to cash-out before review catches up.

Impact: The merchant absorbs chargeback-like loss, shipping loss, or service abuse, while legitimate customers face unnecessary friction if the policy is too blunt. That creates both direct financial exposure and avoidable abandonment in good accounts.

Practitioner Guidance

What to prioritise: Build the ACH policy around change events and fulfilment risk first. The highest-value controls are the ones that catch bank-detail changes, abnormal session behaviour, and fast-shipping exposure before value leaves the merchant.

Decision rule: If the transaction is ordinary in isolation but sits inside a pattern of recent payment-detail change, account novelty, and high-loss fulfilment, treat it as a review or hold candidate rather than an automatic decline. If none of those conditions are present, keep the path lightweight so legitimate buyers are not over-blocked.

What to measure: Track fraud loss by policy tier, review hit rate, fulfilment override rate, and the share of losses that came from accounts with recent bank changes. If losses cluster after shipment, the control is late, not absent.

Practitioner takeaway: ACH fraud is best managed as timing and trust-boundary risk, not as a generic payment-screening problem, so the merchant’s job is to slow down only the transactions that are most likely to cash out before exposure can be contained.

Related resources from NHI Mgmt Group

• How should security teams reduce identity fraud without blocking legitimate users?
• How should gig platforms reduce identity fraud without blocking legitimate users?
• How can organisations reduce fraud without blocking legitimate automation?
• How can merchants reduce fraud without blocking good customers?