Triggers, heaviest first
Each trigger names the signal, its group, the weight it was given and the confidence of the finding, sorted so the list reads the same way every time.
A score you can explain. Line by line.
The suspect score is not a black box and not a probability. It is the sum of the weights of the signals that fired, returned with each of them, so the answer to "why was this flagged" is always in the response.
- A weighted sumEach signal counted once.
- Every trigger listedWeight and confidence for each.
- Your weightsPer platform and per key.
- Explainable laterThreshold and weights kept with it.
[ 01 / 05 ]How it adds up
Four signals. One number.
Say a request from a browser trips automation (9), tampering (8), a hosting network (6) and high activity (6), all at the default weights. The score is 9 + 8 + 6 + 6 = 29. The default threshold is 30, so the level is medium.
Now raise the weight of automation to 12. The same evidence scores 32 and becomes high. Nothing about the request changed. Only your policy did, and the response records the weights that were in force when it was scored.
- Low below half the threshold, medium from half, high at the threshold
- A score of zero is always low
- Not capped, so far over the line reads differently from just over it
Absent is not zero. An ordinary visitor scores 0. A request whose network lookup could not run has no score at all, and the response says so.
[ 02 / 05 ]The heaviest defaults
Rare and hard to fake weighs more.
Shipped defaults reflect product policy, not a trained model: signals that are rare and hard to fake are heavier, and signals with common innocent explanations are lighter.
| Signal | Web | Android | iOS |
|---|---|---|---|
| Fingerprint suppressed | 16 | 16 | 16 |
| Tor exit node | 14 | 16 | 17 |
| Datacenter proxy | 14 | 12 | 15 |
| Virtual machine | 14 | n/a | n/a |
| Instrumentation | n/a | 14 | 14 |
| Interception | n/a | 14 | 14 |
| iOS simulator | n/a | n/a | 16 |
| Rooted device | n/a | 12 | n/a |
| Automation | 9 | n/a | n/a |
| Tampering | 8 | 8 | 8 |
| Device farm | 7 | 8 | 8 |
| High activity | 6 | 5 | 6 |
| Privacy settings | 6 | n/a | n/a |
| Incognito mode | 4 | n/a | n/a |
The default high-risk threshold is 30 on every platform. Weights run from 0 to 10,000.
[ 03 / 05 ]Built to be audited
Decisions you can defend.
When a customer asks why they were stopped, the reasons are already written down.
The policy at the time
The threshold, where the weights came from and their revision are stored with every assessment, so an old decision still explains itself after the weights change.
Switched off, still visible
A signal weighted zero adds nothing, but it is still listed. You can see that it fired while your policy ignored it.
High scores, pushed
Every request that lands at the high level can be delivered to your systems as a visitor.suspect webhook, with its triggers.
[ 04 / 05 ]Questions
Is the suspect score a probability of fraud?
No. It is a weighted sum of the signals that fired, using weights you control. It says how much evidence is present under your policy, not the chance that a person committed fraud.
Does a high score block the request?
No. The API returns the score, the level and the triggers, and never blocks a request because of them. Your application decides whether to allow, review, challenge or refuse.
Are the weights trained on my data?
Not automatically. Weights are explicit: the shipped defaults or the values you set. High activity and the cross-device device farm signal learn what is unusual from your traffic, but the weights themselves stay yours.
Less guessing. More knowing.
Make the next connection a trusted one.
Start with the signals, keep your own decisions, and pay only for what you identify. No credit card needed.