Tuning Fraud Thresholds: How to Balance Security and Conversion

Every fraud prevention system relies on a single, critical decision point: the threshold. It is the line in the sand that separates "allow" from "block," and getting it wrong costs you money in both directions.

Set the threshold too tight and you reject legitimate customers. Too loose and you let fraud slip through. The difference between a well-tuned threshold and a poorly configured one can mean tens of thousands of dollars per month for a growing SaaS or e-commerce business.

This guide covers how fraud thresholds work, how to set your initial values, and how to iterate toward an optimal balance between security and conversion.

What Is a Fraud Threshold?

A fraud threshold is a numeric cutoff applied to a risk score. When a user performs an action (signing up, making a payment, changing account details), your fraud detection system calculates a score representing the likelihood that the action is fraudulent.

That score is compared against your threshold:

• Below the threshold = approved automatically
• At or near the threshold = flagged for manual review
• Above the threshold = blocked or rejected

For example, if your system scores risk on a 0 to 100 scale and your threshold is set at 65, any transaction scoring 65 or higher triggers your fraud response.

Most production systems use two thresholds rather than one, creating three zones:

This three-tier approach gives you a safety net. Instead of making every decision binary, you create a middle ground where human judgment can add context that algorithms miss.

The False Positive vs. False Negative Tradeoff

This is the core tension in fraud prevention. Every threshold configuration produces two types of errors:

False positives occur when a legitimate transaction is flagged or blocked. The customer was real, the payment was valid, but your system rejected it. The cost is lost revenue plus the downstream damage of a frustrated customer who may never return.

False negatives occur when a fraudulent transaction passes through undetected. The fraudster succeeds, and you eat the cost through chargebacks, stolen goods, or abused services.

Here is the hard truth: you cannot eliminate both. Lowering your threshold to catch more fraud will inevitably increase false positives. Raising it to reduce false positives will let more fraud through.

The goal is not perfection. It is finding the point where the combined cost of both error types is minimized for your specific business.

Quantifying the Cost of Each Error

Before tuning anything, you need to understand what each error costs you:

• Cost of a false positive: Average transaction value + customer lifetime value lost + support cost of handling complaints
• Cost of a false negative: Chargeback amount + chargeback fee ($15 to $100) + operational cost of dispute handling + potential impact on your chargeback rate

For most businesses, a single false negative costs more than a single false positive. But false positives happen at much higher volume, so their aggregate cost can exceed fraud losses. This ratio determines where your threshold should sit.

How to Set Initial Thresholds

If you are starting from scratch, do not guess. Use data and industry defaults to establish a starting point, then iterate.

Step 1: Start in Monitor Mode

Before enforcing any thresholds, run your fraud scoring system in monitor-only mode for two to four weeks. Score every transaction but do not block anything. This gives you a baseline dataset to analyze.

With Fidro, you can do this by integrating the risk scoring API and logging the scores alongside your transaction outcomes. The API evaluates 14+ risk factors, including email validity, IP reputation, VPN/proxy detection, and geolocation matching, returning a weighted risk score for each request. bash curl -X POST https://api.fidro.io/v1/assess/risk
-H "Authorization: Bearer YOUR_API_KEY"
-H "Content-Type: application/json"
-d '{ "email": "customer@example.com", "ip": "203.0.113.42", "amount": 149.99, "currency": "USD" }'### Step 2: Analyze the Score Distribution

After your monitoring period, plot the distribution of risk scores. You are looking for two things:

1. Where do confirmed fraud cases cluster? If you have chargeback data or manual reviews, map those back to their original risk scores.
2. Where does the majority of legitimate traffic fall? This tells you where your "safe" zone ends.

In most systems, you will see legitimate traffic clustering between 0 and 30, with confirmed fraud cases concentrated above 60. The exact numbers depend on your industry, customer base, and the risk signals available.

Step 3: Set Conservative Initial Thresholds

Start conservative. It is easier to tighten thresholds gradually than to recover customers you have already blocked. A reasonable starting configuration:

• Auto-approve: 0 to 45
• Manual review: 46 to 74
• Auto-block: 75 to 100

This gives your review queue room to catch edge cases while keeping your block rate low. You will refine these numbers as you collect more data.

Measuring and Iterating: Precision, Recall, and F1

Once your thresholds are live, you need metrics to evaluate performance. Three metrics matter most for fraud detection.

Precision

Precision answers: "Of all the transactions we flagged as fraud, how many were actually fraud?" Precision = True Positives / (True Positives + False Positives)High precision means your system rarely flags legitimate transactions. If your precision is 0.90, then 90% of blocked transactions were genuinely fraudulent.

Recall

Recall answers: "Of all the actual fraud, how much did we catch?" Recall = True Positives / (True Positives + False Negatives)High recall means your system catches most fraud. If your recall is 0.85, you are detecting 85% of all fraudulent transactions.

F1 Score

