Introduction
Defraudo is an anti-fraud platform for online businesses. You send it an event (a payment, a login, a registration) and it answers in real time with a risk score and a decision: allow, review or block.
Scoring is rules-based. Each rule contributes points, and the sum is compared against two thresholds. Device fingerprinting and cross-account linking feed the same rules, so one person opening many accounts becomes visible.
Core concepts
| Concept | What it is |
|---|---|
| Tenant | Your company account. Everything below belongs to one tenant. Raw personal data is never shared across tenants; scoring may use aggregated, cross-tenant reputation confirmations. |
| Project | A scoring scope inside a tenant. Each project has its own API keys, rules, thresholds, webhook URL and data. A tenant can have several live projects and sandbox projects (up to 20 and 3). Sandbox is a separate project, not a mode: rules, keys, thresholds and cases are separate, while account identity is shared across all projects of a tenant. |
| API key | Authenticates a request and resolves the project. Secret keys (ak_) stay on your backend; publishable keys (pk_) are safe in page HTML and can only submit fingerprints. Each key is live or sandbox. |
| Event | One thing that happened, sent to POST /v1/events. Types: payment, payout, login, registration, deposit, withdrawal. The event_id you choose is the idempotency key. |
| Score and decision | risk_score is the sum of the points of matched rules, never below 0. A score at or above the block threshold gives block; at or above the review threshold gives review; otherwise allow. Both thresholds are set per project; a new project starts on the Essentials preset with review 25 / block 250. |
| Rules | Conditions with a band and a score. An active rule affects the score. A shadow rule is evaluated and recorded but never changes the decision, so you can test it on real traffic first. |
| Rule presets | A ready-made rule set a project runs. A new project starts on Essentials; iGaming Standard and iGaming Advanced (enabled per tenant) are also available. |
| Device fingerprint | A stable device id (fp_id) resolved by the server from components your page collects with the browser collector. Pass it in context.fp_id on events. |
| Linked accounts | Accounts that share an email, phone, device, IP or card. Read them with GET /v1/accounts/{id}/links. |
| Trustchain | Allow and deny lists of identities (email, phone, card and more) that you or your analysts maintain; they feed scoring. |
| Cases | A review decision opens a case in a queue. An analyst decides allow or block, snoozes it, or you do it through the API. |
| Webhooks | Signed HTTP callbacks to the project's webhook_url for decisions, case resolutions and snoozed cases returning to the queue. |
Where to go next
- How it works: the path from event to decision.
- Quickstart: your first scored event.
- Integration guide: everything needed to go to production.