Customer Due Diligence: CDD, EDD, and Risk-Based KYC

Customer due diligence is where KYC becomes operational. A company may have an AML policy, a screening vendor, and a compliance officer, but the program succeeds or fails in the onboarding and review workflow. If the business does not understand who the customer is, who owns or controls the customer, why the relationship exists, and what activity is expected, later monitoring has no baseline.

This guide sits under the KYC and AML Compliance pillar in the Kurums Law department. It explains standard CDD, enhanced due diligence, simplified due diligence, risk scoring, ongoing monitoring, review triggers, and the privacy controls needed when collecting identity data.

What is customer due diligence?

Customer due diligence is the collection, verification, and risk assessment process used to understand who a customer is and whether the relationship creates financial-crime risk. For individuals, this usually includes name, date of birth, nationality, address, identification document, and screening. For legal entities, it includes registration details, directors, ownership, control, business activity, expected transactions, and beneficial owners.

CDD is not complete when a document is uploaded. The compliance team must decide whether the information makes sense. A company selling low-value domestic services has a different risk profile from an offshore entity moving high-value cross-border payments through complex intermediaries. CDD converts data into a risk judgment.

CDD, SDD, and EDD compared

What information should CDD collect?

CDD should collect enough information to verify identity, understand the relationship, and assign a defensible risk rating. For individuals, collect identification data, contact details, residence, occupation, source of funds where relevant, and screening results. For entities, collect legal name, registration number, address, business activity, directors, ownership, control structure, expected activity, and beneficial owners.

Data minimization still matters. Do not collect documents merely because a vendor template asks for them. If the risk level can be assessed with less intrusive data, collect less. Identity data should be protected under privacy rules, as explained in the Kurums guide to data privacy law and cross-border compliance.

When is enhanced due diligence required?

EDD is required when the customer or relationship presents higher financial-crime risk. Triggers can include politically exposed persons, high-risk jurisdictions, complex ownership, cash-intensive sectors, unusual transaction patterns, offshore structures, negative media, sanctions proximity, crypto exposure, or inconsistent information.

EDD should not be a vague request for “more documents.” It should answer the specific risk question. If geography is the risk, review country exposure and counterparties. If ownership is the risk, map control and UBOs. If wealth is the risk, verify source of funds or source of wealth. If behavior is the risk, compare transactions against the customer profile.

How should risk scoring work?

A KYC risk score should combine objective risk factors into a transparent rating that drives controls. Common inputs include customer type, entity type, industry, geography, product, delivery channel, transaction volume, UBO profile, PEP status, sanctions exposure, adverse media, and expected activity.

Avoid black-box scoring that compliance cannot explain. Regulators and banking partners may ask why a customer was approved, why EDD was not applied, or why monitoring was reduced. The model should show thresholds, overrides, manual review rules, and review history.

Common CDD mistakes

• Collecting documents without recording risk rationale.
• Using the same checklist for low-risk and high-risk customers.
• Failing to verify beneficial owners.
• Ignoring adverse media because sanctions screening is clear.
• Not updating customer profiles after behavior changes.
• Keeping identity documents longer than necessary without a retention basis.

What should an onboarding policy define?

A CDD policy should define exactly what must be collected, verified, screened, approved, and retained for each customer type and risk tier. The policy should distinguish individuals, companies, partnerships, trusts, charities, funds, government entities, regulated financial institutions, and high-risk intermediaries. Each type needs a different evidence set.

The policy should also define failed onboarding outcomes. If the customer cannot provide documents, if ownership cannot be verified, if sanctions screening produces an unresolved match, or if source of funds is implausible, the business needs a clear reject or escalation path. Without that path, frontline teams may keep asking for documents indefinitely while commercial pressure builds.

How should CDD data be protected?

CDD files often contain passports, national IDs, addresses, tax numbers, ownership charts, bank details, and sensitive financial information. That makes CDD a privacy and security issue as well as an AML issue. Access should be role-based, documents should be encrypted, exports should be controlled, and retention should match legal and regulatory requirements.

