Affirm Risk Policy Builder

The Affirm Risk Policy Builder is the Control Center workspace where administrators define policy evaluation rules that drive verification outcomes. Instead of configuring escalation inline on each workflow step, you build a Policy Evaluation Kit once and assign it to one or more workflows. The kit decides Pass or Fail for each verification action, based on the risk signals that the platform emits as a verification runs.

Available in 11.3

The Affirm Risk Policy Builder is available in HYPR 11.3 and later. Contact your HYPR representative to enable it for your tenant.

Screenshots are sample defaults

Every screenshot on this page shows the default rule set the Risk Policy Builder ships with for the verification actions a representative tenant has enabled. Step names (Phone Number Or Email, Location, Verified Credential, Document and Biometric Verification Step, etc.) and the default rule names within each action (Phone/Email Pass, Location Pass, IDV Outcome Pass — Single Document, etc.) are consistent across tenants. The specific predicates, signals and rule sets in your tenant depend on which steps and features your tenant has enabled in its verification flows. Your defaults can include more or fewer actions than shown here.

For actions whose rules a kit can edit, each rule, condition and group has a trash icon to delete it, and every group has + Condition, + AND group and + OR group controls. + Add rule creates a new rule for the action. Other actions keep the built-in rules: the kit changes only their retry budget or, for some actions, the retry budget plus each Fail rule's action, escalation reason and redirect URL.

For the conceptual model behind risk-signal escalation and how it differs from approver-chain escalation, see Escalation.

Where It Lives

The Risk Policy Builder is a tab inside HYPR Affirm in Control Center. To open it, click HYPR Affirm > Affirm Risk Policy Builder.

The landing area introduces the parts a kit combines (Policy Evaluation, Risk Signals and Escalation Paths) and provides the + New Policy Evaluation Kit entry point. After at least one kit exists, the tab shows a kit list with search and per-kit quick actions.

How a Kit Is Structured

A Policy Evaluation Kit is a per-tenant policy object. For each verification action a kit can configure, it defines the following:

• Risk Signals: The platform-emitted observations the kit can read for that action (for example, IP Allowed for the Location action, or Face Match and Spoof Detection for the Document and Biometric Verification IDV Outcome action). Signals are read-only and provided by the platform; the kit configures how to interpret them.
• Action Retry Budget: The per-action retry envelope (Max attempts and time Window) within which the kit's evaluation applies.
• Evaluation Rules: Ordered Pass or Fail rules. Each rule has a name, a predicate (built from Risk Signals with operators and AND and OR groups), a result (Pass or Fail) and, for Fail results, an action (for example, Deny). For actions whose rules a kit can't edit, the built-in rules apply.

A kit ships with built-in defaults for every action. Administrators customize the defaults rather than starting from an empty kit.

Creating a Kit

On the landing area, click + New Policy Evaluation Kit, then enter a name and an optional description. When the kit is created, Affirm applies the built-in default policies to every action.

After the kit is created, the editor opens on the first action so you can review and customize the kit. The built-in defaults are a starting point. How much of an action you can change depends on the action:

• For actions whose rules a kit can edit, you can edit, replace or remove each rule and condition, and change the retry budget
• For some actions, you can change the retry budget and each Fail rule's action, escalation reason and redirect URL, while the rules themselves stay built in
• For the other actions, you can change only the retry budget

The Kit Editor

The kit editor has two panes: an Action Navigator on the left that lists the verification actions a kit can configure, grouped by step type, and a per-action detail pane on the right.

Use Expand All and Collapse All in the navigator to show or hide the actions of each step type. The badge next to each step type is the action count; the badge next to each action is the rule count.

The top-right of the editor shows the kit's name as a drop-down menu with the following options:

• Edit metadata: Open a modal to update the kit's display name and description
• Duplicate in new tab: Open a copy of the kit in a new browser tab for parallel editing
• Delete orchestration: Delete the kit (with confirmation)

The Edit metadata modal.

The top-right of the editor also has Reset to defaults (restores every action in the kit to the built-in defaults) and Save changes (kit-wide). For how saving and resetting work, see Saving and Resetting.

Configuring an Action

Select an action in the navigator to open its detail pane, which has the following sections.

Risk Signals

This read-only card, headed Risk signals with a count, lists the signals that kit rules can use for that action. An action can emit more signals than the card shows. Each signal has a name and a type (BOOLEAN, STRING, etc.). Predicates inside Evaluation Rules can reference only signals that appear here.

Signal availability varies by action. The card appears for actions whose rule conditions a kit can edit: the Location action exposes three signals, and the IDV Outcome action exposes its per-document check signals, grouped as Document 1 and Document 2. For other actions, the panel says that the action's rules use system defaults. The exact set of signals depends on which features are enabled for your tenant.

Action Retry Budget

The retry budget has the following inputs:

• Max attempts: The maximum number of attempts allowed at this action within the time window
• Window (minutes): The time window the Max attempts counter applies over

For actions whose rules a kit can edit, a Reset to defaults button restores the action's rules and retry budget to the built-in defaults; the + Add rule button next to it creates a new Evaluation Rule for the action.

Evaluation Rules

This section holds the ordered list of rules the kit applies for this action. Each rule has a header showing the rule name, the result badge (PASS or FAIL) and, for a FAIL result, the action arrow and action badge (for example, FAIL → Deny). Click the chevron to expand a rule for editing.

