I have worked in fintech and banking for roughly a third of my decade-plus career, starting at GFT in Brazil on real-time dashboards for investment firms, then at BNP Paribas Cardif as an Angular developer, then at Wonderlabs as an Angular developer and UX lead on a credit card PWA in Canada, and then at BMO as a front-end developer on a loan application platform. Outside finance, I have worked on a job platform, a group-travel platform, a health check-up platform, my own SaaS product, and a mental health platform. The contrast is sharp enough that I want to write about it directly: designing for finance is genuinely different from designing for other sectors, and the differences go deeper than aesthetic conventions or a conservative color palette.
This is not a post about making banking apps look modern. It is about the fundamental design constraints that make financial UX a distinct discipline. And how to work effectively within them.
Trust is the Product
In most software categories, the product is a feature set. Users choose Slack because of its channel system and search, or Notion because of its flexible block editor. In financial products, the feature set is table stakes. The actual product is trust. A user who does not trust that their money is safe, or that the app is showing them accurate information, will not use it regardless of how elegant the interface is.
This means that every design decision in a financial product has to pass a trust filter. Does this UI pattern communicate reliability and stability? Does this error message explain what happened clearly and honestly? Does this loading state reassure the user that their transaction is being processed, or does it create anxiety? These are questions that do not arise as acutely in, say, a travel booking app.
Visual Trust Signals
Trust is partially communicated visually. The conservative design language of most banking apps, muted colors, clean typography, limited use of playful elements, is not a failure of creativity. It is a deliberate signal: this is a serious, stable institution. Users have been conditioned to associate visual calm with financial reliability, and departing from that convention requires careful calibration.
Banking design systems push toward modern, accessible visual design while keeping the trust signals users expect. The primary color sits in a blue-dominant palette associated with financial security. Typography is clear and legible, never decorative. Microinteractions are purposeful and informative rather than delightful-but-distracting. At BMO I built features with the bank's design system, which another team owned, and from the developer's seat the lesson is how little room a system like that should leave for playful variation. A button that feels tonally inconsistent with the context of moving money costs trust, not just clicks.
Compliance as a Design Constraint
Every design decision in a regulated financial product has a legal dimension. In most financial institutions, compliance has a say before development begins. That is not a bureaucratic inconvenience. It is a fundamental part of the design process, and I work the compliance constraints into the first wireframe rather than treating them as a final review step.
Compliance constraints in financial UX include: mandatory disclosures that must appear in specific locations and at minimum font sizes, required confirmation steps before irreversible transactions, specific language for fee disclosure, time-based session expiry with appropriate user notification, and audit trail requirements that affect how interactions are logged and displayed.
In fintech design, the compliance constraint is not the enemy of good UX. It is a design brief from the regulator. The challenge is satisfying it in a way that is also clear and usable.
The disclosure placement problem is a good example. Regulatory requirements often mandate that fee disclosures appear before a user confirms a transaction. A naive implementation puts this as a paragraph of legal text that users immediately scroll past. A better design integrates the disclosure meaningfully. Summarizing the key information (You will be charged $4.50 for this transfer) in plain language, with a link to the full legal text for users who want it. This satisfies the compliance requirement and serves the user.
Error Handling in Financial Flows
Error states in financial applications are genuinely high-stakes. A vague error message during a fund transfer does not just create frustration. It creates panic. Did the money leave my account? Is it lost? Should I try again? If the user retries and the first transaction went through, they may have sent money twice. This is not a theoretical edge case; it is a scenario that banking UX teams take very seriously.
The principles I apply to error handling in financial flows, money movement being the hardest case:
- Always tell the user the current state of their transaction. If the transfer failed before reaching the network, say so. If it was submitted but the response timed out, say that. And explain what that means for their balance.
- Never leave the user in ambiguity about whether money has moved. Even if you do not know the outcome, say 'We are confirming your transfer. We will notify you once we have confirmation.' This is better than silence.
- Distinguish between user errors (wrong account number format) and system errors (network timeout) in the message, because the appropriate action is different in each case.
- Provide a clear recovery path. 'Please try again' is inadequate. 'Please try again in a few minutes. If the problem persists, contact us at 1-800-XXX-XXXX' is actionable.
- For irreversible errors, provide contact information immediately. Do not make a panicked user hunt for a phone number.
Progressive Disclosure for Complex Products
Financial products are inherently complex. A mortgage application involves dozens of data points, conditional questions, legal agreements, and multi-step verification. An investment portfolio view involves data hierarchies, performance calculations, risk indicators, and comparative benchmarks. Presenting all of this at once is cognitively overwhelming. Not presenting enough of it violates the user's need for information when making consequential decisions.
Progressive disclosure, revealing information progressively as the user demonstrates need or readiness, is one of the most important techniques in fintech UX. In a long application form, that means revealing questions based on earlier answers (no need to ask about spouse income if the applicant indicated they are single) and breaking the form into what feels like a conversation. Onboarding is where flow design has paid off most clearly for me: at Wonderlabs I redesigned the credit card platform's onboarding flow through prototyping and testing cycles, and user engagement rose 15%.
Layered Information Architecture
Progressive disclosure applies not just to forms but to information display. The pattern generalizes well to a portfolio view: essential metrics at a glance, total value, today's change, overall return, and everything else one expansion away. By asset class, by individual security, by time period. That layering respects both the user who wants a quick check and the user who wants deep analysis, without overwhelming either.
Security as a UX Pillar
Security requirements in financial applications create real UX friction, and the design challenge is to minimize that friction without compromising the security model. Session timeouts, two-factor authentication, transaction confirmation steps, biometric re-authentication for sensitive actions. All of these exist for legitimate reasons, and all of them add friction to the user experience.
The key insight I have developed is that security friction feels acceptable to users when it is proportional to the action's risk level and clearly explained. Re-entering your password to view your account balance feels absurd and invasive. Re-entering your password to change your linked bank account feels reasonable. Users understand why that action warrants extra verification.
The model banks converge on is risk-tiered authentication, where the friction level scales with the transaction amount and type. Low-value, routine transfers (paying a regular bill under a threshold amount) use biometric only. High-value or unusual transfers require biometric plus a confirmation code. New payees require a full 2FA challenge. I have not designed one of these models myself, but the discipline of matching friction to risk is the part worth copying into any product with consequential actions.
Accessibility in Regulated Industries
Accessibility in financial services is not just an ethical obligation. In many jurisdictions it is a legal one. Canadian banks are federally regulated, so they fall under the Accessible Canada Act and the Canadian Human Rights Act rather than Ontario's AODA (Accessibility for Ontarians with Disabilities Act). AODA covers provincially regulated organizations in Ontario, credit unions among them, and its Integrated Accessibility Standards Regulation (IASR) uses WCAG 2.0 AA as the technical benchmark (with exceptions for 1.2.4 live captions and 1.2.5 audio description). At BMO, the features I built had to be accessibility-compliant, and I treat that as part of done, not an afterthought.
Financial UX has specific accessibility challenges that other sectors encounter less frequently:
- Complex data tables (transaction histories, portfolio views) need proper table markup with column and row headers for screen reader users. A visually elegant table that collapses on mobile and loses its header context fails accessibility.
- Charts and graphs are standard in financial applications but inherently inaccessible without text alternatives. Every chart needs a text summary and an accessible data table alternative.
- Time-limited sessions create a genuine accessibility challenge. Users with cognitive or motor disabilities may need more time to complete transactions. WCAG 2.2.1 (Timing Adjustable) is usually met with a warning before expiry and a simple way to extend the session, and in a banking app that warning has to be announced to screen reader users, not just shown as a toast that fades.
- Error messages in financial forms must be programmatically associated with their input fields so screen readers announce them correctly. This is a development requirement that starts at the design specification stage.
What Transfers from Other Sectors
Not everything is different in fintech UX. The fundamentals of user research, usability testing, information architecture, and interaction design apply everywhere. The mental health platform work I did taught me a great deal about designing for users in emotionally vulnerable states, and those lessons transfer directly to financial UX, where users are often stressed (account overdrawn), anxious (market volatility), or overwhelmed (mortgage application).
The shift in entering fintech design from other sectors is less about learning new techniques and more about internalizing a different risk model. In fintech, the consequences of a poor user experience are not just dissatisfied users. They are financial harm, regulatory non-compliance, and erosion of the trust that is the foundation of the entire product. That weight changes how you design, for the better.
References
- Financial Consumer Agency of Canada, Financial Consumer Protection Framework. https://www.canada.ca/en/financial-consumer-agency/services/banking/rights-new-protections/consumer-protection-framework.html
- WCAG 2.1 Understanding. https://www.w3.org/WAI/WCAG21/Understanding/
- Accessibility for Ontarians with Disabilities Act. https://www.ontario.ca/laws/statute/05a11
- Accessible Canada Act, summary. https://www.canada.ca/en/employment-social-development/programs/accessible-people-disabilities/act-summary.html