Businesses should avoid keeping identity documents in ordinary shared drives or email threads. Use a controlled onboarding system or case-management tool with audit logs. If a third-party identity verification provider is used, review its data processing agreement, retention settings, sub-processors, breach notice terms, and cross-border transfer controls.

How should ongoing monitoring change CDD?

CDD is not static; monitoring results should feed back into the customer profile. If the customer begins using new corridors, sends larger amounts, changes counterparties, adds products, or receives adverse media, the risk score should be reviewed. A well-designed program treats onboarding as the first version of the customer profile, not the final version.

Periodic refresh should also be risk-based. High-risk customers may require annual review, while lower-risk customers may be reviewed less frequently unless a trigger occurs. Refresh should confirm identity, ownership, expected activity, screening results, and whether existing controls still match the risk.

CDD implementation playbook

A workable CDD program should be designed around customer journeys, not only legal requirements. Map every onboarding route: website signup, enterprise sales, reseller onboarding, manual account opening, API onboarding, mobile app registration, and partner referral. Each route should collect the minimum information needed for the initial risk decision while preserving the ability to request more information when risk increases.

Start with segmentation. Separate individuals, sole traders, privately held companies, listed companies, regulated financial institutions, funds, trusts, charities, government entities, and marketplaces or intermediaries. Then define the evidence required for each segment. For individuals, the workflow may require identity document verification and address confirmation. For companies, it may require registry data, signatory authority, business description, ownership chart, UBO verification, and expected activity. For regulated institutions, licensing evidence and regulatory status may reduce some risk but should not eliminate screening.

Next, define decision outcomes. The process should not produce only “approved” or “rejected.” It should support approved low risk, approved standard risk, approved with EDD, pending documents, pending compliance review, rejected, and exited after onboarding. Each outcome should have a reason code. Reason codes make reporting, audit, and model improvement possible.

Finally, connect CDD to operations. Customer support should know what to say when documents are requested. Sales should know that compliance review is not optional. Product teams should know which fields are mandatory before a customer can transact. Compliance should receive alerts when customer behavior conflicts with onboarding data. The program works only when the workflow is embedded into the business process.

CDD audit evidence

A CDD audit file should show the full lifecycle of the decision. Keep original customer submissions, verification results, screening outputs, risk score, reviewer notes, EDD approval where relevant, refresh history, and monitoring triggers. If a customer was approved despite a red flag, the file should explain why the risk was accepted and who approved it.

Audit evidence should be consistent across cases. If one analyst writes detailed notes and another writes only “ok,” the program will look uneven. Templates help. A good case note answers: what was reviewed, what was unusual, what evidence resolved the issue, what risk remains, and what follow-up is required.

CDD metrics and quality controls

CDD quality should be measured with both speed and substance metrics. Track average onboarding time, pending cases by age, rejection reasons, EDD referrals, document failure rates, unresolved ownership issues, manual override rates, and periodic review completion. These numbers show whether the process is efficient, but they do not prove that decisions are good.

Quality controls should include sample review of approved customers, rejected customers, and EDD cases. Reviewers should check whether risk ratings match evidence, whether beneficial owners were verified, whether screening decisions were documented, and whether expected activity was recorded. If recurring gaps appear, update training, forms, vendor settings, or policy language.

CDD metrics should also be reviewed with product and operations teams. If many customers abandon onboarding at one document step, the process may need clearer instructions. If many cases require manual fixes because data fields are missing, the product flow should be changed. Compliance quality often improves when friction is removed intelligently rather than bypassed.

Board reporting should highlight aged pending cases, high-risk approvals, rejected relationships, and overdue refreshes. These are the signals that show whether the business is accepting risk intentionally or simply accumulating unresolved onboarding decisions.

Final compliance note

CDD should make the customer understandable before the business accepts risk. The best test is simple: could a reviewer explain who the customer is, why the customer is using the product, what activity is expected, what risk indicators exist, and why the final risk rating is reasonable? If the file cannot answer those questions, the CDD process is incomplete even if every document field is filled.

Treat every CDD file as a future audit record. The analyst who made the decision may not be available later, so the file itself must tell the story clearly.

Frequently Asked Questions