Buy identity verification with better questions
Before comparing identity-verification providers, write down the decision your business needs to make and the evidence needed to support it. A good buying process compares complete customer journeys, operating costs and failure handling, not a list of features.
Write a one-page buying brief
Bring the service owner, product team, fraud or security lead, privacy lead and whoever will handle exceptions into the same conversation. Begin with a real transaction. Who is the customer, what are they trying to do and why must the organisation check them? Define what would happen if an impostor were accepted and if a legitimate customer were refused.
Identity proofing, authentication and eligibility are different jobs. Proofing establishes confidence in an identity. Authentication helps a returning user demonstrate control of an account. Eligibility decides whether the person may use your particular service. An identity product can support these decisions, but buying one does not settle all three.
Use the NIST identity-proofing model to structure technical questions about evidence and ownership. It is a useful reference, not a substitute for the Irish rules applying to your sector. Confirm those rules with your compliance owner before turning a supplier's proposed workflow into a requirement.
Your brief should answer
- Which transaction needs a check, and at what point?
- Which customer groups, documents and countries must it support?
- What information is necessary, and what should never be collected?
- What existing result will the new service improve?
- Who will own failures, appeals and account recovery?
Buying for recruitment or worker onboarding
Add the hiring owner and candidate-support team to the buying brief. Specify which result the supplier returns and which decision remains with the employer. Do not let an identity score silently become the employment decision.
- Demonstrate an unsupported device, a name discrepancy, an accessibility alternative and a disputed result.
- Show how the result remains linked to the correct applicant through account and equipment issue.
- For staffing agencies, agree who performs the check, who may rely on it and who corrects an error.
- Return the minimum useful result to HR rather than routinely copying passports, selfies or biometric material into applicant systems.
- Provide genuine human review and a non-biometric route where the proposed biometric processing cannot be justified or completed.
EDPB consent guidance specifically discusses the employment power imbalance. That does not decide the lawful basis or Article 9 analysis for a particular Irish deployment. Require qualified review before procurement locks in the process.
Compare what each method establishes
A document photograph, passport-chip read, database match and wallet presentation produce different evidence. A scan can extract a name without proving the document is authentic. Reading a chip is distinct from validating its signed data. A genuine document does not, on its own, establish that the person presenting it is its rightful holder. Ask the provider to explain the complete chain.
For each proposed method, request its supported evidence, validation steps, holder checks and remaining limitations. Require a distinction between a result the product measures and one it infers. For example, matching an entered address with a record is not necessarily proof that the applicant currently lives there.
Put the same customer cases through each shortlisted workflow. A provider demonstrating only its preferred documents and latest phones has not shown how it will perform for your customers. Include expired or unsupported documents in the exercise so you can assess explanations and alternatives, while avoiding any assumption that your business may accept them.
Ask for evidence behind the claims
| Claim | Ask to see | What remains unresolved |
|---|---|---|
| “High accuracy” | Test population, thresholds and separate error measures | Performance on your customers and configuration |
| “Liveness protected” | Exact test scope, version and attack coverage | Controls against attacks outside that scope |
| “Wallet ready” | Wallet, credential, format and environment tested | Production support and operational dependencies |
| “GDPR compliant” | Configured data flow and contractual responsibilities | Your lawful basis, purposes and retention decisions |
Certification can be useful when you understand exactly what it covers. Record the legal entity, product, version, date, issuing body and exclusions. Do not allow a company-wide certificate to answer a question about a specific biometric component without checking that relationship. An independent assessment and a supplier statement should remain visibly different evidence types.
Keep a simple evidence register with the claim, source, date checked, limitation and next question. Where a supplier cannot provide material publicly, agree an appropriate review route. Do not invent a score to fill an empty cell. An unanswered question can be more useful than a tidy comparison table that conceals the gap.
Test the failure cases
ENISA's remote-proofing research describes several ways presentation checks can be attacked, including photos, replayed video and deepfakes. Ask what the proposed workflow tests and what other controls it needs. A claim about liveness should not stand in for an explanation of the whole remote journey.
For your pilot, agree safe tests with the supplier and your security team. Include a cancelled session, unavailable service, duplicate request, poor capture and an unsupported device. Evaluate how your application handles each result. Never use unsolicited tests against a live third-party system or real people's identities as an improvised security exercise.
Discuss manual review early. Who receives the case, what can they see, how long may it wait and what happens outside support hours? If all uncertain cases are pushed to your staff, a low price per automated check may hide significant operating cost. Ask how reviewer decisions are recorded, challenged and monitored for inconsistency.
Trace the data beyond the first API call
Map information from capture to deletion. Include the customer's device, hosted screens, provider systems, subcontractors, your application, support tools, analytics, logs and backups. Identify whether documents, facial images, templates, extracted attributes and decision records follow different retention paths. “Deleted after verification” is too vague unless the relevant copies and exceptions are named.
Ask who determines each purpose and who processes information on whose instructions. Then have your privacy and legal advisers review the actual arrangement. Do not assume a supplier's default agreement fits a different configuration. The GDPR is the primary legal reference; the supplier's marketing page is not a finding about your compliance.
Ask how you can test deletion, restrict support access and export the minimum records needed to answer a complaint. Consider whether raw evidence is genuinely needed after a result. Reducing what you retain may also reduce the material your team must secure, search and manage when the supplier relationship ends.
Make accessibility part of acceptance
Test people and devices that are not represented by the sales team's demonstration. A person may have a low-quality camera, an older phone, a changed appearance, a disability or difficulty following instructions in the available language. Decide what assistance is possible and what equivalent route remains available.
Measure where people leave. Separate refusal, inability to capture evidence, a technical failure and an adverse decision. A single “failed” count hides different problems. Include accessibility and recovery requirements in the contract and acceptance criteria, so they are not optional additions after integration is finished.
Read the wording on the customer's screen aloud. Does it explain why the check is needed, who processes the information and how to continue if it does not work? The experience belongs to your service even when another company hosts the identity screen.
Compare the cost of a completed outcome
Ask what creates a billable event. It might be an attempt, document, workflow, successful verification or monthly minimum. Establish whether retries, NFC, liveness, manual review, account checks and support are included. Ask what happens to unused volume and whether test environments or additional regions cost extra.
Build a modest forecast using your own expected mix. An illustrative comparison might start with 1,000 attempts, then add the number of repeats and manual reviews each workflow produces. Use explicit assumptions; do not present the result as a supplier quote. The point is to expose how an attractive unit price could change once failures and operational work are counted.
Track your team's integration time and ongoing maintenance too. A cheaper product that requires frequent custom changes can cost more overall. Conversely, paying for a broad platform is hard to justify if a narrower product satisfies your current requirement and has an acceptable exit path.
Agree what will make you buy, change or stop
A pilot should answer a decision, not merely end with a successful screenshot. Set the sample, methods, thresholds, data arrangements and review date in advance. Choose measures for customer completion, fraud controls, support effort and privacy. Write down which failures would stop the test and who may authorise a change.
Review outcomes across relevant customer groups where lawful and appropriate. An overall average can hide a particularly poor experience for one document type or device. Report sample limitations and uncertainty. A small test can rule out a bad fit or reveal needed changes; it cannot establish every future production outcome.
Use our pilot plan to structure the exercise. For a wallet product, add the wallet demonstration checklist so tested connectivity is not confused with readiness to operate your service.
Keep the exit visible before signing
Agree incident reporting, support hours, uptime definitions, liability allocation, change notice and subcontractor arrangements. Clarify what happens if a supported wallet, document or integration is withdrawn. Ask how you export your records and how deletion is evidenced at termination. Have qualified advisers review the terms that affect your risk.
Finish with a short decision record: why the selected approach fits, which evidence supports it, what limitations were accepted and who owns the open actions. Then use the editorial provider directory as a source of candidates, not a substitute for your evaluation. Providers cannot buy a favourable conclusion in this guide.
In this topic: Buying, privacy and implementation
How should a buyer define, procure, pilot and govern identity services?
View all 12 pages in this topic
Keep up with the Irish evidence
Independent briefings on wallets, identity verification and age assurance.
Join the business briefing