Every fintech that moves money for its customers eventually asks the same question: build the banking relationships directly, or work with a provider that already holds them. Banking as a Service in the UK exists to answer that question. It is not a single product but a layered set of infrastructure that lets a platform offer account numbers, payment collection and payouts without becoming a bank itself.
This article sets out how that layering actually works, where the regulatory backbone sits, and the mistakes product teams commonly make when they plug into it.
What Banking as a Service actually means
Strip away the marketing language and Banking as a Service UK arrangements have three layers. At the bottom sits an institution with payment scheme membership: access to Faster Payments, Bacs, or the relevant card and SEPA schemes, granted by the scheme operator and supervised by the FCA or PRA. In the middle sits a BaaS provider, which holds the technical connections to those schemes and exposes them through an API banking platform. At the top sits the fintech or marketplace, which uses that API to issue accounts, move funds and reconcile transactions inside its own product.
The point of this structure is that the fintech does not need to apply for scheme membership, build settlement connectivity, or maintain the operational resilience that a payment scheme demands. It consumes those capabilities through an API instead. What it still needs to understand, though, is what is happening underneath the API call, because that determines what it can safely promise its own customers.
The building blocks: IBANs, collection accounts, and payouts
Most Banking as a Service UK propositions are assembled from a handful of components:
- GBP collection accounts, each with a sort code and account number, used to receive domestic payments from customers or partners.
- EUR IBAN issuance, giving the same platform a euro-denominated account number for European customers, typically settling over SEPA.
- Client money accounts, which hold customer funds separately from the platform's own operating funds, a structural requirement rather than an optional safeguard.
- Marketplace payouts, the mechanism for splitting incoming funds and disbursing them to multiple sellers, drivers or suppliers on a schedule the platform controls.
- Cross-border payments via SWIFT, used when a transaction needs to reach a bank outside the domestic and SEPA network.
Individually, none of these is complicated. What makes Banking as a Service valuable is that a platform can combine them under one contract and one API, rather than negotiating separate relationships with a clearing bank, a card acquirer and a correspondent bank for international transfers.
Direct bank integration vs a BaaS provider
There are two broad ways a fintech gets access to this infrastructure, and the right answer depends on stage and scale.
Direct integration with a clearing bank means negotiating your own settlement account, your own scheme access where eligible, and building the technical connections yourself. This suits large, well-capitalised platforms with payment volumes that justify the operational overhead, and with in-house engineering capacity to maintain scheme connectivity, handle scheme rule changes, and manage the compliance obligations that come with direct membership.
Working through a BaaS provider means the provider holds the scheme relationships and exposes them through an API banking platform. The fintech integrates once, gets access to GBP collection accounts, EUR IBAN issuance and payout rails, and can go live in weeks rather than the months or years direct membership usually takes. The trade-off is that the fintech operates within the provider's product boundaries and commercial terms, and depends on the provider's own regulatory standing.
Most fintechs launching in the UK and Europe start with a BaaS provider and only consider direct scheme membership once volumes and balance sheet strength make it worthwhile. London Rails Ltd. operates in this middle layer, building the connective infrastructure that platforms use rather than requiring each one to negotiate its own bank relationships from scratch.
What happens end to end: a marketplace payout
It helps to trace a single transaction through the system. A buyer pays a marketplace for goods sold by an independent seller.
- The buyer sends funds to the marketplace's GBP collection account, identified by its own sort code and account number, or to a virtual account mapped to that order.
- The payment arrives via Faster Payments and is confirmed to the marketplace's platform through a webhook or API callback, usually within seconds for domestic transfers, though timing depends on the sending bank.
- The funds are held in a client money account, segregated from the marketplace's operating account, until the order is confirmed as complete.
- The platform triggers a payout: a proportion goes to the seller, a proportion is retained as commission, and the split is calculated and instructed automatically rather than manually reconciled.
- The seller's share is paid out, either to a UK bank account via Faster Payments or, if the seller is based in the EU, converted and sent via SEPA to a EUR IBAN.
None of this requires the marketplace to hold a banking licence. What it does require is a clear understanding of where funds sit at each stage, because that affects what the platform can tell its sellers about payout timing and what happens if a payment is queried or reversed.
Common integration mistakes
A few patterns recur across fintechs adopting Banking as a Service UK infrastructure for the first time.
Treating settlement times as fixed. Faster Payments transfers typically settle within seconds, but this is not a contractual guarantee, and delays can occur at the sending or receiving bank. Platforms that hard-code assumptions about timing into their own customer-facing promises create support problems when a transfer runs late for reasons outside their control.
Conflating collection accounts with operating accounts. Funds sitting in a client money account are not the platform's own money, even briefly. Product teams sometimes build internal ledgers that blur this distinction, which creates real problems at audit time.
Underestimating reconciliation at scale. A handful of transactions is easy to match manually. Thousands of daily payments across GBP collection accounts and EUR IBANs are not, and platforms that delay building automated reconciliation tend to discover the gap only once volume has already grown past the point where fixing it is simple.
Ignoring cross-border cost and timing differences. A payment routed via SWIFT behaves differently from one routed via SEPA or Faster Payments, in both typical settlement time and the information that arrives with it. Building a single payment status model that assumes all rails behave the same way tends to produce confusing customer communications.
Banking as a Service UK infrastructure removes the need to build banking relationships from the ground up, but it does not remove the need to understand what those relationships are doing on the platform's behalf. The fintechs that get the most out of it are the ones that treat the underlying mechanics as core product knowledge, not something to abstract away entirely.