Question 1

What identity document types and geographies does the platform support for document verification (passports, driver's licenses, national IDs), and how many countries/document types are covered out of the box?

Accepted Answer

Look for a specific country/document-type count; global coverage claims should be backed by a real number, since document format variety is a major technical challenge.

Question 2

Describe the liveness detection methodology (passive vs. active/challenge-based) used to prevent deepfake and photo/video spoofing attacks, and provide a measured spoof-detection accuracy figure from independent testing (e.g., iBeta/NIST) if available.

Accepted Answer

Look for independent third-party testing results (iBeta Level 1/2, NIST) rather than only vendor-reported accuracy, since liveness detection claims are easy to overstate.

Question 3

What is the verification completion rate (percentage of legitimate users who pass on first attempt) and average time-to-verify, and how does the platform balance friction against fraud prevention?

Accepted Answer

Strong answers give real completion-rate and time-to-verify figures; a vendor unable to state these likely hasn't been tested at production scale.

Question 4

Detail how the platform handles synthetic identity fraud (fabricated identities combining real and fake data) specifically, distinct from stolen/impersonated real identities.

Accepted Answer

Synthetic identity fraud requires different detection techniques (cross-referencing data consistency over time) than simple document/selfie matching — look for a specific methodology.

Question 5

Does the platform support step-up/risk-based verification (lighter checks for low-risk transactions, fuller verification for high-risk ones), or is it a single fixed verification flow regardless of risk context?

Accepted Answer

Risk-based verification reduces friction for legitimate low-risk users; a fixed one-size-fits-all flow is less sophisticated.

Question 6

Explain data privacy and retention practices for collected identity documents and biometric data — is raw biometric data stored or only a derived template, and what regulatory certifications (SOC 2, ISO 27001, GDPR/CCPA compliance) apply?

Accepted Answer

Storing only a derived template (not raw biometric images) is a stronger privacy posture — look for a specific answer plus named certifications, not just 'we're compliant.'

Question 7

What is the platform's approach to accessibility and inclusivity in verification — does it account for lower-quality cameras, varying lighting, and diverse skin tones in liveness/face-matching accuracy, with any published fairness/bias testing?

Accepted Answer

Facial recognition bias across skin tones is a documented, real problem — look for published fairness testing, not just an assurance of 'no bias.'

Question 8

How does the platform integrate into an existing onboarding flow (SDK, API, hosted redirect) and what is the typical integration timeline for a new customer, per a reference?

Accepted Answer

Look for a real integration timeline from a customer reference and clarity on integration options (embedded SDK vs. redirect), since redirect flows add friction vendors sometimes downplay.

Question 9

What is the pricing model — per verification attempt, per successful verification only, or a flat volume tier — and does the customer pay for failed/retry attempts, which directly affects cost predictability at scale?

Accepted Answer

Look for clarity on whether failed attempts are billed; a per-attempt (not per-success) pricing model can create unpredictable costs if legitimate users frequently need multiple tries.

Question 10

Does the platform participate in a cross-customer fraud-signal network or consortium (shared fraud intelligence across the vendor's full customer base), and can it flag an identity or device previously linked to fraud at a different customer, distinct from single-customer-siloed detection?

Accepted Answer

Cross-customer fraud-network data is a materially more powerful signal than detection based solely on one customer's own historical data — ask for a concrete example of a network-detected fraud case.

Question 11

What is the manual-review/escalation workflow for verification attempts that fail automated checks but may be legitimate (e.g., a real user with an unusual document or lighting conditions) — is human review included, and what is the typical turnaround time?

Accepted Answer

A well-designed escalation path prevents legitimate users from being permanently blocked by an imperfect automated system — ask for a concrete review-team SLA, not just 'automated with occasional manual review.'

Question 12

Does the platform support periodic re-verification of existing users (e.g., annually, or triggered by risk signals) rather than only a one-time verification at initial onboarding, and how is re-verification friction minimized for returning legitimate users?

Accepted Answer

One-time-only verification leaves a gap for identity compromise or document expiry over time — ask whether ongoing/periodic re-verification is a real, low-friction capability.

Question 13

Detail sanctions/watchlist screening integration (OFAC and equivalent international lists) — is this a native, included capability, or does it require a separate product, and how current is the underlying watchlist data?

Accepted Answer

Watchlist screening is a common, often-regulatory-mandated adjacent requirement — ask explicitly whether it's included and how frequently the underlying list data is refreshed.

Question 14

What is the incident-response plan if the identity-verification system itself is breached, given that it stores especially sensitive biometric and identity-document data — has the vendor had a real security incident, and how was it disclosed and handled?

Accepted Answer

Given the unusually high sensitivity of biometric/ID data here, ask directly about the vendor's own incident history rather than assuming a clean record — a vendor with no verifiable track record either way warrants extra scrutiny, not automatic trust.

Question 15

What is the API uptime/latency SLA, given that identity verification is often a hard-blocking step in a customer's own signup or transaction flow — what happens to the customer's own user experience if the verification API is slow or briefly unavailable?

Accepted Answer

Look for a concrete, contractual uptime/latency SLA and a documented graceful-degradation behavior (e.g., a fallback path) rather than the customer's entire signup flow being fully dependent on this one third-party API's availability.

Question 16

Detail coverage and compliance for identity systems beyond the US/EU — does the platform genuinely support region-specific identity infrastructure (e.g., India's Aadhaar, other national digital-identity systems) for a customer with a global user base, or is coverage effectively US/EU-centric with weaker support elsewhere?

Accepted Answer

Ask for an honest, region-by-region coverage breakdown for a customer with meaningful international user volume — a platform's marketed 'global coverage' often masks materially weaker support outside its home markets.

Identity Verification evaluation questionnaire

Build your evaluation

Match on your requirements

1. Weight what matters

2. Pick vendors to compare

Platform baseline

From other buyers