Skip to content
Magist
AnalyzeRegulationsVendorsCounselUpdatesCompareAbout
← All Controls

Know Your Customer (KYC) program

kyc-programDomain: paymentsType: mixed

Description

A KYC program is the customer-onboarding workflow that establishes who a customer actually is, calibrated to the risk that customer presents to the regulated activity in question. The architecture has settled across regimes into five layers stacked together. Identity collection captures legal name, date of birth, address, and a government identifier (Social Security Number or Tax ID in the US, national identifier in most EU member states, distinct national identifiers across the rest). Document verification checks a government-issued ID for authenticity through whichever document-verification vendor the operator has integrated; the document-authenticity check is the layer that has become most commoditized as Sumsub, Persona, Jumio, Onfido, and Veriff have converged on similar capabilities. Liveness or selfie-match binds the document to the human presenting it, protecting against document theft and against the increasingly common synthetic-identity attacks that pair real documents with stolen biometrics. Sanctions and PEP screening at onboarding and on a recurring cadence thereafter catches counterparties on the relevant restricted-party lists (OFAC SDN, UN Consolidated, EU Consolidated, UK OFSI, and others depending on operator footprint). And a customer-risk rating determines whether enhanced due diligence applies, with the EDD package requiring more documentation, more frequent review, and sometimes a senior-management approval gate before onboarding completes. The regulatory anchors vary across regimes but converge on similar substantive requirements. In the US, the Bank Secrecy Act and FinCEN's Customer Identification Program rule at 31 CFR 1022.220 set the floor, with the 2018 Customer Due Diligence Rule at 31 CFR 1010.230 layering on beneficial-ownership identification for legal-entity customers; New York DFS Part 200 and California DFAL augment the federal rules for virtual-currency activity, with NY DFS in particular running an active examination program. In the EU, the AML Directive series (currently AMLD6, with the AML Regulation 2024/1624 due to apply from July 2027 and the AMLA single supervisor operational from 2025) governs customer due diligence with member-state implementations under AML Regulation Articles 16 to 20; MiCA layers on a CDD overlay for crypto-asset service providers, with the Travel Rule under Regulation 2023/1113 obligating originator and beneficiary information on crypto transfers above the de minimis threshold. In the UK, the Money Laundering Regulations 2017 (SI 2017/692) set the framework, with the JMLSG Guidance providing the practitioner-grade detail and the FCA Handbook operationalizing it for FCA-supervised firms. The practical question regulators evaluate after the fact is rarely the technology of the verification step itself. Document-verification accuracy has become commoditized across the major vendors and the differences between them are usually below the threshold a regulator would notice. What regulators actually evaluate is the risk model: which customers got which level of scrutiny, whether that model was calibrated to the actual customer base the operator acquired rather than to the marketing pitch about who the customer base would be, and whether the EDD population was sized in a way that makes sense given the operator's product and geographic footprint. An operator with 0.1 percent of its customer base in EDD when its product and footprint suggest the figure should be closer to 5 percent will face the same regulatory follow-up as an operator with no risk model at all, even if every individual onboarding has a clean verification trail. The cheapest operational pattern is to set the risk-model thresholds based on a realistic projection of the customer base before launch, to instrument the actual distribution against those thresholds in the first six months, and to recalibrate openly rather than to defend whichever number was originally chosen. Regulators are substantially more sympathetic to a documented recalibration than to a fixed model that visibly does not match the population it screens.

Applicability

Applies when: sector is fintech.

How predicates are evaluated

Required by (4 regulations)

  • US MTL

    BSA Customer Identification Program (31 CFR §1022.220) + 2018 CDD Rule beneficial-ownership identification (31 CFR §1010.230); risk-based EDD for higher-risk customers; NY DFS Part 200 + CA DFAL augment for virtual-currency.

    Bank Secrecy Act, 31 U.S.C. §§5311-5336; 31 CFR Chapter X; per-state Money Transmitter Acts

    Source →

  • EU EMD2

    EU customer due diligence under 2024 AML Regulation Articles 16-18; beneficial-ownership identification with central register access; ongoing monitoring; PEP screening.

    Directive 2009/110/EC of the European Parliament and of the Council of 16 September 2009

    Source →

  • EU MiCA

    MiCA + EU AML framework CDD on CASP onboarding; Travel Rule originator/beneficiary information for crypto-asset transfers (Regulation 2023/1113).

    Regulation (EU) 2023/1114 of the European Parliament and of the Council of 31 May 2023

    Source →

  • UK FCA Payments

    MLRs 2017 Regulations 27-28 customer due diligence; risk-based EDD for higher-risk customers; JMLSG Guidance practitioner-grade reference; FCA Connect onboarding evidence.

    Payment Services Regulations 2017 (SI 2017/752); Electronic Money Regulations 2011 (SI 2011/99); FCA Handbook

    Source →

Fulfilled by (5)

  • sumsub · full · low effort · $$
  • persona · full · low effort · $$
  • jumio · full · medium effort · $$$
  • onfido · full · medium effort · $$$
  • veriff · full · low effort · $$

Magist does not accept payment from vendors. Methodology.

Evidence formats

  • KYC verification logs
  • document-authenticity checks
  • EDD memos for high-risk customers

Magist provides legal information based on publicly available regulatory sources. It does not constitute legal advice and does not create an attorney-client relationship. Consult a licensed attorney in your jurisdiction before making compliance decisions.

Magist

Pre-launch regulatory analysis for product teams. Built by a lawyer, designed for PMs.

Tools

  • Analyze
  • Guided walkthrough
  • Vendors
  • Find counsel
  • Saved analyses

Reference

  • Scope by business model
  • Scope by jurisdiction
  • App ratings
  • Regulations
  • Compare regulations
  • Enforcement
  • Browse Controls
  • Vendor coverage
  • Radar
  • Pulse
  • Changelog
  • Guides
  • Regulatory updates
  • Open data
  • Corpus license
  • Ontology
  • State of Compliance

Solutions

  • For legal teams
  • For engineering
  • For executives
  • For law firms
  • For investors
  • For teams →

About

  • About Magist
  • Methodology
  • Editorial standards
  • Reviewers
  • Coverage status
  • Corrections
  • Trust
  • Coverage scope
  • How we handle data
  • Sub-processors
  • FAQ

Built by Neel Patel, a practicing in-house games attorney. Games touch more compliance domains at once than anything else in tech — Magist was designed around that.

Magist provides legal information based on publicly available regulatory sources. It does not constitute legal advice and does not create an attorney-client relationship. Consult a licensed attorney in your jurisdiction before making compliance decisions. Operated by a Washington-licensed attorney. Not licensed in California or other US states. Magist provides legal information; consult a licensed attorney in your jurisdiction.

Magist is an instrument, not a consultancy. It does not sell compliance services or take payment from vendors for placement; the analysis is the same for everyone. No vendor, sponsorship, or referral fees, ever.

MethodologyLimitationsDisclosures

© 2026 Magist
TermsLicensePrivacySecurityLinkedIn