Docs menuAll pages, quickstarts and this page’s contents
DocsOn this page
Mobile
- Androidsoon
- iOSsoon
- React Nativesoon
- Fluttersoon
Glossary
Fraud detection has an unusual amount of jargon for a field whose job is to explain itself. Every term this product uses is defined here, in ordinary words, with what it is good for and where it fails.
Every entry has its own anchor, so anything on the site can link straight to the definition rather than assume you knew it.
The basics
What the product is and the four words you meet first.
- Fraud scoring
- Judging one user action and returning a decision with the reasons attached.
- You send us what you know about a single action, a signup, a login, a checkout, a cashout. We check it against everything we know about that IP, email, phone and device, and send back a verdict plus the evidence behind it. You decide what to do with it. Nothing is blocked on your behalf.
- Event
- One user action you asked us to judge. One call to /v1/score is one event.
- Event names are yours to choose (
signup,trial_start,cashout). Billing counts events, so the free-tool checkers and dashboard views do not count against your allowance. - Score
- 0 to 100. The sum of every check that fired, clamped.
- It is not a probability and it is not a confidence. It is bookkeeping: each check that fires contributes its weight. The useful information is in the reason codes, not the number, which is why we return both.
- Verdict
- allow, review, or block. The thing you branch on.
- By default
allowis under 40,reviewis 40 to 69, andblockis 70 or more. Every threshold is tunable per account. Most signals are deliberately weighted so they cannot reachblockalone, because one fact is rarely enough to convict somebody. - Reason code
- A stable, machine-matchable name for one thing we found.
datacenter_ip,device_reuse,disposable_email. Every firing carries anevidenceobject with the raw numbers behind it, so you can audit a decision rather than trust it. Branch on these rather than on the score. The full list is in the API reference.
Network and IP
Where a request came from, and why that is rarely as simple as a country.
- ASN (Autonomous System Number)
- The id of the network an IP address belongs to. Roughly, which company routes it.
- Every IP on the internet sits inside a network run by somebody: a home ISP, a mobile carrier, Amazon, a proxy seller. That network has a number. ASN matters here for two reasons. It lets us flag an entire proxy provider rather than chasing individual addresses, and it is the thing that separates two strangers who happen to share a device fingerprint, which makes it half of a rung 2 identity.
- Datacenter IP
- An address that belongs to a hosting company rather than a home or phone.
- Real customers browse from a home ISP or a mobile carrier. A signup arriving from AWS or a hosting provider is usually a script, and it is one of the strongest single signals there is. The exceptions are real and worth knowing: corporate VPNs and some privacy tools egress from datacenter ranges too.
- Residential proxy
- A service that routes an attacker's traffic through somebody's real home connection.
- Sold openly, often built from consumers who installed a free VPN or a paid-to-share app without reading what it does. It defeats the datacenter check by design, because the address genuinely is residential. This is the hardest category in the whole field and we say plainly that catching the large commercial ones properly needs a paid data feed we do not yet buy.
- CGNAT (Carrier-Grade NAT)
- Why thousands of unrelated mobile users can share one IP address.
- Mobile carriers do not have enough addresses to give every phone its own, so they put many customers behind one. This is the reason blocking on a shared IP punishes geography rather than behaviour, and the reason velocity thresholds on mobile traffic have to be set higher than intuition suggests.
- Tor exit node
- The last hop of the Tor network, where anonymised traffic re-enters the open internet.
- Exit nodes are published, so detecting them is easy. Deciding what they mean is not. Tor is used by people evading fraud detection and by people evading their government. For a rewards operator, elevating a Tor session is usually right. Calling its user an attacker is not.
Device and browser
How a browser is recognised, and the honest limits of that.
- Device fingerprint
- A hash of a few hundred browser properties, used to recognise the same browser twice.
- Canvas rendering, installed fonts, screen metrics, audio stack, graphics driver. Combined they are often distinctive enough to identify one browser. Often, not always: a default iPhone is genuinely identical to another default iPhone, which is why a fingerprint is an input here and not an identity. See collision risk.
- Agent (or collector, or beacon)
- The small JavaScript file a fingerprinting vendor loads into your visitor's browser.
- Fingerprinting cannot happen on your server, because the properties being measured only exist in the browser. So every vendor in this market ships a script. That has a consequence most dashboards never show you: the script has to load and run before anything can be decided, and a browser extension can stop it. We measured what happens when it does.
- JA4 (TLS fingerprint)
- The handshake gives it away. A fingerprint of how software negotiates an encrypted connection, taken at the network layer.
- Before any web page loads, the client and server agree on encryption. The exact way a client opens that conversation, which ciphers it offers and in which order, differs between Chrome, Firefox, curl and a Python script. JA4 summarises it. The useful part is that it is captured at our edge rather than by JavaScript, so it survives a changed User-Agent, incognito, and a cleared fingerprint, and it cannot be edited by the page. The honest limit: it identifies the software, not the person, so millions of ordinary Chrome users share one JA4.
- Headless browser
- A real browser engine running with no window, driven by a script.
- The normal tool for automating signups at volume. It leaves tells: a
webdriverflag, no configured languages, a distinctive User-Agent. Modern automation frameworks hide most of them, which is why this is one signal among many rather than a test. - Anti-detect browser
- A commercial browser built to give each account a different, convincing fingerprint.
- Multilogin, GoLogin, AdsPower, Dolphin Anty, Camoufox. They exist to defeat exactly the detection described on this page, and they are good at it. We detect the environment rather than the identity: a software or VM graphics driver, farm-grade hardware, a patched native API, an OS claim contradicted by another OS signal. We publish where that fails, and it fails on a profile spoofing the same operating system it actually runs on.
Identity resolution
The difference between a hash and a person, which is most of the work.
- Rung
- Which of three methods produced the identity for this event, best first.
- Rung 1, we replayed a token your server stored, so we remembered rather than guessed. Rung 2, no token, so the identity is the fingerprint combined with the ASN it arrived on. Rung 3, neither available, so you get a one-off id that deliberately links nothing. The rung is returned on every event and it governs how hard the device signal is allowed to hit. Full mechanics in the device identity docs.
- Collision risk
- The measured probability that one identity covers more than one real person.
- Returned as a number from 0 to 1 on every scored event. It exists because fingerprints collide: on our production traffic one iOS Safari fingerprint covers 2.30 different people. Folding the network in takes that to 1.27. Publishing the number lets you decide how much weight to put on a device link instead of assuming it is a person. Fingerprint ship the same class of figure as
confidenceScore. - Device token
- An opaque signed value you store as your own cookie to recognise a returning browser.
- We return one on every scored event. Your server sets it as an ordinary first-party cookie on your own domain and sends it back next time, which lifts the event to rung 1. First-party matters: a cookie set by your backend lasts about 400 days, while anything a vendor sets from its own infrastructure is capped at 7 days on Safari.
- Canonical email
- Every alias that reaches one inbox, collapsed to one string.
bob+1@gmail.com,b.o.b@gmail.comandbob@googlemail.comare one mailbox. Dedupe on the canonical form instead of the address the user typed and the plus-tag farm stops working, without you encoding any provider's rules yourself.
Behaviour and network effects
Signals that only exist across more than one event.
- Velocity
- How many times something happened in a short window. Speed as a signal.
- Five accounts from one IP in ten minutes, or twenty events from one device. A single signup tells you very little; the same signup twelve times in a minute tells you a great deal. Windows are ten minutes by default and the thresholds are yours to change. Watch out for CGNAT here.
- Cross-network fraud graph
- Shared intelligence: an entity burned on one operator's site arrives already known on the next.
- Opt-in, and off by default. When two operators both enable it, an email, IP or device that one of them confirmed as fraud raises the score for the other. Two things keep it honest. Entities are shared as peppered HMAC hashes, never as raw addresses, so nobody learns another operator's customer list. And an identity is only allowed to cross when its collision risk is low enough to defend, which today keeps iOS Safari devices out entirely.
- HMAC, peppered
- How a shared entity is hashed so it can be matched but not read.
- An HMAC is a one-way hash with a secret key mixed in. The pepper is that secret, held server-side and never shipped to anyone. The effect is that two operators can discover they have both seen the same email address without either of them, or us, being able to turn the shared value back into an address, and without an attacker being able to confirm a guess by hashing it themselves.
- MX record
- The DNS entry that says where a domain's email is delivered. No MX, no mail.
- A cheap, decisive check: if a domain has no mail server, the address on your signup form cannot receive anything, so it was never going to be confirmed.
A term we use somewhere and did not define here is a bug. Tell us at support@kaidn.io and it gets added.