FCA Fund Tokenisation DLT Guidance for Asset Managers

The FCA's October 2023 letter to fund managers on DLT-based fund tokenisation, followed by the Investment Management Association's joint work with HM Treasury under the Asset Management Taskforce, set a hard expectation: UK-authorised funds operating on distributed ledger infrastructure must demonstrate regulatory compliance before going live, not after. The FCA's Technology Working Group published its fund tokenisation roadmap in late 2023, and the regulator has since been clear that sandbox participation is not a substitute for meeting existing COLL and COBS obligations. If you're building or advising on a tokenised fund structure in the UK, the compliance clock is already running.

TL;DR

• The FCA permits DLT-based fund tokenisation within existing regulatory frameworks, but firms must map every tokenisation function to a specific COLL or COBS rule before launch.
• Transfer agent and register functions on-chain require explicit FCA authorisation or a compliant outsourcing arrangement under SYSC 8.
• The FCA's sandbox (formerly the Regulatory Sandbox, now the Digital Securities Sandbox operated jointly with the Bank of England) offers a structured path for novel structures, but admission is not guaranteed.
• AML/KYC obligations under the Money Laundering Regulations 2017 apply in full to tokenised fund units, regardless of the underlying technology.
• Custody of tokenised fund units triggers CASS 6 safeguarding rules; firms cannot contract out of this by pointing to smart contract self-custody.

What This Regulation Actually Requires

The Existing Regulatory Perimeter

The FCA has not created a bespoke tokenisation regime. Instead, it has confirmed that the Collective Investment Schemes sourcebook (COLL), the Conduct of Business sourcebook (COBS), and the Senior Managers and Certification Regime (SM&CR) apply to tokenised funds in the same way they apply to conventional ones. A tokenised unit in a UK UCITS or Non-UCITS Retail Scheme (NURS) is still a unit. The fact that ownership is recorded on a blockchain rather than a traditional register doesn't change the legal character of the instrument.

This matters because it closes off a common misconception: that tokenisation is a technology project rather than a regulated activity. Issuing, transferring, or redeeming tokenised fund units is a regulated activity under the Financial Services and Markets Act 2000 (FSMA), specifically under the Regulated Activities Order 2001 (RAO), Article 51 (establishing, operating, or winding up a collective investment scheme).

COLL Sourcebook Requirements

COLL 6.3 governs the register of unitholders. Any DLT-based register must still satisfy the requirements for accuracy, accessibility, and auditability that COLL 6.3 imposes. The FCA has indicated it will scrutinise whether a blockchain-based register can be amended in the event of error, court order, or regulatory direction. Immutability, a feature often marketed as a benefit of DLT, becomes a compliance problem if it prevents the authorised fund manager (AFM) from correcting a register entry when legally required to do so.

COLL 4.2 requires the prospectus to disclose all material risks. A tokenised fund's prospectus must therefore address smart contract risk, oracle risk, network congestion risk, and the risk of private key loss. Boilerplate technology risk language won't satisfy this requirement.

COBS and Investor Protection

COBS 2.1 (acting honestly, fairly, and professionally) and COBS 4 (communicating with clients) apply to all marketing of tokenised fund units. The FCA has specifically flagged that firms must not imply that tokenisation confers liquidity benefits that the underlying fund structure doesn't actually support. A daily-dealing NURS tokenised on a blockchain is still a daily-dealing fund; secondary market trading of tokens between investors doesn't change the fund's redemption terms.

SYSC 8: Outsourcing and Third-Party Risk

When a firm uses a third-party blockchain protocol, smart contract developer, or DLT infrastructure provider, SYSC 8 outsourcing rules apply. The FCA expects firms to conduct due diligence on the DLT provider equivalent to what they'd apply to any material outsourcing. This includes business continuity planning for protocol upgrades, hard forks, and smart contract vulnerabilities. Firms must retain the ability to terminate the arrangement and migrate to an alternative without material disruption to investors.

The Digital Securities Sandbox

