Most digital onboarding projects in financial services deliver a faster version of the wrong thing. The form moves online, the client uploads a passport photograph instead of handing one over, and the file still lands in a shared mailbox where an analyst re-keys it into three systems. Elapsed time improves modestly. Cost per file does not move. And the compliance team, correctly, does not trust the output any more than before.
Digital onboarding, done properly, is not the digitisation of a document collection exercise. It is the automation of a decision: can this relationship be opened, at what risk rating, with what evidence, and can that reasoning be reconstructed in three years. Everything else — the interface, the upload widget, the e-signature — is plumbing around that decision.
This article sets out what digital onboarding genuinely requires for a bank, an External Asset Manager or a fintech operating from Switzerland, what the Swiss regulatory framework permits, and the three failure modes that account for most stalled programmes.
1. The four layers of a real digital onboarding stack
It helps to separate four layers that are routinely conflated, because vendors sell them as one and they fail independently.
Layer 1 — Identification. Establishing that the natural person is who they claim to be, to the evidentiary standard the regulator requires. This is the layer with the most explicit rules and, paradoxically, the one institutions worry about most and get wrong least.
Layer 2 — Data and document collection. Gathering what the file requires: identity documents, proof of address, corporate documents, beneficial ownership declarations, source of wealth and source of funds evidence. This is where most of the elapsed time actually goes, and it is driven less by technology than by how many times you ask the client for things.
Layer 3 — Checks and risk decisioning. Sanctions and PEP screening, adverse media, customer risk scoring, and the policy logic that turns all of it into an outcome: accept, accept with enhanced due diligence, escalate, decline.
Layer 4 — Record, audit and handover. Producing a client record that survives: a structured, queryable file with a complete reasoning trail, which then becomes the input to ongoing monitoring and periodic review rather than a dead archive.
The common pattern in failed projects is a strong Layer 1, an untouched Layer 2, a Layer 3 bolted on as a set of disconnected point solutions, and no Layer 4 at all. The result is an onboarding that feels modern to the client for ten minutes and remains entirely manual behind the glass.
2. What Swiss regulation actually permits
Remote onboarding in Switzerland is governed principally by FINMA Circular 2016/7, "Video and online identification", which sets out how a financial intermediary may identify a contracting party without a physical meeting. It has been revised repeatedly as technology has moved — most recently through a partial revision put to consultation in December 2025, which addresses identity documents bearing QR codes alongside those with a machine-readable zone, and the treatment of the Swiss e-ID as a means of online identification, following the Federal Act on Electronic Identity Credentials.
Three practical observations for institutions building now.
The circular is a moving target, and that is a design constraint. An onboarding flow hard-coded to one identification method will require re-engineering each time the framework moves. The architectural answer is to treat identification as a pluggable step with a recorded method and evidence standard, not as a fixed screen in a fixed sequence. Institutions that built video identification directly into their application logic in 2017 have since paid for that choice more than once.
e-ID changes the economics, not the obligation. A state-issued electronic identity raises the assurance level and lowers the friction of the identification step. It does not reduce what you must do about beneficial ownership, source of wealth, or risk classification. Teams that expect e-ID to shorten onboarding substantially are usually measuring the wrong bottleneck — see the next section.
Verify the version in force before you build. Circular 2016/7 has a consultation history and revisions that take effect on specific dates. Any implementation decision should be taken against the text currently in force, confirmed with compliance, and not against a summary — including this one.
For cross-border relationships, identification is only the start: the jurisdiction of the client drives a second layer of constraints entirely, which we cover in cross-border onboarding from Switzerland.
3. Where the time actually goes
Institutions that measure their onboarding honestly usually find the same distribution. Identification takes minutes. Screening takes seconds. Waiting for the client takes weeks.
The dominant cost in onboarding is not processing — it is the number of round trips. Each time the institution comes back to the client for one more document, one more signature, one more clarification, the clock stops for days. Four round trips at four days each is more than two weeks of elapsed time in which nothing is being processed at all.
This reframes what a digital onboarding project should optimise. The highest-leverage intervention is not a faster check; it is asking for the right things once. That requires three capabilities that have nothing to do with the user interface:
- Conditional data requirements. What a file needs depends on the entity type, the jurisdiction, the risk rating and the product. A static document checklist either asks everyone for everything — which is slow and annoying — or asks for a minimum and then discovers gaps, which produces round trips. The requirement set must be computed from what is already known.
- Progressive risk assessment. Risk should be scored as data arrives, not at the end. A structure that will clearly require enhanced due diligence should be routed to collect that evidence in the first request, not the third.
- Reuse of what you already hold. For an existing client adding a relationship, or a known UBO appearing in a second structure, re-collecting identical documents is pure round-trip cost. This is only possible where the client record is a single structured record rather than a folder per account — which is the central argument of client lifecycle management.
Institutions that attack round trips rather than processing speed are the ones that report moving from weeks to hours, as we set out in automated KYC onboarding: from 3 weeks to 3 hours.
4. The three failure modes
Failure mode 1: the digital front end on a manual back office. The client experience is rebuilt; the operational process is untouched. Documents arrive faster into the same queue. The tell is simple: if your average handling time per analyst has not changed, you have digitised the client's work, not your own. This is the most common outcome, because the front end is visible to management and the back office is not.
Failure mode 2: orchestration by integration. The institution buys a best-in-class identification provider, a best-in-class screening provider and a best-in-class document vault, then connects them. Each works. But the risk decision lives in no single system, the reasoning trail is split across three audit logs with three timestamps and three identifiers, and nobody can answer "why was this client accepted at medium risk" without a manual reconstruction. The failure surfaces at the first audit, not at go-live — which is what makes it expensive.
Failure mode 3: onboarding as a terminus. The file is completed, approved, and filed. Six months later, the client's beneficial ownership changes, and nothing happens, because onboarding was built as a project with an end state rather than the first phase of a lifecycle. This is the failure that the entire perpetual KYC argument exists to address: a file that is correct on the day it is opened and never revisited is a file that is wrong for most of its life. See perpetual KYC and the end of periodic reviews.
5. What good looks like
A digital onboarding worth building has five properties.
- The requirement set is computed, not fixed. Entity type, jurisdiction, product and interim risk determine what is asked, and the question set adapts as answers arrive.
- Identification is a pluggable step. Method, assurance level and evidence are recorded as data, so a regulatory change is a configuration change rather than a release.
- Risk is scored continuously and visibly. The analyst sees the rating form as the file assembles, and so does the client-facing team — which prevents the late surprise that triggers a fourth round trip.
- The decision is recorded with its reasoning. Not just the outcome, but the inputs, the policy version applied, the screening results reviewed and the person who decided. This is what makes the file defensible, and it is a by-product of the workflow rather than a document produced afterwards.
- The output is a living record. The onboarding file is the opening state of a monitored relationship, with triggers already attached to it — not a PDF bundle in a vault.
6. The measurement that matters
Most onboarding programmes report elapsed time, because it is easy and it improves. Three other metrics tell you far more:
- Round trips per file, by segment. This is the real driver of elapsed time and the one you can act on.
- Rework rate: the proportion of files reopened after approval because something was missing or wrong. A falling elapsed time with a rising rework rate is a programme that moved work downstream, not a programme that improved.
- Time to reconstruct a decision. Pick a file at random from eighteen months ago and ask how long it takes to produce the complete reasoning behind its risk rating. If the answer is measured in hours, Layer 4 does not exist, whatever the front end looks like.
That last measure is the honest test, and it costs nothing to run. We discuss how these figures translate into a business case in the ROI of KYC/AML automation.
7. Where Wecan fits
Wecan's CLM platform treats onboarding as the first phase of the client lifecycle rather than a separate system. The requirement set is derived from the entity and its risk; identification methods are configurable rather than embedded; screening, risk scoring and policy logic resolve into a single recorded decision; and the resulting client record is the same record that monitoring, periodic review and remediation will operate on for the life of the relationship.
The practical consequence is the one that matters at audit: there is one client record, one risk model and one reasoning trail from the first document collected to the day the relationship closes. Digital onboarding that produces anything less has made the client's first ten minutes pleasant and left everything else where it was.
