Document Verification Solution Selection Criteria: Evaluation Framework

According to Gartner, 67% of document verification projects that fail do not have a technology defect but a selection defect: the chosen solution did not match the business's actual need. The cost of a poor choice — £38,000 in migration, 6 to 12 months lost, team frustration — is entirely avoidable with a structured selection process.

This guide proposes 15 evaluation criteria organised into 4 categories, a ready-to-use weighted scoring grid and a POC methodology to validate your choice before committing.

This article is for informational purposes only and does not constitute legal, financial or regulatory advice.

The 15 essential evaluation criteria

The 15 criteria are distributed across 4 categories: technical (6 criteria), compliance (3 criteria), operational (3 criteria) and commercial (3 criteria). Each category has a weight in the overall score, adjustable to your context.

Weights vary by profile. A bank subject to FCA inspections will give 35% to compliance. A growth-stage startup will favour technical and commercial criteria. The important thing is to set weights before evaluating solutions — not afterwards based on results.

Weighted scoring grid

Here is the complete grid with all 15 criteria. Score each solution from 1 to 5 on each criterion, multiply by the coefficient and add to obtain a comparable score.

Instructions. For each solution, multiply the score (1-5) by the coefficient. Add all results. The maximum score is 435 (15 criteria × 5 × average coefficient). A score above 350 indicates a solid solution. Below 250, the solution has significant gaps.

For a comparison of leading solutions evaluated against this grid, consult our buyer's guide to the best software.

Technical criteria: what to verify in depth

Criterion 1: extraction accuracy (coefficient 8)

Extraction accuracy is the most discriminating technical criterion. It decomposes into several metrics:

What to test. Do not rely on vendor benchmarks. Prepare a set of 50 to 100 documents representative of your real use cases, including degraded cases (poor quality scans, mobile photos, partially visible documents). Accuracy rates quoted (98-99%) often drop to 85-92% on real cases.

Question to ask the vendor: "Can you provide results from a test on our own documents, with a detailed report by document type and by field?"

Criterion 2: document types supported (coefficient 7)

Document coverage determines the STP (Straight-Through Processing) rate. A vendor announcing "500 document types" is only useful if they cover your specific documents.

Documents to verify systematically:

• Identity: UK passport, EU identity cards, BRPs, driving licences
• Company: Companies House certificates, articles of association, board minutes, powers of attorney
• Financial: bank statements, accounts, profit and loss statements, tax returns
• Certificates: HMRC compliance certificates, insurance certificates, professional indemnity
• Address: utility bills (electricity, gas), council tax bills, bank statements
• Sector-specific: quotes, contracts, planning permissions, certifications

Question to ask: "For each document type I submit, which fields are automatically extracted? Can you provide the exhaustive field list by type?"

Criterion 3: document fraud detection (coefficient 7)

Fraud detection goes well beyond OCR. Advanced solutions combine multiple techniques:

• Metadata analysis: EXIF, PDF structure, digital signatures
• Retouching detection: pixel analysis (ELA — Error Level Analysis), font consistency, element alignment
• Security element verification: MRZ, 2D barcodes, holograms (on video capture), watermarks
• Deepfake detection: photographic consistency analysis, AI artefact detection
• External source verification: Companies House, HMRC, official registers

In 2026, deepfake document detection is a major differentiator. Europol reports a 400% increase in AI-generated fraudulent documents between 2023 and 2025.

Question to ask: "What is your document fraud detection rate for digital manipulation cases? Do you have a specific module for AI-generated or AI-modified documents?"

Criterion 4: processing speed (coefficient 5)

Speed directly impacts user experience. Processing in under 5 seconds enables a real-time onboarding journey. Beyond 30 seconds, drop-off rates increase significantly.

Question to ask: "What is the P95 latency (95th percentile) in production for a standard document? For a complete file?"

Criterion 5: API and SDK quality (coefficient 6)

This criterion determines the cost and duration of technical integration. Points to verify:

• Documentation: complete, up-to-date, with working code examples
• SDKs: availability in your languages (JavaScript, Python, Java, .NET, PHP)
• Webhooks: asynchronous result notification (essential for batch processing)
• Sandbox: test environment with fictitious data
• Versioning: version management policy (backward compatibility, deprecation period)
• Rate limiting: requests-per-second limits and overflow policy

