OmniRisk

AI-enhanced dashboard for FX repatriation — designed for middle office treasury teams.

Middle office analysts manage the fund's treasury operations — workflows that run manually, delaying timing, compounding reconciliation errors, and forcing trade decisions without forecast data. I designed the dashboard that makes AI recommendations trustworthy enough for experienced operators to use. This is a workflow I ran weekly for over a decade in institutional trading operations.

Client

Independent Project · Instl Fintech

Year

2025

Platform

Web, Tablet

Timeline

10 weeks

Context

Every week, hedge funds with foreign currency exposure convert back to base currency — the workflow called FX repatriation. The middle office analyst running it has to pull files from prime brokers, reconcile positions across systems without integration, and time the conversion against rate forecasts.


The platforms built for this workflow were designed for institutional buyers, not analyst operators. Bloomberg surfaces rate data; Aladdin handles allocations; Enfusion runs the OMS — but none of them sit inside the repatriation workflow itself. The analyst is the integration layer.


A failed repatriation cycle doesn't just create accounting noise — it can cost a fund millions in FX conversion errors and trigger reconciliation breaks.

The Problem

Three things make this problem difficult to solve:


It is structural, not cosmetic. A better spreadsheet is still a spreadsheet. The tools in this space were built for institutional scale — not for the analyst who needs to run repatriation this week, accurately, with the tools on their desk.


The users are sophisticated skeptics. These are professionals who have spent years building workarounds that function. They know where the workflow breaks. Any solution that could not explain itself, audit itself, and defer to their judgment would be rejected, correctly.


AI makes it harder before it makes it easier. The features most likely to improve outcomes — automated reconciliation, predictive rate forecasting, AI-timed execution — are the features most likely to generate resistance without transparency. The design challenge is not whether to include AI. It is how to make it trustworthy enough to use.

Research

FX repatriation has no single owner. It passes from middle office preparing the data, to the trader executing against rate forecasts, to the systems team maintaining the connections that make any of it work. I interviewed four people across those handoffs. Four findings shaped every decision that followed.

The four findings that shaped everything:


1. The platforms weren't built for the analyst running the workflow. The platforms in this space were built for institutional buyers — banks, custodians, asset managers with IT teams and enterprise budgets, not the analyst running repatriation. Alex described running reconciliation in Excel against Bloomberg data that doesn't integrate. Sarah confirmed the same pattern at startup scale, where macro-based Excel sheets sped up data capture but couldn't replace the manual workflow underneath. Michael identified the systems reality beneath both: proprietary software that doesn't scale, integrations kept alive through reactive maintenance.

"Bloomberg is great for providing accurate, real-time market data, but it doesn't integrate with our internal systems. Excel is our primary tool for reconciliation, but it's far from ideal — it's slow, prone to errors, and doesn't scale well."

Alex Johnson, Middle Office Analyst, Hedge Fund

2. Trade timing is the highest-stakes, least-supported decision. The timing problem isn't experience versus data — it's that the data infrastructure operates on a timing delay. Alex traced the mechanics: FCM rate data captured on negotiated weekly schedules, cross-referenced against Bloomberg in Excel, reconciled T+1. Elena named the consequence: narrow execution windows in volatile markets, where the rate she's executing against may already be stale. The insight and the action live in separate tools, on different clocks.

"Delays in communication with the middle office are the biggest bottleneck. It's hard to act quickly when I don't have immediate visibility into account balances or reconciliation statuses."

Elena Rodriguez, FX Trader, Hedge Fund

3. AI is acceptable if it is explainable and controllable. Four roles converged on the same condition. Elena named the bar from the front office: she would use AI for rate forecasts, but only if she could verify each prediction manually. Michael set the bar from the systems vantage: AI is promising, but only paired with audit trails and traceable outputs. Alex and Sarah arrived at the same condition from the middle office side — transparency, override capability, and auditability weren't features they wanted, they were conditions for adoption.

"AI is promising, but it must be paired with clear audit trails and error handling mechanisms."

Michael Lee, Head of IT, Custodian Bank

4. Audit trails are a compliance burden, not a workflow tool. Documenting each step of the repatriation cycle is a regulatory requirement. Currently it depends on each analyst recording everything correctly under time pressure — and when they don't, the gap becomes a compliance risk. Alex and Michael both surfaced audit trail traceability as non-negotiable — one from the analyst's documentation burden, one from the regulatory compliance side.

Design Decisions

The research set the bar: transparency, manual override, and auditability as conditions for adoption. OmniRisk meets that bar through an AI recommendation engine that forecasts conversion timing and surfaces its confidence — and I designed what that engine must reveal and how the user stays in control, not the model behind it.


