ACH fraud monitoring rules reshape merchant risk and payout timing

At a glance

What this is: Riskified says Nacha’s new ACH rules expand fraud monitoring beyond WEB debits and make settlement timing a practical control point for merchants.

Why it matters: For merchants and payment risk teams, ACH is now a governance problem as much as a payout problem, because monitoring, fulfillment timing, and return-code response determine whether fraud losses stay contained.

By the numbers:

• Internet payments on the ACH network reached 11.41 billion in 2025, totaling $6.98 trillion.
• The FTC reported $15.9 billion in fraud losses in 2025.

Context

ACH remains attractive because it lowers fees and declines, but its multi-day settlement window creates a governance gap between authorising a payment and actually absorbing the risk. That gap is now the central issue for merchants using WEB ACH, because fraud, insufficient funds, and account takeover can all surface after fulfilment has already occurred.

The article sits at the intersection of fraud prevention and payment operations rather than classic IAM, but it still has an identity angle: account validation, return-code monitoring, and differentiated fulfilment all depend on knowing who is behind the transaction and how much trust the payment can safely receive. For merchants, the question is no longer whether ACH is economical, but whether risk controls are aligned to settlement reality.

Key questions

Q: What breaks when ACH monitoring is not tied to settlement timing?

A: Merchants can release goods or funds before a transfer is final, which means fraud and insufficient-funds losses surface after fulfilment. The practical failure is not just delayed detection. It is a broken decision chain where validation, payout, and reversal timing are disconnected. Risk management has to happen before release, not after return codes arrive.

Q: Why do ACH return codes matter for fraud governance?

A: Return codes are the clearest feedback signal merchants get on whether their payment controls are working. If the same codes keep appearing in the same channels or customer segments, that usually means the approval logic, account validation, or fulfilment timing is misaligned. Without that signal loop, the organisation cannot separate isolated failures from systemic exposure.

Q: What are the signs that ACH fraud controls are too blunt?

A: Common signs include delayed fulfilment applied to every customer, rising exception rates without segment-level analysis, and no clear distinction between low-risk and high-risk payment flows. When merchants treat all ACH transactions the same, they either add unnecessary friction or leave a fraud window open. Either outcome shows the control design is too coarse.

Q: Should merchants use delayed fulfilment or instant payout for ACH?

A: Use delayed fulfilment for transactions that carry enough settlement or fraud risk to justify it, and reserve instant payout for low-risk flows with strong validation and monitoring. The right answer is usually a segmented model, not an all-or-nothing policy. That lets merchants protect losses without degrading the experience for good customers.

Technical breakdown

Why ACH settlement lag creates a fraud window

ACH is an asynchronous payment rail. A merchant can validate an account and release goods or funds before the transfer has fully settled, which means the operational decision happens ahead of the financial finality. That delay is exploitable because a fraudulent debit, an account takeover, or even an insufficient-balance transaction may not be visible until the return cycle completes. The control problem is not the network itself but the timing mismatch between authorisation, fulfilment, and reversal. Where a merchant treats settlement as a back-office detail, fraud becomes a post-fulfilment discovery problem instead of a pre-fulfilment risk decision.

Practical implication: Tie fulfilment timing to settlement status for higher-risk ACH flows rather than assuming verification alone is enough.

What return codes actually tell merchants

Return codes are the operational signal that tells a merchant whether its ACH controls worked. Codes such as R01, R07, R10, and R29 indicate different failure or fraud conditions, and tracking them across all entry types lets teams see whether loss patterns are emerging in specific products, customer segments, or payment channels. The key governance point is that return data is not just exception handling. It is feedback on whether identity validation, transaction scoring, and payout timing are aligned to actual fraud exposure. Without that loop, merchants cannot distinguish a one-off bad transaction from a systemic control gap.

Practical implication: Use return-code monitoring as a control-performance metric, not just an operations queue.

How differentiated fulfilment reduces ACH exposure

Delayed fulfilment is a risk control, not merely a customer-service choice. By holding goods or services until the transaction settles, merchants reduce the probability of paying out against funds that may later reverse or fail. The trade-off is that not every customer should be treated the same way, because blanket delays can damage experience and conversion for low-risk users. Effective programmes segment customers and transactions so that only higher-risk payments face delayed release, while lower-risk ones move faster. That is a classic governance problem: applying the same control intensity to every transaction creates unnecessary friction or leaves open a fraud path.

