FCA PS26/7 and Cadmos: convergent compliance

On 30 April 2026 the Financial Conduct Authority — the UK's financial regulator — finalised PS26/7 — Progressing Fund Tokenisation, its rulebook for tokenised authorised funds. The headline change is a new optional dealing model called Direct-to-Fund, which lets investors deal units with the fund itself rather than via the manager's principal book. The substance is more interesting. PS26/7 is technology-neutral. It tells UK fund managers and depositaries what a tokenised fund must achieve — control of the register, embedded eligibility, reproducible records, operational resilience — then leaves the technology layer to figure out how. The expectations look a great deal like Switzerland's DLT Act, only with the UK fund-management cast of characters in the picture.

This article walks through who PS26/7 applies to, what it actually requires, and how Cadmos's smart contract layer answers the four expectations that sit on the technology side of the line. A companion piece — Cadmos under Swiss DLT law — covers the same primitives mapped onto the Swiss regime. The full architectural detail lives at docs.cadmos.finance.

What PS26/7 introduces — and to whom

PS26/7 applies to UK authorised funds — funds that must be cleared by the FCA before being marketed to UK investors. Two main wrappers are in scope: UCITS (Undertakings for Collective Investment in Transferable Securities, the EU-derived retail-investor wrapper retained in UK law post-Brexit) and AIFs (Alternative Investment Funds, including most private-market vehicles). Each authorised fund has an authorised fund manager (AFM) who runs it, and a depositary who provides independent oversight, holds the fund's assets, and protects investor interests.

PS26/7 is, in plain terms, the FCA's rulebook for how AFMs and depositaries can use blockchain technology — distributed ledger technology, or DLT — for the unitholder register and primary-market dealing, without changing what they have to achieve. The headline addition is an optional new dealing route called Direct-to-Fund (D2F), under which investors deal units directly with the fund itself rather than through the AFM's principal book.

Cadmos at a glance

Cadmos's smart contract layer is built around five components, all open-source and documented at docs.cadmos.finance:

• The fund token. The ERC-20 unit each investor holds.
• The administrator. A privileged module that controls who in the fund's operations team can do what — issue units, freeze accounts, force a transfer. Permissions are fine-grained: 53 individually assignable flags, each tied to a specific operations address.
• The whitelist. The on-chain investor register. Only whitelisted addresses can subscribe to, hold, or transfer fund tokens.
• The primary market. A pair of settlement contracts — one for subscriptions, one for redemptions — that batch investor flows, price units at the published NAV (net asset value), and settle the cash and token legs in coordinated steps.
• The protocol registry. Governs upgrades. New contract versions register here; each fund's administrator independently chooses whether and when to adopt them.

With that orientation, the four PS26/7 expectations that sit on the technology side of the line are easy to map.

What PS26/7 actually requires

The FCA's framing is deliberately conservative: tokenisation does not change what an authorised fund must do, only the medium it does it in. The substantive expectations spelled out in PS26/7 (and signalled in the prior consultation, CP25/28, in October 2025) are:

• Tokenised registers within existing rules. DLT is a recording medium for the register of unitholders, not a regulatory carve-out. The register itself remains within the existing UK fund rulebooks (COLL for retail funds, the OEIC Regulations for the corporate vehicles many UCITS use).
• Embedded eligibility controls. Smart contracts should enforce eligibility — investor class constraints, minimum holdings, tax status — at the token level. Allow-list models referencing verified wallet addresses are the FCA's reference architecture; ERC-3643, an open token standard for compliance-aware securities, is named as an acceptable template.
• Power of correction held by the AFM or depositary. Whoever maintains the register must retain the power to make unilateral corrections — through minting, burning, corrective transactions, or contractual rights embedded in the smart contracts.
• Reproducible, reconcilable records. The register must be reproducible in legible form in the UK and accessible to investors, depositaries, and the FCA. On-chain and off-chain records can combine, provided together they meet the inspection and aggregation requirements; aggregation across multiple wallets at the unitholder level is required.
• AML "relevant person" analysis. Direct dealing complicates who performs the customer-identity and anti-money-laundering checks (commonly KYC and AML) under the UK Money Laundering Regulations (MLRs). For investment companies with variable capital — ICVCs, the legal form most UCITS take — the AFM as corporate director performs KYC for the fund itself; for other authorised funds, scheme documents must be explicit about who carries the AML relationship.
• Operational resilience for DLT. Outage and degradation scenarios must sit in the AFM's risk framework, with alternative processes that allow dealing, redemption, and orderly wind-up if the network is unavailable. Public or permissionless network use is not, in itself, treated as outsourcing.
• Direct-to-Fund mechanics. Under the optional D2F route, the fund or depositary issues and cancels units directly with investors via a dedicated Issues and Cancellations Account (IAC) — a segregated bank account with prompt attribution rules and no end-of-day overdrafts.