Six decisions shaped OmniRisk. The three that determined whether skeptical operators would trust the AI are examined first; three more shaped the workflow around them.

Sequential CTA Button Flow


The decision: Enforce a sequential button flow — Fetch FCM → Continue to AI Processing → Run AI Analysis → View Insights — where each button activates only when the preceding step is complete.


The alternative considered: All four actions available at once, with the user managing the sequence.


Why sequential won: At a hedge fund, FX repatriation lives across disconnected systems — no single dashboard, every step done by hand. The sequential flow pulls those steps into one orchestrated path: fetch, normalize, analyze, recommend. The order isn't there to guide the user; it reflects real dependencies, and enforcing it prevents out-of-sequence actions that would produce a wrong-but-believable output, not an obvious error. The AI recommendation is the one step the manual workflow never had — surfaced at the moment of decision, not in a separate tool to consult on the side.


Research connection: Alex described the current workflow as a sequence of dependent steps. The button structure mirrors that sequence and makes the dependencies explicit.

Confidence Scores in the Modal, Not the Table


The decision: Surface AI confidence scores and reasoning in the AI Insights modal — a deeper snapshot into each recommendation — rather than as columns in the Currency Trade Table.


The alternative considered: Confidence and explanation columns added directly to the Currency Trade Table.


Why the modal won: The badges are the job: repatriate, monitor, or hold tells you which positions need action. Those guidelines are set upstream — by committee, against the fund's investment strategy — so the badge is a trigger to act, not a recommendation to second-guess. The granular reasoning belongs a layer down: when the user clicks Execute on a row, the AI Recommendation modal opens with the detail — confidence, rationale, the why behind the badge — before they commit. The table stays fast for triage; the modal goes deep for the decision they're about to commit.


Research connection: Elena wants to verify predictions before acting. Alex needs full transparency. The modal serves both without slowing either down at the action layer.

Manual Override as a First-Class Feature


The decision: When the user clicks Execute on a row in the AI Recommendations table, the AI Recommendation modal opens — pairing Manual Override with Accept AI Recommendation as two equally visible buttons at the bottom.


The alternative considered: Burying override behind a secondary menu, settings toggle, or "advanced" mode.


Why first-class override won: Catching errors is the job. In reconciliation against internal controls, a spot trade can post in error, and it's on middle office to catch it — so override has to be available at the decision moment, not later in the flow. Pairing it with Accept at the bottom of the modal signals what the design assumes: the AI recommends, the operator decides. Because an override updates the fund's PnL, the analyst flags the corrected trade, it routes through manager approval and compliance sign-off, and front office executes it.


Research connection: Manual override was the one condition every participant who discussed AI named — the same bar the research set.

Widget-based dashboard architecture Configurable drag-and-drop layout instead of fixed tabbed navigation, so Alex can manage reconciliations while Elena prioritizes rate forecasts — without either adapting to the other's view.


Alternative: tabbed navigation with fixed pages per workflow.


Research: every participant requested customizable dashboards.


In-table highlighting for AI recommendations Recommended trades highlighted within the full data table, not pulled into a separate panel, so the user sees flagged currencies against the ones that weren't — and why one balance triggered a recommendation while others didn't.


Alternative: a separate "Recommended Trades" panel showing only AI-flagged rows.


Research: Alex requested data shown in context; the principle extends to AI output.


Automatic audit trail generation The system records each step as the workflow runs, instead of relying on the analyst to document manually under time pressure.


Alternative: manual logging, the current-state status quo.


Research: Alex relies on audit trails for compliance — but only if every step was recorded correctly by hand.

Testing & Outcomes

Each design decision was a hypothesis. Usability testing was where they got tested — moderated and remote, think-aloud, with a post-task survey. The three operators who run the workflow took part: Alex, Sarah, and Elena. Michael's systems view shaped the research, but the prototype serves the people doing fund administration.

What held up:

  • Sequential flow: all three navigated it without instruction or a wrong path; disabled states read correctly on first contact.

  • Loading states: read as the system working, not stalling — a contrast all three drew against tools that give no feedback.

  • Highlighted rows: identified as AI recommendations by all three, no legend needed.

  • The modal: trust in the recommendations rated 4.3/5 after use, with participants describing more confidence once the reasoning was visible.

