FXpress
AI Co-Pilot for Cross-Border Remittance
Code computes. Claude narrates. The user authorizes.
Sending money internationally shouldn't require guesswork. It reads live exchange rates and helps you send at the right moment — a companion app, not a bank. It describes the rate, recommends, and waits for you to act. It never moves money itself. Deployed and live, tested with people who send money home every month.
Role
Product design — solo (strategy, design, build)
Tools
Claude API · Cloudflare Workers · ExchangeRate-API · Netlify
Type
Self-directed
Status
Deployed · Live
Context
It reads live exchange rates across 18 corridors, narrates the timing decision in plain language, and hands off to your preferred provider — Wise, PayPal Xoom, your bank app — to complete the transfer.
One decision shaped every state of the product:
Code computes. Claude narrates. The user authorizes.
Conversion math is deterministic JavaScript, not generated by AI. Claude only describes what the code already worked out. You authorize every send. That separation is what lets the assistant sound conversational without costing you trust.
The Problem
Someone sends money home to family every month, and the money has to arrive. The anxiety isn't only about fees or exchange rates — it's about timing, and about knowing exactly what lands on the other end.
The market is crowded. Wise, Remitly, Revolut, and Western Union all compete on speed and cost. None of them help you decide when to send.
The design challenge was not building a better remittance app. It was building one that earns trust in a category where users have historically had it exploited.
I send money to family in Vancouver and Korea every month. I wanted to see whether the timing part — the part I could never get right — could be handled honestly, without pretending to predict the market.
Research
Four participants, each at a distinct point on the automation and crypto-comfort spectrum:
A marketing coordinator sending to her grandmother in Manila
A software engineer sending to his parents in South Korea
A warehouse supervisor sending to family in El Salvador
A freelance designer sending to international collaborators across LATAM and Africa
Five findings shaped every decision that followed:
Senders try to optimize timing and can't. The cognitive burden of acting at the right time, while managing other priorities, is the consistent pain point — not lack of access to rate information.
All four will accept crypto rails — if invisible. No participant refused crypto outright. What all four rejected was crypto as a user experience. Tolerance for crypto as infrastructure; zero expectation of encountering it.
Recipient-amount certainty is non-negotiable. Every participant, unprompted, described the same core need: before anything is sent, they want to see exactly what the recipient will receive. Not an estimate.
Automation tolerance is a spectrum. From Perry's manual-only stance to Sadie's programmable rules. A single product had to serve all four without forcing any of them into a flow that felt wrong.
Trust is built through proof, not promises. Every participant framed trust in terms of visibility and control — being able to see the reasoning and stop the system at any moment.
"I don't have time to track that constantly."
Jenni — Marketing Coordinator, Los Angeles CA
"I'd need to see what the rate is, what my family's getting, and how long it'll take."
Perry — Warehouse Supervisor, Dallas TX
Meet Fexi
Fexi is FXpress's AI co-pilot — a narration layer, not an automation engine, and not a forecaster.
She reads the current rate, compares it to what the user has seen earlier in the session, and describes the situation in plain language. She never predicts the future and never executes a transfer.
This is not a design choice made for flavor. It is the trust architecture. Claude can be conversational and approachable without compromising trust because code does the math, not the language model. Every Fexi response is an honest narration of a state that code has already computed.
The same read, both voices. When the Worker is unreachable a templated sentence takes over — built from the same computed signal, so nothing is lost but the warmth. The badge tells you which one is speaking.
Four states, four expressions. Fexi's face is a status indicator, not decoration — the sleeping avatar means the AI layer is down, and the widget says so rather than pretending.
Three Trust-Anchoring Design Decisions
01) Fexi Narrates, Never Decides
The AI is named, conversational, and visible — but it never executes and never advises. Every read describes observed data, with an authorization step that belongs to the user. Claude receives a finished conclusion and a prompt that forbids forecasting, computing, or saying whether to send. It never sees market data, so it has nothing to be wrong about.
02) The Fee I Removed Rather Than Invent
Every participant named the fee as part of what certainty means. FXpress hands off rather than moving money, so it has no fee of its own and no view of the provider's. The hi-fi included a fee line; the deployed widget doesn't, because the only way to fill it was to make a number up. The canvas states the amount at the current rate and names the gap — before your provider's fee. It's the one validated finding this product deliberately under-serves, and saying so is more useful than papering over it.
03) Recipient-Amount Certainty Before Authorization
Every send shows the recipient amount in local currency at the current rate, as the largest figure on the canvas, before the send button is reachable. Every participant cited this as a trust requirement; it's the single most-cited synthesis finding.
How It Works
FXpress is a single canvas with state. The amount input, corridor dropdown, Fexi card, and the two CTAs are persistent — what changes is Fexi's read, the recipient calculation, and the modal layer that opens for Send Now, Set Trigger, and Calendar Reminder.
The widget runs in two layers that never cross:
Deterministic engine (JavaScript, no AI) — fetches the live rate and 30 days of central-bank history, counts how many days closed below today's rate, and calculates the recipient amount. Every number is real, auditable, and survives if the AI layer drops.
Language engine (Claude via Cloudflare Worker) — receives the computed signal as text and phrases it warmly. It cannot invent rates or predict the future because it never sees raw market data. The API key lives only on the Worker, never in the browser.
When the AI layer is unreachable, a templated voice takes over and a status badge shows the user which voice is speaking. The widget never breaks.
The split is sharper than it sounds. The judgment — where today sits in the range — is also code. Claude receives a finished conclusion and a prompt that forbids forecasting, computing, or saying whether to send. It never sees market data, so it has nothing to be wrong about.
Testing & Iteration
A formative usability study — five participants, time-boxed tasks on an interactive prototype. Results reported as counts, not percentages. At this size the useful signal isn't a success rate; it's where people hesitate and self-correct.
What held. All five completed the send path without error. All five read the recipient's local-currency amount first, and it held across every corridor tested: ₱11,200 via GCash, ₩950,000 KRW, $1,350 CAD, M-Pesa instant payout. Nobody asked "what will my recipient get?" And nobody asked about crypto, wallets, or routing — the abstraction held five out of five.
What didn't. The trigger path completed four of five. One participant misclicked "Send Now" while trying to set a trigger — the two CTAs carried equal visual weight — then noticed, backtracked, and recovered. One abandoned the trigger form entirely at an unlabeled threshold field. A third hesitated at the same field and asked: "I don't know what 1,380 means — is that dollars, won, or shillings?"
What changed. Both were comprehension problems, both fixed in copy and hierarchy: the two CTAs were given distinct visual treatments — Send Now filled, Set Trigger outline — so they stop reading as the same choice; the threshold field got a currency label and helper text. Two further refinements — a record of past range reads against what the rate subsequently did, and simplifying the trigger surface on first use — are queued for the next iteration.
Two of five hesitated between the CTAs when both carried equal weight. Filling the primary action resolved it.
Outcomes
FXpress is a deployed, working fintech AI co-pilot — live at fxpress.netlify.app, usable right now with real exchange-rate data. The research confirmed the product concept is viable: all four participants said they would use it if it solved the timing problem without introducing new risk or confusion.
Validated design principles → Principles carried into the build
Fexi describes, never predicts — the architectural guardrail
Crypto abstracted by default, surfaced only on request
Recipient amount on the canvas before authorization, with the provider's fee named as an explicit unknown
Automation earned over time, not assumed at onboarding
Reflection
The research was stronger than I expected going in. The automation spectrum — four participants mapping cleanly from manual-only to programmable — gave the design clearer direction than a single target user would have. That spectrum became the architecture.
The build also corrected the design. The first version compared today's rate to what the user had seen earlier in the session — descriptive, honest-sounding, and hollow: on a first visit it had no data and recommended sending anyway. Replacing it with a 30-day window of central-bank data exposed a second problem. Range position implies mean reversion, and July's KRW data was a one-way 5.5% decline in which "bottom of the range" was the right moment to send every day for a month. The build now states the position and says plainly that it doesn't imply reversion. A trend indicator would resolve it properly; that's the next iteration.
What I'd do differently next time: test the Fexi recommendation pattern in isolation, earlier than I did. It held up in the usability study, but isolating that interaction sooner would have sharpened how much reasoning to show, and when — before it was wired into the full experience.
Previous
Next