---
title: "How to Build a KYC and Identity Verification System in 2026"
author: "Nate Laquis"
author_role: "Founder & CEO"
date: "2029-03-15"
category: "How to Build"
tags:
  - KYC identity verification
  - identity verification system
  - KYC compliance
  - document verification API
  - AML screening
excerpt: "Building a KYC system means stitching together document verification, biometric matching, sanctions screening, and ongoing monitoring into a single reliable pipeline. Here is how to architect one that satisfies regulators and does not frustrate your users."
reading_time: "12 min read"
canonical_url: "https://kanopylabs.com/blog/how-to-build-a-kyc-identity-verification-system"
---

# How to Build a KYC and Identity Verification System in 2026

## Why KYC Is a Product Problem, Not Just a Compliance Checkbox

Most founders treat KYC as a regulatory annoyance. They bolt on a third-party widget at the last minute, ship it, and then spend six months firefighting failed verifications, compliance gaps, and user drop-off rates north of 40%. That approach costs you real money and real customers.

KYC is a product problem. The verification flow is often the first meaningful interaction a user has with your platform. If it takes seven minutes, asks for the same document twice, or crashes on older Android devices, you lose that customer permanently. At the same time, if your system is too lax, you expose yourself to regulatory fines that can reach millions of dollars. FinCEN, the FCA, and MAS are all increasing enforcement actions year over year.

The companies that get KYC right treat it as a core product flow with the same attention they give onboarding or checkout. They measure conversion rates through each verification step, they A/B test camera capture UIs, and they build robust fallback paths for edge cases. If you are [building a fintech app](/blog/how-to-build-a-fintech-app), this flow will directly determine your activation rate.

