Daniil Kozin Tokenization strategy call
Guide · For business owners and CFOs · Updated June 2026

Does tokenizing a real asset need a MiCA or CASP licence? The 2026 EU map.

It is the question that stops a lot of operators before they start, and the honest answer surprises most of them. In the typical real-asset raise, the answer is no: a tokenized interest in your asset is usually a security, governed by the rules that already govern securities, not by MiCA. This guide draws the precise map: when MiCA does not apply and why, the narrow cases where it does, the separate fund question under AIFMD, the licences your platform holds so you do not have to, and what you actually need to issue compliantly. A structural map, written by a practitioner. It is not legal advice.

4,300 words · 17 min read By Daniil Kozin · Tokenization advisor
01 / The short answer

For a normal real-asset raise, you do not need a MiCA or CASP licence.

The direct answer

In most cases, no. Tokenizing a real asset to raise capital does not require a MiCA authorization or a CASP licence, because a tokenized interest in a real-asset SPV is normally a transferable security, which is a financial instrument under MiFID II, and financial instruments are explicitly carved out of MiCA.

What governs the raise instead is securities law: MiFID II, the Prospectus Regulation (where a private placement usually relies on an exemption rather than a full prospectus), national private-placement rules, and, for any regulated secondary trading, the DLT Pilot Regime. The classification of your specific token has to be confirmed for each structure, but for the typical real-asset raise, MiCA simply is not the relevant regime.

This is the single most common misconception I correct on a first call. The presence of a blockchain makes people assume the project lives in MiCA's world of crypto-assets, exchanges, and CASP authorizations. It usually does not. The token is a wrapper on a security, and the law follows the substance of what the holder owns, not the technology used to record it. A holder who has bought a claim on the rental income and value of a warehouse owns a security, whether that claim is recorded on a paper register or an on-chain one.

The rest of this guide explains why that is the case, draws the line precisely so you can see which side your project sits on, and sets out the narrow situations where MiCA genuinely does apply. The practical payoff is large: the difference between needing your own MiCA authorization and relying on a well-structured securities offering with authorized service providers is the difference between a year of licensing and a normal structuring timeline.

02 / Why

Securities and crypto-assets are two different regimes.

EU law puts a token in one of two regimes, and never both. The boundary between them is the entire question, so it is worth drawing carefully.

Regime What it governs Typical tokenized real-asset interest
MiFID II + Prospectus RegulationFinancial instruments: transferable securities such as shares, bonds, participations, and tokenized claims on an asset's economicsYes, this is the usual home
MiCACrypto-assets that are not financial instruments: asset-referenced tokens, e-money tokens, and other crypto-assets (utility, payment)No, unless the token is genuinely non-security

MiCA contains an express exclusion for crypto-assets that qualify as financial instruments under MiFID II. That exclusion is what does the work. The moment your token is a transferable security, it is outside MiCA by definition and inside the long-established securities framework. And a tokenized interest in a real-asset SPV almost always is a transferable security, because investors are buying a negotiable claim on the asset's economics, the rental income, the energy revenue, the share of value on a sale or refinance. That is the textbook profile of a security.

The corollary matters too. If a token were structured so that it is genuinely not a security, a pure utility token granting access to a service, or an asset-referenced token built to function as a means of payment, then MiCA would apply and MiFID II would not. So the classification is not automatic; it depends on what the holder actually owns. But for a capital raise against a real asset, where the whole point is to give investors a return tied to that asset, the natural and usual structure is a security, and that puts the project under securities law, not MiCA.

The test in one line: ask what the holder owns. If it is a claim on an asset's cash flow and value, that is a security, and securities law governs. If it is access to a service or a payment instrument, that is a MiCA crypto-asset. A real-asset raise is the first kind. The blockchain is the registry, not the regime.

03 / The CASP question

A CASP licence is for crypto-asset services, not for issuing securities.

The CASP question deserves its own section, because the term gets attached to tokenization projects that have nothing to do with it. A CASP, a Crypto-Asset Service Provider, is authorized under MiCA to provide services on MiCA-scope crypto-assets. The MiCA service list includes:

  • Custody and administration of crypto-assets
  • Operation of a trading platform for crypto-assets
  • Exchange of crypto-assets for funds or other crypto-assets
  • Execution, placement, and reception and transmission of orders on crypto-assets
  • Advice and portfolio management on crypto-assets
  • Transfer services for crypto-assets

Every one of these is a service provided to other people, on crypto-assets that are not financial instruments. A business tokenizing its own real asset to raise capital is doing neither: it is not running a crypto-asset service for third parties, and its tokens are securities, not MiCA crypto-assets. So a CASP licence is not the relevant authorization, and the operator does not need one to issue.

Where regulated services genuinely are needed for a securities raise, placement of the offering, operation of a venue for any secondary trading, custody of the securities, those services are provided under MiFID II and the related securities authorizations, not under MiCA's CASP regime. And in practice they are provided by your platform and intermediaries, who hold the relevant licences, rather than by you. CASP authorization belongs to the firms operating in the MiCA crypto-asset market; it is not a gate a real-asset issuer has to pass through.

