ACH fraud monitoring rules reshape merchant risk and payout timing

At a glance

What this is: The article explains how ACH growth, settlement lag, and Nacha’s new fraud-monitoring rules are changing merchant fraud controls and fulfillment decisions.

Why it matters: This matters to IAM practitioners because payment fraud prevention increasingly depends on identity verification, account validation, and risk-based decisioning tied to transaction trust.

By the numbers:

• ACH internet payments on the ACH network reached 11.41 billion in 2025, totaling $6.98 trillion, a 6.1 percent year-over-year increase in payment volume.
• The FTC tracked $12.5 billion in reported fraud losses in 2024 and $15.9 billion in 2025.
• Law enforcement estimates that only 2 percent to 6.7 percent of victims report their losses, which led the FTC to estimate the true 2024 toll at $196 billion.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%).

👉 Read Riskified's analysis of ACH fraud monitoring and fulfillment timing

Context

ACH remains attractive because it lowers payment costs and improves acceptance rates, but the same settlement characteristics that help merchants also create a fraud window. When verification is separated from final settlement by days, payout decisions begin to depend on trust controls rather than payment rails alone, which is why ACH fraud management now sits at the intersection of fraud operations, IAM, and identity verification.

The article’s core governance point is that Nacha’s new requirements are outcomes-based, not technology-prescriptive. That means merchants and their payment partners must prove they can monitor fraud across entry types, validate account ownership, and adjust fulfillment based on risk. For identity teams, this is the same control problem seen in broader trust frameworks: confirm who or what is initiating the transaction, then limit exposure until the transaction is truly settled.

Key questions

Q: How can merchants reduce fraud without blocking good customers?

A: Use layered controls that reserve strict checks for combinations of risk, not single signals. Combine seasonal baselines, account age, loyalty behaviour, payment provenance, and fulfilment patterns. That approach protects revenue while avoiding the conversion losses that come from blunt, over-restrictive rules.

Q: Why does ACH settlement lag create more fraud risk than card payments?

A: Because value can be released before final settlement, which gives fraudsters time to exploit the gap between verification and return. Card systems often provide faster dispute and authorization feedback, while ACH return timing can leave merchants exposed after payout.

Q: How do you know if ACH fraud monitoring is working?

A: Look for measurable reduction in losses, fewer false approvals in high-risk segments, and consistent analysis of return-code patterns across all entry types. If monitoring only reports volume and not outcomes, it is not proving control effectiveness.

Q: Who is accountable when ACH fraud monitoring fails under the new rules?

A: Accountability sits with the merchant originator and the financial partners that support origination and monitoring obligations. In practice, that means business owners, fraud operations, and control owners must be able to show that monitoring and escalation procedures actually work.

Technical breakdown

Why ACH settlement lag creates a fraud window

ACH payments are not instant finality systems. The merchant can verify an account, approve a transfer, and even release funds before the network return arrives days later. Fraudsters exploit that delay by using speed on the front end and irreversibility on the back end. The risk is highest where fulfillment is triggered by initial verification instead of confirmed settlement. In practical terms, the fraud control is not just account validation, but the timing of value release relative to settlement and return behaviour.

Practical implication: tie fulfillment to settlement status for higher-risk transactions rather than treating verification as final approval.

How return codes function as a fraud signal

Return codes are the operational feedback loop for ACH controls. Codes such as R01, R07, R10, and R29 tell merchants whether a debit failed because of insufficient funds, authorization problems, or suspected fraud. That makes return-code monitoring a control instrument, not just an accounting artifact. If a program only watches one payment type or one error class, it will miss patterns that signal account testing, fraud rings, or weak validation steps. The new Nacha expectation broadens monitoring across entry types, which is where many merchants are least mature.

Practical implication: build monitoring that aggregates return codes across all ACH entry types and routes anomalies into fraud review.

Why identity verification and decisioning now matter together

The article describes a three-layer model: verification at point of payment, transaction-level decisioning, and recovery when returns arrive. That is effectively a trust pipeline. Verification answers whether the account exists and belongs to the payer. Decisioning weighs velocity, amount, historical behaviour, and risk signals. Recovery handles the losses that escaped the first two layers. For identity and fraud teams, the lesson is that one control is never enough when the payment rail allows delayed discovery of abuse. The program has to treat identity confidence and settlement risk as linked variables.

Practical implication: combine account validation, transaction scoring, and post-loss recovery into one operating model rather than separate workflows.

Threat narrative

Attacker objective: The attacker’s objective is to receive immediate value from a transaction that later returns unpaid or unauthorized, while the merchant absorbs the loss.

1. Entry occurs when a fraudster initiates an ACH transfer through a verified account or a weakly validated payment flow.
2. Escalation happens when the platform releases funds before the ACH settlement and return cycle completes, converting temporary trust into financial exposure.
3. Impact follows when the return arrives too late to reverse the payout, leaving the merchant with unrecoverable losses and no practical dispute recovery.

