Before the action
Explain the product, ownership model, custody, fees, risk, eligibility, and what the next approval will do.
Fintech · Blockchain · Crypto · Trust
Fintech UX for products where a confusing click can become a financial loss
HAAM designs payment, wallet, blockchain, crypto, banking, treasury, and financial AI experiences around clear intent, explicit permission, understandable risk, reliable transaction states, and realistic recovery.
Transaction review
Send 2,400.00 EUR
- Recipient
- Approved vendor ·•• 8C42
- Asset
- EUR stablecoin
- Network
- Supported L2 network
- Network fee
- 0.18 EUR estimated
- Permission
- One transfer only
- Expected settlement
- About 20 seconds
You are authorizing one transfer. This does not grant future access to your balance.
Cancel
Continue to approve
The design problem
Financial interfaces are systems of consequences
A fintech product does not end at a polished dashboard. It includes identity, authentication, permissions, money movement, settlement, evidence, support, fraud response, compliance review, and recovery. Blockchain adds new forms of ownership and interoperability, but it also moves more responsibility into the interface.
During the action
Keep the user oriented across app, bank, wallet, device, provider, network, and external confirmation steps.
After the action
Show settlement status, evidence, receipt, accounting details, support options, and the limits of reversal or recovery.
Best practices
Eight rules for safer, clearer financial interaction
01
Start with the financial intent
A person is trying to save, transfer, invest, borrow, get paid, or understand risk. Lead with that goal. Wallets, chains, ledgers, rails, and protocols should appear only when they change a decision.
02
Make value legible
Show the asset, fiat reference, exchange rate, fees, spread, slippage, network, timing, and final amount in a stable hierarchy. Never make people calculate the real cost from scattered labels.
03
Separate intent, authorization, signing, and settlement
A button click, wallet signature, transaction broadcast, confirmation, and final settlement are different events. The interface should name each one and explain what it permits.
04
Treat irreversible actions as review moments
Before money moves, repeat the recipient, amount, network, fees, permissions, and consequences in plain language. High-risk actions need stronger confirmation than routine navigation.
05
Design every transaction state
Prepared, awaiting approval, signed, submitted, confirming, complete, rejected, expired, replaced, dropped, and failed are all product states. A spinner is not a transaction model.
06
Build recovery before the happy path
Account recovery, lost-device handling, mistaken transfers, chargebacks, failed deposits, disputed identity checks, and support escalation should be designed before launch, not after the first incident.
07
Use progressive disclosure
Give most users the information needed for a safe decision, then expose hashes, contract addresses, gas details, block explorers, and advanced settings without forcing everyone through protocol jargon.
08
Accessibility is part of financial safety
Clear focus states, understandable errors, accessible authentication, readable numbers, non-color status cues, sufficient target sizes, and reduced-motion support reduce both exclusion and costly mistakes.
Transaction state model
A payment needs more than success and failure
Teams often design the first screen and the final receipt, then leave the risky middle to a spinner, wallet popup, or provider redirect. The state model should be explicit before visual design begins.
- 01
Prepared
The product has calculated the amount, quote, fees, and route.
- 02
Review
The user can verify recipient, network, permissions, and total cost.
- 03
Authorize
The bank, wallet, passkey, or device requests explicit approval.
- 04
Submitted
The instruction has left the interface and reached the payment or blockchain rail.
- 05
Confirming
The system is waiting for settlement, finality, or an external provider.
- 06
Complete
The product shows the result, receipt, reference, and next action.
- 07
Exception
Failure, expiry, rejection, replacement, dispute, or delay has a specific recovery path.
Blockchain and crypto
The interface must translate protocol behavior into human consequences
Crypto products often ask users to move between an app and a wallet, interpret unfamiliar assets, approve permissions, choose networks, wait for confirmations, and accept limited recovery. Good UX does not hide this complexity. It sequences and explains it.
| Layer | Conventional fintech | Blockchain or crypto | UX responsibility |
|---|---|---|---|
| Identity | Account, verified profile, passkey, bank authentication | Wallet address, wallet connection, message signature, optional identity layer | Explain who is acting, what is being shared, and how the session can be ended. |
| Authorization | Payment confirmation, strong customer authentication, mandate | Message signature, transaction signature, token approval, multisig approval | Name the exact permission. Signing in should never look like approving a transfer. |
| Settlement | Processor, bank rail, card network, open-banking payment | Network broadcast, confirmations, finality, bridge or smart contract | Show where the payment is, what can still change, and when it is truly final. |
| Recovery | Password reset, support, dispute, chargeback, account restoration | Seed phrase, social recovery, smart account, guardian, or no recovery | State recovery limits before users commit funds or create an account. |
| Evidence | Receipt, payment reference, statement, support case | Transaction hash, explorer record, signed message, contract event | Translate technical evidence into a human-readable receipt without hiding the source record. |
Exception design
Design the moments most teams postpone
Edge cases are normal operating conditions in financial products. Each one needs an explanation, a safe next action, and a record that support teams can understand.
- Unsupported or incorrect network
- Recipient or address mismatch
- Quote, rate, or approval expired
- Fees changed before confirmation
- Insufficient balance for amount and fees
- Signature rejected or wallet disconnected
- Approval grants broader spending access than needed
- Transaction remains pending longer than expected
- Transfer was replaced, dropped, reversed, or returned
- Identity, sanctions, fraud, or compliance review blocks progress
What HAAM can deliver
From a risky flow to an implementation-ready product system
Journey and trust audit
Review onboarding, identity, money movement, permissions, transaction states, recovery, support, and risk communication across the complete journey.
State and exception model
Define the product states behind every payment, wallet, quote, approval, settlement, failure, and recovery scenario before screens are polished.
Prototype and usability testing
Create realistic flows with real amounts, timing, warnings, confirmations, and edge cases, then test comprehension with target users and domain specialists.
Terminology and content system
Replace vague labels and protocol-first language with consistent wording for fees, risk, permissions, ownership, identity, and transaction progress.
Design system and handoff
Specify reusable components for amounts, balances, warnings, account states, confirmations, receipts, tables, charts, and accessible form behavior.
Implementation priorities
Translate findings into a practical backlog for product, design, engineering, security, compliance, legal, analytics, and customer support teams.
Relevant experience
Research depth plus product implementation
HAAM connects interaction design, behavioral research, front-end implementation, accessibility, cross-cultural product work, and practical Web3 field experience.
Explore related HAAM projectsFinancial AI research
675 valid survey responses, 32 interviews, and 32 prototype tests for a financial AI companion focused on shopping, saving, and investing.
Web3 fieldwork
Hands-on participation in Ethereum and blockchain hackathons across Tokyo, Bangkok, Taipei, and Seoul.
Cross-border product context
Product work spanning Estonia, Taiwan, Europe, and Asia, including payments, identity, localization, accessibility, and trust-sensitive services.
Sources and further reading
Standards, handbooks, and design references
These resources inform the questions HAAM asks. They are not a substitute for product-specific legal, security, accessibility, or compliance review.
W. Pitula
Fintech Engineering Handbook
A broad engineering handbook for fintech systems and operational concerns.
Open source ↗Krever · GitHub
Fintech Engineering Handbook source repository
The open-source repository behind the handbook, licensed under CC BY 4.0 for reuse and adaptation with attribution.
Open source ↗ethereum.org
Design and UX in Web3
Research and design resources for products built around Ethereum and wallets.
Open source ↗ethereum.org
7 heuristics for Web3 interface design
Practical guidance on feedback, trust, terminology, network visibility, and app control.
Open source ↗ethereum.org
Ethereum security and scam prevention
Wallet, transaction, approval, phishing, and account-safety guidance.
Open source ↗Ethereum Improvement Proposals
ERC-4361: Sign-In with Ethereum
A standard message format for wallet-based authentication and consent.
Open source ↗OWASP
Application Security Verification Standard
A verification framework for application security requirements and testing.
Open source ↗PCI Security Standards Council
PCI Data Security Standard
The baseline security standard for systems that store, process, or transmit payment card data.
Open source ↗W3C
Web Content Accessibility Guidelines 2.2
The accessibility standard used to evaluate perceivable, operable, understandable, and robust interfaces.
Open source ↗UK Financial Conduct Authority
Crypto: The basics
Consumer-facing guidance on crypto, volatility, scams, and high-risk investment communication.
Open source ↗Boundaries
Trust also means saying what the work is not
- HAAM does not promote tokens, promise returns, or design dark patterns that pressure users into speculative decisions.
- UX work does not replace legal advice, regulatory analysis, security audits, smart-contract audits, or formal compliance assessment.
- Blockchain is treated as one possible infrastructure choice. A conventional database, bank rail, or payment processor may be the better product decision.
- Risk, fees, custody, permissions, and recovery limits should be visible before commitment, not buried in terms after the action.
Start with the highest-risk journey
Make the product understandable before asking people to trust it with money
Bring an existing flow, prototype, product brief, wallet journey, payment architecture, or transaction problem. HAAM can turn it into a clearer model, testable interface, and implementation plan.
Start a fintech UX project