Policy Manager / Rules Engine

The Policy Manager is where you define the rules that determine the outcome of each step in a workflow. When a user completes a step, the policy engine evaluates the results from that step's checkers against your rules and produces a decision: approve, deny, or obligate (route to a step-up).

How It Works

Accessing the Policy Manager

Click any step node on the Builder canvas to open its side panel, then select the Policy tab. You'll see four collapsible sections, each showing its rule count:

Default Rule – the fallback behavior when no other rules match
Deny Rules – rules that block risky or invalid transactions
Approve Rules – rules that approve transactions meeting your criteria
Obligate Rules – rules that route the user to an additional step for further verification

Rule Evaluation Order

Rules are evaluated in a specific hierarchy:

Deny Rules are evaluated first. If any deny rule matches, the transaction is denied immediately.
Approve Rules are evaluated next. If an approve rule matches, the transaction is approved.
Obligate Rules route the user to a specified additional step.
Default Rule fires only when no deny, approve, or obligate rule matches.

This means deny rules always take precedence – a transaction cannot be approved if a deny rule condition is satisfied.

Rule Structure

Every rule (except the default) uses an IF / THEN structure:

IF defines one or more conditions. Conditions can evaluate either the result of a policy group (Pass, Fail, etc.) or the value of a specific attribute (using comparison operators).
THEN defines the action: Approve, Deny (with optional inline retry), or Obligate to a specified step.

Conditions within a rule can be combined using Or and And operators to build complex logic. Nested conditions are supported – a top-level group condition can contain sub-conditions with their own Or/And logic.

Creating Rules

Default Rule

The Default Rule defines what happens when no other rules match. It's always present and cannot be deleted.

To configure it, expand the Default Rule section and set:

Action – Deny, Approve, or Obligate (dropdown)
Inline retry – toggle on to allow the user to retry when the default action is Deny
Number of retry attempts – how many retries the user gets (e.g., 2)
Retry message – the message shown during retry (e.g., "We were unable to confirm your information. Please check and retry.")

Deny, Approve, and Obligate Rules

The process for creating deny, approve, and obligate rules is the same – only the THEN action differs.

To create a rule:

Expand the relevant section (Deny Rules, Approve Rules, or Obligate Rules).
Click "+ Add new rule." A new Custom Rule appears.
Build your IF conditions (see below).
Configure the THEN action:
- Deny – optionally enable inline retry and set the retry count and message
- Approve – no additional options
- Obligate – select the target step the user will be routed to

Each rule can be deleted (trash icon) or reordered (drag handle). Use Expand all / Collapse all to view or hide the full condition tree.

Building Conditions

Conditions come in two types:

"The result of" conditions evaluate a policy group's outcome. You select a group, then set the expected status. Available statuses are:

Pass – the group's checks passed
Fail – the group's checks failed
Unverified – the checks could not be completed
Warn – the checks returned a warning
Close – the checks returned a close/match signal
Partial – the checks partially passed

You can select multiple statuses for a single condition (e.g., "Unverified" and "Pass" both checked).

"The value of" conditions compare a specific attribute against a value using comparison operators. This is useful for evaluating acquired data or inputs directly – for example, checking whether the device platform is not a desktop browser.

Available comparison operators:

Equal to
Doesn't match
Not equal to
Matches
Greater than
Less than

Available value state operators:

Null / Not null
Blank / Not blank

When setting the comparison value, you can pull it from three sources (shown as tabs in the value picker):

Input – user-provided data from the current or another step. Select a step, then browse available input fields (e.g., Name > First Name, Middle Name, Last Name, Suffix).
Acquired Data – data returned by a checker in another step. Select a step, then browse the checker's acquired attributes (e.g., Document + Selfie Match – Incode > Document Type, Name > First Name).
Custom value – a hardcoded string you type in directly (e.g., "browser_computer").

Combining Conditions

Use Or and And buttons to add conditions to a rule:

Or – the rule matches if any of the Or conditions are true
And – the rule matches only if all And conditions are true

