Mercury Design Breakdown: Banking UX Built for Startups

Mercury has an NPS of 73.8. The banking industry average is 34. That gap is not the result of better interest rates or lower fees. It is the direct return on a decade of design decisions that treated banking software the same way Linear treats project management: as a product that respects the operator using it.

This mercury design breakdown covers the specific decisions behind that number, and what you can take from them for your own product.

TL;DR:

• Mercury frames itself as software, not a bank. Every IA and copy decision reinforces this.

• Onboarding requires only an email address to start. The founding team spent six additional months polishing this flow after a partner bank change delayed their launch.

• The color system is built for calm: green for growth, blue for stability, red and yellow reserved strictly for errors and warnings.

• Dashboard controls are designed for operators managing teams, not individual account holders. Granular card controls and spend limits per employee are surfaced prominently, not buried.

• Mercury's design held under maximum stress: 26,000 new businesses chose them in the four months after the SVB collapse in 2023.

Quick Answer: Mercury's design works because it frames itself as software, not banking. Key decisions include navigation that uses product language rather than banking language, onboarding that starts with just an email address, color restraint with green for growth and no anxiety-inducing reds in the dashboard, and operator-grade controls for managing teams and spend. Their NPS of 73.8 versus the banking industry average of 34, and $650M in annualized revenue with 300,000+ customers, shows the commercial return these design choices deliver (Mercury Annual Letter 2025, Sacra 2025).

What is Mercury and why does its design matter?

Mercury is a banking platform for startups and businesses, offering checking, savings, corporate cards, treasury management, and increasingly, finance workflow automation. It was founded in 2017, operates on a partner bank model (Choice Financial and Column), and filed for a national bank charter with the OCC in 2025, a move that its own team described as a direct response to product limitations imposed by that partner model.

As of early 2026, Mercury has 300,000+ business customers, $20 billion in deposits on platform, and $248 billion in transaction volume processed in 2025, a 59% increase year over year (Mercury Annual Letter 2025). Revenue hit $650M annualized in September 2025, with three consecutive years of GAAP profitability, according to research from Sacra. The $3.5B valuation from their November 2025 Series C led by Sequoia reflects an investor thesis that good UX in financial software is a durable competitive moat.

That thesis has been tested. When Silicon Valley Bank collapsed in March 2023, 26,000 businesses moved their accounts to Mercury in the following four months. Companies do not move their banking infrastructure under maximum stress to a product they tolerate. They move to a product they trust. The design breakdown that follows is about how Mercury built that trust through specific, repeatable decisions.

At 925Studios, we design fintech products across payments, lending, banking, and financial operations. The patterns Mercury uses are ones we see working consistently across the category. Here is what is actually happening under the surface.

How does Mercury use information architecture to say "we are software"?

Mercury's top navigation does not use banking language. Where a traditional bank says "Checking Accounts," Mercury says "Product." Where a bank says "Open Account," Mercury says "Product demo." Where a bank's contact page says "New Accounts," Mercury's says "Sales department." These are not copywriting choices. They are information architecture decisions that signal the product's identity before a user reads a single feature description.

This matters because the mental model a user brings to a financial product determines how much friction they will tolerate. When you label something "Open Account," you are activating the user's mental model of banking: paperwork, waiting, verification, anxiety. When you label it "Product demo," you activate a different model entirely: software evaluation, low commitment, reversible decision. Mercury's entire top-of-funnel architecture is designed to suppress the banking anxiety model and install the software evaluation model instead.

The homepage amplifies this. Instead of marketing copy about security and FDIC insurance, Mercury leads with a live interactive product demo. This is a trust-through-transparency move that almost no financial product has done before Mercury. The implicit message is: "we have nothing to hide, and the product speaks for itself." The explicit copy adds to it: "we are a financial technology company, not a bank" appears in the product itself, pre-empting the regulatory confusion that has hurt other neobanks.

Want to see how this kind of IA thinking plays out in practice for a fintech product? Browse our case studies for examples across banking, payments, and lending.

How does Mercury design onboarding to reduce drop-off?

Mercury's account opening starts with a single field: your email address. Nothing else. No business type, no revenue range, no legal name, no EIN. Just an email. This is a significant departure from the traditional business banking onboarding process, which typically requires extensive documentation upfront and delays approval by days or weeks.

The decision to compress the entry point to a single field reflects a specific understanding of where drop-off actually happens. Most banking onboarding asks for information before it has earned the user's commitment. Mercury flips the sequence: get the commitment first (an email, a low-friction action), then build the relationship across subsequent steps where the user is already partially invested in completing the process.

