How per-account behavioral scoring works.
The model does not compare your user to a global population. It compares them to themselves.
Four layers, one synchronous score.
The architecture is designed around one constraint: the score must return before the authorization path times out. Event ingestion accepts a REST POST or webhook callback. The event is routed immediately to the per-account model store, where that account's behavioral baseline lives. The scoring engine reads the baseline and evaluates the deviation signature of the incoming transaction. The response returns risk_score, confidence, and contributing_factors inline, with p50 latency under 8ms.
Model updates run asynchronously and never block the scoring path. Each settled transaction, along with its outcome, feeds back into the account's baseline. This means the model's sensitivity to card-testing bursts, account takeover sequences, and MCC-shift signals improves continuously with each transaction, without adding latency to future scoring calls.
Async webhook events fire when a post-authorization signal changes the risk picture: chargeback filed, account flagged externally, or a pattern cluster identified across accounts. This closes the feedback loop without requiring you to poll for updated scores.
What the model learns per account.
Every account builds its own behavioral profile from observed transaction history. The model never compares an account against a global population baseline. It compares each new transaction against what that specific account has done before.
Time-of-day and day-of-week distributions. Velocity windows at 1 minute, 5 minutes, 1 hour, and 24 hours per account.
MCC code mix the account typically transacts with. Deviations to new merchant categories receive elevated deviation scores.
The account's typical transaction size range and percentile distribution. Outliers in either direction contribute to deviation.
Device fingerprint and IP range history. New device plus new IP in the same session is a strong deviation signal.
Country and city-level location history. Sudden geographic jumps relative to prior transaction history are flagged.
Transaction count and volume within 1-minute, 5-minute, 1-hour, and 24-hour rolling windows, compared against account history at each window.
Score output and contributing factors.
Each scoring response returns a risk_score from 0 to 1, a confidence value reflecting how much transaction history the model has for this account, latency in milliseconds, and an array of contributing factors explaining which behavioral signals drove the score.
Factor strings are human-readable and intended for your risk team to act on, not just log. A score of 0.04 with factors like amount_within_account_norm and known_device means the transaction looks consistent with account history. A score of 0.92 with new_device_and_location and atypical_merchant_category means the account's behavioral pattern shifted, which is the signal that precedes most account takeovers.
Pass threshold. Transaction matches behavioral baseline. No action required.
Review threshold. Elevated deviation. Route to manual review queue or add step-up authentication.
Block threshold. Strong behavioral deviation. Decline or hold pending verification. Your thresholds, your rules.
See the score on your own transaction data.
Request API access and we will issue your sandbox key within one business day. The synthetic transaction generator lets you test against known card-testing and ATO scenarios before you flip to live mode.
Request API access