KYC Without Losing Half Your Signups

KYC drop-off is one of those problems that teams underestimate until they look at their funnel data. The numbers are not flattering: industry studies from Signicat and others consistently put KYC abandonment rates between 40% and 68% depending on the sector. Fintech sits at the worse end. You are losing users before they ever see your product.

This post covers how to architect a KYC flow that keeps conversion high without creating compliance gaps. It assumes you already know what KYC is, you know what a liveness check is, and you are deciding how to actually build this.

Why Do Users Drop Off During KYC?

The short answer: friction that feels disproportionate to the task.

When a user is trying to open an account, every extra step is a bet you are making that they want your product more than they dislike the process. For most products, you are losing that bet somewhere around the third or fourth screen.

The specific friction points that consistently kill conversion:

• Asking for documents the user does not have on hand (passport rather than driving licence)
• Liveness checks that fail on older phones or in poor lighting
• No progress indicator, so users do not know how long the process is
• Re-asking for information already collected at signup
• Timeouts that restart the entire flow

The last one is particularly brutal. A user who fails a liveness check and gets sent back to screen one will almost never complete the journey.

What Is the Right Tier of KYC for Your Risk Level?

Not all KYC is the same, and one of the most common architectural mistakes is applying a single, maximal verification flow to every user regardless of risk. FATF guidance explicitly supports a risk-based approach, and most national regulators (FCA, RBI, MAS) have adopted this in their frameworks.

There are roughly three tiers worth modelling:

Tier	Typical Check	Suitable For
Simplified Due Diligence (SDD)	Email + phone + watchlist screening	Low-value, low-risk transactions
Standard KYC	Government ID + liveness + database match	Most retail fintech products
Enhanced Due Diligence (EDD)	Standard + source of funds + ongoing monitoring	High-value, high-risk, PEPs

If you put every new user through EDD, you will destroy your funnel. If you put everyone through SDD, your compliance team (and eventually your regulator) will have serious concerns.

The architectural decision here is to build a tiered, event-driven KYC system where users start at the minimum viable tier and get escalated based on transaction behaviour, risk signals, or regulatory triggers. You are not asking for more than you need at the point of onboarding.

Designing the Escalation Logic

Escalation should be triggered by events, not time. Concrete examples:

• Transaction amount crossing a defined threshold (commonly £1,000 or £10,000 depending on jurisdiction)
• Destination country flagged on your jurisdiction list
• Anomalous velocity: ten transactions in four hours for an account that normally runs one per day
• A watchlist hit on a name match that was previously low-confidence

Build this as a state machine. Each user has a KYC state. Events push them to the next state. The compliance team can review and override. This gives you auditability that a rules-based if/else system does not.

How Do You Choose Between Building and Buying the Verification Layer?

The vendor market here is mature. Onfido, Jumio, Veriff, Sum and Substance (Sum Sub), and Persona all offer SDKs with liveness detection, document OCR, and database matching baked in. Pricing is per-verification, typically in the £1.50 to £5.00 range depending on volume and check depth.

The case for buying is strong if you are pre-Series B. The engineering effort to build reliable liveness detection alone, across device types, lighting conditions, and spoofing attempts, is six to twelve months of focused work. The vendors have trained models on hundreds of millions of verifications. You will not beat that in a reasonable timeframe.

The case for building is relevant when you have very high volumes (millions of verifications per year where per-unit cost matters), a non-standard document set (regional IDs that major vendors do not support well), or a regulatory environment that restricts sending biometric data to third-party processors.

Most teams should integrate a vendor and focus their engineering effort on the orchestration layer: the logic that decides which checks to run, in what order, how to handle failures, and how to surface results to your compliance team.

The Orchestration Layer Is Where the Real Work Is

A good orchestration layer does the following:

1. Accepts a user identifier and a risk context (product, jurisdiction, transaction type)
2. Queries your risk model to determine which checks are required
3. Calls the relevant vendor APIs in the right sequence
4. Handles partial failures gracefully (retries, fallback to manual review, not hard errors)
5. Emits events to your audit log and your compliance dashboard
6. Returns a structured result that your product can act on immediately

This is not a simple API wrapper. It is a workflow engine with state, retries, and a dead-letter queue for cases that fall out of automated handling. Tools like Temporal or AWS Step Functions work well here. You want durability, because a KYC check that silently fails and leaves a user in an ambiguous state is a compliance problem.

