How to tokenize a fund in Europe

Tokenizing a fund in Europe takes three to six months and costs €120,000 to €400,000 for a first issuance. The work is not the token. It is the wrapper, the classification, the register owner, the depositary and the cash leg. This is the process, in order, with the timeline and the fees.

What does it actually mean to tokenize a fund?

Tokenizing a fund means issuing its units or shares as transferable records on a distributed ledger, and treating that ledger as the register of holders. Everything else about the fund stays where it was. The legal wrapper is a normal European fund vehicle. The manager is authorised. The depositary holds the assets. The administrator strikes NAV. Tokenization replaces one component — the register and the transfer mechanism — and leaves the other five in place.

That is a narrower change than the word suggests, and the narrowness is the point. A fund is not made better by being on a ledger. It is made faster to subscribe to, faster to transfer, cheaper to administer at scale, and continuously reconcilable rather than periodically reconstructed. Those are operational gains in the register, and they are the only gains tokenization delivers directly.

Three things are commonly claimed and are not true. Tokenization does not create liquidity: liquidity requires licensed distribution and a venue where transfers can occur, which is a separate build with its own permissions. Tokenization does not reduce regulation: a tokenized fund unit is a financial instrument and carries the same obligations as an untokenized one. And tokenization does not remove intermediaries: the depositary, administrator and transfer agent all remain, because their duties are legal rather than technical.

The six components, and which one changes

• Legal wrapper — the fund vehicle and its domicile. Unchanged.
• Manager — an authorised AIFM or UCITS management company. Unchanged.
• Depositary — safekeeping and oversight of the fund’s assets. Unchanged.
• Administrator — accounting and NAV calculation. Unchanged.
• Register and transfer agency — this is what tokenization changes. The holder record moves on-chain and transfer eligibility is enforced by the token.
• Distribution — placement to investors, requiring MiFID II permissions. Unchanged in substance, though a tokenized register makes onboarding and secondary transfer mechanically simpler.

If a provider proposes changing more than the fifth item, ask which authorisation covers the change. That question resolves most conversations quickly.

What the register change actually buys is worth stating in operational terms rather than in principle. Onboarding a new holder becomes a verification and whitelisting step rather than a paper transfer instruction routed between three parties. A secondary transfer between two eligible holders becomes a validated transaction rather than a bilateral process with a settlement lag and a manual register update. The holder list at any NAV date is read rather than assembled. And each of those improvements compounds with holder count: at twelve holders it is invisible, at three hundred it is the difference between a two-person operations function and a five-person one.

Who is commissioning this work in Europe is also instructive. It is predominantly managers of private funds — venture, private credit, real estate — with international holder bases and periodic subscription windows, plus securitisation arrangers issuing note-like instruments repeatedly from a single platform. The common factor is repetition: the economics of tokenization improve markedly on the second and third issuance from the same rails, because the fixed structuring and provider-onboarding costs are already spent. A manager planning one issuance and no successors should expect the cost case to be neutral at best, and should tokenize for the register quality rather than the savings.

Which EU legal wrapper do I need — UCITS, AIF, SPV or securitisation vehicle?

For a tokenized fund in Europe the answer is almost always an alternative investment fund or a securitisation vehicle. UCITS is available in theory and impractical today, because its eligible-asset rules under Directive 2009/65/EC were not written with ledger-native instruments in mind and its retail distribution obligations add cost that tokenization does not offset. A plain SPV without a fund manager is suitable only for single-asset or note-like structures.

The decision turns on four inputs: who the investors are, what the underlying assets are, whether you need a marketing passport, and whether the instrument is better expressed as a fund unit or as a debt security. The table below is the shortlist we work from in practice.

A short decision path

1. Are the assets liquid transferable securities and do you need retail distribution across the EEA? If yes, consider UCITS. If no, stop considering it.
2. Is this a pooled, actively managed portfolio for professional investors? Then an AIF — a Luxembourg RAIF or an Irish QIAIF — with an authorised AIFM.
3. Is it a single asset, a note, or a defined revenue stream, with the economics expressed as debt? Then a securitisation vehicle, usually with a segregated compartment per issuance.
4. Is the instrument intended to trade on a DLT market infrastructure from day one? Then structure with the pilot regime in view, and accept its volume caps.