NHI Mgmt Group analysis

Delayed settlement is the real control boundary in ACH fraud. Merchant verification can be accurate and still fail if value is released before final settlement. That makes the operational decision point the gap between verification and return, not the initial account check. Practitioners should treat settlement timing as part of the trust model, not just the payment rail.

Fraud monitoring rules are pushing merchants toward measurable outcomes, not tool labels. Nacha’s technology-neutral approach means merchants have to prove that monitoring works across entry types and return patterns. This is the same governance shift seen in identity programmes when audits move from policy existence to control effectiveness. The practical conclusion is that merchants need evidence, not assumptions, about detection quality.

Payment fraud and identity governance are converging around account ownership assurance. The strongest programs verify that an account exists, belongs to the right party, and behaves consistently over time. That is an identity control problem as much as a payments problem, especially when unauthorized debits and account takeover are in scope. Organisations that already understand lifecycle validation in IAM will recognise the same pattern here.

Return-code analytics create a named governance concept: settlement risk visibility. The article shows that knowing why payments fail matters as much as knowing that they failed. Without visibility into return-code trends, merchants cannot distinguish insufficient funds from fraud patterns or tune fulfillment accordingly. Practitioners should make return-code analysis a standing control signal, not a retrospective report.

Delayed fulfillment is a risk partitioning strategy, not a customer-service compromise. The article shows that higher-risk transfers need a different release policy from lower-risk ones. That is a form of differentiated trust, which aligns with modern identity and access thinking even outside IAM. The governance conclusion is simple: risk-based treatment beats blanket treatment when settlement is not immediate.

What this signals

ACH fraud control is moving toward the same outcome-based logic that identity programmes already face. Merchants will need to show that validation, monitoring, and payout decisions reduce loss, not just that policies exist on paper. The control conversation is shifting from payment processing to trust assurance, which is where identity teams already live.

Settlement risk visibility: merchants that cannot see return-code trends across entry types will not be able to distinguish customer error from fraud or tune hold policies effectively. That makes the quality of telemetry as important as the quality of identity verification, especially when value release happens before final settlement.

Where payment fraud touches account ownership, transaction history, and authorization confidence, the boundary between fraud operations and identity governance becomes thinner. Teams that already use risk-based access and lifecycle controls should recognise the same operating principle here: release value only when the evidence supports trust, not before.

For practitioners

• Separate verification from release decisions Do not treat account validation as permission to fulfill. For higher-risk ACH transactions, hold goods or services until settlement confidence is sufficient, especially where return windows are long and loss recovery is weak.
• Monitor return codes across all ACH entry types Build a single fraud telemetry view for R01, R07, R10, and R29 events so your team can see whether fraud is shifting across payment categories rather than only in WEB debits.
• Add transaction-level decisioning to identity checks Combine account ownership validation with velocity, amount, device, and historical behaviour signals before approving fulfillment. Identity assurance alone is not enough when the settlement window remains open.
• Define a recovery playbook for returned ACH payments Document who reviews returns, when holds are triggered, and how losses are escalated. A recovery workflow should be explicit before fraud volume increases, not improvised after the first wave of returns.

Key takeaways

• ACH fraud is driven as much by timing as by identity confidence, because merchants can release value before settlement catches up.
• The scale of ACH adoption and fraud reporting shows why return-code monitoring and differentiated fulfillment are now core controls, not optional refinements.
• Merchants reduce loss by linking account validation, transaction scoring, and settlement-aware release decisions into one operating model.

Key terms

• ACH settlement lag: The time between an ACH transfer being initiated and the network confirming final settlement. That delay creates a window where merchants may release value before they know whether the payment will clear, return, or be disputed, which is why fraud controls must be settlement-aware.
• Return code monitoring: The practice of tracking ACH return reasons such as insufficient funds, authorization failure, or suspected fraud. It is a control signal, not just an operational report, because return patterns reveal whether verification, decisioning, and fulfillment controls are working as intended.
• Transaction Decisioning: Transaction decisioning is the process of approving, declining, or reviewing a purchase using multiple risk signals in real time. It goes beyond card verification to combine behavioural, device, and historical context so merchants can reduce fraud without blocking too many legitimate customers.
• Differentiated fulfillment: A release strategy that varies delivery timing based on risk. Lower-risk ACH transactions may proceed faster, while higher-risk ones are held until settlement confidence is stronger. This reduces exposure without forcing every customer through the same friction path.

What's in the full article

Riskified's full article covers the operational detail this post intentionally leaves for the source:

• How Riskified applies approve or decline decisions to ACH transactions in practice.
• How the instant versus delayed fulfillment recommendation is used to reduce exposure.
• How financial guarantee coverage works when an approved ACH payment is later returned.
• How the article maps return codes and fraud signals to specific decisioning outcomes.

👉 Riskified's full article covers the transaction-level decisioning and fulfillment logic behind its ACH fraud approach.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners translate trust, validation, and lifecycle control into practical programme decisions across identity and security teams.