Why Multi-Currency Cards Need More Than Card Issuing

Tap a multi-currency card in Tokyo, and the payment looks no different from any other card transaction.

Behind the tap, however, is a different story as the issuer has to identify the purchase currency, find the matching wallet, decide whether another balance should cover a shortfall and apply foreign exchange where required. 

The transaction must then be authorised, settled and reconciled across the programme’s records and external partners.

More customers are making the kind of payments that expose this complexity. 

Cross-border transactions on Asia-Pacific-issued Visa cards grew at more than twice the rate of domestic transactions in 2025, while spending at travel merchants increased around 2.5 times as fast as overall card spending.

More than 300 million people travelled internationally during the first three months of 2025, up 5% from the same period a year earlier, according to UN Tourism.

LuLu Exchange encountered an operating challenge when it set out to build a multi-currency card programme in the UAE. 

Although the product launched in one market, the architecture questions apply much more widely.

Any institution building a similar product needs a clear operating layer to coordinate the programme across the systems and partners involved.

Why Several Wallets Change the Architecture

One the one hand, a conventional card usually checks one primary balance before approving a transaction.

A multi-currency programme on the other, may have several live wallets, each carrying its own balance, spending limits, pricing and fee rules. 

Before authorisation, the card platform needs to identify which wallet should fund the purchase and what should happen when that balance falls short.

Most financial institutions can already source the individual components as issuers, processors, FX providers, settlement partners and reconciliation tools are readily available.

The difficulty however, lies in the logic between them.

The fragmented-stack diagram shows how those components can become separated across several providers. 

Issuing connects to wallet management, processing handles authorisation, and an FX provider manages currency conversion. 

Settlement and reconciliation may operate elsewhere, leaving the financial institution to manage the handoffs between them.

Every handoff introduces another dependency.

Adding a currency can require changes across the wider card programme, not just the wallet itself.

When those updates sit with different providers, a relatively routine product decision can turn into a much larger technology project.

When Every Change Becomes a Project

LuLu Exchange had encountered that fragmentation before.

Previous attempts relied on separate processors, issuing infrastructure, FX providers and settlement systems.

Each component performed its own function, although the company lacked one operating layer to manage the logic across the programme.

At the company’s transaction volumes, the arrangement placed a ceiling on how far the product could develop.

Introducing another currency could require a new integration, while adjusting a transaction limit or fee became a coordination exercise involving several vendors.

Scaling meant taking on more operational complexity alongside higher transaction volumes.

“We were looking for the right partner to support launching our multi-currency cards, and Stitch clicked right away,” said Joseph Cleetus, Vice President of Business Transformation at LuLu Exchange.

Cleetus said Stitch worked closely with LuLu Exchange’s teams and helped the company manage the external stakeholders involved in bringing the programme to market.

One Operating Layer Instead of Several

Stitch consolidated issuing, processing, FX, ledger management and reconciliation within one operating environment.

A common data model gave LuLu Exchange a shared view of balances and transaction activity, while a consistent set of APIs allowed programme rules to be managed without maintaining separate connections for every function.

The architecture diagram shows processing and FX connected with wallet management on one side, while card-scheme connectivity, settlement and reconciliation operate on the other.

A ledger underneath them maintains the programme’s record of balances and transaction movements.

External institutions remain part of the arrangement.

The bank sponsor and payment networks continue performing their respective functions, while Stitch coordinates the card, wallets and transaction logic across those relationships.

A common operating layer also gives the product team more control over how the card behaves.

Currencies, fees, transaction limits and wallet priorities can be configured within the programme rather than distributed across several vendor systems.

What Financial Institutions Need to Decide

Architecture decisions determine how much control a product team retains after launch.

An institution needs to know whether currencies, limits and pricing can be changed through configuration, or whether each update will require engineering work, vendor approval and another release.

The answer affects how quickly the programme can respond when a new travel corridor becomes commercially relevant or customer behaviour changes.

Funding logic also deserves the same scrutiny.

When the matching wallet does not contain enough money, the programme needs a clear rule for which balance should be used next and how much of the purchase requires conversion.

The decision shapes the customer experience, affects the institution’s FX economics and determines what its operations team must later reconcile.

Maintaining a reliable source of truth is just as important, because every system involved needs to record the transaction consistently.

Without a reliable source of truth, operations staff may have to trace a mismatch across several systems after the customer has already completed the purchase.

How the Card Chooses a Currency Wallet

Suppose a customer makes a HK$100 purchase with only HK$70 remaining in their euro wallet.

Declining the payment would be the easiest response for a platform designed around a single balance.

A multi-currency programme can instead check whether another wallet should fund the HK$30 shortfall.

Stitch calls this priority-based wallet dipping.

Customers arrange their currency wallets in a preferred order. When the matching balance runs short, the platform checks the next available wallet and converts only the amount required to complete the purchase.

One authorisation can therefore draw from more than one currency balance without asking the customer to move money manually before paying.

Once approved, the transaction updates the relevant wallets and ledger accounts.

Settlement and reconciliation later confirm that the programme’s records match the information received from the payment network and settlement partners.

Customers only see a completed purchase, while LuLu Exchange has to ensure every movement behind it is recorded correctly.

Launch Tests the Operating Model

LuLu Exchange’s reloadable prepaid travel card supports AED and 25 other currencies, giving customers access to 26 currency wallets through one product. 

It is available in digital and physical formats through the LuLu Money app.

Supporting those currencies creates a continuing operational requirement.

Travel patterns change, new corridors emerge, and pricing needs to be reviewed. Product teams may also want to introduce another wallet or alter the order in which balances are used.

Stitch allows LuLu Exchange to adjust call of those without rebuilding the underlying architecture for every change.

The card connects to the LuLu Money app through APIs and PCI-certified card widgets.

Customers can manage their PIN, adjust spending limits, freeze or unfreeze the card and review transaction history without leaving the existing app.

Implementation time will also influence whether an institution builds the stack internally or works through one operating layer. 

Stitch says its wider platform can reduce implementation time by 80%, with some programmes going live in as little as 90 days, compared with the nine to 12 months it associates with traditional providers.

Infrastructure Customers Never See

LuLu Exchange built its programme in the UAE, but the lesson travels.

A multi-currency card only works as a long-term product when the institution can change how it behaves without reopening the entire technology stack each time.

Customers judge the card at the point of payment as they expect the right balance to be used and the transaction to go through.

Product teams face a different test.

Can the programme evolve without another round of integrations and operational fixes?

The infrastructure may remain invisible to customers, but it determines how much control the financial institution keeps.

Featured image: Edited by Fintech News Hong Kong based on an image by Stitch via its case study.