KYC, KYB and Customer Due Diligence: A Practical Guide for Compliance Teams

Teams often have an identity-check tool, a business-data provider, a sanctions screen and a customer score, but cannot clearly show how those inputs became an onboarding decision. That is the practical problem this guide addresses. A useful KYC/KYB process is not a collection of acronyms or documents: it is a traceable customer lifecycle.

FATF Recommendation 10 provides a useful international baseline: identify and verify the customer, identify and take reasonable measures to verify beneficial owners, understand the purpose and intended nature of the relationship, and conduct ongoing due diligence.¹ FATF sets standards for countries; enforceable duties arise through the applicable national or regional regime. The question is therefore not “what is the global KYC checklist?” but what must this firm understand, verify, decide and retain for this relationship?

How KYC, KYB and CDD fit together

KYC is practical shorthand for understanding and verifying an individual customer. KYB is practical shorthand for applying relevant due-diligence controls to a business or other legal entity. CDD is the broader, risk-based process through which the firm understands the customer and the relationship. Terminology overlaps: the underlying legal duties in FATF, UK and EU frameworks are usually expressed as customer due diligence rather than as a universal statutory category called “KYB”.¹²³

For focused definitions, see KYC: essential compliance for businesses and KYC vs CDD vs EDD. This guide addresses the next operational question: how the concepts should work together in one evidence-backed customer lifecycle.

Customer onboarding is the operational process that collects information, applies CDD, assigns risk and decides whether to establish, restrict, escalate or decline a relationship. Customer-risk assessment calibrates the level of scrutiny. Sanctions screening has a separate legal purpose, even when it uses the same identity and ownership data. Transaction monitoring evaluates activity during the relationship; ongoing CDD is broader because it also keeps the firm’s understanding of the customer current.

For the wider AML programme context, see the AML compliance guide.

The regulatory baseline: label the source before using it

Use clear labels in policy and content:

The UK Money Laundering Regulations contain current binding CDD requirements for entities within their scope.² Regulation (EU) 2024/1624 will introduce directly applicable EU requirements principally from 10 July 2027; it must not be described as a current EU-wide duty before then.³ The US FinCEN CDD framework applies to specified covered financial institutions, not to every US business.⁴

How to build a practical KYC and KYB workflow

1. Define scope and legal perimeter

Before requesting documents, identify the legal entity providing the service, the customer type, product, jurisdictions, regulated activity and rules that govern the relationship. A global policy can set common controls, but it should not conceal which local rule requires a step or which step is a risk-management choice.

2. Collect customer and business information

For an individual, collect the information necessary to identify the person under the applicable regime. For a business, establish the legal name, legal form, registration details, jurisdiction, registered or principal place of business, relevant directors or managers, people claiming authority to act, and ownership/control information. The information needed should be proportionate to the relationship, not an unchanging global form.

3. Verify identity and assess source reliability

Collecting a customer statement is not the same as verifying it. FATF calls for reliable, independent source documents, data or information.¹ A robust record captures:

An electronic source can be appropriate where the applicable regime permits and the firm understands its reliability. “Verified” should never become an unexplained status with no source, date or exception record.

Separate collection, validation and verification

These stages are often collapsed into one status in an onboarding system. That makes it difficult to explain what the firm actually knows. Collection records what a customer or representative supplied. Validation checks whether a field is present, internally consistent and in an expected format. Verification tests a relevant fact against a source whose reliability is understood for that fact.

For example, a company name can match a registry record while the person submitting the application still lacks authority to bind the entity. An identity document can appear valid while a customer profile contains an unresolved mismatch. A provider can return a result while its coverage, retrieval date or source lineage is unclear. The workflow should retain those distinctions instead of converting every returned result into a green status.

Set a practical rule for material mismatches: which may be corrected by the applicant, which require independent corroboration, which need an analyst decision and which stop the relationship from proceeding. This reduces both repetitive customer requests and unsupported approvals.

