Identity Verification Software: How to Evaluate It

Identity verification software vendors all describe themselves in the same words. This is what the coverage numbers actually mean, the ten questions that test a vendor claim, and where identity verification stops being the whole answer.

How to evaluate identity verification software and test vendor claims

Identity verification software confirms a person is who they claim to be. It runs three checks: it authenticates a government ID document, matches a live selfie against the photo on that document, and cross-references the identity against authoritative databases. A modern platform returns that decision in 30 seconds.

What it does not do is tell you whether that person should be on your platform. Buying identity verification software is harder than it should be, and not because the products are complicated. It is hard because every vendor describes itself in the same words. Global coverage. AI-powered. Bank-grade security. Thousands of document types. Those phrases are not comparable to each other, and most of them are not verifiable at all.

So this is not a ranked list of vendors. It is the thing a ranked list cannot give you: what the claims in the category actually mean, and the questions that separate a real capability from a well-designed slide.

What is identity verification software?

Identity verification software is a system that establishes a person's real-world identity during a digital interaction, usually at onboarding. It runs three checks in sequence: document authentication, biometric matching, and database verification. The output is a decision, plus a record of how that decision was reached.

Each check catches something different. Document authentication looks for forgery signals in the ID itself: hologram behaviour, font irregularities, barcode and machine-readable-zone consistency. Biometric matching confirms the person presenting the document is the person pictured on it. Database verification confirms the identity exists in authoritative records rather than being wholly invented.

The third one is the check people forget, and it is the one that catches synthetic identities. A well-made fake ID with a real person holding it passes the first two checks. It fails the third, because the name, date of birth and identifier combination does not resolve to a real history.

The reference library behind the check is the part that decides whether any of this works on your users, and it is the hardest thing for a vendor to fake. Authenticate's covers 6,500+ government ID types across 200+ countries, with identity verification running in 203 and the Medallion™ flow presenting in 38 languages. Those are the three numbers that matter operationally, and they are the three that vendors state most inconsistently.

What are the main types of identity verification software?

Five categories, and they are not competing for the same job: document and biometric point solutions, data and database verification tools, risk-scoring models, workflow and orchestration layers, and screening platforms. Most buying mistakes come from evaluating a vendor in one category against requirements that belong to another, then concluding the product is weak when it was simply the wrong shape.

Document and biometric point solutions

These do the first two checks extremely well and stop there. They authenticate the document, run liveness detection against a selfie, and return pass, fail or refer. You will see Onfido and Jumio on most shortlists in this category.

Choose this if your only question is whether the document is genuine and the person holding it is live and present. The category boundary is real: a point solution verifies identity, and it does not check records. If you also need to know what is in someone's history, that is a second vendor and a second integration.

Data and database verification tools

These skip the document. They verify a name, address, date of birth and national identifier against authoritative data sources, and return a match confidence. They are fast, they are cheap per check, and the user does not have to photograph anything.

Choose this when friction is your binding constraint and your risk tolerance allows a non-documentary check. The boundary: a database match tells you the identity exists. It does not tell you the person supplying it is the person it belongs to.

Risk-scoring models

These return a score rather than a verification. They weigh hundreds of behavioural, device and data signals and output a probability that an identity is fraudulent. Socure operates this way.

Choose this when you need to triage volume and route the ambiguous cases somewhere. The boundary is auditability. A score is a judgement, not a record. If a regulator, an insurer or a plaintiff asks what you verified about a specific person on a specific date, a probability is a harder answer to give than a document check with a stored result.

Workflow and orchestration layers

These are developer tools for composing a verification flow. You define the steps, the branching logic and the thresholds, and the layer calls out to underlying data providers. Persona is built around this model.

Choose this when your verification logic is genuinely bespoke and you have engineering capacity to own it. The boundary: the orchestration layer is not usually the source of the underlying data. You are still contracting for the data itself, sometimes separately.

Screening platforms

These treat identity as the first step rather than the whole product. The same integration that verifies a document also runs criminal record searches, sex offender registry checks, watchlist and sanctions screening, education and licence verification, and ongoing monitoring after onboarding. Authenticate is in this category. Background-check-first vendors built around employment screening, such as Checkr, sit adjacent to it from the other direction, with records as the core product and identity as the addition.

Choose this when knowing who someone is only solves half your problem. The boundary here is the opposite of the others: if you genuinely only need document and liveness checks, a platform is more surface area than you need.

