When a platform holds customer money in a payment account, the obvious question is whether that money is protected if the provider behind it fails. Safeguarding is the mechanism that answers this question, but the mechanism only works if it is implemented correctly and checked regularly. For a product or finance team choosing a banking infrastructure partner, understanding what safeguarding looks like on paper, not just in theory, is one of the more practical due diligence exercises available.
Safeguarding is not the same as deposit insurance
A common assumption is that money held by an e-money institution or payment institution is covered by something equivalent to the Financial Services Compensation Scheme. It is not. FSCS protection applies to deposits held by banks. Electronic money institutions and payment institutions are not banks, and their customer funds are not deposits. Instead, UK and EU regulation requires these firms to safeguard client money through segregation, insurance, or a comparable arrangement, so that if the institution becomes insolvent, the funds can in principle be returned to customers rather than absorbed into the general pool of creditors.
The distinction matters because it changes what a platform should be checking. FSCS cover is binary and automatic up to a threshold. Safeguarding is procedural. Its effectiveness depends on how well the underlying arrangement was set up, documented, and maintained. That is where due diligence has to focus.
What actually sits behind a safeguarding arrangement
In practice, a safeguarding arrangement for client money accounts involves three components working together.
- A segregated account or accounts at a bank, held in the name of the institution but designated so that it is clearly identified as holding client funds rather than the institution's own money.
- An acknowledgment letter from the bank confirming it recognises the account as a safeguarding account and waives any right of set-off against the institution's other liabilities. Without this letter, the segregation is largely symbolic, because the bank could otherwise treat the account as ordinary company funds in a dispute.
- Reconciliation between the balance held in the safeguarding account and the sum of individual customer balances recorded in the institution's own ledgers, performed frequently enough to catch discrepancies before they compound.
All three need to be present. A segregated account without an acknowledgment letter offers weaker protection than it appears to. Reconciliation that happens monthly rather than daily leaves a wider window in which a shortfall could develop unnoticed. This is the level of detail that separates a safeguarding policy that reads well from one that actually functions under stress.
Questions worth asking a provider directly
A platform evaluating a BaaS provider or an API banking platform for its payment infrastructure can reasonably ask for specifics rather than accepting general assurances. Useful questions include:
- How frequently is the safeguarding reconciliation performed, and is it automated or manual?
- Are acknowledgment letters in place for every bank holding safeguarded funds, and can their existence be confirmed?
- Is the safeguarding arrangement reviewed by an external auditor, and how often does that review take place?
- What happens operationally if a reconciliation break is identified, and who is responsible for resolving it?
- Does the safeguarding arrangement extend to funds held across different products, such as GBP collection accounts and EUR IBAN issuance, or only to certain flows?
- Treating safeguarding as a one-off box ticked at onboarding. Safeguarding is an ongoing operational discipline, not a static certificate. It should be revisited whenever the product adds new currencies, new account structures, or new markets.
- Not distinguishing between the provider's own operational funds and client money. Some platforms assume that any account with a sort code and account number attached to their brand is automatically a client money account. It is only a client money account if it has been designated and safeguarded as such under the relevant regulatory framework.
- Assuming safeguarding is uniform across jurisdictions. UK and EU safeguarding rules share a common ancestry but are not identical in every detail. A provider offering both GBP and EUR rails needs a safeguarding approach that satisfies both regimes, not one applied loosely across both.
- Overlooking the audit trail. Independent verification, whether through a statutory audit or an external assurance report, is what turns a safeguarding claim into something a platform can rely on with confidence. A provider unwilling to share evidence of this audit process is asking its partners to take the claim on trust alone.
Note: the last list item above should not contain a closing tag typo; providers who can answer these questions with specifics, rather than a general reference to "regulatory compliance," are usually the ones with a more mature operational process behind the claim.
Where marketplace and platform structures add complexity
Safeguarding gets more complicated when a platform is not simply holding its own customers' balances but managing funds on behalf of a two-sided marketplace. Marketplace payouts often involve money moving from buyers through a collection account, being held briefly pending a payout condition, and then being disbursed to sellers or service providers. At each stage, someone needs to be clear about whose money it currently is and under what safeguarding arrangement it sits.
This is one of the more common gaps platforms encounter when scaling. Early on, a single client money account might cover all customer funds adequately. As the platform adds multi-currency flows, cross-border payments over SWIFT, or additional payment scheme membership for local rails, the safeguarding arrangement needs to be extended and re-documented to cover each new account and currency. A safeguarding arrangement that was accurate at launch can become inaccurate a year later simply because new accounts were opened without updating the underlying reconciliation process.
Common mistakes platforms make when relying on a provider's safeguarding
A few patterns recur across platforms that later find gaps in their assumptions.
What this means for a platform's own risk assessment
Ultimately, the responsibility for understanding how client funds are protected does not disappear simply because the funds sit with a third-party provider. Platforms that build payment flows on fintech banking infrastructure are still accountable to their own customers for the safety of their money, and regulators increasingly expect platforms to demonstrate that they have assessed their provider's arrangements rather than assumed them. Building this assessment into supplier due diligence, alongside the usual checks on uptime, API reliability and settlement times, gives a platform a clearer picture of where the real protection lies and where it is only assumed. London Rails approaches safeguarding as an operational discipline that needs revisiting at every stage of a platform's growth, not a checkbox completed once and forgotten.