Citi Trade Platform · FX Processing
Outcome: designed a unified FX workbench that brings entitled-currency conversion, invoice-currency payment, rate visibility, and approval context into one payment queue.
The concept addresses a recurring enterprise problem: corporate trade clients managing international payments across regional accounts, currencies, and changing rates. The design makes the 15-minute lock understandable at the moment money is committed.
Design scope and example data shown above; production impact is separated and labelled below.
| □ | Invoice currency | Amount | Conversion currency and live rate | FX converted amount |
|---|---|---|---|---|
| ☑ | USD | 25,075.00 | ✓ 0.9215 EUR1.0000 USD0.7887 GBP6.8717 DKK | 23,100.61 EUR |
| ☑ | EUR | 36,199.00 | ✓ 1.0000 EUR1.0852 USD0.8559 GBP7.4571 DKK | 36,199.00 EUR |
| □ | GBP | 37,677.98 | ✓ 1.1684 EUR1.2683 USD1.0000 GBP8.7130 DKK | 44,023.47 EUR |
Everything a recruiter needs to orient before reading the reasoning.
I owned the research synthesis, task flows, information architecture, wireframes, interaction model, prototype direction, and stakeholder validation plan. I partnered with product on scope, with trade operations and risk on business rules, and with engineering on feasibility and state handling.
Lead product designer on the FX processing experience.
Trade platform product, treasury operations, risk, engineering, implementation, initiators, and checkers.
Discovery → synthesis → concept design → stakeholder validation.
Enterprise web application within Citi’s trade platform and ICG design language.
15-minute rate refresh, account-level currency entitlement, approval controls, high-volume queues, and confidentiality.
One decision surface for conversion and invoice-currency payment, with rate, eligibility, and approval context visible.
I triangulated the product brief, the supplied reference screens, and secondary research. That helped separate what was known from what needed validation—and kept the problem grounded in the moments where operational coordination becomes user risk.
The stated problem was operational inefficiency, delayed payments, and unpredictable exchange-rate exposure when cross-border trade payments required regional hand-offs.
Observed input: supplied project briefThe screens show total-payment visibility, equivalent amounts, entitled conversion currencies, a 15-minute refresh timer, and a separate invoice-currency mode.
Observed input: supplied FX processing screensBIS, FSB, and ICC research provided ecosystem context for why rate traceability, fewer hand-offs, and clearer payment states matter.
Secondary evidence: linked sources belowProblem statement
How might we let entitled trade clients convert and pay from the account they already use—without losing confidence in the rate, eligibility, or final payment amount?
Confidentiality-safe portfolio reconstruction based on the supplied FX processing screens and problem brief.
Understand the full payment queue and equivalent value before choosing a target currency.
Know what is available for this account and avoid a late-stage rejection or regional workaround.
Use a clear 15-minute lock, a visible refresh moment, and a recoverable expiry state.
Keep the invoice flow available as a deliberate second mode, not a hidden exception.
The research plan combined desk research with workflow walkthroughs and stakeholder alignment. The key was to study the moments where operational coordination turns into user risk: account eligibility, rate freshness, conversion choice, and approval hand-off.
The BIS 2022 Triennial Survey reported average daily FX turnover of $7.5 trillion in April 2022. That scale makes clarity and traceability product requirements, not decoration.
BIS desk research ↗The Financial Stability Board frames the global challenge around cost, speed, access, and transparency—the same dimensions that surfaced in the FX workflow brief.
FSB desk research ↗An ICC survey signal found that many banks were moving toward digitalisation, while far fewer reported efficiency gains. The implication: remove hand-offs, not just paper.
ICC desk research ↗Regional bank accounts create extra coordination work and make “where is the money?” a recurring question.
Users need a decision window, not a market lesson: what is locked, until when, and what happens next?
Currency availability changes by account and user. A visible eligibility model prevents surprise failure.
Users reason about invoice amount, converted amount, value date, and approval as one job.
Instead of clustering by feature request, I grouped findings by the confidence gap they created. Each cluster ends in a product implication so synthesis can move directly into prioritisation.
Design implication: make rate age, lock state, expiry, and audit details persistent.
Design implication: bring conversion into the payment queue and carry context into approval.
Design implication: show entitled currencies at the point of choice and preserve a no-conversion path.
Design implication: pair portfolio summary cards with a dense, scannable matrix and review drawer.
Each decision connects a finding to a choice. I considered the simplest possible change, then chose the direction that reduced ambiguity for users and made the system rules discussable for product, risk, and engineering.
Learned: A user needs to know whether the selected rate is still actionable—not just see a rate number.
Considered: Hide the timer until confirmation; refresh silently; or keep the lock state persistent.
Chose: A visible countdown, rate snapshot, refresh boundary, and explicit expired state.
Changed: Rate freshness became a primary part of the workbench instead of a backend detail.
Learned: Not every payment needs conversion; hiding invoice-currency payment would create unnecessary work.
Considered: Separate screens; one overloaded table; or a shared queue with a clear mode switcher.
Chose: FX conversion and pay-in-invoice-currency as two explicit modes over the same payment data.
Changed: The user can preserve the invoice currency without leaving the context of the payment queue.
Learned: The initiator and checker need the same currency, amount, rate, and total context.
Considered: Row-level action only; a confirmation toast; or a selected-payment review drawer.
Chose: Entitled currency choices in the matrix plus a grouped summary before submission.
Changed: The conversion action became a reviewable payment decision, not a one-click mutation.
The solution combines a portfolio-level summary, transparent rate movement, a currency conversion matrix, and a review drawer. The user can act at row level or in bulk while the system keeps eligibility and rate state visible.
See total payments and equivalent value across entitled currencies.
Pick the target currency from the row-level rate pills or use the invoice mode.
Confirm the rate snapshot within the 15-minute window.
Review grouped totals and send the request for checker authorisation.
Use when the invoice is in one currency but the account user needs to pay from an entitled account currency. Each row exposes the same target-currency choices and the resulting FX amount.
Use when the account can pay the invoice currency directly. Keep the same queue, metadata, selection, value date, asset ID, and approval behaviour.
Rate and converted amount are held for the active selection.
Refresh boundary is explicit; users can reselect without losing the payment context.
Disable submit, explain why, and offer a single “Refresh rates” recovery action.
The final experience is designed around a realistic job: pay a mixed-currency queue without moving funds to a regional bank or losing track of the rate used.
| Conversion currency and live rate | PI Details |
|---|
Try the prototype: switch payment modes inside the workbench, click any currency account or graph, select rows, choose conversion currencies, sort table labels, search Asset IDs, and review the submission. Rates and all four graphs continue changing within the 15-minute lock.
What changed in the design
Rate lock, entitlement, conversion math, invoice mode, and approval are all treated as first-class interaction states. This turns a complex matrix into a confident decision surface.
Testing is not only a usability exercise here. The prototype needs to align treasury operations, trade product, implementation, risk, engineering, initiators, and checkers on what the timer means and where entitlement is enforced.
Run three focused rounds, each with a different decision owner. Use the prototype to test comprehension, system rules, and operational fit—not just click paths.
Ask the participant to select the right target currency, review the aggregate, and submit within the active lock period.
“Which rate is used?” “Why is this currency selectable?” “What changes at the next refresh?” “Can I pay without conversion?”
Time to first confident selection, wrong-currency attempts, rate-lock explanation accuracy, recovery success, and stakeholder acceptance of the approval summary.
No quantitative production results were supplied, so I’m separating the validated design outcomes from the metrics I would instrument in a pilot. That makes the case study credible without overstating impact.
Accounts involved in the conversion journey.
Places needed to see, convert, and review a payment.
Freshness, lock state, expiry, and rate detail are explicit.
FX conversion and invoice-currency payment share one model.
Use this as a measurement plan in the interview: baseline the current workflow, then compare a controlled pilot with the unified workbench.
The strongest design move was treating FX as a confidence problem, not a currency calculator. The constraint that rates change every 15 minutes pushed the experience toward explicit state, recovery, and auditability.
External sources ground the problem space. Product-specific findings, wireframes, and targets are presented as a portfolio reconstruction based on the supplied brief and reference screens.