Customer due diligence design: stages and deadlines
Customer due diligence design moves through four fixed stages: scoping the risk profile, collecting identity and source-of-funds evidence, verifying documents against independent sources, and recording the decision for audit. Each stage carries an internal deadline set by the obliged entity, not a statutory one. Compliance teams that skip verification miss the point of no return and must restart the file from the collection stage.
Why the design stage exists at all
A customer file is not built by filling a form once. It is built in layers, each one closing off a category of risk before the next opens. Design is the work of deciding what those layers are, in what order they run, and who signs off at each point. Skip the design and the file becomes a pile of documents with no defensible sequence behind it.
The practical difference shows up during a supervisory review. A file with a documented design answers "why did you accept this" in one sentence. A file without one forces a reconstruction, months later, from memory and email threads.
Stages and typical timing
The table below reflects working practice across obliged entities handling digital assets. Timing depends on customer complexity, so treat the ranges as planning figures, not commitments.
| Stage | What happens | Typical duration |
|---|---|---|
| Scoping | Risk category assigned, checklist selected | Same day to two working days |
| Collection | Identity, ownership and source-of-funds documents gathered | Three to ten working days, customer-dependent |
| Verification | Documents checked against independent sources | Two to five working days |
| Decision and record | Approval, escalation or refusal, with reasons filed | One working day after verification closes |
The verification stage is the point of no return. Once a document has been checked and accepted, walking it back requires a formal re-review, not a quiet correction. Design the checklist so that nothing enters verification before collection is genuinely complete.
What to prepare before you start
- A written risk-scoring method that assigns each customer to a tier before any document is requested.
- A fixed document list per tier, so collection does not drift customer by customer.
- An independent verification channel — a registry, a database, or a second reviewer — separate from the person who collected the file.
- A decision log template that records the reasoning, not only the outcome.
Entities that build the checklist after the first customer arrives tend to redesign it twice within a year. Building it before the first file is opened avoids that cost.
Who decides and where the file goes
Inside the entity, the decision sits with the compliance function, not with the commercial team that brought the customer in. Escalations above a set risk threshold go to a designated compliance officer or committee, and that escalation point should be named in the design itself, not improvised when a difficult file appears.
Design also has to account for supervisory change during the life of a project. When the responsible authority shifts mid-way through onboarding, the file's ownership and reporting line can change with it — the mechanics of that shift are set out in The regulator changes during the project authorisation who decides.
Common forks
If the customer is a natural person with a simple income source, the standard tier applies and the file typically closes within the ranges shown above. If the customer is a corporate structure with layered ownership, scoping alone can take longer than the entire standard file, because each layer needs its own verification pass.
If the customer's assets rest on a licence issued to someone other than the counterparty in front of you, the ownership chain has to be checked before source-of-funds evidence is accepted at face value — the cost of getting that wrong is set out in When a licence is granted by a non-owner.
If part of the verification work is delegated to an external provider, the design has to specify what happens when that provider subcontracts the check further abroad, because the entity's responsibility for the outcome does not travel with the subcontract — see When the outsourcing provider subcontracts abroad.
What this page does not cover
This page describes the design of the ordinary due diligence file. It does not cover the enhanced procedure that applies once a risk indicator is triggered, and it does not set out how long a regulator has to respond to a filing — timing for supervisory decisions depends on the authority and the case type, and belongs to a different page. It also does not fix numerical thresholds; those are set internally, tier by tier, based on the entity's own risk appetite.
Reviewed
Reviewed against current supervisory practice for entities handling digital assets. This page describes procedure and internal timing, not statutory deadlines, and carries no citation to a specific act or article; a national-law reference for a specific jurisdiction sits outside this page's scope.
Related reading
Once a file is flagged for closer scrutiny, the design above stops being sufficient. The escalated process, with its own stages and deadlines, is covered in Enhanced due diligence procedure step by step.
Frequently asked questions
How long does customer due diligence design take in practice?
Building the design itself — the checklist, tiers and decision log — usually takes one to two weeks for a small obliged entity working from scratch. Running a single customer file through an already-built design takes the days shown in the table above, not weeks.
Which documents are needed to start?
At minimum: proof of identity, proof of the customer's address, and evidence of the source of funds appropriate to the assigned risk tier. Corporate customers add ownership and control documents. The exact list belongs in the fixed checklist, not decided case by case.
What happens if the other side does not respond?
The file stays open and is not accepted. A design should set a fixed waiting period before a non-response converts into a refusal or a downgrade to a lower service tier, so the file does not sit indefinitely in an undecided state.
Next step
A due diligence file rarely stands alone. If the customer relationship also involves an intangible asset bought from a third party, the same verification discipline applies before any purchase closes — the risk of getting that wrong is described in When a patent is offered to you for sale. Where the file in front of you does not fit either pattern cleanly, describe the customer structure and the stage you have reached, and we will map it against the design above.