KYC Explained: Process, Requirements, and APIs

KYC, or Know Your Customer, is the process an organization uses to establish who a customer is, assess the risk of the relationship, and keep that understanding current. In regulated sectors, KYC operationalizes customer due diligence: it connects identity evidence, verification, risk assessment, screening, decisions, records, and ongoing review.

KYC is not synonymous with a document scan. A document check can validate one piece of evidence, while a complete KYC program decides what evidence is sufficient, how higher-risk cases are handled, when a customer must be reviewed again, and how every decision can be explained later.

Key takeaways

• KYC is a lifecycle, not one check. It begins before or during onboarding and continues when identity data, sanctions exposure, ownership, or behavior changes.
• eKYC is the digital delivery of KYC. It can use documents, authoritative databases, biometrics, NFC, and other remote evidence, but it does not remove the underlying compliance obligation.
• KYC and AML are related but different. KYC identifies and assesses the customer; AML is the broader control framework that can also include transaction monitoring, investigations, reporting, and governance.
• Risk determines depth. Lower-risk applicants may follow a simpler path, while higher-risk relationships may require enhanced due diligence and human review.
• A KYC API is only one part of the operating model. Teams also need policy, orchestration, exception handling, audit records, privacy controls, and monitoring.

What does KYC mean?

KYC means knowing enough about a customer to make and maintain a defensible decision about the relationship. The exact legal duties vary by jurisdiction, sector, product, customer type, and risk level. The common operating pattern is to identify the customer, verify reliable evidence, understand the purpose and expected nature of the relationship, assess risk, and monitor for material changes.

The Financial Action Task Force guidance on digital identity treats digital identity systems as one way to support customer identification and verification. It does not turn a technology result into automatic compliance: the regulated organization remains responsible for judging whether the system, assurance level, and controls are appropriate for the risk.

KYC is often used casually as shorthand for identity verification. That shorthand is useful in product conversations, but incomplete in a compliance program. Identity verification answers whether the person presenting evidence is linked to the claimed identity. KYC also asks whether the relationship is understood, whether risk is acceptable, and whether the customer profile remains current.

KYC, eKYC, CDD, AML, CIP, and KYB compared

Term	Practical meaning	Typical scope	Common mistake
KYC	Know and assess an individual customer	Identity, risk, screening, decisions, records, review	Treating it as a one-time document upload
eKYC	KYC completed through digital channels	Remote evidence capture, validation, biometrics, database checks	Assuming “electronic” means lower assurance
CDD	Customer due diligence	Identity, beneficial owner where relevant, purpose, risk, monitoring	Reducing CDD to sanctions screening
EDD	Enhanced due diligence for higher-risk cases	More evidence, source-of-funds or wealth checks, approvals, closer monitoring	Applying the same workflow to every risk level
AML	Anti-money-laundering control framework	KYC, screening, transaction monitoring, investigations, reporting	Using KYC and AML as interchangeable terms
CIP	Customer identification requirements, especially in US usage	Collecting and verifying identifying information	Assuming one country’s CIP rules are universal
KYB	Know Your Business	Entity status, ownership, controllers, business activity, linked people	Verifying the company but not its beneficial owners

These terms overlap because they describe different layers of the same operating problem. KYC is customer-focused. CDD is the risk-based legal and operational process. AML is the wider financial-crime framework. eKYC describes the channel. KYB applies similar reasoning to a legal entity and its ownership.

How does the KYC process work?

The strongest KYC flows separate policy from evidence. Policy defines what must be proven and what happens at each risk level. Evidence and technical checks support that policy.

1. Set the policy and trigger

Start with the reason for the check. Account opening, a regulated transaction, a payout, account recovery, a limit increase, or a material profile change may require different assurance. Define the jurisdictions, customer types, accepted evidence, prohibited relationships, escalation rules, retention periods, and owners before choosing API fields.

2. Collect identifying information

Collect only the attributes needed for the purpose and applicable obligation. Common fields include legal name, date of birth, residential address, nationality, and a government identifier. Business customers require entity data and ownership information instead.

Data minimization matters here. Collecting more data does not automatically create more assurance; it can create privacy, security, and operational risk if the information has no defined use.

3. Resolve the claimed identity

Identity resolution determines whether the supplied attributes point to a real, distinct person in the relevant population. The evidence may be a government-issued document, a digital credential, an authoritative database record, or a permitted combination.

The current NIST identity-proofing model separates resolution, validation, and verification. That distinction is useful outside US government use because it prevents teams from collapsing three different questions into one score.

4. Validate evidence and attributes

Validation asks whether the evidence is authentic, accurate, and acceptable under policy. A document flow can inspect format, expiry, printed and machine-readable fields, security features, tampering, and issuer data. A database flow can compare submitted attributes with authoritative or credible sources.

