Customer due diligence explained: KYC's regulatory core

What CDD requires, in plain terms

Across jurisdictions, customer due diligence decomposes into four duties. Identify and verify: establish who the customer is, name, date of birth, address, identifier, and verify it against reliable, independent sources, documents, data, or certified digital identity. Understand the relationship: know why the customer is here, what activity is expected, and for entities, who ultimately owns and controls them, the beneficial ownership question that decides most hard cases. Assess and rate risk: assign the customer a risk rating that drives everything downstream, from refresh cadence to transaction thresholds. And monitor on an ongoing basis: keep the picture current, screen against sanctions and PEP updates, and detect activity inconsistent with the expected profile.

The two design words regulators lean on are risk-based and ongoing. Risk-based means diligence depth scales with exposure rather than applying uniformly, which is a permission and an obligation at once: light-touch onboarding for low-risk retail is allowed, and deep diligence for high-risk relationships is required. Ongoing means CDD never finishes: the file that was accurate at onboarding and stale at examination is a finding, not a defense.

The three tiers: simplified, standard, enhanced

Standard CDD is the baseline above. Simplified due diligence applies where risk is demonstrably low, certain regulated counterparties, low-value products, and trims verification depth, never the monitoring duty. Enhanced due diligence (EDD) triggers on elevated risk, politically exposed persons, high-risk jurisdictions, complex ownership chains, unusual transaction patterns, and adds source-of-funds and source-of-wealth inquiry, senior management approval, and tighter monitoring.

The operational challenge is the borders between tiers. Customers migrate: the low-risk account that starts receiving high-risk-corridor wires belongs in a different tier than the one it opened in, and the program must notice. That migration duty is why event-driven re-screening and perpetual KYC displaced calendar refreshes in serious programs: the trigger for renewed diligence is evidence, a sanctions update, a behavior break, an ownership change, not an anniversary.

Where digital identity fits CDD now

The verification duty is being rebuilt around credentials. US banking agencies confirmed in September that state-issued mobile driver's licenses and other verifiable digital credentials satisfy the documentary pathway of the CIP rule. The UK's Money Laundering Regulation 28 points to certified Digital Verification Service providers, with the certification confusion still settling, and recognizes EU eIDAS qualified trust services. EUDI wallets arrive within the quarter carrying exactly the attested attributes CDD consumes.

The architecture lesson from the UK muddle generalizes: certificates and schemes will keep shifting, so a CDD program should verify to evidence, not to scheme membership alone. Accept certified credentials where presented and validate them cryptographically; run chip, forensic, and liveness verification where they are not; and record both paths to one evidence standard. On the deepidv stack, Arc handles the credential path with per-issuer policy while the core engine carries the forensic path, and the CDD record shows the method, the evidence, and the regulation mapping either way.

Beneficial ownership: the hard half of KYB

Entity customers multiply the diligence problem: the customer is a company, but CDD's target is the humans behind it. Beneficial ownership analysis traces control chains through layered entities to the natural persons who ultimately own or direct them, verifies those persons like any customer, and keeps the picture current as structures change. Registry data helps and misleads in equal measure, ownership records lag and launder well, so mature programs corroborate registries with documents, declarations, and the transaction behavior that reveals who actually controls the account. The US's shifting beneficial ownership reporting rules, with domestic filing obligations rolled back while bank CDD duties stand, put the burden squarely on institutional diligence rather than public registries.

The evidence standard: CDD that survives examination

Every 2026 enforcement trend converges on one test: produce the record. An examiner, or an investigator armed with the UK's new £500 million capability, asks for specific customer files and expects the identification evidence, the screening results with timestamps, the risk rating with its reasoning, the monitoring alerts and their dispositions, and the EDD file where triggered, coherent, complete, and produced from systems rather than reconstructed from inboxes.

That standard is an architecture choice. Programs assembled from point solutions produce evidence by manual archaeology; programs run on an integrated engine produce it as a by-product. Luna operates CDD as that kind of program: identification through the verification engine, screening on event cadence, risk ratings maintained against live data, monitoring dispositions logged, and the whole file exportable per customer on request. The measure of a CDD program in 2026 is not the policy binder; it is the minutes between an examiner's request and a complete answer.

Five design decisions that decide CDD quality

Program design compresses to five choices. Evidence versus attestation: verify to records the system produces, never to a vendor's certificate alone, the lesson the UK's scheme confusion teaches. Event versus calendar: refresh diligence on triggers, screening updates, behavior breaks, ownership changes, with periodic review as backstop, not driver. Depth versus friction: tier the diligence honestly, spend verification depth where risk lives, and document the reasoning so the risk-based defense is written before it is needed. Integration versus assembly: one engine producing identification, screening, monitoring, and evidence beats four tools whose seams the examiner will find. And ownership: name the person who answers the file request, because programs without an owner produce evidence without an author.

A sixth choice hides inside the fourth: where the CDD evidence lives. Records scattered across vendor dashboards are assembled by hand under deadline; records written into one evidence plane at decision time are exported on request, and the difference between the two is measured in examiner patience and, increasingly, in enforcement outcomes, because the investigator who waits weeks for a file draws conclusions from the wait itself. The five choices also decide cost. Event-driven programs screen less and catch more than calendar programs; integrated evidence eliminates the examination-preparation project; and tiered depth returns the onboarding friction budget to the customers who deserve it. CDD done well is cheaper than CDD done nervously, which is the argument that wins the budget conversation.