Part 3 of 3 in our multi-currency accounts series. Read Part 1, by Rana Palit here and Part 2 by Kanika Agarwal here.
In Part 1, we made the case that banks are bleeding cross-border receivables revenue to fintechs that have quietly built better infrastructure underneath them. In Part 2, we showed what that infrastructure actually looks like — and what it unlocks for product and technology teams when it's done right.
This article is for the bank executive who has read both, agrees with the diagnosis, and is now sitting with a harder question: where do we actually start?
The honest answer is that most banks approach this the wrong way. They treat multi-currency accounts as a technology procurement exercise — a system to scope, a vendor to evaluate, an integration to plan. Twelve to eighteen months later, they have a build plan, three competing internal opinions on architecture, and no product in market.
The banks getting this right are doing something different. They're treating it as a product launch, not an IT project. They're making a small number of sharp decisions early, deferring the rest, and getting to market in six to nine months rather than eighteen. Here's how.
1. Decide what kind of player you want to be — before you decide anything else
The single decision that will shape every other decision is whether you're building this capability in-house or partnering for it.
Most banks default to "build" without realising they've made the decision. The question gets framed as an architecture choice, debated by technology and operations, and the commercial implications surface eighteen months later when the first customer asks for a currency the build doesn't support.
The question isn't whether you can build this — most banks can. The question is whether you should. Three questions will help you to frame this.
- Is multi-currency infrastructure a strategic differentiator for you, or table stakes you need to offer? If it's table stakes, partnering is almost always the right answer. There's no point building what dozens of others have already built unless it's genuinely central to your competitive positioning.
- What's your credible time-to-market on a build? If the answer is eighteen months, your customers are already solving their cross-border receivables needs elsewhere — with fintechs, with neobanks, with embedded finance providers. Every quarter you delay is another quarter of relationship erosion and revenue leakage. Speed to market isn't a nice-to-have here.
- Do you have the operational footprint to deliver this at the breadth your customers will demand? That means ten-plus currencies, fifteen-plus countries, with the rails and relationships already in place. If not, you're choosing between a strategic infrastructure partner upfront, or a fragmented set of tactical partnerships later to fill the gaps in the build. The latter is almost always slower, more expensive, and operationally messier.
A white-label infrastructure partner can compress the timeline from twelve to eighteen months down to six to nine months, with your brand on the front and the operational plumbing handled underneath. This isn't a compromise — for most banks outside the top tier, it's the only path to market that doesn't end with the project being quietly shelved.
2. Pick your first currency corridors — and resist the urge to be comprehensive
The instinct is to launch with full coverage. Don't.
Demand from bank customers isn't evenly distributed across currencies. In practice, it clusters at two ends of the spectrum: USD, which everyone needs, and a small number of exotic or local currencies that matter intensely to a specific customer segment. A bank in the UAE doesn't need EUR collections nearly as much as it needs USD and a credible AED proposition. A bank in Southeast Asia is solving for USD and IDR or PHP, not for SEK.
This bimodal pattern is good news, because it means you don't need to launch with thirty currencies. You need to launch with the two or three that 80% of your customer demand sits behind, and a credible roadmap for the rest.
Here's the practical sequencing that works:
Phase 1 (months one to four post go-live): USD plus one or two local or regional currencies your customer base demands most. Get the operational model right at small scale before you expand.
Phase 2 (months four to nine): Expand to the next tier of mature corridors — typically GBP, EUR, AUD, SGD — where the operational rails are well-established and you're not navigating unfamiliar regulatory territory.
Phase 3 (months nine onwards): Exotic currencies driven by specific customer requests with revenue attached. Don't build for hypothetical demand. Build for the customer who's standing in front of you.
3. Get the right people in the room — in the right order
The biggest cause of stalled multi-currency programmes inside banks isn't technology. It's internal sequencing. The wrong stakeholders get involved too early, and the right ones too late.
Here's the sequence that works:
Weeks one to four: Product and commercial. Define the customer proposition, the pricing model, and the first-corridor decision. If you can't articulate who's buying this, what they're paying for, and why they'd switch from their current provider, no amount of downstream effort will save the programme.
Weeks four to eight: Internal control functions. Bring them in once the customer proposition is sharp. The conversation is shorter and more productive when you can show them a defined use case rather than an open-ended capability. Run this in parallel with — not after — the technology workstream.
Weeks six to ten: Technology and operations. Architecture, integration approach, reconciliation, exception handling, customer servicing. By this point the proposition is defined and tech can solve a concrete problem rather than an abstract one.
Weeks eight to twelve: Treasury and finance. Funding model, balance sheet treatment, FX exposure management, internal pricing. This often gets left to the end and then becomes the unexpected blocker, so bring it forward.
The single biggest mistake banks make is starting with technology. The second biggest is letting any one function run the programme on its own. Multi-currency is genuinely cross-functional, and the programme governance needs to reflect that from day one.
4. Make the build-versus-buy call on five specific components
Even if you're partnering for core infrastructure, you'll still own pieces of the stack. Decide which ones deliberately rather than letting it emerge by accident.
The customer-facing experience. Almost always owned by the bank, because this is where the brand lives. A white-label partner provides the rails; the bank owns the UX, the onboarding journey, and the customer relationship.
Customer onboarding orchestration. Often shared. The partner can provide tooling and operational infrastructure; the bank typically retains the customer-of-record relationship and final approval steps.
Account structure and currency rails. Almost always partnered. Standing up the operational footprint to support thirteen-plus currencies is a multi-year undertaking. This is the core of what infrastructure partners exist to provide.
FX execution. Optional. Some banks keep this in-house to protect treasury margin; others outsource for simplicity. Decide based on whether FX is a profit centre or a cost line for you.
Reporting and reconciliation. Bank-owned, partner-fed. The bank needs the data in its own systems; the partner provides clean, structured feeds that slot into your existing reporting infrastructure.
Get this division of responsibility onto one page before you sign anything, because ambiguity here is where partnerships unravel six months in.
5. Plan internal governance — and start it early
The thing that derails most multi-currency programmes inside banks isn't external. It's internal. Senior stakeholders get involved too late, mandates are unclear, and decisions that should take a week take a quarter.
Three governance moves to make early:
Name a single accountable owner with authority across product, technology, and operations. Multi-currency programmes that are run by committee, or that change ownership halfway through, are the ones that miss the six-to-nine-month window. The owner doesn't need to be the most senior person in the room — they need to be empowered to make decisions and hold people to them.
Get executive sponsorship on the record before the detailed work starts. A sponsor who agrees in principle in month one but hasn't been walked through the commercial and operational implications in detail will, predictably, raise concerns in month four when the budget request lands. Front-load that conversation so there are no surprises later.
Bring all relevant internal functions into the same forum from week one. This includes product, technology, operations, treasury, finance, and the bank's own control functions. Running these workstreams in parallel rather than in sequence is the single biggest lever you have on timeline. It requires coordination, but the alternative is waiting for each function to finish before the next one starts — which is how you end up at eighteen months.
The pattern across the banks that have done this well is that they treated the launch as a product programme with cross-functional governance from day one, not as a technology project with stakeholders consulted along the way.
6. Set realistic milestones to hit a six-to-nine-month timeline
Here's a practical timeline for a bank launching with a white-label infrastructure partner:
Months 1-2: Proposition definition, corridor selection, partner selection, internal stakeholder alignment.
Months 3-4: Contract and commercials, integration scoping, internal sign-offs.
Months 5-7: Build and integrate the customer-facing layer, configure operational workflows, internal testing.
Months 8-9: Limited customer pilot, learn, scale.
Two things will blow this timeline if you let them:
Scope creep. Every additional currency, every additional product feature, every additional internal stakeholder added mid-programme adds weeks. Define the minimum viable first release in month two and hold the line on it. You can always add currencies in phase two — you can't get the time back if you try to launch with everything at once.
Sequential rather than parallel work. Banks tend to run workstreams sequentially because that's how programmes are usually governed. For this kind of launch, they need to run in parallel. That requires programme leadership with authority to make trade-offs across functions, and it requires everyone involved to accept a bit more coordination overhead upfront in exchange for speed.
The barriers are no longer technical
The banks that win in cross-border receivables over the next three years won't be the ones with the best technology. They'll be the ones that got to market first with a credible proposition, learned from real customers, and iterated. The infrastructure to support that is now available off-the-shelf. The barrier is no longer technical. It's organisational — the willingness to make decisions quickly, partner where partnering makes sense, and resist the gravitational pull of an eighteen-month build that never quite ships.
If you're starting this conversation inside your bank, the most useful thing you can do this week is decide who owns the answer to one question: who's buying this from us, and what are they paying for? Every other decision flows from that one.