Validation should return evidence, warnings, and reason codes—not only “pass” or “fail.” A mismatched machine-readable zone, an expired document, and an unsupported document are different operational conditions and may require different actions.

5. Verify the applicant is the rightful holder

Verification links the person in the flow to the validated identity. In a remote document flow, that can involve live capture, liveness detection, and a one-to-one face comparison between the applicant and the portrait on the evidence.

These checks answer different questions:

• Document validation: is the evidence genuine and acceptable?
• Face match: does the presented face correspond to the reference portrait?
• Liveness: is a living person present at capture rather than a presentation artefact?
• Capture integrity: did media come through the expected sensor and channel rather than being injected?

No single answer replaces the others.

6. Screen and assess customer risk

Risk assessment combines identity results with the purpose of the relationship, geography, product exposure, customer type, and other policy factors. Where required, screening can cover sanctions, politically exposed persons, adverse media, and other relevant sources.

A potential match is not necessarily a confirmed match. Names can collide, lists can be incomplete, and context matters. Good workflows preserve the matched fields and source data, apply thresholds, and route ambiguous or higher-risk cases to trained reviewers.

7. Decide, enroll, and preserve evidence

The outcome should map to an explicit state such as approved, declined, retry, or manual review. Store the policy version, evidence references, provider responses, reason codes, timestamps, reviewer actions, and final rationale needed for audit and appeal.

Do not let the browser decide whether access is granted. The backend should consume a signed webhook or retrieve the final result from the API, verify authenticity and idempotency, and then update the customer state.

8. Monitor and refresh

KYC continues after onboarding. Refresh can be periodic or event-driven when a document expires, ownership changes, sanctions data changes, behavior diverges from the expected profile, or a higher-risk action occurs. Transaction monitoring and ongoing AML screening are related controls, but neither should silently rewrite the original identity record.

What is eKYC?

eKYC is KYC conducted through electronic channels. It replaces or supplements in-person collection with remote evidence capture, digital credentials, authoritative database queries, biometric verification, NFC chip reads, or a combination.

The evaluation question is not “digital or manual?” It is whether the evidence, capture method, fraud controls, and exception process reach the assurance required for the use case. A well-designed remote flow can collect strong evidence and create a detailed audit trail. A poorly designed flow can automate weak checks at high speed.

eKYC also changes the failure modes. Teams must account for manipulated media, virtual cameras, device emulators, accessibility needs, camera quality, network loss, repeated attempts, and users who cannot present the default evidence. Exception handling is part of the control, not an afterthought.

How do KYC and AML fit together?

KYC is one component of AML controls. It creates the customer identity and initial risk picture that downstream controls rely on. AML can also include sanctions and PEP screening, ongoing screening, transaction monitoring, alert investigation, suspicious-activity reporting, recordkeeping, training, governance, and independent testing.

The relationship is easiest to see as a timeline:

1. Before the relationship: identify, verify, screen, and risk-rate the customer.
2. During the relationship: monitor activity and changes against the expected profile.
3. When risk changes: refresh evidence, apply enhanced due diligence, restrict activity, investigate, or report as required.
4. At closure: preserve required records and apply any continuing restrictions.

That is why an aml kyc search should not lead to a page that discusses only document capture. The identity decision supplies context; ongoing controls test whether reality continues to match it.

What should a KYC API provide?

A KYC API should expose a stable contract for creating checks, receiving results, and handling exceptions. The exact endpoint shape matters less than the operational guarantees around it.

Core API capabilities

• A customer or vendor reference that maps the check to your own record.
• Idempotency for create and retry operations.
• Explicit workflow or policy versioning.
• Hosted and embedded capture options where relevant.
• Signed, retryable webhooks with documented event states.
• A retrieval endpoint so consumers can reconcile missed events.
• Structured reason codes, warnings, and evidence-level results.
• Separate states for technical failure, user retry, review, approval, and decline.
• Test data and sandbox scenarios for both success and failure paths.
• Retention, deletion, residency, and access-control documentation.

A minimal integration pattern

Your backend
  -> creates a verification session with an internal customer reference
  -> sends the user to the approved capture flow
  -> receives a signed event
  -> retrieves the final decision from the provider API
  -> applies your own policy and customer-state transition
  -> records the evidence, reason, and policy version

The vendor result is an input into your decision. Keeping the policy boundary in your backend makes it possible to change thresholds, providers, or workflows without losing control of the customer state.

How should teams evaluate a KYC service?

Regulatory and assurance fit

Ask which identity-proofing model the service supports, what evidence strengths are available, which jurisdictions and customer types are covered, and what independent tests apply to each component. A certification for one biometric mechanism does not certify the full onboarding journey.

Fraud resistance

