Fintech App Design: Balance and Transactions Screen

Fintech app design for a balance-and-transactions screen starts with one visually dominant available-balance figure, a transaction list whose amounts use tabular figures, and credit/debit labels that do not depend on colour. Add a visible balance-mask control and a quick-hide control, then place fee, rate, and legal disclosures next to the feature or transaction they qualify—not between list rows. Test the screen with masked data, VoiceOver or TalkBack, large text, and a compliance-approved disclosure inventory before handoff.

Key takeaways

•Use tabular figures (tnum) so every transaction amount occupies equal-width digit columns.
•Make one available-balance amount the screen’s primary numeric hierarchy; account metadata stays subordinate.
•WCAG 2.2 Success Criterion 1.4.1 prohibits using colour as the only way to convey credit or debit.
•Provide a persistent balance-mask control and a separate quick-hide action for sensitive account data.
•Put fee and rate disclosures adjacent to the transaction, transfer, or product they qualify.

This guide is for mobile product designers, founders, and engineers who already understand iOS and Android screen layout and need to ship a reviewable financial account screen.

Time: 45 minutes · You'll need: floow.design project with an iOS and Android mobile frame, Approved account, transaction, fee, and disclosure copy, SF Pro and Roboto font access, iPhone and Android device previews with large text enabled, VoiceOver and TalkBack test devices or simulators

What's on this page

•Set one balance as the primary finance app UI element
•Apply tabular figures to banking app design amounts
•Encode credit and debit with fintech UI patterns
•Add privacy controls to the balance area
•Place disclosures beside the qualified action
•Run accessibility and compliance review on both platforms
•Reference table

•Common mistakes
•FAQs

Creating a fintech app design balance screen

1. Set one balance as the primary finance app UI element

Place the account name first, then one primary amount labelled Available balance. Use that label rather than a bare currency figure: a customer must know whether the number is available, current, posted, or pending. Keep the primary balance in its own block above the transaction list. Put secondary facts—account ending, last updated state, pending total, interest rate, and account type—below it at a smaller text style and lower visual emphasis.

Do not give current balance, available balance, and pending balance equal size or weight. If the product must show all three, make Available balance the default primary value and expose the others as labelled rows or a details view. Use the locale-aware currency formatter supplied by iOS or Android; do not concatenate a currency symbol and a decimal string manually. Test a negative balance, a four-digit balance, and a balance with cents so the hierarchy remains stable.

Tip: If “available” and “current” can differ, show both labels in the first rendered state rather than hiding the distinction behind an info icon.

2. Apply tabular figures to banking app design amounts

Build each transaction row with a fixed trailing amount column. Apply the OpenType tnum feature—tabular figures—to every amount, including the primary balance when it can update live. Tabular figures give each numeral the same advance width, so decimal points and final digits form a readable vertical edge even when values mix £9.50, £120.00, and £1,204.75.

On Apple platforms, use a font configuration that enables monospaced digits, such as SF Pro’s monospacedDigit() behavior. On Android, request the tnum font feature through the text system used by the app, then verify it with the shipping font and a real device. Keep signs and currency symbols inside the aligned amount field; do not put a green + in a separate decorative column. Use a single currency format within one account list. A multi-currency account needs a visible ISO currency code, such as USD, when symbol ambiguity is possible.

Tip: Check alignment with values containing 1, 8, zero decimals, negative signs, and four-digit grouping; proportional digits often fail most visibly on 1.

3. Encode credit and debit with fintech UI patterns

Give every transaction a text status that communicates direction without colour. Use a signed amount such as + $42.00 and − $18.75, or use explicit labels such as Money in and Money out when signs are unfamiliar to the product’s audience. Pair that status with a descriptive merchant or payer name and a transaction state such as Pending, Completed, or Reversed.

WCAG 2.2 Success Criterion 1.4.1 requires information conveyed by colour to be available through another visual means. Green credit text and red debit text may remain as a redundant cue, but they cannot be the only distinction. Check text contrast separately: WCAG 2.2 AA requires a 4.5:1 contrast ratio for normal text and 3:1 for large-scale text. Do not rely on a red-to-green chart icon without a label; screen-reader users and customers with colour-vision differences need the same meaning in the accessible name.

Tip: Use “pending card payment” rather than only “pending”; the transaction type changes what a customer expects to happen next.

4. Add privacy controls to the balance area

Put a balance-mask button in the balance block, adjacent to the number it changes. Its label must describe the resulting action: Hide balances when amounts are visible and Show balances when they are masked. When masked, replace every sensitive amount in the screen’s current scope with a consistent placeholder such as ••••••; do not leave transaction amounts exposed while hiding only the header balance.

Add a separate quick-hide control in the top app bar or overflow menu for situations where the customer needs to obscure the screen immediately. The action should hide balances and transaction amounts in the current view without requiring navigation. Announce the changed state to VoiceOver or TalkBack, and retain a visible way to restore the values. On Android, assess whether FLAG_SECURE is appropriate for the threat model because it prevents screenshots and display on non-secure displays; it is not a substitute for an in-app privacy state and has support and usability trade-offs.

Tip: Do not persist a “shown” balance state across a fresh app launch unless the product’s authenticated-session policy explicitly allows it.

5. Place disclosures beside the qualified action