The four things that matter for the technology layer

For a platform sitting under an FCA-authorised AFM, four of those expectations sit on the technology side of the line:

• Embedded eligibility. The token has to refuse transfers to ineligible wallets, every time. A whitelist that lives off-chain or behind an admin queue does not survive PS26/7's inspection requirements.
• Power of correction. The AFM or depositary must be able to mint, burn, force-transfer, or freeze — and every such action must be logged, reviewable, and contained within their authority.
• Audit-ready records. The state of the register at any prior date must be reconstructable from on-chain events alone, with off-chain documents reachable through stable references.
• Operational resilience. The AFM's pool must keep working even if the underlying protocol changes or fails. Upgrades cannot be unilateral on the part of a third-party platform.

How the Cadmos stack maps

Whitelist and embedded eligibility

Cadmos's whitelist module is consulted on every transfer of the fund token, refusing any move to an address outside the eligibility set — including issuance and redemption, not only secondary trading. Both batch on-chain registration and gasless signature-based whitelisting are supported, and account freeze is available for regulatory holds. The pattern is functionally equivalent to the ERC-3643 / allow-list architecture PS26/7 references.

AFM and depositary correction power

The administrator module exposes a structurally protected forced-transfer flag — the regulated party can re-route a holding when a court order, inheritance, or correction demands it. New units are minted and old units burned through the primary-market modules, which gate issuance and cancellation under the AFM's control. Every privileged action emits an on-chain event; corrections never go silent.

Reconcilable records

The fund token uses OpenZeppelin's snapshot extension — an open-source Solidity library that lets the contract record every holder's balance at periodic checkpoints. The full register at any past block is queryable on-chain. Privileged actions emit events. The token's metadata URI points at off-chain legal documents pinned to a stable reference. On-chain plus off-chain combine cleanly into the FCA's "reproducible in legible form" standard.

Wallet-to-unitholder aggregation

PS26/7 requires AFMs to aggregate holdings at the unitholder level across multiple wallets. Cadmos's admin tooling supports this aggregation natively — a beneficial-ownership view at the AFM portal, wallet-level enforcement at the token. The same investor with three wallets reads as one unitholder for register, KYC, and concentration purposes.

Operational resilience and upgrade governance

Upgrades are opt-in. The platform team can register a new contract version, but each issuer's pool administrator must independently activate it for their pool, behind a 15-minute on-chain timelock. The protocol registry's ownership transfer is two-step (a new owner must accept the role, not just receive it). The architecture means an FCA-authorised AFM's pool is not silently changed underneath it — the same answer that satisfies Switzerland's Article 973d CO integrity pillar.

What stays with the AFM and depositary

PS26/7 regulates UK authorised fund managers and depositaries, not technology providers. Cadmos is the technology layer. The regulated functions — unit dealing, register maintenance, AML "relevant person" status under the Money Laundering Regulations, depositary oversight, the Issues and Cancellations Account if Direct-to-Fund is adopted — sit with the FCA-authorised parties. Cadmos's job is to provide the on-chain primitives that make those regulated functions auditable and efficient: a whitelist the AFM can rely on, a forced-transfer right the AFM can exercise, snapshots the depositary can reconcile against. The role line is clean — the regulated party holds the regulatory burden; Cadmos provides the rails.

Switzerland and the UK are converging

The FCA's headline expectations — embedded eligibility, power of correction, reproducible records, operational resilience — are the same architectural primitives Switzerland's Article 973d CO has required since 2021. The Swiss mapping is covered in detail in the companion article. A platform that meets one regime's primitives tends to meet the other's, because the two regulators are answering the same question — what does it take to make a tokenised fund unit legally and operationally sound? — and arriving at the same engineering answer. Cadmos's stack is one such platform. For a UK manager evaluating Cadmos, the practical implication is that the smart contract layer underneath is already running under a regime — Switzerland's — that asked many of the same questions PS26/7 asks now.

The convergence is the point

Tokenisation infrastructure that meets only one regulator is technical debt. PS26/7 codifies what Switzerland already established: tokenised funds need the same set of primitives — embedded eligibility, power of correction, reproducible records, operational resilience — wherever they are launched. Cadmos's stack meets those primitives by construction. The regulated functions stay where they belong, with the AFM and depositary; the technology stays where it belongs, in code that can be audited and depended on.

For deeper detail on any module described here, see docs.cadmos.finance.