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:
- Daily reconciliation of safeguarded funds.
- Monthly reporting confirming safeguarding practices and reconciliation outcomes.
- 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).
- Resolution packs that allow safeguarded funds to be distributed quickly in a wind-down.
- 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.
Read the full article on tomcn.uk →
About the Author
I'm Tom Wang, an AI Developer & Fintech Developer — building AI agents, crypto payment infrastructure, and cross-border payout systems with Rust, Go, and TypeScript. Based in London, UK.
Currently open to new opportunities in fintech, crypto payments, and AI agent engineering.
Top comments (1)
Good piece — the "six reconciliations a day" framing is the bit most non-engineers underestimate. Want to push on one specific angle that I think gets missed: the daily reconciliation requirement is fundamentally a data problem, not a ledger problem.
Your internal ledger knows what the safeguarding requirement should be — that's deterministic, you control it. The hard part is the "safeguarding resource" side: pulling structured, current balances and transactions from the safeguarding accounts at every UK safeguarding bank or custodian you use, every business day, and reconciling them against the D+1 confirmation and the external comparison. CSV exports emailed by a relationship manager don't survive that cadence.
This is where PSD2 Account Information Services (AIS) APIs stop being a consumer-app feature and start being regulatory plumbing. The exact same structured bank-data feeds that power a budgeting app are what a CASS 15 reconciliation job needs to read its own safeguarding accounts programmatically. If your AIS feeds are clean and timestamped, the daily check collapses to a few JOINs and an alert.
The wrinkle that bugs me, though: PSD2 obliges banks to expose AIS APIs, but consuming them in your own right requires an eIDAS QWAC+QSeal cert (roughly €2–10k/yr) plus AISP authorisation or registration. That's table stakes for a mid-sized PISP, but it prices smaller payment firms out of building the reconciliation automation themselves and pushes them onto third-party AIS aggregators — a gap between "the data exists" and "you can afford to read it." Worth thinking about whether the FCA intended that dependency.
Anyone here building the reconciliation side of CASS 15 in-house vs. buying it? Curious how people are modelling the D+1 confirmation lag in particular.
Disclosure: I maintain open-banking.io