KYC Onboarding Software: 5 Requirements to Check Before Buying

Last updated: July 2026.

KYC onboarding software does more than scan an ID. The software you choose determines how fast customers get through, how much fraud you catch, and whether your compliance program holds up to regulatory scrutiny. This guide covers the five requirements every KYC onboarding platform must meet — and the gaps that separate compliant software from incomplete ones.

Every vendor on a KYC software shortlist claims global coverage, fast verifications, and full compliance. The actual differences sit below those claims — and they surface in audit findings, fraud losses, and integration timelines, not in demos. This guide covers the five structural requirements a KYC onboarding platform must meet, and the specific gaps to probe during evaluation.

TL;DR: KYC onboarding software is more than an ID scanner. It needs document coverage for the 16,000+ ID types your customers actually carry — not just country-level claims. It needs ISO 30107-3 certified liveness detection to stop deepfakes, mask attacks, and video injection. It needs AML screening that covers all four PEP tiers with ongoing monitoring, not just an onboarding snapshot. It needs SOC 2 Type II, ISO 27001, and GDPR-compliant data handling. And it needs a REST API plus WebSDK your team can integrate in days. Miss one of those five and the gap surfaces in fraud losses, audit findings, or engineering backlog.

Who this is for: Compliance leads, fintech founders, and engineering teams evaluating KYC onboarding software for a regulated product — crypto exchange, neobank, lending platform, iGaming operator, or any business required to verify customer identities under AML regulations before account opening.

Who this is NOT for: Businesses looking for HR employee onboarding tools, no-code form builders, or general CRM onboarding flows. The five requirements covered here are specific to identity verification under AML/KYC regulatory frameworks. If your onboarding requirement is compliance-driven, you’re in the right place. If it’s HR-driven, this is a different category entirely.

Related: Best KYC Software Providers — Ranked and Reviewed

Jump to a section:

• What Is KYC Onboarding Software?
• Requirement 1: Document Verification
• Requirement 2: Liveness Detection and Face Matching
• Requirement 3: AML Screening and Ongoing Monitoring
• Requirement 4: Data Security and Certifications
• Requirement 5: Integration Flexibility
• The Bottom Line

What Is KYC Onboarding Software?

KYC onboarding software is the technology layer that verifies a customer’s identity at the point of account opening or service activation. It collects identity documents, runs a liveness check to confirm the person is physically present, screens against sanctions and watchlists, and assigns a risk rating. All of it happens before the customer ever touches your product. For an overview of the full KYC process, see iDenfy’s KYC guide.

The five requirements below are not optional features. They are the structural conditions that a KYC platform must meet to actually deliver on what regulators expect and what your customers will tolerate.

Requirement 1: Document Verification That Covers Your Actual Customer Base

Document verification is the entry point for every KYC check. It is also the requirement with the widest variance between vendors. For context on what gets through when document checks fail, see fraud risks in onboarding. A platform can truthfully claim it supports “200+ countries” while being genuinely inaccurate on the specific ID types your customers actually carry.

The scope of the problem is larger than most teams expect. There are more than 16,000 distinct government-issued identity document types in circulation globally — regional driver’s licenses, national ID cards, residence permits, and multiple passport generations across nearly every country. Document layouts differ. Languages differ. Some documents use right-to-left scripts. A system that handles a German passport reliably but fails on a Moroccan national ID or a Brazilian regional driver’s license is not global coverage — it is partial coverage that will create friction or manual review queues for predictable customer segments.

Forgery detection adds another layer. Modern document fraud includes printed photographs, tampered holograms, and digitally edited ID files — and the software must detect these at the extraction stage, not flag them for human review after the fact. Optical character recognition (OCR) accuracy matters too: extracted data feeds into your CRM, your AML checks, and your audit records. Errors at extraction compound downstream.

What to look for

• Document type coverage: test on your actual customer document sample before committing — not just country-level claims.
• Automatic document classification: the system should identify the document type without the user selecting it manually.
• Multi-script OCR: including Arabic, Cyrillic, Chinese, and other non-Latin alphabets.
• Forgery and tamper detection built into the automated pipeline — not just flagging for human review.
• MRZ and barcode extraction as a secondary data source for cross-validation.

iDenfy supports over 16,000 document types across 200+ countries and territories, with automatic classification and extraction. The system handles right-to-left layouts natively and flags forgeries — including manipulated holograms and printed-photograph attacks — at the document analysis stage rather than routing them to a manual queue. Full supported document list is available directly on the iDenfy site for pre-sales validation.

“There has to be a way to validate it from the document as well. That’s a part of due diligence that we carry on.”

— Roshan Khurana, KYC compliance professional (12+ years in KYC)

Requirement 2: Certified Liveness Detection and Biometric Face Matching

A verified document without a verified person is an incomplete check. Document fraud and identity fraud are not the same thing — someone can submit a legitimate, unmodified ID that belongs to someone else entirely. Liveness detection and face matching close that gap: they confirm that the person presenting the document is physically present and matches the photograph on the document.

