Identity verification best practices

Here, you can learn about the out-of-the-box solutions that come with every identity verification policy template.


Identity verification is a complex process that usually involves more than just identity establishment.

While establishing trust in online identities is the main focus, you should also

  • know how to combine risk evaluation techniques for your benefit
  • determine the success threshold customers should pass to get verified
  • have an easy way to obtain customer consent and handle data collection
  • pass customer information down to risk evaluation services
  • guide customers throughout the whole process

There are a few best practices we've included in the identity verification policy templates so you can stay focused on building the journey while adding the rest of the capabilities as you go. You can also use default configurations to your benefit.

Table of contents

Identity verification templates

When you create a brand new identity verification policy, you will have a template on your hands that includes some pre-canned configurations:

Verification steps

You can build the verification customer journey in the 'Verification Steps' section where you will find ready-to-add risk evaluation and data collection steps:

Default verificaiton step settingsDefault verificaiton step settings

Notification and failure messages

The notification and failure messages are enabled by default and put into the right places of the identity verification journey.

Each step contains default messages inside that you can use as a draft for creating your own messaging:


Default verification notification and previewDefault verification notification and preview

Failure message

Default failure message and previewDefault failure message and preview

Consent collection

By default, explicit consent collection is configured with a checkbox to let customers deliberately confirm their agreement.


In the identity verification workflow, obtaining consent from customers is always mandatory.

Default consent collection setupDefault consent collection setup

Phone number risk evaluation

Phone number evaluation has a fixed spot in the verification journey: if enabled, it always comes before any other verification step. This setup allows you to filter out risky phone signals and detect recent SIM card changes (that are indicators of SIM swap attacks) before letting a customer move forward with identity verification.

Verification stepsVerification steps

We've also added information about each line type's risk level inside the phone number evaluation step.

Phone risk evaluation optionsPhone risk evaluation options

Data display & collection

The 'Verification data collection & display' step comes with pre-configured customer data fields to help you get a hold of this type of verification step and adjust it to your own needs.

Default data display & collection fieldsDefault data display & collection fields

Compound address field

In the 'Verification data collection & display' step, you can add a compound address field to the customer journey. The compound address field is made up of individual attribute fields that are already selected and assigned a governing native claim when you start configuring the field:

Compound address field configurationCompound address field configuration

In the data collection step, customers can type in a few letters of their address to search for it and then select it to auto-fill the appropriate fields:

Compound address customer experienceCompound address customer experience

Knowledge-based verification

In a knowledge-based verification (KBV) step, customers go through a series of questions to answer in order to affirm their identity. These verification exams are created based on the customer information handed off to the third-party credit bureau that takes care of generating questions.

Personal information is collected with attributes from customers and handed over to the third-party verification service with the help of native claims.

When adding a new KBV step, claim mappings are already configured by default for each attribute:


Example If the 'Given name' native claim is set to the attribute that collects the customer's given name at registration or data collection, knowledge-based verification will receive the given name of the customer and use that information to generate a questionnaire.

The more attributes you have configured for KBV, the more relevant questionnaire the customers will receive.

Default claim mappings for knowledge-based verificationDefault claim mappings for knowledge-based verification