Phone fraud: attribute matching step

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

The Phone fraud: attribute matching step validates customer-provided personal information against authoritative phone-carrier records. By comparing key attributes (such as name, address, or date of birth) with the data associated with a phone number, the step helps detect identity mismatch or potential fraud.

This check is available only in the US and Canada.

Capabilities

• Match customer attributes against phone-carrier records linked to their phone number.
• Choose which attributes to evaluate (for example, given name, address, date of birth).
• Set a match threshold per attribute (partial, high-partial, exact).
• Decide how mismatches are handled (fail the verification immediately or count toward a cumulative failure threshold).
• Require customer consent before performing the evaluation.
• Map the phone number from a local variable, context variable, or native claim.
• Configure how many failed matches should cause the step to fail.

📘

For conceptual background about match thresholds and attribute matching, see the Phone fraud: attribute matching section of the Identity verification policy.

Sample use cases

• Confirm ownership of a phone number during account recovery.
• Strengthen verification during high-risk login attempts.
• Add fraud detection checks into a registration flow.

Configuration

To add a Phone fraud: attribute matching 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: attribute matching.
4. Select the pencil icon to configure the step. You can optionally rename the step.

The following options can be configured:

1. Consent requirement: 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:
   • Local variable: A variable stored earlier in the journey.
   • Context variable: Select from available context data in the journey.
   • 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.
   For each available attribute, you can configure:
   1. Match threshold: Determines how strict the attribute comparison should be.
      1. Exact match: The customer-provided value must match the carrier’s record exactly.
      2. High partial match: Allows minor differences such as typos or alternate name spellings.
      3. Partial match: Allows broader variations (abbreviations, formatting differences, etc.).
   2. Risk impact: Defines what happens when this attribute does not meet the match threshold.
      1. Fail verification:
Returns a failure outcome.
      2. Add to attribute failure count: The mismatch increments the cumulative failure counter.
The step fails only when the total failed attributes reach your configured threshold.
      3. Do not evaluate:
The attribute is ignored and does not impact success or failure.
4. Attribute match failure count: Defines the minimum number of attribute matches that must fail before the verification step fails. Only attributes configured with Add to attribute failure count contribute to this total.

Outcomes

This step returns the following outcomes:

• success: All evaluated attributes meet the configured thresholds.
• notAvailable: The step could not perform the evaluation. For example, the phone number could not be found at the configured source.
• failure: A defined attribute meets a failure rule, or a required consent was not accepted.

Notes and limitations

• This step relies on phone-carrier data and is only available in the US and Canada.
• ZIP+4 postal codes are not supported; use 5-digit ZIP codes instead.
• Consent acceptance must already exist in the customer's account; consent is not collected within this step.