The F1 score is the harmonic mean of precision and recall. It gives you a single number that balances both: F1 = 2 × (Precision × Recall) / (Precision + Recall)An F1 score of 0.80 or higher is considered strong for fraud detection systems. Below 0.60 indicates significant room for improvement.

The Iteration Loop

Here is the process for ongoing threshold optimization:

1. Measure precision, recall, and F1 weekly
2. Identify whether false positives or false negatives are your bigger problem
3. Adjust thresholds by small increments (3 to 5 points at a time)
4. Wait at least one week before measuring the impact
5. Repeat

Never make large threshold changes in a single step. A 10-point shift can dramatically change your approval and block rates. Small, measured adjustments with time to observe results will get you to optimal performance without creating volatility.

Industry Benchmarks

Threshold configurations vary significantly by industry. Here are reference points based on aggregated data from fraud prevention platforms:

These are starting points, not targets. Your optimal thresholds depend on your transaction volume, average order value, fraud rate, and risk tolerance.

A few things to keep in mind:

• High-value transactions justify lower thresholds. The cost of a single false negative on a $5,000 order outweighs blocking a few legitimate $50 orders.
• Digital goods typically need tighter thresholds because there is no shipping address to verify and no way to recover the product.
• Subscription businesses can afford slightly higher thresholds at signup because they have ongoing opportunities to detect fraud through usage patterns.

Using Fidro's Risk Scores Effectively

Fidro's API returns a composite risk score built from weighted algorithms across multiple signal categories. Understanding these signals helps you make better threshold decisions.

Signal Categories and Their Weight

Each API response includes individual signal scores alongside the composite score:

• Email signals: Disposable domain detection, domain age, syntax validation, MX record verification. A disposable email alone can push the score above 60.
• IP signals: VPN/proxy/Tor detection, IP reputation, ISP classification, abuse history. A residential IP from the expected country scores low. A datacenter IP routing through a known proxy scores high.
• Geolocation matching: Does the IP location match the billing address? Mismatches are a strong fraud indicator, though legitimate travelers can trigger this signal.
• Behavioral patterns: Velocity checks (how many requests from this email or IP in a given window), device fingerprinting, and session analysis.

Building Conditional Thresholds

Rather than using a single global threshold, consider different thresholds based on context:

$riskScore = $fidroResponse['risk_score']; $isHighValueOrder = $orderAmount > 500; $isNewCustomer = $customer->created_at > now()->subDays(7);

if ($isHighValueOrder && $isNewCustomer) { $blockThreshold = 55; // Stricter for high-value new customers $reviewThreshold = 35; } elseif ($isHighValueOrder) { $blockThreshold = 65; $reviewThreshold = 40; } else { $blockThreshold = 75; // Default thresholds $reviewThreshold = 50; }

if ($riskScore >= $blockThreshold) { return 'block'; } elseif ($riskScore >= $reviewThreshold) { return 'review'; }

return 'approve';This layered approach lets you apply stricter scrutiny where the stakes are highest while keeping friction low for routine transactions.

Leveraging Individual Signals

Sometimes the composite score alone is not enough. A transaction might score a moderate 55 overall, but if the email is disposable and the IP is a known proxy, that combination warrants a block regardless of the overall score.

Fidro's response includes individual signal flags that you can use to build override rules:

• Always block if the email is disposable and the IP is a proxy, regardless of composite score
• Always review if geolocation does not match the billing country, even if the composite score is low
• Lower the threshold by 10 points for first-time customers with accounts less than 24 hours old

These signal-level rules work alongside your threshold, catching edge cases that a single-number cutoff might miss.

Common Mistakes to Avoid

Setting and forgetting. Fraud patterns evolve constantly. A threshold that worked six months ago may be wildly off today. Schedule regular reviews.

Optimizing only for fraud catch rate. A system that blocks 99% of fraud but also blocks 10% of legitimate customers is not a success. Always measure both sides.

Ignoring the review queue. If your manual review zone is too wide, tickets pile up and reviews happen too late to matter. Keep the review band narrow enough that your team can process it within your SLA.

Using the same threshold globally. Different products, price points, and customer segments have different risk profiles. Treat them differently.

Reacting to individual cases. One high-profile fraud case should not trigger a 20-point threshold drop. Use aggregate data, not anecdotes, to drive changes.

Getting Started

Effective threshold tuning requires good risk scores to begin with. If your scoring system only looks at one or two signals, even the best threshold will underperform.

Fidro's risk scoring API evaluates 14+ weighted risk factors per request, giving you the granularity needed to set precise thresholds. Start with the free tier (200 requests per month) to test the scoring against your transaction data, then scale as you implement automated decisions.

Try the free IP checker or email checker to see the risk signals in action. Enter any email or IP address and review the full breakdown of factors that contribute to the score.

Fraud prevention is not a set-it-and-forget-it problem. But with the right data and a disciplined iteration process, you can find the threshold balance that protects your revenue without turning away the customers who drive it.