The first thing to establish is that this is a different product category from everything else in identity, bought by a different person for a different reason, and conflating the two produces bad decisions in both directions.
Identity verification proves that a human is who they claim to be. It happens once, usually at onboarding, sometimes again at a risk trigger. It involves a government document, a face, and a decision that carries legal weight. The buyer is compliance, risk or fraud, and the requirement often comes from a regulator rather than from a product manager.
Authentication proves that a returning user is the same one who was here before. It happens every session. It involves a credential, and the question it answers is continuity, not identity. The buyer is engineering.
These get confused constantly, and the confusion is expensive. A team that thinks strong MFA satisfies a know-your-customer requirement has built nothing a regulator will accept. A team that runs a document check on every login has made their product unusable and their bill enormous. Verification establishes the link between an account and a real person. Authentication maintains it. You need both, and they are not substitutes.
The second thing to establish is that this category has one dominant tension: every control you add to stop fraudsters also stops some real customers, and the cost of the second group is invisible in the fraud dashboard.
Key takeaways
- Verification is a one-time proof of identity, authentication is a per-session proof of continuity. The verification result has to be bound to the account and then maintained by your auth system.
- Document verification quality varies enormously by region and document type. A passport with an NFC chip is a cryptographic check; a photograph of a regional ID card is a judgement call.
- Presentation attacks put something in front of the camera; injection attacks replace the camera. Only the second is growing fast, and the defence is device and SDK integrity, not a better liveness classifier.
- Per-check pricing means you pay for the customers you reject and for every retry. False rejections cost you the check fee plus the acquisition cost of a customer who then leaves.
Where verification ends and authentication begins
Draw the line explicitly, because the handoff between the two systems is where implementations fail.
A verification event produces a decision: this document appears genuine, this face matches it, this person appears live, and the extracted identity data is this. What you do with that decision is the design question nobody documents.
Bind the result to an account, not a session. The verification outcome, a reference to the provider’s case, the extracted identity fields you are permitted to keep, and the timestamp all belong on the user record. The session that performed the verification is irrelevant five minutes later.
Decide what re-triggers it. Verification decays. A check from three years ago says nothing about who controls the account today, and account takeover after a legitimate verification is the standard attack pattern precisely because it inherits the trust. Common triggers: a change of bank details, a first withdrawal above a threshold, a device and location combination that has never been seen, a regulatory review cycle. Write the list before launch, because retrofitting a re-verification trigger into a product means asking existing customers to re-verify, and that conversation goes badly.
Do not let verification carry session security. After a successful check the account is protected by ordinary authentication, and if that is a password with SMS recovery then your expensively verified identity is one SIM swap from being someone else’s. Verification raises the cost of creating a fraudulent account. It does nothing about taking over a real one, which is the job of MFA and step-up authentication.
Store as little as you can. Document images and face biometrics are regulated more strictly than ordinary personal data, as special category data under GDPR and under dedicated biometric privacy statutes in several US states with private rights of action attached. The safest architecture keeps the images with the provider, stores only the decision and the minimum identity fields on your side, and has a documented retention period for both. The team that quietly kept every selfie in an object storage bucket has created a liability that grows every day and serves no purpose. Whatever you do keep needs an audit trail with retention that matches your regulatory obligation, which is a log management problem as much as an identity one.
Document verification: the regional reality
The marketing describes one capability. The engineering reality is that document verification is thousands of separate capabilities with wildly different quality, and your pass rate is a function of which passports and ID cards your customers actually hold.
NFC chip reading is a different class of check. Modern passports and many national ID cards contain a contactless chip following the ICAO machine-readable travel document standard, holding the data and the photograph signed by the issuing country. Reading it with a phone and verifying the signature is a cryptographic verification of an authentic document. Everything else is inference from pixels. If your customers hold chip-enabled documents and your app can read them, this is the highest-assurance and lowest-friction option available, and it is worth selecting a provider on this capability alone.
Optical checks are probabilistic. Without a chip, the provider is examining an image for security features, font consistency, layout, the machine-readable zone checksum, and evidence of tampering. That works well for a small number of widely issued, heavily standardised documents and progressively less well as you move down the long tail. A regional ID card from a country the provider has seen a few thousand times gets a weaker model than a passport it has seen millions of.
The variables that actually move pass rates:
- Document type. Passports are the most standardised and generally the most reliable. Driving licences vary by sub-national issuer. National ID cards vary by country and by issue year, since a redesign creates a document the model has not seen.
- Region. Coverage follows the provider’s customer base, so a vendor grown in Europe is stronger on European documents than on South or Southeast Asian ones, and vice versa. This is the single most important thing to test with your own users.
- Capture conditions. Glare on a laminate, a low-end camera sensor, poor indoor lighting, and a cracked screen all degrade the image before any model sees it. Much of the gap between a good and bad provider is capture guidance in the SDK rather than model quality.
- Names and scripts. Transliteration between a non-Latin-script document and a Latin-script account record is a genuine source of mismatch, as are patronymics, multiple surnames, and the difference between a name as printed and a name as stored in the machine-readable zone.
- Edge cases that are entirely normal. Recently married and holding documents in two names. An expired but valid-for-identification card. A refugee travel document. A teenager whose only document is a school ID. Each is a real customer your flow either handles or loses.
Needs first-hand data: Run a shadow evaluation. Send the same real verification traffic to two providers simultaneously for a defined period, accept on the incumbent decision only, and compare outcomes segmented by document type and issuing country. The aggregate pass rate tells you nothing useful; the per-corridor breakdown is where providers differ by margins that change the business case.
Liveness, and the attack that changed the threat model
Face matching answers whether the selfie matches the document. Liveness answers whether the selfie is a live human rather than an artefact. The second is where the arms race is.
Presentation attacks put something in front of a real camera: a printed photograph, a photo on a phone screen, a video replay, a silicone mask. This is the classic threat, the one the ISO presentation attack detection standard describes, and mature providers handle it well. Detection uses texture, reflection, depth cues, micro-movement, and in active liveness a challenge the user must respond to.
Injection attacks do not use the camera at all. The attacker feeds a synthetic or replayed video stream directly into the application through a virtual camera driver, an emulator, a hooked SDK, or a compromised browser. The liveness model receives a perfectly clean, perfectly lit, entirely fabricated face that satisfies every presentation cue, because the physical capture step it was trained to reason about never happened.
This distinction is the most important technical fact in the category right now, for two reasons. Generative models have made a convincing synthetic face cheap, and virtual camera tooling is commodity software. The combination means the attack scales in a way mask-making never did.
The defence is not a better liveness classifier, because the classifier is being fed an image that looks correct. It is establishing that the frames came from a real sensor on a real device:
- SDK and application integrity checks, so a hooked or repackaged app is detected
- Device attestation through the platform’s own attestation APIs, so an emulator or rooted device is visible
- Signals about the capture pipeline itself, such as whether a virtual camera is present
- Cryptographic binding between the capture session and the frames submitted, so a stream cannot be substituted in transit
- Server-side analysis of the submitted media for generation artefacts rather than trusting a client-side verdict
When you evaluate providers, ask specifically about injection resistance and device attestation, not about liveness accuracy. Every vendor has a good answer on presentation attacks. The answers diverge sharply on injection, and a provider whose response is a confidence number rather than a description of the attestation mechanism has told you something.
One more thing worth building in: active liveness challenges that ask the user to turn their head or follow a prompt create accessibility problems for users with motor or visual impairments, and they add friction that shows up in your drop-off numbers. Passive liveness is better user experience and a weaker signal on its own. Most mature deployments run passive by default and escalate to active on a risk signal.
Needs first-hand data: Commission a red team exercise against your live verification flow using a virtual camera injecting a generated face, on both a clean device and an instrumented one. Record whether each candidate provider detects it, and whether it detects the device manipulation or only the media. This is the test that separates the category and it is not answerable from documentation.
Per-check pricing inverts your incentives
Every other product in identity is priced per user or per month. This category is priced per check, and that single difference reshapes the decision.
You pay for rejections. A fraudster who fails verification still costs you a check. So does a legitimate customer whose ID card photograph had glare. Your bill is a function of attempts, not of customers acquired, and a fraud wave is a cost event even when your controls work perfectly.
You pay for retries, and retries are the norm. A first-attempt failure on a document capture is common and usually a capture problem rather than a fraud signal. If you allow three attempts you have tripled the cost ceiling per user. If you allow one you have made a capture problem into a lost customer. The retry policy is a pricing decision disguised as a product decision, and it should be set with both numbers in front of you.
Meters multiply. A document check, a biometric check, a watchlist and sanctions screening, an ongoing monitoring subscription per customer, a manual review, an address verification, a business verification for a KYB flow. These are typically separate meters. The quoted headline price is one of them. Build your model from your actual flow, counting every check a single user triggers on a good path and a bad one.
Manual review is a separate cost with a separate latency. Cases the automation cannot decide go to a human queue, either yours or the provider’s. That queue has a cost per case and a turnaround time, and that turnaround time is your customer waiting. A provider with a slightly lower automated pass rate but a fast, reliable review queue can produce a better outcome than one with the opposite profile.
The false rejection cost nobody puts in the model
Here is the asymmetry that makes this category hard. A false acceptance is visible: fraud loss, a chargeback, a regulatory finding, a number someone reports. A false rejection is invisible: a real customer who tried to sign up, was told their identity could not be verified, and left.
That customer cost you the acquisition spend that brought them, the check fee, and the lifetime value they would have produced. They do not appear in any fraud metric. They frequently do not appear in any product metric either, because signup funnels are often instrumented up to the verification step and not through it.
Three practices make the invisible cost visible:
- Instrument the verification step as a funnel stage, with drop-off measured separately for failed checks, abandoned checks and never-started checks. Abandonment before the first capture is usually the largest bucket and is a user experience problem, not a fraud one.
- Segment rejections by reason and by corridor. A rejection rate that is uniform across regions is a threshold problem. One concentrated in specific countries is a coverage problem, and coverage problems are fixed by changing provider or adding a fallback, not by lowering thresholds globally.
- Give rejected users a path. A dead end at verification turns a recoverable capture failure into a permanent loss. A manual review escalation, an alternative document option, or a human contact route recovers customers that an automated decision threw away.
The threshold that minimises fraud is not the threshold that maximises profit, and the gap between them is usually large. Whoever owns this decision needs both numbers, which means the false rejection cost has to be measured rather than assumed.
Needs first-hand data: Calculate your own cost per false rejection: acquisition cost plus check fees consumed, multiplied by the share of failed verifications that are legitimate customers, which you can estimate from manual review overturn rates. Put that number next to your fraud loss number. Most teams discover the two are closer than the org chart implies.
Veriff
Veriff is a verification specialist with a strong document coverage story and an SDK focused on getting a usable capture on the first attempt, which is where a large share of real-world failures actually originate. Its approach combines automated decisioning with a human review layer, and it has invested visibly in the injection and deepfake problem rather than treating liveness as solved.
For teams whose problem is genuinely verification rather than a broad fraud platform, it is a focused product rather than a module inside something larger.
Pros
- Broad document coverage with per-country capability detail, which is what you need to assess your own corridors rather than a global average
- Capture guidance in the SDK is a real strength, and first-attempt capture quality moves pass rates more than model differences do
- Explicit investment in injection attack and synthetic media detection rather than presentation attack detection alone
- Combined automated and human review means undecidable cases have a path rather than becoming rejections
Cons
- Per-check pricing means fraud waves and retry-heavy flows are cost events regardless of whether your controls work
- Coverage quality is not uniform across regions, so your specific corridors need testing rather than trusting the country list
- Narrower than the platform vendors on ongoing monitoring, business verification and transaction risk
- Enterprise contracting and volume commitments make it heavy for an early-stage product with unpredictable volume
Best for: Teams whose primary need is document and biometric verification across multiple countries and who want a specialist rather than a module in a larger fraud suite.
Pricing: Per verification check, typically with volume tiers and separate meters for additional check types and manual review, under an annual commitment at scale.
Sumsub
Sumsub is the broadest of the specialists, covering document verification, liveness, sanctions and watchlist screening, ongoing AML monitoring, business verification for KYB, and transaction monitoring in one platform with a configurable rules engine. For a regulated business that needs the whole compliance stack rather than an identity check, that consolidation is the argument: one vendor, one audit trail, one place where the rules live.
The corresponding cost is scope. You are adopting a compliance platform, and the configuration surface is sized accordingly.
Pros
- Covers the full compliance flow from onboarding verification through sanctions screening and ongoing monitoring in one product
- Configurable verification levels and rules let different customer segments face different requirements without separate integrations
- Business verification for KYB is a first-class capability rather than a bolt-on, which matters for marketplaces and B2B fintech
- Strong coverage in regions where several Western-grown vendors are weaker
Cons
- Meaningfully more product than a team that only needs a document check, with configuration complexity to match
- Multiple meters across check types, monitoring and screening make total cost harder to forecast than a single per-check price
- The rules engine is powerful and becomes its own maintenance surface, with change control implications for a compliance-critical path
- Breadth means individual capabilities are not always the best available in isolation
Best for: Regulated fintech, crypto and marketplace businesses that need onboarding verification, sanctions screening and ongoing monitoring from a single vendor with one audit trail.
Pricing: Per check with separate meters by verification type, plus subscription pricing for ongoing monitoring per customer under management.
Persona
Persona’s distinguishing idea is that verification should be configurable infrastructure rather than a fixed flow. You build the journey as a sequence of steps with branching logic, so different user segments, risk levels and regions can take different paths, and you can change the path without an engineering release. It also supports bringing your own data sources into the flow rather than being limited to the vendor’s checks.
That flexibility is the reason to pick it and the reason to be careful. A configurable flow is an asset when you have someone who owns it and a liability when the person who built it leaves.
Pros
- Flow builder lets risk and compliance own the verification journey and change it without an engineering release cycle
- Step-level branching means low-risk users get a light path and high-risk ones get a heavy one, which directly reduces false rejection cost
- Supports composing multiple data sources and check types into one decision rather than accepting a fixed pipeline
- Good developer experience and API design relative to the traditional compliance vendors
Cons
- A configurable flow is a production system with no pull request unless you build change control around it, and this path decides who gets an account
- The flexibility rewards teams with dedicated risk operations and penalises those hoping for a sensible default
- Document coverage depth in the long tail of regions needs verification against your own corridors
- Composing multiple data sources means composing multiple meters, and cost modelling gets harder
Best for: Teams with a dedicated risk or compliance function who want to tune verification journeys per segment continuously rather than integrate a fixed flow once.
Pricing: Per check with separate meters by step type, so the effective cost per verified user depends on how many steps your flow runs.
Onfido
Onfido, now part of Entrust, pairs document and biometric verification with a long track record in regulated onboarding, and has been one of the more vocal vendors on the injection and synthetic media problem specifically. Its positioning has historically been enterprise financial services, with the compliance documentation and assurance evidence that audience requires.
The vendor state is worth weighing. Acquisition into a larger identity and security portfolio changes roadmap priorities and packaging in ways that are hard to predict from outside, and this is a long-term dependency in a regulated path.
Pros
- Mature document and biometric verification with the assurance documentation enterprise compliance reviews require
- Explicit focus on presentation and injection attack detection rather than treating liveness as a finished problem
- Long deployment history in regulated financial onboarding, which means the edge cases have been encountered before
- Now part of a larger identity and security portfolio, which appeals to buyers consolidating vendors
Cons
- Acquisition means roadmap, packaging and pricing direction are set inside a larger portfolio rather than by a focused product
- Enterprise sales and contracting motion is heavy for a team wanting to start small and scale
- Coverage strength follows its customer base, so regional performance outside its core markets needs testing
- Narrower than the compliance platforms on ongoing monitoring and business verification
Best for: Regulated financial services onboarding where enterprise assurance documentation and a long production track record carry more weight than flexibility.
Pricing: Per check with volume tiers and separate meters by check type, typically under an enterprise annual contract.
Jumio
Jumio is one of the longest-established vendors in the category, with wide document coverage, an orchestration layer for composing checks, and AML screening alongside identity verification. Its natural buyer is a large regulated enterprise that needs global coverage and is comfortable with an enterprise procurement and integration process.
Its age cuts both ways: a long history means an enormous corpus of documents seen and a lot of encountered edge cases, and it also means a product surface that has accumulated layers.
Pros
- Very wide document and country coverage built over a long operating history, which matters most in the long tail
- Orchestration and workflow capability for composing different check types per risk level
- AML screening and ongoing monitoring available alongside identity verification from one vendor
- Enterprise compliance and certification depth that shortens procurement in regulated industries
Cons
- Enterprise-shaped procurement, integration and contracting, which is slow for a team that needs to ship this quarter
- Accumulated product surface means the developer experience trails the newer API-first vendors
- Per-check pricing with multiple meters and enterprise minimums makes small-volume economics unattractive
- Configuration depth requires internal ownership rather than working well from defaults
Best for: Large regulated enterprises needing global document coverage and AML screening under one contract, with the procurement capacity to buy it.
Pricing: Per transaction with volume tiers and separate meters for screening and monitoring, under enterprise annual agreements with minimum commitments.
Stripe Identity
Stripe Identity is the pragmatic answer for a large class of teams: document and selfie verification, delivered through the same API, dashboard and integration model as the rest of Stripe. If Stripe already handles your payments, adding verification is a small, well-documented integration rather than a vendor evaluation, a security review and a new contract.
Be clear about what it is not. It is identity verification, not a compliance suite. Sanctions screening, ongoing AML monitoring, business verification and configurable risk journeys are outside its scope, and a regulated business will need them from somewhere.
Pros
- Integration cost is close to zero for teams already on Stripe, using the same keys, dashboard, webhooks and test mode
- Well-designed hosted verification flow that handles capture, retry and the user-facing experience without custom work
- Verification results connect naturally to the payment and account objects that already exist in your Stripe data
- Transparent per-verification pricing without an enterprise sales process, which makes it viable at small volume
Cons
- Not a compliance platform: no sanctions screening, no ongoing monitoring, no business verification, so a regulated business needs a second vendor
- Document coverage and regional depth are narrower than the specialists, and the long tail is where that shows
- Limited configurability of the verification journey compared with the flow-builder vendors
- Ties another part of your stack to Stripe, which is a consideration if payment provider independence matters to you
Best for: Marketplaces and platforms already on Stripe that need identity verification for trust and safety or payout eligibility rather than a full regulatory KYC programme.
Pricing: Per verification session at a published rate with no enterprise minimum, billed alongside the rest of your Stripe usage.
LoginRadius
LoginRadius belongs in this list for a different reason from the others, and it is worth being precise about it. It is a customer identity platform, not a document verification vendor. What it provides is the layer that a verification result has to land in: the user record, the progressive profiling flow that decides when to ask for more, the consent and preference management that governs what you are permitted to keep, and the authentication that protects the account after verification is done.
That matters because the most common architectural mistake in this category is treating verification as a step that happens and then evaporates. The verification decision needs a durable home on an identity record, with the consent state and the audit trail attached, and re-verification triggers wired into the same lifecycle. If your CIAM layer cannot express “this user is verified, at this level, as of this date, with consent recorded here”, you will rebuild that yourself.
Pros
- Customer identity platform with consent, preference and progressive profiling management, which is where a verification result and its permissions belong
- Verification outcomes can be held as part of the user profile alongside the authentication that protects the account afterwards
- Data residency options and compliance tooling aimed at consumer-scale deployments across multiple jurisdictions
- Covers the authentication half of the problem properly, which the verification specialists deliberately do not
Cons
- Not a document verification or liveness vendor, so the actual KYC check comes from one of the specialists above and must be integrated
- Buying a CIAM platform to solve a verification problem is the wrong order of operations if you do not also need CIAM
- Platform breadth means evaluating it against the CIAM category rather than against the verification vendors here
- Enterprise contracting rather than self-serve, which slows a team that just wants to ship a check
Best for: Consumer-scale businesses that need a verification result and its consent record to live durably on a customer identity profile, alongside the authentication that protects the account.
Pricing: Per monthly active user platform tiers with data residency, consent management and enterprise features by tier, rather than per verification check.
How to choose
This is one of the few categories where the answer follows almost mechanically from the requirement, if you state the requirement precisely.
Is this a regulatory obligation or a trust and safety measure? If a regulator requires KYC, you need sanctions and watchlist screening, ongoing monitoring and an audit trail, and the shortlist is the compliance platforms: Sumsub, Jumio, Onfido. If you are verifying identity to reduce fraud or enable payouts and no regulator is involved, a verification specialist or Stripe Identity is sufficient and much cheaper to operate.
Which corridors do your customers come from? This question decides more than any feature comparison and it can only be answered with your own traffic. Get per-country, per-document-type performance for your actual mix, ideally through a shadow evaluation against live traffic. A provider that is excellent for your competitor in a different market tells you nothing.
Do you have someone who will own the risk configuration? If yes, the flow-builder vendors let you tune per segment and reclaim a lot of false rejections. If no, a vendor with strong defaults beats a flexible one that nobody tunes, and an untuned flexible configuration decays into a liability.
What is your volume shape? Per-check pricing punishes retry-heavy flows and fraud waves. Model your cost on a realistic attempt count, not on verified users, and get the manual review price and turnaround time in writing, because that is the meter people forget.
| Tool | Scope | Screening and monitoring | Flow configurability | Buying motion |
|---|---|---|---|---|
| Veriff | Verification specialist | Limited | Moderate | Enterprise with volume tiers |
| Sumsub | Full compliance platform | Yes, including KYB | High, rules engine | Enterprise |
| Persona | Configurable verification | Via composed sources | Highest, flow builder | Self-serve to enterprise |
| Onfido | Verification specialist | Limited | Moderate | Enterprise |
| Jumio | Enterprise verification and AML | Yes | Moderate orchestration | Enterprise with minimums |
| Stripe Identity | Verification only | No | Low | Self-serve |
| LoginRadius | Customer identity platform | Not applicable | Identity lifecycle | Enterprise |
Whichever you choose, the two decisions that determine the outcome are yours, not the vendor’s: what happens to a rejected legitimate customer, and what re-triggers verification on an account that was verified once and is now behaving strangely. Neither appears in a feature comparison, and both cost more than the per-check price.
Frequently asked questions
Is identity verification the same as authentication?
No. Verification proves a person is who they claim, once, using a document and a biometric, and it usually exists because a regulator or a fraud policy requires it. Authentication proves a returning user is the same account holder, on every session, using a credential. Verification establishes the link between account and person; authentication maintains it. Neither substitutes for the other, and the tools are different products from different vendors, as the authentication providers hub lays out.
What is an injection attack and why does it matter more than deepfakes?
An injection attack feeds a video stream directly into the application through a virtual camera, an emulator or a hooked SDK, so the real camera is never involved. The deepfake is the payload; injection is the delivery mechanism, and it is the part that makes the attack scale. Liveness models trained on what a real capture looks like receive a clean, well-lit, entirely fabricated one. The defence is device attestation and SDK integrity, which establishes that the frames came from a real sensor, rather than a better classifier.
Why do pass rates differ so much by country?
Because document verification quality is per-document-type, not global. A provider’s model quality follows how many examples of a given document it has seen, which follows its customer base. Add NFC chip availability, capture conditions, document redesign cycles and name transliteration, and two countries can differ enormously with the same provider. Always test your own corridors rather than trusting an aggregate figure.
How many retries should I allow?
Enough that a capture problem is not a lost customer, which in practice means more than one, and few enough that your cost per verified user stays sane. The better lever is reducing first-attempt failures through capture guidance in the SDK, and giving failed users an escalation path to manual review or an alternative document rather than a dead end.
Do I need to store the document images?
Almost certainly not, and you probably should not. Document images and face biometrics are regulated more strictly than ordinary personal data, and several jurisdictions attach specific obligations and private rights of action to biometric data. Keep the decision, the provider case reference and the minimum identity fields you have a lawful basis to retain, with a documented retention period. Let the provider hold the media under their retention policy.
Does verification stop account takeover?
No. It raises the cost of creating a fraudulent account, and account takeover targets accounts that already passed verification precisely because they inherit that trust. Protecting the account afterwards is an authentication problem: phishing-resistant factors, step-up on sensitive actions, and a recovery flow that is not the weakest link. See MFA providers and passwordless authentication for that half.
Related reading
- Best authentication providers for developers — the identity layer that maintains the link verification establishes.
- Best CIAM platforms — consumer identity, consent management and where a verification result lives durably.
- Best MFA providers for developers — protecting the verified account against takeover, which verification does not do.
- Best auth providers for B2B SaaS and enterprise — the business verification and organization side of the same onboarding problem.
- Best log management tools — retention and searchability for the audit trail a regulator will eventually ask to see.