4. Establish beneficial ownership, control and authority

For business customers, trace ownership and control until the relevant natural person or persons are understood under the applicable test. Beneficial ownership includes ultimate ownership or control; it is not limited to direct shareholding or a single global percentage.¹ The UK rules provide a concrete safeguard: beneficial-owner verification cannot be satisfied solely by relying on information from the registrar.²

Use UBO and related parties to support ownership-chain mapping. For complex groups, trusts, nominees or conflicting evidence, prioritise traceability: understand the structure’s rationale, who ultimately controls it, which evidence is reliable and what remains unknown. Complexity is not proof of wrongdoing. An unresolved required fact should be documented and escalated, not silently turned into a verified conclusion.

Also check the identity and authority of a person acting for the customer where applicable. Being a director, employee or intermediary is not automatically proof of authority in every context.

5. Understand purpose and expected activity

The firm needs a usable view of why the relationship exists and how it is likely to be used. Depending on the product and risk, that can include purpose, business activity, required services, expected volumes or ranges, expected geographies, transaction types, counterparties, funding routes and source of funds where relevant. These are control-design examples, not a universal mandatory-document checklist.

Expected activity provides the baseline for risk assessment and later monitoring. It is not a promise that every transaction must match a forecast, nor proof that a deviation is suspicious. It is context that helps the firm ask a better question when activity changes.

Turn expected activity into an operational baseline

Expected activity is useful only when it can inform a later decision. A generic answer such as “international payments” rarely gives an operations team enough context. A proportionate baseline can describe the business model, expected corridors, payment or funding methods, approximate pattern, relevant counterparties and reason for using the service. The objective is not to collect every possible data point; it is to identify the facts that would make a later event more or less explainable.

For an individual, the relevant context may be occupation, source of funds, intended product use and expected relationship activity. For a marketplace, it could include merchant categories, settlement model, supported countries and expected payment size. For a corporate treasury customer, it may include group entities, currencies, payroll or supplier-payment patterns and authority to instruct payments. Capture the context that materially changes the control response.

When the business changes, update the baseline rather than treating the onboarding answer as permanent. This is where customer due diligence and ongoing monitoring meet: the same customer understanding should help explain alerts, new products, new geographies and significant changes in activity.

6. Assess customer risk

Customer risk assessment uses relevant inputs to decide the appropriate intensity of CDD, EDD, monitoring and review. Inputs may include customer/entity type, ownership complexity, geography, products, delivery channel, expected activity, and relevant PEP or sanctions signals. A numerical score can support consistency, but it is not a legal determination that a customer is acceptable or unacceptable.

The methodology should show factor weighting, material overrides, decision authority and evidence. FCA supervisory findings identify weighted factors, clear methods and documented changes as useful practice; unsupported overrides are a quality risk.⁵ A practical record might retain the model/version, inputs, result, any human override, supporting evidence and approval.

Make risk decisions explainable

A risk score is an input to a decision, not a conclusion by itself. Design the methodology so an independent reviewer can answer four questions: which factors were considered, which had the greatest effect, what evidence supported the inputs, and who approved any departure from the normal outcome.

“High risk because the model score is 82” does not explain whether the driver was complex ownership, geography, product exposure, PEP relationship, data uncertainty or a combination. The reason should direct the next control: more ownership evidence, enhanced review, a product restriction, senior approval, closer monitoring or a decision not to proceed.

Use controlled overrides sparingly. A legitimate override can arise when verified evidence gives material context that the automated input could not represent. Record the person, reason, evidence, approval level and expiry or review point. An override without an owner or review date can silently turn an exception into a permanent rule.

7. Apply standard or enhanced measures

EDD should respond to the legal trigger and the identified risk, not to a generic slogan such as “high risk means five more documents”. Measures can include additional customer or beneficial-owner information, source of funds or wealth where relevant, transaction rationale, senior approval and enhanced monitoring. The UK has its own binding EDD requirements.⁶ From 10 July 2027, EU AMLR Article 34 provides a proportionate menu of enhanced measures; it is not a present-day global checklist.³