The Financial Services and Markets Act 2023 created the Digital Securities Sandbox (DSS), jointly administered by the FCA and the Bank of England. The DSS allows firms to test DLT-based securities infrastructure, including fund unit registers, under modified regulatory conditions. Admission to the DSS requires a detailed application demonstrating the specific regulatory modifications sought, the safeguards in place, and the exit plan if the sandbox activity is wound down. As of early 2026, the FCA has admitted a limited cohort of firms; the sandbox is not open-ended.

AML and the Money Laundering Regulations 2017

Tokenised fund units are not crypto-assets for the purposes of the MLRs' crypto-asset business registration requirement, but the fund manager and any distributor remain obliged persons under the MLRs. Customer due diligence (CDD) must be conducted on investors acquiring tokenised units. The FCA has flagged that smart contract-based transfers between wallets don't automatically satisfy the Travel Rule obligations under the Wire Transfer Regulation 2017, as amended. Firms need to think carefully about how CDD data travels with the token.

What This Means for Your Company

If you're an authorised fund manager considering tokenisation, the practical implication is that you need a dual-track analysis: technology architecture and regulatory mapping must happen simultaneously, not sequentially.

Firms that have approached tokenisation as a technology upgrade and then tried to retrofit compliance have consistently run into problems at the FCA authorisation or variation-of-permission stage. The FCA's supervisory teams have asked detailed questions about how the AFM retains control over the register, how errors are corrected, and how the depositary's oversight function operates when assets are held in smart contracts.

For fund administrators and transfer agents, tokenisation changes the operational model significantly. If the blockchain is the register, who is the registrar? The FCA expects a regulated entity to remain responsible for register accuracy. Distributed consensus doesn't satisfy the requirement for a responsible person.

Depositaries face a specific challenge under COLL 6.6B. The depositary must be able to verify that the fund's assets are properly safeguarded. For tokenised funds, this means the depositary needs to understand and audit the smart contract logic, not just receive a periodic report from the manager.

How to Operationalize

Step 1: Regulatory mapping exercise. Before any technology decisions, map every function in your proposed tokenised fund structure to a specific FCA rule. Register maintenance, unit issuance, redemption processing, distribution, custody, and reporting each need a named regulatory owner and a named rule.

Step 2: Prospectus and constitutional document review. Engage fund counsel to update the prospectus, instrument of incorporation, and key investor information document (KIID or KID) to reflect DLT-specific risks. The FCA expects this to be substantive, not a one-line addition.

Step 3: Depositary engagement. Bring your depositary into the design process early. Depositaries have their own FCA obligations and their own risk appetite. Several UK depositaries have published internal policies on DLT-based fund structures; understand their requirements before finalising your architecture.

Step 4: SYSC 8 outsourcing assessment. Conduct a formal outsourcing risk assessment on every third-party DLT component. Document the due diligence, the contractual protections, and the exit strategy. This documentation will be requested by the FCA.

Step 5: AML/CDD workflow design. Design the investor onboarding and transfer workflow to capture and transmit CDD data in compliance with the MLRs and the Wire Transfer Regulation. If you're using a permissioned blockchain, consider how whitelisting of wallet addresses integrates with your CDD process.

Step 6: DSS application assessment. Evaluate whether your structure requires regulatory modifications that only the DSS can provide. If so, prepare a DSS application. If not, document why existing rules are satisfied without sandbox participation.

Step 7: FCA pre-application engagement. Use the FCA's Innovation Pathways service (formerly the Regulatory Sandbox pre-application process) to engage with the FCA before submitting a variation of permission or new authorisation application. The FCA has been receptive to early engagement on novel structures.

Step 8: Ongoing governance. Establish a governance framework for smart contract upgrades, protocol changes, and incident response. The FCA expects this to be documented and tested, not theoretical.

Common Mistakes and How to Avoid Them

Treating the blockchain as the compliance solution. Immutability and transparency are properties of the ledger, not substitutes for regulatory compliance. The FCA doesn't accept "the blockchain is auditable" as a response to a COLL 6.3 register requirement question.