According to analysis from Fintech Labs, Mercury's founding team spent six additional months polishing this onboarding flow after a banking partner change forced them to delay their launch. That investment in onboarding quality before a single customer had signed up is unusual and the results show in their activation rates. The products that get onboarding right are almost always the ones that treated it as a core product investment rather than a necessary step before the "real" product begins.

Not achieving the activation rates you expected from your onboarding? Get a free UX audit from 925Studios -- we review onboarding flows regularly and can show you where users are actually dropping.

How does Mercury use color and visual restraint in the dashboard?

The Nicely Done Club has catalogued 367 UI screens and 48 marketing screens across 112 identified UI components in Mercury's interface. The color system that emerges from that analysis is built around calm, not energy. Green is the primary brand color, carrying growth framing. Blue is secondary, carrying stability. Red and yellow appear only for errors and warnings. There are no aggressive accent colors, no promotional oranges, no engagement-bait purples.

This restraint is a deliberate design choice for a financial dashboard. Traditional banking apps use color emotionally and inconsistently. Red appears next to negative balances, upcoming bills, overdue payments, and error states simultaneously, creating a constant low-grade anxiety signal. Mercury's color discipline means that when red appears, the user knows exactly what it means: something needs immediate attention. Everything else is just information, not urgency.

The ratio of modals to onboarding screens (108 modal instances documented versus 10 onboarding screens) reveals that Mercury is a dense product post-login. The design challenge with a product this complex is preventing cognitive overload on the dashboard. Mercury resolves this with a clear visual hierarchy that surfaces financial position (account balance, recent transactions, cash flow) at the top level, and puts operational controls (card management, user permissions, wire setup) one level down. Users see their financial state first, then their controls.

How does Mercury design for operators, not individual account holders?

Mercury's most distinctive design decision is who it treats as the primary user. Traditional business banking is designed for the account holder, a single person with signing authority. Mercury is designed for the operator: the founder, CFO, or financial lead who is managing a team with different spending needs and permissions.

Granular card controls are a core feature surfaced prominently in the dashboard, not buried in settings. Each employee card can have category-based spend limits, meaning a marketing team member's card can be restricted to ad platforms and tools while an engineer's card can cover cloud services. This is not a novel fintech feature, but the decision to surface it prominently rather than hide it in an admin panel signals who Mercury sees as its primary user.

The fact that international wire transfers were supported from day one reflects the same operator empathy. Mercury's early customer base was heavily immigrant founders building companies in the US while managing international vendors, teams, and suppliers. A product that forces international wire transfers through a phone call or branch visit is not designed for that user. Mercury built the feature before they had customers who needed it because they understood who their customer was going to be.

This is the pattern we see in the fintech products that retain well: the ones that chose a specific operator profile early and built every feature, every information hierarchy, and every notification around that profile consistently. Our guide to fintech UX design covers the trust and compliance patterns that underpin this kind of product thinking in detail.

What should you borrow from Mercury's design for your product?

The IA framing lesson is the most transferable. Before you name a feature, ask what mental model that name activates and whether that mental model helps or hurts the user's first interaction with it. "Product demo" works for Mercury because the software mental model reduces anxiety in a high-stakes category. The same reframing question applies to any product where the category carries negative associations: healthcare, legal, insurance, compliance. You can design around the anxiety of the category through naming before you design a single screen.

The single entry point principle scales beyond onboarding. Anywhere in your product where you ask for multiple pieces of information before delivering value, apply the Mercury test: what is the minimum commitment required to move the user forward? Compress to that. Collect the rest afterward when the user is already invested.

Color restraint is underused in B2B products. Most SaaS dashboards use color for decoration rather than communication. Mercury's model, where color carries only functional meaning and emotional neutrality is the default, is worth adopting especially in any product where the user's primary emotional state during usage is evaluative or anxious. Financial, medical, legal, and operational tools all benefit from the same discipline.

The operator-first framing lesson is for any B2B product with multiple user roles. Identify who is doing the most consequential work in your product and make sure the dashboard is optimized for that person's workflow, not for a generalized "user." That often means promoting controls that feel advanced (permissions, limits, bulk actions) to the primary navigation level rather than treating them as power user features.

What did Mercury get wrong?

The partner bank model that Mercury used until its charter application created product ceilings they could not design around. Certain product limitations, interest rate caps and specific regulatory constraints, were imposed by the partner structure and not within Mercury's design or engineering control. The charter application in 2025 is an admission that the product vision outgrew the infrastructure it was built on. For startups studying Mercury, this is a useful reminder that product excellence has a ceiling when third-party infrastructure controls the constraints.