Review document attack coverage, presentation attack detection, injection defenses, face-match evaluation, repeated-device or identity controls, and manual-review tooling. Ask for test protocols, attack classes, false-accept and false-reject results, and how performance changes under compression, poor lighting, older devices, and unseen attacks.

Coverage quality

“Global” is not a test plan. Build a matrix of the countries, document types, scripts, data sources, and customer populations you actually serve. Run production-like samples and track completion, rejection, review, and unsupported-evidence rates by segment.

Decision quality and operations

Inspect reason codes, evidence views, reviewer permissions, audit logs, case queues, retry controls, and appeals. A high automation rate is not useful if analysts cannot understand the exceptions.

Developer reliability

Test idempotency, webhook delivery, signature verification, ordering, retries, timeouts, API versioning, rate limits, status reconciliation, and sandbox fidelity. Define what happens when a user completes the flow but the event is delayed.

Privacy and security

Map every collected attribute and biometric artefact to a purpose, retention rule, access policy, region, and deletion path. Review subprocessors, encryption, incident response, access logs, and the ability to separate environments and applications.

User experience and inclusion

Measure completion and false rejection by document, device, operating system, network, language, and relevant demographic group. Provide clear recovery instructions and an alternative path for users who cannot complete the default method.

Common KYC implementation mistakes

Treating KYC as a one-time gate

A clean onboarding result can become stale. Documents expire, watchlists change, accounts are taken over, and behavior changes. Define refresh triggers when the original policy is written.

Confusing verification with risk acceptance

A person can be correctly identified and still present unacceptable or elevated risk. Keep identity, screening, customer risk, and business eligibility as separate decisions.

Auto-declining every potential screening match

Names are not unique identifiers. Preserve match context and review ambiguous results rather than converting every candidate match into a confirmed identity.

Using one workflow for every customer

Uniform flows can overburden low-risk users while under-checking higher-risk cases. Use a documented risk-based approach with bounded branches and clear escalation criteria.

Trusting the client-side redirect

A success page is not a trusted decision. Confirm the result server-side, authenticate events, retrieve the canonical record, and make the access decision in your own system.

Measuring only pass rate

Track security and user outcomes together: false accepts, false rejects, retries, abandonment, manual-review rate, time to resolution, unsupported evidence, and downstream fraud. A higher pass rate can be a warning if controls weakened.

Ignoring the exception path

Real users have damaged documents, mismatched names, limited devices, disabilities, and poor connectivity. Define retries, alternate evidence, manual review, appeals, and support ownership before launch.

Where Didit fits

Didit provides composable identity and fraud checks that can be assembled into a workflow. The published KYC bundle is $0.33 for ID Verification, Passive Liveness, Face Match, and IP Analysis; the published free tier is 500 free verifications per month.

For the identity portion, see ID Verification. For presence checks, see Liveness Detection. For customer-risk screening, see AML Screening. Teams can connect the checks through the Workflow Orchestrator and review the module-level rates on the pricing page.

Those product results still need to sit inside the organization’s own policy, legal analysis, review process, and monitoring program.

Frequently asked questions

What does KYC stand for?

KYC stands for Know Your Customer, also written as Know Your Client. It is the process of identifying a customer, verifying appropriate evidence, assessing relationship risk, and keeping the customer profile current.

Is eKYC different from KYC?

eKYC is the electronic delivery of KYC through remote or digital methods. The objective remains the same; the evidence, capture method, fraud threats, and user-recovery paths differ.

What is the difference between KYC and identity verification?

Identity verification establishes linkage between a claimed identity and the applicant. KYC uses that result alongside risk assessment, screening, policy, records, and ongoing review.

What is the difference between KYC and AML?

KYC is a customer-focused part of AML. AML is broader and can include transaction monitoring, investigations, suspicious-activity reporting, governance, and continuing controls.

Does KYC always require an identity document?

Not universally. The accepted evidence depends on law, policy, assurance, jurisdiction, and risk. Some permitted flows can use authoritative databases, digital credentials, or combined evidence. Teams should confirm the applicable requirement rather than assume one method fits every case.

How often should KYC be refreshed?

There is no universal interval. Refresh should follow applicable requirements and a documented risk model, with event-driven reviews when material identity, ownership, sanctions, document, or behavioral signals change.

Can a KYC API make a business compliant?

No API creates compliance by itself. It can collect evidence and return structured results, while the organization remains responsible for policy, risk decisions, exceptions, governance, records, and monitoring.

Primary references

• FATF Guidance on Digital Identity
• FATF customer due diligence guidance
• NIST SP 800-63A-4: Identity Proofing and Enrollment
• HMRC explanation of customer due diligence

KYC works when identity evidence, risk policy, technical controls, human judgment, and ongoing monitoring agree. Build the lifecycle first; then choose the checks and API contract that can support it.