Building a Design System for a Fintech Product

Build a fintech design system in a deliberate order: define design tokens in three tiers — primitive, semantic, component — then a component library prioritized by money surfaces such as amount inputs, currency display, data tables, status states, and charts, with WCAG 2.2 AA accessibility built in, documented in Storybook, versioned, and shipped as code so brand, site, and product stay consistent.

A design system is not a component library, and for a fintech it is not a nice-to-have. It is the machinery that keeps a balance readable, a loss unmistakable, and a brand coherent from the marketing site through onboarding to the dashboard where a user actually moves money. Most systems fail because they start from buttons and colors instead of from the decisions money surfaces force. This is the build order we use at FinWeb when the system has to hold up under real financial data.

How do you build a design system for a fintech product?

Work outward from the smallest decisions. Lock design tokens first, because everything else references them. Build components in priority order set by the surfaces that move or display money. Bake accessibility into each component rather than auditing later. Document in Storybook, version deliberately, and treat tokens-in-code as the single source of truth.

The order matters because each layer depends on the one beneath it. Tokens define what “negative” or “primary” means before any component consumes those meanings; components define behavior before any screen composes them. Skip a layer and you end up hard-coding a red hex into a status chip, which then can’t be re-themed for dark mode without a find-and-replace across the codebase. The practical sequence:

1. Define design tokens in three tiers, in code, with a documented naming scheme.
2. Prioritize and build the money-critical components against those tokens.
3. Fold accessibility requirements into each component’s definition of done.
4. Wire up theming — including dark mode — through the semantic token tier.
5. Document every component and state in Storybook.
6. Set versioning, ownership, and a contribution path before the system has more than one consumer.

What makes a fintech design system different from a generic one?

A fintech system carries higher consequences per pixel. It treats money display as a first-class concern — tabular figures, signed amounts, currency, pending versus cleared — and it encodes accuracy and trust into components. Generic systems optimize for marketing flexibility; a fintech system optimizes for legibility, correctness, and states that never let a user misread a balance.

The difference shows up in the details a generic library ignores. A generic table component sorts and paginates; a fintech table also has to right-align amounts, render them in tabular (monospaced) figures so digits line up, distinguish debits from credits without relying on color, and handle a “pending” row differently from a “cleared” one. A generic input validates format; an amount input has to handle currency symbols, thousands separators, decimal precision that varies by currency, and negative values. These are not edge cases in a fintech — they are the main case. The same rigor that belongs in fintech brand guidelines around number formatting has to be enforced by the components themselves, not left to whoever assembles the screen.

How should you structure design tokens?

Use three tiers, following the W3C Design Tokens Community Group format. Primitive tokens hold raw values — a hex code, a pixel step. Semantic tokens give those values intent, like color.text.negative or space.inset.md. Component tokens bind semantics to a specific part, like button.primary.background. Products and sites reference the semantic and component tiers, never raw primitives.

The W3C Design Tokens Community Group publishes a format specification that defines tokens as JSON with a $value and $type. Adopting it means your tokens are tool-agnostic: the same file can feed Figma, a web build, and a native app, so the design source and the code source cannot drift. The three-tier separation is what makes theming and dark mode tractable, because only the semantic layer changes between themes.

The three token tiers

Tier	Purpose	Example token	Referenced by
Primitive	Raw, context-free values	color.red.600, size.4	Semantic tokens only
Semantic	Values with intent and meaning	color.text.negative, space.inset.md	Components, themes
Component	Semantics bound to one part	button.primary.background, table.cell.padding	A single component

The rule that keeps the system honest: application code and screen composition reference only semantic and component tokens. A developer who reaches past those to grab color.red.600 directly has just created a value that dark mode will break. Primitives exist to be aliased, not consumed.

Which components should you build first?

Order the backlog by money surface, not by alphabetical convenience. The components a fintech touches on every screen — amount inputs, currency and amount display, data tables, status and state indicators, and charts — carry the most correctness risk, so they earn the most design time. Build these to a high bar before decorative or marketing components.

Each of these has fintech-specific requirements that a generic version will not meet:

• Amount input — currency-aware formatting, correct decimal precision per currency, thousands separators, negative handling, and a masked or unmasked mode. The single most error-prone input in the product.
• Amount and currency display — tabular figures so columns of numbers align, an explicit sign, currency code or symbol, and a visual distinction between pending and cleared values.
• Data table — right-aligned numerics, sortable columns, sticky headers, row-level states, and semantics that survive a screen reader. The density work here overlaps directly with fintech dashboard design patterns.
• Status and state components — chips and badges for pending, settled, failed, disputed, and flagged, each legible without color as the only signal.
• Charts — a small, disciplined set (line, area, sorted bar) with a text or table equivalent, never a decorative gauge that hides the number a user came to read.

