How real-time fraud scoring works: from transaction event to ALLOW/REVIEW/BLOCK in under 200ms

Payment platforms cannot afford to pause a transfer while a fraud analyst reviews a queue. Real-time scoring means your checkout, wallet transfer, or card authorization receives a decision in the same HTTP round-trip as the score request — typically under 200 ms at the median for MaiGuard synchronous scoring.

The five stages of a score request

When you call POST /v1/transactions/score, MaiGuard runs a fixed pipeline. Understanding each stage helps you design payloads that produce accurate decisions and explain outcomes to compliance teams.

1. Ingestion — The API validates your payload shape, normalizes field names, and rejects malformed requests before any evaluation begins. Tier 0 payloads (amount + customer ID) work, but richer tiers unlock more signal dimensions.
2. Enrichment — Velocity counters, entity graph lookups, onboarding context, and tenant list matches are applied. This is where a deviceSessionId from the Browser SDK materially improves accuracy.
3. Evaluation — Active rules, ML models, and pattern analysis run in priority order. The first matching rule with the highest priority determines the candidate action.
4. Decision — The engine maps evaluation output to ALLOW, REVIEW, or BLOCK. REVIEW routes transactions to analyst queues without blocking the API response.
5. Response — You receive riskScore (0–100), decision, matchedRules, and optional shadowEvaluation if shadow rules are configured.

What drives latency

Most latency budget is spent on enrichment — especially graph traversals and list lookups when payloads include counterparty metadata. Keep synchronous scoring lean: send the fields your active rules need, defer heavy analytics to batch scoring or webhooks for async workloads.

Global rate limits apply at 100 requests/min per IP, with tenant-scoped limits of 1,000/min for REST scoring paths. See the API Reference rate limits section for canonical values.

Designing for production payment flows

Treat scoring as a gate, not a log. Your integration should branch on decision immediately:

• ALLOW — proceed with settlement or authorization.
• REVIEW — hold or step-up verification; case appears in the analyst queue with full context.
• BLOCK — reject the transaction and surface a customer-safe message.

Include stable userId values that match your onboarding records. Inconsistent IDs break velocity rules and weaken entity graph links across sessions.

Next steps

For a deeper reference on each pipeline stage, see How Scoring Works in the docs. To add behavioral biometrics, integrate the JavaScript SDK and pass deviceSessionId on every score call.