For a complete technical guide, consult our article on document verification API integration.

Question to ask: "Can you give us access to your sandbox with a test API token for 2 weeks? What is the average integration time observed with your clients for a scope similar to ours?"

Criterion 6: geographic coverage (coefficient 4)

If your activity is exclusively UK-based, this criterion is less of a priority. If you operate across multiple European countries or internationally, it becomes a knockout.

Points to verify:

• Number of countries covered (from 30 to 200+ depending on solutions)
• Depth of coverage per country (identity documents only vs business documents)
• Supported extraction languages (including non-Latin alphabets if relevant)
• Knowledge of local regulations (a Companies House certificate exists only in the UK — equivalents vary by country)

Compliance criteria: regulatory questions

Criterion 7: audit trail and traceability (coefficient 8)

In regulated sectors, the audit trail is not optional. It must document:

• Which document was verified (reference, type, timestamp)
• Which checks were performed (rules applied, results)
• What decision was taken (accepted, rejected, escalated)
• By which operator or algorithm (human/machine traceability)
• On what date and time (certified timestamp)

AMLD6 and MLR 2017 requirements. These regulations require retention of documents and verification results for at least 5 years after the end of the business relationship. The audit trail must be immutable, timestamped and available on demand during an inspection.

Question to ask: "Can you show me an example of a complete audit report for a processed file? Is this report exportable in a standard format (PDF, JSON)? How long is data retained?"

Criterion 8: certifications and data location (coefficient 7)

Certifications serve as a proxy for evaluating the vendor's security maturity:

Data location. Post-Schrems II, personal data transfers outside the EU/UK require enhanced safeguards. Verify where data is processed (not just stored) and whether the vendor can guarantee entirely UK/EU processing.

Question to ask: "Where are documents and extracted data physically processed and stored? Do you have sub-processors outside the UK/EU involved in processing? What security certifications do you hold?"

Criterion 9: native GDPR compliance (coefficient 6)

GDPR compliance is not a checkbox. Verify concretely:

• Data minimisation: the vendor retains only data necessary for processing
• Right to erasure: data can be deleted on request, with proof of deletion
• Portability: data is exportable in a standard format
• Privacy by design: default settings are the most protective
• DPA (Data Processing Agreement): a data processing agreement compliant with Article 28 GDPR

Question to ask: "Can you provide your standard DPA? What is the effective data deletion timeframe following an erasure request? Is data encrypted at rest and in transit?"

Operational criteria: integration and support

Criterion 10: SLA and availability (coefficient 6)

Beyond the overall percentage, verify:

• SLA per component (extraction API, supervision interface, reporting)
• Penalties for SLA breach (credits, refunds)
• Guaranteed recovery time (MTTR)
• Planned maintenance policy (windows, advance notification)

Criterion 11: support and onboarding assistance (coefficient 5)

Onboarding is the moment of truth. A vendor that supports you well during the first 90 days reduces deployment failure risk by 60%.

Points to verify:

• Support channels: email, chat, telephone, ticketing
• Languages: native English support or via translation
• Response times: support SLA (P1 critical < 1h, P2 major < 4h, P3 minor < 24h)
• Integration assistance: dedicated project manager, technical sessions, configuration review
• Training: standard programme, customisation options, training documentation

Question to ask: "Who will be my technical contact during integration? What is your support SLA for critical incidents?"

Criterion 12: documentation and community (coefficient 4)

Good documentation reduces integration time and support dependency. Evaluate:

• API documentation quality (completeness, code examples, changelog)
• Existence of a sandbox with predefined test scenarios
• Community presence (forum, Stack Overflow, GitHub)
• Step-by-step integration tutorials and guides
• Documentation in your language (an advantage for non-English-speaking teams)

Commercial criteria

Criterion 13: pricing model (coefficient 6)

Four models coexist on the market: pay-per-check, tiered subscription, volume-degressive and enterprise licence. For a detailed analysis of each model with price ranges, consult our pricing guide.

Key questions:

• Does the quoted price include all verification types or only simple verifications?
• What is the overage rate beyond the included volume?
• Are setup, training and customisation fees included?
• How do prices evolve in case of growth (doubling of volume)?

Criterion 14: contract terms (coefficient 4)