04 / When MiCA does apply

The narrow cases where MiCA does bite.

MiCA is not irrelevant to everything with a token, and being precise about when it applies is as important as knowing when it does not. Three situations bring a project into MiCA's scope.

1. The token is genuinely not a financial instrument. If what you issue is a pure utility token (access to a service or platform) or a payment token, it is a MiCA crypto-asset and MiCA applies. This is rare in real-asset raises, because the whole purpose is to give investors a return on the asset, which makes the instrument a security. But a project that bolts a non-security token onto a real-asset story should expect MiCA to be in play for that token.

2. A stablecoin or asset-referenced token is part of the structure. If the design includes a token that references a basket or an asset value and is meant to maintain a stable value for payment, that is an asset-referenced token or an e-money token, and MiCA's specific issuance regimes for those apply. Bringing a stablecoin into the structure brings MiCA with it.

3. You provide crypto-asset services to others. If, beyond issuing your own security, you also operate a service on MiCA-scope crypto-assets for third parties, custody, a trading venue, exchange, you need CASP authorization for those services. This is a separate business activity from tokenizing your asset, and most operators never touch it.

The pattern: MiCA applies to your project when there is a genuine non-security crypto-asset in it, or when you are running a crypto-asset service for other people. It does not apply to the ordinary case of issuing a security that represents your real asset's economics. If a structure has been designed so that MiCA applies to a real-asset raise, it is worth asking why the token was made a non-security in the first place, because that usually adds regulatory burden without adding value to the raise.

05 / What governs you instead

Securities law, and usually an exemption.

If the token is a security, the relevant framework is the one that has governed securities for decades, now applied to a token. Three pieces of it matter to an operator.

MiFID II

It defines your token as a financial instrument and sets the framework for the firms that provide investment services around it (placement, advice, dealing, operating a venue). You do not become a MiFID investment firm by issuing your own security; the firms that help you place or trade it operate under MiFID authorizations.

The Prospectus Regulation

Because the token is a security, the Prospectus Regulation applies, but it contains the exemptions that most real-asset raises live on. A full approved prospectus is the exception, not the rule, for a private placement. Common exemptions a raise relies on:

  • Offers made solely to qualified or professional investors
  • Offers to fewer than 150 retail investors per member state
  • Offers with a high minimum ticket per investor
  • Offers below the applicable national prospectus threshold

This is exactly why the investor base drives both the cost and the compliance burden of a raise. A private placement to professional investors usually proceeds under an exemption without a full prospectus; a broad or retail-facing offering is more likely to need one. The exemption is confirmed at structuring, which is one reason the scoping phase defines the investor base early, and it feeds straight into the cost of the raise.

The DLT Pilot Regime

For any regulated secondary trading and settlement of tokenized securities, the EU has the DLT Pilot Regime, which lets market infrastructures operate a DLT trading facility, settlement system, or combined venue within defined limits. This is the platform's or venue's framework, not yours as an issuer. You rely on a venue that operates under it; you do not apply under it yourself.

06 / The separate question

AIFMD asks a different thing: is it a fund?

One regulatory question is genuinely separate from MiCA and often more relevant: whether the structure is a fund under AIFMD. It is independent of the MiCA question entirely, and confusing the two leads operators to worry about the wrong regime.

AIFMD governs collective investment: the pooling of capital from a number of investors to invest it according to a defined policy for their benefit. The test is about pooling and management, not about tokens. So:

  • A single-asset SPV where the operator controls the asset and investors hold a defined claim on its economics is usually not a fund.
  • A vehicle that pools capital across multiple assets and is managed for the investors is more likely to be an alternative investment fund, which needs an authorized or registered AIFM.

Notice that this cuts independently of MiCA. A structure can be outside MiCA (because the token is a security) and still inside AIFMD (because it is a collective investment). It can be outside both (a single-asset SPV issuing a security to professional investors). The two questions are answered separately, and a real-asset raise has to clear both. When the fund layer does apply, it brings an external AIFM, a depositary, and an administrator, with real cost and real benefit in specific situations, which is the subject of the AIFM-wrapped SPV guide.

Not sure whether your structure is a security, a fund, or both?

The classification of the token and whether AIFMD applies are the two questions that decide your whole regulatory path. A scoping conversation maps both for your specific asset and investor base, before any structuring spend.

Book a tokenization strategy call →
07 / The platform's licences

You rely on their authorizations, not your own.

The reason an operator can run a compliant tokenized raise without holding a licence is that the regulated functions are performed by parties who do hold the relevant authorizations. This is the same division of labour as a traditional securities placement, where the issuer issues and the regulated intermediaries handle the regulated services.

In a tokenized raise, the platform and intermediaries typically carry the authorizations for issuance support, placement, and any secondary trading, often as an investment firm under MiFID II, as a venue under the DLT Pilot Regime, or as another authorized service provider. You rely on their licences for those functions rather than obtaining your own. The choice of platform is therefore partly a regulatory choice, not just a technology one, because you are leaning on its authorizations and its standards. The trade-offs between the main platforms, including their regulatory positioning, are in the platforms comparison guide.

