What a Risk Score of 73 Actually Means

You call a fraud API. It returns 73. Now what?

That question gets asked more than any other about risk scoring, and the documentation usually answers it with a table suggesting you block above 80. That table is a guess about your business made by somebody who has never seen it.

Here is what the number actually is, and how to turn it into a decision you can defend when a genuine customer emails asking why they were blocked.

It is a ranking, not a probability

The most consequential misunderstanding first. A score of 73 does not mean a 73% chance this signup is fraudulent.

Risk scores are ordinal. They tell you that 73 is riskier than 40 and less risky than 90. They do not tell you that the distance between 40 and 50 is the same as the distance between 80 and 90, and in practice it usually is not. Scores tend to be compressed at the low end, where most traffic sits, and stretched at the top.

This matters when someone tries to do arithmetic with it. "Our average score is 31, so 31% of our signups are fraudulent" is wrong, and I have seen that number end up in a board pack. Averaging scores across a population produces something with no interpretation at all.

What you can legitimately do: sort by it, set thresholds on it, and watch its distribution shift over time. A sudden change in the shape of the distribution is one of the better early warnings of a coordinated attack, and it is more informative than any individual score.

What goes into it

Four families of signal, weighted.

The email address. Whether the domain is disposable, how old the domain is, whether the address is a role account, whether the local part looks generated. Domain age is doing more work than disposability now, because operators moved past throwaway providers years ago and buy cheap domains instead. An eleven-day-old domain passes every disposability check and is a genuinely useful signal, which we covered in how to block disposable emails.

The IP. Datacenter, commercial VPN, public proxy, Tor exit, or consumer ISP. Plus geolocation, and whether it agrees with everything else you know about this user. Residential proxies make this weaker than it used to be, for reasons in residential proxies and the VPN detection blind spot.

Linkage. Whether this account shares a payment instrument, device, or payout destination with accounts you have already seen. This is frequently the highest-weighted family, because it is the hardest for an attacker to avoid while operating at scale. One card across twelve accounts is a much stronger statement than any property of a single account, which is the whole argument in catching cross-account fraud with Stripe card fingerprints.

Behaviour. Velocity, form completion time, whether fields were pasted, whether the flow was traversed in a human order.

The weighting is where the craft is, and the specific trap is correlated signals. A datacenter IP, a fresh domain, and a paste-filled form frequently travel together because they come from the same tooling. Counting each as independent evidence triple-counts one underlying fact, which is how scores end up pinned at 95 for a population that includes real customers.

Three bands, not one line

The single most useful change most teams can make is to stop treating this as a binary.

$risk = $fidro->check([
    'email' => $request->input('email'),
    'ip' => $request->ip(),
]);

match (true) {
    $risk->score >= 85 => $this->block($request),
    $risk->score >= 55 => $this->stepUp($request),
    default            => $this->allow($request),
};

Allow, review, block. The middle band is what makes an imperfect score usable, because it lets you act on suspicion without paying the cost of being wrong.

A step-up check is asymmetric in exactly the right way. An emailed code, an SMS, or a small card authorisation is a minor annoyance to one genuine customer and a serious obstacle to somebody creating their fortieth account, because it has to be completed forty times with forty distinct identities. That asymmetry is the entire point, and it is why the review band tends to catch more abuse per unit of customer friction than raising the block threshold ever does.

Setting the numbers

Do not start from the vendor's suggested table. Start from what an error costs you in each direction.

Write down two figures. What does one fraudulent account cost, including support time, chargeback fees, and reputational damage? And what does one wrongly blocked customer cost, in lifetime value and in the chance they tell somebody?

For a free developer tool, a fake account costs you a database row and a blocked customer costs you a potential advocate. Be permissive. For a marketplace where a fraudulent seller takes money from a real buyer, the asymmetry runs the other way and strictness is justified, which is the reasoning in the marketplace trust and safety playbook.

Then set thresholds provisionally and measure. Run in shadow mode first if you can: score every signup, log the decision you would have made, act on none of it. After two weeks, look at what you would have blocked and check manually whether those accounts turned out to be bad. That exercise reliably surprises people, usually because the review band is much larger than expected.

Tuning fraud thresholds goes further into moving these numbers against live conversion data.

Different thresholds for different moments

One score, several decisions, because exposure varies across your product.

Account creation is low exposure. A bad account that never transacts costs almost nothing, so be generous here.

First payment is higher. Now there is money and a potential chargeback, and Visa's VAMP thresholds mean disputes carry consequences beyond the transaction itself, as we covered in Visa VAMP 2026.

Payout destination changes are the highest exposure event in most products and deserve a hard stop at a much lower score than anywhere else. This is the classic account takeover payoff, and a false positive here costs one annoyed customer while a false negative costs the money.

A score of 60 can reasonably mean allow at signup, review at first payment, and block on a payout change. Same number, same user, three answers, because the question is different each time.

Log everything that contributed

The part people skip, and the part they regret skipping.

When you block someone, record the score and the individual signals that produced it. Not just "blocked, score 87", but which factors contributed and by how much.

Two reasons. A real customer will eventually be blocked and will email you, and without the breakdown you cannot tell them anything useful or work out what misfired. And systematic false positives hide in aggregates. If a particular corporate VPN is pushing a whole customer's employees into your review band, that is visible in the contributing-signal data and invisible in the score alone.

Log::channel('risk')->info('signup_blocked', [
    'email_domain' => $domain,
    'score' => $risk->score,
    'signals' => $risk->signals,      // the breakdown, not just the total
    'decision' => 'block',
]);

The score is a summary, and summaries are for making decisions quickly. When a decision turns out wrong, you need what the summary discarded.

You can see the full signal breakdown on any check in the docs, and try a live scoring call against your own address on the free VPN detector. Start at the signup check, then extend the same score to the payment layer where the stakes are higher and the signals are harder to fake.