Identity verification policies overview
A high-level overview of Strivacity's identity verification features
Identity verification policies consist of one or more of the following modules:
- Custom messaging
- Verification notification and consent collection
- Failure notification
- Risk evaluation
- Phone line type detection
- SIM change detection
- Carrier-based identity affirmation
- Knowledge-based verification
- Data collection
- Data requests from external services (via event hooks)
- Data dispatch to external services (via event hooks)
- Policy workflow preview
Verification notifications allow you to add your brand's communications to the beginning of the identity verification flow. You can provide information for customers as you see fit, share your data privacy policy, and collect customer consent for the proofing and affirmation process.
Verification notifications are made up of two separate parts:
1) Notification text
2) Consent collection
You can choose to include either one of these parts in the identity verification flow
Message display disabled
Implicit consent collection
Verification notification and consent configuration screen. Notification text disabled, choose a consent selected.
Verification notification and consent configuration screen. Notification text enabled, use implicit consent selected.
or stick with the default setting and show both the notification message and consent collection to customers:
Verification notification and consent configuration screen. Notification text enabled, choose a consent selected.
If regulations allow, you can make the notification step completely invisible for customers to minimize friction:
By applying a hidden-implicit notification step, customer consent will still be collected and stored as account information for that customer.
Hidden message and implicit consent collection
Adding a custom failure message allows you to give a potential customer additional options to confirm their identity if the verification process fails.
Risk evaluation helps prevent bad actors from creating accounts by preventing the use of risky phone number or compromised phone accounts.
Phone number risk evaluation allows you to choose which phone number types to allow when performing identity verification. You can prevent the use of certain phone number types such as non-fixed VoIP numbers which are disposable and may indicate the person signing up is not genuine. In this case you can choose to fail the process to prevent risky phone information from being used to affirm an identity.
Phone number risk evaluation configuration screen
Phone-based identity verification affirms a customer's identity by matching the personal information provided by the customer against their phone carrier records. You can choose which fields to use for verification, match threshold information for each field, how many fields must pass, and select fields that must match for a successful verification.
Phone-based identity affirmation configuration screen
Knowledge-based verification affirms an identity by asking for information only the true owner of the identity should know. This works by sending customer-provided information, such as name, address, phone number, etc., to a third-party credit bureau. The credit bureau returns a series of questions that must be answered correctly in order to affirm the person's identity.
The number of questions and the failure thresholds are defined during vendor onboarding. Work with your Strivacity customer success representative to determine what works best for your organization.
Depending on your brand's needs, you may not want to collect personal information unless identity verification is required to create the account. Also, you may not want to maintain this information after identity verification is complete to avoid data retention risks.
The data collection step allows you to collect missing customer data required for identity verification while the verification flow is in progress and discards it after verification is complete. You can also display previously collected customer data gathered from the initial registration step or from external services via lifecycle event hooks.
Finally, you can take a sneak peek at the identity verification flow you've assembled to ensure your flow makes sense and you haven't configured any dead-ends.
Example verification policy workflow