How would you design customer onboarding for a bank, from identity verification through to keeping due diligence current?

Onboarding is an evidence-gathering problem

The instinct is to model onboarding as a form with validation. That model fails the first time someone asks you to justify a decision you made two years ago, because a form produces fields and what you need is evidence.

The unit to design around is an assertion, the artefact supporting it, and the moment it was accepted. The customer asserts a name, a date of birth, an address, a nationality. Against each you hold something: a document image and its authenticity result, a database match with its provider and confidence, a reference returned by a government register — each stamped with when it was captured and the rule under which it was deemed sufficient. Nothing overwrites anything, so a change of address adds evidence rather than editing a column.

That is not archival fussiness. When a document type turns out to be forgeable you must enumerate every customer whose acceptance rested on it, which requires the dependency to be recorded rather than inferred.

Three checks that get collapsed into one

"Identity verification" hides three distinct questions, and candidates who name them separately sound like they have done this.

Does this identity exist? You match the claimed identity against independent sources — a credit file, an electoral or population register, a government identity service — and what you want is corroboration from sources that would not all be wrong together.

Does this person own that identity? Possession of a document and knowledge of facts about an identity are both weak, because both are stealable. This is where a document check that reads the machine-readable zone and validates the chip or security features earns its cost, and where matching a selfie against the document photograph does the rest.

Is a live human doing this right now? Liveness and presentation-attack detection exist because a photograph of a photograph, a replayed video or a synthesised face will otherwise pass a face-match, and injection attacks against the camera stream make integrity of the capture channel as important as the matching model.

Screening sits outside all three: sanctions lists, politically exposed person status, adverse media. It runs against the verified identity and it runs again forever, whereas verification is a point-in-time act.

Depth follows risk, not product

Due diligence is tiered because applying the deepest checks to everyone is both unaffordable and counterproductive — it buries the analysts who should be looking at the genuinely risky files. The rating is assembled from factors whose weights the bank sets and documents: geography of the customer and of their expected counterparties, occupation or industry, the products they want, the delivery channel, expected volumes and the source of funds, plus screening outcomes and whether the entity structure obscures who controls it.

Tier	Typically applies to	What is additionally required
Simplified	Low-risk, well-evidenced, low-value relationships where the regime permits it	Fewer independent identity sources; lighter source-of-funds enquiry
Standard	The large majority of retail customers	Full identity verification, screening, expected-activity profile
Enhanced	High-risk geographies, PEPs, opaque ownership, high-risk sectors	Source of wealth as well as source of funds, senior sign-off, closer ongoing scrutiny

Two design consequences follow. The tier must be a stored, versioned attribute with the factor values that produced it, because "why is this customer standard rather than enhanced" is an examinable question. And the tier has to be readable by downstream systems, because it should be selecting monitoring sensitivity, transaction limits and review cadence rather than only describing how much work was done at the start.

Why periodic review lost

The traditional control was a calendar: refresh low-risk customers on a long cycle, high-risk on a short one. It failed for a reason that is obvious once stated. Risk does not change on your review date. A customer correctly assessed as low risk who then began receiving large transfers from an unrelated jurisdiction is misclassified from the day the behaviour changed until the day the calendar reaches them, and meanwhile most completed reviews re-confirm customers whose circumstances have not moved.

Perpetual KYC inverts it. The profile is continuously evaluated against events: address and name changes, a new product, a new controlling party, a screening list update that now matches, a monitoring alert, transaction behaviour diverging from the expected-activity profile. An event that materially changes a risk factor re-derives the rating, and only a change in the rating or a specific stale-evidence condition creates work for a human. The calendar does not vanish — an identity document past its validity date genuinely expires — but it stops being the primary trigger.

That requires a risk model recomputable on demand from a stream of profile-affecting events, with every recomputation stored alongside its inputs so a rating can be explained as at any past instant. The failure mode of a badly tuned perpetual programme is a backlog growing faster than analysts clear it, which is worse than the regime it replaced, because now you have documented awareness of risk you are not acting on.

The distinction that separates a strong answer

Weak answers describe onboarding as a gate: checks pass, customer is created, done. Strong answers treat the output of onboarding as a living risk assertion that other systems consume. The expected-activity profile you capture during due diligence is what transaction monitoring compares reality against, so a lazy profile guarantees noisy alerts later. The risk tier is what sets monitoring thresholds and review depth. The evidence set is what a restatement or a forged-document exercise depends on. Onboarding that produces a verified: true flag and nothing else has satisfied the front door and left every control behind it running blind.

Design onboarding so its outputs are the inputs to everything after it: dated evidence you can re-examine, a risk rating you can explain at any past moment, and an expected-activity profile precise enough that a deviation from it means something.