![Person holding smartphone showing identity verification screen for KYC process](https://images.unsplash.com/photo-1563986768609-322da13575f2?w=800&q=80)

This guide walks through the full architecture of a production KYC system: document capture and OCR, biometric liveness detection, sanctions and watchlist screening, ongoing monitoring, webhook-driven orchestration, and the manual review queues that catch what automation misses. We will name specific vendors, share integration patterns, and give you realistic timelines.

## Document Capture, OCR, and Data Extraction

The foundation of any KYC system is document verification. Your user submits a government-issued ID (passport, driver's license, national ID card), and your system needs to confirm that the document is authentic and extract structured data from it.

### How Document OCR Works

Modern identity document OCR goes far beyond basic text recognition. The pipeline typically runs in four stages. First, the system classifies the document type (passport, license, ID card) and country of origin. Second, it extracts text fields: full name, date of birth, document number, expiration date, and address where available. Third, it reads machine-readable zones (MRZ) on passports and checks digit validation. Fourth, it runs fraud detection checks on the document itself, looking for signs of tampering, photoshop artifacts, screen recapture (someone photographing a screen showing an ID), and mismatched fonts.

Vendors like Onfido, Veriff, and Jumio have spent years training models on millions of document types from 190+ countries. Rolling your own OCR pipeline with Tesseract or AWS Textract is technically possible, but you will spend months handling edge cases that these vendors already solve: laminated IDs with glare, low-resolution phone cameras, documents in non-Latin scripts, and the hundreds of different ID formats issued globally.

### Choosing a Document Verification Vendor

Here is how the major players compare in 2026:

- **Onfido** offers strong global coverage (2,500+ document types), a polished SDK for mobile and web, and a Studio product that lets you build custom verification workflows without code. Pricing starts around $2 per check for high volumes. Their AI-first approach means faster results (typically under 15 seconds) but occasional false positives on damaged or older documents.

- **Veriff** excels at session-based verification where the user is guided through a real-time video capture. Their assisted verification product uses human reviewers for complex cases. Particularly strong in European markets and for crypto/DeFi compliance. Expect $1.50 to $3 per verification.

- **Jumio** is the enterprise choice with deep integrations into banking and financial services platforms. Their NetVerify product supports 5,000+ ID types and includes certified liveness detection (ISO 30107-3). Pricing tends to be higher ($3 to $5 per check) but includes more comprehensive fraud signals.

For most startups, Onfido or Veriff gives you the best balance of coverage, developer experience, and price. If you are processing fewer than 1,000 verifications per month, expect to pay the higher end of per-check pricing until you negotiate volume discounts.

### Integration Pattern

All three vendors follow a similar pattern. You initialize a verification session server-side, receive a session token, pass it to your frontend SDK, and the SDK handles camera capture and image upload. The vendor processes the document and sends results via webhook. Never build document capture yourself. The SDKs handle camera permissions, auto-capture (detecting when the document is properly framed), image quality checks, and compression. Your custom camera UI will have worse conversion rates.

## Liveness Detection and Biometric Selfie Matching

Document verification confirms that a real ID exists. Liveness detection confirms that the person holding the ID is the person on it, and that they are physically present (not a photo printout, deepfake video, or 3D mask).

### Passive vs. Active Liveness

There are two approaches to liveness detection. Passive liveness analyzes a single selfie image for signs of spoofing: texture analysis to detect printed photos, reflection patterns that indicate a screen, depth estimation, and moire pattern detection. The user experience is seamless because the user just takes a normal selfie. Active liveness asks the user to perform actions: turn their head left, blink, smile, or follow a moving dot on screen. This is harder to spoof but adds friction and accessibility concerns (users with mobility limitations may struggle).

In 2026, passive liveness has improved significantly. Onfido's Motion product and Veriff's liveness check both achieve ISO 30107-3 Level 2 certification with passive capture. Jumio's iProov integration achieves Level 1 and Level 2 with a brief, light-based "flashmark" sequence. For most use cases, passive liveness with a certified vendor is sufficient and gives you better conversion rates than active challenges.

### Face Matching

After liveness confirmation, the system compares the selfie against the photo on the submitted ID document. This is a 1:1 biometric comparison. The vendor's model generates face embeddings (numerical representations of facial features) for both images and calculates a similarity score. Typical thresholds sit around 70 to 80% similarity, with anything below triggering manual review rather than automatic rejection.

Key edge cases to handle in your product flow:

- **Old documents:** A passport photo taken 10 years ago may look significantly different from a current selfie. Weight loss, aging, glasses, beards, and hairstyle changes all reduce match scores. Build messaging that tells users to remove glasses and hats before the selfie.

- **Lighting conditions:** Poor lighting is the top cause of failed biometric checks. Your SDK should display a lighting quality indicator before capture.

- **Twins and family resemblance:** Rare, but your manual review queue needs to account for it. Some regulated environments require additional verification steps if the document holder has a known twin on file.

![Close-up of biometric facial recognition technology used in identity verification](https://images.unsplash.com/photo-1556742049-0cfed4f6a45d?w=800&q=80)

Store biometric data carefully. Many jurisdictions (GDPR, BIPA in Illinois, CCPA) have specific rules about biometric data retention. Most vendors process biometric comparisons on their infrastructure and return only a match score, which means you never need to store raw biometric templates. Confirm this with your vendor and [make sure your GDPR compliance](/blog/gdpr-compliance-for-apps) covers the data flows.

## Sanctions Screening, PEP Checks, and Adverse Media

Verifying someone's identity is only half the KYC equation. You also need to confirm that the person is not on any sanctions lists, is not a politically exposed person (PEP) who requires enhanced due diligence, and has no adverse media coverage that signals risk.

### Sanctions and Watchlist Screening

At minimum, you must screen against these lists:

- **OFAC SDN List** (U.S. Office of Foreign Assets Control): The primary U.S. sanctions list. If you have any U.S. nexus (U.S. customers, U.S. banking relationships, or processing USD), screening against OFAC is mandatory.

- **EU Consolidated Sanctions List:** Required for any business operating in or serving EU customers.

- **UN Security Council Sanctions List:** Globally applicable and often mirrored in national lists.

- **HMT (UK):** Required for UK-regulated entities post-Brexit.

- **National lists:** Canada (OSFI), Australia (DFAT), and others depending on your operating jurisdictions.

Screening is not a one-time check at onboarding. Sanctions lists update frequently (OFAC updates multiple times per month), and you need ongoing screening against updated lists. Most vendors offer both one-time and continuous monitoring products.

### Vendor Options for Screening

ComplyAdvantage, Dow Jones Risk & Compliance, and Refinitiv World-Check are the dominant players. ComplyAdvantage is the most startup-friendly with API-first design and reasonable pricing for smaller volumes. They aggregate 12,000+ sanctions, watchlists, and PEP lists into a single API. Dow Jones and Refinitiv are more enterprise-oriented with richer datasets but steeper onboarding and pricing.

You can also use the screening modules built into Onfido, Veriff, or Jumio. Onfido's Watchlist product covers OFAC, EU, UN, and PEP lists, and running it alongside document verification simplifies your integration. The tradeoff is less granular control over matching thresholds and fewer list sources compared to dedicated screening providers.

### Adverse Media Screening

Adverse media checks scan news sources and public records for negative coverage: fraud convictions, money laundering charges, terrorism associations, and financial crimes. This is a requirement for enhanced due diligence (EDD) on higher-risk customers and a best practice for all customers at many financial institutions.

ComplyAdvantage and Dow Jones both offer structured adverse media feeds categorized by risk type. The challenge with adverse media is false positives. A common name like "John Smith" will return hundreds of irrelevant results. Effective screening requires fuzzy name matching with additional filters (date of birth, country, middle name) to narrow results. Budget time for tuning these thresholds because overly aggressive matching creates a flood of false alerts that overwhelms your compliance team.

### PEP Screening

Politically exposed persons (heads of state, senior government officials, military leaders, and their family members) require enhanced due diligence under most regulatory frameworks. PEP status does not mean someone is a criminal. It means they are in a position where corruption risk is elevated, so your compliance team needs to apply additional scrutiny: source of funds verification, ongoing transaction monitoring, and senior management sign-off on the relationship.

## Webhook-Driven Verification Architecture

A production KYC system is event-driven. Verification checks are asynchronous (document OCR takes 5 to 60 seconds, sanctions screening takes 1 to 5 seconds, manual reviews take hours), so polling for results is wasteful. Webhooks are the right pattern.

### Core Architecture

Here is the flow for a typical verification:

- **Step 1:** Your backend creates a verification session with your vendor (Onfido, Veriff, etc.) and stores the session ID linked to the user record in your database. Set the verification status to "pending."

- **Step 2:** Your frontend loads the vendor's SDK with the session token. The user captures their document and selfie. The SDK uploads media directly to the vendor's infrastructure (your servers never touch raw images).

- **Step 3:** The vendor processes the verification and sends a webhook to your registered endpoint. The payload includes the result (clear, consider, or failed), extracted data, and sub-check details.

- **Step 4:** Your webhook handler validates the signature, idempotently updates the user's verification status, and triggers downstream actions (unlock account features, queue for manual review, or send rejection notification).

### Webhook Reliability Patterns

Webhooks fail. Your endpoint might be down, the vendor might have a delivery issue, or a network blip drops the request. Build these safeguards:

- **Idempotency:** Process each webhook exactly once. Store the webhook event ID and skip duplicates. Vendors often retry failed deliveries, and processing the same event twice can corrupt your verification state.

- **Signature verification:** Always validate webhook signatures using the vendor's shared secret. This prevents spoofed webhooks from granting verification status to unverified users.

- **Async processing:** Accept the webhook immediately (return 200), push the payload onto a message queue (SQS, BullMQ, or Google Cloud Tasks), and process it asynchronously. If your processing logic fails, the message stays in the queue for retry. This is far more reliable than blocking the webhook response while you run database operations.

- **Polling fallback:** For critical flows, implement a periodic poller that checks for "stuck" verifications. If a session has been pending for longer than your expected SLA (say, 10 minutes for automated checks), query the vendor's API directly to fetch the result. This catches webhooks lost in transit.

If you are building [secure authentication flows](/blog/how-to-build-secure-authentication), you are already familiar with these event-driven patterns. KYC verification slots into the same architecture cleanly.

### State Machine Design

Model your verification as a state machine with clear transitions:

- **not_started** (user has not begun verification)

- **document_submitted** (images uploaded, awaiting OCR result)

- **document_verified** (document passed, awaiting biometric check)

- **biometric_passed** (face match successful, awaiting screening)

- **screening_clear** (no sanctions/PEP matches found)

- **approved** (all checks passed, account fully verified)

- **manual_review** (one or more checks flagged, human review needed)

- **rejected** (verification failed, with reason code)

- **expired** (session timed out before completion)

Persist every state transition with timestamps in an audit log. Regulators will ask for this during examinations. Every transition should record who or what triggered it (system, compliance analyst, API) and the evidence that justified the decision.

## Manual Review Queues and Ongoing Monitoring

No automated KYC system catches everything. You will always have cases that need human judgment: blurry documents, borderline face match scores, common-name sanctions hits, and documents from countries with limited verification coverage. A well-designed manual review queue is what separates a compliant system from one that either auto-rejects good users or auto-approves risky ones.

### Building the Review Queue

Your review queue should surface the right information to compliance analysts so they can make fast, accurate decisions. Each review case should display: the original document images, the selfie, OCR-extracted data alongside the raw images for comparison, the specific sub-check that triggered the review (with the vendor's confidence score), the user's self-reported information from onboarding, and any prior verification attempts.

Priority routing matters. A sanctions screening flag should jump to the top of the queue ahead of a blurry document re-submission. Build priority tiers: critical (sanctions match, fraud signal), high (biometric mismatch, document tampering suspicion), medium (low confidence OCR, expired document), and low (minor data discrepancy, re-verification request).

Track analyst metrics: average review time, approval/rejection rates per analyst, and overturn rates (how often a supervisor reverses an analyst's decision). These metrics help you identify training gaps and detect if an analyst is rubber-stamping approvals to hit volume targets.

### Ongoing Transaction Monitoring

KYC does not end at onboarding. Regulations require ongoing monitoring of customer activity for suspicious patterns. This means:

- **Transaction monitoring:** Flag unusual transaction patterns, amounts exceeding established thresholds, rapid movement of funds, transactions with high-risk jurisdictions, and structuring (breaking large amounts into smaller ones to avoid reporting thresholds). Tools like Unit21, Sardine, and Featurespace provide rule-based and ML-driven transaction monitoring.

- **Periodic re-screening:** Run your customer base against updated sanctions lists on a daily or weekly cadence. ComplyAdvantage and similar providers offer batch screening APIs that process your entire customer list against the latest lists and return only new matches.

- **Trigger-based re-verification:** Certain events should trigger fresh KYC checks. A customer changing their country of residence, a significant increase in transaction volume, or reaching a higher account tier should all kick off enhanced due diligence.

![Data analytics dashboard showing transaction monitoring patterns for compliance](https://images.unsplash.com/photo-1551288049-bebda4e38f71?w=800&q=80)

File Suspicious Activity Reports (SARs) when your monitoring detects genuinely suspicious behavior. In the U.S., SARs go to FinCEN within 30 days. In the UK, they go to the NCA. Your system should have a SAR workflow that guides analysts through the filing process and maintains a complete audit trail.

## Timelines, Costs, and Getting Started

Here is a realistic breakdown of what it takes to build a production KYC system, based on what we have seen across dozens of fintech projects.

### Implementation Timeline

- **Weeks 1 to 2:** Vendor evaluation and contracts. Sign up for sandbox accounts with Onfido, Veriff, or Jumio. Test document verification and liveness detection with your target user demographics. Negotiate pricing based on projected volumes.

- **Weeks 3 to 4:** Core integration. Implement the frontend SDK, backend webhook handlers, and verification state machine. Build the database schema for verification records and audit logs.

- **Weeks 5 to 6:** Sanctions screening integration. Connect ComplyAdvantage or your chosen screening provider. Configure matching thresholds, build the logic for handling potential matches, and set up ongoing monitoring schedules.

- **Weeks 7 to 8:** Manual review queue. Build the analyst interface, priority routing, case assignment, and decision recording. Connect the review outcomes back to the verification state machine.

- **Weeks 9 to 10:** Testing, edge cases, and compliance review. Run the full flow with test documents, simulate failure scenarios (webhook failures, vendor downtime), and have your compliance counsel review the system against applicable regulations.

Total timeline: 8 to 10 weeks for a team of 2 to 3 engineers. That assumes you are using vendor SDKs for document capture and liveness, not building custom computer vision pipelines. For a deeper look at what this costs, check our [KYC identity verification cost breakdown](/blog/how-much-does-kyc-identity-verification-cost).

### Cost Estimates

Per-verification costs vary by vendor and volume tier:

- **Document verification + liveness:** $1.50 to $5.00 per check (Onfido, Veriff, Jumio)

- **Sanctions/PEP screening:** $0.10 to $0.50 per check (ComplyAdvantage, Onfido Watchlist)

- **Adverse media:** $0.20 to $1.00 per check

- **Ongoing monitoring:** $0.50 to $2.00 per user per month

For a startup processing 5,000 verifications per month, expect $10,000 to $25,000/month in vendor costs. Engineering build cost (if outsourced) ranges from $40,000 to $120,000 depending on complexity and the team's rate. This is one area where getting the architecture right from the start saves you from expensive rework later.

### Where to Start

If you are building a KYC system today, here is the fastest path: pick Onfido or Veriff as your primary verification vendor (they cover document OCR, liveness, and basic sanctions screening in one integration), add ComplyAdvantage for deeper sanctions and adverse media screening, build webhook handlers and a state machine on your existing backend, and ship a basic manual review interface for your compliance team. You can add transaction monitoring and advanced ongoing screening in a second phase after launch.

Do not try to build document OCR or liveness detection yourself. The vendors have spent years and tens of millions of dollars training these models. Your engineering time is better spent on the orchestration layer, the review queue, and the user experience of the verification flow. If you want help architecting a KYC system that meets your regulatory requirements and does not tank your conversion rates, [book a free strategy call](/get-started) and we will walk through your specific use case.

---

*Originally published on [Kanopy Labs](https://kanopylabs.com/blog/how-to-build-a-kyc-identity-verification-system)*