Tokenization & RWA
Tokenization becomes complex where blockchain infrastructure meets legal ownership, settlement, identity and the operational requirements of regulated financial markets.
White papers on the tokenisation of Real World Assets all follow the same structure.
They describe the asset. They explain the technology. They outline the benefits: liquidity, fractionalisation, operational efficiency, near-instant settlement. They cite the applicable regulatory frameworks. They conclude with a roadmap.
What they do not describe is what happens when you actually start building.
Not out of bad faith. For a simpler reason: the deep operational problems of a tokenisation system are not visible until the infrastructure exists. They emerge in the interaction between on-chain logic and the legal, accounting, and regulatory reality off-chain. And that interaction, in most cases, is far more complex than any project document anticipates.
This article describes three of those problems. Not in the abstract. From the experience of building the infrastructure of Arbit Technology Limited, designed to support the tokenisation of assets in regulated markets.
A Distinction That Matters
Before addressing the operational problems, it is worth clarifying a distinction that many in the market confuse: the difference between a token and the infrastructure on which the token operates.
ABTK, the token of Arbit Technology Limited, is a utility token. Its function is simple and deliberate: to give holders discounted access to the platform’s services. The conceptual model is that of a coupon, not an investment instrument. It carries no economic rights over the underlying asset, will not be listed on exchanges, and will have no staking mechanisms. This simplicity is not a limitation. It is an architectural choice that eliminates entire classes of regulatory and operational problems before they arise.
The tokenisation of Real World Assets with economic rights, security tokens following a MiFID II pathway, is a separate layer that will operate on this infrastructure through a dedicated vehicle.
The problems described below belong to the infrastructure, not the token. They are the challenges that anyone seeking to build an institutional tokenisation system must face, regardless of which token runs on top of it.
The First Problem: Who Is Right When the Registers Disagree
In a tokenisation system operating in regulated markets, at least three levels of register exist simultaneously: the blockchain, which tracks token movements; the application database, which manages system state; and the legal register, which determines the legal ownership of the underlying asset.
Under normal conditions the three levels are aligned. The problem is that regulated markets do not always operate under normal conditions. There are settlement windows, operations crossing multiple jurisdictions, events occurring in non-atomic sequences. In those moments the three registers can diverge, and the question that no white paper addresses directly is: which register is right?
The answer is not technical. It is an architectural decision that must be made before the system exists, not after the problem manifests.
The solution we adopted defines an explicit hierarchy of sources of truth: the legal level is primary, the blockchain and application database are subordinate. This hierarchy is embedded in the system through event-driven mechanisms, triggers activated by on-chain and off-chain operations, and periodic alignment checks between registers. The separation is clear and codified: technical representation of the token, application state, and legal ownership are three different things, managed with different logic, that must be reconciled continuously and verifiably.
This is a level of complexity that does not appear in white papers because it requires decisions that precede the design of the token, not ones that follow from it.
The Second Problem: A Transfer Is Not a Transfer
In traditional markets the concept of settlement is well established. There are procedures, intermediate states, time windows, fail management mechanisms. All of this is built up over decades of operational practice and codified in international standards.
In tokenisation systems the implicit assumption is that the blockchain solves the problem: the transfer is atomic, irreversible, final. And technically, that is true.
The problem is that on-chain technical finality does not automatically coincide with legal and financial finality off-chain. A token transfer may be technically completed on the blockchain while the KYC/AML validation of the recipient is still in progress, or while the off-chain counterparty has not yet confirmed its position, or while a regulatory settlement window has not yet closed.
In those cases the system needs controlled intermediate states that the blockchain alone does not provide. Pending, locked, settled are operational categories that must be managed at the application level: with escrow mechanisms and temporary position locking, with the ability to freeze or roll back in the event of failed settlement completion, and with a clear separation between technical execution of the transfer and legal and financial finalisation.
This architecture, which in the traditional world is implicit in existing infrastructure, must be built explicitly in a tokenisation system. It is not an additional feature. It is a precondition for operating in regulated markets.
The Financial Stability Board, in its tokenisation report published in October 2024, is explicit on this point: instant settlement reduces the time available for error correction, and on-chain reversals require a robust smart contract architecture with contingency measures. The apparent simplicity of on-chain transfer conceals real operational complexity that must be managed before it becomes a problem.
The Third Problem: The Wallet Is Not the Owner
In regulated capital markets the identification of the beneficial owner is not an optional requirement. It is a structural obligation under the Fourth and Fifth Anti-Money Laundering Directives, MiFID II, and the KYC/AML requirements applicable to any operator providing services on financial instruments.
In blockchain-based systems the wallet address is the technical identity of the holder. But the wallet address is not the beneficial owner. It may be a custodial wallet managed by an intermediary on behalf of a client. It may be a nominee address aggregating positions of multiple parties. It may change without any change in the underlying economic ownership.
The operational problem is that on-chain transparency, one of the declared benefits of tokenisation, does not automatically produce the required regulatory transparency. Knowing that a wallet holds a certain quantity of tokens does not say who the economic subject holding the rights is.
The solution requires a structured and verifiable mapping system between real identity and economic position, independent of the technical wallet: association between KYC-verified user, wallet or account, and assets held; explicit management of custody arrangements with a clear distinction between technical holder and beneficial owner; tracking of ownership changes also off-chain; and the ability to audit and provide regulated disclosure when required by competent authorities.
This system is not visible to token users. But it is the condition that makes it possible to operate in regulated markets, and that distinguishes an institutional tokenisation infrastructure from a project that defers the compliance problem to the future.
The Fiscal Context: A Variable Still Open
One dimension that white papers tend to treat with excessive optimism is the tax treatment of tokenised assets.
In Europe the situation is fragmented. There is no harmonised tax framework yet for tokens representing Real World Assets. The taxable event, whether issuance, transfer, or redemption, is interpreted differently across jurisdictions. The treatment of tokenisation services varies depending on the type of token and the structure of the issuer. Malta, the jurisdiction of Arbit Technology Limited, has developed one of the most advanced regulatory frameworks for digital assets in Europe, but even in the Maltese context some cross-border tax questions remain open and evolving.
For those building tokenisation infrastructure at this moment, fiscal uncertainty is not a risk to ignore. It is a variable to map explicitly and monitor as national and European frameworks evolve.
What White Papers Cannot Say
The three problems described in this article, register synchronisation, settlement atomicity, and beneficial owner identification, are not new problems. They exist in traditional markets and have been solved over decades of operational practice, technological infrastructure, and accumulated regulation.
Tokenisation does not eliminate them. It repositions them. It moves them from a context in which solutions already exist to one in which they must be built from scratch, or adapted from technological and regulatory domains that were not designed to interoperate.
Building tokenisation infrastructure for regulated markets means confronting these problems before they become operational incidents. It means making architectural choices that do not appear in white papers because they presuppose an understanding of the system that goes far beyond the technology of the token.
It is the work that is not visible. And it is the work that determines whether a system actually functions.
