Create a risk policy

Creating a risk policy lets you define reusable risk decision logic: which signals to query, which rules decide deterministically, and how scoring grades everything in between. Once created, the policy can be selected in adaptive access policies, identity verification policies, and journeys, and invoked from lifecycle event hook code.

Before you begin

• Set up the signal sources you want to use in Risk signal sources. Built-in sources are preloaded; third party sources need credentials and a level mapping before a policy can query them.
• Know where the policy will run. The signals you select determine what the policy needs from the point in the journey where it runs (for example, a signal that requires an identified customer rules out pre-identification use). Check Required data for risk signal inputs as you build.

Create the policy

1. Log in to the Admin Console.
2. From the left-hand menu, select Policies, and then Risk.
3. Select Create risk policy.
4. Add a name and, optionally, a description and a policy tag.

The Required data for risk signal inputs panel fills in automatically as you add signals. It follows from the signals in the policy and decides where in the customer journey the policy can be selected.

Results

Results are the outcomes this policy can return, up to six. Each place the policy is used maps them to its own actions, so you can name them for what they mean, not for the action a particular place maps them to. Typical examples: high / medium / low or step-up / step-down / block for adaptive authentication; pass and fail for identity verification.

1. On the Results tab, select Add result.
2. Name the result.
3. Repeat for each outcome the policy should distinguish.

Signals

Signals are queried in parallel when an evaluation starts. Their outputs become local variables for rules, scoring, journeys, and hooks.

1. On the Signals tab, select Add signal and choose a source from your risk signal sources.
2. Map the source's inputs. Required and optional inputs are declared by the source; supply each from a native claim, context variable, or local variable.
3. Map the source's outputs to local variables, defining new local variables as needed. The signal's normalized level is always available alongside any mapped raw outputs.
4. Decide whether the signal is a Required signal. If a required signal fails (timeout or error after the integration's own retry logic), the entire evaluation ends with an error and the error handling configured where the policy is used applies. If an optional signal fails, evaluation continues: its variables stay unset, it adds nothing to the score, and rules that reference it don't match.
5. Decide whether to enable Query every time. By default, signal results are cached per session and reused when the inputs are unchanged. Enable this option to query the source on every evaluation instead.

Whether a missing signal should invalidate the whole decision depends on its role in the policy: for example, mark a fraud score the policy exists to consult as required, and leave a nice-to-have enrichment optional.

Risk rules

Rules run in priority order. The first match selects a result and ends the evaluation. If no rule matches, risk scoring or the default result decides.

1. On the Risk rules tab, select Add rule.
2. Build the rule's condition from local variables (including signal outputs), native claims, and context variables to be evaluated with comparison operators. Multiple conditions can be combined into a single result with nested AND / OR.
3. Select the result the rule returns when it matches.
4. Drag rules to change their priority.

Rules are optional; a policy can rely on scoring alone.

Risk scoring

Scoring runs when no rule matches. Contributions are added up and the total falls into exactly one band, which selects the result.

1. On the Risk scoring tab, enable Use risk scoring.
2. Under Score contributions, select Add signal to choose which of the policy's signals participate, and assign a numeric contribution to each signal's medium and high levels. None and low contribute 0.
3. Under Score bands, define ascending thresholds and map each band to one of the policy's results. The lowest band starts at 0 and the top band is open-ended, so every score lands in exactly one band. For example: 0 to 29 returns step-down, 30 to 79 returns step-up, and 80 and above returns block.

The score is a simple sum, so you can predict it and explain it afterward. The editor shows the highest possible score: the sum of the highest contributions.

Default result

Scoring is optional; a policy can rely on rules alone. While scoring is off, you must designate one of the policy's results as the default result, returned when no rule matches. This is a normal outcome, not an error.

Save and verify

1. Select Save.
2. Open the place where you plan to use the policy (for example, an adaptive access policy in Risk policy mode) and confirm that it's offered there. A policy is only selectable at points in the journey that can supply the Required data for risk signal inputs.
3. After the policy runs in a test flow, open the event in the Admin Console event log and confirm the recorded result, score, signal levels, and matched rule are what you expect.