Build these five families well and you have covered most of what a fintech screen is made of. Everything else — modals, tabs, tooltips — is comparatively generic and can borrow from existing open patterns.

How do you bake accessibility into the system?

Make accessibility a property of each component, not a later audit. Meet WCAG 2.2 AA: 4.5:1 contrast for normal text, 3:1 for large text and meaningful non-text elements. Never signal a gain or loss by color alone — pair it with a sign, arrow, or label. Ship focus styles and target sizes inside the components themselves.

The W3C WCAG 2.2 recommendation sets these thresholds, and the W3C WAI is explicit that color must never be the sole means of conveying information. In a fintech that rule is load-bearing: red-for-loss and green-for-gain is invisible to a red-green color-blind user, so a −$420 has to carry the minus sign and, ideally, a downward arrow or the word “down.” When accessibility lives in the token and component layers — contrast-passing color pairs, a focus ring baked into every interactive component, a 24px minimum target size on row actions — it stops being a remediation project. We treat this as a design-system discipline, and the deeper mechanics live in accessibility in fintech products.

How do you handle theming and dark mode for financial data?

Theming is why the semantic tier exists. Because components reference color.text.negative rather than a raw red, one token swap re-themes the whole product. For dark mode, re-check contrast against dark backgrounds — a red that passes on white often fails on near-black — and keep gain and loss distinguishable by more than hue for color-blind users.

Dark mode is not a color inversion. A saturated red that reads as a clear loss on a white statement can vibrate or wash out on a dark background, and its contrast ratio against that background is a different number that must be re-measured against the 4.5:1 threshold. Define a distinct set of semantic values for the dark theme rather than algorithmically flipping the light one. The same caution applies to charts, where line and fill colors need their own dark-theme values so a portfolio’s loss series stays legible. Because every consumer reads the semantic tier, a treasurer switching to dark mode at 11pm sees the same meanings rendered correctly, not a broken palette.

How do you document and govern the system?

Document components in Storybook so every state — empty, loading, error, negative balance — is visible and testable in isolation. Version the system with semantic versioning so consumers know when a change is breaking. Assign clear ownership, a contribution path, and a deprecation policy, or the system rots into a component graveyard within a year.

Storybook matters more in fintech because the interesting states are the dangerous ones. A “pending transfer” row, an amount input rejecting an over-limit value, a table with zero results versus a table still loading — these are the states that cause real incidents, and they belong in documented stories that reviewers and QA can inspect without reconstructing the scenario in a live app. On governance:

• Versioning — use semantic versioning; a token rename or a changed component API is a major bump, and consumers should never be surprised by a silent breaking change.
• Ownership — name a maintainer or a small team. An unowned system drifts within months as teams fork components locally.
• Contribution — publish how a product team proposes a new component or variant, so additions flow back into the system instead of accumulating as one-off copies.
• Tokens-in-code as source of truth — the token files, not a Figma library or a slide, are canonical. Design tools and code both read from them, which is what keeps brand, marketing site, and product visually identical.

A system governed this way is also a trust asset: consistent, correct interface behavior is one of the strongest signals that a fintech is competently built, an argument we make in full in designing trust in fintech UX.

Key takeaways

• Build in order — tokens first, then money-critical components, then theming, documentation, and governance — because each layer references the one beneath it.
• Structure tokens in three tiers (primitive, semantic, component) using the W3C Design Tokens Community Group format, and never let application code reach past the semantic tier to a raw primitive.
• Prioritize the five money surfaces: amount inputs, amount/currency display, data tables, status states, and charts. They carry the correctness risk.
• Meet WCAG 2.2 AA (4.5:1 normal text, 3:1 large and non-text) inside each component, and never encode gain or loss by color alone.
• Re-measure contrast for dark mode rather than inverting; define separate semantic values for the dark theme.
• Treat tokens-in-code as the single source of truth so brand, site, and product cannot drift, and govern the system with versioning, ownership, and a contribution path.

---

A fintech design system is where brand discipline, engineering rigor, and accessibility meet a screen that moves real money. Build it from tokens up, prioritize the components that carry correctness risk, and govern it so it stays the single source of truth rather than a snapshot everyone forks. Our product design practice builds these systems the way they have to be built for money — legible, correct, and consistent from the first token to the last chart. Talk to FinWeb about designing a system your product, site, and brand can all stand on.