PEP and sanctions controls can require separate assessments even where one reviewer sees the same customer record. Keep the legal and policy basis, evidence and resulting decision distinct.

Design EDD as a response to a defined question

EDD is more effective when each additional request has a purpose. If an ownership structure is unclear, seek evidence that resolves ownership or control. If expected activity is unusually complex, understand the commercial rationale and relevant funding or payment flows. If a customer presents a higher-risk relationship because of geography, PEP exposure or another applicable trigger, use the measures required by the governing regime and document why they address the identified exposure.

Avoid an indiscriminate “enhanced pack” that collects documents without changing the decision. It creates friction, delays and an evidence store that is difficult to review. A better case file identifies the trigger, facts still unknown, evidence requested, reviewer, outcome and residual risk accepted or declined. This helps distinguish a normal business explanation from a case that requires escalation.

8. Make and document the relationship decision

Useful operational outcomes include approve, approve with controls, escalate or request further evidence, and decline or do not establish the relationship. These are workflow states, not universal statutory categories. Where required CDD cannot be completed, applicable law may restrict whether the relationship can be established or continued.¹

The record should explain what was known, which sources were used, what conflicted, which risk methodology applied, why additional measures were or were not used, who approved an exception and what happened next.

KYB in practice: businesses, ownership and authority

KYB goes beyond looking up a company number. The process normally moves from legal entity to registration, legal form and jurisdiction, directors and representatives, ownership chain, control by other means, ultimate natural persons, and business purpose/expected activity. A registry is important evidence, but content, reliability and freshness differ across jurisdictions.

When evidence is incomplete, keep the distinction between unknown, unverified and contradictory. The next action may be further evidence, specialist escalation, a product restriction or a decision not to proceed under the applicable policy and law. Do not label a structure suspicious simply because it has multiple layers.

A practical KYB evidence pack

Organise a business file around the questions the firm has to answer rather than around a fixed document list:

The list is not a substitute for legal requirements. It makes a KYB file reviewable. The strongest files do not merely contain documents; they show which proposition each item supports, when it was assessed and what the reviewer concluded. For more on thresholds and ownership concepts, see Global UBO thresholds and key regulations.

From onboarding decision to a controlled handoff

An approved onboarding file is not the end of the control. The information collected during KYC and KYB has to reach the teams and systems that use it next. That includes permitted products and jurisdictions, expected activity, relevant owners and representatives, risk outcome, review date, restrictions, outstanding evidence and the rationale for any exception.

Without a controlled handoff, the firm can complete a careful initial review and still lose the benefit of it. A payments-operations team may not see a product restriction. A monitoring rule may not receive the expected-activity context needed to make an alert meaningful. A relationship manager may request a change without knowing that it triggers a renewed authority or ownership review. The customer file should therefore be a maintained record, not an archive of onboarding documents.

Define what each downstream process needs, who may update a customer fact, how a material change is detected, and which changes require compliance review. Preserve the previous value and decision rationale where it matters; a current profile alone may not explain why a product was enabled, an exception was granted or a restriction was lifted. Clear ownership and change history make the customer lifecycle auditable without forcing every operational action through the same reviewer.

Ongoing customer due diligence: event-driven, not annual by default

Ongoing monitoring should connect customer understanding with later activity. Important review triggers include a change in ownership or control, a new director or representative, material changes in business or expected activity, new products or geographies, new PEP or other risk information, doubts about earlier data, data conflicts, unusually inconsistent activity and improved information revealing a missing fact.

FATF expects CDD information to stay current and relevant, especially for higher-risk customers.¹ This does not create a universal annual-refresh rule. For covered US financial institutions, FinCEN’s CDD Rule requires customer information to be maintained and updated on a risk basis.⁴ From 10 July 2027, EU AMLR Article 26 will combine event-driven updates with maximum intervals of one year for customers subject to higher-risk measures and five years for other customers.³ Scheduled review can be a useful backstop; event detection prevents material changes from waiting for the next calendar date.

