There are a million use cases where you need identity verification. You need to know who your user is when setting up an account, you need to assess risk when granting access, you need to verify identity when recovering credentials, you need assurance of an identity when setting up MFA….the list is endless.
Just as endless is the array of attribute providers and credit bureaus and risk services. Each use case listed above needs to call data from multiple sources to truly verify the user’s identity. You need to be able to verify phone possession and ownership. You need a risk score from a credit bureau and the ability to triangulate data about the user. You need to be able to scan a government ID and match its data to DMV data and a biometric.
There are use cases where you need next to no friction while still having a reasonable idea that the user is who they say they are. There are highly secure use cases where you need undeniable proof of the user’s identity. You need to be able to design a system that checks three factors: what you know, what you have and what you are. And be able to mix and match with all of those attribute providers in the background.
Orchestration and Policy: Workflows Save the Day
An orchestration layer within your identity verification system simplifies this process, I’ll give an example. A gaming company is setting up accounts for their loyalty program; security is obviously paramount because money is involved, but ease of use is essential because customers are involved. And this is happening digitally so the old paradigm of showing an ID doesn’t work.
The policy is set up in three phases:
- Prove possession and ownership of the device being used. If not,
- Answer dynamic knowledge-based questions. If failed,
- Scan government ID and match to a selfie.
There are legitimate reasons for not being able to pass each but if you do pass it, we have very good certainty that the user is who they say they are. You might be using a friend’s phone, you might not know how much your mortgage is, but if you don’t have a valid ID you should not get to have an account.
The reason that the orchestration layer is so important is that process is fantastic for the customer and their users, but it requires a LOT of data from a lot of vendors. Having a single API to call into an orchestration network erases that complexity for the customer while retaining all of the benefits.
The orchestration layer coordinates all of the backend attribute providers and feeds, streamlines the data, and gives back a very simple response as to the user’s identity. The enterprise only needs a single API and interface to verify the identity, despite all of the complexity happening behind the scenes. ID Dataweb’s Attribute Exchange Network (AXN) has built in templates to simplify the process and build the exact identity verification policy you need for the use case.
The Power of a Network: Dynamic Backup of Attribute Providers
Guess what? Attribute providers go down. You don’t want to have your customer onboarding halted when that happens. By having a network of attribute providers, you can failover to a backup vendor for that data without missing a beat…or a customer. ID Dataweb’s Attribute Exchange Network (AXN) allows for having backup providers for almost every identity attribute that you are verifying. As an enterprise, you get the benefit of a single interface, a single contract, and dynamic backups with all of these attribute providers and feeds.
Between the policy engine consolidating all of the varied attribute providers into a single interface and the exchange network providing backup vendors, the AXN platform makes a complex identity verification problem very simple. You get to know who your customers are when you need to.
Between the policy engine consolidating all of the varied attribute providers into a single interface and the exchange network providing backup vendors, the AXN platform makes a complex identity verification problem very simple. You get to know who your customers are when you need to.