Predictive Forecasting Engine

Overview

HSBC’s treasury operations span 40+ markets. Each market produces daily cash flow data that finance teams use to manage liquidity positions, hedging decisions, and inter-company transfers. Before this project, that process was largely manual — spreadsheets, overnight batch jobs, and a significant amount of analyst time spent reconciling data rather than acting on it.

The Predictive Forecasting Engine was built to automate the reconciliation layer and surface AI-generated cash position forecasts directly to the analysts and treasury managers who needed them. I led the UX for the 14-month build, from initial discovery through to post-launch optimisation.

Business Context

The strategic driver was regulatory. Basel IV requirements placed new demands on HSBC’s intraday liquidity reporting. The business needed more accurate, more frequent visibility of cash positions across markets. The existing process could not scale to meet those requirements without a significant increase in headcount.

The product was also strategically positioned as a demonstration of HSBC’s internal AI capability — it would be reviewed by group-level leadership as evidence that AI could be deployed responsibly in regulated financial processes.

Problem

The core challenge was trust. Treasury analysts were highly numerate professionals who understood cash flow deeply. The product was asking them to rely on AI-generated forecasts for decisions that had real financial consequences.

The initial prototype, built by the engineering team before I joined, presented forecasts as single numbers. Analysts rejected this immediately. A single number without context — no confidence range, no methodology visibility, no audit trail — was not actionable in a regulated environment.

The problem I was hired to solve: how do you make AI-generated financial forecasts legible and trustworthy to expert users who are held accountable for the decisions those forecasts inform?

Constraints

• FCA and internal risk frameworks required every forecast to have a documented basis. The UX had to make audit trails accessible without making them the primary focus
• Data latency varied significantly across markets. The design had to represent forecast reliability without obscuring which markets had stale inputs
• The model was updated daily. Analysts needed to understand when a forecast had changed and why
• The product would be used across multiple seniority levels — junior analysts needed guidance; senior treasury managers needed summary views with drill-down access
• We were building on an internal enterprise platform with strict component library requirements

Research

I led a 6-week discovery phase with the research lead. We conducted:

• 24 contextual interviews with treasury analysts, cash managers, and treasury directors across 5 markets
• A workflow mapping exercise that traced a single day’s reconciliation process end-to-end
• A review of existing spreadsheet models to understand what signals analysts currently used

Key findings:

Treasury analysts had developed highly sophisticated mental models of their market’s cash behaviour. They didn’t need the AI to explain cash flow fundamentals — they needed it to flag anomalies, explain its reasoning when a forecast differed from their expectation, and give them confidence that the data feeding the model was current and complete.

Senior treasury managers had a different need: they wanted exception-based views. They did not want to review every market daily — they wanted to know which markets needed their attention and why.

Insights

Insight 1: Analysts need explainability, not transparency. Showing the model’s weights would not help analysts. Showing which inputs drove a material change in a forecast — in language they recognised — would.

Insight 2: Data freshness was as important as forecast accuracy. An accurate forecast based on stale data was worse than no forecast. The design needed to communicate data source age prominently, not as a footnote.

Insight 3: Exception-based navigation was essential for senior users. Designing a chronological market list was wrong. Senior users needed to arrive at the product and immediately know where to focus.

Product Thinking

The product team’s initial framing was “a dashboard that shows cash forecasts.” I pushed to reframe it as “a tool that helps treasury professionals make better decisions faster.”

This distinction changed what we prioritised. A dashboard optimises for information display. A decision tool optimises for the actions that follow. The difference showed up in:

• Designing forecast change explanations as the primary content, not a secondary panel
• Adding a recommended action layer that surfaced hedging or transfer suggestions based on forecast position
• Building the exception view as the primary entry point for senior users, not a filter applied to a full list

The recommended action layer was the most contested feature. Legal required every recommendation to be prefaced with a disclaimer. Risk required a review process for each recommendation category. The PM wanted to ship without it. I argued that without it, we were building a forecasting tool that required analysts to do the same cognitive work they currently did, just with better input data.

We shipped a constrained version: flagged positions rather than explicit recommendations, with a link to the relevant hedging policy. Not the full vision, but a meaningful step.

Key Decisions

Decision: Show confidence intervals as visual ranges, not percentage scores. Testing showed analysts interpreted percentage confidence scores as reliability guarantees. Ranges better represented genuine uncertainty and aligned with the probabilistic language analysts already used internally.

