Tokenisation is not a technology upgrade. It is a structural redesign of the legal, settlement, and governance architecture that underlies how value moves between institutions. HRB advises at this structural layer, before any technology is specified.
Tokenisation, tokenised deposits, and digital assets are not product innovations. They are architectural transformations in how value is represented, governed, and settled.
The HRB Index Universe measures these transformations at the structural layer, where incentives, risk pathways, and systemic behaviour are determined, and provides the analytical foundation to assess and design architectures that remain coherent under stress.
The institutional failures in tokenisation to date have not been technical. They have been structural. An asset tokenised without the correct legal wrapper in the target jurisdiction is not a tokenised asset. It is an unregistered security or an unlicensed instrument, depending on where it is held and traded.
HRB advises at the structural layer: legal wrapper, smart contract architecture, settlement design, and regulatory compliance, before any technology vendor is engaged and before any issuance is planned.
The settlement layer question is equally structural. Tokenising an asset on a ledger that has no interoperability with the institutional payment infrastructure through which it will be purchased and redeemed creates a system that works in isolation and fails in production.
Every layer of a tokenisation architecture is a governance decision before it is a technology decision. The legal wrapper, the smart contract standard, the settlement design, and the regulatory compliance mapping each carry long-cycle consequences that cannot be corrected after issuance.
Technology Assessment
Tokenisation decisions are inseparable from technology architecture. HRB provides structural assessment of the implications of technology choices for governance, regulatory positioning, and settlement design. Smart contract development and platform implementation are not within scope.
Most tokenisation engagements begin with platform selection or technology architecture. HRB's engagement begins at the governance layer: what legal instrument is being created, in which jurisdiction, under which regulatory classification, and with what settlement design. Technology is the last decision, not the first.
Legal architecture first
The legal wrapper is specified before any technology is selected. Classification errors cannot be corrected after issuance.
Regulatory mapping across jurisdictions
MiCA, UK Digital Securities Sandbox, DFSA, and MAS each impose distinct requirements. HRB maps all applicable regimes before any structural decision.
Settlement design as governance
Atomic settlement, CBDC interoperability, and tokenised deposit connectivity are governance decisions, not engineering decisions. HRB resolves them at the architecture layer.
No technology vendor relationships
HRB holds no commercial relationships with technology vendors. Every structural recommendation is analytically independent.
The journey from a real-world asset to an institutionally-grade digital asset passes through five structural stages. Each stage presents a specific problem to be solved and an opportunity to be captured. Select any stage to understand the structural question.
A tokenised asset is only as sound as its weakest structural layer. HRB maps and designs all four before any implementation begins.
SPV structure, regulatory classification, jurisdictional domicile
Token standards, programmable compliance, on-chain governance
Clearing architecture, DvP mechanics, interoperability protocols
MiCA, UK FSMA sandbox, DFSA, MAS frameworks
Each asset class presents a distinct legal, settlement, and regulatory architecture challenge. The structural questions are not universal. They are asset-class specific and jurisdiction-specific. HRB maps both dimensions before advising on structure.
Illiquid to liquid
Fractionable debt
Long-duration yield
Supply chain finance
Institutional cash
Capital markets
They are a new settlement instrument with distinct liquidity behaviour, supervisory implications, and interoperability requirements. The structural questions they raise are categorically different from those raised by tokenised assets, and they require a dedicated analytical framework.
Commercial bank money on DLT
Tokenised deposits are liabilities of regulated commercial banks, issued on distributed ledger infrastructure. They are not asset-backed tokens, stablecoins, or CBDCs. The issuing bank remains the obligor and the deposit protection regime applies.
A new settlement instrument
Tokenised deposits enable programmable payment flows, atomic settlement of tokenised asset transactions, and real-time interoperability between ledger-based and traditional payment systems. Their settlement behaviour differs materially from traditional deposits.
Supervisory architecture in development
The EBA, Bank of England, and BIS are actively developing the supervisory architecture for tokenised deposits. Questions on deposit displacement, resolution architecture, and interoperability with CBDCs remain structurally open.
Settlement finality and liquidity coherence
How does a tokenised deposit achieve settlement finality in a hybrid system where some counterparties operate on distributed ledger infrastructure and others on traditional payment rails? The liquidity synchronisation architecture determines the answer.
Issuer resolution and deposit protection
In the event of issuer resolution, the priority waterfall for tokenised deposit holders requires explicit architectural design. The on-chain representation of the deposit must be coherent with the off-chain regulatory treatment under the applicable deposit protection regime.
Interoperability with CBDC infrastructure
Tokenised deposits and wholesale CBDCs are designed to operate in complementary roles within the same settlement ecosystem. The interoperability architecture between the two determines whether programmable settlement is achievable at scale within the regulated financial system.
HRB produced a dedicated research series on tokenised deposits synthesising 30+ institutional and regulatory sources. Full CBDC and tokenised deposit architecture intelligence is available on the dedicated pages.
CBDC ArchitectureThe HRB Index Universe measures these transformations at the structural layer, where incentives, risk pathways, and systemic behaviour are determined. The indices operate across the digital value stack through four structural functions.
P04 FMI at the structural hub. Tokenised value node connected to four measurement pillars.
Because the indices operate at the architectural layer, HRB's work across tokenisation, tokenised deposits, and digital assets is not about platform selection, implementation, or operational optimisation. It is about governance, systemic behaviour, and institutional posture, and the ability to assess and design architectures that remain coherent as digital value systems evolve.
This is what differentiates HRB's digital value advisory from technical or operational consulting.
Precision about scope is not a limitation. It is the basis of a mandate that delivers the right outcome. Select any item to understand the reasoning.
The analytical architecture underpinning HRB's tokenisation practice was developed before the current institutional wave. The foundational work on digital securities architecture and the governance design for tokenised deposits was conducted when the regulatory landscape was still being written.
Art and Cultural Asset Tokenisation
Cross-border legal wrapper design
Tokenised Deposits Research Series
30+ institutional sources synthesised
MiCA and UK Sandbox Analysis
Regulatory divergence mapping
GBP Systemic Stablecoin Architecture
Live venture position
If you are designing a tokenised asset structure, evaluating a tokenisation programme, or need independent structural analysis of a tokenisation proposal, the conversation begins with an enquiry.
The FMI Architecture Cluster
The structural layer extends across the full FMI architecture.