Risk & decisions

Two separate engines, deliberately kept apart: risk scoring produces an explainable number, and a policy engine turns that number into a decision your application can act on.

Risk scoring

Every event is scored by a fixed set of deterministic, weighted signals — things like unusual velocity (too many events too fast from a device, account, or IP), new-vs-known device, multiple accounts on one device, brute-force or credential-stuffing patterns, and automation heuristics. Each signal that fires contributes its weight to a running total, which lands in the 0–100 score range.

The score is deterministic and rule-based, not machine-learned — there is no model being trained on outcomes, and no black-box component. That score is then banded into a risk level: low, medium, high, or critical. The level is informational; it doesn't directly determine what happens next.

Explainability

Every signal that contributed to a score is named in the response, with a human-readable description. There is no opaque number — you can always see exactly why an event scored the way it did.

The policy engine: score → decision

A separate policy engine maps a risk score to a decision using thresholds you configure per environment in the dashboard:

• allow — proceed normally.
• monitor — proceed, but the event is flagged for your own review.
• challenge — your application should require additional verification of its own choosing.
• block — your application should stop the flow.

Scoring and policy are kept as separate steps deliberately: the score for a given event never changes, but you can retune what decision it produces at any time without touching how risk is computed.

What this is not

• Not an ML-based or statistical risk model — every signal and weight is fixed, deterministic logic.
• Not adaptive — thresholds don't self-tune based on outcomes; you set them explicitly.

Thresholds are only the baseline — you can also layer conditional rules on top (e.g. "never auto-block login events"). See Policy.