Digital design system for banks: compliance first, aesthetics later

Digital banks and e-wallets face two pressures simultaneously: legal requirements for interfaces to be accessible to all users, and business demands for a platform that serves various customer groups. If the design system is not built correctly from the start, both pressures become technical debt and trust risks.

Why approach is a constraint, not a feature

The WCAG (Web Content Accessibility Guidelines) standard issued by W3C has been directly referenced by many legal systems. The European Accessibility Act (EAA) comes into effect on June 28, 2025, and clearly applies to financial services. If the product serves customers or partners in the EU, this is no longer a design recommendation but a legal obligation.

WCAG 2.2 level AA presents four foundational principles, abbreviated as POUR: perceivable, operable, understandable, and robust. For digital banking, these principles directly touch on the most sensitive areas: user authentication, filling out money transfer forms, displaying balances, and transaction error alerts. This is also where trust can be lost the fastest if information is unclear or actions encounter barriers.

Sinh Vũ sets WCAG 2.2 level AA as the baseline right from the token layer, meaning color contrast, minimum touch size, and focus indicators are integrated into the raw materials before components are created. Components, when integrated into the screen, do not need to be rechecked for accessibility from the beginning.

Multisegment: use semantic tokens, do not create separate versions

A bank typically has at least three user groups with different interface needs: retail customers using a personal app, business clients using an account and payroll management portal, and integration partners using an API dashboard. The natural reflex is to create three separate interfaces. This is a structural error.

The three-tier token architecture solves this problem much more neatly. The first tier is the primitive token: color values, spacing, and text in their pure form. The second tier is the semantic token: assigning meaning to values, for example, "primary action background color" or "error warning color." The third tier is the component token: attached to specific elements. When retail segments need a different identity color from the business, you only need to override the semantic tier, while the primitive tier and component logic remain shared.

Areas where trust is lost the fastest

It’s not colors or fonts that make bank customers lose trust. It’s the error state. When customers enter the wrong account number, if the app shows different error messages on each screen, they won’t know where they went wrong or if they should try again. The design system must standardize the entire confirmation loop: error messages, success states, warnings for reconsideration, all must be consistent in placement, language, and color.

WCAG 2.2 emphasizes this point: authentication must have alternative methods (not just color to distinguish right from wrong), forms must have clear guidance before errors occur, not just after. For digital banking, compliance with WCAG in the areas of forms and authentication is both a legal requirement and a direct way to retain customers.

Accessibility is not just the final coat of paint. It is the structure of the building.

Principles of Sinh Vũ practice, based on WCAG 2.2 and implementation experience

The boundary you need to maintain clearly with the design studio

A common point of confusion: the digital design system does not include the core banking operations. Transaction processing, account management, core banking integration, and API layer security are the responsibilities of the internal technical team or the banking system provider. The design studio handles the interface layer, digital identity system, component structure, and tokens. This boundary needs to be agreed upon before the project starts to avoid misaligned expectations along the way.

For legal compliance milestones, the accessibility audit should have a legal expert or accessibility expert confirm it independently. Sinh Vũ provides a foundation that meets audit requirements, but the final confirmation rests with the legal authority.

Common mistakes when building a system for banks

• Considering accessibility as a task at the end of the project. The consequence: having to redo numerous screens during review, costing much more than integrating it from the start.
• Creating separate interface versions for each segment instead of separating semantic tokens. This leads to component duplication, requiring updates in multiple places and increasing the risk of discrepancies.
• Error status and unstandardized validation. This is where customers lose trust the fastest and most directly.
• Expecting the studio interface to always integrate core business operations. That part lies outside the scope of digital design and requires a specialized technical team.