What do the coverage numbers actually mean?

Less than they appear to. Every vendor publishes a country count, an ID-type count and a speed claim, and almost none of those figures are comparable, because there is no shared counting convention behind any of them. Only two claims in this category have an independent standard you can check: liveness testing and security auditing.

Country counts tell you where a vendor claims some capability, not what that capability is. Supporting a country can mean full document authentication, or it can mean a name-and-address database lookup with thin coverage. The number is a starting point for a question, not an answer.

ID-type counts are the least comparable figure in the category. Vendors count differently. One counts every variant of every state licence as a separate type; another counts the licence once. A vendor claiming twice as many document types as another is not necessarily ahead of it. Ask for the list for the countries you actually operate in.

"Global coverage" is not a number and should be treated as a claim awaiting evidence. If a vendor cannot name which countries it covers and at what depth, it does not know.

Liveness detection is the one claim in this category with an independent standard behind it. According to ISO/IEC 30107-3, the international standard for biometric presentation attack detection, spoof resistance is something you test and grade rather than assert, and iBeta runs accredited conformance testing against it at Level 1 and Level 2. A vendor that has passed iBeta Level 2 testing can say so and name the date. A vendor describing its liveness as "advanced" or "AI-powered" has told you nothing testable. Authenticate's liveness detection is iBeta Level 2 tested against ISO 30107-3.

Assurance level is the vocabulary your compliance team already uses. According to NIST Special Publication 800-63-3, the US federal Digital Identity Guidelines, identity proofing is graded in Identity Assurance Levels that describe how strongly an identity has been established, rather than treated as a single pass or fail. Asking a vendor which identity assurance level a given flow configuration meets is a far more precise question than asking whether they are secure.

Jurisdiction and facility coverage applies once records checks enter the picture, and it is the figure most vendors will not publish. A criminal database is only as good as the share of sources it actually reaches. Authenticate publishes its figures: as of 2026, the national criminal check draws from 99% of US incarceration facilities, and county courthouse searches cover 3,200+ US counties. Ask any vendor for the specific percentage. A qualitative answer is an answer.

Speed needs a start point and an end point. Thirty seconds from document upload to returned decision is a different claim from thirty seconds of processing time inside a flow that also queues for manual review. Ask what is being measured.

The claimWhat it sounds likeWhat to ask forWhat a good answer looks like
Country coverage"We cover 200+ countries"The depth of coverage per country you operate inA per-country breakdown distinguishing document authentication from database-only checks
ID types"Thousands of document types"The document list for your specific marketsAn actual list, and an explanation of how they count a variant
Global reach"Global coverage"Which countries, at what depthA named list. Anything else is marketing
Liveness"AI-powered liveness"The independent test and its date"iBeta Level 2, tested against ISO/IEC 30107-3," with the test month and year named
Assurance"Bank-grade security"Which NIST 800-63-3 identity assurance level the flow meetsA specific IAL, with the configuration that achieves it
Records coverage"Comprehensive criminal database"The source coverage percentageA number, such as 99% of US incarceration facilities, and the county count
Speed"Instant verification"Measured from what, to what, and at what percentileEnd-to-end time to decision, with the manual-review rate stated separately
Security posture"Enterprise-grade"The current audit reportA SOC 2 Type II report, audited against the AICPA Trust Services Criteria, available under NDA

One note on the last row, because it is the most misused word in vendor security copy. SOC 2 Type II is an audit against the AICPA Trust Services Criteria, which specify the controls an independent auditor tests for security, availability, processing integrity and confidentiality over a period of time rather than at a single moment. "Enterprise-grade" is not a certification. A Type II report is.

Authenticate's own posture, for the record: SOC 2 Type II, NIST 800-63-3, HIPAA, PCI DSS v4.0, iBeta Level 2, CCPA and GDPR. Ask for the equivalent list from everyone on your shortlist, and ask for the reports.

How do you test what a vendor tells you?

