Fraud Metrics
- Loss metrics: Track fraud by dollars and count; Net fraud loss = Gross - Recoveries
- Detection: Read detection rate, false positives and precision together. No single percentage sets the right balance
- Operational: Set review load and response times from your capacity and fulfillment deadlines
- Prevention balance: Block rate + friction rate vs. insult rate
- Segment by: fraud type, channel, product, customer segment, geography
You can't manage fraud without measuring it. These are the KPIs that tell you whether your fraud program is working, wasting money, or blocking good customers. Track loss metrics to know how much fraud costs you, detection metrics to know if your tools are catching it, and operational metrics to know if your team can keep up.
Set your loss budget from your own margins and fraud history. A rate from another business doesn't tell you what yours can afford. For sourced figures and their populations, use Benchmarks.
Loss Metrics
| Metric | Definition | What to compare |
|---|---|---|
| Fraud Rate (bps) | Fraud $ / Transaction $ x 10,000 | Your dollar-loss budget and the same segment over time |
| Fraud Rate (#) | Fraud count / Transaction count | Your count rate for the same population and outcome window |
| Gross Fraud Loss | Total confirmed fraud | Before recoveries |
| Net Fraud Loss | Gross - Recoveries | True P&L impact |
How to Calculate Fraud Rate
Fraud rate is the most important number in your fraud program. Two ways to calculate it:
By dollar volume (most common):
Fraud Rate (bps) = (Fraud Dollars / Total Transaction Dollars) x 10,000
Example:
$2,500 fraud in a month / $500,000 total volume = 0.005
0.005 x 10,000 = 50 bps (0.50%)
By count:
Fraud Rate (%) = (Fraud Transactions / Total Transactions) x 100
Example:
12 fraud transactions / 5,000 total transactions = 0.24%
Dollar-based and count-based rates tell different stories. If your dollar rate is high but your count rate is low, you have a high-ticket fraud problem. If both are high, you have a volume problem.
Only count confirmed fraud: chargebacks with a fraud reason code, transactions you refunded because you confirmed fraud, and transactions flagged by your processor as confirmed unauthorized. Don't count friendly fraud, product disputes, or "I don't recognize this" chargebacks. Those are chargeback metrics, not fraud metrics. Mixing them inflates your fraud rate and sends you chasing the wrong problem.
Net Fraud Loss: The Number That Matters
Gross fraud is the headline number, but net fraud loss is what hits your P&L:
Net Fraud Loss = Gross Fraud
- Chargebacks won (representment recoveries)
- Insurance/guarantee recoveries
- Pre-chargeback refund savings
Example:
$10,000 gross fraud
- $2,000 won through representment
- $3,000 covered by chargeback guarantee vendor
- $500 caught and refunded before chargeback filed
= $4,500 net fraud loss
Track both. Gross fraud tells you how much fraud is getting through your defenses. Net fraud loss tells you the actual financial damage.
Detection Metrics
| Metric | Definition | How to set your limit |
|---|---|---|
| Detection Rate | Detected confirmed fraud / All confirmed fraud in the measured population | Compare loss prevented with blocked good orders; report missing outcomes |
| False Positive Rate | Confirmed legitimate transactions blocked / All transactions blocked by fraud controls | Price the lost margin and customer impact against fraud prevented |
| Precision | Confirmed fraud / All transactions flagged by the measured control | Separate flags, reviews and blocks; compare the same action and outcome window |
| Recall | Same as detection rate | Use the same population and outcome window |
Here, false positive rate means the legitimate share of fraud blocks. In model evaluation it often means false positives / all legitimate transactions. Those denominators aren't interchangeable. Blocked-good share of all attempts is a third measure: legitimate fraud blocks / all attempts. Name it explicitly.
Block rate counts fraud-control blocks / all payment attempts, not every issuer decline. A shadow test reports would-block rate. Keep unresolved outcomes visible in every denominator; they aren't confirmed good orders or confirmed fraud. Precision and the legitimate share add to 100% only for the same fully labelled set.
The False Positive Problem
False positives are legitimate transactions your fraud tools incorrectly blocked. They're the hidden cost of fraud prevention, and for most merchants, they cost more than actual fraud.
False Positive Rate = Legitimate Blocked / Total Blocked
Example:
You blocked 100 transactions this month.
30 were confirmed fraud.
70 were legitimate customers.
False positive rate = 70 / 100 = 70%
What's "too high" depends on your risk appetite. Set a budget for the margin lost on blocked good orders, then compare it with the loss the control prevents. A majority-legitimate blocked set can be costly, but its percentage alone doesn't settle whether a rule pays.
How to measure false positives: Start with a random sample you have time to investigate, then expand it if the answer could change your decision. Confirm outcomes through customer checks and order history. Keep uncertain cases unknown. Report the sample count and uncertainty; a complaint or familiar buying pattern is a lead, not proof.
What false positives actually cost:
| Scenario | Cost |
|---|---|
| Customer buys elsewhere | Lost sale + lifetime value |
| Customer calls support | $5-15 in support cost + friction |
| Customer doesn't come back | Permanent revenue loss |
| Customer posts negative review | Reputation damage |
If blocked legitimate sales equal 1% of $500,000 in attempted monthly sales value, that's $500,000 x 1% = $5,000/month, or $5,000 x 12 = $60,000/year. That's a share of attempted sales dollars, not the share of blocked transactions defined above. Lost margin also depends on how many customers return and buy.
Detection Rate vs. Precision: The Tradeoff
These two metrics pull in opposite directions:
- Tighter rules (block more) = higher detection rate, but more false positives (lower precision)
- Looser rules (block less) = fewer false positives (higher precision), but more fraud slips through (lower detection rate)
There is no right answer. The balance depends on your margins, your fraud type mix, and how much your customers tolerate friction.
| Business Type | Lean Toward |
|---|---|
| Low-margin physical goods | Higher precision (can't afford blocking good orders) |
| High-margin digital goods | Higher detection rate (fraud is expensive, false positives less so) |
| Subscriptions | Higher precision (blocking a subscriber has high LTV cost) |
Operational Metrics
| Metric | Definition | How to set your limit |
|---|---|---|
| Review Rate | Transactions sent to review / Total attempts | Cases you can clear before fulfillment deadlines |
| Manual Review Time | Avg time per case | Time justified by the loss at stake and available staff |
| Auto-Decision Rate | Automatically approved or declined / Total attempts | Automation that meets your loss and customer-impact budgets |
| Time to Detection | Transaction to fraud confirmation | Your response needs; track delays separately by source |
Review Rate: Your Automation Gauge
A review queue is too large when cases miss your deadlines or cost more to investigate than the decisions are worth. The percentage alone won't tell you that.
Review Rate = Transactions Sent to Review / Total Attempts
Example:
250 reviews / 10,000 attempts = 2.5%
1,200 reviews / 10,000 attempts = 12%
Neither example is a capacity target. Multiply case count by review time and compare it with the hours you have.
What to do if review rate is too high:
- Find which rules send the most cases to review.
- Test narrower conditions or a different threshold without losing coverage of confirmed fraud.
- Check rules whose reviews usually end in approval. Test changes under the live-test safeguards.
Time to Detection
The faster you confirm fraud, the faster your model learns and the faster you can stop similar transactions. "Time to detection" measures how long it takes from when a fraudulent transaction processes to when you know it was fraud.
| Detection Source | Typical Time |
|---|---|
| Customer contacts you | 1-3 days |
| Internal review catches it | Same day to 7 days |
| Chargeback arrives | 30-120 days |
| Fraud vendor flags it | 1-7 days |
Waiting for chargebacks means your fraud tools are always learning from stale data. Proactive detection (internal review, customer reports, vendor flags) gives you faster feedback. See Fraud Model Feedback for how faster signals improve your detection over time.
Prevention Metrics
| Metric | Definition | Notes |
|---|---|---|
| Block Rate | Transactions blocked / Total attempts | Higher isn't always better |
| Friction Rate | Step-ups triggered / Total | Balance UX vs. security |
| 3DS Challenge Rate | Challenges / Total 3DS attempts | Compare the same issuer and customer mix |
| Insult Rate | Confirmed legitimate fraud blocks / All legitimate attempts | State the denominator and unknown outcomes |
Block Rate: When Higher is Worse
A rising block rate doesn't mean your fraud prevention is working better. It often means your rules are too aggressive or a new rule is catching too many legitimate transactions.
Warning signs:
- Block rate moves outside the range you set from comparable traffic, with no corresponding fraud change
- Blocks exceed the customer-impact budget you approved
- Block rate rises but fraud losses don't decrease (check whether you're blocking the wrong transactions)
What a healthy block rate looks like:
A healthy rate stays within your loss and customer-impact budgets. Compare like-for-like traffic:
| Business Type | What to check |
|---|---|
| Low-risk e-commerce | Legitimate repeat buyers caught by new rules |
| Digital goods | Lost contribution against fraud losses and abuse |
| High-risk verticals | Attack traffic separately from ordinary customer attempts |
Segmentation
Track every metric above by:
- Fraud type (first-party, third-party, ATO, etc.)
- Channel (web, mobile, in-store)
- Product type (high-value items often have different fraud patterns)
- Customer segment (new vs. returning customers)
- Geography (cross-border transactions have higher fraud rates)
Aggregate numbers hide problems. In an illustrative month, digital goods might run at a 1.5% fraud rate and physical goods at 0.05%, while the combined rate is 0.2%. Compare each with its own budget and prior results. The overall rate can hide a targeted problem.
Test to Run
False positive audit:
- Start with a random sample of blocked transactions you can investigate; record its size and expand it if results are uncertain.
- For each one, determine: confirmed fraud, confirmed legitimate, or unknown.
- Calculate the legitimate share of fraud blocks, with unknowns reported separately.
- Identify which rules or score thresholds caused the most false positives.
- Moving a live rule to shadow lets flagged orders through, so set an owner, loss cap and outcome window first, then measure impact.
Success criteria: False positives fall without fraud increasing after the outcome window closes. Until then, fraud results are inconclusive. If you can't tell whether a blocked transaction was fraud or not, that's a data collection problem to fix first.
Scale Callout
| Volume | What to Track | How |
|---|---|---|
| Under $50K/month | Fraud rate (monthly), chargeback count | Check processor dashboard weekly. Manual count is fine. |
| $50K-$250K/month | Add: false positive rate, detection rate, review rate | Monthly spreadsheet. Size the blocked-order sample to the decision; record unknowns. |
| $250K-$1M/month | Add: precision per rule, time to detection, block rate trends | Weekly reporting. Segment by fraud type and product category. |
| Over $1M/month | All metrics, segmented by channel, geography, and customer segment | Automated dashboards. Daily review of anomalies. |
Where This Breaks
- Optimizing one metric in isolation. Pushing detection rate to 99% will spike false positives. Pushing false positives to zero will miss fraud. Read metrics as a set, not individually.
- Comparing across business models. The same fraud rate can cost two businesses different amounts. Use your margins and losses, and keep published survey populations separate from your own.
- Low volume noise. One case among 1,000 transactions is 0.1 percentage points. Show counts beside rates and use a longer window when individual cases dominate; wait for outcomes to mature.
- First-party fraud miscategorization. If you're counting friendly fraud as third-party, your detection rate looks worse than it is and your prevention strategy targets the wrong problem.
- Only counting chargebacks as fraud. Chargebacks represent fraud you missed. If you refund a fraudulent transaction before the chargeback arrives, that's still fraud. Count it.
What to Do When...
Fraud rate is climbing:
- Segment by fraud type. Is it third-party fraud (stolen cards) or friendly fraud (legitimate customers disputing)?
- Check if a specific product, geography, or customer segment is driving the increase.
- If it's third-party fraud, tighten your velocity rules or risk scoring thresholds.
- If it's friendly fraud, the solution is better evidence collection and refund policy design, not tighter fraud rules.
False positive rate is too high:
- Identify the rules sending the most transactions to review or block.
- Check what percentage of those flagged transactions were actually fraud (precision per rule).
- Compare each rule's prevented loss with blocked-good margin and review cost. Move it to shadow or change conditions only under the live-test safeguards, with approval before changing current controls.
- See Building Fraud Rules for shadow testing methodology.
Detection rate is too low:
- Review recent chargebacks. What fraud got through? Was there a pattern your rules should have caught?
- Check if your rules cover the fraud types you're actually seeing (card testing, ATO, etc.).
- Consider adding device intelligence signals to catch fraud that transaction data alone misses.
Tracking fraud is just one piece. See also: Payments Metrics · Chargeback Metrics · Compliance Metrics · Operations Metrics
Do next
- Tune manual review - Reduce false positives
- Evaluate vendors - Consider specialized tools
- Building Fraud Rules - Rule construction and testing
Deeper
- Fraud Vendors - Vendor performance measurement
- Running Fraud Operations - Operational cadence
Fraud rate too high?
- Consider 3DS - Liability shift for fraud
Optimizing detection?
- Review rules vs ML - Choose right approach