One architecture, three local rails
How one account structure served Colombia, Mexico and Brazil: local bank details became one more way to add money, inside Add.
Airtm · 2026 · Live in Colombia and Mexico
Project sheet
- Sole designer
- 1 PM, engineering, Compliance
- 1 month to handoff
I was the only designer across the three markets: architecture, flows, prototypes and handoff.
- Problem
- Three markets needed local bank rails, each with different identifiers and regulatory steps. Separate flows would multiply design and engineering.
- Decision
- Place virtual accounts inside Add and keep one shared structure, changing only the rail-specific details.
- Result
- Colombia and Mexico went live in the same half-year; Brazil entered build, and Venezuela later reused the architecture.
No way in through local rails
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.
North starFunding a dollar wallet should feel like paying a local bill, in your own bank app, with your own identifiers.
One structure, five screens

Three rails, one team
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.
An account is a way to add money
I treated it as an architecture question before a screen question, and the answer was a definition: a virtual account is one more way to add money. 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. Only the rail-specific details changed.
One artefact to review
The flow shipped as a single interactive prototype. Product, engineering and compliance reviewed the same working thing, and saw the state changes instead of imagining them.
The test of the idea
Later, a relief initiative 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.
Less 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. The other half of the bet: the details, where the rails really differ, carry enough locality on their own.
Colombia and Mexico live
Colombia and Mexico went live in the same half-year, with Brazil in build. New markets became a configuration job. The structure passed its first real test when Venezuela reused it, with fewer screens than the original.