Send the same list to everyone on your shortlist and compare the answers rather than the decks. Ten questions, and the reason each one works is that a vendor who cannot do the thing will visibly struggle to answer it.

  1. Which countries do you support at full document authentication, and which at database lookup only? A good answer is a table. A poor answer is a total.
  2. Can I see your supported document list for the three markets I care about? A vendor with real coverage has this as a file and will send it.
  3. What independent liveness testing have you passed, at what level, and on what date? A good answer names iBeta Level 2 and ISO/IEC 30107-3 and gives you a date. A vendor who reframes the question is telling you the answer.
  4. Which NIST 800-63-3 identity assurance level does the configuration you are proposing to me meet? This distinguishes vendors who understand the compliance framing from those who have only heard of it.
  5. What is your end-to-end time to decision at the 95th percentile, and what share of checks go to manual review? Averages hide queues. The percentile and the review rate are the operationally honest numbers.
  6. What happens when the system is wrong? Ask about both directions: a real user wrongly rejected, and a fraudulent identity wrongly passed. Ask what the appeal path is and who bears the cost.
  7. Can I run this in a sandbox this week, with test identities that are supposed to fail? Any vendor confident in the product will hand you keys. Testing the failure cases is more informative than testing the happy path.
  8. What do you store, where, for how long, and can I get a deletion confirmed? Verification means handling identity documents. Data handling is not a footnote here.
  9. Show me the actual response payload. Not a screenshot of a dashboard. The JSON. It tells you what the product genuinely knows versus what the interface implies.
  10. What is the pricing model, and what triggers a charge? Per verification, per attempt, per seat, or a committed annual minimum are very different commercial shapes. Ask whether a failed check bills, and whether unused capacity expires.

Question seven is the one that changes evaluations most often, and it is the cheapest to run. A sandbox with deliberately failing test identities tells you in an afternoon what a procurement cycle takes six weeks to surface.

If you want to run this list against Authenticate, Authenticate's identity verification documents the methods, coverage and response format, and the sandbox is available on a free account.

What identity verification software does not tell you

Verification answers one question well: is this person real, and are they who they say they are. It does not answer the two questions that usually follow.

Should this person be on my platform? That is a records question, not an identity question. A verified identity can belong to someone with a relevant conviction, an active sanctions listing, or a place on a sex offender registry. Confirming the identity is genuine tells you nothing about any of that. Answering it means criminal record searches, registry checks, and watchlist and sanctions screening. As of 2026, Authenticate's registry check covers 600,000+ records across all 50 states, US territories and tribal lands, and global watchlist and criminal data spans 40 countries including OFAC screening.

Is that still true in six months? Verification is a snapshot of the day it ran, and as of 2026 no verification product on the market changes that on its own. Someone verified in January and screened clean in January is still recorded as clean in December, whatever happened in between. Closing that gap means monitoring rather than re-verification. True Continuous Monitoring (TCM™) covers 95%+ of the US adult population, ingests 100,000+ new criminal records every day, refreshes its covered databases every 60 seconds, and fires an alert within 24 hours when a record changes for someone enrolled. What it watches for is deliberately broad: a new arrest, warrant, booking or sanctions hit triggers an alert, not convictions alone.

Here is the honest part. Plenty of platforms only need the first question answered. A digital product verifying that a signup is a real adult human does not need criminal record screening, and buying it is waste. The distinction that matters is whether a bad actor passing your verification step costs you a fraudulent account or costs you a physical incident, a regulatory finding, or a liability claim. If it is the latter, identity verification alone is a partial answer, and it is worth knowing that before you sign rather than after.

Where the categories genuinely differ is the integration count. Doing all three through criminal background checks on the same platform as the identity check is one contract and one API. Assembling it from three vendors is three of each, plus the work of reconciling identities across them.

Which type should you choose?

Match the category to the job, not to the longest feature list. The right question is what a missed verification actually costs you: a fraudulent account, a regulatory finding, or a physical incident. That answer determines the category, and the category determines the shortlist. This is the segmentation most vendor content skips, because it inevitably points some readers somewhere else.

Your situationThe category that fitsWhy
Single-market fintech, needs documentary proof and liveness for onboardingDocument and biometric point solutionThe job is genuinely bounded. Extra surface area is cost without benefit
High-volume consumer signup, friction is the binding constraintData and database verificationNo document capture, lowest drop-off, adequate for lower assurance requirements
Large platform triaging fraud at scale with a review teamRisk-scoring model, layered on a verification stepA score routes cases. Pair it with something auditable underneath
Bespoke verification logic, strong engineering team, appetite to own itWorkflow and orchestration layerMaximum control, and you accept responsibility for the flow
Users are entering homes, treating patients, driving, or handling moneyScreening platformIdentity plus records plus monitoring, because the cost of a miss is physical or regulatory
Global user base, many document types, no dedicated engineerScreening platform with a no-code optionBreadth without an integration project. Medallion covers this path

