A Risk Dashboard That Explains Itself
A good dashboard answers the question 'what is happening'. The trouble is that the people looking at it are usually asking a harder one: 'so what, and what should I do about it'. I built my retail-banking risk dashboard to close that gap, to take a clean view of credit risk and revenue and add the layer most dashboards leave to a human analyst: the interpretation.
Where dashboards usually stop
Most analytics work ends at the chart. You wrangle the data, choose a sensible visualization, and ship a screen full of bars and lines. It looks rigorous, and for someone fluent in the numbers it genuinely is useful. But hand the same screen to a busy executive and you have quietly outsourced the hardest step, turning the pattern into a decision, to the person with the least time to do it.
I wanted the dashboard to carry more of that weight. Not to replace judgment, but to offer the first draft of an insight the way a sharp analyst sitting beside you might: default risk is creeping up in this segment while revenue holds, so margins are thinning exactly where you can least afford it.
The stack
The application itself is deliberately lightweight and fast.
- React with Vite for a quick, responsive front end.
- Tailwind CSS for a dense, bank-grade interface that stays legible under a lot of information.
- Recharts for the visualizations, which kept charting declarative and easy to wire to live state.
- Groq running Llama 3.3 as the reasoning layer behind the AI analyst.
Vite mattered more than it sounds. A risk dashboard lives or dies on how quickly you can read it, and a snappy build with instant interactions is part of that feeling of trust. Sluggishness reads as unreliability even when the numbers are perfect.
An analyst that reads the screen
The core idea is simple to describe and was fiddly to get right: the AI analyst does not run on stale, pre-baked data. It reads the same live metrics the charts are rendering and generates its commentary from those exact numbers. When the data on screen changes, so does the interpretation.
To make that work I treated the chart state as the single source of truth and fed a structured snapshot of it to the model, the metrics, the segments, the direction of travel, then asked for an executive-level reading. Keeping the model anchored to the real on-screen figures, rather than letting it free-associate, was the difference between a feature people trusted and a party trick.
Prompting for executives, not for me
Writing the prompt was an exercise in restraint. My instinct as a builder is to ask for completeness; an executive wants the opposite. I tuned the analyst to lead with the implication, keep it to a few sentences, name the segment and the direction clearly, and avoid hedging itself into uselessness. A paragraph that says risk may or may not be rising depending on various factors is worse than no paragraph at all.
I also made it say when the data did not support a strong conclusion. An analyst who only ever sounds confident is one you stop believing. Letting the model occasionally say nothing here looks alarming this period made the times it did raise a flag land much harder.
Trust is a design problem
The recurring theme across this project was that the technical work was the smaller half. The bigger challenge was making people comfortable acting on a sentence a model wrote. That is a design problem as much as an engineering one: ground every statement in visible numbers, keep the tone calm and specific, and never let the insight drift away from what the user can see for themselves.
The chart shows you the number. The analyst tells you why it matters. Most dashboards ship the first and quietly hope someone is around to do the second.
Building this changed how I think about data work in general. The visualization is necessary, but it is not the deliverable. The deliverable is a decision made well, and anything that shortens the distance between a chart and that decision, including a careful and honest AI analyst, is worth building.