Probability of fraud
Every event gets a probability that it is fraud, from 0% to 100%, with the arithmetic that produced it. It is built on your rules and their weights, and it sharpens as your team gives verdicts.
How the number is calculated
- Start from the base rate. How often this kind of event (a payout, a login) turns out to be fraud in your workspace. Until you have history, a conservative industry default is used (0.8% for payouts).
- Each piece of evidence multiplies the odds. For every rule that fired, pattern that matched, and trust signal, Sieve asks: how much more often does this appear on fraud than on honest customers? That ratio multiplies the odds. A payout to an account three other customers also use might be ×30; an established, verified customer is ×0.35.
- Overlapping evidence is discounted. Signals that describe the same behaviour (a pattern and the rules inside it) are not counted twice: the second and later ones count for less. Protective evidence always counts in full.
- Calibrate. Once you have 20 fraud and 20 legitimate verdicts, the result is calibrated against what actually happened, so “30%” really means fraud about 3 times in 10. The Rules → Learn from verdicts page shows the calibration chart.
In log-odds: z = logit(base rate) + Σ discount × ln(ratio), then P = σ(a·z + b) with a and b fitted on your verdicts.
Where the ratios come from
Before you have verdicts, a rule’s ratio is derived from its weight and how strongly it fired: your weights are the expert starting estimate, so tuning a rule changes the probability immediately. As verdicts arrive, each rule’s ratio is measured from your own data and blended with that estimate: a rule that has fired on 5 cases barely moves; one that has fired on 500 is trusted. Watch-mode rules count as evidence too, so a rule on trial still informs the probability without affecting the verdict.
Verdicts come from cases you close, events you label, POST /v1/feedback (with a source such as chargeback; a late fraud report overrides an earlier “legit”), and historical labels you import. Allowed events that nobody disputes for 45 days (adjustable in Settings) count as legitimate, except for customers with confirmed fraud, an open case or a hold: fraud that slipped through must not be learned as good behaviour. A small random audit of allowed events (Settings) measures how much fraud gets through.
Learning settings
Two settings, in Settings next to the probability mode and lines, shape what the model learns from and how you find out what it misses.
| Setting | Default | What it does |
|---|---|---|
| Presume legitimate after | 45 days | An allowed event nobody has disputed is learned as legitimate once it is this old. Set it past your chargeback and complaint window (14 to 180 days), so fraud reported late is not first learned as good behaviour. Customers with confirmed fraud, an open case or a hold are never presumed legitimate. |
| Random audit | 0.2% of allowed events, at most 10 a day | A small random share of events Sieve allowed opens a low-priority Random audit case, so a person checks activity nothing flagged. Up to 5% and 500 a day. |
Audits matter because every other verdict comes from something Sieve (or a customer) already flagged, and that can never show what slipped past unnoticed. From audited verdicts, Rules → Learn from verdicts estimates the share of allowed events that were fraud, with a range, and how many that means in the last 30 days. The same page shows how the model would have done on traffic it had not seen: it is trained on older verdicts, tested on newer ones, and compared with your rules alone at review rates of 0.5% to 5% of events.
Beyond the rules
Rules only describe fraud someone has already seen. Three more kinds of evidence let the probability notice fraud nobody wrote a rule for, and each is learned from your verdicts like any rule:
- Anomaly. How unlike this customer’s own habits the event is (hour, kind of activity, method, amount size, country, and whether the device, counterparty, payout account or place is new), judged against customers like them when the history is short. A new device alone is ordinary; a new device, a first bank payout and 3 a.m. together are not.
- Near misses. Checks that came within 20% of their limit without crossing it. Several at once is how fraud tuned to stay under every threshold looks.
- Links between accounts. Groups of new accounts joined by shared devices, payout accounts, identities and money passed between them, distance to confirmed fraud, and bursts of new accounts on one IP address or payout account.
When a stronger signal is already counted, the next one counts for less. How much less is learned from how often the two appear together on fraud and on legitimate activity: independent evidence counts in full, near-duplicates barely count.
What you get back
value | The probability, 0–1. |
interval | An 80% range. Wide when the evidence rests on few verdicts; narrow when it rests on many. |
confidence | high, medium or low, from the width of the range. |
evidence | Each step: the signal, its full ratio, the ratio actually applied after overlap discounting, how many verdicts support it, and the probability after it. |
without_strongest_signal | What the probability would be without the single strongest piece of evidence. Useful when a customer disputes a decision. |
expected_loss | Probability × amount, for money leaving: a way to rank a review queue by money at risk. |
anomaly | How unusual the event is for this customer (score in nats of surprise, band), whose habits it was judged against, and the most unusual dimensions in plain English. |
near_misses | Checks that came close to their limit without firing, with how close (closeness, 1 = at the limit). |
Advisory or deciding
By default the probability is advisory: it is shown on every decision, and your rules and score lines make the call. In Settings you can let it also decide: events above your probability review or block line are escalated. It can only make a decision stricter, and never overrides a blocklist, an allowlist or a confirmed sanctions match.