Conditions can be nested. For example, a top-level group condition can contain sub-conditions joined by Or, and the entire group can be joined to another condition by And. This lets you build logic like: IF Session Risk (High) passes AND (Aggregator Presence Check OR Malware Check OR Tor Network Check OR Tor Exit Node Check OR Session ID Replay Check OR IP Address OFAC Check all pass/are unverified) AND Device type is mobile, THEN Approve.

Policy Groups

Policy groups are reusable condition bundles that package one or more checks into a named unit. Instead of building the same set of check conditions across multiple rules, you define a group once and reference it wherever needed.

Adding a group to a rule:

When building a condition, click the "Add group..." area to open the group selection popover. The popover shows two sections:

Workflow Policies – groups already used in this workflow (e.g., "Session Risk (High), ThreatMetrix Advanced")
Templates – pre-built group templates available across workflows (e.g., "*CF - The person is located in the US.", "*CF - ThreatMetrix country is US or MX", "Device + credential trusted in last 12 months")

Use the Search groups bar to filter, or click "Create new" to build a custom group from scratch.

Creating a new group:

The Create new group dialog asks for:

Name – a descriptive name (e.g., "Session Risk (High), ThreatMetrix Advanced")
Description – what the group checks for (e.g., "Standard session risk component for ThreatMetrix Advanced.")
Category – classification (e.g., Risk). Categories help organize groups and are shown as color-coded badges.
Type – Or / And. Determines whether the group's internal conditions use any-match (Or) or all-match (And) logic. The default is Or ("Any of the conditions can match").

Editing an existing group:

Click the gear icon (⚙) on any group condition in a rule to open the Group settings popover, where you can update the name, description, and category. Click Save Changes to apply.

Best Practices

Start with the default rule. Set it to Deny with inline retry enabled. This ensures that if no other rules match – whether due to a misconfiguration, an edge case, or missing data – the transaction fails safely rather than silently approving.

Put your strongest deny signals first. Since deny rules are evaluated before approve rules, configure deny rules for your highest-risk signals (TOR detection, OFAC-sanctioned IPs, known fraud indicators) so they block immediately.

Use policy groups for reusability. If you find yourself building the same set of conditions across multiple rules or steps, extract them into a named group. This keeps rules readable and makes updates easier – change the group once, and every rule that references it picks up the change.

Name groups descriptively. A group named "Session Risk (High), ThreatMetrix Advanced" tells you exactly what it evaluates. A group named "Risk Check 1" doesn't.

Be intentional about Or vs. And. Or conditions are inclusive (any match triggers the rule); And conditions are strict (all must match). Mixing them with nested sub-conditions is powerful but can get complex – test thoroughly.

Use "the value of" conditions for edge cases. When you need to evaluate a specific attribute value (e.g., device platform, country code, or a score threshold), use a value-based condition with the appropriate comparison operator rather than trying to force it into a group-based result check.

Test with known personas. Use your test personas (e.g., Jane Sandoval) to validate that rules fire as expected. Check the Transaction Details Report to see which rule was the deciding rule and whether conditions were satisfied.

Interpreting Results in Policy Context

After a transaction completes, the Transaction Details Report shows exactly how the policy engine evaluated each step. This gives you a clear audit trail for every decision.

What you'll see per step:

Which rule fired and whether it was the deciding rule (shown as a badge)
The full IF/THEN logic displayed with the actual values from the transaction, so you can trace exactly which conditions were satisfied or not
Status banners indicating the outcome:
- A pink/red banner shows when conditions were not met (e.g., "None of the following conditions were satisfied, so the action for this rule was not executed")
- A green banner when conditions were satisfied and the rule's action was applied
Multiple rules shown in sequence – if a step has multiple rules, you can expand "Show additional rules" to see how each one was evaluated, even the ones that didn't fire

Example:

An obligation rule on a PII Validation step might show: IF Name > First Name was equal to "Adam" OR Name > Last Name was equal to "Westfall," THEN Obligate to 1b. MobileMatch – OTP. If neither condition matched, the banner reads "None of the following conditions were satisfied, so the action for this rule was not executed," and the engine moved to the next rule in the hierarchy.

This level of transparency makes it straightforward to debug unexpected outcomes, validate that rules are working as designed, and explain policy decisions to stakeholders or auditors.

For more on investigating individual transactions, see