A good FX risk dashboard answers four questions in under a minute: what currency exposure do we have, how much of it is hedged, what could it cost us if rates move, and what do we need to do today. Everything else on the screen is decoration. This guide covers how to design one for a UK finance team, from the decisions it supports to layout, refresh rates, alerts and data checks.
TL;DR
- Design backwards from decisions: is exposure within tolerance, and if not, what do we do about it?
- Show exposure by currency and period, hedge coverage against policy, and potential loss (including Value at Risk and a simple rate-shock test) on one primary view.
- Give treasury, the CFO and the board different views of the same underlying data, not different numbers.
- Set refresh rates by exposure size and transaction volume, and make every number traceable to a source system.
- Alerts should fire on policy breaches and maturities, not on every market tick.
Table of Contents
- Start with the decision, not the chart
- Which exposures to display
- Presenting exposure, hedge coverage and potential loss so people can act
- Different views for treasury, the CFO and the board
- How often the data should refresh
- Alerts, access and audit trail
- Feeding the dashboard: sources and reconciliation
- What we would put on the first screen
- Our perspective
- Build it yourself or use a platform
- Common design mistakes to avoid
- FAQ
- Sources
Start with the decision, not the chart
Most dashboard design advice starts with colors and widgets. For FX risk that is the wrong end. The page you are building exists to support a decision process, and the best public description of that process comes from HM Treasury's 2023 guidance on managing foreign exchange exposure. It frames FX risk management as four steps: identify forthcoming foreign-currency payments and receipts, measure their budget impact against your risk tolerance, manage or reduce the risk when it exceeds that tolerance, and report total exposures.
The guidance is written for UK public bodies, but the logic carries over to a company's finance team. A dashboard can be built as four zones that mirror those steps:
| Step | Question the user asks | What the dashboard shows |
|---|---|---|
| Identify | What foreign-currency flows are coming? | Forecast receipts and payments by currency, entity and month |
| Measure | Does the impact breach our tolerance? | Budget-rate impact, Value at Risk, stress scenarios |
| Manage | What have we hedged and what is open? | Hedge coverage against policy, maturing contracts |
| Report | What is the total picture? | Consolidated exposure and hedge position, exportable |
If a widget does not serve one of these four questions, it belongs on a secondary page or nowhere. This is the single most useful filter in dashboard design, and it is what separates a risk tool from a market-data wall.
Which exposures to display
The same HM Treasury guidance separates direct and indirect cash-flow exposures from translation risk affecting reported assets and liabilities. A dashboard that shows only one type will mislead.
Transaction (cash-flow) exposure. Invoices, purchase orders and forecast flows in a currency other than your reporting currency. For a UK company reporting in sterling, that is every euro, dollar, Polish zloty or Swedish krona flow that will settle in the future. This is the core of the main view.
Indirect exposure. Costs that move with a foreign currency even though you pay in sterling, for instance a UK supplier who reprices when the dollar moves. It is harder to capture and is usually entered as an assumption, which should be labelled as such on screen.
Translation exposure. Foreign subsidiaries' assets and liabilities translated into your reporting currency. It does not move cash, but it moves reported numbers and sometimes covenant ratios, so it needs its own panel, visibly separate from cash-flow exposure. Mixing the two in one total is one of the most common design errors.
For each exposure, show three things together: the currency, the time bucket (month or quarter) and whether it is committed or forecast. Forecast flows carry uncertainty; committed ones do not. If the screen treats them identically, users will over-hedge or under-hedge without noticing.