Domicile follows the wrapper, and it also decides whether an on-chain register can be legally authoritative. Several member states have amended their securities or company law to recognise a distributed ledger as the register; others have not. Where they have not, the on-chain record runs alongside an authoritative off-chain register, which works but adds a reconciliation duty. Ask this question before you pick a domicile, not after.

Is my instrument a MiCA crypto-asset or a MiFID II financial instrument?

If the token represents a unit or share in a fund, it is a financial instrument and MiFID II applies. MiCA does not. Regulation (EU) 2023/1114 excludes crypto-assets that qualify as financial instruments from its own scope, so a MiCA CASP authorisation does not permit a firm to issue or place tokenized fund units. This is the single most expensive mistake in the category, and it is usually made at the point where a project chooses its service providers.

The test is substance, not form. A transferable instrument that carries a claim on a pool of assets, a share of profits, or a right to a return determined by the performance of a portfolio, sits within Annex I Section C of MiFID II. Naming it a utility token, issuing it on a public chain, or describing the holder as a member of a community does not change the analysis. Classification questions are settled against MiFID II and the guidance of ESMA, not against MiCA’s categories.

MiCA still matters to a tokenized fund, in two indirect ways. First, the cash leg: e-money tokens under MiCA are the most credible route to a same-ledger payment leg, and their issuers are authorised credit or electronic money institutions. Second, custody of any crypto-assets the fund itself holds is a MiCA service, distinct from the custody of the fund’s units. A fund that invests in digital assets and issues tokenized units therefore touches both regimes at once, through different providers with different permissions.

Who issues, who registers, who custodies and who settles?

Four distinct roles, four distinct permissions, and in most European structures four distinct entities. Issuance and placement require a MiFID II investment firm. The register is maintained by a transfer agent or registrar appointed under the fund documentation. Custody of the fund’s assets is the depositary’s duty; custody of any crypto-assets is a separately authorised service. Settlement of the units happens on the ledger, while settlement of the cash leg usually happens in the banking system.

The mistake to avoid is assuming a single technology vendor covers all four. Most platforms in this market supply the token standard and the register software, which is the technology layer, and then rely on licensed third parties for issuance, custody and distribution. That is a legitimate model, but it means the regulatory perimeter runs through several firms and the issuer carries the coordination burden.

Two structural notes. The depositary is not optional for an AIF, and a depositary that has never overseen a tokenized register will price its unfamiliarity into the fee — budget time for its operational due diligence. And the transfer agent role does not disappear when the register is on-chain: someone must remain legally accountable for the accuracy of the record, and that accountability should be named in the documentation rather than implied by the software.

What does the timeline look like, week by week?

A first tokenized issuance in Europe takes three to six months from decision to first settled subscription, assuming the fund vehicle either exists or is a standard product from a known domicile. Subsequent issuances on the same rails take four to eight weeks. The long pole is never the token. It is the depositary’s operational due diligence, the bank account, and — where a new vehicle is needed — regulator or domicile timetables that are outside your control.

Compressing this is mostly a matter of sequencing rather than speed. Start depositary and bank conversations in week two, not week eight. Freeze the eligibility matrix before token configuration begins. And run the dry run with real documents and a real NAV strike, because the breaks that matter appear in reconciliation, not in test transfers.

What does it cost, and what are the ongoing fees?

Budget €120,000 to €400,000 for a first European tokenized issuance, and €40,000 to €120,000 a year to run it, excluding the manager’s own costs. The range is wide because three items dominate and each varies by an order of magnitude: legal structuring, the depositary, and whether you are standing up a new vehicle or using an existing compartment. Anyone quoting a single number without knowing your wrapper and domicile is guessing.

Two economics to keep in view. First, tokenization does not pay for itself on a single small issuance — the fixed costs are front-loaded and the savings are per-transfer and per-reconciliation. The break-even is a function of holder count and transfer frequency, not of fund size. Second, the recurring cost of a tokenized register is lower than a manual one at scale, but only if you stop maintaining a parallel manual process. Firms that run both indefinitely pay for both.

Two further budget items are routinely omitted from first plans. The first is the internal cost: someone in the manager’s operations function has to own the whitelist, the reconciliation sign-off and the investor queries that arrive when a transfer fails a rule. Budget a meaningful fraction of one full-time role in the first year, less thereafter. The second is the cost of change: revising the eligibility matrix, adding a jurisdiction, or migrating to a new token standard is a controlled project with legal, technical and communication components, not a configuration edit. Structures that anticipate one change a year and price it are calm about it; structures that treat the configuration as permanent are not.

