An embedded finance platform lets a non-bank business offer banking-like features: accounts, cards, payouts, currency accounts, all inside its own product. The commercial logic is straightforward. The regulatory logic is less visible, and it matters more than most product teams initially assume. Before a platform builds anything, it needs to know exactly who is regulated, who holds the money, and who is liable if a payment goes wrong or a customer complains.

This is not a compliance footnote. It shapes what the platform can build, how fast it can launch, and what it can say to its own users about their money.

The regulatory perimeter, in practice

A platform offering embedded finance features is almost never a bank or an e-money institution itself. It sits on top of a BaaS provider that holds the relevant permissions: e-money issuance, payment services, or in some cases full banking licences with payment scheme membership. The platform builds the user experience; the regulated entity underneath does the things that require authorisation, such as issuing IBANs, safeguarding funds, or executing SWIFT and SEPA transfers.

The practical question for a product team is not "do we need a licence" but "what is our relationship to the entity that has one". Two structures dominate:

  • Agency or distributor model. The platform introduces users to the regulated provider's product. The end user's contractual relationship, in strict legal terms, is with the BaaS provider, even though the platform's brand is what the user sees. Onboarding, terms and conditions, and complaint handling need to reflect this clearly.
  • Programme model with delegated operations. The platform takes on more operational responsibility, such as first-line customer support or transaction monitoring, under a contract with the regulated provider that specifies exactly which functions it can perform and which remain with the licence holder.

Neither model is inherently better. The choice depends on how much control the platform wants over the user experience, and how much operational and compliance capability it is willing to build in-house.

Where the money actually sits

This is the point most founders get wrong at pitch stage. Embedding a banking feature does not mean the platform holds customer funds. In almost every workable structure, funds sit in accounts controlled by the regulated provider, not the platform.

Two structures are common, and they are not the same thing:

  • E-money float accounts. The BaaS provider issues e-money to represent customer balances and safeguards an equivalent amount in a separate account at a bank, typically ring-fenced from its own operating funds. This is the usual model behind EUR IBAN issuance and GBP collection accounts for platforms offering wallets or virtual accounts to their users.
  • Client money accounts. Under payment services rules, funds held on behalf of clients pending execution of a payment can sit in a client money account, subject to specific reconciliation and record-keeping obligations. This structure is more common where the platform is facilitating a transaction rather than holding a persistent balance.

A platform's marketing copy should never blur these two. Telling users their money is "safeguarded" when it is technically client money, or vice versa, creates a gap between what is promised and what is legally true. That gap becomes very visible if the provider ever fails.

Following the liability chain end to end

Take a simple case: a marketplace platform pays out a seller's earnings to their bank account. Walking through who is responsible at each step clarifies the structure better than any diagram.

  1. The platform's application calls an API banking platform to initiate a payout. The platform is responsible for correct data: amount, currency, destination sort code and account number, or IBAN.
  2. The BaaS provider validates the instruction and checks it against its own risk and screening rules. It is responsible for sanctions and fraud controls at the account level, and for holding the payment scheme membership, or an arrangement with a settlement bank that holds one, needed to actually move the money.
  3. The payment enters the relevant rail: Faster Payments for GBP, SEPA for euro transfers within the scheme's reach, or cross-border payments SWIFT for transfers outside those networks. The scheme or correspondent bank is responsible for the mechanics of settlement between institutions.
  4. Funds arrive at the seller's bank. If something fails at this stage, such as a rejected account number, the receiving bank is responsible for returning the funds, and the BaaS provider is responsible for handling the return correctly.
  5. Throughout, the platform is responsible for what it told the seller: expected timing, any conditions on release, and how to raise a query.

Liability does not sit in one place. It moves along this chain, and a platform that has not mapped it will struggle to answer a straightforward customer complaint about a delayed or failed payout.

Where platforms get the structure wrong

A few recurring mistakes show up across embedded finance builds:

  • Assuming the provider's licence covers the platform's own conduct. A BaaS provider's authorisation does not extend to how the platform markets its product, handles disputes, or represents fund safety. Platforms still carry conduct risk for their own communications.
  • Treating all currency accounts as equivalent. An account used for EUR IBAN issuance and one used for GBP collection accounts may sit under different legal protections, different scheme rules, and different settlement timeframes. Product copy that describes them identically misleads users.
  • Under-specifying operational boundaries in contracts. Where a platform takes on delegated functions, such as first-line support, the split of responsibility needs to be explicit and tested against real complaint scenarios, not just written into a services agreement and left unread.
  • Ignoring rail-specific liability rules. A payment that fails on SWIFT is handled very differently, in terms of timing and cost of investigation, from one that fails on a domestic instant rail. Platforms that promise uniform timelines across all payout destinations set expectations they cannot control.

Structuring for growth, not just launch

The right structure at ten thousand users is not necessarily the right one at a million. Platforms scaling internationally often move from a single BaaS relationship toward a broader fintech banking infrastructure stack, combining local e-money issuance in one market with correspondent banking relationships for cross-border volume. Providers building this kind of infrastructure, including London Rails Ltd., typically support both models, but the platform's own contracts and disclosures need to evolve alongside the technical stack, not lag behind it.

Getting the liability chain right early is cheaper than fixing it after a regulator, a bank partner, or an angry customer asks the platform to explain exactly who was responsible for their money at each step.