The density problem is real. With 108 documented modal instances in the interface, Mercury has built a complex product that rewards power users but can overwhelm first-time business banking customers who are not already familiar with financial operations tooling. The onboarding flow is polished, but the initial post-login experience can feel like being dropped into a cockpit without a briefing. For businesses that are not venture-backed startups with financially sophisticated operators, this density works against Mercury's 73% non-tech expansion goal for 2026.

The tonal consistency that works brilliantly for the startup-operator demographic breaks down somewhat for the professional services and ecommerce verticals that now represent 73% of Mercury's new customer growth (Mercury Annual Letter 2025). A law firm's finance director does not want "sales department" in the navigation. The same framing that earned Mercury trust with YC founders creates friction for more traditional business buyers. As the customer base diversifies, the IA and tone that served the early market will need to evolve without abandoning the software-first identity that made Mercury different.

At 925Studios, we've seen this exact tension in fintech products that start niche and try to expand. The design decisions that attract your first 10,000 customers can become barriers to the next 100,000 if the IA and tone were built for a specific demographic rather than a durable product identity. Solving that without losing what made the product work is one of the hardest design problems in growth-stage fintech.

Frequently Asked Questions

What makes Mercury's design different from other neobanks?

Mercury frames itself as software, not banking. Most neobanks (Revolut, Brex, Relay) still use financial language in their IA and copy. Mercury systematically replaces banking terminology with product terminology at every touchpoint. This single decision shapes the entire user experience before a feature is built. It reduces onboarding anxiety, sets appropriate expectations for how the product behaves, and attracts users who think of themselves as product operators rather than account holders.

How does Mercury achieve an NPS of 73.8 when banks average 34?

The NPS gap is the cumulative result of consistent design decisions: fast onboarding, color restraint that eliminates dashboard anxiety, operator-grade controls surfaced prominently, and a tone of voice that treats the user as a competent professional rather than a retail banking customer. None of these is a single feature. The NPS reflects the product experience as a whole, which is why traditional banks cannot replicate it by copying individual features without changing the underlying design philosophy.

What is the mercury design breakdown most useful for?

It is most useful for designers and PMs building fintech products, B2B SaaS dashboards, or any product where the user category carries anxiety (healthcare, legal, compliance, insurance). Mercury's specific decisions around IA naming, color restraint, onboarding compression, and operator-first hierarchy are all applicable outside of banking. The SVB crisis moment, where 26,000 businesses trusted Mercury under maximum stress, is the clearest real-world test of what trust-focused product design actually delivers.

Does Mercury use a design system?

Based on analysis of their 367 catalogued screens and 112 identified UI components on Nicely Done Club, Mercury maintains a consistent internal design system with a defined color scale (OKLCH-based), predictable component behavior (modals, filters, detail pages), and a strict separation of functional and decorative color use. The consistency across 367 screens at this level of complexity requires a design system, even if they have not published it as an open-source resource.

What is the most transferable design lesson from Mercury?

The single entry point principle. Wherever your product asks for multiple pieces of information before delivering value, identify the minimum commitment required to move the user forward and compress to that. This applies to onboarding, feature setup flows, account upgrade prompts, and any conversion moment in a B2B product. Mercury compresses business account opening to a single email field. That decision alone is responsible for a significant portion of their activation rate advantage over competitors.

How did Mercury's design hold up during the SVB collapse?

26,000 businesses moved to Mercury in the four months following the Silicon Valley Bank collapse in March 2023. This is the most meaningful real-world test of trust design: users choosing a product under maximum financial stress, when the stakes of a wrong decision are existential for their company. Mercury's trust design, built on transparency (live product demo on homepage), honest framing (we are a fintech company, not a bank), and product control depth, held up precisely because it was consistent, not promotional.

What did Mercury get wrong in its design?

Two things. First, the partner bank model imposed product ceilings that no amount of design could work around, which led to the 2025 charter application. Second, the startup-operator tone and IA that built Mercury's early reputation creates friction for the professional services and ecommerce customers now representing 73% of their new customer growth. The design that worked for YC founders may not scale to law firms and retail businesses without changes that risk alienating the core identity.

Which other fintech products use similar design principles to Mercury?

Wise uses the same transparency-first approach, publishing their fee structure upfront and using plain language across the product. Stripe applies the same software-company framing to payments infrastructure. Linear, while not fintech, pioneered the same operator-first design philosophy that Mercury applies to banking. Our Wise design breakdown covers how the transparency principle plays out differently in a consumer-facing remittance product versus Mercury's B2B banking context.

Building a fintech product? See how we design for trust and compliance -- without sacrificing conversion.

If you're building a product and want a second opinion on your UX, talk to 925Studios. We work with SaaS, fintech, healthtech, web3, and AI startups.

See our work or book a free 30-minute call.

Follow us on Instagram and YouTube for design breakdowns and case studies.