KYC and Identity Verification Buyer’s Guide

An applicant can present a genuine document that belongs to someone else. A business can exist in a registry while the person controlling it remains unclear. Those two cases show why document capture, identity verification, fraud controls, customer due diligence, and business verification must be evaluated as connected but distinct functions.

This guide covers technology used to collect and verify identity attributes for people and organizations. It does not decide the institution’s legal customer-due-diligence obligations. The FATF Recommendations provide a risk-based standard that jurisdictions implement through their own frameworks. Buyers must translate applicable requirements and policy into testable outcomes for their customers, products, and channels.

Decision context

Define the decision the system will support. Is it confirming that an identity exists, that evidence is authentic, that the applicant is the evidence holder, that a business is active, that ownership has been collected, or that risk requires manual review? A platform may perform some of these steps and depend on other services for the rest.

Map every onboarding route: individual, sole proprietor, private company, public company, partnership, trust, nonprofit, financial institution, and any jurisdiction-specific form. Record whether the customer is present, remote, assisted, introduced, or acting through a representative. Identify the authoritative evidence and fallback path for each route.

FATF’s Digital ID guidance advises regulated entities to understand a digital identity system’s technology, architecture, governance, and assurance levels, then judge whether those levels are appropriate for the relevant money-laundering and terrorist-financing risks. It does not say that any one digital method is automatically sufficient.

Set current baselines: completion, abandonment, automated and manual decisions, exception reasons, confirmed fraud, review time, data quality, jurisdiction coverage, and downstream corrections. Treat vendor-reported conversion or fraud figures as non-transferable until tested on the institution’s flow and population.

Requirements checklist

Identity proofing for people

Collect only the identity attributes needed for a documented purpose, and record the applicable lawful basis and any further condition required for sensitive data.
Provide applicable privacy information and transparency at collection; rely on consent only where it is appropriate and can be validly given.
Validate document type, integrity, expiry, security features, and data consistency where supported.
Separate document authenticity from holder binding, such as face comparison or liveness checks.
Support approved non-documentary evidence and authoritative data sources.
Detect repeated or linked applications using shared identifiers under documented policy.
Provide accessible alternatives for customers who cannot complete one digital route.

In the UK context, the ICO’s lawful-basis guide says organizations should identify and document a valid basis before processing and include the purpose and basis in privacy information. Its data-minimisation guidance says personal information should be adequate, relevant, and limited to what is necessary. The ICO also explains that consent is one possible basis and is not always appropriate. Buyers must map these jurisdiction-specific principles to the laws and data types in scope.

Business and ownership verification

Retrieve or validate registration status, legal name, number, address, form, and officers from identified sources.
Record source jurisdiction, query time, returned data, and conflicts.
Collect ownership and control information according to the institution’s policy.
Represent layered ownership without flattening uncertainty.
Escalate unavailable, stale, conflicting, or unsupported registry results.

Decision and evidence

Return granular check results instead of only a pass/fail response.
Explain which evidence, rule, threshold, or provider response drove the decision.
Preserve submitted data, extracted data, transformations, source responses, configuration version, user actions, and timestamps.
Support controlled override, reason capture, quality review, and rework.
Define retention, redaction, deletion, and export behavior.

Integration and operations

Use secure APIs, callbacks, batch processes, or interfaces suitable for the onboarding design.
Make retries idempotent and expose partial, timed-out, or unavailable checks.
Monitor latency and success by route, document, jurisdiction, device, and customer segment.
Version workflow and decision configuration.
Separate administration, review, approval, support, and audit permissions.

Evidence to request

Request the provider’s source and document coverage by country and document type, update process, test methods, known limitations, and dependencies. Ask which results come from government or authoritative sources, licensed databases, the provider’s own analysis, or another subcontractor. Obtain sample raw and normalized responses.

