Risk policies

A risk policy is a reusable policy that answers one question: given the available risk signals, what should happen? It combines built-in and third party risk signals, precedence-ordered risk rules, and additive risk scoring to produce a named result, entirely through no-code configuration. You define a risk policy once, then use it in adaptive access policies, identity verification policies, journeys, and lifecycle event hook code.

Risk policies extend the risk analysis you may already know from adaptive rules. Instead of a fixed set of built-in checks, you choose the signals (including third party fraud, bot, and IP intelligence services), decide how they combine, and reuse the same decision logic everywhere it's needed.

How an evaluation works

When a risk policy is evaluated:

All of the policy's signals are queried in parallel. Signal outputs are written to local variables and each signal reports a normalized level: none, low, medium, or high.
Risk rules are evaluated in priority order. The first matching rule selects one of the policy's results and ends the evaluation.
If no rule matches, risk scoring adds up the score contributions of the participating signals, and the score band the total falls into selects the result. If scoring isn't configured, the policy returns its default result.

The policy always produces one of its defined results. A policy without scoring must designate a default result, and score bands cover every possible score.

Policy components

A risk policy has four configuration components, each on its own tab of the policy editor:

Results: The outcomes the policy can return, up to six, each with an admin-defined name. Results keep the policy purpose-neutral: the same policy engine serves adaptive authentication (for example step-up, step-down, block), identity verification (pass, fail), and journey branching. Each place the policy is used maps its results to its own actions.
Signals: The risk signal sources the policy queries, with input and output mappings. Sources are defined once at the instance level in Risk signal sources and referenced by any number of policies.
Risk rules: Deterministic conditions evaluated in priority order before scoring. Rules express the certainties you learn from your data (for example, unknown devices from a specific geography are always fraudulent for your business); scoring handles everything the rules don't anticipate.
Risk scoring: A transparent additive model. You assign score contributions to each participating signal's medium and high levels, and ascending threshold bands map the total to a result. This provides you detailed control over how different signals factor into authentication and other outcomes.

See Create a risk policy for the full configuration walkthrough.

Where risk policies are used

Each place a risk policy is used maps its results to its own actions and configures its own error handling:

Where it's used	How it uses the policy
Adaptive access policy	In Risk policy mode, an optional pre-identification policy in the IP-based protection section maps results to Block or Allow, and an optional Authentication policy maps results to Step up, Step down, or Block.
Identity verification policy	The Risk policy evaluation verification step maps results to pass or fail, alongside document and phone-based verification steps.
Journey builder	The Risk policy step exposes one output node per result, plus an error output. The journey branches on the outcome.
Lifecycle event hooks	Hook code can invoke a risk policy and receive its result, score, and the evaluation's local variables.

Signal outputs mapped to local variables during an evaluation follow the platform's existing local variable model: they're readable by journey conditions and steps, and they're passed to lifecycle event hooks.

Ensuring risk policies have needed data

Risk policies run at very different points in the customer journey: before the customer is identified, during authentication, mid-journey, and during identity verification. The data available differs at each point. A signal that needs the customer's phone number can't run before anyone knows who the customer is, and a signal fed by a web SDK can't run at a point with no browser.

Every signal input declares what it needs from the point in the journey where the policy runs, such as Session data, Identified customer, or Web/mobile SDK. A risk policy inherits the combined requirements of its signals, shown as Required data for risk signal inputs in the policy editor. The Admin Console only lets you select a policy at points that can satisfy those requirements, so mismatches surface at configuration time instead of as runtime failures.

Evaluation errors

An evaluation error occurs when a required signal fails to return data after its integration's retry logic is exhausted, or when the platform can't complete the evaluation for internal reasons. A policy whose rules simply don't match is not an error: scoring or the default result covers that case.

The risk policy itself doesn't define error behavior, because the safe response depends on where the policy is used. Blocking is safe at login but wrong for an identity verification step that should route to manual review. Every place that uses a risk policy explicitly configures what happens on evaluation error when it selects the policy, so evaluations never fail open.

Signals marked optional behave differently: if an optional signal fails, evaluation continues. Its local variables stay unset, it adds nothing to the score, and rules that reference it don't match.

Execution and caching

All signals in a policy are queried in parallel, so evaluation latency is bounded by the slowest signal, not the sum.
By default, signal results are cached per session, keyed by source and resolved input values. A later evaluation that reuses the same source with identical inputs uses the cached result. If any input value has changed (for example, the customer has since been identified), the signal is re-queried automatically. Most third party APIs bill per query, so caching avoids paying twice for the same answer.
A per-signal Query every time option bypasses the session cache for signals whose data must be fresh on every evaluation.
Every signal query records operational metrics: the integration, latency, cache hit or miss, retry count, and outcome. When logins slow down, these metrics let you attribute the latency to a specific integration.

Explainability

Every event where a risk evaluation ran records the full decision: the policy evaluated, the result, the numeric score (whenever scoring ran, even when a rule determined the outcome), each contributing signal's level and mapped values, which rule matched and the variable values it used, and which signals failed or were skipped. This detail appears in the Admin Console event log, the Account Events API, and event streaming.

When a customer calls support saying they can't log in, the service rep can see whether and why they were blocked, and fraud teams can feed the same detail into investigations and downstream systems.

Changing and deleting risk policies

The places that use a risk policy hold mappings keyed by its results, so changing results underneath a live reference would silently break those mappings. Therefore:

A risk policy's results can't be added, renamed, or removed while the policy is referenced by an adaptive access policy, an identity verification policy, or a journey step.
When no policy or journey references the risk policy, result edits are allowed. The Admin Console warns you that references from lifecycle event hook code can't be detected and may break.
Deleting a risk policy follows the same rule: blocked while referenced, warned otherwise.