Digital onboarding Switzerland: KYC and AML checklist

Short answer: Digital onboarding in Switzerland must combine a simple customer journey with documented identity, risk and relationship controls. Video or online identification can reduce friction, but it does not remove due-diligence duties. A bank, broker, fintech or insurer should be able to show what it verified, when it verified it, who reviewed exceptions and how the relationship is monitored after the account opens.

Digital onboarding is often presented as a design problem: fewer fields, faster verification and a clean mobile flow. For a financial institution, it is also a control system. The platform must establish who the customer is, who ultimately controls a company account, why the relationship is being opened, what products are appropriate and what happens when the evidence is incomplete or contradictory.

This checklist is written for Swiss-facing banks, brokers, digital wealth platforms, payment providers and insurers. It is an operational guide, not a legal opinion. The exact requirements depend on the institution, activity, customer, products and applicable rules.

The onboarding journey has five separate jobs

Do not treat onboarding as one form. Break it into five jobs so the product, compliance and engineering teams can assign ownership.

The order can vary. What matters is that the business does not confuse “the person passed the selfie test” with “the institution understands the relationship.”

Build the legal-entity and responsibility map first

Before choosing a vendor, identify the entity responsible for the customer relationship. A group may use one brand, one mobile application and several legal entities. The onboarding workflow must route each customer to the correct entity and apply the correct eligibility rules.

Document:

• the entity that signs the customer agreement;
• the entity that receives or controls assets;
• the entity that performs the KYC review;
• the entity that owns the customer record;
• the entity responsible for complaints;
• the technology providers that process identity data;
• the jurisdictions from which staff can access the data.

This map is particularly important for brokers and digital banks. A customer may believe it is opening an account with a Swiss brand while the contract is with a foreign group entity. The public explanation, onboarding screen and agreement should be consistent.

FINMA’s FinTech material makes clear that companies entering financial services must assess authorisation and anti-money-laundering requirements in relation to the services they provide. Read FINMA’s FinTech guidance.

Identity verification: design for evidence, not just completion

A strong identity flow answers four questions:

1. Is the document genuine enough for the institution’s risk policy?
2. Does the person presented match the document?
3. Is the person physically present or is the method vulnerable to replay?
4. Can the institution reproduce the decision later?

The product team should resist the temptation to hide every control. A customer does not need to see internal risk rules, but it should understand why a document, video step or additional question is required. Clear explanations reduce abandonment and prevent customers from assuming that an automated pass is a guarantee of account acceptance.

FINMA has published material on video and online identification in the context of digital financial services and anti-money-laundering due diligence. See the FINMA online-identification material.

If the exact technical source changes, the compliance team should verify the current FINMA publication before updating the production flow. A blog article should link to the deep official source and display the review date rather than pretending that one technical rule is permanent.

Customer risk and purpose of the relationship

Identity is only one part of KYC. The institution needs enough information to understand the relationship and to decide whether the selected products are appropriate for the customer category.

For an investment platform, relevant questions can include:

• customer residence and tax residence where required;
• employment or business sector when relevant to risk;
• expected account activity;
• source and intended use of funds;
• investment experience and product knowledge;
• expected instruments and trading behaviour;
• whether the customer acts for itself or another person.

The form should be proportionate. Asking every customer the same long questionnaire creates poor data and encourages copy-paste answers. A better journey starts with the minimum reliable information and adds targeted questions when the model, product or risk signal requires them.

For an insurer or insurance intermediary, the purpose may be different. The flow must explain the insurance need, the role of the intermediary, the insurer providing the contract and the information the customer receives before concluding the policy.

FINMA’s guidance on insurance distribution highlights that obligations apply to insurers in relation to distribution and that control expectations depend on the intermediary relationship. Read FINMA’s insurance distribution guidance.

Beneficial ownership and company accounts

Business onboarding should never be treated as a longer version of retail onboarding. It is a different workflow with different evidence.

The institution should be able to identify:

• the registered company;
• the directors and authorised signatories;
• the ownership chain;
• the ultimate beneficial owner or owners;
• the purpose of the account;
• the expected transaction profile;
• the countries and counterparties involved.

The interface should support ownership structures without forcing the customer to describe a complex group in a single text box. Provide a clear upload path, show which evidence is missing and create an exception route for a human reviewer.

The review team should record why it accepted the ownership evidence. A file that contains documents but no decision trail is not a complete control. The audit record should show the version of the evidence, the reviewer, the decision, the date and any conditions attached to the relationship.

