We analyzed 50 recent RFIs, RFPs, and procurement requests for identity verification solutions. They ranged from short questionnaires for individual components to extensive procurement packages covering implementation, security, pricing, service management, and vendor due diligence.
The variety is understandable, as the identity verification projects differ by use case, market, risk level, technical environment, and procurement process.
This guide shows how to turn that context into clear requirements, structured vendor responses, and a practical basis for comparing proposals.
In brief: A useful RFP defines the business need and operating context without prescribing the solution. It gives vendors a common structure for explaining their approach, limitations, evidence, support, and pricing, so the buyer can compare proposals on the same basis.
What do identity verification RFPs usually contain?
Identity verification RFPs vary in purpose and structure. Across the documents we reviewed, three common formats appeared:
1. Feature checklist. A list of individual capabilities, such as OCR, NFC, liveness detection, or face matching. This format works well for early market screening, initial request for information (RFI), or when the buyer needs a single component.
On the flip side, it often produces similar “Yes” responses from most established vendors, making differences in quality, limitations, and total cost difficult to see.
2. Technical requirements specification. A detailed description of required capabilities, supported documents and markets, channels, architecture, integrations, security, and deployment. This format is most useful when the buyer has already defined the target solution and needs to assess technical fit.
3. Evaluation framework. A broader procurement structure that combines requirements with priorities, response formats, evidence, pricing assumptions, evaluation criteria, and PoC scenarios. It’s usually more useful when the buyer needs to compare different approaches rather than confirm compatibility with an already defined specification.
These formats aren’t maturity levels for identity verification. A short checklist may be entirely appropriate for an RFI or the purchase of a single component, such as a document verification SDK. A broader evaluation framework makes more sense when the organization is selecting an end-to-end identity verification platform or comparing different delivery models.
Regardless of format, the content of an identity verification RFP typically falls into eight areas:
| Area | What it defines |
|---|---|
| Business context | Why the organization needs identity verification, and which business problems it is trying to solve |
| Use cases and scope | Where verification happens, who completes it, when it is triggered, and through which channels (such as mobile app, web, or assisted flow) |
| Functional requirements | Document verification, biometric verification, fraud detection, identity lifecycle, access, and identity verification workflow management |
| Non-functional requirements | User experience, performance, FAR and FRR metrics, availability, security, and privacy |
| Integration and operating model | APIs and SDKs, cloud or on-premises hosting, data flows, manual review, and responsibilities |
| Vendor and implementation | Relevant experience, project team, deployment approach, trial or pilot options, customer support, and training |
| Commercial and contractual | Pricing, SLAs, liability, subprocessors, and termination |
| Evaluation | Mandatory criteria, evidence requirements, and PoC requirements |
Not every RFP needs to cover all the areas in the same depth. For example, the organization may need to:
-
Select an end-to-end identity verification platform
-
Replace or implement a digital onboarding solution
-
Add biometric verification or liveness detection to an existing process
-
Find an eKYC solution for a specific market or channel
-
Consolidate several identity verification providers
-
Select a primary and backup vendor
-
Move from SaaS to a self-hosted deployment
The right scope depends on the decision the RFP needs to support.
Do you need to define a technical solution before writing the RFP?
Not completely. An RFP can be specific about the technologies and checks the organization already knows it needs, without prescribing how the vendor must implement every requirement.
For example, the buyer may require NFC reading with chip authentication and certificate validation, face recognition, face matching, or specific document authenticity checks. It may also define the fraud cases the solution must detect, such as printed photos, injection attacks, or deepfakes.
The important part is to distinguish between fixed requirements and areas where different technical approaches are acceptable.
The RFP may therefore define:
-
Business process and use cases
-
Required checks and capabilities
-
Supported ID documents
-
Target users and user flows
-
Channels and devices
-
Operating systems supported
-
Fraud cases to detect
-
Regulatory and data requirements
-
Existing infrastructure and integrations
-
Architectural overview
-
Encryption and data protection
-
Operational constraints
-
Expected outcomes and acceptance criteria
Being specific about these requirements gives vendors a common baseline for their responses. Where the technical approach is left open, vendors can explain how they meet the requirement, which limitations apply, and what evidence supports their approach.
Example
The solution must include liveness detection for remote mobile onboarding and address impersonation attempts involving photographs, replayed videos, deepfakes, and manipulated camera input. Describe which of these attack types are covered, any user actions required, known limitations, fallback behavior, and supporting test evidence.
What context should you give identity verification vendors in your RFP?
The same identity verification technology can perform very differently across markets, document mixes, user populations, and risk levels. Without a shared context, proposed solutions, prices, implementation plans, and performance claims may then describe different services.
To give vendors a consistent basis for their proposals, describe these aspects of the future identity verification service:
1. Purpose and scope
A short qualification summary gives vendors enough information to judge whether they are likely to be a fit. It may state whether the organization is looking to implement an end-to-end identity verification platform, replace a component, add a new capability, enter new markets, or change the deployment model.
It can also flag deal-breakers upfront, such as mandatory countries, document types, channels, integrations, hosting requirements, data residency, or a fixed launch date.
Keeping the summary high-level helps vendors qualify the opportunity before investing time in a full response.
Example
The objective of this RFP is to select a solution that will [implement/replace/modernize] existing identity verification capabilities.
The selected solution will support approximately [volume] verification sessions annually across digital channels and will become a core component of the company’s customer onboarding and identity verification infrastructure.
2. RFP process and submission
A short process section can prevent incomplete submissions and unnecessary follow-up. It may cover:
-
Where proposals must be submitted, such as a procurement portal or a specific email address
-
Submission deadline and applicable time zone
-
Accepted file formats and file-naming requirements
Example
Submit the complete proposal through the procurement portal by [4:00 p.m. ET] on [date]. Proposals sent by email or submitted after the deadline will not be accepted. Submit the technical response as one file and the completed pricing worksheet as a separate attachment. Questions must be sent to the designated procurement contact by [date].
3. Use cases
Explain when identity verification will take place and what decision it will support.
Common use cases include:
-
Customer onboarding
-
Age verification
-
Account recovery
-
High-risk transactions
-
Periodic reverification
-
Assisted or in-person verification
A use case often shapes more than the technical flow. It also affects the organization’s risk appetite: how much uncertainty it is willing to accept and how strict the checks should be. That risk appetite comes from the company’s own policies and, in some cases, from regulation. A high-risk transaction, for example, may justify more friction than a lower-risk account action.
If you have multiple use cases, it’s better to describe them individually, as they may require different user journeys and fallback options.
Example: New customer contract registration
When registering a new customer contract, an authorized employee must be able to scan the customer’s identity document within the registration system.
The solution must:
-
Extract identity data from the document using OCR and MRZ
-
Validate the extracted data and document validity
-
Compare the extracted data with the customer information entered in the registration system
-
Automatically populate the relevant registration fields
-
Return one of the following results:
-
Complete match: all fields match
-
Partial match: non-critical discrepancies are found
-
Mismatch: A critical discrepancy is found
Critical fields include the customer’s name, date of birth, and identity document number. The result, identified discrepancies, and subsequent employee actions must be recorded in the audit log.
4. User population and markets
Specify who will complete verification and where they are located.
Relevant factors may include:
-
Countries and jurisdictions
-
Residents and non-residents
-
Customer or employee segments
-
Supported languages and scripts
-
Demographic diversity of the expected user population
-
Accessibility requirements
-
Expected levels of digital literacy
These conditions can affect document coverage, localization, regulatory obligations, biometric performance, and the amount of guidance users need.
Where biometric verification is used, it’s also useful to understand how the solution has been evaluated across relevant demographic groups and which performance differences, if any, were observed.
Example
The service will be used for digital and assisted customer onboarding in Cambodia. Identity data may be presented in either Khmer or English, and users may provide a national identity card or passport.
5. Channels and devices
Channel support does not necessarily mean feature parity. A vendor may, for example, support mobile capture through both a native SDK and a browser, but offer better capture quality or stronger fraud controls in the native flow. Channel-specific responses make these differences easier to see than a general “mobile supported” answer.
Example
Customers will complete verification through mobile applications, web portals, or assisted retail channels.
The solution must support native mobile applications running iOS 16 or later and Android 12 or later. Browser-based verification must be available on smartphones, tablets, laptops, and Chromebooks and support the latest maintained versions of Chrome, Edge, Safari, and Firefox.
6. Priority documents
Broad claims about document coverage can hide important differences in supported versions, data fields, and available authenticity checks. A vendor should explain:
-
Which documents and their versions are supported
-
Which checks are performed
-
How unsupported or unknown documents are handled
Example
The solution must support current Italian and international identity documents, including:
-
National identity cards
-
Passports
-
Residence permits
-
Temporary identity documents
-
Driver’s licenses
-
Italian health insurance cards
Support for all current versions of Italian identity documents is mandatory. The solution must account for country-specific variations in document layouts, formats, data fields, and security features.
New versions of supported documents must be added no later than 60 calendar days after their official issuance.
A real-world example of this level of specificity is UBS: its onboarding flow accepts biometric passports only, with Swiss residence permits additionally required for non-citizens, and includes RFID chip verification and authentication.
7. Volumes and usage patterns
Without shared assumptions, vendors may price different units: initiated sessions, completed verifications, or individual checks. Similar-looking totals can therefore cover very different scopes of service. To avoid this, it’d be useful to include:
-
Expected annual and monthly volumes (users, transactions)
-
Peak loads
-
Seasonal fluctuations
-
Expected growth
-
Country and document mix
-
Likely retries
-
Required test and production environments
-
Operating hours
Example
The expected annual volume is approximately [250,000–350,000] identity verification journeys, including identity document and selfie verification. The solution must support at least [target concurrent capacity] concurrent requests and batch processing of up to [expected batch size] existing records. A user may make up to three verification attempts before being redirected to an assisted support channel.
8. Existing systems
Describing the existing environment helps buyers and vendors identify the required integration points, data exchanges, and ownership boundaries. This may include:
-
Customer-facing web or mobile applications
-
Identity and access management (IAM/CIAM)
-
CRM
-
KYC or AML systems
-
Fraud prevention and risk management platforms
-
Case management and manual review tools
-
Analytics systems
-
Data storage
-
Notifications
-
Reporting and audit systems
Example
Identity verification will be embedded into the organization’s existing mobile application through an SDK.
The application will initiate the verification journey and provide the user’s email address and internal customer ID. Once verification is completed, the solution must return:
-
The extracted identity data
-
The captured selfie
-
The verification outcome
-
A unique verification reference
Upon successful verification, it must update the customer record, mark the verification as completed in the organization’s account management system, and trigger a customer notification. Journey events must be passed to the organization’s existing customer experience and analytics platforms.
9. Critical constraints and decision drivers
The last part of the context section can bring together the constraints and trade-offs that may shape — or rule out — a proposed approach. This is the place for non-negotiable requirements.
They may include:
-
Specific fraud scenarios the solution must address
-
Regulatory or internal policy requirements
-
Mandatory countries and document types
-
Data residency and deployment restrictions
-
Required integrations and existing infrastructure
-
Fixed implementation deadlines
-
User experience and conversion priorities
-
Required levels of automation
-
Budget or commercial constraints
Some regulatory requirements go beyond a simple compliance checkbox. If the use case involves qualified electronic signatures, for example, eIDAS requirements or relevant ETSI standards may affect the architecture, integrations, vendor responsibilities, and costs. Previous experience with the required framework may also become an important vendor qualification criterion.
Example
The solution must allow user data to be stored locally in Europe, North America, and China, with controls that prevent cross-region transfers where local data-residency rules apply.
By the end of the context section, a vendor should understand:
-
What the organization is trying to achieve
-
The conditions under which the solution must operate
-
Which risks and constraints matter most
How should you organize functional requirements in your identity verification RFP?
The context section explains (but is not limited to) where and why identity verification will be used. The next step is to define what the solution must do across that process.
Functional requirements can be organized by technology, product module, or internal owner. For many buyers, however, structuring them around the user journey makes gaps, dependencies, and areas of responsibility easier to identify.
| User verification step | What to consider |
|---|---|
| 1. User initiation and consent |
|
| 2. Document capture |
|
| 3. Data extraction |
|
| 4. Data verification |
|
| 5. Document authenticity | |
| 6. Biometric checks |
|
| 7. Decisioning |
|
| 8. Results and downstream actions |
|
Looking at requirements stage by stage makes gaps easier to spot. A solution may detect a capture problem, for example, without providing a clear recovery path, or identify conflicting document data without defining how that affects the final decision.
What operational and non-functional requirements should the RFP for identity verification cover?
Functional requirements define what the identity verification solution should do. Non-functional requirements define how reliably, securely, and efficiently it should operate.
Performance and scalability
Performance requirements are only comparable when vendors work from the same workload assumptions. Relevant questions may cover:
-
Expected and peak transaction volumes
-
Concurrent sessions
-
API rate limits
-
Response-time metrics
-
Regional differences in performance
-
Batch-processing requirements
-
Expected behavior during traffic spikes
-
Performance in low-bandwidth or unstable network conditions
It’s better to avoid asking only for an average response time. Averages can hide slow outliers that cause users to abandon the process.
Availability and resilience
It’s worth asking what happens when an individual component becomes unavailable: whether the process can continue in a degraded mode, switch to an alternative path, or must stop until the affected service is restored.
The RFP may ask about:
-
Service availability and how it is calculated
-
Planned maintenance
-
Regional redundancy and failover
-
Backup and disaster-recovery arrangements
-
Recovery time and recovery point objectives
-
Dependency failures
-
Degraded or fallback modes
-
Incident notification
-
Historical service performance
Security and auditability
Security requirements should reflect both the data being handled and the ways the service could be attacked. Depending on the scope, these may include:
-
Which encryption requirements apply to data in transit and at rest?
-
How are encryption keys generated, stored, rotated, and protected?
-
How should privileged access be controlled and audited?
-
Which security testing and vulnerability-management requirements should the vendor meet?
-
How should security incidents be detected, reported, and handled?
-
Which audit logs should the solution maintain?
It’s also worth clarifying where the vendor’s responsibility ends and the buyer’s begins. Some controls may be built into the product, while others depend on the buyer’s infrastructure, configuration, or operating procedures.
Privacy and data lifecycle
Identity verification may involve document images, extracted personal data, biometric data, device signals, and evidence used to support a decision. The RFP should make clear how each data type will be handled from collection to deletion.
Relevant questions include:
-
Which data should the solution collect, process, and store?
-
Which data handling and retention controls can the customer configure?
-
How are stored data, logs, biometric templates, and audit records protected?
-
For vendor-hosted deployments, where is the data processed and stored?
-
For vendor-hosted deployments, which subprocessors may access the data, and how are cross-border transfers handled?
-
For vendor-hosted deployments, may customer data be used to train or improve the vendor’s models?
It’s worth looking beyond broad claims such as “no data storage.” A vendor may still retain logs, derived data, biometric templates, fraud signals, or support records even when document images aren’t stored.
User experience, accessibility, and alternative paths
Clear guidance is an important part of verification performance. Document capture, NFC reading, and biometric checks can all fail for reasons that have little to do with fraud and a lot to do with how clearly the user is guided through the process. Poor guidance shows up in retries, abandonment, and lower completion rates.
Accessibility has the same operational consequence. If the default flow does not work well across languages, devices, levels of digital literacy, or accessibility needs, more users will fail or leave the process before verification is complete.
Questions to consider include:
-
What real-time guidance should the solution provide?
-
How should users be guided after a failed capture or inconclusive check?
-
Which accessibility requirements apply to the interface and capture flow?
-
Which languages should the interface, instructions, and error messages support?
-
How should the process support users with different levels of digital literacy?
-
Should the flow work on older or lower-quality devices?
Example
All user-facing components must conform to WCAG 2.2 Level AA. Instructions, capture guidance, and error messages must be available in the supported user languages.
Users who cannot complete the default document or biometric flow must be offered a secure assisted or manual verification path that meets the level of identity assurance required for the use case.
Implementation and vendor support
Implementation support can affect how quickly the solution goes live and how smoothly it operates afterward. It’s worth understanding what help the vendor provides during a proof of concept (PoC), integration, rollout, and ongoing operation.
Relevant questions may include:
-
Is a PoC or trial available, and on what terms?
-
Who will support implementation, testing, and rollout?
-
What technical resources will the vendor assign?
-
What training is provided?
-
Which support levels and response times are available?
-
How quickly can the vendor address product gaps or add support for new documents and markets?
What should you ask about the vendor?
Choosing an identity verification solution also means adding a third party to a sensitive and often regulated process. The vendor becomes part of the organization’s third-party risk and compliance assessment.
The RFP may therefore need to cover:
-
Experience with similar use cases, markets, and regulated industries
-
Customer references from comparable projects
-
Relevant security, privacy, and quality certifications
-
Company ownership, financial stability, and insurance
-
Partners, subcontractors, and subprocessors involved in delivering the service
The scope of due diligence should reflect both the risk of the use case and the vendor’s role in delivering the service.
For example, the deployment model changes what needs to be examined. With a self-hosted solution, the review may focus more on software supply-chain security, vulnerabilities, updates, and vendor access during implementation or support. With a vendor-hosted service, it usually extends to hosting controls, data locations, subprocessors, privileged access, availability, and business continuity.
How can you compare identity verification pricing and licensing terms?
Identity verification pricing is rarely apples-to-apples. One vendor may bundle document verification, liveness detection, face matching, and workflow management into a single price. Another may charge separately for every check, retry, environment, or support service.
Using the same use cases and volume scenarios makes the commercial proposals easier to compare. Useful questions include:
-
What is the billing unit: transaction, session, user, or another metric?
-
What does the quoted price include?
-
What costs extra?
-
How are retries billed?
-
Are implementation, training, PoC, and support included?
-
How will the price change as volumes, markets, or requirements grow?
The goal is to compare the cost of the full verification journey, rather than isolated line items. A lower headline price may reflect a narrower scope, with additional fees for checks, retries, or support.
Build an RFP package, not one enormous questionnaire
An RFP doesn’t need to be a single document containing every product, security, legal, and commercial question the organization may want to ask. A modular package is usually easier for vendors to complete and for internal teams to evaluate. It also prevents detailed due diligence questions from obscuring the capabilities that will actually determine whether the solution fits the use case.
Depending on the scope, the identity verification RFP package may include:
-
An RFP overview with the business context, scope, expected volumes, procurement process, and response instructions
-
A requirements and response matrix
-
A separate security and vendor RFI questionnaire
-
A pricing template based on common volume and usage assumptions
The exact package will depend on the decision the company needs to make. What matters is not the number of questions. The RFP package should provide vendors with sufficient information to propose an appropriate solution and give you, as the buyer, enough structure to evaluate the differences among those proposals.
If you’re defining requirements for a new identity verification solution, Regula can help you understand what is feasible across your target documents, markets, channels, and deployment model.
Discuss your identity verification requirements with Regula.
