The phrase "embedded finance platform" gets applied to almost anything that lets a non-bank move money. A ride-hailing app that pays drivers instantly. A marketplace that issues virtual cards to sellers. A software company that gives its users a business account without sending them to a separate bank. These look similar from the outside, but the infrastructure behind them varies a great deal, and the differences matter once a platform starts scaling transaction volume across currencies.

An embedded finance platform, properly defined, is software that lets a non-financial business offer financial products — accounts, payments, cards, lending — as a native part of its own product, rather than redirecting users to a third party. The "embedded" part is the point: the end customer never knows there's a bank or a BaaS provider underneath. They just see a balance, an account number, and a payment that arrives on time.

What actually sits underneath the interface

Strip away the branding and most embedded finance platforms are assembled from the same handful of components, sourced either from a single BaaS provider or stitched together from several specialists.

  • A ledger. Every transaction needs a system of record that tracks who owns what money, independent of where the money physically sits. This is the accounting layer that reconciles deposits, fees, and payouts.
  • Account issuance. This is where EUR IBAN issuance and GBP collection accounts come in. Customers or platform users get their own identifiable account — a full IBAN for euro transactions, or a sort code and account number for sterling — so payments in can be attributed automatically rather than matched by hand.
  • Payment scheme connectivity. Money doesn't move unless something has payment scheme membership — direct or indirect access to Faster Payments, SEPA, or correspondent banking networks for cross-border payments SWIFT transfers. Most embedded finance platforms access these schemes indirectly, through a BaaS provider that holds the membership itself.
  • Safeguarding or client money accounts. Where a platform holds customer funds without being a bank itself, those funds typically sit in ring-fenced client money accounts at a regulated institution, kept separate from the platform's own operating funds.
  • An API banking platform. This is the layer product teams actually touch: endpoints for creating accounts, initiating payments, checking balances, and receiving webhooks when something happens.

None of this is visible to the end user, and that's deliberate. The commercial value of embedded finance is that the financial functionality disappears into the workflow it supports.

Build it yourself or plug into a provider

There are two broad routes to assembling an embedded finance platform, and the right one depends on what the business is actually trying to do.

Route one: direct infrastructure ownership

A handful of large platforms pursue their own banking licence or e-money authorisation, build their own ledger, and negotiate direct scheme membership. This gives full control over cost structure, product design, and settlement timing. It also means owning the compliance burden that comes with it: capital requirements, ongoing regulatory reporting, and the operational cost of running payment infrastructure at bank-grade reliability. This route tends to make sense only where financial services are the core product, transaction volumes are very high, and the business has years of runway to absorb the build.

Route two: BaaS provider integration

Most platforms take the second route: they connect to a BaaS provider that already holds scheme membership, banking relationships, and regulatory permissions, and consume that infrastructure through an API. The platform focuses on its own product — the marketplace, the payroll tool, the invoicing software — while the provider handles account issuance, payment routing, and the regulatory obligations that come with holding client money.

This is the more common choice for platforms whose core business is not banking. A marketplace exists to match buyers and sellers; a payroll platform exists to calculate and schedule wages. Financial movement is a necessary feature, not the reason the company exists. Sourcing that feature from fintech banking infrastructure built for the purpose is usually faster to market and cheaper to maintain than replicating it internally.

A worked example: marketplace payouts

Marketplace payouts are a useful illustration because they combine most of the components above in one workflow. A buyer pays into the marketplace's collection account. The platform's ledger records that the funds are owed, in part, to a specific seller, minus commission. At the point of payout, the platform instructs a transfer from the underlying account to the seller's own bank account, often using a dedicated virtual account or sub-account structure so each seller's balance is individually trackable rather than commingled in one pool.

The complexity increases once sellers are based in different countries. A seller paid via SEPA settles differently from one paid via Faster Payments, and a seller outside the EU or UK may need to be paid through a correspondent banking route. A well-designed embedded finance platform abstracts this: the marketplace calls one API endpoint to trigger a payout, and the underlying infrastructure decides which rail to use based on the destination account.

Common integration mistakes

Platforms building on top of a BaaS provider tend to run into a similar set of problems, most of which are avoidable with earlier design decisions.

  • Treating settlement time as fixed. Typical settlement windows for domestic and cross-border rails vary by scheme, time of day, and cut-off times. Hard-coding an assumed settlement time into user-facing copy or business logic causes support tickets when a payment takes longer than expected.
  • Under-provisioning for reconciliation. Without a unique identifier per customer — an individual IBAN, or a dedicated sort code and account number combination — incoming payments have to be matched manually against references, which breaks down at volume.
  • Ignoring webhook failure modes. API banking platforms typically notify applications of payment events via webhooks. If a platform doesn't build retry logic and idempotency checks for these notifications, duplicate or missed events cause ledger drift.
  • Conflating client money with operating funds. Platforms that hold customer balances need a clear structural separation between client money accounts and their own corporate account, both for regulatory reasons and to avoid accounting confusion during audits.
  • Assuming one rail fits all destinations. A platform serving both UK and EU customers needs infrastructure that can route between Faster Payments and SEPA — and fall back to SWIFT for destinations outside either scheme — without the product team having to manage that logic themselves.

Embedded finance platforms succeed when the financial plumbing is invisible and reliable, and fail visibly when it isn't. Getting the underlying account structure, scheme routing, and reconciliation logic right at the design stage is cheaper than retrofitting it once transaction volume has already scaled. London Rails works with platforms building this layer, providing the account issuance and payment rail access that sits behind the product their customers actually use.