Anti-Fraud Platform
Real-time fraud risk decisions on every onboarding and every transaction. Backed by a curated Indonesian rule library, a device intelligence SDK for mobile, and an ML scoring layer that learns from your dispositions.
Scope: fraud, not AML
Anti-Fraud Platform handles application fraud, account-takeover, transaction fraud, and device-level risk. It is explicitly not an AML / sanctions / PEP / SAR product — that's AML Platform →. The two services share customers but maintain separate alert tables and decision policies.
What it does
| Capability | API |
|---|---|
| Real-time risk evaluation | POST /api/evaluate — sub-100ms decision |
| Mobile device intelligence | POST /api/device-session + React Native SDK |
| Jailbreak / root detection | Native iOS + Android probes inside the SDK |
| Native attestation | AppAttest (iOS) + Play Integrity (Android) |
| Allow / block lists | NIK, email, phone, IP, beneficiary, country |
| Configurable rules + ML scores | Combine deterministic rules with ML risk |
| Cases & workflows | Group alerts, route to investigators |
| Custom workflows / automations | Auto-decline · notify · escalate · hold based on triggers |
Core concepts
| Concept | What it is |
|---|---|
| Customer | The user being scored. Anti-fraud reads (never writes) Customer.kycLevel from Identity Platform. |
| Lane | onboarding or transaction. Most rules and thresholds are lane-specific. |
| Evaluation | A single POST /api/evaluate. Produces a decision, a fraudScore, and a list of rule hits. |
| Device session | An SDK-collected device payload with signals + attestation, token-referenced from the evaluate call. |
| Alert | The fraud-side equivalent of an AML alert. Same lifecycle pattern. |
| Rule | Deterministic logic that can fire allow / review / flag / block (and bypass ML when needed). |
| ML score | A per-org learned model that can downgrade rule actions when ML confidence is low. |
| List | Allow / block list keyed by NIK, email, phone, IP, beneficiary, or country. |
| Workflow | Reactive automation triggered by alert creation: auto-decline, notify, escalate, or hold. |
Decisions
POST /api/evaluate returns one of four decisions:
| Decision | What it means |
|---|---|
allow | Proceed. |
flag | Proceed but record an alert for analyst review (post-hoc). |
review | Hold the transaction/application; analyst must clear before completion. |
block | Reject immediately. |
Common integration shape
Onboarding (mobile app)
- 1SDKSDK collects device payload.`@quantum-elixir/device-sdk-rn`.
- 2POST
/api/device-sessionReturns `sessionToken` (30-min TTL). - 3POST
/api/evaluatePass `sessionToken` + customer / application data. - 4Use the decision to gate completion.
Transaction monitoring
- 1POST
/api/evaluate`lane=transaction`, amount, channel, counterparty. - 2Use the decision to gate the transaction.
- 3Subscribe to the `alert.created` webhook for backoffice review.Async — runs in parallel with the decision path.
Endpoints at a glance
| Group | Endpoints |
|---|---|
| Evaluate | POST /api/evaluate · POST /api/test-evaluate |
| Channels | GET/POST /api/channels · GET/PATCH/DELETE /api/channels/{id} — see Channels → |
| Device SDK | POST /api/device-session · GET /api/device-session/{token} · GET /api/sdk-config |
| Customers | GET /api/customers · GET /api/customers/{id} |
| Alerts | GET /api/alerts · GET /api/alerts/{id} · POST /api/alerts/{id}/{assign,escalate,resolve} |
| Rules | GET/POST /api/rules · GET/PUT /api/rules/{id} · POST /api/rules/{id}/{approve,backtest} |
| Cases | GET /api/cases · GET /api/cases/{id} · POST /api/cases/{id}/{notes,reject-customer} |
| Workflows | GET/POST /api/workflows · GET /api/workflows/{id}/runs |
| Lists | GET/POST /api/lists · POST /api/lists/{id}/entries · POST /api/lists/{id}/import |
| Analytics | GET /api/analytics · POST /api/reports · GET /api/metrics |
| Webhooks | GET/POST /api/webhooks · POST /api/webhooks/{id}/test |
| API keys | GET/POST /api/api-keys |
| Health | GET /api/healthz |
Production considerations
| Concern | Answer |
|---|---|
| Data residency | All evaluations, device sessions, alerts, and ML training data live in id-jkt-1. Never replicated cross-border. |
| Latency tiers | Standard p95 80ms · Premium p95 40ms · Enterprise p95 20ms (co-located inside your VPC). See Risk evaluation → Latency. |
| Rate limits | Per-org default: 100 /api/evaluate calls/min on sandbox; per-tier limits up to 20,000/min on production. List imports: 5/min. See Rate limits →. |
| Idempotency | POST /api/evaluate accepts a requestId field — same requestId within 24h returns the original decision row. Use the upstream transaction ID. |
| Device session TTL | 30 minutes from POST /api/device-session. Re-issue rather than extend. |
| ML model | Per-org learned model (anti-fraud:v3). Re-trained nightly on your dispositions. Branded as Quantum AI; internal stack not exposed. |
| Audit | Every evaluate, alert action, rule change, list change, channel change, workflow trigger is audit-logged. Immutable, 7 years. |
| Webhook signing | HMAC-SHA256 over the raw body, header X-AntiFraud-Signature: sha256=<hex>. Suite-wide migration to X-Quantum-Signature on the 2026 roadmap. |
| Customer.kycLevel | Anti-fraud reads kycLevel as a feature; never writes it. KYC tier is owned by Identity Platform. |
Anti-Fraud + Identity together
The most powerful pattern is to pair anti-fraud signals with KYC tier. Customer.kycLevel is owned by Identity Platform; anti-fraud reads it as a feature:
| KYC tier | Anti-fraud default treatment |
|---|---|
none | Higher base risk; almost always review on first transaction |
basic | Standard scrutiny |
standard | Standard scrutiny |
premium | Lower base risk on legitimate-looking transactions; faster auto-allow |
If you want an end-to-end onboarding example that wires Identity + Anti-Fraud together, see Guides → End-to-end KYC onboarding.