Reducing Drop-Off Without Reducing Checks

The checks you run are largely dictated by regulation. What you control is how you run them.

A few changes that consistently improve completion rates:

Async where possible. Not every check needs to block the user. Database watchlist checks can run in the background. Let the user into a limited product state while the check completes. This is sometimes called a "provisional access" model and is explicitly permitted under SDD frameworks for low-risk products.

Progressive disclosure. Do not front-load all document requests on screen one. Show the user what they need to complete in order, with a clear count of steps remaining. Users who can see they are on step 2 of 4 complete at meaningfully higher rates than users who cannot see the end of the process.

Failure recovery, not failure termination. If a liveness check fails, give the user a specific reason and let them retry immediately. If they fail three times, route to manual review rather than hard rejection. Hard rejection at the point of liveness failure converts almost no one.

Mobile-first capture. Vendors like Veriff and Sum Sub have native SDKs for iOS and Android that significantly outperform web-based capture for document quality and liveness success rates. If your user base is majority mobile, this matters a lot.

Reduce re-entry. Pre-fill everything you already know. If the user gave you their name and date of birth at signup, do not ask again during KYC. Pull the values from your user record and use them for the verification match. Every redundant field is a potential drop-off point.

Compliance Monitoring After Onboarding

KYC is not a one-time gate. Ongoing monitoring is a regulatory requirement in most jurisdictions, and it is where a lot of fintech teams have compliance gaps they are not aware of.

The minimum you need:

• Periodic re-verification on a risk-based schedule (annually for standard users, more frequently for high-risk)
• Continuous watchlist screening against updated PEP and sanctions lists (OFAC, UN, EU Consolidated List)
• Transaction monitoring with configurable rules and a case management system for alerts
• A documented and tested process for handling positive watchlist matches

Most of the major KYC vendors offer ongoing screening as an add-on. It is worth evaluating whether to keep this with your onboarding vendor for simplicity or to bring in a dedicated AML tool like ComplyAdvantage or Acuris for the screening layer. The dedicated tools tend to have lower false-positive rates and more granular tuning, which matters when your compliance team is reviewing alerts manually.

Wrapping Up

The conversion problem in KYC is largely an architecture problem. Applying maximum friction to every user regardless of risk is the wrong default. Build a tiered system, buy the verification primitives from a vendor, own the orchestration layer, and treat failure recovery as a first-class feature rather than an edge case.

The next concrete step: pull your current KYC funnel data, find the screen with the highest drop-off rate, and look at the failure reason codes for that step. That will tell you whether you have a UX problem, a vendor configuration problem, or a flow design problem. Start there.

---

FAQ

What KYC abandonment rate should I expect? Industry benchmarks from Signicat put average abandonment between 40% and 68%, with fintech at the higher end. Mobile-first flows with clear progress indicators and fast liveness checks can bring this below 30%. Your actual number depends heavily on your user demographic and how much friction your product requires at onboarding.

Can I let users into the product before KYC completes? Yes, under a provisional or limited-access model. Many regulators permit reduced-function access while checks are pending, provided you restrict transactions below defined thresholds. You need to define what "limited" means precisely, document it in your compliance framework, and ensure the escalation to full KYC is automatic and auditable.

Should I build my own liveness detection? Almost certainly not. The major vendors have trained on hundreds of millions of verifications and iterate continuously on spoofing attacks. Building competitive liveness detection in-house is a six-to-twelve month engineering commitment with ongoing maintenance. Unless you have a specific reason a vendor cannot serve (regulatory data localisation, unusual document set), buy this layer.

How often do I need to re-verify users? This is jurisdiction-specific, but a risk-based annual review for standard users is a common baseline. High-risk users, including politically exposed persons (PEPs), warrant more frequent review. Your compliance policy document should specify the schedule, and your system should enforce it automatically rather than relying on manual reminders.

What is the difference between KYC and AML monitoring? KYC verifies who the user is at onboarding and periodically thereafter. AML monitoring watches what the user does: transaction patterns, counterparty behaviour, and watchlist matches on an ongoing basis. The two are complementary. KYC without AML monitoring creates a gap that regulators will flag; AML monitoring without solid KYC data at its base produces poor-quality alerts.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.