A practical procurement framework for evaluating identity verification software in 2026, with 12 criteria, a scoring rubric, an RFP question bank, and a pilot framework that surfaces real differences between vendors.

The identity verification software market in 2026 looks different from the market in 2020. The first-generation IDV platforms that defined the category were document-and-selfie-only stacks built around document forensics and basic liveness. The second wave layered on AML, sanctions, and ongoing monitoring as separate products. The current generation is a verification engine plus an agentic compliance suite, where KYC, KYB, AML, ongoing monitoring, background checks, and case management run on a single platform with an AI compliance officer drafting the procedural compliance documentation in real time.

Procurement teams evaluating IDV software in 2026 face a meaningfully harder decision than five years ago. The question is no longer "which document-and-selfie vendor has the lowest false acceptance rate?" It is "which architecture replaces the multi-vendor patchwork we built up over the last five years?"

This framework walks the 12 criteria that actually surface differences between vendors in 2026, the scoring rubric to apply, the RFP question bank that pulls real answers from each vendor, and the pilot framework that validates the answers before procurement.

Suggested read: The 2026 Age Verification Architecture Guide: Inference, Document, Wallet, Token

The 12 evaluation criteria

The 12 criteria below organize into four categories: coverage, compliance, architecture, and economics. Each is scored on a 1 to 5 rubric (1 = baseline, 3 = competitive, 5 = differentiated) with weighted total scoring against the buyer's specific use case.

Coverage

Criterion 1: document and country coverage. How many document types does the vendor verify, across how many countries and territories, in how many languages? Baseline coverage in 2026 is 200+ countries and 10,000+ document types. Differentiated coverage is 220+ countries and 14,000+ document types with 40+ language UI support and dedicated coverage for unbanked or thin-file populations.

Criterion 2: biometric and liveness performance. What is the vendor's PAD (presentation attack detection) certification level? iBeta Level 1 PAD under ISO/IEC 30107-3 is the published baseline. Independent benchmarks beyond Level 1 (NIST FRVT performance metrics, peer-reviewed evaluations) indicate differentiated capability. What are the published false acceptance and false rejection rates? Vendors that won't disclose the metrics rarely have the metrics to disclose.

Criterion 3: multi-product breadth. Does the platform handle KYC, KYB with UBO resolution, AML and sanctions screening, PEP and adverse media monitoring, ongoing transaction monitoring, background checks, and case management on a single integration? Or is each capability a separate product, separate integration, separate credit pool?

The single-platform pattern compresses procurement, integration, training, and ongoing operational overhead. The multi-vendor patchwork pattern preserves vendor optionality but multiplies operational complexity.

Compliance

Criterion 4: compliance certifications. SOC 2 Type 1 is the baseline floor. SOC 2 Type 2, ISO 27001:2022, ISO 27017, ISO 27018, FCRA, PCI DSS, GDPR/CCPA, and PIPEDA are the markers of a mature compliance posture. For specific industries, additional certifications matter (HIPAA for healthcare, KSA SDAIA for Saudi Arabia, IMDA Data Protection Trustmark for Singapore).

Criterion 5: cryptographic audit trail. Does each verification produce a cryptographic receipt that survives examination? The EU AMLA framework's outcome-effectiveness supervision approach (effective 2027 to 2028) explicitly requires firms to demonstrate that their AML programs achieve regulatory outcomes, not just that procedures exist. Without a cryptographic audit trail, the firm cannot prove that the verifications happened as recorded.

Criterion 6: regulatory framework alignment. Does the platform support EU MiCA Travel Rule (TFR), DORA operational resilience, AMLA outcome-effectiveness evidence, GENIUS Act stablecoin compliance, FATF Recommendation 16, eIDAS 2.0 EUDIW, and the long tail of US state laws? A platform that handles EU and US compliance natively reduces the integration burden compared to a platform that requires bolt-on modules for each regime.

Suggested read: From Onboarding to Ongoing: Building Continuous Verification That Survives an AMLA Examination

Architecture

Criterion 7: agentic compliance layer. Does the platform include an AI compliance officer that drafts SAR narratives, regulatory inquiry responses, and supporting documentation? Single-vendor liveness solutions and document-and-selfie-only stacks do not. The agentic layer is the architectural differentiator that separates the current generation from the prior one.

Criterion 8: wallet and reusable credential support. Does the platform consume EUDIW credentials via OpenID4VP, mDL credentials under ISO/IEC 18013-5 (proximity) and 18013-7 (online), and W3C Verifiable Credentials with DIDs? The wallet era is being defined now. The platforms that consume wallet credentials on the same engine that runs document-based verification will outlast the platforms that treat wallet support as a separate product line.