Presenting exposure, hedge coverage and potential loss so people can act
This is where most designs fail. The data is usually there; the arrangement stops anyone acting on it.
The exposure ladder
The central chart should be a stacked bar by month for the selected currency: committed exposure, forecast exposure, and the hedged portion overlaid. A line shows the minimum and maximum coverage your policy allows for that horizon. Users should see within seconds where the bars sit outside the band. A table of numbers behind it is useful, but the picture is what spots the gap in month seven.
Hedge coverage against policy
A coverage percentage on its own is nearly meaningless. 60% hedged is fine for month nine and a breach for month two. Show coverage as a comparison against the policy target for each period, with a clear status (within, below, above). The HM Treasury guidance says an FX policy should define objectives, responsibilities, risks faced, identification processes and risk tolerance, among other things, so the policy limits you display should be traceable to a written document, not typed into a settings page by one person.
For guidance on which hedging figures deserve a place on screen, see our piece on the FX hedging metrics that belong on your dashboard.
Potential loss: Value at Risk and stress tests
HM Treasury defines Value at Risk as the maximum likely loss over a given period at a given confidence level, and describes the practical question as how much you would be likely to lose if exchange rates moved by, say, 1%. Two design rules follow.
First, always print the assumptions next to the number: horizon, confidence level and the data window. A VaR of £400,000 at 95% over one month is a different statement from the same figure at 99% over a quarter.
Second, pair VaR with a plain rate-shock table. VaR is a statistical estimate built on past behavior, so it can understate a sudden, unusual move. A table showing the effect on your budget of a 5%, 10% and 15% move in sterling against each main currency is blunt, but nobody misreads it. Show the unhedged result and the result after existing hedges side by side, so the value of the hedge book is visible.
We go deeper on how VaR can set hedge sizes on our page about hedging based on value at risk, and on the link between VaR, accounting treatment and settlement risk in portfolio FX hedging for CFOs.

