A marketplace that takes payment from a buyer in London and pays out a seller in Lisbon two days later is running a small banking operation, whether it calls itself one or not. Money has to be collected, held correctly, converted if needed, and released down the right rail to the right account. Banking as a Service in the UK exists largely to make that operation possible without the platform holding a banking licence itself. This article walks through what actually happens to the money, step by step.

What happens between a sale and a payout

Take a simple case: a customer buys a product through a marketplace, and the marketplace owes a share of that payment to the seller. Five things typically happen, usually within seconds of each other from the platform's point of view, though the underlying settlement can take longer.

  • The buyer's payment lands in a collection account held in the marketplace's name, structured so the funds are identifiable as belonging to sellers rather than to the platform's own working capital.
  • A ledger entry records who is owed what. This ledger is separate from the bank account itself; the account holds the cash, the ledger holds the obligations.
  • The platform's rules engine decides when the seller gets paid — instantly, on a schedule, or after a holding period for dispute protection.
  • At payout time, the system checks the seller's destination details and selects a payment rail based on currency and destination country.
  • The payment instruction is sent to the relevant scheme, and the seller's account is credited, typically within the timeframes normal for that rail.

Each of these steps sits on top of infrastructure the platform doesn't build itself. That infrastructure is what a BaaS provider supplies: accounts, ledgering tools, and connectivity to payment schemes, exposed through an API banking platform rather than a branch counter.

Domestic payouts: sort codes, account numbers and GBP collection

For a UK seller being paid in sterling, the payout usually travels over Faster Payments, identified by a standard sort code and account number rather than an IBAN. This is a point that trips up teams building for international audiences from day one: UK domestic accounts don't use IBANs in normal day-to-day transactions, even though they can be expressed in IBAN format for international messaging. GBP collection accounts used by marketplaces are structured to receive buyer payments and hold seller balances separately, so that a platform's own funds and its sellers' funds are never mixed in a way that would be difficult to unwind if something went wrong.

Cross-border payouts: EUR IBANs and SWIFT

Paying a seller in the eurozone is a different mechanic. Here, EUR IBAN issuance matters because SEPA payments are routed by IBAN rather than by local account and sort code equivalents. A marketplace operating across the UK and EU typically needs both GBP and EUR account infrastructure, with payouts routed over Faster Payments or SEPA depending on currency and corridor.

Payouts outside the SEPA zone — to a seller in the US or parts of Asia, for example — usually move over cross-border payments SWIFT rails. SWIFT payments involve more intermediaries than a domestic transfer, which is why they can take longer and why fees are less predictable; correspondent banks along the route each take a small cut and add their own processing time. None of this is fixed to a guaranteed timeframe. Settlement is typically same-day or next-day for well-formed payments, but SWIFT routes through multiple banks, and any one of them can introduce delay.

Where client money accounts fit

Marketplace payouts almost always involve holding money on behalf of someone else, even briefly. Depending on the platform's regulatory position, that money sits either in a safeguarding account under electronic money rules or in a client money account under different regulatory permissions. The distinction matters for how the money is protected if the platform itself fails, but from a plumbing perspective, both approaches require the same discipline: funds owed to third parties must be identifiable and separate from the platform's own balance sheet at all times, not just at month end.

Common mistakes platforms make with payout infrastructure

A few patterns show up repeatedly in marketplace payout builds, and most of them are avoidable with earlier planning.

  • Treating one currency as the template for all. A payout flow built and tested only in GBP often breaks when EUR or USD sellers are added, because IBAN validation, scheme cut-off times and reference field formats differ by rail.
  • Ignoring scheme cut-off times. Faster Payments runs close to 24/7, but SWIFT and some batch-based rails have cut-offs. A payout requested late in the day can silently roll to the next business day.
  • Conflating the ledger with the bank account. If the internal ledger and the actual account balance are updated on different schedules, reconciliation gaps appear that are hard to trace later. The ledger should reflect obligations; the account should reflect cash; the two need to be checked against each other regularly, not assumed to match.
  • Underestimating name-matching checks. Payout details that don't match the account holder's registered name can be rejected or delayed at the receiving bank, particularly for cross-border transfers where verification standards vary by country.
  • Assuming any BaaS provider gives the same rail access. Payment scheme membership varies. Some providers hold direct membership of Faster Payments or SEPA; others route indirectly through a sponsor bank, which can affect both speed and resilience if that sponsor has an outage.

What to check when evaluating infrastructure for payouts

For a platform building or reviewing its payout stack, a few questions are worth asking directly. Which schemes does the provider connect to directly, and which are routed through a third party? How are GBP and EUR balances segregated, and is that segregation visible in reporting rather than just described in a contract? What happens operationally if a payout fails partway — does the money return automatically, or does it need manual intervention? Providers such as London Rails Ltd approach these questions by separating the account infrastructure, the ledgering layer and the rail connectivity into distinct, inspectable components, so a platform can see exactly which part of the chain a payment is in at any moment.

Marketplace payouts look simple from the seller's side: money appears in an account. Behind that appearance sits a chain of collection accounts, ledgers, scheme connections and settlement windows, each with its own rules. Understanding that chain is what separates a payout system that scales cleanly from one that needs constant manual fixing as transaction volume grows.