Phone fraud: risk evaluation step

A step in the Journey Builder is a component used to configure and customize login, registration, or self-service workflows.

The Phone fraud: risk evaluation step allows you to assess the risk associated with a customer's phone number before continuing the journey. The step evaluates several phone-related fraud signals (such as line type or recent SIM changes) and returns success, notAvailable, or failure depending on your configuration. You can also require the customer to have accepted a specific consent before any evaluation takes place.

This evaluation is only available in the US and Canada.

Capabilities

• Evaluates the risk of a phone number using configurable fraud indicators.
• Check whether the customer has accepted a required consent before performing the evaluation.
• Retrieve the phone number from a local variable, context variable, or native claim.
• Route customers along different branches based on success, notAvailable, or failure outcomes.

📘

This step uses the same phone-risk signals that are described in the Phone fraud: risk evaluation section of the Identity verification policy.

If you'd like additional context on these signals and where they are configured at the policy level, you can review that section.

Sample use cases

• Add a fraud check to registration or high-risk login paths to prevent account takeover attempts.
• Block authentication if a phone number appears risky.
• Detect potential SIM-swap fraud and divert customers into a step-up flow.

Configuration

To add a Phone fraud: risk evaluation step to your journey:

1. Open the Journey Builder in the left-hand menu.
2. Create a new journey or select an existing one to edit.
3. Select the + icon and choose Phone fraud: risk evaluation.
4. Select the pencil icon to configure the step. You can optionally rename the step.

The following options can be configured:

1. Consent requirement: Some phone risk checks require explicit customer consent. When configuring the step, select the consent that must be accepted before the evaluation can proceed.
   • If the customer has accepted the consent → The step continues.
   • If no acceptance record is found → The step returns failure and includes metadata describing the reason.
2. Phone number mapping: Choose where the step should read the customer’s phone number from:
   1. Local variable: A variable stored earlier in the journey.
   2. Context variable: Select from available context data in the journey.
   3. Native claim: Reads the phone number from the selected native claim, defined in the identity store.
3. Failure rules: Select the conditions under which the risk evaluation should fail.
If the phone number matches any selected rule, the step returns a failure outcome.
   • You can fail the evaluation when the phone number is classified as:
     • Mobile (not recommended)
     • Land line
     • Fixed VoIP
     • Non-fixed VoIP (more risky; often used by scammers)
     • Other
   • Or fail if:
     • The phone number to SIM-card pairing has changed recently (potential SIM-swap)

Outcomes

This step returns the following outcomes:

• success: The phone number passes all checks.
• notAvailable: The step could not perform the evaluation. For example, the phone number could not be found at the configured source.
• failure: The number meets a risk rule, or a required consent was not accepted.

Notes and limitations

• Consent acceptance must already exist in the customer's account; consent is not collected within this step.
• Accuracy and availability of phone risk signals depend on carrier data providers.
• Phone fraud: risk evaluation is currently only available in the US and Canada.