Keep the transaction list scannable: do not insert a full legal paragraph between two transactions. Put short, decision-relevant disclosure copy directly beneath the feature it qualifies—for example, under an overdraft transfer call to action or beneath an exchange-rate quote. Link that copy to a full Fees and terms or Rate details screen, and retain the exact disclosure version with the transaction or product state used at confirmation.

For the account overview, use a compact footer after the last transaction for account-level notices such as deposit insurance wording, subject to the approved jurisdictional copy. For a specific transaction, show details and related disclosures in the transaction-detail screen, not the list row. Do not treat a generic footer as adequate for a fee or rate that changes a customer’s decision. Have compliance provide an inventory that maps each disclosure to its trigger, placement, approval owner, and locale; the UI should implement that map exactly.

Tip: A disclosure that applies only to international transfers belongs in the transfer quote and confirmation flow, not on every domestic-card transaction row.

6. Run accessibility and compliance review on both platforms

Test the completed screen at the largest supported text setting in the product’s acceptance criteria. Confirm that the primary balance, account label, mask state, each transaction’s merchant, date, amount, direction, and pending state remain available without clipped or overlapping controls. Use VoiceOver on iOS and TalkBack on Android to verify that an amount is announced with its sign or direction and currency, not as an unexplained sequence of digits.

Review three states: visible balances, masked balances, and a quick-hidden screen. Then review empty transactions, an error loading transactions, a pending debit, a reversed debit, and a negative balance. Give compliance a static capture and an interactive build containing every disclosure trigger; they need to verify copy in context, not only a document. Record approved strings, locale, build number, and review date in the handoff ticket so engineering can trace changes after copy updates.

Tip: Treat a changed fee, APR, exchange rate, or insurance statement as a new review trigger even when no layout component changes.

Reference table

Rules for a trustworthy transaction list

Screen element	Specification	Implementation note
Transaction amounts	OpenType `tnum`	Align digit widths vertically
Credit and debit	WCAG 2.2 SC 1.4.1	Never colour alone
Normal text contrast	4.5:1	WCAG 2.2 AA
Large text contrast	3:1	WCAG 2.2 AA
Sensitive values	Hide balances action	Expose changed state

Common mistakes

Showing available, current, and pending balances with the same visual weight.

Choose one primary balance and label it. Put the other balance definitions in subordinate, explicitly labelled rows or a details view.

Using green for credits and red for debits with no sign, label, or accessible description.

Add + and − signs or “Money in” and “Money out” text. Keep colour only as a redundant cue and meet the applicable contrast ratio.

Using proportional numerals in the trailing transaction amount column.

Enable OpenType tabular figures (tnum) in the shipping font. Test values with different digit counts and grouped thousands.

Hiding the header balance while leaving transaction amounts readable.

Define the privacy scope before design. A mask action should consistently cover every amount promised by its label.

Frequently asked questions

What information should be on a banking app balance screen?

A banking app balance screen should show one clearly labelled primary balance, account identity, recent transactions, transaction states, privacy controls, and disclosures tied to relevant actions. Show secondary figures only when their labels explain how they differ from the primary amount. Keep fees, rates, and terms out of the transaction scan path unless they qualify a visible decision.

How should I show credit and debit in a finance app UI?

A finance app UI should distinguish credit and debit with signed amounts or text labels as well as colour. WCAG 2.2 Success Criterion 1.4.1 does not allow colour to be the only carrier of meaning. Use green and red only as redundant cues, and provide transaction state labels such as Pending or Reversed.

Why do transaction amounts need tabular figures?

Transaction amounts need tabular figures because equal-width digits create a stable right-aligned numeric column. Enable the OpenType tnum feature rather than relying on proportional numerals. This makes cents, negative signs, and thousands-grouped values faster to compare in a mobile transaction list.

Where should fintech disclosures appear in a mobile screen?

Fintech disclosures should appear next to the feature, price, rate, or transaction decision they qualify. Put account-level notices in a compact footer after the list and place transaction-specific terms in the relevant detail, quote, or confirmation flow. Compliance must approve the jurisdiction-specific wording and its trigger conditions.

Where this leaves you

A trustworthy account screen makes the customer’s available money easy to identify without making every number compete for attention. Tabular figures turn the transaction list into a column people can scan; text direction and status make credits and debits accessible beyond colour; privacy controls let customers choose when values are visible. Disclosures belong where their fee, rate, or condition can affect a decision, with the full approved text available from that point. Build the six review states—visible, masked, quick-hidden, pending, reversed, and negative balance—into your next prototype before sending it to compliance.

Design the screens first

Describe the screen you need in plain English and floow.design generates production-ready iOS and Android layouts you can iterate on by chat, then export to Figma or code. Design your mobile app screens in floow.design first, then build.

Start designing free →

•Color Picker from Image — Pull a palette out of any image, assign it to screen roles, and export it as tokens or native code.
•Aspect Ratio Calculator — Work out the missing width or height for any ratio, with the common phone and store ratios one click away.
•App Onboarding Screen Design: 3-Screen Flow — Create app onboarding screen design that reaches first value in three screens, defers sign
•Ecommerce App Design: Mobile Checkout Flow — Ecommerce app design guide for faster mobile checkout: guest entry, wallet-first payment,
•Gemini 3.1 for Mobile App UI Design: 4 Real Prompts Tested Hands-On (2026) — I tested Gemini 3.1 Pro with 4 real mobile app UI prompts — fitness tracker, food delivery