One architecture, three local rails
Airtm is a digital dollar wallet used across Latin America and other emerging markets, where most people fund their balance through local payment rails rather than international transfers.
- Role
- Senior Product Designer — sole design owner across three markets: architecture, flows, prototypes, handoff.
- Collaborators
- Product, Engineering, Compliance.
- North star
- Funding a dollar wallet should feel like paying a local bill, in your own bank app, with your own identifiers.
In 30 seconds
- 01 · Problem
- Three markets needed local bank rails, each with different identifiers and regulatory steps. Separate flows would multiply design and engineering.
- 02 · Decision
- Place virtual accounts inside Add and keep one shared structure, changing only the rail-specific details.
- 03 · Result
- Colombia and Mexico went live in the same half; Brazil entered build, and Venezuela later reused the architecture.
The problem
People in Colombia, Mexico and Brazil had no way to fund Airtm through the rails they use daily. Each market has different identifiers, account-detail formats and regulatory steps, and the obvious answer — one bespoke flow per country — multiplies design, engineering and QA with every new market.
One structure, five screens
01 / 05
The constraint
Three markets, three rails, one team, and a roadmap that expected more countries after these. Whatever shipped had to be legible to someone who has never heard the words “virtual account”, and had to survive the next country being added by someone who was not in the room.
A shared architecture
Separate flows for each country would multiply the onboarding, copy and maintenance work. The design instead keeps the structure shared, with market-specific account details and requirements.
The pivot
I treated it as an architecture question before a screen question, and the answer was a definition: a virtual account is a way to add money, not an object that lives inside the wallet. Once it sat inside Add, one structure served every market — entry point, accounts hub, per-country onboarding, account details mapped to the local rail, and deactivation — with only the rail-specific details changing.
One artefact to review
The flow shipped as a single interactive prototype rather than a screen deck, so product, engineering and compliance reviewed the same working thing and could see state changes instead of imagining them.
The test of the idea
When a relief initiative later needed a US account for users in Venezuela, it reused the structure directly — and got simpler: one account instead of a hub, and no “not eligible” screen, because the entry point only appears for people who can use it.
What I gave up
Local flavour. A Brazilian-feeling Pix flow would have been warmer than a shared structure wearing Pix details, and I chose the structure. The bet was that consistency and speed to the next market matter more than each country feeling bespoke — and that the details, which is where the rails actually differ, carry enough locality on their own.
Outcome
Colombia and Mexico went live in the same half, with Brazil in build. New markets became a configuration exercise rather than a redesign, and the structure survived its first real test when Venezuela reused it unchanged.