What didn't hold:

  • The sequential flow's disabled states were supposed to carry the whole load. They didn't. Two of three hesitated at the pipeline's intermediate state — uncertain whether processing had finished. Users needed more than disabled buttons to know where they were in the full sequence.

  • Confidence scores were supposed to be interpretable on sight. They weren't. The same 78% read as "high" to one participant and "moderate" to another — no shared frame, no calibration.

  • "More Details" was supposed to draw users in. They didn't reach for it. Only one of three opened the expansion spontaneously; the other two valued the idea but didn't engage on first contact.

What changed:

  • Step Progress Indicator in the CTA group. Added "Step 1 of 4" labeling alongside the disabled-state pattern, so the buttons communicate position in the sequence, not just what action is available now. Answers the pipeline hesitation: users now see where they are in the full flow, not just which button is active.

  • Confidence score legend in the modal. Low / medium / high bands with percentage ranges, so the same 78% reads consistently across users. Answers the calibration gap: the scale is named, the score has a shared reference frame.

  • "More Details" relabeled to "See AI reasoning." Names what the expansion actually contains, not the fact that it expands. Answers the underuse: the label now signals value, not just presence.

What surfaced for scope: Elena flagged mobile access unprompted — execution monitoring during volatile sessions doesn't always happen at a desk. Out of scope for this prototype, kept for the roadmap.

Reflection

What I Would Do Differently


Test the AI trust layer earlier in the process. I validated the AI recommendation presentation late — after the design was largely complete. The trust questions from interviews were rich enough to support concept testing much earlier, on a low-fidelity modal. Earlier signal on the confidence score issue alone would have saved iteration time.


Push harder on the Execution & Confirm flow. The first two flows — Data Aggregation and AI Recommendation — received the most attention because they were most visible in testing. But Execution & Confirm is the highest-stakes part of the workflow: the moment a user commits real money based on AI guidance. It deserved equal design rigor from the start.


Interview a compliance officer. Four participants covered the operational and technical dimensions of the workflow well. But the compliance layer — audit trails, AML, FATCA, internal policy adherence — was represented secondhand through Michael. A direct conversation with a compliance officer would have sharpened the audit trail requirements and surfaced constraints I may have designed around incorrectly.

What the Project Taught Me


Trust is a design material, not a user education problem. Trust isn't built by explaining AI — it's built by designing for the moment when users decide whether to act on it. The difference between a confidence score that reads as useful and one that reads as noise isn't how much information it contains; it's whether it answers the question the user is actually asking.


Sequential workflows need explicit position markers. The sequential CTA flow was the right structural decision, but disabled states alone weren't enough to keep users oriented. People need to know where they are in a sequence, not just what they can do next. "Step 2 of 4" is a small addition with significant effect on user confidence.


The widget architecture creates a design debt. The widget dashboard was the right choice for customizability, but it leaves a question I didn't fully answer: what does the default configuration look like for a new user? The layout I designed reflects the middle office persona — a front office or startup user would land in a dashboard that doesn't yet fit. Onboarding and first-run configuration are a design problem for the next phase.


Fintech UX requires designing for two kinds of uncertainty. Market uncertainty — will the rate move? — and system uncertainty — is the AI right? — are both present in this workflow, and they interact. A user already uncertain about market conditions is more sensitive to system uncertainty. Designing the AI layer to reduce system uncertainty also helps users manage market uncertainty — a connection I didn't see at the start.

What I'd Explore Next


A/B test the confidence score presentation. Testing surfaced that confidence scores needed a legend. The broader question I didn't answer: does quantitative scoring (78%) build more trust than qualitative labeling (High / Medium / Low)? Alex may want the number, Sarah may prefer the label — A/B testing would give real signal.


Design the reconciliation widget at the same depth as FX repatriation. Automated reconciliation was the most consistently requested feature in research, but in this project it was scoped as a widget rather than designed at depth. The reconciliation widget deserves its own sequential workflow: matching, exception review, resolution, audit trail. A full design problem in its own right.


Explore the front office dashboard configuration. Elena's needs — rate forecasts, execution status, middle office visibility — are well defined from research, but I designed primarily for the middle office persona. A front office configuration built from Elena's POV would test whether the widget architecture is genuinely flexible enough to serve both personas.

Final Thought

OmniRisk is a product designed for people who do important work with inadequate tools. The weekly FX repatriation cycle is repetitive, precise, and consequential — it happens quietly in funds most people outside finance have never heard of. The users who manage it are skilled professionals working around infrastructure gaps the market never solved for them.


The most meaningful thing a design can do for those users is not impress them — it is get out of their way. Every decision in OmniRisk was made in service of that: reduce friction, surface what matters, explain the reasoning, and always let the user be the one who says yes.

View Prototype

Next

FXpress ›