When a marketplace, payroll app or vertical SaaS platform lets its users hold balances, send payments or receive payouts without leaving the product, most of the underlying banking mechanics are invisible. The user sees a balance and a button. Behind that button sits a chain of account structures, payment rails and regulatory obligations that determine whether the money actually arrives, and whose responsibility it is if it doesn't. This article traces that chain from the moment a payment is initiated to the moment it lands.
What "embedded" changes about the payment path
A traditional business banking relationship involves a company opening an account, receiving a sort code and account number, and moving money through its own banking portal. Embedded finance removes that step for the platform's end users. Instead of each seller, driver or freelancer opening their own bank account, the platform provides account-like functionality directly inside its own interface, backed by a regulated partner behind the scenes.
That partner is typically a BaaS provider or an e-money institution offering an API banking platform, which issues the account numbers, connects to payment schemes, and holds the regulatory permissions the platform itself does not have. The platform's job is the product experience. The provider's job is the account infrastructure, the compliance obligations that come with holding client funds, and the connectivity to Faster Payments, SEPA, and card schemes.
This division matters because it changes where liability sits at each stage of a transaction, and it is worth understanding the mechanics rather than treating the whole thing as a black box.
The account layer: what a user's "account" actually is
When a UK-facing platform gives a user a sort code and account number, that number is usually issued against a client money account or a segregated ledger held by the underlying provider, not a standalone bank account in the user's name. The number routes correctly into Faster Payments or BACS, but the balance sitting behind it is tracked in the provider's ledger, apportioned to that specific user.
For platforms operating across the UK and eurozone, the same pattern applies to EUR IBAN issuance. A user might see a GBP collection account for UK-based customers and a euro IBAN for EU-based ones, both issued from the same underlying provider relationship but routed through different domestic schemes. Getting this right means the platform's ledger and the provider's ledger stay reconciled in real time, otherwise a payment can clear on the rail while the platform's own records lag behind.
Two ways to structure payouts
Platforms that pay out to many recipients, such as marketplaces, gig-economy apps or affiliate networks, generally choose between two structural approaches.
Pooled disbursement: the platform holds a single operating or client money account and pushes bulk payments out to individual recipients, matching each transaction to a recipient using payment references. This is simpler to set up and works well when payout volumes are modest and reconciliation tooling is solid, but reference-matching errors become more likely as volume grows, and a misapplied reference can mean a payout reaching the wrong ledger entry even if the funds arrive at the correct bank.
Per-user virtual accounts: each recipient is issued their own dedicated account number within the provider's infrastructure, so incoming settlement and outgoing payouts are automatically attributed without relying on reference text. This scales better for high-volume marketplace payouts and reduces manual reconciliation work, at the cost of a more involved integration and, usually, a larger number of account records to manage.
Neither approach is universally better. A platform paying out to a few hundred recipients a month with predictable reference formats may find pooled disbursement perfectly adequate. A platform paying tens of thousands of recipients across multiple currencies typically needs the per-user structure to keep reconciliation manageable and to avoid the operational cost of chasing misapplied payments.
Where cross-border payments still need SWIFT
Most embedded finance activity inside the UK and EU runs on domestic or regional rails: Faster Payments, BACS and CHAPS in the UK, SEPA Credit Transfer and SEPA Instant across the eurozone. These rails are fast, and same-day or near-instant settlement is typical for domestic and intra-SEPA transfers. But platforms with customers or suppliers outside these zones, or handling currencies other than GBP and EUR, still rely on cross-border payments via SWIFT for the leg outside the regional scheme.
This matters for embedded finance platforms because a payout journey often has two legs: a fast domestic or SEPA transfer from the provider to a local account, and then, for genuinely international payments, a SWIFT message between correspondent banks that can take longer and carries its own fee and messaging structure. Platforms that assume every payout will be instant regardless of destination often discover the exception only when a customer in a non-SEPA country complains about a delay. Setting expectations correctly at the product level, based on the actual rail being used, avoids this.
Common integration mistakes with marketplace payouts
A few patterns recur across platforms building payout functionality for the first time. Treating all destination accounts as equally fast, without checking whether a payout is going through Faster Payments, SEPA or a SWIFT correspondent chain, leads to inconsistent delivery times that are hard to explain to users. Failing to validate account details before initiating a payout, rather than relying on the scheme to reject bad data after the fact, causes delays and failed payments that could have been caught earlier. And underestimating the reconciliation burden of pooled accounts, particularly once payout volume passes a few thousand transactions a month, tends to surface as a support and finance-team problem months after launch rather than at the design stage.
Why scheme membership shapes what's possible
Every payment rail a platform relies on, whether Faster Payments, BACS, CHAPS or SEPA, is operated by a scheme with its own membership tiers. Direct scheme members connect straight to the payment infrastructure and carry the operational responsibility that comes with it. Indirect participants access the same rails through a sponsoring bank or BaaS provider that already holds direct membership. For most platforms building embedded finance features, indirect access through a provider's existing scheme membership is the practical route, since direct membership requires a regulatory and operational footprint that sits outside the platform's core business. Understanding which membership model sits behind a provider's infrastructure helps explain settlement timing, resilience, and what happens if a rail experiences downtime.
The mechanics described here sit underneath every embedded finance product, whether the platform frames it as a wallet, a payout tool or a business account. Understanding the account structures, the rail choices and the reconciliation implications up front makes the difference between a feature that scales cleanly and one that generates support tickets as volume grows.