UK Safeguarding Rules Reshape Payment Devs' Day

Twelve days ago, on 7 May 2026, the FCA's new safeguarding regime for UK payments and e-money firms came into force. The headline rules sit inside the brand-new CASS 15 sourcebook chapter and they are the most prescriptive operational obligations the FCA has ever written for non-bank payment institutions. If you work as a UK fintech developer or payment developer inside a payment firm, an e-money issuer, or a platform that holds relevant customer funds, the engineering bar has just been raised — and the build that satisfies the new rules is the kind of unglamorous, deeply boring backend work that separates the firms that survive an audit from the ones that scramble through their first one.

This is the regulatory counterpart to the HM Treasury stablecoin consultation closing in three days. The Treasury piece sets out where UK payments regulation is going. CASS 15 is what is already in force this week.

What Actually Changed on 7 May

The old safeguarding regime relied largely on high-level principles. CASS 15 replaces that with prescriptive operational rules across five areas:

1. Daily reconciliation of safeguarded funds. 2. Monthly reporting confirming safeguarding practices and reconciliation outcomes. 3. Annual safeguarding audit by a qualified auditor (unless the firm has not been required to safeguard more than £100,000 of relevant funds at any point in the preceding 53 weeks). 4. Resolution packs that allow safeguarded funds to be distributed quickly in a wind-down. 5. Third-party due diligence on safeguarding banks, custodians, and account providers.

The piece that puts the largest demand on engineering teams is the daily reconciliation requirement. It is the most operationally specific obligation in the regime and the one that, in practice, will define whether a firm's safeguarding posture is real or theatrical.

"Six a Day" — the Reconciliation Obligation in Practice

The FCA requires multiple types of reconciliation on every business day (excluding weekends and UK public holidays):

• An internal check that the firm's "safeguarding resource" — the funds actually held in segregated accounts or invested in relevant assets — equals its "safeguarding requirement", the amount the rulebook says it should be holding.
• A D+1 internal confirmation that relevant funds received on day D have, by close of business the next business day, landed in a designated safeguarding account or relevant asset.
• An external comparison of the firm's own internal records against third-party records: statements from safeguarding banks, statements from account providers, and confirmations from authorised custodians.

Industry counts of these obligations have settled on "six reconciliations per business day" as a rough sketch — the precise number depends on a firm's product mix and the number of safeguarding venues it uses. Either way, the operational tempo has changed from "weekly or monthly reconciliation with manual breaks" to "every-day reconciliation with automated breaks investigation."

Why This Is an Engineering Problem, Not a Compliance Problem

A daily reconciliation regime can be assembled with spreadsheets and willpower for a single product line at a single bank. It cannot be assembled that way at scale. The firms that are about to discover this the hard way are the ones whose existing safeguarding process depends on a Compliance team manually pulling CSVs from banking portals once a week.

The build that actually satisfies CASS 15 looks something like this:

• A canonical safeguarding ledger — the system-of-record for what every customer's relevant funds should be at any moment. Typically built on PostgreSQL with strict transactional guarantees and immutable journal semantics.
• A bank-statement ingestion pipeline — automated fetch of bank, custodian, and account-provider statements (ISO 20022 camt.053 where the venue supports it, screen-scraped portals where they do not) into a structured form.
• A reconciliation engine — the matching layer that compares the canonical ledger against external records on each reconciliation day, surfaces breaks within a defined SLA, and routes them to a human investigator.
• A D+1 settlement tracker — the per-transaction state machine that watches incoming relevant funds from receipt to settlement in a safeguarding venue, and raises an alert when the D+1 boundary is at risk.
• An observability and audit-trail layer — every reconciliation run, every break, every investigation, and every resolution recorded with sufficient granularity for an auditor walking in cold a year later.

In production this typically maps to a Rust or Go ingestion and reconciliation service for the latency-sensitive path, PostgreSQL as the ledger of record, Redis for short-lived state and rate-limited bank API calls, Kubernetes for the ingestion fleet, and a structured-event store for the audit trail. None of this is novel. All of it must be built — and most importantly, must demonstrably keep running every single business day for years.

The Resolution Pack Build Is Underrated

The piece most teams underestimate is the resolution pack requirement. The pack is a pre-prepared bundle of information that would let an insolvency practitioner distribute safeguarded funds to customers rapidly if the firm failed. It is not enough to maintain the ledger; the firm must be able to produce, on demand, a complete, machine-readable account of every customer's safeguarded balance, the venues those funds sit in, and the legal claim each customer has on them.

For an engineer, that is a separate build. The runtime ledger is optimised for the firm's own operations. The resolution pack is optimised for a third party to pick up cold and act on. They draw from the same source of truth, but the resolution-pack export needs its own format, its own validation, its own freshness guarantees, and its own dry-run cadence. Firms that treat it as "we'll generate it when we need it" tend to discover during the first audit dry-run that the data they thought they had does not reconstitute cleanly.

Where This Sits in the Wider UK Payments Picture

CASS 15 is not happening in a vacuum. The UK is simultaneously:

• Folding UK-issued stablecoins into the payment services perimeter (consultation closes 22 May)
• Consolidating the Payment Systems Regulator into the FCA
• Expanding the FCA's powers over Open Banking
• Hosting the launch market for products like MoonAgents Card, which depend on this regulatory infrastructure being mature

CASS 15 is the floor under all of that. A jurisdiction that wants to be the home of agentic commerce, stablecoin payments, and a unified payment-services regime has to demonstrate that its operational safeguarding model is genuinely robust. The 7 May deadline was the moment the floor was poured.

Key Takeaways for UK Payment Engineers

• CASS 15 has been in force since 7 May 2026. Daily reconciliation, D+1 checks, monthly reporting, annual audit, and resolution packs are now operational obligations, not aspirations.
• The daily-reconciliation regime sketches out to roughly six reconciliation runs per business day, mixing internal-vs-internal, D+1, and internal-vs-third-party comparisons.
• The build that actually satisfies the rules is a canonical safeguarding ledger, an automated statement-ingestion pipeline, a reconciliation engine with break workflows, a D+1 settlement tracker, and a first-class audit-trail layer. Typically Rust/Go + PostgreSQL + Redis + Kubernetes.
• The resolution pack requirement is its own engineering project — same source of truth, different consumers, different freshness guarantees, dry-run cadence essential.
• Firms whose existing safeguarding process is "manual CSV reconciliation once a week" have weeks, not months, to migrate. The audit cycle will catch this within the first reporting period.

As an AI Developer and fintech developer building crypto payment infrastructure and cross-border payout systems, this is exactly the kind of work that defines the next decade of UK payments engineering: less glamorous than agentic commerce, less talked about than stablecoins, but the operational substrate that makes everything above it actually safe to ship. The teams that build the safeguarding stack properly now are the teams that can credibly take on the agent-economy, stablecoin, and Open Banking workloads that land on top of it.