Two cross-cutting rules. If a use case is genuinely bounded, buy the bounded product. And if you cannot articulate what you would do with a verification result when it comes back negative, no vendor on your shortlist will fix that for you.

What does implementation involve?

Two paths, and the difference between them is weeks. A no-code path configures a hosted verification flow and embeds it, which takes hours. An API path builds verification into your own onboarding, which takes days. Most evaluations never ask which path a vendor genuinely supports, then discover the answer during implementation.

The no-code path. You configure which checks run, in what order, with what thresholds, then embed the resulting flow as a link or an iframe. No engineering ticket. Medallion™ is Authenticate's version, and it carries the same coverage as the API: 6,500+ government ID types across 203 countries, in 38 languages, with the interface adapting to the user's locale rather than requiring a translation layer. As of 2026 this is the path most operations teams take, because it removes the dependency on a release cycle.

The API path. You call a REST endpoint, receive a structured response, and handle asynchronous results over webhooks. Authenticate ships SDKs for Python, Node.js and Java, with separate sandbox and production environments and deterministic test results per check type. Expect days rather than weeks for a standard onboarding flow, and longer if you are also handling asynchronous record checks that return later by webhook.

Three implementation questions worth asking every vendor, because the answers are rarely in the deck. Does the no-code path have the same coverage as the API, or is it a reduced version? Are webhook deliveries signed, and what is the retry behaviour when your endpoint is down? And can a non-engineer change a threshold after launch, or does every change need a deploy?

That last one determines who owns the flow six months from now. A verification step that only engineering can adjust becomes a verification step nobody adjusts.

Frequently asked questions

What is identity verification software? Identity verification software confirms a person is who they claim to be during a digital interaction. It authenticates a government-issued ID document, matches a live selfie against the photo on that document, and cross-references the identity against authoritative databases. The output is a pass, fail or refer decision, plus a stored record of how the decision was reached.

How much does identity verification software cost? Pricing follows one of four shapes: per verification, per attempt, per seat, or a committed annual contract with a minimum. The shape matters more than the headline rate, because a low per-check rate inside an annual minimum you do not use costs more than a higher rate you only pay when you run a check. Ask whether failed checks bill and whether unused capacity expires. Authenticate publishes its rates at Authenticate's pricing.

What is the difference between identity verification and KYC? Identity verification is a technical process: proving a person is who they claim to be. KYC (Know Your Customer) is a regulatory obligation that requires identity verification as one of its components, alongside ongoing due diligence, sanctions screening and record-keeping. You can run identity verification without being subject to KYC. You cannot satisfy KYC with identity verification alone.

Does identity verification software stop deepfakes? Good liveness detection stops most current presentation attacks, and the claim is testable: ask for iBeta Level 2 conformance against ISO/IEC 30107-3, with a date. Active liveness prompts the user to move, which defeats static images. Passive analysis catches screen replay and video injection. This is an arms race, so the date on the certification matters as much as the level.

How long does identity verification take? A document and selfie check completes in 30 seconds on a modern platform, and database-only checks return faster. What extends it is manual review. Ask any vendor for the end-to-end time to decision at the 95th percentile alongside the share of checks routed to a human, because those two numbers together describe what your users will actually experience.

Do I need identity verification software if I already run background checks? Usually yes, and the reason is that a background check assumes an identity. If the name and date of birth you searched belong to someone else, the clean result you received is meaningless. Verifying identity first is what makes the records check about the right person. Running both on one platform removes the reconciliation step between them.

What certifications should an identity verification vendor have? Ask for SOC 2 Type II, audited against the AICPA Trust Services Criteria, and ask to read the report. For liveness, ask for iBeta Level 2 against ISO/IEC 30107-3. For assurance framing, ask which NIST 800-63-3 identity assurance level the proposed flow meets. Add HIPAA for healthcare, PCI DSS for payment data, and GDPR or CCPA depending on where your users are.

The claims are the product

Every vendor in this category will tell you they have global coverage, advanced liveness and enterprise-grade security. Those sentences are identical across the shortlist, which means they carry no information. What separates the products is what happens when you ask for the country list, the certification date, the percentile latency and the sandbox keys. Send the ten questions. The answers will sort your shortlist faster than any comparison table, including this one.

See pay-as-you-go pricing

Related resources