Safeguarding and reconciliation are two of the most closely watched controls in regulated fintech. Safeguarding is the obligation to protect customer money or assets so that they remain available even if the firm itself fails. Reconciliation is the discipline of continuously proving that a platform’s own records match the external reality they claim to represent. The two are inseparable: safeguarding without reliable reconciliation is an assertion rather than a control.
For an electronic money institution, a payment institution or a crypto-asset service provider, these controls are not back-office housekeeping. They are supervised expectations, and they are increasingly examined through the records and evidence a platform can produce rather than the policies it has written. That shift—from stated intention to demonstrable capability—turns safeguarding and reconciliation into an engineering question as much as a compliance one.
This article looks at safeguarding and reconciliation as an engineering discipline: what the two controls require, why they belong together, and what a platform has to be able to show. It stays at the level of architecture and evaluation rather than implementation. It describes what a regulator or auditor expects to see, not how to build a ledger or configure a reconciliation job.
What Safeguarding and Reconciliation Mean
Safeguarding protects the funds or assets a firm holds on behalf of its customers. In payments and electronic money this typically means keeping relevant customer funds separate from the firm’s own money, so that a customer balance is not exposed to the firm’s commercial risk. In crypto-asset services the equivalent obligation is the segregation of client crypto-assets from the provider’s own holdings, with records that identify what belongs to each client at any moment. The legal mechanics differ, but the principle is the same: customer value must be protected, identifiable and returnable.
Reconciliation is the control that keeps safeguarding honest. It compares independent records of the same value—for example a firm’s internal ledger against the balance held at a safeguarding account or a custody provider—and identifies any difference between them. A difference, known as a break, is a signal that something has moved, been misrecorded or been delayed. Reconciliation exists to detect breaks quickly, explain them and resolve them before they become losses or reporting failures. On its own, a ledger records what a platform believes; reconciliation is what tests that belief against the outside world.
Why These Are Engineering Problems
Both controls are often treated as procedures owned by a finance or operations team. In a modern platform they are properties of the architecture. Whether customer balances can be reconciled daily, whether a break can be traced to a specific transaction, and whether the resulting evidence can be produced on request all depend on how the underlying systems record, timestamp and expose data. A platform that was not designed with these questions in mind can usually still reconcile, but only through manual effort that is slow, error-prone and difficult to evidence.
The supervisory direction of travel makes this concrete. Expectations have moved from periodic, high-level assurance towards frequent, granular and auditable control. Where a firm might once have reconciled monthly and described its approach in a policy, it is now expected to reconcile far more often, retain the results, and show an unbroken evidence trail from a customer transaction to a safeguarded balance. Meeting that expectation reliably is an engineering outcome, not a matter of writing a better procedure.
The Building Blocks of Reconciliation
Reconciliation engineering can be described through a small set of building blocks. None of them is a product to be bought; each is a capability the platform has to possess and maintain. Understanding them helps a firm evaluate whether a platform—built in-house, licensed or delivered as a bespoke system—can actually support the controls its licence requires.
| Building block | Why it matters |
|---|---|
| Independent records | Reconciliation only works when the two sources being compared are genuinely independent. A platform must hold its own authoritative record of customer positions and compare it against an external source such as a bank or custody balance, not against a copy of itself. |
| Frequency and timeliness | The value of reconciliation depends on how quickly a break is found. Daily reconciliation is now a common baseline in payments and electronic money, and near-real-time comparison is increasingly expected where the underlying movements are fast. |
| Break detection | Differences must be surfaced automatically rather than discovered by chance. The platform needs to classify breaks by type and size, so that significant ones are escalated while routine timing differences are not treated as incidents. |
| Break management | A detected break is only useful if it can be investigated and resolved. This requires a record of what caused it, who reviewed it and how it was cleared, so that the resolution itself becomes part of the evidence. |
| Evidence trail | Supervisors and auditors examine what a platform can show, not what it asserts. Reconciliation results, exceptions and resolutions have to be retained in a form that can be reproduced later and tied back to the transactions that generated them. |
These building blocks reinforce each other. Independent records make comparison meaningful; frequency limits how far a problem can travel before it is caught; detection and management turn raw differences into controlled outcomes; and the evidence trail is what allows the whole process to be examined after the fact. A weakness in any one of them undermines the others, which is why reconciliation is better designed as a coherent capability than assembled from disconnected reports.
Safeguarding Records and Segregation
Safeguarding places its own demands on a platform’s records. To keep customer value protected and identifiable, a firm has to know, at any point in time, how much it holds for each customer and where that value sits. This is why safeguarding and reconciliation are engineered together: the safeguarding position is only as trustworthy as the reconciliation that confirms it. A platform that segregates funds or assets but cannot continuously prove that the segregated total matches its customer obligations has a records problem, not merely a housekeeping one.
The links between customer-facing balances, the firm’s ledger and the external accounts or wallets that hold safeguarded value therefore have to be explicit and consistent. The same architectural discipline applies whether the platform runs an e-money and payment platform or a crypto exchange and custody platform: customer obligations, internal records and external holdings must line up, and the platform must be able to demonstrate that they do. The categories being protected differ—fiat customer funds in one case, client crypto-assets in the other—but the requirement to keep records that are complete, identifiable and reconcilable is common to both.
Where UK and EU Requirements Land
In the United Kingdom, safeguarding for payment and electronic money firms sits within the established payments and e-money framework and the FCA Handbook. In May 2026 the regime was strengthened, with more prescriptive expectations around books and records, reconciliation frequency, monitoring and reporting, while a broader end-state reform was deferred for further assessment. The practical effect is that reconciliation and safeguarding records are no longer treated as internal good practice; they are examined controls, and the evidence a platform produces is central to how compliance is judged. Firms structuring for this can review our view of UK regulatory readiness.
In the European Union, electronic money and payment institutions safeguard customer funds under the established e-money and payment-services framework, which remains in force as later reforms move through the legislative process. For crypto, MiCA requires a crypto-asset service provider that holds client assets to segregate them from its own and to keep records that identify each client’s holdings at any time. The MiCA transition has ended. New EU cryptoasset projects must be designed for an authorised CASP operating model from the beginning. That model carries client-asset segregation and the reconciliation of custody records as standing features. Operational resilience expectations under the EU’s digital operational resilience framework, DORA, apply to the systems that deliver all of this, so the reliability of reconciliation and safeguarding records is itself a supervised property. Our perspective on EU regulatory readiness develops these points.
What a Ready Platform Looks Like
A platform that is ready for safeguarding and reconciliation scrutiny shares a set of characteristics. It holds an authoritative internal record of customer positions, separate from and reconcilable against the external accounts or wallets that hold value. It reconciles at a frequency matched to how quickly money or assets move, surfaces breaks automatically, and manages them through to a recorded resolution. It retains reconciliation and safeguarding evidence in a form that can be reproduced and examined. And it treats these as continuous properties of live operation rather than reports assembled shortly before an audit.
None of this is achieved by buying a single component. Safeguarding and reconciliation are properties of how customer records, internal ledgers, external accounts and controls are organised, and they have to be maintained as the platform changes. We do not provide legal opinions or guarantee authorisation. We implement regulatory and audit requirements across technology, infrastructure and operations, so that an e-money, payment or crypto platform can show—not merely state—that customer value is protected, identifiable and continuously reconciled.
Summary and Next Steps
Safeguarding and reconciliation are where a regulated platform proves that customer value is where it should be. Safeguarding sets the obligation; reconciliation provides the continuous evidence that the obligation is being met. Across UK and EU frameworks alike, both are increasingly examined through what a platform can demonstrate rather than what it declares, which makes them an engineering concern as much as a compliance one. Designing the records, reconciliation and evidence trail in from the start is far cheaper than reconstructing them under supervision.
Firms planning or reviewing a platform can begin with the architectural questions rather than the tooling. Where the question is how to structure that work, our fintech architecture advisory sets out how safeguarding and reconciliation fit into the wider platform design.
Make customer value provable, not just protected. Grumpio engineers safeguarding and reconciliation into fintech platforms around the evidence supervisors and auditors actually examine.