Platforms that collect or pay out in more than one currency face a structural decision early on: hold everything in one multi-currency account, or open separate accounts per currency. The choice affects reconciliation, regulatory treatment of client funds, and how fast money actually moves. There is no universally correct answer, only a better fit for a given payment flow.

Two ways to hold multi-currency balances

The first approach is a pooled multi-currency wallet: one account record that can hold balances in several currencies, usually presented to the platform through a single ledger with currency sub-balances. The second is a set of currency-segregated accounts, each with its own local identifiers — a EUR IBAN for euro transactions, a sort code and account number for sterling, sometimes a routing number for dollars. Behind either approach, a BaaS provider is typically holding the underlying funds across correspondent or scheme accounts, but the two models present very differently to the platform's users and to its own accounting.

Pooled wallets are administratively simple. A user or merchant sees one balance, converted or displayed in a reference currency, and the platform manages currency exposure internally. Segregated accounts are operationally more granular: each currency behaves like a local bank account, with its own inbound routing details, its own statement, and its own settlement rail.

When segregated currency accounts fit better

Segregated accounts make sense when the platform needs recipients to pay in using local rails, rather than sending an international transfer. A UK marketplace collecting from UK buyers wants GBP collection accounts with a normal sort code and account number, so buyers can pay via Faster Payments without their bank flagging an unfamiliar international transfer. A platform operating in the eurozone wants EUR IBAN issuance so counterparties can pay via SEPA, using a domestic-looking IBAN rather than routing money through SWIFT.

This matters for adoption. Payers are more likely to complete a transfer, and less likely to abandon or delay it, when the destination looks like a local account. It also matters for cost and speed: local scheme rails are generally faster and cheaper to use than a cross-border SWIFT payment, and reconciliation is more precise because each currency's inbound funds land in a dedicated account rather than a shared pool.

The trade-off is operational overhead. Each currency account typically needs its own compliance monitoring, its own liquidity management, and in some structures its own segregation logic if the funds are client money rather than the platform's own. A platform trading in six currencies under this model is effectively managing six sets of account relationships.

When a pooled structure fits better

A pooled multi-currency account suits platforms with lower transaction volume per currency, or platforms where most money movement is internal — for example, converting a seller's earnings from one currency to another before payout, rather than receiving large volumes of inbound payments in each currency separately. It also suits platforms still validating demand in a new market, where opening a fully local collection account for every currency would be premature.

The cost of this simplicity is that inbound payments from outside the platform's home market often still have to travel by cross-border payments SWIFT rails, even where the destination currency is one the platform holds, if there's no genuinely local account number backing it. That means longer typical settlement windows and higher per-transaction friction for the payer, compared with a domestic transfer.

What happens to client money in each structure

For platforms holding funds on behalf of others — marketplace payouts to sellers, or funds awaiting distribution to end customers — the account structure interacts directly with how client money is protected. Client money accounts must be clearly identifiable as holding funds belonging to third parties, distinct from the platform's own operating funds, regardless of whether the underlying structure is pooled or segregated by currency.

In a segregated model, this is usually cleaner to demonstrate: a EUR client money account and a GBP client money account each have their own audit trail, matching the currency of the underlying obligation. In a pooled model, the ledger has to do more work internally to show which portion of a mixed-currency balance belongs to which client and which currency, which increases the burden on reconciliation logic even though the commercial presentation to end users is simpler.

Marketplace payouts and scheme membership

Payout timing depends partly on which scheme the receiving account sits on. A GBP payout into a UK current account can typically move through Faster Payments in minutes. A EUR payout can typically move through SEPA Credit Transfer, or SEPA Instant where both banks participate. Payments to a currency or country outside these schemes generally route through correspondent banking and SWIFT, which is slower and where the final settlement time is genuinely not guaranteed in the way a domestic scheme's typical window is.

This is where payment scheme membership matters to a platform choosing infrastructure. A provider with direct or well-connected indirect access to Faster Payments and SEPA can offer materially better typical payout experience than one relying solely on SWIFT for every currency. Platforms building payout flows should ask, currency by currency, which rail a given payout will actually travel on, rather than assuming "multi-currency support" means equally fast settlement everywhere.

Common mistakes when structuring multi-currency accounts

  • Treating currency support as binary. Holding a EUR balance is not the same as having a EUR IBAN that can receive local SEPA payments. Confirm which specific inbound and outbound rails each currency actually supports.
  • Underestimating reconciliation complexity in pooled models. A single ledger balance across currencies still needs granular internal accounting if any portion is client money.
  • Assuming SWIFT settlement times as fixed. Cross-border payments SWIFT can vary by correspondent chain, and typical timeframes should never be presented to end users as guarantees.
  • Ignoring payer experience. A cross-border-looking payment instruction, even for a domestic-feeling transaction, can trigger extra bank checks and delays that a locally issued account number would avoid.
  • Building the integration around one currency and retrofitting others. An API banking platform that only abstracts GBP flows well often needs significant rework when EUR or USD volume grows, because the underlying rail logic, not just the currency field, differs.

Choosing a structure

The practical test is volume and payer expectation, currency by currency. Where a platform expects sustained local inbound volume — genuine GBP collection accounts’ worth of UK payers, or EUR-denominated sellers across the eurozone — currency-segregated accounts with proper local identifiers, issued as part of fintech banking infrastructure designed for that purpose, usually pay for their extra operational overhead. Where currency exposure is smaller, occasional, or largely internal to the platform's own conversions, a pooled structure keeps things simpler without materially harming the end-user experience. Most growing platforms end up with a mix: segregated accounts for their core markets, pooled balances for everything else, reassessed as volumes shift.