A polished identity-check demo tells a bank or lender little about the applications that will need the most work. The harder buying questions concern incomplete records, unsupported documents, interrupted sessions and findings a reviewer cannot explain. A useful selection process turns those cases into written requirements, then compares how each proposed service handles them across the whole onboarding journey.
Define the buying scope before the shortlist
Identity verification software connects an applicant to a claimed identity using evidence such as identity documents (IDs), source records and biometric comparisons. Suppliers package these functions differently. A full-service platform may combine several checks and case handling; an orchestration layer connects other services; a specialist supplies one kind of evidence.
At Trustable, we provide a specialist file-authenticity layer. Our onboarding authenticity checks examine ID images for edited photos and details, rebuilt templates and signs of AI generation. We check selfies for AI generation or editing, recorded and live video for face swaps and other generation traces, and proof-of-address utility bills and statements for editing. We do not perform liveness detection, biometric matching or database lookups. We recommend keeping those capabilities explicit in procurement so that adding a forgery check does not leave another identity requirement uncovered.
A brief function schedule provides a starting point for defining the buying scope. Institution-specific requirements extend beyond these categories:
| Function | What the proposed service must explain |
|---|---|
| Evidence and attribute validation | Which IDs it authenticates, which attributes it validates against source records, and which supporting documents it only reads. |
| Applicant-to-identity link | How it connects the applicant to the evidence, including the reference used for any face comparison. |
| Capture and attack defenses | What liveness, capture-integrity and forged-media controls cover, with separate evidence for each. |
| Workflow and case handling | How results reach your systems, how exceptions reach a reviewer, and what decision history remains available. |
The National Institute of Standards and Technology (NIST) separates evidence validation, attribute validation and applicant verification in its identity proofing framework. That is a useful technical vocabulary for requirements. It does not establish that a product satisfies every financial-services obligation.
For US banks, the Federal Financial Institutions Examination Council's Customer Identification Program guidance describes risk-based verification procedures and procedures for situations where identity remains unresolved. Institution type, product and jurisdiction determine the applicable duties. The institution's compliance team owns that scope. A supplier's claim of know your customer (KYC) compliance cannot define it.
Put source coverage in writing
A supported-country count does not explain whether a provider can validate the attributes your applicants present. The coverage schedule should identify the country, document version, language, capture method and source checks available for each intended journey. It should distinguish an ID template the software recognizes from an issuer record it can actually consult.
For each source check, the procurement record needs:
- The source's authority or basis for credibility, and the attributes it can corroborate.
- Whether the response comes from the issuer, an intermediary or an aggregated record, with material dependencies disclosed.
- Available freshness information and the treatment of outdated records.
- Matching rules for names, addresses and other attributes, including transliteration and recent changes.
- Separate outcomes for a conflicting record, no record, unavailable source and unsupported request.
The same underlying record accessed through different providers should remain identifiable as one dependency. More responses do not necessarily mean more independent evidence.
Supporting documents need their own scope. Extracting an address from a utility statement is different from examining the file for alteration or confirming an account record with its issuer. In lending, identity checks also leave income and asset claims to other controls. Our bank statement verification guide explains that separate evidence job.
Specify the result your reviewers will receive
A top-level pass or fail is too coarse for procurement acceptance. Each component needs a documented result contract: a stable definition of what it returns and what that result means.
A usable contract includes the application and attempt identifiers; the check performed; its completion status; the finding and reason code; the source or reference used; relevant timestamps; and the model, rule or service version. Supporting files and localized findings need durable references under the institution's retention policy. Where a score is supplied, its meaning, threshold and limitations belong beside it.
Service status, evidence finding and institutional disposition are separate fields. A timeout means a check did not complete. A mismatch means a completed comparison found disagreement. An unsupported document means that service could not assess the evidence. None should silently become “fraud.”
For example, an illustrative evaluation case can contain an unavailable source response and a later successful response. The case history should retain both attempts and identify which response the decision used. The later result must not overwrite the reason the application entered review.
A detector score is not automatically a calibrated probability of fraud. A marked region identifies a finding for review, rather than proving the applicant's intent. An unflagged file also does not establish that every claim in it is true.
Make integration failures part of acceptance
Integration choices affect what evidence survives. A hosted journey may simplify capture; an embedded software development kit gives the institution more control over the experience; a server-side application programming interface connects checks to existing systems. The proposal should state who owns capture, applicant notices, session recovery and reviewer access in the chosen arrangement.
Acceptance scenarios need to include duplicate callbacks, delayed results, interrupted uploads and responses arriving out of order. An authenticated callback should attach to the correct application and attempt. A retry should not create duplicate decisions or hide an earlier contradiction. The record should show which required checks finished before the application moved forward.
The implementation agreement also needs defined timeout behavior, service-outage handling and escalation contacts. An unavailable provider should produce an explicit operational exception, with access restrictions governed by institutional policy. Automatic approval during an outage is a policy choice with consequences, not a harmless technical default.
An export of a closed sample case should remain understandable outside the supplier's dashboard. A screenshot alone cannot supply a reusable history of responses, policy versions and reviewer actions.
Compare providers with a representative casebook
A useful evaluation casebook contains legitimate applications, authorized attack samples and operational failures. It reflects the actual countries, document types, devices, browsers and languages in scope. Supplier-selected demonstration cases can explain features; they cannot establish fit for a different applicant population.
The institution should define the expected handling before results arrive. Some cases have confirmed genuine or manipulated evidence. Others are deliberately unresolved and should be assessed on routing and explanation, without inventing a true identity or fraud label.
| Evaluation case | Evidence of acceptable handling |
|---|---|
| Genuine applicant with a low-quality capture | Specific recovery instructions, an accessible alternative and a record of the original attempt. |
| Recent name or address change | A visible discrepancy and a policy-approved way to resolve it, without silently changing the submitted data. |
| Limited source history | A distinct no-record outcome and an alternative evidence route, rather than a fabricated match or fraud finding. |
| Unsupported ID or document version | A clear coverage limitation and a controlled handoff. |
| Authorized forgery or manipulated-media sample | The component result and its limitations remain visible to the reviewer, including missed samples. |
| Provider outage or delayed callback | The correct exception state, controlled retries and no unintended account-opening decision. |
| Applicant returns through an assisted route | Earlier evidence stays connected to the case, with the assistance and final decision attributable. |
These are evaluation scenarios, not Trustable performance results or customer outcomes.
Component evaluation and journey evaluation answer different questions. A face-comparison result needs a defined reference and threshold. A liveness assessment needs its attack scope. Forged-media evaluation needs both manipulated and genuine samples. Our selfie and deepfake guide explains why those checks cannot substitute for one another.
NIST's remote proofing requirements distinguish injected-media defenses from biometric comparison and call for analysis of forged and genuine media, with manual review addressing detection errors. The procurement evidence should identify the tested product version, configuration and conditions. A component report does not establish the behavior of the complete deployed journey.
The evaluation record should count failed and incomplete attempts, not only completed checks. It should separate genuine applicants incorrectly challenged from attack samples accepted, and report unresolved cases separately. Results broken down by relevant document, device and applicant groups reveal limitations an overall average can hide. Where the sample is too small for a reliable conclusion, the record should say so.
Accessibility includes the route out of a failed check
An accessible start screen is insufficient when the camera flow, retry instructions or assisted handoff cannot be used. Procurement should require evidence covering the integrated journey against the applicable accessibility standard. The Web Content Accessibility Guidelines provide testable criteria for web content; a conformance report's scope and version need to match the proposed implementation.
Practical acceptance includes keyboard and screen-reader use, readable errors, zoom, session timing, camera permissions and recovery after interruption. Representative users need to be included, including people who cannot hold a device steadily or complete a particular movement. Language support must cover the error and support journey as well as initial instructions.
NIST's customer experience guidance emphasizes representative users, realistic tasks and contexts, and clear access to assistance. For a bank or lender, that means an alternative route with defined evidence requirements and an accountable owner. Repeatedly asking an applicant to complete the same inaccessible action does not resolve the case.
Every unresolved state needs an owner, a next evidence request, a response deadline and an escalation path. The supplier and institution need an agreed boundary for customer support, identity review and fraud escalation. A help-desk agent should not gain an undocumented ability to bypass verification. Applicants also need a usable way to raise an error or challenge an unresolved outcome without receiving details that expose fraud defenses.
Price the whole application and protect the evidence
Quotes are comparable only when their charging units are clear. A submitted application may trigger capture, source lookups, biometric checks, retries and manual review. The commercial schedule should state which events incur charges, including unsuccessful attempts, abandoned sessions and fallback providers.
Operating cost also includes integration maintenance, support, reviewer time, storage and exit. A lower per-check quote can still require more paid attempts or more internal handling. The commercial comparison should use the institution's expected journey mix, with assumptions visible rather than a single headline price.
Sensitive identity data needs a written handling schedule: storage locations, subprocessors, access controls, encryption, retention and deletion, plus any use for model training. The agreement should distinguish production evidence from sandbox samples and explain how deletion applies to backups and derived biometric data. Security reports need to cover the service and deployment being purchased.
Before contract approval, the institution needs export rights for its case evidence, notice of material source or model changes, support commitments and a workable termination process. Data retention follows applicable obligations and policy; indefinite storage is not a substitute for an evidence plan.
Turn the findings into a selection decision
Mandatory requirements should be separated from scored preferences. Missing required source coverage, unusable exception paths, unacceptable data handling or an inability to export decision evidence should not disappear inside a high weighted score for convenience.
For each requirement, the final comparison can record the evidence supplied, the observed limitation, the accountable owner and the acceptance decision. Fraud, compliance, operations, accessibility, security and engineering teams each have a distinct part in that decision. Open gaps need an explicit treatment before rollout, with a controlled launch and ongoing monitoring appropriate to the institution's risk.
The deliverable is a service the institution can operate and explain, including the applications it cannot resolve automatically.
Questions from software buyers
Is identity verification software the same as a complete KYC platform?
No. KYC covers a wider set of customer due-diligence activities. Identity verification establishes the identity evidence and applicant link within that process. Screening, business ownership checks and ongoing monitoring need their own scope, even when supplied in the same platform.
Can a specialist be added without replacing the existing provider?
Yes, when the integration and data-handling arrangements support it. A specialist can supply evidence missing from the current journey. Procurement still needs to define how that evidence reaches the case record, who reviews it and how it affects the institution's policy decision.
Add authenticity evidence to your existing review
We help onboarding teams examine ID images, selfies, video and proof-of-address utility bills and statements, with findings showing what was flagged, where it appears and the strength of the signal. These authenticity findings complement your identity verification provider. Routing results into your onboarding workflow is in development. Your compliance or fraud team decides the next action.
Book a demo to see authenticity findings on a sample onboarding file and discuss where they fit in your review process.