The threat environment here has changed significantly. Deepfake video attacks — where an attacker substitutes a synthetic face during the liveness check — are no longer niche. Injection attacks, where fraudulent video streams are fed directly into a mobile SDK bypassing the camera entirely, are also being deployed at scale. Printed photograph attacks and mask attacks remain active. See spoofing attack prevention for a breakdown of how each attack type works. Software that was adequate against these threats two years ago may not be adequate today.

There is also a real tension between security and conversion. More aggressive liveness challenges reduce fraud but increase genuine customer drop-off — particularly for older users, users on lower-quality devices, or users in poor lighting conditions. Passive liveness (single-frame analysis, no user action required) minimizes friction. Active liveness (user follows on-screen instructions) provides a stronger signal against certain attack types. The best implementations offer both and apply them based on risk level rather than treating every session identically.

What to look for

• ISO 30107-3 certification: the international standard for presentation attack detection — non-certified liveness is an audit liability. See what liveness detection covers and why certification matters.
• Passive and active liveness options, with the ability to configure which applies to which risk tier.
• Deepfake, injection, and mask detection explicitly — not just generic “liveness.”
• Face match accuracy data on your specific user demographics, not just headline benchmark figures.
• False rejection rate: how often does the system block genuine customers? This directly affects onboarding conversion.

iDenfy holds ISO 30107 certification and runs dedicated detection layers for deepfakes, mask attacks, and injection attacks. The platform applies risk-scoring at the session level — high-risk signals trigger enhanced liveness checks without applying that friction to every user. According to iDenfy’s internal data, this approach improves conversions by at least 20% compared to uniform active liveness across all sessions.

Requirement 3: Integrated AML Screening and Ongoing Monitoring

KYC and AML are legally distinct requirements, but in practice they run on the same data and the same event. A customer who passes identity verification but appears on a sanctions list should not onboard. A customer who was clean at onboarding but is designated by OFAC six months later should trigger a re-review. Treating KYC and AML as separate systems that never communicate is the architectural version of doing half the compliance job.

Scope matters here more than the headline claim. Ask any vendor and they’ll confirm they do sanctions screening. What they won’t volunteer: which lists they actually check, and how often those lists refresh. A module that runs OFAC but skips the UN Consolidated List, EU Financial Sanctions, or HM Treasury has real gaps — it just won’t say so in the pitch. PEP coverage has the same problem. There are four tiers: direct PEPs, immediate family members, known close associates, and domestic PEPs from lower-risk jurisdictions. Most platforms screen tier one. Most platforms market it as full PEP coverage.

Ongoing monitoring is the operationally complex part. Regulators don’t accept a one-time onboarding check as sufficient for high-risk customers or long-term relationships — customer status changes. Someone clean at signup can be designated by OFAC six months later. Batch monitoring runs overnight checks; event-driven monitoring catches a designation the day it happens. That gap — one day versus the next morning — is meaningful in an enforcement context.

What to look for

• Sanctions list coverage: OFAC, EU Financial Sanctions, UN Consolidated List, HM Treasury, Interpol, and regional equivalents. See the full list of AML databases iDenfy covers.
• PEP screening across all four tiers — ask vendors explicitly which PEP levels they cover.
• Adverse media screening with configurable risk categories.
• Ongoing monitoring that is event-driven rather than batch-only — or at minimum, daily batch updates with clear SLA documentation.
• Customizable blocklists for internal risk management, separate from public watchlists.
• Audit trail showing when each customer was screened, against which lists, and with what result.

iDenfy’s AML screening module covers OFAC, Interpol, and major global sanctions lists, screening all four PEP levels and including adverse media. For a full walkthrough of how sanctions screening works, see the sanctions screening guide and what AML screening involves. Ongoing monitoring runs at the customer profile level, not just at onboarding. Customizable blocklists allow compliance teams to apply internal risk rules in addition to public watchlist logic. All screening events generate a downloadable audit record.

“Your PEP, your sanction, your Adverse Media checks, to be able to verify passports, driver’s licenses — that kind of thing. That’s what we need.”

— Compliance lead, iDenfy prospect evaluation call

Requirement 4: Data Security and Verifiable Compliance Certifications

A KYC platform processes some of the most sensitive data your business will ever handle: passport scans, biometric samples, proof of address, date of birth. The security architecture around that data is not a vendor differentiator — it is a regulatory obligation. GDPR Article 25 requires data protection by design and by default for any processor handling EU residents’ personal data. CCPA imposes similar requirements for California residents. And the regulators who audit your KYC program will ask about your data processor’s certifications, not just your internal policies.

Certifications are the mechanism that makes security claims verifiable. SOC 2 Type II and ISO 27001 are the baseline — an independent auditor reviewed the vendor’s security controls and found them running as designed. ISO 30107-3 covers biometric presentation attack detection specifically; that’s the certification to look for on any liveness check. GDPR compliance is not a checkbox a vendor fills in themselves — it requires documented data processing agreements, defined retention periods, and a clear deletion process. All verifiable, none of it self-certified.

