Why can low in-store fraud loss rates be misleading for merchants?

Why This Matters for Security Teams

Low reported loss can create a false sense of security in retail, payments, and omnichannel commerce. A merchant may be stopping chargebacks, card testing, account takeover, refund abuse, and synthetic identity activity before it ever reaches the loss ledger. The operational question is not just what was lost, but what was prevented, what was diverted to manual review, and what would happen if thresholds were relaxed.

This is why fraud metrics need to be treated like security metrics, not just finance metrics. Controls that reduce exposure often make their own value invisible unless teams track declines, step-up challenges, review queues, and dispute outcomes together. NIST’s control baseline in NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reminder that monitoring, logging, and risk response only work when leaders actually observe the full control effect, not just end-state losses.

In practice, many security teams encounter “good” fraud numbers only after control weakening has already increased exposure, rather than through intentional measurement of prevented loss.

How It Works in Practice

Merchants usually measure fraud in terms of realized loss, chargebacks, and operational handling cost. That is necessary, but not sufficient. A low loss rate can hide the fact that the fraud stack is aggressively blocking transactions, pushing risky behavior into other channels, or transferring risk to manual reviewers. The right question is whether the merchant is reducing fraud, or merely shifting where the fraud appears.

To see the full picture, teams should separate three measurements: observed loss, blocked or challenged activity, and estimated avoided loss. This is where rule tuning, device intelligence, behavioral analytics, and payment authentication need to be evaluated together. If a merchant sees fewer losses after adding stronger filters, that may indicate better protection. But if approval rates also collapse or review queues spike, the business may be trading visible fraud for hidden friction.

Useful operational signals include:

• Decline reasons and how often they map to fraud rules versus payment failures.
• Chargeback reason codes, because not all disputes reflect the same control gap.
• Manual review outcomes, including false positives and false negatives.
• Trend lines for card testing, promo abuse, refund abuse, and account takeover attempts.
• Projected loss under a counterfactual scenario where controls are relaxed or removed.

For control design, fraud prevention should be treated as part of a broader detection and response model. Mapping merchant telemetry to the control intent in CISA guidance on threat mitigation and aligning governance to NIST AI Risk Management Framework can help when machine learning or decision automation is part of the fraud stack.

These controls tend to break down in high-volume, low-margin checkout environments because the pressure to reduce friction makes blocked and deferred fraud hard to measure consistently.

Common Variations and Edge Cases

Tighter fraud controls often increase review overhead, requiring organisations to balance prevented loss against customer friction and analyst capacity. That tradeoff becomes more visible in businesses with thin margins, high repeat purchase volume, or heavy promotion cycles, where even small shifts in approval rate can materially affect revenue.

There is no universal standard for defining “good” fraud performance yet. A merchant selling high-value goods may tolerate more manual review than a low-value subscription business, while a marketplace may prioritize seller trust and dispute reduction over short-term approval rate. Current guidance suggests using segmented reporting by channel, region, payment method, and risk tier rather than one blended fraud rate.

Edge cases matter. A merchant with very low fraud loss may still be exposed if losses are being absorbed by processors, issuers, or customers through friendly fraud disputes. Likewise, a sudden drop in fraud loss after a policy change may reflect weaker detection, not real improvement. That is why leadership should review prevented loss estimates alongside abandonment, dispute ratios, and exception handling.

For payments-linked environments, the most relevant lens is whether controls are reducing risk in a measurable way without masking exceptions. If the merchant also handles identity verification, account recovery, or non-human workflow access, fraud metrics should be joined with credential and session telemetry so that abuse patterns are not misread as simple commerce noise.

Related resources from NHI Mgmt Group

• Why do crypto firms struggle with fraud even when verification rates improve?
• How do IAM and fraud teams know when insider risk is moving from theory to loss?
• Who should be accountable when a compromised mailbox leads to fraud or access loss?
• Who is accountable when cash-out fraud is booked as an operational loss?