Sanctions, adverse information and escalation

Sanctions and adverse-information screening should be designed as a decision workflow, not as a black-box vendor result. A potential match may be a false positive, a name collision or a genuine risk. The institution needs a documented process for triage, additional information, escalation and closure.

The customer experience matters here too. An indefinite “verification pending” message creates frustration and encourages repeated submissions that may make the record harder to interpret. Where legally and operationally possible, explain that additional review is required without revealing sensitive detection logic.

Escalation owners should be named for:

• identity mismatch;
• altered or expired documents;
• unclear ownership;
• high-risk geography;
• unusual purpose of the relationship;
• inconsistent source-of-funds information;
• suspected impersonation;
• suspected fraud or account takeover.

No automation should silently approve an exception just because the customer abandons the flow and returns later. The new attempt should be linked to the existing record and reviewed under the same policy.

Data protection and vendor governance

Digital onboarding exposes sensitive identity data to several systems. The institution should document the data path from capture to storage, review, archive and deletion.

Ask each technology provider:

• where the data is processed and stored;
• which subcontractors are involved;
• how access is controlled;
• how evidence is protected from alteration;
• how incidents are reported;
• how a record is exported for an audit or customer request;
• what happens when the contract ends;
• how model or vendor changes are approved.

The technology contract should not be separated from the compliance design. A change to the identity vendor may change the evidence quality, decision logic, user messaging and retention process. Create a change-control trigger for vendor, model and workflow changes.

The trigger should apply to silent changes as well as visible redesigns. A new document model, a different fraud score or a changed subprocessor can alter the risk outcome even when the customer sees the same button. Record those changes and test a representative set of cases before relying on the new result.

For institutions within the European regulatory perimeter, DORA provides a useful reference for ICT risk and third-party arrangements. The EBA DORA overview explains why resilience and third-party governance are core financial-sector issues. Swiss entities should determine their own scope rather than copy a generic EU statement.

Measuring a healthy onboarding system

Conversion rate alone is a poor measure. A platform can increase account openings while weakening evidence quality or creating more manual remediation.

Use a balanced dashboard:

The metrics should be segmented by customer type, country, language, product and acquisition channel. A single average can hide a serious problem in one segment.

Public communication that supports compliance

Acquisition pages often cause the most confusion. Review every claim about:

• account opening speed;
• eligibility;
• security;
• protection;
• regulation;
• execution;
• product access;
• support;
• withdrawals;
• insurance cover.

The claim should identify the entity and its scope. Avoid “fully protected,” “risk-free,” “instant approval” and similar wording that a customer could read more broadly than the institution intends. A precise sentence is usually more credible than a large promise.

Affiliates and lead partners should receive approved copy, not a general brand deck. Monitor how the page is actually displayed in search results, social posts and comparison tables. The insurer or broker may still face reputational damage when a partner makes a promise that the institution did not approve.

Digital onboarding readiness checklist

Before launch, a bank, broker, fintech or insurer should be able to answer:

1. Which legal entity receives the application?
2. Which customer and country rules apply?
3. Which identity method is used and why?
4. How are beneficial owners identified?
5. What information explains the purpose of the relationship?
6. How are sanctions and adverse-information matches reviewed?
7. Who owns exceptions and manual decisions?
8. Which evidence is retained and for how long under the applicable policy?
9. Which vendor systems process the data?
10. How are model, vendor and workflow changes approved?
11. How are customers informed about delays or additional review?
12. Which public claims have been approved by compliance?

If the answer to any of these questions is unclear, the next action should be a controlled review, not a larger advertising budget.

The exception queue is part of the customer experience

Most onboarding discussions focus on the happy path. In practice, trust is often created in the exception queue. A customer whose name is common, whose company structure is complex or whose document is difficult to read should not disappear into an unexplained process.

Design a visible internal queue with categories such as:

• document quality;
• identity mismatch;
• ownership complexity;
• country or product restriction;
• sanctions or adverse-information review;
• source-of-funds question;
• duplicate account;
• suspected account takeover;
• technical failure.

Each category needs a service owner, a maximum review interval under the institution’s policy, an escalation route and an approved customer message. Do not promise a specific approval time publicly unless operations can sustain it across countries and customer types.

The queue should also capture the reason for closure. “Rejected” is not a sufficiently useful internal outcome. The institution should know whether the case was incomplete, outside scope, inconsistent, suspicious, duplicated or blocked by a technical issue. This helps compliance, product and marketing correct the root cause without exposing sensitive detection methods.

