9:41
Search for
'BTC'
'BORG'
'ETH'
'BTC'
'BTC'
.png)
Get Started
Total Wealth
+9.87% (24 h)
€1'309'99.82
Today's yield €+8.90
Deposit
BTC
€90'324.89
+8.93%
ETH
€3'450.65
+12.45%
XRP
€1.20
+2.28%
GHST
€1.20
+8.93%
CAKE
€1.73
+8.93%
MATIC
€0.0078
-80.93%
Pepe
€0.00000457
+23.59%
Chain
€8.60
+12.93%
DOT
€1.35
+10.93%
Shib
€0.0000063
-32.56%
Ren
€0.004565
-8.35%
HNT
€0.82
-4.87%
Today
Folio
Exchange
Invest
Profile
Personal Details
Personal Information
Questionnaire
Close
SwissBorg
A regulated European cryptocurrency wealth platform
About SwissBorg
SwissBorg is a European crypto wealth platform operating in a highly regulated environment. Alongside its consumer app, SwissBorg must ensure user identity data stays accurate over time to remain compliant. This requires periodic user data renewal at scale without overwhelming support teams or disrupting access to the platform.
What this case study looks into
This case study focuses on designing a self-serve Data Renewal experience. Previously, users could not update identity information themselves and had to contact support. The challenge was guiding hundreds of thousands of users to review and confirm their data inside the app, reducing support load while keeping users compliant.
"Data renewal’s results are looking amazing. 220k users completed it with hardly any complaints and zero UX complaints."
Sebastien Morelle, Product Manager
My role
Product Designer
Team
Product Owner
Frontend Developer (2)
Backend Developer (3)
Legal (1)
Time frame
1 Month
Tools
Figma
Slack
Jira Confluence
SwissBorg Back Office
Over 700,000 users needed to confirm their data within a year.
How do we avoid creating friction..🤔?
How do we avoid creating friction..🤔?
context
Keeping users information compliant over time
SwissBorg operates in a regulated environment where user data must remain accurate. Regulations required users to periodically reconfirm their personal information, something the platform had never asked at scale in 5 years. Hundreds of thousands of users would need to complete this without overwhelming support teams or harming trust.
Constraints
Epic limitations
User honesty dependency
The users confirm the accuracy of their data themselves. It's up to the users to be honest with us and tell us their latest information, or to confirm that nothing has changed and everything is correct.
.svg)
Cost vs efficency
Manual review for all users would be impossible. Each Proof of Identity review costs money and would certainly lead to friction and drop-offs. So we don't want to make it mandatory to reverify identity.
Annual timing
Not everyone renews at once. Each user renews based on their onboarding anniversary.
Roadblock policy
After 30 days without confirmation, the entire app must be locked. The user can not continue unless they confirm.
Problem statement
Hundreds of thousands of users need to confirm their details. Users need to periodically reconfirm their information, but the product has no self-service flow. Previously, changes like Proof of Identity or Proof of Residence required contacting support. This would create a massive operational load and frustration if repeated at scale.
.svg)
Fines and fees
If SwissBorg does not confirm user data, SwissBorg would receive millions in fines and potential license suspension.
SwissBorg's set-up
The application currently requires users to go through customer support to update details like name and address.
No entry point
There is no in-app way to prompt users to update their data. In the past users were prompted through e-mail.
Goals
Enable compliant renewal without support dependency
Create a simple in-app flow where users can review and confirm their information when prompted, removing the need for manual outreach and reducing operational pressure while keeping data up to date.
Operational scalability
Avoid massive spikes in Proof of Identity and Proof of Residence support tickets.
Clear countability
Allow users to review and update their own information.
Clear entry point
In-app widget prompts users at the right moment and starts the flow.
opportunity
Making a global entry point KYC widget
The KYC widget was designed as a shared surface for all regulatory actions, not just data renewal. It gives the product a consistent way to request information when required, without building separate flows each time.
A solution for all future KYC entry points
This becomes the standard way to handle future compliance requests, reducing repeated builds, support load, and user friction.
Results
High completion, minimal friction
By moving from a fragmented, tab-based experience to a single, guided review flow, agents were able to complete Proof of Residence checks significantly faster. The reduction came from clearer structure, less scrolling, and removing the need for agents to decide how to review an application.
220k+ users competed renewal
Out of those 220k+ users we received zero to minimal UX complaints.
Full-scale compliance achieved
My team and I saved SwissBorg millions in fines all whilst making users compliant.
Massive drop in support tickets
Support tickets dropped significantly once users could update their own data.
Click ont the flows to open in more detail..
JP
Happy Path
From start to success without any edge cases or updating information.
JP
Updating name (Proof of Identity)
Users are now able to update their name by carrying out proof of identity without needing to go through customer support.
JP
Updating address (Proof of Residence)
Updating Proof of Residence without needing to contact support unless the country is not supported.
JP
Updating E-mail address
JP
Updating mobile number
JP
Update citizenship
JP
Updating PEP Status
Users who are a PEP (politically exposed person) are not allowed to continue on the app and if they state they are a PEP they need to contact support.
JP
Updating the place and date of birth
I initially proposed locking the date and place of birth after a successful Proof of Identity to preserve verified identity data. The concern was that allowing edits could undermine a verified profile.
Legal required all users to retain the ability to update their personal details. We aligned with support to route sensitive changes through support review, reducing misuse while remaining compliant.
Legal required all users to retain the ability to update their personal details. We aligned with support to route sensitive changes through support review, reducing misuse while remaining compliant.
JP
Updating questionnaire
I hope you enjoyed the read so far!
To see the design process and how the design solution came to be, please continue to scroll.
Or feel free to see
other projects
The Plan
Section by section
This epic was done in section's we first focused on being compliant by having a flow users can go through to confirm their information. We estimated this would cover around 65% of users.
This was done as a back-up in case we run out of time, we can push users to customer support to change data and not face millions in fines. (We did not run out of time; we worked in sprints, and my engineers did a fantastic job in making sure everything was built in time and minimal support was needed once the solution was released).
This was done as a back-up in case we run out of time, we can push users to customer support to change data and not face millions in fines. (We did not run out of time; we worked in sprints, and my engineers did a fantastic job in making sure everything was built in time and minimal support was needed once the solution was released).
Support approval
Support agreed to this plan, knowing that if we do not release the solution in time, they might be bombarded with data change requests. However, our roadmap showed that we will release in time.
JP
Roadblock
For users who did not log in for the last 30 days or did not confirm their data
Users who did not confirm their data before their deadline will face a complete application roadblock. They will not be able to enter the application until they carry out their data renewal.
We carry out a complete block to the user, as we faced major complaints and pushback from users in a previous regulatory and compliance epic, where we let users enter the application but blocked trading and deposits.
Blocking the user entirely showed much better response in the A/B test.
We carry out a complete block to the user, as we faced major complaints and pushback from users in a previous regulatory and compliance epic, where we let users enter the application but blocked trading and deposits.
Blocking the user entirely showed much better response in the A/B test.
JP
Complications
This was not a one-month project (Backend was a blocker)
During development, we discovered that onboarding questionnaire data was not stored in a reusable way. Updating answers during data renewal would not persist correctly, nor could uses see the questionnaire data they provided in the onboarding.
Rather than patching the flow with the backup solution, which needs support, we aligned as a team to create a proper questionnaire database. This unblocked data renewal and also enabled an upcoming tailored user journey epic that depend on the same data. Solving it once avoided major future complications and blockers.
Rather than patching the flow with the backup solution, which needs support, we aligned as a team to create a proper questionnaire database. This unblocked data renewal and also enabled an upcoming tailored user journey epic that depend on the same data. Solving it once avoided major future complications and blockers.
JP
Tailored user journey
Above you can see the custom tailored journey epic that if a user is a beginner, their Today Tab is different to the Today Tab of a more advanced user or none-tailored. In order for this to be possible, we gather data from the onboarding questionnaire, which we then require for a backend database.
Hand off
Handing off the designs for development
Design hand off was simple and efficient. I aligned with my frontend engineers and my line manager, as well as the design manager, to make sure that all new components are well documented. Below is a photo of the hand-off.
Reflection
My thoughts on this project
This project turned out more complex than expected. Backend became a major blocker, and without it the frontend could not progress, meaning the design would have needed to change.
In the end, 220k+ users completed the flow, keeping the platform compliant with virtually no UX complaints. The KYC widget also became a long-term entry point, later reused for UK compliance, Proof of Residence, Proof of Identity, Tax ID, and other regulatory flows.
Users can now update their name and address without contacting support. This improves the experience and significantly reduces agent administrative workload, allowing them to focus on higher-risk compliance tasks.
In the end, 220k+ users completed the flow, keeping the platform compliant with virtually no UX complaints. The KYC widget also became a long-term entry point, later reused for UK compliance, Proof of Residence, Proof of Identity, Tax ID, and other regulatory flows.
Users can now update their name and address without contacting support. This improves the experience and significantly reduces agent administrative workload, allowing them to focus on higher-risk compliance tasks.
.svg){kind=icon}