Most platforms that need to hold money, issue account numbers, or move funds across borders reach the same decision point: work with one Banking as a Service provider that covers everything, or combine several specialist providers into a stack you manage yourself. Both approaches are common in the UK market. Neither is automatically correct. The right answer depends on payment volume, geography, and how much operational capacity the platform has to manage vendor relationships.
What actually sits behind a BaaS arrangement
Banking as a Service is often described as a single product, but it is really three layers stacked together.
The first layer is the regulated entity. This is the institution that holds an e-money or banking licence and is legally responsible for safeguarding client money accounts. Funds sitting in a customer's balance are ultimately protected under this entity's regulatory permissions, not the platform's.
The second layer is payment scheme membership. To move money on Faster Payments, BACS, or SEPA, an institution needs either direct membership of that scheme or a relationship with a member that provides indirect access. Scheme membership determines who can issue a genuine sort code and account number, or a EUR IBAN that clears through SEPA rather than through a slower correspondent route.
The third layer is the API banking platform: the software that lets a fintech or marketplace create accounts, initiate payments, receive webhooks, and reconcile transactions programmatically. This is the layer most product teams interact with daily, but it is only as reliable as the regulated entity and scheme access underneath it.
A single BaaS provider bundles all three layers under one commercial relationship. A multi-rail stack means the platform sources some of these layers separately, for example using one provider for GBP collection accounts and another for EUR IBAN issuance or cross-border payments via SWIFT.
Two ways to assemble the stack
A single-provider approach suits platforms that need one core capability done well: typically GBP-denominated collection and payout accounts for a UK customer base, with straightforward onboarding and a single API to integrate. The trade-off is currency and rail coverage. If the provider's scheme access stops at Faster Payments and BACS, any EUR or USD flow has to route around that gap, often through a correspondent bank arrangement that adds cost and settlement delay.
A multi-rail stack suits platforms with genuinely mixed currency needs: a UK marketplace paying GBP payouts to domestic sellers while also collecting EUR from customers across the EU, or a fintech offering multi-currency wallets. Here, no single provider may hold scheme membership across every rail required, so the platform integrates a GBP-focused provider alongside a EUR-focused one, sometimes with a separate correspondent relationship for wider SWIFT coverage into currencies outside Europe.
The cost of the multi-rail approach is not commercial, it is operational. Each provider has its own reconciliation format, its own webhook structure, its own approach to name-matching checks, and its own settlement cut-off times. A platform running three providers effectively runs three sets of operational procedures, three support relationships, and three points of failure to monitor.
A reasonable rule of thumb: below a certain transaction complexity, a single BaaS provider with broad rail coverage reduces integration risk more than it costs in flexibility. Once a platform is settling meaningful volumes in more than two currencies, the operational overhead of a single provider stretched across rails it does not natively support tends to outweigh the simplicity of one API.
Following a payment through the stack
It helps to trace what happens end to end, because the abstraction of "BaaS" hides a fairly mechanical sequence.
Take a UK marketplace paying out a seller in sterling. The platform's API call creates a payout instruction against the seller's account. The API banking platform validates the instruction and passes it to the regulated entity's core ledger, which checks the platform's own account has sufficient balance in the relevant client money account. The instruction is then submitted to the payment scheme, typically Faster Payments for same-day sterling transfers. The receiving bank's sort code routes the payment to the correct institution, and the account number identifies the seller's account. Confirmation comes back through the scheme, the ledger updates, and a webhook notifies the platform that the payout has settled. Settlement is typically same-day within Faster Payments' operating hours, though this is not a guarantee and depends on scheme processing at the time.
Now take the same marketplace paying a supplier in the eurozone. If the provider holds a direct SEPA connection, the flow is structurally similar: instruction, ledger check, scheme submission, confirmation, typically settling within the SEPA credit transfer window. If instead the payment has to leave the SEPA area, or the receiving bank does not participate in SEPA, the payment routes over SWIFT. This introduces intermediary banks, correspondent relationships, and messaging that carries payment details between institutions that have no direct connection. Settlement times extend accordingly and are typically measured in days rather than hours, again without guarantee, since the number of intermediaries involved varies by corridor.
Where platforms get the integration wrong
A recurring mistake is treating the API layer as the whole product and underestimating the underlying scheme access. A platform that integrates a slick API without checking whether the provider holds direct or indirect Faster Payments membership can find itself with slower settlement than expected, because indirect access routes through a sponsoring bank rather than the scheme directly.
Another common error is assuming EUR IBAN issuance automatically means SEPA-speed settlement. Some EUR IBANs are issued by institutions without direct SEPA scheme membership, meaning payments still route through a correspondent arrangement despite carrying a European account number.
A third mistake is underestimating reconciliation complexity when combining providers. Each provider's transaction reference format, timing of webhook delivery, and handling of failed or returned payments differs. Platforms that build reconciliation logic against one provider's quirks often find it breaks when a second provider is added for a different currency or rail.
Finally, platforms sometimes overlook payment scheme membership entirely when evaluating a provider, focusing instead on the developer experience of the API. The API is what you build against day to day, but scheme membership is what determines whether your customers' payments actually move at the speed your product promises.
London Rails works across this layered structure, connecting fintech banking infrastructure to scheme access so platforms can focus on the product decisions above rather than the plumbing underneath.