A Tokenized Share Class on a Fund That Already Exists

An asset manager is asked by a client, or watches a competitor announce, on-chain access to a fund. The obvious options are expensive: launch a new fund built for a ledger, or re-plumb an existing one. This pattern is a third and cheaper route. One share class of a fund already in market gains a token, while the fund keeps its authorisation, its portfolio, its track record, its ratings, its depositary and its transfer agent. MiCA does not apply, because a fund unit is a MiFID II financial instrument that Art. 2(4)(a) excludes, and UCITS or AIFMD applies exactly as before because the fund itself is unchanged.

The largest managers have now done it in a form regulators have seen, disproportionately in money market funds where demand for an on-chain cash-equivalent sits. Twelve tokenised share classes across six money market funds went live on 4 August 2026, and a national regulator approved a further tokenised class on 6 August 2026. For an incumbent manager it is a way to give existing clients on-chain access to the fund they already know, on regulated rails, without a new authorisation or a change to the register of record.

• Yes if you manage an authorised fund already in market - money market funds most of all - a client or a competitor has raised on-chain access, and you would rather extend the fund you have than launch one you do not.
• Not if the fund does not exist yet (tokenizing the register from the start is a different blueprint), if you are the administrator wanting to sell this to your manager clients (different buyer, different economics), or if the token has to trade on a venue - that changes the regime entirely.

A token can move around the clock, while the fund redeems at a cut-off. If holders treat continuous transfer as continuous redemption, the mismatch can become a run, and the ECB named exactly this as the central risk of tokenised money market funds in April 2026.

The largest live instance answers it with an asymmetry worth copying exactly: secondary transfer between approved wallets runs 24/7, while minting and redemption stay on the fund's own hours. Transfer is continuous and primary dealing is unchanged. Because a top-tier manager has already built it, it is a straightforward design to put in front of a risk committee.

• The register does not move. The token is a synchronised representation of a register your transfer agent already keeps. Nothing about the fund's authorisation, portfolio, depositary or administrator changes, which is why this is the lowest-friction route in the tokenization cluster.
• MiCA does not apply to the token. A fund unit is a MiFID financial instrument and MiCA Art. 2(4)(a) excludes it, so no crypto-asset authorisation enters the picture. No DLT Pilot Regime licence either, because nothing lists on a venue.
• Two variants, and the choice is a documentation question: tokenize an existing class (what most incumbents do first) or create a natively tokenized class on the same fund (rarer, more capable, more paperwork).
• The sync layer is the only genuinely rentable piece in the whole stack: a bank-operated translation platform, a distribution platform's variant, or an open compliance-token standard. Two credible alternatives at every layer.