Criterion 9: integration model. Three integration models exist: API-only (the buyer's developers integrate against documented endpoints), SDK-plus-hosted (the vendor provides a hosted UI that the buyer embeds), and agent-native (the platform exposes verification as an MCP tool callable by AI agents and orchestrators). Most buyers in 2026 need at least two of the three. A platform supporting all three reduces architectural lock-in.

Criterion 10: performance and latency. What is the published end-to-end verification latency at the buyer's expected scale? Sub-second decisions at the 99th percentile are the baseline for high-volume operators. The platforms that can sustain sub-150ms median latency under load reflect mature infrastructure, not just demo conditions.

Economics

Criterion 11: pricing transparency. Is per-check or per-verification pricing publicly published? Are subscription tiers documented with included credits and overage rates? A platform with sales-quoted-only pricing transfers procurement risk to the buyer. A platform with published pricing externalizes the risk. Mid-market and growth-stage buyers have a meaningful preference for the latter.

Criterion 12: total cost of ownership. What is the all-in cost of running the platform end to end at the buyer's volume, including verification credits, ongoing monitoring fees, integration cost, training cost, and the operational overhead of multi-vendor coordination? The single-platform option often shows lower TCO at scale even when per-verification pricing looks higher than a low-end specialist vendor's headline rate. The TCO calculation should be the procurement team's anchor metric, not the per-check rate.

The scoring rubric

Each criterion scores 1 to 5 against the buyer's specific use case. A baseline of 3 indicates competitive market parity. Below 3 indicates a gap. Above 3 indicates differentiation that warrants weighted preference.

The weighting depends on the buyer's profile:

• Regulated financial services (banks, EMIs, payment institutions, crypto exchanges) typically weight Compliance criteria (4 to 6) and Architecture criteria (7 to 8) most heavily. The cost of non-compliance is multiples of the cost of the platform itself.
• High-volume operators (gaming, marketplaces, e-commerce, social platforms) typically weight Performance (10), Coverage (1 to 3), and Economics (11 to 12) most heavily. The cost difference at high volumes is material.
• Multi-jurisdictional operators (cross-border fintech, travel, real estate, education) typically weight Architecture (7 to 9) most heavily. The multi-jurisdictional integration complexity is where most platforms fall short.

A weighted total above 4.0 against the buyer's profile indicates a strong fit. Below 3.5 indicates a gap that should be addressed before procurement, either through vendor remediation commitments or reconsideration of the shortlist.

The RFP question bank

Procurement teams running an RFP process should pull verifiable answers from each vendor. The questions below are designed to surface real differences rather than vendor marketing claims.

On Coverage:

• Provide the current document and country coverage list, last updated within 30 days. Identify any documents flagged as "limited support" or requiring manual review.
• Provide the published false acceptance rate (FAR), false rejection rate (FRR), and presentation attack detection rate (IAPAR) under the most recent independent third-party evaluation.
• List all certifications held with current validity dates and certificate numbers verifiable on issuer registries.

On Compliance:

• Provide the cryptographic audit trail mechanism. Where are receipts anchored? What is the verification process for examiners?
• List all regulatory frameworks supported natively versus through bolt-on modules. For each, identify the specific implementation (e.g., Travel Rule via TRP messaging, EUDIW credential consumption via OpenID4VP).
• Describe the SAR drafting and regulatory inquiry response capability. Is it AI-assisted, fully automated, or manual?

On Architecture:

• Demonstrate end-to-end verification latency at the buyer's expected production scale, not demo conditions.
• Describe the integration models offered. For each, provide reference customers operating in production at scale comparable to the buyer's.
• Demonstrate wallet credential consumption (EUDIW, mDL, W3C VC) on the production platform with verifiable proof.

On Economics:

• Provide the published per-verification pricing for each module, with overage rates for usage above the subscription tier.
• Provide the total annual cost at the buyer's projected volume, broken down by component (verification credits, monitoring fees, integration, support).
• Provide the cost comparison against a typical multi-vendor stack the buyer would otherwise need to assemble (KYC + KYB + AML + monitoring + case management).

Suggested read: Reusable Digital Identity in 2026: A Practical Buyer's Guide

The pilot framework

After RFP scoring, the buyer should pilot the top 2 to 3 vendors against a representative slice of production traffic before procurement.

The pilot should run for at least 30 days against at least 10,000 verifications, with traffic representative of the buyer's actual customer mix (geographic, document type, age distribution, risk profile). Pilots run against synthetic data or vendor-provided test sets do not surface the operational issues that production traffic surfaces.

The pilot should measure:

• End-to-end completion rates at each step of the user flow. The single biggest difference between vendors at scale is the drop-off rate at marginal cases (low-light selfies, partial documents, unbanked users). Headline accuracy metrics rarely capture this.
• Examination-readiness of the audit trail by simulating a regulatory inquiry. Can the vendor produce a complete decision-rationale trail for a specific verification, on demand, with cryptographic verification of integrity?
• Operational responsiveness during the pilot. How does the vendor handle escalations, performance issues, or integration questions? The pilot is a preview of the long-term operational relationship.
• Total cost at the pilot volume scaled to expected production volume. The TCO calculation should anchor against actual usage patterns, not vendor-projected ideal cases.

The pilot output is a procurement decision file with the scored criteria, the RFP responses, and the pilot results. That file is also useful documentation when the buyer's compliance program is later examined.

What deepidv brings to the procurement evaluation

deepidv is built around the architectural pattern this framework optimizes for. KYC, KYB with UBO resolution, AML and sanctions screening (Arbiter agent fleet), ongoing monitoring, background checks, and case management run on a single platform with one credit pool. Each verification produces a cryptographic receipt anchored on Base L2 (proof.deepidv.com). Luna, the AI compliance officer, drafts SAR narratives and regulatory inquiry responses. Coverage spans 211+ countries and 14,000+ document types. ISO 27001:2022, SOC 2 Type 2, FCRA, PCI DSS, GDPR/CCPA. Pricing is published. Wallet consumption (EUDIW via OpenID4VP, mDL via ISO 18013, W3C VC) is on the same engine. The architecture is designed to score well across the criteria that matter to regulated buyers, multi-jurisdictional operators, and high-volume platforms.

To evaluate against the framework, see the head-to-head comparison page or book a live demo with a real production traffic walkthrough.

Frequently Asked Questions

How long does a typical IDV software procurement cycle take?

For mid-market buyers, 3 to 5 months from initial RFP to signed contract. For regulated financial services buyers, 6 to 12 months including security review, vendor risk assessment, and procurement governance. The pilot phase typically runs 30 to 60 days within that window.

Should we choose a single platform or a multi-vendor stack?

The architectural trend in 2026 is toward consolidation. The multi-vendor patchwork pattern that defined the 2020 to 2024 era multiplies operational complexity, integration cost, and audit-trail fragmentation. The single-platform option with a verification engine plus agentic compliance suite typically wins on TCO at scale and on examination readiness.

How do I evaluate cryptographic audit trail claims?

Ask the vendor to produce, on demand, a verification receipt for a specific transaction. Verify the cryptographic anchor (the receipt should reference an immutable structure, typically a blockchain or cryptographically anchored database). Confirm that the receipt cannot be altered after the fact. Vendors that cannot produce receipts on demand do not have an examination-ready audit trail regardless of marketing claims.

What weighting should we apply to each criterion?

The weighting depends on the buyer's profile. Regulated financial services typically weight compliance criteria (4 to 6) at 30 to 40% of total score. High-volume operators weight performance and economics (10 to 12) at 40 to 50%. Multi-jurisdictional operators weight architecture (7 to 9) at 35 to 45%. Adjust the framework's default weights to match the specific use case.

Are sales-quoted-only platforms inherently more expensive?

Not always at high volumes, where bespoke pricing can match or beat published rates. Often at low and mid volumes, where sales-quoted pricing typically reflects a margin premium. The published-pricing platforms reduce procurement risk and accelerate the decision timeline, which has independent value beyond the rate itself.

How do we test wallet credential support during a pilot?

Issue a test credential through a publicly available EUDIW emulator or mDL test wallet. Present the credential to the vendor's verification flow and confirm the platform consumes the credential, validates the issuer signature, and returns a structured verification result. Vendors that cannot consume wallet credentials on the same engine that runs document-based verification will struggle as wallet adoption matures through 2026 and 2027.

What if our top-scoring vendor on the framework has a coverage gap?

Coverage gaps are negotiable. The vendor's roadmap commitments, with contractual milestones, can close coverage gaps within 6 to 12 months in most cases. Other criteria (compliance certifications, architectural model, agentic capabilities) are harder to remediate post-procurement. Weight architectural and compliance differentiators higher than addressable coverage gaps.

Compare platforms or book a demo to see deepidv evaluated against your specific procurement profile.