FCA Safeguarding by 7 May 2026: Building the Daily Reconciliation and Resolution Pack for Payment Firms

The FCA’s interim safeguarding rules do not ask you to hold more capital or restructure your accounts. They ask you to prove, every business day, that the money you owe customers is actually where you say it is — and to hand an insolvency practitioner a pack they can act on the day the firm fails. Most payment firms are trying to do both in a spreadsheet.

From 7 May 2026 the FCA’s supplementary safeguarding regime, set out in policy statement PS25/12 and housed in a new client-assets sourcebook, CASS 15, applies to authorised payment institutions and e-money institutions. It is deliberately an interim step. The end-state regime — a full statutory-trust, CASS-style framework replacing the safeguarding provisions of the Payment Services Regulations and the Electronic Money Regulations — comes later, once Treasury legislation is in place. But the interim rules are not a soft launch. They tighten record-keeping, reconciliation and reporting well ahead of the final regime, and they are the version supervisors will test first.

The practical consequence for the technology function is narrow and specific: you need an automated daily reconciliation that produces evidence, and a resolution pack that stays current without anyone remembering to update it. This is a data-lineage problem before it is a compliance one.

What “daily reconciliation” actually means here

CASS 15 requires two reconciliations, both performed on each reconciliation day — broadly, every business day excluding weekends and the usual public holidays. They are different checks and firms conflate them at their peril.

The internal reconciliation compares your safeguarding records against each other: the total of relevant funds you have recorded as owed to customers, reconciled across the systems that hold that number. This is your resource requirement — what you must be safeguarding.

The external reconciliation compares your internal record of what should be segregated against what the third party — the safeguarding bank, or the insurer or guarantor — actually confirms is held. This is your resource: what is genuinely there.

A break is any difference between the two. The rule is not “reconcile and note discrepancies for later”. Where the reconciliation shows a shortfall, the firm must make it good — pay in from its own funds — and where it shows a surplus of the firm’s own money sitting in the safeguarding account, that must be removed. The correction is expected promptly, not at month-end. If your process cannot detect a break, attribute it, and resolve it inside the same day, it does not meet the standard.

That is why the spreadsheet approach fails. A manual reconciliation run by one person, from exported balances, tells you the position hours after the event and leaves almost no defensible trail of who checked what against which source. The interim regime is built to close exactly that gap.

The reconciliation, in code

The core of the daily job is a comparison between your internal safeguarding ledger — the sum of relevant funds owed to customers — and the cleared balances confirmed by your segregated accounts. The important design choice is the full outer join: a break is not only when the numbers differ, but also when one side is missing entirely, such as a bank feed that failed to arrive. A missing feed is a break, not a pass.

-- Daily safeguarding reconciliation (CASS 15 supplementary regime)
-- Internal resource requirement (what we owe customers) vs
-- external resource (what the segregated accounts actually hold).
-- Run once per reconciliation day. A non-zero break must be actioned
-- the same day: a shortfall topped up from own funds, a surplus withdrawn.

WITH resource_requirement AS (
    -- What we owe customers per our own books at close of the recon day
    SELECT
        reconciliation_date,
        SUM(relevant_funds_balance) AS internal_requirement
    FROM safeguarding_ledger
    WHERE reconciliation_date = :recon_date
    GROUP BY reconciliation_date
),
segregated_resource AS (
    -- What is confirmed held in designated safeguarding accounts
    SELECT
        statement_date AS reconciliation_date,
        SUM(cleared_balance) AS external_resource
    FROM segregated_account_balance
    WHERE statement_date = :recon_date
      AND account_type = 'SAFEGUARDING'
    GROUP BY statement_date
)
SELECT
    COALESCE(r.reconciliation_date, s.reconciliation_date) AS recon_date,
    r.internal_requirement,
    s.external_resource,
    COALESCE(s.external_resource, 0) - COALESCE(r.internal_requirement, 0)
        AS variance,
    CASE
        WHEN r.internal_requirement IS NULL
          OR s.external_resource   IS NULL           THEN 'MISSING_SOURCE'
        WHEN s.external_resource < r.internal_requirement THEN 'SHORTFALL'
        WHEN s.external_resource > r.internal_requirement THEN 'SURPLUS'
        ELSE 'MATCHED'
    END AS break_type,
    -- Anything other than a clean match must be evidenced and resolved today
    (COALESCE(s.external_resource, 0)
       <> COALESCE(r.internal_requirement, 0)
     OR r.internal_requirement IS NULL
     OR s.external_resource   IS NULL) AS action_required
FROM resource_requirement r
FULL OUTER JOIN segregated_resource s
    ON r.reconciliation_date = s.reconciliation_date;

The query is the easy part. What makes it evidential is what surrounds it: the run is logged with a timestamp and the identity of the source feeds, every break row is written to an immutable audit table with its resolution, and the top-up or withdrawal that clears a break is linked back to the break that triggered it. A supervisor asking “show me the reconciliation for 12 March and what you did about the break” should get an answer from the system, not from someone’s memory. This is the same evidenced-pipeline discipline that reporting-clock regimes elsewhere demand: the artefact has to be produced by the machine, not reconstructed after the fact.

The resolution pack is a live dataset, not a document

The second deliverable is the harder one to fake. CASS 15 requires firms to maintain a resolution pack: the records and information an insolvency practitioner would need to return safeguarded funds to customers quickly if the firm fails. The test is brutal in its simplicity — could an administrator, walking in cold on the day of failure, work out who is owed what, where it is held, and how to give it back, using only what the pack contains?

In practice the pack needs to resolve, at any point in time: the identity of each safeguarding account and the institution holding it; the acknowledgement letters confirming the account’s trust status; the current customer liability schedule; the reconciliation history evidencing that resource matched requirement; and the operational detail — agents, distributors and third parties whose systems hold or move relevant funds. The failure mode is treating this as a Word document refreshed once a year. On the day it matters, an out-of-date pack is worse than none, because it sends the administrator to accounts that have closed and customers whose balances have moved.

The engineering answer is to generate the pack from the same systems that feed the daily reconciliation, on a schedule, so it is never more than a day stale. If the customer liability schedule in the pack is the same figure your internal reconciliation used that morning, the two artefacts corroborate each other. If they are produced by separate manual processes, they will drift, and the drift is exactly what an administrator or a supervisor will find.

What else changes, and who is caught

Two further obligations sit alongside the reconciliation and the pack. There is a new monthly regulatory return on safeguarding arrangements, submitted to the FCA — which is only as reliable as the daily data underneath it, so a firm that automates the reconciliation gets the return largely for free. And there is an annual safeguarding audit by a qualified auditor, reporting on whether the firm’s systems were adequate throughout the period and compliant at its end. The FCA has exempted the smallest firms from the audit — broadly those safeguarding under £100,000 across the relevant period — but the reconciliation and record-keeping duties are not similarly waived.

The third-party dimension is where firms most often underestimate the work. Safeguarding rarely lives in one place: funds move through agents, distributors, a safeguarding bank, sometimes an insurer. Each is a dependency that has to be identified, evidenced in the pack, and captured in the reconciliation feeds. Getting the supplier map right is a recurring theme for regulated firms — the same discipline the FCA’s critical third party regime forces at the infrastructure layer applies here at the money-flow layer. If your architecture already treats safeguarding as a first-class data domain rather than a reporting afterthought, as a well-built payment institution architecture does, most of this is wiring rather than rebuilding.

The firms that struggle in May 2026 will not be the ones that misread a rule. They will be the ones who still reconcile safeguarded money by hand and discover, the first time an examiner asks for the daily trail, that the evidence was never being produced.