Test the onboarding flow before it goes live

Use scenario testing rather than only a clean demonstration account. A serious test set includes:

1. a straightforward retail customer with a valid document;
2. a customer whose document is near expiry;
3. a customer with a transliterated name;
4. a company with several ownership layers;
5. an authorised signatory who is not an owner;
6. a customer in a country the service does not accept;
7. an identity match that requires human review;
8. a payment or identity vendor outage;
9. a customer who abandons and resumes the flow;
10. a customer who asks to correct personal data.

For each case, record the screen shown, the data saved, the control outcome, the notification sent and the person who can override the result. Run the tests again after a major vendor or workflow change.

Avoid dark patterns in financial onboarding

A financial institution should not make the compliant choice harder to find than the commercial choice. Examples of poor practice include hiding the contracting entity, preselecting a complex product, making a risk disclosure unreadable on mobile, requiring a customer to accept marketing before receiving essential information or making the withdrawal and complaint path difficult to find.

Good onboarding is clear about what is mandatory, what is optional, which product is being requested and what will happen next. It tells the customer when a review is incomplete instead of using a success screen that creates a false sense of approval. This clarity is not only a design preference; it reduces complaints and gives the institution a more defensible record of communication.

Governance for an onboarding change

Every material change should answer five questions before release:

• What customer, product or country is affected?
• Which control or evidence changes?
• Which vendor, model or data path changes?
• Which public wording must be updated?
• Which test proves the new flow works?

Keep a release note with the decision, reviewer, date and rollback plan. A change to a vendor’s document-recognition model can affect approval rates and false positives even when the interface looks identical. A change to the public claim can affect customer expectations even when the compliance control is unchanged.

What a partnership due-diligence pack should include

When a bank, broker or insurer evaluates an onboarding provider, request more than a product demonstration. Ask for a data-flow diagram, subprocessor list, incident process, access-control summary, testing approach, service-level assumptions, export method, retention configuration and change-notification process.

The institution should also test the provider’s public language. Does the provider claim to make a compliance decision, or does it provide evidence and workflow support? Does it promise that a customer is “verified” when it only completed an automated check? Precision in the vendor’s own marketing is a useful signal of how it will communicate inside the partnership.

Review questions for management

Senior management can use these questions in a quarterly review:

1. Which onboarding step creates the most manual work?
2. Which customer segment creates the most false positives?
3. Are rejected customers given a clear and appropriate explanation?
4. Have any vendor or model changes altered the evidence quality?
5. Can the institution reproduce a decision from the retained record?
6. Are marketing claims still consistent with the current customer flow?
7. Are complaints reaching the team that can correct the product?
8. Has a new product or country been launched without updating the risk map?

These questions connect the onboarding funnel to governance. They also create useful editorial material for a bank, broker or insurer that wants to demonstrate operational maturity without publishing confidential controls.

The same principle applies to acquisition partners. A lead form, comparison page or educational guide should not imply that every visitor is eligible, verified or approved. Use the content to explain the process, then let the institution make the actual customer and risk decision through its documented workflow.

That separation protects both the reader and the institution when a partner campaign is scaled across languages and countries.

Frequently asked questions

Can digital onboarding replace a human compliance team?

No. Automation can collect evidence, identify signals and route cases, but institutions still need governance, exception handling, quality assurance and accountable decisions.

Is video identification the same for every financial business?

No. The acceptable method depends on the institution, activity, customer and current rules. The platform should verify the applicable official guidance before changing the workflow.

What should a broker tell a customer during onboarding?

The broker should make the contracting entity, eligible products, custody model, relevant risks, support route and any additional review requirements understandable before the account is activated.

How should a fintech measure onboarding quality?

Combine completion, manual review, false positives, decision time, rework, fraud signals and complaint themes. Do not use conversion as the only success metric.

Why is vendor governance part of KYC?

Because an identity or screening vendor influences the evidence collected, the decisions made and the records available for review. A vendor change can therefore be a control change.

Conclusion

The best digital onboarding journey is not the one with the fewest questions. It is the one that collects reliable evidence, explains the process, routes exceptions to accountable people and keeps the public promise aligned with the actual service. Swiss banks, brokers, fintechs and insurers can improve both conversion and trust when product, compliance, engineering and marketing work from the same entity and data map.

For the wider business-model context, read the Swiss FinTech market-entry checklist, the FINMA broker safety checklist and the Swiss financial platforms pillar.