A marketplace that sells across the UK and the eurozone will collect money from buyers in pounds and euros, and eventually needs to pay sellers in whatever currency those sellers expect. A subscription platform with customers in three countries faces the same problem in miniature. The naive answer is to open a business bank account in each currency. The practical answer, for most platforms, is a multi-currency account structure built on top of banking infrastructure designed for exactly this. This article looks at what that structure actually consists of, how money moves through it, and where platforms tend to get the integration wrong.
What a multi-currency account actually is
A multi-currency account is rarely one account in the traditional sense. It is usually a ledger that holds balances in several currencies, each backed by a real underlying account held with a bank or e-money institution, accessed through a single API. A platform sees one balance sheet showing, say, GBP 40,000 and EUR 25,000, but behind that view sit separate currency accounts, each with its own identifiers.
For GBP, that means a sort code and account number, the identifiers used by UK payment schemes to route Faster Payments and BACS transactions. For EUR, it means an IBAN, issued so that euro payments can be sent and received directly through SEPA. A platform operating in both currencies typically holds a GBP collection account and a EUR IBAN side by side, both reachable from a single API banking platform rather than two separate banking relationships.
Two structural approaches, and when each fits
There are two broad ways a BaaS provider will structure multi-currency accounts for a platform, and the difference matters for reconciliation and for how funds are legally held.
The first is dedicated accounts per currency, sometimes called segregated accounts. Each currency the platform needs gets its own distinct account, with its own IBAN or sort code and account number, held in the platform's name or in a client money structure on the platform's behalf. Money in the GBP account stays in the GBP account until it is paid out or converted. This approach is straightforward to reconcile because each account's statement maps directly to one currency's activity, and it is well suited to platforms with a small number of core currencies and predictable volumes in each.
The second is a pooled or omnibus structure with sub-ledgers. Here, the underlying accounts are held by the BaaS provider across various currencies, and the platform's balances in each currency are tracked as ledger entries rather than as separate legal accounts per user or per business line. This scales better when a platform has many end users each needing their own multi-currency wallet, because the provider is not opening a new bank account for every customer, only a new ledger entry. Marketplace platforms with thousands of sellers, each needing a payout balance in more than one currency, typically need this model rather than dedicated accounts per seller.
Neither approach is universally better. Dedicated accounts suit platforms that need clean, auditable, one-to-one account mapping, often for regulatory or client money reasons. Pooled ledgers suit platforms that need to give many end users their own multi-currency balance without the operational weight of opening that many real bank accounts.
What happens end to end for a cross-border payout
Consider a marketplace with a UK-based buyer and a seller based in France. The buyer pays in GBP through Faster Payments into the platform's GBP collection account. That payment settles into the ledger, usually within seconds to a few hours, though this is a typical timeframe rather than a guarantee, since it depends on the sending bank and time of day.
The platform now holds GBP but owes the seller a payout in EUR. One option is to convert GBP to EUR within the platform's own multi-currency structure, then pay the seller from the EUR account via SEPA, which usually settles same day. The seller receives a EUR-denominated payment that looks, from their bank's perspective, like any other incoming SEPA credit transfer, with no visible sign that the original funds arrived in a different currency.
Where the platform has no EUR balance, or where the currency pair is one the platform doesn't hold natively, the payout may route via cross-border payments over SWIFT instead. SWIFT payments carry more routing information, often pass through one or more correspondent banks, and typically take one to a few working days to arrive, again as a typical range rather than a fixed promise. For platforms doing regular business between two currencies, holding a local account in each currency and using SEPA or Faster Payments directly is usually faster and more predictable than relying on SWIFT for every transaction.
Client money and where the funds actually sit
A question that comes up quickly once a platform starts holding balances on behalf of sellers or users is whether those funds are the platform's own money or client money. If a marketplace collects payment from a buyer and holds it before releasing it to a seller, that balance is often the seller's money, not the platform's, and needs to be held accordingly. This is usually done through client money accounts, which are segregated from the platform's operating funds and structured so that, if the platform itself became insolvent, the money held for sellers would not simply be swept into the general insolvency estate. Multi-currency structures need to preserve this segregation across every currency held, not just the platform's primary one. A EUR balance held for French sellers needs the same protection as a GBP balance held for UK sellers.
Common integration mistakes
Platforms building marketplace payouts on multi-currency infrastructure tend to run into a handful of recurring problems. Treating all currency accounts as fungible is one: pulling funds from a GBP balance to cover a EUR shortfall without an explicit conversion step creates a reconciliation gap that is hard to unpick later. Assuming instant settlement across every rail is another; Faster Payments and SEPA typically settle quickly, but SWIFT payments do not, and building payout logic that assumes uniform speed across currencies causes support tickets when a EUR-to-non-EUR payout takes longer than expected.
A third mistake is ignoring payment scheme membership entirely when things go wrong. Most platforms access Faster Payments, SEPA and SWIFT indirectly through their BaaS provider's own scheme membership, which is normal and efficient, but it means that when a payment fails or is delayed, the platform needs a clear escalation path to the provider rather than trying to query the scheme directly. Building that escalation process before launch, rather than discovering it during an incident, saves time when it matters.