Practical implication: Segment ACH transactions by risk so delay is targeted, measurable, and defensible.

NHI Mgmt Group analysis

Settlement lag is the real control boundary in ACH fraud. The merchant’s risk decision happens before financial finality, which means validation alone cannot prove the transaction is safe. Fraud prevention has to shift from single-point approval to time-aware governance that connects payment acceptance, fulfilment timing, and loss recovery. Practitioners should treat settlement lag as a first-class control variable, not an operational afterthought.

Return-code tracking is the closest thing merchants have to feedback control for ACH. The article’s emphasis on R01, R07, R10, and R29 shows that fraud monitoring only becomes meaningful when the organisation can observe outcomes across entry types, not just one channel. This creates a named concept worth using: the ACH return-feedback loop, which is the continuous connection between payment decisioning and loss data. Practitioners should build governance around that loop or risk flying blind.

This rule change validates outcome-based fraud governance. Nacha is not prescribing a single technology, which means merchants must prove that their control set works rather than merely show that it exists. That places more weight on decisioning, monitoring, and recovery protocols, and less on compliance theatre. Practitioners should expect auditors, banks, and risk partners to ask whether controls reduce fraud across the full payment lifecycle.

Identity confidence matters even in a payments article. ACH fraud control depends on knowing whether the account behind the transaction is credible, whether the payer is likely legitimate, and whether transaction behaviour matches expected patterns. That makes account validation and transaction-level identity signals part of payment governance, not separate identity hygiene. Practitioners should align payment risk rules with the identity signals they already trust elsewhere in the programme.

From our research library:

• Nearly 60% of companies reported that fraud losses were still increasing in 2025.

What this signals

ACH fraud monitoring is becoming a lifecycle control, not a single screening step. Merchants that still treat approval as the end of the control chain will struggle to manage settlement risk because the exposure only becomes real when funds clear or returns arrive. The operational shift is toward monitoring that spans validation, fulfilment, and recovery rather than isolated transaction checks.

The ACH return-feedback loop now matters because it converts payment exceptions into governance evidence. Merchants should use return codes to tune risk thresholds, segment customers, and decide where delayed fulfilment is justified.

Identity signals will matter more in payment operations as merchants try to separate credible payers from higher-risk transactions without blocking legitimate volume. That means account validation, behaviour analysis, and settlement-aware release rules need to be managed as one control stack rather than separate teams.

For practitioners

• Implement settlement-aware fulfilment rules Hold delivery, release, or payout for higher-risk ACH transactions until settlement clears, and document the thresholds that justify instant release.
• Track return codes across all ACH entry types Build a monitoring view that groups R01, R07, R10, and R29 by merchant, channel, and customer segment so you can see where controls fail.
• Separate low-risk and high-risk ACH flows Use risk scoring to apply delayed fulfilment only where the loss exposure justifies it, rather than imposing a blanket delay on every customer.
• Align account validation with transaction decisioning Treat account existence checks as one input, then combine them with behavioural and payment-risk signals before approving fulfilment.

Key takeaways

• ACH fraud is increasingly a timing problem because the money movement and the merchant’s fulfilment decision no longer happen on the same clock.
• Return-code monitoring is the clearest way to see whether ACH controls are actually reducing fraud or just shifting it downstream.
• Merchants that segment payout timing by risk can protect against exploitation without forcing every customer into the same slow path.

Key terms

• Automated Clearing House (ACH): Automated Clearing House is a US payment network for electronic fund transfers between banks. It is commonly used for direct deposits, bill payments, and person to person transfers. ACH transactions are usually batch processed on a scheduled cycle, which makes them slower than instant payment methods but often lower cost and dependable.
• Settlement Lag: Settlement lag is the time between payment initiation and the point at which funds are final and can no longer be assumed safe. For merchants, that delay creates a control gap because business actions may occur before the financial outcome is confirmed.
• Exit Code: The numeric result a command returns after execution. In script-based alerting, exit codes provide a simple pass or fail signal, which makes them useful for monitoring conditions, but only if the script logic is precise and the execution context matches production.
• Instant Fulfillment: Instant fulfillment is the immediate delivery of a purchased digital product after approval. In gift card commerce, it is both a customer expectation and a risk factor because fraud can be monetised before manual review occurs. Teams need controls that preserve speed while still evaluating transaction legitimacy in real time.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle thinking, and secrets management in a way that helps practitioners connect identity controls to broader security operations. It is a practical fit for teams that need a shared governance model across identity, access, and risk.