An expanded rule has the following editable areas:

• Rule name: Administrator-supplied label
• Result: Pass or Fail
• Action: Only shown when Result is Fail; the action to take on failure. See Available Actions on a Fail Rule.
• Predicate: The condition tree (see Building Predicates)
• Escalation reason: Only shown when Result is Fail and Action is an escalation type; a required reason shown to approvers during live chat
• Redirect URL: Only shown when Result is Fail and Action is Redirect immediately; the required URL the requester is sent to

Drag the handle on the left of a rule's header to reorder rules. Rules evaluate in display order; the first rule whose predicate matches determines the action's outcome.

Available Actions on a Fail Rule

A Fail rule can take one of the following actions.

• Deny: Terminate the verification immediately with an Unverified outcome
• Escalate immediately: Pause the flow and route the verification into the escalation approver chain
• Redirect immediately: Terminate the verification and redirect the requester to the Redirect URL set on the rule
• Continue on failure (escalate): Let the verification continue through subsequent actions but flag it for escalation at the next attestation point
• Continue on failure (deny at end): Let the requester finish the flow before the denial applies

When the Action is an escalation type, the rule editor also shows a required Escalation reason field. Approvers see this message during live chat, so the escalation approver knows which rule fired.

Sample: a Fail rule with Action set to Escalate immediately, showing the Escalation reason field at the bottom for approver context.

Building Predicates

A predicate is a tree of conditions combined with AND and OR group nodes. The leaf of the tree is a single condition of the form:

Risk signal Operator Value

• Risk signal: Picked from the action's available signals

  

• Operator: One of equals, not equals, greater than, less than, greater or equal, less or equal, in, contains. BOOLEAN signals offer equals only, and signals with a fixed set of values offer equals, not equals and in.

• Value: The literal to compare against. For BOOLEAN signals, a true or false drop-down. For STRING signals, a free-text input (or, where the signal enumerates allowed values, a drop-down of those values).

  

To combine multiple conditions, wrap them in an AND group (all child conditions must be true) or an OR group (any child condition is true). Groups can nest: an AND group can contain OR groups, and an OR group can contain AND groups. A kit can therefore express complex policies such as "the country must not be on the block list AND (the requester's IP must be allowed OR the location must be within the distance threshold)".

Each group has the following buttons:

• + Condition: Add another single condition at this level
• + AND group: Nest an AND group at this level
• + OR group: Nest an OR group at this level

For example, when network and location policy controls are enabled for your tenant, the Location action's sample default Pass rule is an AND of three signals (Country Block List EQ false, IP Allowed EQ true, Distance Threshold EQ true).

The same Location action also ships with sample Fail rules, one for each of those signals, each with the Continue on failure (deny at end) action by default.

Reading the IDV Outcome Action

The IDV Outcome action (Requester Requests Idv Outcome in the Action Navigator) is the most expressive action a kit can configure. Its rules use the per-document check signals, such as Face Match, Spoof Detection and Not Expired, under Document 1 and, when Dual Document Verification is enabled, Document 2. The sample default rules cover both single-document and dual-document flows.

To fail on a specific check, add a Fail rule on that check's signal, for example Face Match EQ LOW under Document 2.

These rules are starting points. A high-security tenant can tighten the predicate with additional checks on signals such as No Sanctions or Spoof Detection. A lower-friction tenant can choose Escalate immediately rather than Deny on a Fail rule, so a person reviews the verification before it is denied.

Saving and Resetting

The editor has the following save and reset controls:

• Save changes (top right of the editor) persists every edit across every action in the kit
• Reset to defaults (top right) restores every action's rules and retry budget to the built-in defaults; the Reset to defaults button in an action's panel restores only that action

Unsaved edits are preserved as you navigate between actions, so you can review and tune multiple actions before you save. When you iterate on a kit, use Duplicate in new tab from the kit drop-down: keep the original open in one tab and experiment in the duplicate.

Assigning a Kit to a Verification Flow

A kit takes effect only when it is assigned to a verification flow. To assign a kit:

1. Open the verification flow's editor.
2. Go to Advanced Customization > Risk Policy.
3. From the Policy Evaluation Kit drop-down, choose the kit.
4. Click Save to save the flow.

See Creating and Managing Verification Flows → Advanced Customization.

A workflow uses one kit at a time. Workflows without a kit fall back to platform default behavior.

Policy Ledger and Observability

Every verification flow that runs against a kit produces a policy ledger record: a per-flow audit of which rules fired, which signals matched and what action was taken. The ledger is appended to the Activity Log for the verification flow, and you can also retrieve it with the Affirm API. For how the policy ledger correlates with the rest of Affirm observability, see Observability and Workflow ID.

Related

• Escalation (concept) — risk-signal escalation versus approver-chain escalation
• Escalation Policy — risk-signal policy outcomes as they appear in the Activity Log and Audit Trail
• Network and Location Policy — the Location action's policy controls covered from the network and location perspective
• Creating and Managing Verification Flows — assigning a Policy Evaluation Kit to a workflow
• Activity Log — per-verification record where the policy ledger is appended
• Verification Status Values — the canonical outcome values rules drive toward