UK authorised funds · FCA PS26/7
Since 30 April 2026 the FCA Handbook has set out how an authorised fund manager can keep the unitholder register on a blockchain. The guidance is written as outcomes, and each outcome has to be met by the technology underneath the register. Tokenistry Core supplies that technology — the token, the rules for who may hold it, and a register that aggregates and reconciles — running in your own cloud account.
The guidance sits in COLL 6 Annex 4. It applies to UCITS schemes and non-UCITS retail schemes, and the FCA extended it to qualified investor schemes and long-term asset funds. It settles three things fund managers had been asking about: the on-chain record of transactions may be the primary books and records, units in one class may sit on more than one blockchain, and public networks such as Ethereum may be used where the controls meet the rules.
It also keeps one thing fixed. The firm responsible for the register must be able to amend it without the consent of anyone else. Most of what follows is a consequence of that.
Paraphrased rather than quoted, and not legal advice: the guidance is illustrative, and your counsel reads the Handbook text. The right-hand column is what the software does, not a claim that doing it makes a fund compliant.
| Guidance | What it asks for | What Core does |
|---|---|---|
| 4.5G | The on-chain record of transactions may be treated as the primary books and records for unit deals, with no duplicate off-chain mirror. | The Indexing Engine reads canonical chain state with reorg handling and backfill, and the Ownership Engine derives the register from it rather than from what an application says it wrote. |
| 4.8G–4.9G | The responsible firm can amend the register without any third party's consent. That power may not exist by default; smart contracts, key control or a master-node function can provide it. | Mint, burn, freezing an exact amount and forced transfer are contract functions behind roles. The authority key sits in your custody workspace, and eligibility administration can sit on a separate key. |
| 4.10G | Units in one class may use more than one DLT network, provided holders' rights and charges stay the same. | EVM chains, public or permissioned. Each chain deployment is its own asset against the same investor records, so holdings are reported per chain and per investor. |
| 4.12G–4.13G | Where distributors or unitholders can write to the ledger, the firm must still be able to reverse incorrect entries, and needs procedures to find them. | The Ownership Engine flags anomalies against chain state. A correction is a new transaction — a forced transfer or a burn — so the history keeps both the error and the fix. |
| 4.14G–4.17G | Controls so units move only to, from or between eligible unitholders: an allow list of verified addresses, including access to particular classes. | The token checks the Eligibility Engine registry inside every transfer, with separate send and receive permissions, and moves nothing when no list is attached. Each unit class is its own token with its own eligibility rules. |
| 4.18G | Smart contracts relied on for eligibility or fund operation should be regularly audited. | The contract source is open to your reviewers. An external audit of our own contracts has not been completed yet; ask where it stands before you rely on them. |
| 4.19G–4.21G | The register states units per class per unitholder, so systems must aggregate a holder's positions across wallets and blocks. | Wallets are assigned to investors, and positions are reported per investor across all of their wallets. A move between one investor's own wallets is a reallocation, not a change of owner. |
| 4.22G–4.26G | Plans for a network outage: risk policies, alternative ways to deal, and wind-up procedures if the network is lost for an extended period. | The derived register lives in your PostgreSQL database and stays readable while the chain is not. Pending operations wait in a durable queue and resume. The alternative dealing and wind-up procedures are yours. |
| 4.27G–4.28G | The register is available for inspection free of charge in the UK, combining on-chain and off-chain records where that cannot be done on DLT alone. | Single-tenant in your cloud account, in the region you choose, London included. Holders per unit class and positions per investor are API reads for whatever inspection process you run. |
| 4.29G | Public or consortium networks may operate overseas; consider whether that affects the scheme's domicile. | The chain is a deployment decision rather than an architectural one. The domicile assessment is yours. |
| 4.32G–4.33G | Data protection, particularly on public networks where records are permanent and not encrypted by default. | No personal data goes on chain. Contracts hold addresses and permission flags; who an address belongs to stays in your database. |
Source: FCA, PS26/7 Progressing fund tokenisation, 30 April 2026, and the COLL 6 Annex 4 guidance it inserted.
Authority over the register and the keys that exercise it. Eligibility decisions, KYC and AML. Dealing, the issue and cancellation account and any Direct to Fund model. Depositary oversight. The choice of network, and the outage and wind-up procedures.
Token contracts, eligibility enforcement, transaction orchestration and custody signing, indexing, the ownership register and reconciliation — deployed, integrated and supported. Tokenistry is a software supplier: not a transfer agent, registrar, depositary, custodian or distributor, and it holds no FCA permissions.
| Firm | Typical starting point | What matters most |
|---|---|---|
| Authorised fund managers | A tokenised unit class alongside an existing register | Unilateral correction, eligibility per class, aggregation across wallets |
| Transfer agents & fund administrators | A DLT register offered to several managers | One deployment per client, reconciliation, anomalies worked as a queue |
| LTAF & private-markets managers | Less liquid units with restricted, infrequent transfers | Eligibility that fails closed, lot-level lineage for redemptions |
| Depositaries | Oversight of on-chain activity they did not initiate | Evidence of what moved and why, from a reconciliation that holds no key |
Core executes the unit side of a deal when your dealing process instructs it. The money side runs in systems you already have, and a tokenised register does not change that.
Licensed and customer-hosted: container images, a Helm chart and Terraform modules in your own cloud account, against databases you hold, with your custody workspace holding the keys. Source escrow and documented exit provisions are available where continuity has to be evidenced.
That is the model that fits an authorised fund. An operated deployment also exists, for issuers without a technology function; it puts Tokenistry in the operating path, which is a different conversation with your risk function. More on the licensed model under institutional tokenisation.
Outcomes rather than a design. The ones that land on technology are in COLL 6 Annex 4: the firm can amend the register without anyone else's consent, units move only between eligible holders, a holder's positions can be aggregated across wallets, incorrect entries can be found and reversed, the register can be inspected in the UK, and there is a plan for a network outage. The table above maps each one to what the software does.
The FCA has said public networks may be used where the controls meet its rules, and that using a public network in fund management is not in itself outsourcing. The tokens here run on EVM chains, public or permissioned. The domicile and data-protection assessment for a public network is the manager's.
Through contract functions only the manager's roles can call: mint, burn, freezing an exact amount and forced transfer. The keys behind those roles sit in the manager's custody workspace, so no distributor, unitholder or supplier has to agree to a correction.
Each wallet is assigned to an investor, and the Ownership Engine reports positions per investor across all of them. A transfer between two wallets of the same investor is a reallocation rather than a disposal, and a wallet nobody has claimed shows up as unmapped rather than being guessed at.
No. The manager, or the transfer agent it appoints, keeps the register and the authority over it. Tokenistry supplies the software that register runs on.
The unit side, yes: Core mints, burns and transfers units when your dealing process instructs it, whichever dealing model you run. The cash side is outside Core: the issue and cancellation account and its reconciliation, and settlement in stablecoins or tokenised cash.
Not yet by an external firm. The guidance expects contracts relied on for eligibility or fund operation to be regularly audited, so ask where our audit stands before relying on them. The source is available to your own reviewers in the meantime.
Yes. The FCA applied the same DLT register guidance to qualified investor schemes and long-term asset funds, with their own register rules substituted. The technology does not change between fund types; eligibility rules and transfer restrictions differ per fund and are configuration.
The register Core derives lives in your own database and stays readable, and operations waiting to be sent sit in a durable queue until the network returns. The guidance also expects alternative dealing processes and, for a prolonged outage, wind-up procedures; those belong to the manager and the depositary.
Technically a class is one token with its own supply and eligibility rules, alongside the others. Whether that is a new class, a change to an existing one or a new fund is a question for your counsel, your prospectus and the FCA, not for the software.
Tell us the fund type, the network you have in mind and who keeps the register today. We will map it against Annex 4 and say which parts Core covers and which stay with you.
Discuss a tokenised fund