How do investors subscribe and redeem?

Subscription in a tokenized fund follows the same sequence as a conventional one, with two steps automated. The investor is onboarded and verified, their wallet address is added to the whitelist, they commit at a NAV struck on the fund’s schedule, they pay the cash leg, and units are minted to their address once payment is confirmed. Redemption reverses it: a redemption instruction, a NAV strike, burning or transferring the units, and payment out.

The automation is in eligibility and in the register. Because the token validates the receiving address against on-chain rules before any transfer executes, an ineligible holder cannot be onboarded by mistake and a transfer to an unverified wallet simply fails. And because the register is the ledger, the holder list after each subscription is authoritative immediately rather than after a reconciliation cycle.

What is not automated is the cash leg, in most structures today. Where payment is a bank transfer, the fund waits for confirmation before minting, which reintroduces a settlement gap of hours or days. Where the cash leg is a MiCA e-money token or tokenized deposit on the same ledger, subscription can settle atomically — the units and the payment move in one transaction, or neither moves. That is available now for some structures and not for all, and it is the honest dividing line between what tokenization delivers today and what is claimed for it.

The subscription cut-off, the NAV strike and the payment confirmation therefore remain the three dates that govern the experience, exactly as in a conventional fund. Where tokenization changes the experience is in what happens either side of those dates: onboarding a holder is faster because verification and whitelisting replace a paper chain, and the post-strike register is authoritative immediately rather than after reconciliation. Managers who expect the fund’s own terms to compress are disappointed; managers who expect the operations around those terms to get lighter are not.

Redemption deserves one specific note, because it is where structures diverge most. Units may be burned on redemption, which reduces units in issue and requires the administrator’s books to be updated in step, or transferred back to a treasury address held by the fund, which keeps units in issue constant and treats the treasury holding as unissued. Both are used. The choice affects the reconciliation design and the way units in issue are reported, so it should be settled during structuring rather than discovered at the first redemption window.

Practical constraints worth stating to investors up front

• Redemption terms come from the fund documentation, not from the technology. A quarterly-redemption fund does not become daily because it is tokenized.
• NAV frequency is unchanged. A ledger cannot value an illiquid portfolio more often than its administrator can.
• Secondary transfer between eligible holders is possible where the documentation permits it and a venue exists. Absent a venue, transfers are bilateral.
• The whitelist is a live obligation. An investor whose verification lapses can be blocked from receiving units, which needs to be explained before it happens.

What goes wrong, and how do you avoid it?

Five failure modes account for nearly every stalled European tokenization project, and none of them is technical. In order of frequency: the wrong classification, an unappointed register owner, a cash leg nobody designed, an eligibility matrix that changes after the token is configured, and a depositary brought in too late.

1. The wrong classification

A project selects a MiCA-oriented provider for what is a MiFID II instrument, then discovers at the placement stage that no one in the chain holds the permission to place it. This is recoverable but expensive: it usually means re-papering the offering and appointing a licensed issuance firm mid-process. Avoid it by obtaining a written classification view before selecting any provider.

2. No named owner of the register

The software maintains the record and everyone assumes accountability sits somewhere else. When the first break occurs, there is no party contractually responsible for resolving it. Name the transfer agent or registrar in the documentation and define the reconciliation process, including who signs off the holder list at each NAV date.

3. An undesigned cash leg

Asset-leg settlement is instant, so the cash leg is assumed to keep up. It does not. Decide early whether payment is fiat through a bank, an e-money token on the same ledger, or a hybrid, and state the resulting settlement timing in the subscription documents.

4. A moving eligibility matrix

Investor categories, jurisdictions and holding periods get revised after transfer rules are already encoded. Each revision is a re-configuration and, if the token is live, a controlled migration. Freeze the matrix before configuration and treat changes as a formal change process.

5. A late depositary

The depositary’s operational due diligence on a tokenized register is the most under-budgeted item in the plan. It is also the one you cannot compress, because it is their risk decision, not yours. Engage in week two and give them the token documentation, the transfer-rule logic and the reconciliation design in one package.

There is a sixth, softer failure: tokenizing without a reason. If a fund has twelve holders, no secondary transfer activity and an annual NAV, the register is not its constraint and tokenization will add cost without removing friction. The honest test is whether holder count, transfer frequency or onboarding volume is the thing slowing the fund down. Where it is, tokenization addresses it directly. Where it is not, it does not.