This is also why the Securitize roast on this site keeps drawing the line between regulated rails and the cargo that rides on them: a platform holding the right authorizations makes the issuance and trading compliant, but it says nothing about whether any specific asset issued on it is a good investment. As an operator you benefit from the platform's licences for the mechanics of the raise; the quality of your asset and the honesty of your offering are still yours to get right.

08 / What you actually need

Usually a clean securities offering, not a licence of your own.

Pulling it together, here is what a typical real-asset raise actually requires. Note what is on the list and, more importantly, what is not.

  • A correctly structured and classified token, normally a security under MiFID II, confirmed by a legal opinion for your specific structure and jurisdiction.
  • A compliant offering basis under the Prospectus Regulation, which for a private placement to professional investors is usually an exemption rather than a full prospectus.
  • A tokenization platform and intermediaries that hold the relevant authorizations for issuance, placement, and any secondary trading, so you rely on their licences.
  • KYC and AML processes enforced at issuance and at every transfer, which a permissioned token standard supports by design.
  • An AIFMD assessment of whether the structure is a collective investment requiring an AIFM.

What is not on the list, for the typical case, is a MiCA authorization or a CASP licence of your own. The operator tokenizing its own real asset generally needs a well-structured securities offering and authorized service providers, not a crypto-asset licence. That is the practical headline, and it is why the regulatory path for a real-asset raise looks much more like a private placement than like launching a crypto product.

The honest caveat is that classification is fact-specific and the exemptions vary by jurisdiction, so the security analysis and the chosen exemption have to be confirmed for the specific deal. That confirmation is part of structuring, and it is exactly the kind of question a scoping phase is built to answer early. The full process around it, from scoping to close, is in the how-businesses-tokenize guide.

This is general information, not legal advice. The classification of a token, the availability of a prospectus exemption, and the application of MiCA, MiFID II, and AIFMD depend on the specific structure, the asset, the investor base, and the jurisdiction, and EU and national rules change. Confirm the position for your deal with qualified legal counsel before issuing. Nothing here creates an advisory or legal relationship.

Want the regulatory path mapped for your specific asset?

Bring the asset and how you want to raise. A strategy call maps the regulatory route for your deal: whether your token is a security, whether MiCA or AIFMD is in play, which prospectus exemption fits your investor base, and what authorizations your platform needs to carry, so you know the path before any structuring spend. For European real-economy businesses with €5M+ in assets or revenue. No pitch, no obligation.

09 / FAQ

Questions owners ask about licensing.

Do I need a MiCA licence to tokenize a real asset?

Usually no. A tokenized interest in a real-asset SPV is normally a transferable security under MiFID II, and financial instruments are carved out of MiCA. So the issuer does not need a MiCA authorization or CASP licence to issue; securities law governs instead. The token's classification has to be confirmed per structure. See section 01.

What is the difference between MiCA and MiFID II here?

MiFID II governs financial instruments, including most tokenized real-asset interests, which are securities. MiCA governs crypto-assets that are not financial instruments (asset-referenced tokens, e-money tokens, utility and payment tokens). A token is in one regime or the other. A real-asset security sits under MiFID II, not MiCA. See section 02.

What is a CASP and do I need one?

A CASP is a Crypto-Asset Service Provider authorized under MiCA to provide services (custody, trading, exchange, advice) on MiCA-scope crypto-assets to third parties. Issuing your own tokenized security is neither a crypto-asset service nor a MiCA crypto-asset, so you do not need a CASP licence. See section 03.

When does MiCA actually apply?

Three cases: the token is genuinely not a security (a utility or payment token), a stablecoin or asset-referenced token is in the structure, or you provide crypto-asset services to others. The ordinary real-asset security raise triggers none of these. See section 04.

Do I need a prospectus?

Often not. Because the token is a security the Prospectus Regulation applies, but a private placement usually relies on an exemption: qualified or professional investors only, fewer than 150 retail investors per member state, a high minimum ticket, or below the national threshold. A retail-facing offer is more likely to need a prospectus. See section 05.

Does my tokenized SPV need an AIFM?

Maybe, and it is a separate question from MiCA. AIFMD governs collective investment. A single-asset SPV with operator control is usually not a fund; a multi-asset pooled vehicle managed for investors usually is. A structure can be outside MiCA and inside AIFMD, or outside both. See section 06.

Who holds the licences if I do not?

Your tokenization platform and intermediaries, who carry the MiFID II, DLT Pilot Regime, or other authorizations for issuance, placement, and secondary trading. You rely on their licences, which makes platform choice partly a regulatory decision. See section 07.

So what do I actually need?

For the typical case: a correctly classified security token (confirmed by legal opinion), a compliant offering basis (usually a prospectus exemption), authorized platform and intermediaries, KYC and AML at issuance and transfer, and an AIFMD assessment. Usually not a MiCA or CASP licence of your own. This is general information, not legal advice. See section 08.