KYC, AML, and Identity Tech: Verifying Users Without Killing UX

Two minutes. That was the promise on the sign-up screen. A new player tried to make a small deposit. The app asked for a passport photo. The room light was low. The camera warned about glare. The user tried again. This time the selfie check failed. “Move closer.” “Now turn your head.” Still no go. The user quit, left a one-star review, and never came back. That “two minutes” silently turned into twelve and a lost customer.

Every percent you lose in KYC is money gone and risk up. You need proof, but you also need speed. This guide shows how to do both, in plain words and with steps you can ship next week.

The real trade: certainty, speed, and privacy

KYC and AML exist to stop crime, protect the system, and keep you safe. Users want to move fast, share less, and feel in control. Product teams want high pass rates and low cost. Fraudsters try to blend in. The job is to balance it all without guesswork.

You do not have to pick “hard checks” or “happy users.” Use a risk-based path. Map key rules, then match controls to real risk. For a global baseline, see the FATF recommendations. They push for strong rules, but also for proportional, risk-based steps.

Regulatory ground truth, minus the buzzwords

Most rules share a few ideas: know your customer, screen for sanctions, keep records, and turn up checks when the risk rises. Put it in writing and keep proof of how you judge risk. That is the core of “risk-based.”

In the U.S., banks must run a Customer Identification Program (CIP). You need name, address, date of birth, an ID number, and a way to check them. Read the U.S. CIP rule for the base line and keep a clean audit trail.

Sanctions checks are not optional. Screen users and counterparties against official lists, like the OFAC sanctions list. Tune your name match rules to avoid floods of false hits.

In the UK, see the FCA’s guide on financial crime. It explains what good looks like in practice and what “proportionate” means. Start with the FCA financial crime guidance.

For the EU, two items matter a lot: AML risk factors and payment auth rules. The EBA risk factors guidance covers when to step up checks. For payments, learn how PSD2 uses multi‑factor auth (SCA). A good plain intro sits here: PSD2 Strong Customer Authentication.

The quiet UX tax of identity checks

Friction hides in small places: weak copy, poor light tips, error loops, slow manual reviews, and long forms. Many users fail not because they lie, but because the flow is unclear or the device has limits. Fixing this is cheaper than adding yet another check.

Write clear, short copy. Show what comes next. Let users try later or switch devices. This is not guesswork; there is good UX friction research you can apply in a day.

Design your forms with care. Micro details change pass rates: labels above fields, one idea per step, strong error text, and clear help. See this form usability study for patterns that work.

• Good: “Stand near a window. Hold phone at eye level. Blink twice when the ring turns blue.”
• Weak: “Make sure your face is visible. Try again.”

Identity methods that actually ship (and when to use them)

Do not stack every control for every user. Start light. Step up on signals: high amounts, odd device, bad IP, or hits on watchlists. Use strong methods only when they add real assurance. If you scan passports, follow ICAO Doc 9303. For a common language across risk, look at the NIST Digital Identity Guidelines. For liveness, ask vendors for liveness certification levels. If you test new models like verifiable credentials, start with the Verifiable Credentials data model. And if you bind accounts to devices, plan for passkeys to cut takeovers.

Privacy, data limits, and biometrics you can defend

Collect only what you need for the job. Write down why you need it. Set a clear time to delete it. If you use a vendor, ask where data lives and who can see it. If you must use face data, run a necessity test, use strong consent, and give a non‑biometric path when you can. The UK regulator has a plain guide: ICO guidance on biometrics and special data.

For EU‑level advice on biometric impact and consent, read the EDPB guidance. For a broad privacy frame you can adopt across markets, the OECD Privacy Guidelines are short and practical.

Blueprint flows by risk, with safe fails

Low risk (e.g., small wallet, low limits)

Collect basic PII. Run database match and sanctions. Skip document scans at first. Step up only on alerts (mismatch, risky IP, velocity).

Medium risk (e.g., payment app, mid limits)

Do ID scan + selfie match with liveness. Offer NFC read if a chip is present. Ask for proof of address only if triggers fire (e.g., high amount, fraud markers).

High risk (e.g., iGaming with large play, brokerage)

Use face liveness with clear copy, NFC when possible, and step up to source‑of‑funds on triggers. Build a fast lane for known good users: same device, clean history, stable payment method.

Safe fails matter. If a user fails on mobile, let them switch to desktop. If liveness fails twice, offer a call or a local branch ID check where allowed. Set a clean service time for human help, even on weekends.

For gambling, check age and location early and hard. The UK has strict checks—see the age and identity rules—and many markets have the same spirit even if words differ.

Build vs. buy: pick vendors without handcuffs

