A platform that pays sellers, contractors or partners in more than one country will eventually run into the same question: does each currency need its own local account, or can everything sit in one multi-currency ledger and be converted as needed? The answer shapes how fast payments move, how much they cost to route, and how much reconciliation work falls on the finance team. It is a structural decision, not a cosmetic one.
What a multi-currency account is actually doing
A multi-currency account, in practice, is rarely a single account. It is usually a set of currency-denominated balances, or sub-accounts, sitting under one customer relationship, each connected to a different local payment scheme. A EUR balance connects to SEPA. A GBP balance connects to Faster Payments and Bacs, and comes with its own sort code and account number. A USD balance typically routes through correspondent banking and SWIFT. The platform sees one dashboard; underneath, each currency has its own rail, its own cut-off times, and its own settlement behaviour.
This matters because currency and payment rail are not the same thing. Holding a EUR balance does not automatically mean payments move on SEPA — it depends on whether the account has a EUR IBAN issued in a way that gives it real scheme access, or whether it is a virtual representation that ultimately routes through a correspondent bank via SWIFT. The distinction rarely shows up in a sales conversation, but it shows up immediately in settlement speed and in how a beneficiary bank displays the sender.
Two structural approaches
Platforms generally choose between two models.
The first is local currency accounts per market: a GBP collection account with a UK sort code and account number for UK-facing flows, a EUR IBAN for eurozone flows, and so on. Each account behaves like a domestic account in its own country. Payments in and out use local rails, arrive with recognisable local formatting, and typically settle on local timeframes rather than international ones. This is the model most marketplaces use once volume in a given currency becomes material, because local formatting and local settlement speed materially affect trust and conversion rates at the payout stage.
The second is a single multi-currency wallet that holds balances in several currencies but routes everything less-common through SWIFT or a correspondent network. This is simpler to integrate initially — one account structure, one set of credentials — but it means payments to counterparties in currencies without a dedicated local rail move more slowly and through more intermediary banks, each of which can apply its own cut, delay or formatting quirk.
Neither approach is universally better. A platform with occasional payouts in a dozen currencies does not need local IBAN issuance in all twelve; the operational overhead would outweigh the benefit. A platform with concentrated, high-volume flows in two or three currencies usually benefits from local accounts in exactly those currencies and SWIFT-based routing for everything else.
What happens end to end
Consider a platform collecting from customers in the UK and Ireland, and paying out to suppliers in both. A UK customer pays into the GBP collection account via Faster Payments; the funds typically clear within seconds and land against the platform's ledger, tagged to that customer's reference. An Irish customer pays into the EUR IBAN via SEPA Credit Transfer; that payment typically settles same-day under standard SEPA processing.
On the payout side, the platform's ledger allocates the correct balance to the correct supplier. A UK supplier is paid from the GBP balance via Faster Payments, arriving with the platform's sort code and account number as the visible sender. An Irish supplier is paid from the EUR balance via SEPA, arriving with the EUR IBAN as sender. No currency conversion happens in either leg, because the currency of the balance matches the currency of the payout. This is the scenario local accounts are built for: money moves on the rail native to that currency, without a conversion step introducing FX exposure or delay.
Now add a US supplier being paid in USD from a platform that only holds GBP and EUR balances. Here, a conversion step is unavoidable, and the payment leaves via SWIFT through a correspondent banking relationship. It typically takes longer to arrive, may pass through one or more intermediary banks, and each intermediary can deduct handling charges before the recipient's bank credits the remainder — a detail that surprises platforms unfamiliar with correspondent banking, since the amount received can be lower than the amount sent.
Common integration mistakes
The most frequent mistake is treating currency balances as interchangeable buckets rather than as connections to distinct schemes. A product team building payout logic sometimes assumes any balance can pay any currency, when in fact a EUR balance without SEPA access, or a USD balance without correspondent routing configured correctly, will simply fail or fall back to an expensive manual process.
A second mistake is underestimating reconciliation complexity when balances are pooled across currencies without clear sub-ledger separation. If client money and platform revenue sit in the same multi-currency pool without segregation by currency and by owner, month-end reconciliation becomes a manual exercise in unpicking FX movements from genuine transaction activity.
A third is ignoring scheme membership status when selecting a provider. Not every BaaS provider has direct payment scheme membership; some route through an intermediary bank that itself holds membership, adding a layer of dependency and, in some cases, additional latency. For a platform evaluating an API banking platform, it is worth asking plainly whether currency accounts connect directly to local schemes or indirectly through an aggregator, since that answer determines realistic settlement expectations, not just theoretical ones. London Rails Ltd. structures multi-currency account access around this exact question, treating each currency corridor as a distinct rail decision rather than a single generic feature.
Choosing a structure that fits
The practical rule is to match account structure to transaction concentration. High-volume, recurring flows in a currency justify a dedicated local account with direct scheme access. Low-volume, occasional flows are usually better served by SWIFT-based conversion from a smaller number of core balances. Reviewing currency volumes quarterly, rather than locking in a structure at launch and never revisiting it, keeps the account setup aligned with how the platform actually moves money as it grows.