Data retention is a practical compliance requirement that gets overlooked in software evaluations. Financial regulators in most jurisdictions require identity verification records to be retained for five to seven years after the end of the customer relationship. Some require eight years. Your KYC software must support this retention period, provide tamper-evident audit records that can be produced in a regulatory examination, and also provide documented deletion processes for GDPR right-to-erasure requests — which pull in the opposite direction from long retention requirements and must both be satisfied simultaneously.

What to look for

• SOC 2 Type II certification — not just Type I — verifies controls are operating over time, not just designed correctly.
• ISO 27001 certification covering information security management.
• Signed Data Processing Agreement available before procurement — not a legal negotiation that begins after contract signing.
• Configurable data retention: some regulated customers require 5 years, others 8 — the platform should support your jurisdiction’s requirement.
• Downloadable PDF audit records per verification, formatted for regulatory examination.
• Documented data deletion procedures that satisfy GDPR right-to-erasure requests.

iDenfy holds SOC 2, ISO 27001, and ISO 30107 certifications and is GDPR-compliant with documented data processing agreements available before contract execution. Data retention is configurable up to eight years. Each verification generates a downloadable PDF audit record that includes document images, liveness results, AML screening outcomes, and timestamps — structured to meet the documentation requirements of a regulatory examination. iDenfy also carries Lloyd’s of London insurance coverage, adding a financial backstop to the technical and legal compliance framework.

Requirement 5: Integration Flexibility and Developer Experience

The best KYC software ships zero value if your team can’t wire it into the product. How long does integration actually take? How many sprints does maintenance eat after go-live? Can a compliance team update verification rules without opening an engineering ticket? Those questions matter — and the answers vary significantly between vendors.

In practice, the checklist is: a REST API with complete documentation you can read before signing anything, a Web SDK for browser onboarding, native SDKs for iOS and Android, and a sandbox. If a vendor needs a two-month professional services engagement before you’re live — that’s a services firm, not a software product. Ask them directly: how long for two engineers to go live? Anything over a month is a red flag. The honest answer is days, or a few weeks for a complex multi-platform build.

For any product where brand experience matters, white-label is table stakes. The drop-off signal is obvious: a user moves through your branded onboarding flow and hits a KYC step that suddenly looks like a different product — different colors, different domain, sometimes a different URL. Some close the tab. A fully embedded SDK or white-label option keeps the session in your UI. Same principle applies to language — an English-only interface on a platform serving Southeast Asia or LATAM creates friction that has nothing to do with the verification itself.

What to look for

• REST API with full documentation available before signing a contract — vendors that require an NDA to share API docs add friction to the evaluation process.
• WebSDK and native mobile SDKs (iOS and Android) with maintained changelogs and version history.
• Sandbox environment for development and QA testing — free to access before signing.
• White-label or fully embedded UI options with your brand’s color scheme and domain.
• Multi-language support — at a minimum, covering the languages your customers use.
• Configurable verification workflows — the ability to turn individual checks on or off by risk tier without engineering changes.

iDenfy provides a REST API, WebSDK, and mobile SDKs for iOS and Android, with a sandbox environment included in the free 14-day trial. The platform supports 40+ interface languages and offers full white-label customization. Verification workflows are configurable at the risk-tier level — meaning compliance teams can adjust which checks apply to which customer segments without requiring a new development sprint. The 14-day trial includes 10 complimentary verifications for real-environment testing before procurement decisions are made.

“Not a lot of coding needed. You can customize branding elements — upload your own logos, fonts, colors for different parts of the onboarding. API keys, webhooks — it’s all quite convenient.”

— Robert Kotov, Head of Partnerships, iDenfy

The Bottom Line

The five requirements above — document verification coverage, certified liveness and face matching, integrated AML screening, verifiable data security, and developer-ready integration — are the baseline for a KYC onboarding platform that does what it needs to do. Miss one and the gap surfaces somewhere: fraud clearing onboarding, conversions lost at the liveness step, a finding in the next compliance audit, or an engineering team buried in integration maintenance.

The evaluation process should move in the same order as the requirements. Start with document coverage — run your actual document sample through any shortlisted platform before the demo. Then check certifications — ask for SOC 2 Type II and ISO 30107 reports, not just claim statements. Then review the AML architecture — ask specifically about PEP tier coverage and whether monitoring is event-driven or batch. Integration quality you can assess yourself with a sandbox trial. Pricing model matters at the end: a pay-per-approved model (billed only on successful verifications) aligns vendor incentives with yours; a per-attempt model does not.

Related: Best KYC Software — Ranked and Reviewed

Related Articles

• Best KYC Software Providers — Ranked and Reviewed
• What Is Liveness Detection? How ISO 30107-3 Certification Works
• PEP Screening Guide: What the Four Tiers Mean and How to Check Them
• Sanctions Screening Guide: OFAC, EU, UN and What Gets Missed
• Fraud Risks in Onboarding: What Gets Through When KYC Fails
• Deepfake Detection in Identity Verification
• What Is AML Screening? A Compliance Team’s Practical Guide