A fintech dashboard is not a regular dashboard with dollar signs added. The data behind it has conventions, rules, and failure modes that general dashboard advice never touches.
A price feed can drop mid session. A correctly calculated number can still be a lie if it is rounded wrong. Red can mean the opposite of what you assume, depending on the market you're shipping to.
Most writing on this subject comes from design agencies and BI tool vendors. About half of it is generic dashboard advice with the word fintech pasted on top: onboarding flows, gamification, biometric login.
None of it comes from someone who has actually shipped a live trading or payments screen. These are eight patterns that are true of financial data specifically, not of dashboards in general.
This post is about the dashboard itself. For the product around it, the onboarding, the money movement, the confirmations and errors, see the broader guide to fintech UX design.
Red and green are not universal, and one of them is backwards
In the US and Europe, green means a price went up. Red means it went down. That convention feels like a law of nature if you've only designed for those markets.
It isn't one. In China, Japan, South Korea and Taiwan, the convention is inverted. Red signals a gain. Green signals a loss. Plenty of design guides state "green for gains and red for losses" as though it were fixed. It's a regional default, not a rule.
If your product serves those markets, gain and loss color needs to be a locale setting, not a constant baked into your component library. Ship it the same way you ship currency formatting or date formatting.
There's a second problem inside a single market too. Color alone fails colorblind users, regardless of which convention you use. A red number and a green number can look nearly identical to someone with red green color blindness.
Gain and loss need a second signal that doesn't depend on color: a plus or minus sign, an arrow, a triangle. Color reinforces the message. It should never be the only one carrying it.
Negative numbers have a convention, and it isn't just making it red
Finance has real formatting conventions for negative numbers, and design guides almost never state them.
Parentheses for negatives are standard in accounting and financial statements. A figure like (1,240.00) reads as a loss of 1,240.00 in almost any ledger or report a finance team has seen.
A minus sign is standard in trading and market data instead. A position screen or a price ticker uses negative 1,240.00 written with a sign, not parentheses.
Pick one per context, and never mix them in the same view. A table that uses parentheses in one column and minus signs in another forces the reader to translate twice, and every translation is a chance to misread a loss as a gain.
Color only negatives fail for the same reason color only gains and losses fail. A low vision user, a printed report, or a greyscale export all lose the color entirely. If a number's sign only lives in a background tint, it doesn't exist for that reader.
The fix is cheap. Keep the sign or the parentheses in the text itself. Let color sit on top as decoration, not as the only carrier of meaning.
Precision is a decision, and the wrong precision is a lie
This goes almost entirely uncovered, and it's one of the easiest ways to quietly break trust.
Money isn't one number type. A cash balance shows two decimal places. A forex pair often needs four or five. Crypto can need more, because a single unit can be small enough that two decimals round it down to zero.
Basis points exist for a similar reason. At large scale, a percentage rounded to one decimal can hide a difference that actually matters to someone's position.
The rule that matters most: never round a number a user will reconcile against another system. If your dashboard shows a portfolio total that doesn't match a bank statement to the cent, you haven't simplified anything. You've broken it, and that mismatch is what actually erodes trust in a product.
Rounding is fine in a summary tile, where the point is a quick read. It's never fine in a row someone will tick off line by line against a statement.
And if you round anywhere, say so. A small "rounded" label costs one line of copy and saves a support ticket later.
Traders read tables. Stop giving them cards
A lot of fintech design advice recommends card based layouts with small inline graphs. That's exactly wrong for a position screen.
Someone scanning twenty open positions, comparing them, and deciding what to close needs a dense table they can sort and align. Not a grid of cards. A card forces the eye to a new spot for every comparison. A table lets the eye travel one column at a time.
Numbers need to be right aligned, ideally set in tabular figures, so the digits line up in a straight column. Right alignment turns a column of numbers into something scannable the way a spreadsheet is scannable. Left aligned or centered numbers force you to read every digit of every row.
The honest rule: charts are for shape and trend. Tables are for values someone will compare or act on. A price chart shows direction. A position table tells you whether to act.
Most fintech dashboards need more table than their designer wants to give them, because tables feel plain next to a chart. If you're not sure whether a screen actually holds up under real use, auditing it against how people actually work it is the fastest way to find out, faster than guessing from a mockup.
When the feed drops, the UI has to say so
Nobody covers this, including the BI vendors who are otherwise the most finance literate writers on the subject.
If a price feed dies mid session, a position row must not keep showing the last known value as though it were still live. A trader who doesn't know the feed is down will act on a stale number as if it were current. That's worse than the feed going blank.
The pattern that actually works: freeze the value at its last known number. Mark it visibly stale with a badge and a muted, lower contrast treatment. Stamp the exact time it was last good. "Last updated 14:32:07" tells a trader everything they need to decide whether to trust the number.
Never blank the cell. An empty cell reads as a zero position, or as an error to investigate, when the real state is simpler: the feed dropped, and this is the last thing it told us.
The general rules for loading, empty, and stale states are their own topic, and I've written those up in full in the guide to designing stale and partial failure states, so I won't repeat them here. What's specific to finance is narrower: a stale price is not the same failure as an empty state, and treating it like one gets someone trading on bad information.
Delayed data has to disclose itself
Real time market data costs money. Most retail facing products show delayed data instead, and the finance industry has a standard way of handling that honestly.
The common convention is a disclosed delay, most often fifteen minutes. Brokerages and market data vendors label it explicitly on screen: "Data delayed by 15 minutes" sits right next to the price, not buried in a settings page.
Dashboard advice in general never mentions this, because delay disclosure isn't a general dashboard problem. It's a finance specific one. Showing a delayed number as current isn't just misleading. It can be a compliance problem before it's a design one.
If your data is delayed, the delay is part of the interface. It belongs next to the number it affects, at a weight the user will actually notice, not tucked into a tooltip they have to hover to find.
A number presented as current when it isn't is a false claim, whether or not anyone intended it as one. Treat the delay label with the same seriousness as the number itself.
Reconciliation needs a UI, not just an architecture
The BI vendor's page frames reconciliation as a data problem: matching numbers across many source systems that disagree with each other. That's correct, and it stops one step short of the real design question.
The question it skips: what does the screen do when two systems disagree?
The pattern: show both values side by side. Show the difference between them. Name which source is treated as authoritative, and timestamp the side that's stale or unconfirmed. A reconciliation screen that hides the disagreement hasn't solved the problem. It's just hidden it from the person whose job is to catch it.
Don't silently pick a winner and show only that number. Don't average the two values either. An average isn't a real number here, it's a figure that looks plausible while representing neither system correctly.
A number that quietly resolved a disagreement behind the scenes is the most dangerous one on the screen. It looks settled and final when it's neither, and the person looking at it has no way to know a disagreement ever existed.
If two source systems disagree and your dashboard has to pick a display value, show a small "differs from source" flag on the number instead of silently resolving it. It costs one icon and saves a very bad phone call later.
Time is the quietest bug in finance
"Today's volume" with no timezone stated is where reconciliation failures usually begin. A trader in London and a trader in New York can both look at "today" and mean two different windows.
Financial data has session boundaries a general dashboard never has to think about: premarket, after hours, market close, weekends, and holidays that differ per exchange. A portfolio holding a US stock, a European bond, and a Tokyo listed equity is spanning three market calendars at once.
Two rules fix most of this. First, annotate the timezone on every time bounded figure, not just once at the top of the page. "Volume (ET)" next to the actual number removes an entire category of confusion for four characters of copy.
Second, design an explicit market closed state instead of showing a flat line and letting the user guess whether the feed died. A frozen chart during market hours and a normal chart after close can look pixel for pixel identical. Only a label tells the difference. Without one, the user has to guess, and guessing is exactly what a financial interface should never ask for.
The through line
Every one of these patterns is really one idea, repeated eight times: financial data punishes ambiguity. A number that could mean two things isn't a small flaw here. It's a number someone will act on, reconcile against a statement, or use to decide whether to close a position.
A color that flips meaning by market. A rounded figure that doesn't match a bank statement. A stale price shown as live. A resolved disagreement with no trail. Each one is the same failure wearing a different costume: the number stopped saying what it actually is.
If you're choosing who builds a screen like this, the gap between an agency that has shipped one and one that has only designed dashboards in general is exactly the eight patterns above. Our roundup of B2B design agencies is a reasonable place to start comparing.
If you'd rather have someone audit or build the dashboard itself, that's what B2B product design work looks like in practice.