Grow · FinTech · Mobile · Web
NDA
A banking app that every client launches under its own brand
I redesigned the mobile app of a white-label banking platform and designed key parts of its web banking and back office.
- Role
- Senior Product Designer: mobile, web, back office
- Team
- Product manager, business analyst, project manager, developers, QA
- Platforms
- iOS, Android, Web
- Users
- Customers of client fintechs; bank administrators
Overview
Challenge. The mobile app looked outdated, and it had to work under any client’s logo and colors. There was no design system either, so every new feature started from zero.
My role. I redesigned the mobile app, designed transfers, cards, onboarding and crypto flows for mobile and web, designed a large part of the back office and set up a component library.
Outcome. An app that works with any client’s brand, the same flows on mobile and web, and faster delivery once the components were in place.
Context
Fintech companies buy the platform and launch it under their own name, with their logo and colors on top of the same product. Their customers use it on iOS, Android and the web. Behind the scenes, the client’s staff run the bank from a back office: they review requests, manage accounts and import transactions.
Scope
Mobile app. Full redesign: wallet and cards, transfers, transaction history, onboarding with KYC, Face ID and one-time passwords, crypto and currency exchange.
Web banking. New features and improvements to existing flows, kept consistent with mobile.
Back office. Reviewing transfer and registration requests, managing accounts, importing transactions in bulk.
Designing for any client’s brand
Each client puts its own logo and color on the app.
What I did
- Built the redesign on a neutral black-and-white base with one accent color. A client’s logo and brand color can go in without breaking anything.
- Let the content (balances, cards, transactions) set the visual hierarchy, with very little decoration.
- Set up a reusable component library. Before that, every screen was put together by hand.
- Used the same components and logic on mobile and web, and features behaved the same on both.
Trade-off. The default look is a bit plain.
Once the components were in place, new features got noticeably faster to design and ship.
Transfers and transactions
When people send money, they want to know what it costs and whether it got there.
What I designed
- One screen for all transfers. Between your own accounts, to other users, outgoing SEPA and SWIFT wires, card funding and incoming wire details. Each option has a short note on speed or method. This hub was my own proposal.
- Recent recipients and saved templates for repeat payments.
- Transaction history with clear statuses, fees as separate lines, filters for incoming and outgoing, and a money in / money out summary.
- Edge cases and states: pending and failed transfers, insufficient funds, limits, empty states.
A hub takes more space than one form with a dropdown. In return, people see every option and what it costs before they start.
Cards and security
Card details are the most sensitive data in the app, but people need them all the time: to pay online, top up or freeze a lost card.
How it works
- Wallet with virtual and physical cards, the balance and status of each, and quick actions: details, freeze, top-up.
- Details on demand. Card number and CVV open in a sheet with copy buttons and hide again after a countdown.
- PIN behind a one-time password, worked out with the business analyst.
- Onboarding and sign-in: registration with KYC, Face ID and one-time passwords.
Every security step adds friction, so we only added it where the risk is real: card details and the PIN. Everyday card actions stay one tap away.
Web banking and back office
The same flows ran in web banking. For the client’s staff, I designed a large part of the back office.
Request review for transfers and registrations, with active filters shown as removable chips.
Account management: dense, sortable tables with search, filters and export.
Bulk CSV import with the required format and an example file right on the screen. It runs in the background while staff keep working.
How I worked
From Jira to flows. Tasks came from the business analyst, project manager and product manager through Jira. I turned them into flows, sorted out the logic with the BA and covered edge cases before handoff.
Options first. Before picking a direction, I usually brainstormed a few approaches with the team.
Animated prototypes to show how interactions should feel.
Daily collaboration with the PM, BA, developers and QA on priorities, logic and releases.
Metrics
Grow has two layers of metrics: end users of each branded app, and the banks that launch brands on the platform.
+7 pp
Sign-ups reaching an open account
Registration with KYC, Face ID and one-time passwords
−24%
Card and transfer tickets per 1,000 MAU
Clear statuses, fees as separate lines
−4 weeks
From signed client to store release
A neutral black-and-white base with one accent color
pp: percentage points. End-user figures come from one client bank.
What I’d change
Most problems reached me second-hand, through the PM and the BA. Today I’d push for direct contact with end users and client teams, even just a few short calls, to check flows before they ship.