Set up phone-based verification

Learn how to set up identity verification that affirms customer identities using phone carrier information.

Phone-based identity verification affirms customer identities by matching personal information against a customer’s phone carrier records. Tune the parameters to decide how well the information should match and what actions to take when a match or faliure occurs.

1) Open an identity verification policy.

2) Go to 'Phone-based identity verification' in the policy.

3) Click the + sign to configure the step.

Phone-based verification risk evaluation step configurationPhone-based verification risk evaluation step configuration

4) Inside the step, set up a native claim at 'Phone number availability'.

Phone-based identity verification will use the phone number that goes into the account attribute that’s mapped to the selected native claim.

🚧

Select a native claim that's mapped to an account attribute that's created for collecting a customer's phone number.

Native claim configurationNative claim configuration

Have customers provide their phone numbers at sign-up or include a data collection step in your identity verification flow:

Sign-up

Phone number collection in the registration formPhone number collection in the registration form

Data collection

Phone number collection during the identity verification flowPhone number collection during the identity verification flow

Attribute match

Set up match thresholds and failure rules for each customer attribute.

5) Select one or more attributes you want to use for data matching.

📘

The more attributes you check, the higher the confidence of identity affirmation.

There are 9 different attributes available for matching:

  • Given name
  • Family name
  • Street address
  • City
  • State
  • Postal Code
  • Country code
  • Date of birth
  • National ID

Attribute match configurationAttribute match configuration

Native claim

6) Set up the governing native claim.

🚧

Select a native claim that's mapped to an account attribute that's created for collecting the corresponding customer data.

The customer data that goes into the account attribute mapped to the selected native claim will be checked against the phone carrier records.

Native claim configurationNative claim configuration

Match threshold

7) Set up the success threshold for data matching.

📘

There are 3 different match thresholds you can choose from.

Match threshold configurationMatch threshold configuration

  • 3 - Exact match Require customers to enter details exactly how they have them on record with their carrier. If the data provided by the customer is not identical to the phone carrier records, then attribute matching will fail.
  • 2 - High partial match You allow customers to make a few minor mistakes, like typos, or to enter commonly known variants of their first name, last name, street address, etc.
  • 1 - Partial match: Allows more inaccuracies than just a simple typo. Customers can enter abbreviations or not-so-common variants of their first name, last name, address, etc.

Match threshold action

8) Decide what happens if data matching fails.

Data match failure actionData match failure action

  • Add to attribute failure count If data matching fails, it will add to the verification step's total failure count. If the verification step's total failure count reaches a specified number, the identity verification fails.
  • Fail verification If data matching fails, identity verification will fail immediately, regardless of the total failure count.

📘

Customers will continue with the selected Failure action if they fail phone-based verification.

  • Do not evaluate The data point will not be evaluated.

Attribute match failure count

Set up how many failed data matches result in a failed identity verification.

Attribute match failure count configurationAttribute match failure count configuration

Actions

Decide how the identity verification flow should move forward from either outcome.

  • Success action: the customer can either
    • go to a 'Next verification step' OR
    • can be allowed to log in by selecting 'Exit verification flow'.

📘

In case of a Success action, the 'Exit verification flow' logs the customer into their account.

  • Failure action: the customer can either
    • go to a 'Next verification step' OR
    • can be removed from the flow either by
      • displaying a 'Failure message' OR
      • directing the customer to the 'Exit verification flow'

📘

In case of a Failure action, the 'Exit verification flow' leads to a session timeout.