Combine scheduled review with material-change detection

Scheduled reviews prevent dormant files from remaining untouched indefinitely. Event-driven review makes the programme responsive when the customer, relationship or risk changes. These are complementary controls, not alternatives.

Build the trigger into the operating workflow: identify the event, assign an owner, set a response deadline based on risk, preserve the prior state and record the final outcome. A notification with no accountable queue is not ongoing due diligence. The control should be able to show how many events were detected, how long they remained open, which were overdue and whether recurring data issues require remediation.

Governance, evidence and automation

Treat the operating model as a practical responsibility map, not a universal organisation chart. Senior management should receive meaningful information about risk and control health. Compliance leadership should own the framework and material exceptions. KYC/KYB operations collect and verify evidence. Product, engineering and data teams own workflow logic, source integrations, permissions and data lineage. QA and independent testing should test whether the control actually works.

The evidence record should connect customer-supplied data, verification sources and timestamps, entity and registry evidence, ownership/control mapping, representative authority, purpose and expected activity, risk inputs and methodology version, EDD evidence, screening references, conflicts, analyst notes, overrides, approvals, final decision and later review events.

Quality assurance: test the decision, not only the document

Quality assurance should sample completed cases across customer types, risk outcomes, reviewers and exception routes. Test whether the stated decision follows from the evidence, whether evidence was current and reliable, whether required escalation was used, and whether the system record lets another reviewer reproduce the reasoning. Test false confidence as well as obvious failures: a complete-looking file can still have an unsupported ownership conclusion, an outdated source or a risk override without approval.

Useful programme measures include completeness of required evidence, rework rates, mismatch rates, time in queue, exception ageing, override frequency, overdue reviews, source failure rates and the quality of final rationales. Metrics should prompt action. If one source creates recurring gaps, one team produces more overrides, or a new product creates more unresolved authority questions, revise the workflow and verify the change worked.

Automation can gather evidence, match data, extract information, route cases and support decisions. It does not transfer accountability. For controlled AI-agent workflows that connect to authorised AML capabilities, see Agentic AML via MCP. A firm still needs to govern how outputs become compliance decisions, including limits, exceptions, human review, evidence and change control.

KYC, KYB and CDD implementation checklist

Related KYC and due diligence resources

Use this guide when you need to design or assess the end-to-end customer-due-diligence lifecycle. Use the supporting resources when you need a deeper answer on one component:

• What is KYC? for a focused KYC introduction.
• KYC vs CDD vs EDD for the terminology and level-of-scrutiny distinction.
• UBO and related parties for ownership and control mapping.
• Customer risk assessment for the methodology that calibrates due diligence.
• Ongoing monitoring for continuing review, alerts and case work after onboarding.

Frequently asked questions

What is the difference between KYC, KYB and CDD?

KYC and KYB are practical labels for individual and business workflows. CDD is the wider risk-based process reflected in many AML standards and laws. It connects identity, ownership/control, purpose, risk and ongoing review.

Is KYB the same as KYC?

They have related goals but require different evidence. KYB normally adds legal-entity identity, representatives, ownership/control and business context.

How often should KYC be refreshed?

There is no universal annual rule. Update information when material facts change and follow any risk-based or jurisdiction-specific review cycle that applies. The future EU AMLR has specific maximum intervals from 10 July 2027.³

Can KYC and KYB be automated?

Many collection, verification, screening and routing tasks can be automated. The firm remains responsible for governing the overall process and its final compliance decisions.

Closing perspective

KYC, KYB and CDD work when they form one traceable lifecycle: understand the applicable scope, identify and verify the customer, establish ownership and authority, understand purpose and expected activity, assess risk, apply appropriate measures, preserve the decision record and update it when facts change. That is how isolated checks become an auditable control.

References