Cross-border money still moves like it's 1995
Sending money across borders is still slow and expensive for anyone outside a traditional bank's correspondent network freelancers getting paid by an overseas client, remote workers wiring money home, digital asset holders who want to spend crypto without becoming a full-time trader. They end up choosing between slow bank wires with opaque fees, remittance apps that only handle fiat, or crypto exchanges that don't talk to a bank account at all.
PayMight set out to close that gap: one account that handles fiat and digital assets together. Virtual bank accounts for collecting and paying in USD, EUR, and GBP. Direct wallet-to-wallet and wallet-to-bank transfers. And a yield product for people holding BTC, ETH, or USDT who don't want that value sitting flat.
I joined as the freelance product designer for a year-long engagement, designing the platform from account creation through to daily use MiBank onboarding, the Pay/Receive/Transfer core, and the MiEarn dashboard.
3
Core money movements designed end-to-end: Pay, Receive, Transfer
60+
Payout currencies supported, from HKD and PHP to JPY and KRW
T+1
KYC turnaround target built into the verification flow
Two systems of trust: fiat compliance and blockchain transparency
The hardest part of PayMight wasn't screen count. It was that the product has to satisfy two entirely different trust systems at once. Fiat rails demand KYC, sanctions screening, and jurisdiction-specific compliance we were designing for users across Canada, the US, and the EU from day one. Blockchain rails demand something else: visible, verifiable transactions with no intermediary to call when something goes wrong. A user moving USDT into a EUR bank account needs to feel safe under both sets of rules at once, and the interface is the only place those two systems actually meet.
The second problem was legibility. Off-ramping BTC or ETH into a bank withdrawal has more moving parts than a card payment an exchange rate, a network, a settlement window, a fee stack. If any one of those is unclear, the user won't finish the withdrawal, because moving real money through an unfamiliar sequence is exactly the moment people stop trusting a product.
Compliance and blockchain transparency are solving the same problem from opposite directions proving a transaction is safe. My job was making sure the interface didn't argue with itself while doing both.
Three users, one account they all have to trust with real money
The Cross-Border Earner
Freelancers and remote employees getting paid by overseas clients or employers. Mental model: "I did the work, I need the money in my local bank, and I need to know exactly what I'll actually receive after fees." Needs: a receiving account that looks and behaves like a real bank account, clear same-name payout rules, and a payout total they can trust before they confirm.
The Asset Holder
People holding BTC, ETH, or USDT who need to spend or move that value into everyday life rent, tuition, family remittances without fully cashing out on an exchange first. Mental model: "This is worth something right now, I want it in my bank account without three extra apps in between." Needs: a clear off-ramp path, an honest exchange rate, and confidence that the blockchain transaction and the bank transfer are the same event, not two separate leaps of faith.
The Idle-Balance Holder
Users who already hold BTC, ETH, or USDT and don't want it sitting flat. Mental model: "I'm not trading, I just don't want this doing nothing." Needs: a simple entry into yield with the term and expected return visible before committing, and a real-time way to check it's actually earning not a black box.
Ask for what the next step needs, and make it one account, not two
Account opening was the first fork in the whole product: a new user shouldn't have to understand blockchain mechanics, banking compliance, and yield terms before they can send their first payment. I designed onboarding to collect identity details progressively, tied to the specific rail the user is about to use, rather than front-loading a long form before they've seen any value.
The second decision was making the fiat and crypto sides of the product look like one account, not two. Balances, transaction history, and payout status use the same visual language whether the underlying movement is a SWIFT transfer or an on-chain transaction the user shouldn't have to context-switch between "the bank part" and "the crypto part" of an app they're trusting with real money.
Verification that doesn't feel like an interrogation
KYC is the single biggest drop-off risk in any fintech onboarding, so I staged it around what the user is actually trying to do enough verification to open the account and see the product, more only when they try to move money past a certain threshold or use a named payout. Progress is always visible, and the T+1 turnaround is stated up front instead of left as an open-ended wait.
Pay, Receive, Transfer and the account that carries them
Three flows share one foundation. Receive generates a payment link, QR code, or dedicated virtual account depending on who's paying and in what currency, then settles into whichever currency the user has designated. Pay handles both digital-asset and fiat payments from the same balance screen, whether the recipient is online, a merchant terminal, or another PayMight user. Transfer strips out everything but the essentials for direct wallet-to-wallet or wallet-to-bank movement no intermediary screens, because there's no intermediary in the transaction itself.
MiBank onboarding
Named collection and payout accounts only work if the name on the account matches the name on the user's verified identity, so the design surfaces that constraint early before a user picks a currency rather than as a rejection message after they've already tried to send money. Currency selection is scoped to what's actually usable at that user's verification level.
MiEarn
Deposit an asset, see the term and real-time yield before committing, then track accrual on a dashboard that behaves like a receipt, not a trading chart. The design deliberately avoids the volatility-driven, constantly-refreshing feel of a trading app this is a savings product wearing crypto's rails, not a speculation tool.
Fiat and crypto balances share one visual language in the wallet screen no context-switching between "the bank part" and "the crypto part"
What shipped over a year
MiBank Virtual Accounts
Named collection and payout onboarding with currency-scoped verification, supporting USD/EUR/GBP collection and 60+ payout currencies
Pay / Receive / Transfer
Unified core flows for digital-asset and fiat movement, spanning payment links, QR codes, and direct wallet transfers
MiEarn Dashboard
Yield product for BTC, ETH, and USDT holders with visible terms and real-time accrual tracking
Off-Ramp Flow
Digital-asset-to-fiat withdrawal across five supported assets, with transparent rate and fee display before confirmation
Staged KYC Verification
Identity checks scoped to what the user is trying to do next, with a stated T+1 turnaround instead of an open-ended wait
Unified Balance UI
One visual system for fiat and blockchain transactions so users don't have to context-switch between the bank part and the crypto part