Identity verification step

The Identity verification step is triggered when there is an Identity verification policy tied to an application that determines a the customer needs to verify their identity before continuing. This step can involve either invisible verification (such as data matching behind the scenes) or visible verification (such as phsycial document scans).

Identity verification methods

Strivacity supports multiple identity verification methods, which can be configured in an Identity verification policy. Some of these involve direct interaction with the customer, while others are performed silently in the background.

Customer-facing methods

These verification types require the customer to actively participate in the process:

• Physical document verification:
  Customers take a photo of a government-issued ID and a selfie to prove their identity. This process uses biometric and document authenticity checks.
• Knowledge-based verification:
  Customers confirm their identity by answering challenge questions based on personal data matched against third-party credit bureau records.

Background verification methods

These methods operate silently during the verification step and do not require customer interaction:

• Phone number risk evaluation:
  Analyzes a customer's phone number type and SIM change status to identify risky signals; configurable to restrict certain number types or take action based on the detected risk.
• Phone-based verification:
  Matches personal information provided by the customer against phone carrier records using configurable field criteria.
• Email and physical address risk evaluation:
  Assesses the risk tied to a provided email or mailing address based on known risk signals or reputation databases.

These background checks can be combined with customer-facing methods to strengthen verification outcomes.

Settings that affect this step

The following settings in the identity verification policy configuration impact the customer's experience:

• Enabled identity check types:

  Defines which identity verification methods are used in the flow. You can choose from a list of available methods, including document and knowledge-based verification, as well as background risk evaluation steps like phone or email checks.
• Require customer consent:

  Customer consent is collected by default as part of the identity verification process. When creating an identity verification policy, you're required to select an existing consent from your application's global Consents list.
• Custom messaging:

  Lets you customize the content shown at key moments in the identity verification flow. You can configure a verification notification, which appears at the start of the process and allows you to display a message, optionally collect customer consent, and link to information like your privacy policy. If identity verification fails, you can also display a custom failure message—for example, to offer alternative verification options or direct the customer to support.

What happens next

• If the verification is successful, the customer is redirected back to the desktop and proceeds to the next step in the flow (typically MFA).
• If the verification fails, the customer is shown a failure page. This page can be customized to include next steps, such as retry options or customer support contact.

Extensibility points

Before and after the Identity verification step, the following extensibility points are available:

Before identity verification: This event launches prior to starting the identity verification workflow, allowing data retrieval from an external system for verification purposes without storing the data in the customer’s account. Synchronous hook.

After identity verification: This event launches after the identity verification workflow has finished. It can be used to persist the information gathered during the identity verification process to the customer's account. Synchronous hook.