FCA Safeguarding Software: A Buyer's Guide for PIs and EMIs
In short: FCA safeguarding software automates the operational obligations placed on payment institutions and electronic money institutions when they hold relevant funds: daily internal and external reconciliations, shortfall and excess correction, records and accounts, the monthly safeguarding return, the annual safeguarding audit, and a resolution pack that must be kept current and produced on request.
What FCA safeguarding software actually has to do
FCA safeguarding software is not a reporting dashboard bolted onto a finance system. It is the operating layer that carries the evidential burden the FCA places on a firm holding relevant funds. That burden is specific and testable, and any platform that cannot discharge each element in sequence will fail at audit regardless of how the interface looks.
There are six obligations that define the category. First, an internal reconciliation of the firm's own records of relevant funds received and held. Second, an external reconciliation of those internal records against the balances confirmed by each safeguarding institution and each third party holding funds. Third, immediate correction of any shortfall or excess identified, funded from the firm's own resources where a shortfall exists. Fourth, records and accounts sufficient to distinguish relevant funds from every other sum the firm holds. Fifth, the monthly regulatory return submitted to the FCA. Sixth, a resolution pack maintained so that an insolvency practitioner or the regulator can identify and return client funds without reconstructing the firm's books.
Software that automates only reconciliation solves one sixth of the problem. The compliance failure modes that generate enforcement outcomes are almost never a broken matching rule. They are late reconciliations, unevidenced corrections, a resolution pack that has drifted from reality, and an inability to reproduce the state of the safeguarding position on a specific historic date.
Why spreadsheet-based safeguarding fails under PS25/12
Most firms arriving at PS25/12 are running safeguarding through a reconciliation workbook, a shared drive of bank statements, and a monthly finance close. That model was tolerable when the reconciliation was periodic and largely self-reported. It does not survive a regime built on daily obligations and an annual audit against a specified standard.
The first failure is temporal. A workbook records a conclusion, not a process. When an auditor asks what the safeguarding position was on the fourteenth of a given month, who reviewed it, what variance was present, how it was corrected and when, a spreadsheet can rarely answer without a manual reconstruction that itself becomes an audit finding.
The second failure is coverage. Relevant funds move across multiple safeguarding accounts, acquirers, card schemes, agents, and distributors. A workbook reconciles the accounts someone remembered to include. A platform reconciles the accounts that exist, and flags an account that has stopped reporting as an exception rather than silently omitting it.
The third failure is correction. The obligation is not to notice a shortfall. It is to correct it, from the firm's own funds, and to evidence the correction. Manual processes routinely capture the identification and lose the remediation trail, which is precisely the gap a safeguarding audit is designed to find.
The fourth failure is oversight. Senior managers under SM&CR carry personal accountability for safeguarding arrangements. A monthly finance pack delivered in arrears does not constitute live oversight of a daily obligation.
The buyer's scorecard: eleven questions that separate platforms
Ingestion. Can the platform take the data as it exists today, in bank statement formats, acquirer settlement files, ledger extracts, scheme reports, and custodian statements, without a six-month data engineering project? Format-agnostic ingestion with automated schema mapping is the difference between going live in weeks and going live after the audit.
Reconciliation depth. Does the platform reconcile internally and externally as separate, separately evidenced processes, or does it collapse both into a single match run? The FCA treats them as distinct obligations and an auditor will test them distinctly.
Break investigation. When a variance appears, does the platform explain it, or does it hand a compliance analyst a list of unmatched rows? Autonomous investigation, with the reasoning retained against the break, is where the operational cost of safeguarding is actually recovered.
Correction workflow. Is there a first-class record of shortfall identification, funding decision, transfer, and confirmation, timestamped and attributable to a named individual?
Monthly return. Does the platform produce the FCA safeguarding return from the same reconciliation data that produced the daily positions, or is the return assembled separately? A return that cannot be traced back to the underlying reconciliations invites challenge.
Resolution pack. Is the pack generated continuously from live data, or is it a document that a compliance officer refreshes when they remember to? A resolution pack that is out of date is a breach in itself.
Audit evidence. Can the firm export a complete, tamper-evident evidence set for any date range without engaging the vendor?
Immutability. Are reconciliation runs cryptographically sealed so that a record cannot be amended after the fact without detection? Hash-sealed runs convert an assertion of control into a provable one.
Independent verification. Can an auditor or regulator verify a sealed run without the firm's cooperation and without a login to the firm's tenant?
Governance. Does the platform produce board-level and senior manager reporting as an output of the process, rather than as a slide someone builds afterwards?
Scalability across regimes. If the firm also operates under EMR 2011, PSD2, CASS 6, CASS 7, or MiCA, does one platform carry all of them, or does each regime add another system?
How Safeheld is built against that scorecard
Safeheld ingests source data in the formats a firm already receives, maps unfamiliar schemas automatically, and reconciles continuously rather than on a nightly batch. Internal and external reconciliations are executed and evidenced as distinct processes, which is how they are tested.
Every break is investigated autonomously before a human sees it. The platform gathers the supporting records, forms an explanation, attaches its reasoning, and routes only the items where confidence is insufficient to a named reviewer. Compliance teams spend their time on judgement, not on matching.
Each reconciliation run is sealed with a SHA-256 Merkle root. The seal fixes the inputs, the matching logic, the outcome, and the reviewer, and it can be verified independently. An auditor does not have to accept the firm's word that a reconciliation was performed on a given date and produced a given result.
The monthly safeguarding return, the resolution pack, and the annual audit evidence set are generated from the same sealed runs that produced the daily positions. There is one version of the safeguarding truth, and every artefact traces back to it.
What a realistic implementation looks like
A firm with a conventional safeguarding footprint, meaning a handful of safeguarding accounts, one or two acquirers, and a single core ledger, should expect connection and first reconciliation inside the first fortnight, parallel running against the existing manual process through the following month, and full cutover with the manual workbook retired thereafter.
Parallel running matters. It is the period in which the platform's output is compared line by line against the incumbent process, and it is where firms typically discover variances the manual process had been absorbing without recording. Those discoveries are uncomfortable and they are precisely the reason the regime changed.
The dependency that most often extends a timeline is not technical. It is obtaining timely, complete statement data from every safeguarding institution and third party. Firms that start that conversation early implement faster.
Frequently asked questions
Is safeguarding software mandatory under PS25/12?
No. The FCA specifies outcomes, not tooling. The rules require daily reconciliations, immediate correction of shortfalls, adequate records, a monthly return, an annual audit, and a current resolution pack. Firms may meet those obligations manually, but the evidential standard and the daily frequency make manual compliance expensive and fragile at any meaningful volume.
How often must safeguarding reconciliations be performed?
Internal reconciliations are expected on each business day. External reconciliations are expected as often as necessary and, for most firms holding relevant funds, that means daily. Any shortfall identified must be corrected immediately from the firm's own resources.
What is a resolution pack?
A resolution pack is the set of records that allows an insolvency practitioner to identify and return relevant funds quickly if the firm fails. It must be kept current and produced on request. A pack that reflects last quarter's arrangements does not meet the standard.
Does safeguarding software replace the annual safeguarding audit?
No. The audit remains an independent exercise. Software changes what the auditor is given: a complete, sealed, date-addressable evidence set rather than a reconstruction assembled under time pressure.