To tokenise an asset in the EU, you first define the asset and the rights the token will give its holders, because those rights decide whether the token is regulated under MiCA, MiFID II or another framework. The technology comes after that: the smart contract, investor onboarding and issuance are configured to fit the classification, and both the legal and the technical work continue after launch.
Co-authored by Demis Buttigieg, Senior Legal Associate at A2CO, and Alessio Acco, CTO and Co-Founder at Arbit Technology.
This guide sets the two disciplines side by side. Demis covers the legal, regulatory and structuring questions, and Alessio covers the architecture, smart contracts and infrastructure Arbit builds for tokenised assets.
How to tokenise an asset: the seven steps
Asset tokenisation in the EU follows the same order whatever the asset is:
- Establish the asset. Confirm what it is, who owns it, and that the legal and operational arrangements around it are in place.
- Define the rights. Decide what the token gives its holder: economic rights, voting rights, access, or a claim on the asset itself.
- Identify the investors. Settle who the token is for, whether retail or professional, and in which jurisdictions.
- Classify the token. Assess whether it falls under MiCA, under MiFID II as a financial instrument, or under another regime.
- Complete the legal and compliance work. Prepare the disclosures the classification requires, make any notifications or obtain any authorisations, and set up AML and KYC.
- Configure the technology. Set the token standard, transfer rules, whitelisting, distributions and controls to match the first five steps.
- Issue, then operate. Onboard investors, distribute the tokens, and keep meeting the regulatory and technical obligations that follow.
The order is the point. Technology sits sixth, and as Arbit has put it in its own writing, “The blockchain is the last thing to design in a tokenisation project, not the first.”
Start with the asset and the rights the token carries
When a business says it wants to tokenise an asset, neither author starts with the blockchain.
“The key question is really what the token gives its holder,” says Demis Buttigieg. “Does it carry voting or profit participation rights, does it represent an entitlement to an asset or income, or does it simply allow the holder to access a particular product or service?”
Arbit’s preliminary analysis asks a parallel set of questions about the asset itself. Alessio Acco wants to know whether it is a real-world asset or is held inside a legal vehicle, whether it already exists or is still a project, whether it produces revenue, and whether anyone else holds rights over it.
Those answers are not background. According to Alessio, they determine the transferability rules, the token supply, the duration of the offer, the token’s lifecycle, jurisdiction restrictions, how distributions are paid and the custody model.
What goes wrong when the build comes first
Demis describes a pattern A2CO sees in practice. A client sets out to create a token intending it to be treated as a crypto-asset, and finds once the structure is assessed that it has the characteristics of a financial instrument.
“If significant technical development has already taken place, this can have considerable implications in terms of cost, timing and the infrastructure required,” he says.
Alessio makes the same point from the engineering side. “A wrong initial setup could be hard to correct in the future,” he says. “Retrofitting compliance is just not possible.”
MiCA or MiFID II: how the token’s rights decide the framework
Demis starts every project with three questions: what the underlying asset is, what rights the token will give its holders, and where the business will establish its operations and offer the token.
The second question carries the most weight. MiCA regulates crypto-assets, but it does not apply to crypto-assets that qualify as financial instruments under MiFID II. A token whose rights make it comparable to a share or a bond may therefore sit under MiFID II and the wider EU securities rules.
“Calling something a ‘token’ or ‘crypto-asset’ does not determine its regulatory treatment,” Demis says. “You need to look at what the token actually represents and what rights its holders receive.”
ESMA’s guidelines on the qualification of crypto-assets as financial instruments take the same substance-over-form approach. They state that tokenising a financial instrument should not change its classification, and that where a hybrid token meets the criteria of a financial instrument, that nature takes precedence.
Security token or utility token: the first design filter
At design stage, Alessio applies a practical first filter based on what the asset’s revenue does. If the benefit the token provides is economic, he treats the project as a security token. If revenue is not shared with holders and the token instead gives a right, a role or access, he treats it as a utility token.
The legal test is narrower than that filter. MiCA defines a utility token as one “only intended to provide access to a good or a service supplied by its issuer”, and the ESMA criteria look at the full set of rights attached. The classification should therefore be confirmed legally before anything is configured.
The token’s own status matters, not only the provider’s
“A common misconception is that regulatory compliance stops with the business itself,” Demis says. “In reality, you also need to consider the regulatory status of the token and how it is made available to clients.”
ESMA reinforced this in an Opinion published on 8 October 2026, addressed to national competent authorities. Its position is that crypto-asset service providers should not provide services in relation to asset-referenced tokens or e-money tokens that do not comply with MiCA.
The Opinion gives authorities three months from publication to require remediation of remaining legacy exposures. Being authorised does not, by itself, allow a CASP to make any token available on its platform.
How classification shapes the technical build
Once the classification is settled, the technical work becomes a configuration exercise.
“It took a bigger effort so far to understand, from a MiCA perspective, the regulatory classification and structure of the underlying asset,” Alessio says. “After that it almost feels easy to set up the technological layer.”
Arbit’s platform can enable or disable transfer restrictions, distributions, voting, redemptions, freezing, and minting and burning, depending on how the token is classified. Jurisdiction restrictions and additional identity checks can be added where a project needs them.
Alessio compares these functions to the terms and conditions of a traditional financial product, where one condition triggers another. Most are disclosed to investors, and some are disclosed only to the authority.
In regulated tokenisation projects, he ranks these controls as the most important:
- Transfer eligibility
- Identity and whitelist integration
- Role-based access
- Pause and emergency controls over the offer and transfers
- Governance over new issuances, with minting and burning controls
- Recovery of credentials
- Auditability, and transparency over audit results
The legal requirements feed straight into that list. “Requirements around who may acquire or transfer the token, investor eligibility, or the rights afforded to token holders may need to be reflected in the functionality of the smart contract,” Demis says. An independent smart contract audit then tests whether the code does what the structure requires.
Investor eligibility and onboarding
Who may acquire or hold tokenised assets depends on the token’s classification and how it is offered. Different requirements may apply depending on whether the investor is retail or professional and where they are based.
Before any token is issued or marketed, Demis expects several items to be settled. Depending on the classification, these may include a regulatory assessment, a MiCA white paper, authorisations or notifications, the required disclosures, and appropriate AML and KYC processes.
Technology then enforces those decisions. On Arbit’s platform, every investor completes identity verification and provides information on source of funds, occupation and political exposure.
An issuer can go further and restrict the offer to particular individuals or legal entities. Investors then complete an additional declaration and are admitted through manual whitelisting.
The wallet is checked too. An investor supplies one address at registration, and that address can be screened on-chain for links that would exclude it from the offer.
From approval to allocation
Alessio describes the sequence after approval:
- The investor reviews the asset and token details in the offering portal, registers and passes KYC.
- When the offer opens, the investor purchases tokens. Payment usually goes into an escrow contract linked to those tokens.
- Tokens are delivered immediately or after the offer closes successfully, depending on how the offer was set up.
- If a minimum cap was set and is not reached, the funds go back to the investors and the project does not start.
- Once the issuer closes the offer, tokens are distributed and the proceeds are released from escrow to the asset owner or managing company.
Transfers can be locked for a set period or enabled from the first day.
What smart contracts can enforce, and what they cannot
Regulation decides who may hold a token, and technology helps enforce that decision. Both authors add a qualification.
“In an era where we get scared about what AI could do, smart contracts remind us that they are good at deterministic rules,” Alessio says. If the pre-set conditions exist, the contract acts as instructed. If they do not, it stays still.
A smart contract cannot, on its own, determine legal ownership of an off-chain asset, receive a court order, value an asset or verify its authenticity. Alessio’s formula for a sound structure is “legal agreement + governance + trusted data + smart contract”, with the connectors for outside inputs built before deployment.
Demis reaches the same conclusion from the legal side. “Smart contracts can automate certain predefined functions, such as transfers and restrictions, but they do not replace the underlying legal arrangements.”
Each author also relies on the other’s discipline. The technologist says an accurate compliance analysis has to come before the setup, and the lawyer says the regulatory analysis depends on knowing how the blockchain and the smart contracts work.
“Understanding the technology is therefore fundamental, as it effectively underpins the entire regulatory analysis,” Demis says. Arbit sets out the limits of code in more detail in The four problems no smart contract can solve.
Custody and ownership: the on-chain record is not the legal title
A tokenised asset has two records, the blockchain and the legal structure behind it. They are not the same thing.
“A blockchain record can evidence ownership or control of a token, but this does not necessarily establish legal ownership of the underlying asset,” Demis says. “The key distinction is between owning the token and owning, or having enforceable rights over, the asset that the token represents.”
On-chain, the record is public and traceable from the address of the smart contract that originates every transaction. Arbit’s backend adds the off-chain layer: an export of registered, KYC-verified users with their addresses and transactions.
State changes can be recorded as well. Alessio gives the example of a holder crossing a threshold that unlocks voting rights or a different dividend rate.
Custody decisions
Custody and administration of crypto-assets on behalf of clients is one of the crypto-asset services MiCA regulates. For a token under MiCA, Alessio’s working rule is that a third-party custodian must be an authorised CASP.
Receiving investor funds is largely automated. Releasing the proceeds of a token sale goes through procedures that confirm the right entities are authorising the transfer.
Alessio adds a design principle that is easy to overlook: “For Arbit, preserving asset portability and independence from a single front-end or provider is a major architectural objective.”
When the two records disagree
“The legal structure should clearly establish which record is authoritative and how any discrepancy will be resolved,” Demis says.
Alessio regards a conflict as remote but possible. It arises where the same asset is offered both traditionally and through tokens, and the two paths drift apart.
The issuer must decide before issuance whether those routes are alternative or complementary, and the traditional offer should refer to the tokenised one. A token can be linked to a share or a bond, or part of the supply can be offered each way.
Technically transferable is not legally tradeable
“The fact that a token can technically be transferred on a blockchain does not necessarily mean that it can be freely transferred from a legal or regulatory perspective,” Demis says. Classification, the rights attached and any restrictions on who may hold the token all affect transferability.
Where secondary trading is intended, the analysis has to go beyond the issuance. It must cover where the token will trade, who can access that market, and whether the venue or service providers need authorisation.
For tokens that are financial instruments, the EU’s DLT Pilot Regime may be relevant. It provides a framework for trading and settlement infrastructures built on distributed ledger technology.
On the technical side, Alessio notes that the infrastructure for transfers already exists. Any wallet or exchange that supports the token’s standard can handle it, subject to lock-up periods and transfer restrictions.
What does not move automatically is the set of rights. “If Alice wants to sell all her tokens to Bob, Bob can pay Alice what they agree,” Alessio says. “But Bob will need to satisfy the issuer’s terms and conditions to exercise voting rights or receive dividends.”
In practice, a later holder receives the benefits only after completing KYC and being whitelisted. That is why tradeability has to be decided in the pre-analysis and disclosed in the white paper, and why an exchange listing needs its own due diligence.
After issuance: the work that continues
“Issuance is not the end of the regulatory process,” Demis says. Depending on the token, continuing obligations may cover how it is marketed, keeping the white paper and related information available to the public, and making submissions to the competent authority.
He sees one assumption repeatedly with utility tokens: that once the notification to the competent authority is made, the job is done. Issuers remain responsible for meeting the standards that apply to them under MiCA after launch.
The technical work continues too. Arbit monitors the networks and protocols it uses for flaws, and Alessio’s policy is to stay on “the safer and more tested version” of a standard, so that an attack on a newer variant cannot be turned against a live token.
Time horizons are the part businesses most often underestimate. “Settlement of a token could be in years, or it could even be perpetual,” Alessio says.
Settlement might mean repaying the amount invested, exchanging tokens for shares, or selling the completed project. None of this is new to finance, he adds. It is “just made easier by automation and a good analysis before issuance.”
When asset tokenisation makes commercial sense
Both authors start from the commercial purpose.
For Demis, tokenisation makes most sense where there is a clearly established real world asset and a clear understanding of the rights attached to it. “The technology should therefore serve a clear commercial purpose rather than tokenisation being pursued simply for the sake of using blockchain technology,” he says.
Alessio describes tokenisation as “one more selling channel”. It offers more specialised ways to sell parts of an asset, and it can give an otherwise illiquid asset the funding to get started.
He is equally direct about its limits. “If the problem is commercial, adding a new layer or changing shape to the underlying does not ultimately solve it.” Tokenisation requires deep disclosure of the token, the asset and the people behind the operation, so it exposes a weak project and does not repair one.
The benefit that is real and the one that is overstated
Asked separately, the lawyer and the engineer named the same overstated benefit: liquidity.
“Simply tokenising an asset does not automatically create a liquid market for it,” Demis says. “There still needs to be market demand, an appropriate trading infrastructure and, importantly, a regulatory framework that permits that trading.”
The real benefits are less dramatic. Demis points to broader access, where interests in an asset can be divided among a wider range of investors. Alessio points to automation, with ownership, dividends and compliance tracked on-chain.
Six mistakes to avoid
| Legal and structuring mistakes (Demis Buttigieg, A2CO) | Technical mistakes (Alessio Acco, Arbit Technology) |
|---|---|
| Treating regulation as an afterthought | Putting technology before the numbers and the compliance analysis. A token standard or platform may not fit inside the regulatory limits, and that is hard to fix once deployed. |
| Not clearly defining the rights given to token holders | Assuming the job ends when the smart contract is live. Monitoring and managing the next steps and transactions follow. |
| Tokenising before the underlying asset and its legal and operational arrangements are properly established | Depending on a single platform or infrastructure. The project should make sense to anyone it is explained to, in clear terms and with the law referenced. |
Demis sums up the legal side in one line: “Tokenisation should sit on top of a sound underlying structure, not be used to remedy gaps within it.” Alessio’s version is that “the pre-analysis is the asset of the asset”.
One decision is routinely left too late. Alessio would settle how the project communicates far earlier, because marketing professionals who also understand the regulatory position are scarce. Demis would bring the regulatory analysis to the very beginning, before the business commits to a structure or a technology.
Worked example: tokenising a €5 million asset
Take a business that wants to tokenise an asset worth about €5 million and offer participation to investors across the EU.
The legal groundwork. Demis would first establish exactly what the asset is, who owns it, and whether the legal and operational arrangements are in place. He would then determine how the tokenisation is structured, which rights investors receive, and which categories of investor it is offered to.
Those elements drive the regulatory classification, and the classification sets the requirements to meet before issuance.
The technical build. Once the asset type, the classification, the entities involved and the benefits carried by the token are clear, Arbit configures them on its platform. The offering site is created and the start date of the offer is set.
Jurisdiction restrictions, restrictions on individuals or legal entities, the distribution schedule and voting rights are configured next.
Issuance and operation. Investors register, pass KYC and purchase. Funds sit in escrow until the minimum is reached, the tokens are distributed, and the proceeds are released to fund the project.
From there, holders follow the project’s progress and receive distributions in proportion to their tokens. The issuer keeps its disclosures, monitoring and reporting up to date.
This is real world asset tokenisation in its plainest form. The same sequence applies to a building, a fund interest or a revenue stream, and the classification step is where the paths divide.
Planning a tokenisation project?
A2CO’s legal and regulatory team can assess the asset, the rights and the likely classification before you commit to a build, and supports token issuance under MiCA from Malta. Arbit Technology provides the tokenisation infrastructure that the classification calls for.
Speak to either team early, ideally before a token standard or platform has been chosen.