For biometrics or liveness, request evaluation methods, attack coverage, threshold controls, demographic performance analysis where lawfully available, presentation-attack testing, device assumptions, and manual fallback. For document checks, ask how altered images, screenshots, photocopies, expired documents, unsupported versions, glare, cropping, and extraction conflicts are handled.

The EBA risk-factor guidelines address risk assessment and customer due diligence in a European regulatory context. FINRA’s AML overview describes a risk-based customer identification program for member firms. These sources illustrate why requirements must be tied to the institution’s applicable framework; neither validates a supplier.

Request privacy and security evidence: data-flow diagrams, subprocessors, processing locations, encryption, key management, access logs, retention controls, incident procedures, independent assurance scope, and deletion evidence. Identity artifacts are sensitive. Minimize collection where policy allows and verify that “deletion” applies to derived files, debug records, and subcontractors.

Proof-of-concept test plan

Construct an approved, lawfully sourced, or synthetic test pack for every in-scope route. Include valid and invalid documents, supported and unsupported versions, near-expiry documents, inconsistent attributes, low-quality images, repeated applications, name and address variations, business registry conflicts, layered ownership, service timeouts, and customers who need manual alternatives.

Run these stages:

Capture. Test the real web or mobile flow on representative devices, networks, languages, and accessibility settings.
Verification. Compare expected and returned results for each individual check, not just the final decision.
Binding and fraud. Exercise approved presentation-attack and mismatch cases under controlled conditions.
Business data. Query organizations with clean, stale, conflicting, unavailable, and layered records.
Exceptions. Interrupt downstream services, repeat callbacks, submit corrections, and move cases through manual review.
Evidence. Reconstruct sampled decisions from retained artifacts, source responses, settings, and user actions.
Scale and privacy. Measure peak behavior and confirm retention, redaction, export, and deletion controls in a test environment.

Report results by route and segment. Measures can include completion, check-level error, false acceptance and false rejection where the test supports them, manual-review rate, time to decision, abandonment location, unavailable-source rate, exception resolution, and evidence completeness. Do not merge distinct outcomes into one “verification accuracy” percentage.

Commercial and implementation questions

Establish what counts as a billable verification. Clarify charges for attempts, retries, documents, biometric checks, registry queries, database checks, users, environments, stored artifacts, enhanced support, and manual review. Model abandonment, repeated attempts, fraud spikes, new jurisdictions, and peak campaigns. Ask whether minimum volumes apply separately to each service.

Assign implementation responsibilities:

Who owns the customer journey and accessible fallback?
Who decides accepted evidence and risk-based routes?
Who integrates manual review and screening?
Who investigates source conflicts and suspected fraud?
Who sets and approves thresholds?
Who validates before launch and after material changes?
How are customer corrections propagated downstream?
How are data and evidence exported or deleted at exit?

Review contractual allocation for source availability, lawful processing, security incidents, breached credentials, biometric data, subcontractors, and changes to coverage. A service-level credit does not repair an unlawful or unreviewable onboarding decision.

Red flags

Pause when the provider equates document extraction with identity verification, cannot identify a data source, or returns a final decision with no check-level evidence. Other warnings include automatic approval when a critical service times out, no manual route, unclear biometric retention, unsupported demographic claims, and a country-coverage total that does not specify document versions or registry fields.

Do not accept “fully compliant KYC” as a product property. Compliance depends on law, policy, risk assessment, configuration, data, and operations.

Procurement implications and limitations

Score proofing coverage, assurance, fraud controls, business verification, explanations, privacy, security, resilience, accessibility, integration, implementation, and cost separately. Include compliance, fraud, privacy, security, customer experience, accessibility, technology, operations, legal, and procurement stakeholders in the decision.

A proof of concept cannot measure every document, attack, population, or source outage. Government and registry data can be incomplete or delayed. Biometric and automated methods can produce different outcomes across conditions and populations. The approval record should state which routes were tested, accepted limitations, fallback controls, monitoring measures, validation ownership, and the events that require reassessment.