Top 10 Questions to Ask an Identity Verification Vendor Before Choosing One

The FTC reported over $12.5 billion in fraud losses in 2024, a 25% increase year-over-year, with more than 1.1 million identity theft reports filed through IdentityTheft.gov. That backdrop makes vendor selection feel urgent, and urgency tends to collapse due diligence into a feature comparison. One vendor gets checked off against another on accuracy numbers, price, and integration speed. The contract gets signed.

Six to eighteen months later, many teams discover the real evaluation questions were never asked. A new market requires document types that the vendor barely covers. A service outage has no contractual SLA remedy. The data processing agreement conflicts with local residency rules. The identity verification market is projected to grow from $14.34 billion in 2025 to $29.32 billion by 2030, and every vendor in that market will claim the same tier-one capabilities. The questions below are designed to show you where those claims diverge from reality.

Do you build and own your verification technology?

Many IDV vendors integrate third-party components for document capture, biometric matching, or liveness detection and package them under a single brand. Ask specifically which parts of the pipeline are proprietary and which are licensed from other providers. Third-party dependencies create SLA, licensing, and roadmap risks that sit outside the vendor’s control. When a subcontractor changes its pricing or discontinues a product line, the disruption lands on your operations team, not theirs.

What deployment options do you support?

Cloud-only works for many organizations. For teams with data sovereignty requirements, the question of whether a vendor can run on your own infrastructure, your cloud tenancy, or a hybrid of both is not optional. Regulators in financial services, healthcare, and government have become increasingly specific about where identity data may be processed and stored. Confirm that the vendor’s architecture can match your jurisdictional obligations before the contract is signed, not after.

Which regulatory certifications do you actually hold?

The industry baseline includes SOC 2 Type II, ISO 27001:2013, PCI DSS, and GDPR-compliant data processing. For biometric liveness detection, iBeta Level 1, 2, and iBeta Level 3 certification from a NIST NVLAP-accredited testing lab is the recognised independent benchmark. If your business operates in Germany, KJM approval is a hard requirement for age-gated products. Ask the vendor to produce the actual certificates. A certificate with an expiry date two years in the past is a signal worth investigating.

How many countries and document types does your solution genuinely cover?

Document coverage is where vendor claims diverge most sharply from deployment reality. A vendor may support 200 countries in principle, but have extraction rates that degrade significantly for certain document formats in specific regions. Ask for coverage data at the document type and jurisdiction level for the markets that matter to you. Organizations expanding to Southeast Asia, Latin America, or the Middle East will find that coverage depth determines how many verifications end up in a manual review queue.

What does your liveness detection defend against?

Presentation attack detection has moved well beyond static photo checks. The current threat environment includes 3D mask attacks, deepfake video injections, and screen replay attacks. Ask the vendor which attack categories their liveness detection is trained on and what independent testing validates those claims. iBeta Level 2 covers a broader set of presentation attacks than Level 1. Vendors without third-party certification are asking you to accept their own accuracy figures, which is a different category of risk than the fraud the product is supposed to prevent.

How deep is your AML and sanctions screening coverage?

AML screening is not a binary feature. Ask how many watchlists are covered, how frequently data updates, how PEP profiles are sourced and maintained, and whether adverse media screening is included. The FATF Recommendations frame AML compliance as a risk-based process, not a checklist. A vendor covering 50 watchlists and one covering 3,500 are not solving the same compliance problem, even if both describe the feature identically in their documentation.

What are your uptime guarantees and SLA remedies?

Onboarding flows do not have planned downtime windows. Ask what the vendor’s contractual SLA is, what constitutes a breach, and what the actual remedy looks like. Credit toward future invoices rarely compensates for a failed onboarding flow during a product launch or a regulatory audit. Ask whether the vendor maintains a public status page and what their incident communication process is, including how quickly clients are notified and through which channel.

Can you scale with us without forcing a platform migration?

Vendors optimized for small-to-medium volumes sometimes require architectural changes to support enterprise-grade throughput. Ask whether the API architecture is the same at 1,000 verifications per day as it is at one million. A thorough vendor due diligence process that evaluates only current needs will produce a contract that fits today but constrains growth. Ask about historical incidents where volume increases caused degraded performance, not just about theoretical limits.

Where does our identity data go, and who has access to it?

Data residency is a procurement question, not just a legal one. Ask for the vendor’s full sub-processor list, where data is stored at rest, where it is processed during a verification session, and what data retention and deletion policies apply after a check completes. Under GDPR, your organization is responsible for your processor’s practices alongside your own. Vendors that cannot produce a current, signed Data Processing Addendum before contract signature are signaling something about their compliance maturity.

What does integration actually require?

Implementation timelines vary from a few days for webhook-based integrations to several months for complex enterprise environments. Ask for the specific integration path for your technology stack, whether a sandbox environment is available before go-live, what documentation coverage looks like at the edge cases, and whether dedicated integration support is included or available only as a paid add-on. A clear picture of what identity verification services realistically demand at the integration stage will prevent you from discovering the answer mid-project, when switching costs are highest.

Choosing the wrong identity verification vendor shapes every onboarding flow, every AML alert, and every market expansion that depends on the vendor’s coverage depth and SLA reliability. Shufti’s identity verification platform covers 240+ countries, supports cloud, on-premises, and hybrid deployment through a single API, holds iBeta Level 1, 2, and 3 certifications for liveness detection, and screens against 3,500+ global watchlists, all under one contract.

Request a demo to run your specific use case through the platform and see how it performs against your target markets and compliance requirements.