Decision: Data freshness indicator on every forecast card. Some markets had data pipelines that fed the model every 2 hours. Others updated once daily. We made this visible at the forecast level, not buried in a data provenance section. An amber or red freshness indicator was a signal to verify before acting.

Decision: Design the audit trail as a collapsible timeline, not a separate report. Compliance required every forecast to have an accessible audit trail. The instinct was to build a separate “Audit” section. I pushed for it to be accessible directly from the forecast card — one click, not navigation to a different screen. Analysts were more likely to reference it, and it felt like part of the decision flow rather than a compliance afterthought.

Design Process

The design went through four major phases:

Phase 1 – Structure: Information architecture workshops with the product team and senior analyst stakeholders. We tested three IA approaches with 8 analysts before settling on an exception-first entry point.

Phase 2 – Forecast card design: Six rounds of iteration on the core forecast card — the unit analysts would interact with most. Key iterations: confidence representation, change attribution, data freshness, and one-click audit access.

Phase 3 – Role-based views: Separate design tracks for analyst and manager views. The manager view was a significant reduction in complexity — aggregated market positions, exception highlights, and a single drill-down path.

Phase 4 – Edge cases: High data latency states, model update transitions, market holiday handling, and the zero-data state when a market was offline.

Validation

We ran three rounds of moderated usability testing with analysts and treasury managers from two markets. Key outcomes:

• Round 1 revealed that analysts were not noticing the data freshness indicator — it was too subtle. We moved it to a more prominent position and added colour coding.
• Round 2 revealed that the confidence interval representation was misunderstood by junior analysts — they thought the range represented the possible forecast values, not the uncertainty around the central forecast. We added a plain-language explanation on hover.
• Round 3 validated the core flow. All 9 participants completed the primary task (review a flagged position, understand the basis for the forecast, and decide whether to act) without facilitator assistance.

Final Solution

The Predictive Forecasting Engine has two primary entry points:

Exception view (default for managers): A ranked list of market positions that require attention, sorted by variance from expected position. Each item includes the forecast, the direction of change, the primary driver, and a confidence indicator.

Market view (default for analysts): A detailed view of a single market’s cash positions across a 30-day rolling horizon. Includes forecast timeline, confidence bands, data freshness indicators, change attribution, and one-click audit trail.

Both views are connected — managers can drill from an exception into the full market view, and analysts can escalate a flagged position to a manager directly from the interface.

Collaboration

The most challenging collaboration was with the data science team. They were confident in the model’s accuracy but reluctant to expose uncertainty explicitly — their concern was that showing a confidence range would undermine trust in the AI.

I ran a small experiment: I showed treasury analysts two versions of the same forecast — one with a single number, one with a confidence range. Analysts trusted the range version more, not less. Showing uncertainty was a signal of rigour, not weakness. The data science team accepted the finding.

I also worked closely with compliance and legal throughout. Rather than treating their requirements as constraints to design around, I framed accessibility of audit information as a product feature. This changed the dynamic — they became advocates for the audit trail design rather than requesters of a compliance checkbox.

Influence

I extended my remit beyond the primary product by identifying that the exception-based navigation model we’d built was applicable to three other risk monitoring tools the team was building. I wrote a short design brief articulating the exception-first pattern and presented it to the design practice lead.

Two of the three subsequent tools adopted the pattern. The third went in a different direction due to different user needs — which was the right outcome.

Outcomes

Post-launch data from the first 3 months:

• 60% reduction in daily reconciliation time across pilot markets
• 92% forecast accuracy within 5% tolerance on a 30-day horizon
• Average of 3 hours saved per analyst per day
• Zero compliance incidents related to the forecast audit trail

The product received a positive internal audit review — the first AI-enabled tool in the treasury division to pass without a remediation request.

Failure and Risk

The recommended actions feature shipped in a constrained form. I think we could have shipped more if we had started the legal and risk review process earlier. By the time we had validated the design with analysts, the compliance review timeline left no room to iterate based on their feedback.

The exception view for managers was initially too aggressive — it surfaced too many exceptions and created alert fatigue in the first two weeks. We recalibrated the threshold based on manager feedback, but it should have been configurable from the start.

Reflection

The biggest shift I made in this project was learning to treat expert users’ scepticism as design input rather than an obstacle. Treasury analysts pushed back on almost everything in early testing. Rather than softening the design to reduce pushback, I treated every piece of resistance as a signal about what they actually needed.

The result was a product that felt like it had been built by people who understood finance, not by technologists who thought finance was simple. That credibility was hard to earn and, I think, the real reason the tool was adopted.