End-to-end product design of a fintech mobile app: multi-currency accounts (₾ / $ / €), card deposits from local banks, KYC with liveness verification, and biometric login — taken from market research to a fully documented, dev-ready handoff in one month.
People in Georgia live between three currencies: salaries in lari, savings in dollars, subscriptions in euros. Managing that usually means juggling two banking apps and a trip to an exchange booth. Multipay's bet was a single wallet where GEL, USD and EUR live side by side, funded from local bank cards, with exchange built into the transfer flow itself.
Before drawing screens I mapped how Georgians actually handle money — freelancers paid in USD, families with EUR subscriptions, everyone spending in GEL — and benchmarked every product they use for it.
The field: the two big bank apps (TBC and Bank of Georgia's mBank, plus TBC's neobank Space), the local wallet eMoney, and the global neobanks people install for travel. Each wins somewhere — none covered the full loop of hold-in-three-currencies, top-up-from-any-local-card, pay-and-withdraw:
← swipe the matrix →
Product context: Multipay is a real product by Multiverse (multipay.ge) — QR & phone-number transfers, IBAN withdrawals, event cashless payments, and two-tier registration, which shaped the flows below.
Every time my salary lands I lose money — the bank's rate, the transfer fee, the waiting.
If I can't see where my money is right now, I don't trust the app holding it.
← swipe the map →
Balances always visible, IBAN masked but copyable, panic actions (block account, freeze card) one tap from Home. The app never hides what's happening with money.
Every step of every flow asks exactly one question: from where, to where, how much, confirm. No screen mixes decisions — which is why 20+ flows stay learnable.
Currency chips sit directly under the main balance on every account screen. Switching ₾ / $ / € is a glance, not a journey.
No screen ships without its siblings: loading, empty, error, denied. If a developer has to invent a failure screen, the design isn't finished.
I started with a mood board, then built the same core screens in five complete color directions — not swatch tests, but full flows: a Google-inspired palette, a Facebook-style blue, a mentor-suggested variant, deep purple, and cyan. Seeing real screens side by side made the decision honest instead of theoretical.
Electric blue #2C4FFF on near-black navy #090411. Blue reads as banking and security; the dark base makes balances and the premium card the heroes of every screen, and passes contrast checks even at caption sizes.
Deep purple looked striking but read as crypto/gaming — the wrong association for an app holding salaries. The Google and Facebook palettes tested friendlier, but felt borrowed; a wallet shouldn't remind you of someone else's brand.
The home screen leads with the physical card and total balance, currency chips directly beneath (₾ 15,354.60 / $ 14.53 / € 0.00), then the five actions people actually come for: Deposit, Withdraw, Transfer, Block, Card details. The hexagonal PAY button anchors the tab bar — payment is the center of the product, so it's the literal center of navigation.
Top-ups come from local BOG and TBC cards — the two cards every Georgian actually owns. Quick-amount chips (10 / 20 / 50 / 100₾) cover most real deposits; card entry supports save-for-next-time; and the flow always resolves to an explicit end state.
Internal same-currency, internal with exchange, and external to IBAN are three separate flows in the spec — but to the user they're the same four questions: from, to, amount, confirm. Exchange shows the rate inline at the amount step, so converting salary into dollars is a transfer, not a feature to find.
Money leaves either to a bank card or an IBAN — mirrored flows with the same confirmation contract. Card management covers linking, blocking and detail views without leaving the wallet.
Face ID / Touch ID after first login, a Devices screen listing every active session, and account blocking one tap from Home. Security isn't a settings page — it's furniture in the main rooms of the app.
KYC is where wallets lose users, so verification is progressive: a light registration opens a limited account immediately, and full KYC — documents plus liveness — unlocks withdrawals when the user is ready. Nobody hits a wall of paperwork before seeing the product. Every failure state is drawn: blurry ID, rejected selfie, pending review. My exploration page grew past 600 screens before this flow was distilled.
Now tap through it. The same click-through build I use for usability testing:
2,000+ screens stay consistent because they're built from 49 components and two documented overlay structures — a popup and an action drawer — with fixed spacing rules. Every control ships with neutral, focused, typed, error and disabled states.
Below isn't a screenshot. It's Multipay's actual token set and core components rebuilt in live code — click a swatch to copy its hex, focus the inputs, type in the OTP:
| Heading 3 | Gilroy Bold · 24 / 20 |
| Body — Balances always visible, actions one tap away. | Gilroy Medium · 14 / 16 |
| Caption — Amounts are given in GEL for a year | Gilroy Regular · 12 / 16 |
| Button Label | Gilroy Bold · 14 / 20 |
Why this matters: I hand off design systems developers can trust — and I can rebuild them in code myself. Every state above (hover, press, focus, error, disabled) matches the documented Figma spec.
The final deliverable was a dedicated Handoff page: 20 flows — sign-in, registration, deposits, three transfer types, two withdrawal types, cards, transactions, notifications, devices, account management — each laid out screen-by-screen with the style guide at the top. A developer can build any screen without asking "what happens if this fails?", because the answer is already drawn.
"Research, five directions, 2,000+ screens, 49 components, twenty documented flows — one month."
I'd bring usability testing earlier into the KYC flow — I designed all the failure states, but real users would have shown me which ones they actually hit most, and the flow could be ordered around that. And I'd lock the component library before the color explorations instead of after; rebuilding five directions on unfinished components cost me days I could have spent testing.
Have a project in mind? I'd love to hear about it.
Beka Jikurishvili