Identity verification RFPs go wrong when they ask whether a service "detects deepfakes" or "supports 200 countries", because every bidder says yes and the real differences only appear in pass rates, fraud slipping through and the per-check invoice. This template gives you a ready-to-issue request for proposal for a remote identity verification (IDV) service: document capture and validation, selfie and liveness, injection attack detection, database and authoritative source checks, orchestration, case review and pricing per check. Requirements are numbered, typed and written so that each answer can be tested in a proof of concept and scored. It uses NIST SP 800-63A-4 as the reference for measurable assurance, and it is vendor-neutral. It is written for onboarding product owners, fraud and compliance leads, security architects and procurement. For the market view, read the Identity Verification Buyer's Guide; for the selection process, the Security Vendor Evaluation and RFP Guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [monthly verification volume] and [supported countries], with your own details. Delete requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example IDV-LV-02) and a type: M mandatory (pass or fail; a fail eliminates the bid), S scored (0 to 5, weighted) or I informational. Keep M items to the few that are truly non-negotiable, usually assurance level, data residency and injection defence.
- Weights, volumes and thresholds in brackets are illustrative. Set them from your own fraud losses, regulatory obligations and conversion targets before issue, and never change them after responses arrive.
- Decide the target assurance level first. If you need NIST IAL2, the numeric thresholds in section 4 come straight from SP 800-63A-4; if you follow a national scheme (for example a UK digital identity trust framework or eIDAS for EU wallets), add its requirements as M items.
- Issue sections 1 to 9 to bidders. The Implementation guidance section is for your evaluation panel only.
- Ask for responses in a spreadsheet with one row per requirement ID, a documentation link for every "available now" answer, and the independent test report for every performance claim.
1. Purpose and scope
[Organisation] invites proposals for a remote identity verification service and associated implementation services, to verify the identity of [customers / applicants / account holders / workforce joiners] during [account opening, high-value transactions, account recovery, age assurance] across [web, iOS, Android, branch].
- In scope: document capture and validation; reading of chip (NFC) data where available; selfie capture with liveness and presentation attack detection; injection attack and forged media detection; face comparison; checks against authoritative and credible data sources; watchlist and politically exposed person screening [if required]; workflow orchestration; manual review tooling; reusable verified identity [if required]; APIs and SDKs.
- Out of scope: [customer identity platform, procured separately]; [transaction fraud monitoring]; [business verification (KYB)].
- Drivers: [synthetic identity and account opening fraud losses]; [regulatory customer due diligence obligations]; [completion rate below target]; [end of current contract].
- Target assurance: [NIST SP 800-63A-4 IAL2 remote unattended] for [journeys]; [IAL1] for [journeys].
- Contract term: [three] years with an option to extend by [two].
2. Organisation background and current state
| Item | [Organisation] value |
|---|
| Verifications per month today, peak month and in three years | [number] / [number] / [number] |
| Countries of residence and document types to support | [countries]; [passports, national ID cards, driving licences, residence permits] |
| Channels and devices | [web share], [iOS share], [Android share], [assisted channels] |
| Current completion rate and manual review rate | [%] / [%] |
| Known fraud patterns | [synthetic identities, mule accounts, document templates, face swaps, repeat applicants] |
| Regulatory drivers | [anti-money laundering customer due diligence, age assurance, sector rules] |
| Downstream systems | [customer identity platform], [case management], [fraud platform], [SIEM] |
| Data residency and retention requirements | [regions], [retention periods for images, biometric templates and results] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarification questions by [date]; answers shared with all bidders by [date]; responses due [date, time, time zone]; demonstrations and proof of concept [dates]; decision [date].
- Single point of contact: [name, email]. Other contact with [Organisation] staff about this RFP may lead to disqualification.
- Response scale: for each requirement state available now, available with configuration, requires custom code, third-party component (name the component category and whether you or a subprocessor operates it), roadmap (committed date) or not supported. Roadmap answers score zero unless the date is contractual.
- Evidence: cite the product documentation page for each answer. For every performance figure (liveness, face comparison, document validation) supply the independent test report, the test standard, the laboratory, the date and the product version tested.
- Subprocessors: list every subprocessor that receives images, biometric data or identity data, with country of processing.
4. Functional requirements
4.1 Document capture and validation
| ID | Type | Requirement |
|---|
| IDV-DC-01 | M | Supports the document types and issuing countries listed in section 2, with a published coverage list showing which checks run for each document (visual, machine-readable zone, barcode, chip). |
| IDV-DC-02 | S | Guided capture with real-time feedback on glare, blur, cropping and framing, plus live capture only (no gallery upload) as a configurable policy. |
| IDV-DC-03 | S | Compares machine-readable zone or barcode data with the printed data and checks document presence (physical document, not a screen or print), as SP 800-63A-4 Sec. 3.13 requires for automated validation. |
| IDV-DC-04 | S | Automated document validation meets a document false acceptance rate (DFAR) and false rejection rate (DFRR) of 0.1 or less, with test results published as SP 800-63A-4 Sec. 3.13 requires. State the test method and dataset. |
| IDV-DC-05 | S | Reads and cryptographically verifies chip data (NFC) on supported passports and ID cards, including passive authentication of the signed data, on [iOS and Android]. |
| IDV-DC-06 | S | Detects template-based and digitally altered documents, reused document images across applicants and known compromised document numbers. |
| IDV-DC-07 | I | Describe support for digital evidence such as mobile driving licences and digital identity wallets, and how signatures are verified. |
4.2 Selfie, liveness and face comparison
| ID | Type | Requirement |
|---|
| IDV-LV-01 | M | Presentation attack detection tested to ISO/IEC 30107-3:2023 by an independent laboratory, meeting an impostor attack presentation accept rate (IAPAR) below 0.07, the SP 800-63A-4 Sec. 3.11 threshold for remote collection. State the attack instrument species and levels tested. |
| IDV-LV-02 | S | 1:1 face comparison with a false match rate of 1:10,000 or better and false non-match rate of 1:100 or better, tested to ISO/IEC 19795-1:2021 and ISO/IEC 19795-10:2024, as SP 800-63A-4 Sec. 3.11 requires. |
| IDV-LV-03 | M | Demographic performance: no demographic group (sex, age, skin tone) more than 25% worse than the overall population at a fixed threshold, tested to ISO/IEC 19795-10:2024, with results published (SP 800-63A-4 Sec. 3.11). |
| IDV-LV-04 | S | Passive liveness option with no user gestures, and an active option for higher-risk journeys, selectable by policy. |
| IDV-LV-05 | S | Accessibility: capture flows meet [WCAG 2.2 AA], with an alternative route for users who cannot complete a biometric check. |
| IDV-LV-06 | S | Optional 1:N deduplication against [Organisation]'s own verified population to find repeat applicants, with manual review before any rejection based on a 1:N result. |
4.3 Injection attack and forged media detection
| ID | Type | Requirement |
|---|
| IDV-IJ-01 | M | Technical controls that detect virtual cameras, device emulators and rooted or jailbroken devices in every remote flow, as SP 800-63A-4 Sec. 3.14 requires. |
| IDV-IJ-02 | M | Analysis of submitted images and video for manipulation (face swaps, synthetic faces, morphs, replayed media), with documented false negative rates against current attack artefacts (Sec. 3.14). |
| IDV-IJ-03 | S | Device and app attestation for native SDKs, and signed, encrypted transfer of captured media from SDK to service. |
| IDV-IJ-04 | S | Web capture flow resists browser-level stream substitution; describe controls and their limits honestly. |
| IDV-IJ-05 | S | Update cadence for detection models when new generation tools appear, and notification to [Organisation] of material model changes before deployment. |
See the Deepfake and AI Impersonation Guide for the threat background.
4.4 Data checks, screening and orchestration
| ID | Type | Requirement |
|---|
| IDV-OR-01 | S | Validation of core attributes against authoritative or credible sources in [countries] (for example credit reference, electoral, mobile operator data), with source named per result. |
| IDV-OR-02 | S | Sanctions, watchlist and politically exposed person screening with ongoing monitoring [if required], configurable match thresholds and audit of dispositions. |
| IDV-OR-03 | S | No-code workflow builder: different journeys per country, product and risk score, with versioning, approval before publish and A/B testing. |
| IDV-OR-04 | S | Risk signals (device, IP, email and phone reputation, velocity) available to the workflow and returned in the result. |
| IDV-OR-05 | S | Result payload returns each check, its score, reason codes and the evidence strength achieved, not only a single pass or fail. |
4.5 Manual review and case handling
| ID | Type | Requirement |
|---|
| IDV-MR-01 | S | Review console with side-by-side document, selfie and check results, reason codes, four-eyes approval for overrides and full audit trail. |
| IDV-MR-02 | S | State whether vendor staff perform manual review, where they are located, how they are trained (including on manipulation indicators, Sec. 3.14) and the review service levels. |
| IDV-MR-03 | S | Feedback loop: confirmed fraud and false rejections marked by [Organisation] are used to tune rules for this tenant. |
| IDV-MR-04 | S | Redress route for applicants who are wrongly rejected, with an alternative verification path. |
4.6 Reuse, recovery and workforce use
| ID | Type | Requirement |
|---|
| IDV-RU-01 | S | Re-verification against the originally enrolled face for account recovery and help desk resets, without full document capture. |
| IDV-RU-02 | I | Describe any reusable identity or network model: what is shared across the vendor's clients, consent basis and how [Organisation] data is used. |
| IDV-RU-03 | S | Supports verification of new joiners and contractors before credential issue [if required]. |
See the Workforce and Help Desk Identity Verification Buyer's Guide for workforce scenarios.
5. Privacy, data protection and biometrics
| ID | Type | Requirement |
|---|
| IDV-PR-01 | M | Images, biometric templates, identity data and results stored and processed only in [regions], including backups, logs, manual review and subprocessors. |
| IDV-PR-02 | M | Configurable retention per data type (images, templates, results) with automatic deletion and deletion evidence; default retention stated. |
| IDV-PR-03 | M | No use of [Organisation]'s images or biometric data to train the vendor's general models without explicit written agreement. |
| IDV-PR-04 | S | Support for [Organisation]'s data protection impact assessment, including the lawful basis and conditions for processing biometric data and the applicant notice text. |
| IDV-PR-05 | S | Data subject requests (access, erasure) can be fulfilled by API within [days]. |
| ID | Type | Requirement |
|---|
| IDV-PS-01 | M | Independent assurance: [ISO/IEC 27001 certificate and SOC 2 Type II report] covering the verification service and manual review operations, plus a summary of the latest penetration test. |
| IDV-PS-02 | S | API credentials scoped per environment and journey, rotatable without downtime, with IP allow-listing and short-lived session tokens for the SDK. |
| IDV-PS-03 | S | Webhooks signed and verifiable; results retrievable only by authenticated server-side calls, never trusted from the client. |
| IDV-PS-04 | S | Console administrators use phishing-resistant MFA and SSO; roles separate configuration, review and data export. |
| IDV-PS-05 | S | Event and audit logs streamed to [SIEM] in near real time, including configuration changes and manual overrides. |
| IDV-PS-06 | M | Contractual availability of at least [99.9%], published status history, documented rate limits and a degradation plan if a data source or model is unavailable. |
The API keys and webhook secrets in IDV-PS-02 and PS-03 are machine credentials with access to identity data; manage them as described in the API Key Management Guide.
7. Implementation and support
- IDV-IM-01 (S): implementation plan, named staff and [number] references of similar volume and geography.
- IDV-IM-02 (S): SDK release cadence, minimum supported OS versions and deprecation notice period.
- IDV-IM-03 (S): support tiers, severity definitions and response times, including fraud attack escalation outside business hours.
- IDV-IM-04 (S): monthly reporting on completion, pass, refer and reject rates by country, document and device, and on detected attack types.
- IDV-IM-05 (M): exit: export of results and audit records in a documented format, and certified deletion of images and templates at contract end.
8. Pricing schedule
| Cost element | What to state |
|---|
| Pricing metric | Price per completed verification, per attempt or per check; how abandoned, retried and duplicate sessions are charged |
| Check bundles | Price for document only, document plus liveness, chip read, data source checks, screening and ongoing monitoring |
| Country variation | Any surcharge for specific countries or data sources |
| Manual review | Price per reviewed case, if vendor staff review |
| Volume model | Total cost at [current], [2x] and [5x] monthly volume over the term; minimum commitments; cap on renewal increases |
| Services | Implementation price, day rates and estimated days |
9. Evaluation method and proof of concept
[Organisation] will check mandatory items first, then score the rest with these illustrative weights:
| Criterion | Weight | Evidence |
|---|
| Attack resistance: liveness, injection, document fraud (4.1 to 4.3) | [25%] | Independent reports, red team results in proof of concept |
| Completion rate and user experience (4.1, 4.2) | [20%] | Proof of concept with real users, by device and country |
| Coverage, data checks and orchestration (4.4) | [10%] | Coverage list, demonstration |
| Privacy and biometric governance (5) | [10%] | Response, DPIA support, contract terms |
| Platform security and operations (6, 7) | [15%] | Assurance reports, questionnaire |
| Three-year cost at volume scenarios (8) | [20%] | Pricing schedule |
Scores: 0 not met; 1 roadmap only; 3 met with configuration; 5 met and demonstrated. Shortlisted bidders run a proof of concept of [number] weeks:
- Integrate the web flow and one native SDK into a test journey, using test API credentials issued for the proof of concept only.
- Run [number] consenting staff or recruited testers through the flow across [devices, countries, document types]; record completion time, pass, refer and reject rates.
- Run an authorised red team set prepared by [Organisation] or an independent tester: printed and screen replays, masks, altered documents and, with the vendor's written agreement, injected and synthetic media. Record which are caught and at which check.
- Review a sample of referred cases in the console and time each decision.
- Export results and audit logs to [SIEM]; confirm reason codes and evidence strength are present.
- Request deletion of all proof of concept data and verify the deletion evidence.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Measure both sides: fraud caught means nothing without completion rate. Score them together on the same proof of concept population, broken down by device and country.
- Insist on independent test reports: a laboratory report names the standard, attack levels and product version. A brochure figure without one scores zero against IDV-LV-01 to LV-03.
- Treat injection as the main threat: presentation attack testing alone does not cover virtual cameras and emulators. SP 800-63A-4 makes this point directly: biometric comparison alone does not stop these attacks.
- Read the result payload: a single pass or fail cannot feed your fraud models or support an audit. Reason codes per check are what you will use every day.
- Involve the data protection officer early: retention, training use of images and subprocessors are often decisive and slow to negotiate.
- Plan recovery and help desk use: attackers who cannot pass onboarding target account recovery. See the Identity Proofing and KYC Guide.
Common failure patterns
- Accepting self-declared accuracy: figures from the vendor's own dataset, with no standard and no laboratory, cannot be compared between bids.
- Testing only with friendly users: a proof of concept with staff on new phones shows high completion and no fraud, so neither number predicts production.
- Single score thresholds: one global threshold set in the proof of concept produces unexpected rejection rates in countries or demographic groups that were not tested.
- Per-attempt pricing surprises: retries and abandoned sessions billed as checks can double the effective cost per verified customer.
- Uncontrolled proof of concept data: real customer images sent to bidders without a contract or deletion commitment create a privacy incident before a vendor is chosen.
Framework mapping
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | NIST SP 800-63A-4 |
|---|
| Document and data validation (4.1, 4.4) | IA-12 | PR.AA-02 | Sec. 2.3, 2.4, 3.13 |
| Liveness and face comparison (4.2) | IA-12 | PR.AA-02 | Sec. 3.11 |
| Injection and forged media (4.3) | IA-12, SI-4 | DE.CM-09 | Sec. 3.14 |
| Privacy and biometrics (5) | PT-2 | GV.SC-06 | Sec. 3.11 (published results) |
| Supplier assurance (6, 7) | SA-9, SR-6 | GV.SC-06 | Not applicable |
Standards and references
Related NHI Mgmt Group resources: Identity Verification Buyer's Guide · Identity Proofing and KYC Guide · Biometrics Guide · CIAM RFP Template · Fraud Prevention Platform RFP Template