Underestimating depositary friction. Depositaries are conservative institutions with their own regulatory obligations. Assuming your depositary will simply adapt to your DLT architecture is a project risk that has derailed several UK tokenisation initiatives. Engage early, in writing, and get their requirements documented.

Ignoring the prospectus. Several firms have built technically sophisticated tokenised fund structures and then discovered that their existing prospectus doesn't permit DLT-based register maintenance. Amending a UCITS prospectus requires FCA approval and takes time. Build this into your project timeline.

Conflating DSS participation with regulatory approval. The DSS allows firms to test under modified rules. It doesn't mean the FCA has approved the structure for general deployment. Firms must still obtain appropriate authorisation or variation of permission before launching to investors outside the sandbox.

Mishandling the Travel Rule. The Wire Transfer Regulation 2017 requires that certain information accompany fund transfers. When transfers happen via smart contract, the mechanism for transmitting this information isn't automatic. Firms that haven't designed this into their architecture face a compliance gap that's expensive to fix post-launch.

Assuming retail eligibility. Tokenised fund units are not automatically eligible for retail distribution. The fund's existing retail eligibility (or lack thereof) carries over. Tokenisation doesn't change the investor categorisation requirements under COBS 3.

FAQ

Q: Does the FCA require a separate authorisation for a tokenised fund, or does an existing AFM authorisation cover it?

An existing AFM authorisation covers the activity of operating a collective investment scheme, including a tokenised one. However, if the tokenised structure involves activities that fall outside the scope of the existing permission (for example, operating a DLT-based trading venue for secondary market transactions in fund units), a variation of permission or additional authorisation may be required. The FCA's Innovation Pathways service can help clarify this before you apply.

Q: Can a tokenised fund unit be held in self-custody by the investor?

Technically possible in some DLT architectures, but it creates significant CASS 6 and COLL 6.6B complications. The depositary's oversight function requires it to be able to verify safeguarding of assets. If units are in investor-controlled wallets, the depositary needs a mechanism to verify this. The FCA hasn't prohibited self-custody arrangements, but it expects firms to demonstrate how depositary oversight is maintained.

Q: How does the FCA treat smart contract bugs or exploits that affect the fund register?

The AFM remains responsible for register accuracy under COLL 6.3 regardless of the cause of any error. A smart contract exploit is treated as an operational failure of the AFM, not a force majeure event. This is why SYSC 8 outsourcing due diligence on smart contract developers and auditors is so important.

Q: Are there specific FCA rules on the use of oracles in tokenised fund structures?

No oracle-specific rules exist yet, but the FCA's general principles on data integrity and the COLL requirements for accurate NAV calculation apply. If your fund uses an oracle to feed NAV data into a smart contract for automated redemption processing, the oracle is a material component of your NAV calculation process and must be subject to appropriate controls and oversight.

Q: Can a non-UK DLT infrastructure provider be used for a UK-authorised fund?

Yes, but SYSC 8 applies in full, and the FCA expects the AFM to be able to demonstrate that it can exercise effective oversight of the provider regardless of its location. Post-Brexit, the FCA has been explicit that it won't accept "the provider is regulated elsewhere" as a substitute for the AFM's own due diligence and contractual protections.

Sources

• Financial Conduct Authority, COLL Sourcebook, FCA Handbook (current version)
• Financial Conduct Authority, SYSC 8: Outsourcing, FCA Handbook (current version)
• HM Treasury and FCA, Asset Management Taskforce: Fund Tokenisation Working Group Report, 2023
• Bank of England and FCA, Digital Securities Sandbox: Policy Statement, 2024

---

Disclaimer: This article is produced by BizLegal-AI Intelligence Desk for general informational purposes only. It does not constitute legal advice and does not create a solicitor-client or adviser-client relationship. Regulatory requirements change frequently; readers should verify current rules with the FCA Handbook and seek qualified legal counsel before making compliance decisions. BizLegal-AI is not a law firm and does not provide regulated legal services.