• Commitment duration: monthly, annual, multi-year. Annual commitments generally offer 15-30% discounts.
• Termination conditions: notice period (1 to 6 months), early termination penalties, data portability
• Data ownership: processed data remains your property. Verify the contract states this explicitly.
• Reversibility clause: the vendor commits to helping you migrate to another solution at contract end

Question to ask: "What are your exit conditions? In the event of termination, within what timeframe and in what format is our data returned?"

Criterion 15: roadmap and longevity (coefficient 4)

You will use this solution for 3 to 5 years. Evaluate the vendor's longevity:

• Company history: founding date, funding rounds, profitability
• Product roadmap: new features planned over 12-18 months
• Update frequency: a solution updated monthly is healthier than a frozen one
• Client base: number of clients, sectors, references in your industry
• Acquisition risk: a vendor acquired by a third party may change strategy or be absorbed into a larger suite

For comparing an external solution with internal development, consult our build vs buy analysis.

How to structure an effective POC (proof of concept)

The POC is the final step before the decision. It lasts 2 to 4 weeks and should cost only internal time — most vendors offer free or reduced-cost access during this phase.

Prepare the POC

Build the test dataset. 50 to 100 real documents covering all document types in your main flow. Include at least 10 degraded cases (poor quality, atypical formats) and 5 suspected fraudulent cases if available.

Define success criteria. Before launching the test, set validation thresholds in writing:

Assemble the POC team. A developer for technical integration, a business operator to evaluate results, a compliance officer to validate the audit trail.

Execute the POC

Week 1: technical integration. Connect the API, configure business rules, send the first batch of documents. Measure actual integration time and documentation quality.

Week 2: dataset testing. Process all 50-100 documents. Compare results with expected manual outcomes. Document each divergence.

Week 3: real-conditions testing. If week 2 results are satisfactory, process a sample of real files in parallel with the current process. Measure the concordance rate.

Week 4: evaluation and decision. Consolidate results, present to the decision committee, negotiate commercial terms.

POC pitfalls

• Selection bias: the vendor provides a dataset optimised for their solution. Use your own documents.
• Scope too narrow: testing only simple cases gives a false sense of confidence. Include edge cases.
• Ignoring integration: a POC limited to the vendor's web interface does not test the reality of technical integration.
• Forgetting compliance: checking accuracy without examining the audit trail is a common error in regulated sectors.

For a comparison of solutions to evaluate, consult our complete buyer's guide to the best software.

Frequently asked questions

How many solutions should you evaluate?

Three to five solutions represent the right balance. Fewer than three does not allow proper comparison. More than five disperses effort and delays the decision without improving the quality of the choice. Start with a shortlist based on public documentation, then run a POC on 2 to 3 finalists.

Is the scoring grid adaptable to my sector?

Yes. Adjust coefficients according to your context. A banking institution will increase the coefficient for compliance criteria (audit trail, certifications, GDPR). A marketplace will emphasise speed and geographic coverage. The important thing is to set coefficients before evaluation.

Should the CIO be included in the selection process?

The CIO or technical lead should evaluate integration criteria (API, SDK, architecture). The business lead evaluates functional criteria (document types, business rules). The compliance officer evaluates regulatory criteria. None of these three roles can evaluate the entire grid alone.

How do you handle a vendor that refuses a free POC?

It is a warning sign. The vast majority of serious vendors offer a free trial or reduced-cost POC. A vendor that demands a commercial commitment before any testing either lacks confidence in their solution or lacks commercial flexibility. In both cases, the risk is high.

What is the average lifespan of a document verification solution?

Between 3 and 5 years before renewal or replacement. The most frequent change drivers: evolving needs (new document types, new countries), dissatisfaction with performance or support, vendor acquisition by a third party, and regulatory evolution requiring capabilities not covered.

How do you assess vendor longevity?

Three positive signals: a diversified client base with references in your sector, recent funding rounds or demonstrated profitability, and high update frequency. Three negative signals: a single client representing more than 30% of revenue, no updates for more than 6 months, and predominantly negative recent user reviews.

Should you choose a UK vendor or an international one?

For exclusively UK flows, a UK or European vendor offers advantages: native knowledge of UK business documents, local support, guaranteed European hosting. For international flows, a global vendor offers broader document coverage. The best compromise is often a European vendor with international coverage.

This article is for informational purposes only and does not constitute legal, financial or regulatory advice.