One screen, one call to action
Every red status should lead somewhere: a click from a coverage breach should open the exposure that caused it and the hedge options already modeled. A dashboard that tells you something is wrong and then leaves you to open a spreadsheet has done half its job.
Different views for treasury, the CFO and the board
The numbers must be identical across views. What changes is the altitude.
| Audience | Main question | Content | Detail level |
|---|---|---|---|
| Treasury specialist | What do I trade or adjust today? | Exposure by entity and currency, maturing contracts, rate levels, scenario tools | Transaction level, drill-down |
| Finance director or CFO | Are we inside policy and what is the budget at risk? | Coverage vs policy, VaR, budget-rate impact, top three exposures | Currency and period level |
| Board or executive team | Is the FX effect understood and controlled? | One page: net exposure, hedge ratio, worst-case impact, key actions | Summary, trend over time |
Chatham Financial's experts argue that treasury teams should actively shape the FX story for the C-suite, using real-time dashboards to explain exposure in the context of the hedging program. That is a design brief as much as a communication tip: an executive view should explain what exposure exists and why the company hedges the way it does, not simply display a spot rate.
A practical test: show the executive view to someone outside treasury. If they cannot say, in one sentence, whether the company is in a comfortable position, the page has too many elements.
How often the data should refresh
There is no universal refresh rate, and promising one would be dishonest. HM Treasury's guidance says internal FX reports should use periods appropriate to transaction volume and exposure size. Apply that literally and separate the layers:
- Market rates: live or near-live, because they are cheap to refresh and users look at them for context.
- Exposure and hedge positions: as often as underlying systems update, commonly daily for active programs, weekly or monthly for small ones.
- Forecast flows: at the cadence of your forecasting cycle, with a visible "last updated" stamp.
A small importer with a handful of euro invoices a month does not need intraday position data. A company with hundreds of cross-border payments a week might. Put a timestamp next to every panel, so a user never mistakes a stale number for a current one.
Alerts, access and audit trail
Alerts are where good dashboards become tools. Keep the list short and tied to policy:
- Coverage falls outside the policy band for any period.
- A hedge contract matures within a set number of days.
- VaR or budget impact crosses the tolerance threshold.
- A rate crosses a level the team has set deliberately, such as the budget rate.
- A data feed fails or is out of date.
Alerts on every rate move train people to ignore them. Alert on breaches and deadlines.
On access, separate who can view, who can propose a hedge and who can approve one. The HM Treasury guidance stresses defined responsibilities within policy, and the dashboard should reflect that: role-based permissions, and a log recording who changed an input, a limit or a forecast, and when. This audit record is what makes numbers defensible when an auditor or board member asks where a figure came from.
Feeding the dashboard: sources and reconciliation
A dashboard is only as good as the data under it. The typical sources are:
- the ERP or accounting system, for receivables, payables and orders;
- forecasts from sales, procurement or FP&A, often in spreadsheets;
- hedge confirmations and trade records from your banks or providers;
- market data for rates and volatility.
Three habits keep it trustworthy.
Agree definitions first. Finance, treasury and the controller must use the same categories for exposure types, entities and time buckets. Most disagreements about "the number" are really disagreements about definitions.
Reconcile on a schedule. Compare the hedge positions on screen with counterparty confirmations, and the exposure totals with ledger balances. Show reconciliation status on the dashboard itself: last run, number of breaks, owner. A silent mismatch is worse than a visible one.
Show provenance. Every figure should open to the underlying items and the system they came from. Where a number is an estimate or manual input, mark it.
What we would put on the first screen
If you are designing from a blank page, this layout works for most mid-sized companies:
- Top strip: total net exposure in reporting currency, hedge ratio against policy, VaR with its assumptions, and data freshness.
- Left, main area: exposure ladder by month with hedge overlay and policy band.
- Right: breaches and upcoming maturities, ranked by urgency.
- Bottom: rate-shock table, then currency breakdown.
- Second tab: translation exposure by subsidiary.
- Third tab: reports and audit log.
Use color only for status. Currency pairs should not each have a color of their own; that spends your color budget on identity when it is needed for warnings. Prefer tables where users compare exact numbers and charts where they look for shape.
Our perspective
We see the same failure repeatedly: companies buy or build a screen full of live rates and call it risk management. Rates are the least useful thing on an FX dashboard, because they tell you what the market is doing, not what it means for your margins.
The design that works starts with exposure and policy. Know what you owe and expect to receive in each currency, decide how much uncertainty you can live with, and let the screen tell you plainly when you have drifted outside that. Value at Risk is useful for this, as long as the assumptions are visible and a simple stress table sits beside it.
This matters more as a business spreads across currencies. A UK company that adds Polish or Swedish customers or suppliers adds złoty and krona exposure to its euro and dollar flows, and the number of exposure lines grows faster than the team does. We are expanding into Poland and Sweden ourselves, and we expect that kind of multi-currency growth to be common for companies trading across those markets. Simplicity becomes a requirement then, not a preference.
— Bartas
Build it yourself or use a platform
Many teams begin with a spreadsheet and a market-data page, and for a few exposures that is reasonable. The strain shows when forecasts live in several files, hedges are recorded by hand and nobody can say who changed a cell. At that point the cost is not the subscription you avoided; it is the time spent rebuilding the picture before each meeting.
The Corphedge platform is built for this stage. It brings currency position tracking, hedging strategy simulation, Value at Risk analysis, portfolio reporting, live market data and automated notifications into one place, and it connects with the Corpay integration. If your team also needs to build in-house understanding of the subject, our FX hedging course is a €220 one-off purchase. For a broader view of the topic, start with our page on foreign exchange risk management.
Common design mistakes to avoid
- Mixing exposure types. Transaction, translation and forecast exposure in one total hides which risk you are actually hedging.
- Coverage without context. A single hedge ratio hides gaps in specific months.
- VaR without assumptions. An unlabelled number invites false comfort.
- Too many live widgets. Moving numbers draw the eye away from slow-moving but important gaps.
- No timestamps. Users cannot judge whether a figure is current.
- Executive view as a simplified copy of the trader view. It needs its own purpose: confidence and control, not detail.
- No link from alert to action. Warnings that lead nowhere get ignored.
If you want a process to run alongside the dashboard, our four-week executive FX checklist shows how a CFO can review exposure on a regular rhythm, and our guide to cash flow hedging programs explains how coverage targets are set by horizon.
FAQ
What should an FX risk dashboard show first?
Net exposure by currency and period, hedge coverage against your policy limits, and potential loss. These map to the identify, measure and manage steps in HM Treasury's FX guidance. Live rates can sit in a corner for context.
How often should an FX dashboard update?
It depends on your exposure size and transaction volume, which is the principle HM Treasury applies to internal FX reporting. Market rates can be live, while exposures and hedges usually update daily or at the pace of your source systems. Whatever the rate, show a timestamp on each panel.
Is Value at Risk enough on its own?
No. VaR gives a likely maximum loss at a chosen confidence level and horizon, but it relies on past behavior. Pair it with simple rate-shock scenarios, such as a 10% move in sterling, so decision-makers can see outcomes beyond the statistical range.
Who needs access to the dashboard?
Treasury, finance leadership and the board need different views of the same data. Separate view, propose and approve permissions, and keep a log of changes to inputs and limits so figures can be explained later.
Sources
- Guidance for the Management of Foreign Exchange Exposure, HM Treasury (March 2023)
- FX Dashboards: Essential Tool to Manage the Volatility Narrative, Chatham Financial