• Coverage: What countries and documents? Do they support local IDs and scripts?
• Liveness: Which PAD level? Give proof, not claims.
• NFC: Can they read chips on both iOS and Android? Show pass rates by model.
• Quality: Share false accept and false reject rates by scenario. How do they test bias?
• Updates: How often do models and templates update? How are edge cases handled?
• Privacy: Where is data stored? Who can view it? How long is it kept?
• Security: Ask for ISO/IEC 27001 and a recent SOC 2 overview.
• Manual review: What are SLAs? Time zones? Quality checks for reviewers?
• Pricing: Predictable? Do retries cost extra? Any lock‑ins?
• Controls: Can you A/B test copy and steps without a code release?

Metrics that matter and tests to run

• Time to verify: from start of KYC to pass/fail. Track medians and the long tail.
• Step drop‑off: where users leave. Fix the top two steps first.
• False rejects: root cause tags (light, glare, network, doc type, liveness).
• Manual queue time: average and weekend. Set a hard cap.
• Retry rate and second‑try pass: a strong sign of fixable UX.
• Fraud after KYC: chargebacks, mule flags, friendly fraud. Trend by method.

Run small A/B tests: copy on liveness, a help link on doc scan, a switch device prompt after a fail, and a “come back later” save. Ship wins fast.

What’s next: reusable identity, passkeys, and trusted wallets

We are moving from repeated KYC to reusable proof. With Verifiable Credentials, a user can hold a signed “KYC token” and share only what is needed, like age or country. The EU’s push for cross‑border digital ID will speed this trend through eIDAS 2.0.

On the auth side, passkeys cut account takeovers and reduce recovery pain. For open banking and secure APIs, align with FAPI so tokens and scopes are clean.

To build today, read a short primer and try a developer demo: Google’s guide to passkeys for developers is a good start.

Anti‑patterns to drop this quarter

• Asking for proof of address on day one for all users.
• Selfie‑first with no alternative path.
• Error messages like “Something went wrong.” Say what and how to fix it.
• Opaque rejects with no reason and no appeal.
• Keeping document images “just in case.” Set and follow a delete date.

Monday morning checklist

• Instrument each KYC step; log drop‑offs and reasons.
• Rewrite liveness and doc scan copy with clear tips and photos.
• Enable NFC chip read for passports and eIDs where legal.
• Add a fallback path: switch device, later upload, or human assist.
• Tune sanctions name matching; test with real edge cases.
• Write and publish data retention periods; set auto‑delete for images.
• Run a DPIA if you use biometrics at scale; record the outcome.
• Review vendor DPAs and data residency; confirm who can access data.
• Pick one AB test: help link on fail vs. no link. Ship in one sprint.
• Publish a help page with clear “why we ask” and “how to pass” tips.

FAQ

Is KYC required for gambling sites?
Yes. Most markets require age and ID checks before play or cash out. The UK is strict and clear; operators must verify age and identity early. Rules change by country, so check local laws and set a written policy.

Are face biometrics allowed under GDPR?
Often yes, but they count as special data. You must have a legal ground, a clear need, and strong security. Give users a non‑biometric option when you can, and avoid keeping raw face data longer than needed. National regulators like the ICO have practical advice.

What is the difference between KYC and SCA?
KYC proves who the user is at onboarding or when risk rises. SCA proves the user controls the account when they log in or pay, using two or more factors (something you know, have, or are). You need both, but at different times.

How do we show a risk‑based approach to auditors?
Write it down. List user types, risks, and triggers. Map each trigger to a step‑up check. Keep logs of decisions, false hits, and updates. Review the policy at least twice a year and after big rule changes.

Field notes (quick hits)

• Light fixes half of selfie fails. Add a “stand near a window” tip.
• NFC works great but needs a GIF or short video to show where to place the phone.
• “Save and finish later” can rescue 10% of rage quits in KYC.
• Age and geo checks up front reduce wasted liveness runs in iGaming.

One more thing: small things that pay off

• Sort error causes. Fix top three. Repeat monthly.
• Give a fast lane to returning users in good standing.
• Send a warm, plain “We verified you” email with next steps.

Not legal advice: This article is for information only. Work with your counsel and MLRO for your market and product. Last reviewed: 2026‑07‑05.

Sources and useful primers

• FATF recommendations
• U.S. CIP rule
• OFAC sanctions list
• FCA financial crime guidance
• EBA risk factors guidance
• PSD2 Strong Customer Authentication
• UX friction research
• Form usability study
• ICAO Doc 9303
• NIST Digital Identity Guidelines
• Liveness certification
• Verifiable Credentials
• Passkeys
• ICO guidance on biometrics and special data
• EDPB guidance
• OECD Privacy Guidelines
• UK Gambling Commission rules
• ISO/IEC 27001
• SOC 2 overview
• eIDAS 2.0
• FAPI
• Passkeys for developers