When a platform holds money on behalf of its users, whether that is a marketplace collecting seller balances or a fintech app holding customer deposits, the question of what happens to that money if the platform fails is not theoretical. Safeguarding client funds is the regulatory and operational answer to that question. It is a set of rules and practices that keep customer money separate from a firm's own operating cash, so that if the firm becomes insolvent, that money can be identified, protected and returned rather than absorbed into the general pool of assets available to creditors.
For anyone building on fintech banking infrastructure, understanding how safeguarding actually works matters more than knowing that it exists. The mechanics determine how quickly funds can be traced, how reconciliation is structured, and what happens during an outage or a wind-down.
What safeguarding means under the Electronic Money Regulations
In the UK, electronic money institutions and payment institutions are required under the Electronic Money Regulations 2011 and the Payment Services Regulations 2017 to protect customer funds received in exchange for e-money or in the course of providing payment services. This is not deposit insurance. It has nothing to do with the Financial Services Compensation Scheme, which applies to bank deposits, not e-money balances. Safeguarding is a segregation duty: the firm must keep relevant funds separate from its own money at all times, and be able to demonstrate that separation to regulators on demand.
The practical effect is that a customer's money is never supposed to sit in the same account as the firm's payroll, rent or working capital. It sits in a designated pool, tracked against individual client ledgers, so that in an insolvency event an administrator can identify who is owed what and distribute accordingly, ahead of unsecured creditors.
Two methods of segregation, and when each applies
Regulated firms generally use one of two approaches to safeguarding.
The first is the segregation method. Funds received from customers are placed into one or more designated client money accounts held with an authorised credit institution, separate from the firm's own accounts. These are sometimes called relevant funds accounts. The bank holding them is told, in writing, that the balance belongs to customers collectively, not to the firm. This is the more common approach among e-money institutions because it does not depend on a third party's willingness to underwrite risk, only on the banking relationship being properly documented and maintained.
The second is the insurance or guarantee method, where the firm arranges an insurance policy or comparable guarantee from an authorised insurer or credit institution, which pays out to customers if the firm fails to meet its obligations. This method is less widely used in practice, partly because suitable providers are limited and partly because segregation is generally simpler to operate and easier for auditors to verify.
Neither method is inherently safer on paper, but they fail differently. Segregation depends on the safeguarding account being correctly designated and reconciled at all times. The guarantee method depends on the insurer honouring the policy when it matters most, which is precisely when the firm is under financial stress. Most platforms evaluating a BaaS provider should ask which method is used and, if segregation, which institution holds the account and how often it is reconciled.
What happens to a payment, from receipt to safeguarding
It helps to trace a single payment through the system. A customer sends funds to a GBP collection account, identified by a sort code and account number, or to a EUR IBAN issued for that customer or for the platform's pooled balance. The receiving institution's core ledger records the incoming payment and matches it, usually via a unique account reference or virtual account, to the correct customer or platform.
Once matched, the funds are recorded on an internal client ledger showing exactly who owns what. On a scheduled basis, often daily and sometimes multiple times a day, the firm reconciles the total balance across all customer ledgers against the actual balance sitting in the designated safeguarding account. Any discrepancy has to be investigated and resolved, typically by topping up the safeguarding account from the firm's own funds if a shortfall is found, since regulation requires the safeguarding account to hold at least as much as is owed to customers at all times.
From there, money moves according to what the customer instructs. A marketplace payout might go out via Faster Payments to a UK bank account. A cross-border payment to a supplier in another currency might route via SWIFT, or via SEPA if it stays within the eurozone. Throughout, the firm's role is to hold the balance safely between receipt and onward payment, not to use it for its own purposes in the interim.
Where BaaS providers and payment scheme membership fit
An API banking platform sits underneath much of this. It provides the account infrastructure, the reconciliation logic, and the connections to payment schemes that move money in and out. Some BaaS providers hold direct payment scheme membership, giving them a direct settlement account with the scheme operator. Others route indirectly through a sponsor bank, which introduces an extra layer of dependency: the platform relies not only on the BaaS provider's own solvency and controls, but on its sponsor's willingness and ability to keep processing payments.
This distinction matters for safeguarding because the safeguarding account itself is usually held with a separate credit institution from the one providing payment rails access. A platform doing due diligence should ask where the safeguarding account sits, who has visibility over it, and how reconciliation between the ledger and the bank statement is evidenced. London Rails Ltd. structures this separation explicitly, treating safeguarding account custody and payment rail connectivity as distinct functions that are each independently verifiable.
Common mistakes platforms make when relying on safeguarding
The most frequent error is assuming that "the money is safeguarded" is a fixed, binary fact rather than an operational discipline that has to be maintained daily. A safeguarding account that was correctly designated at account opening can still fail its purpose if reconciliation lapses or if operational funds are accidentally mixed in during a manual process.
A second mistake is not distinguishing between funds that are safeguarded and funds that are merely held in a business account with careful bookkeeping. Only funds held under the formal safeguarding regime, with the correct account designation and acknowledgment letters in place, receive the regulatory protection. A platform should ask its provider directly whether the relevant accounts are designated as safeguarding accounts under the Electronic Money Regulations, not simply described informally as client money accounts.
A third is overlooking how safeguarding interacts with multi-currency operations. A EUR IBAN and a GBP collection account may sit with different banking partners, under different legal frameworks, which means segregation has to be maintained separately for each currency pool rather than assumed to carry across automatically.
None of this requires a platform's product team to become safeguarding specialists. It does require asking specific, mechanical questions of any provider handling customer funds: which method is used, which institution holds the account, how often reconciliation happens, and what evidence exists that it actually does.