Tokenization Custody Infrastructure: How Institutional-Grade Custody Works

Most tokenization projects fail not at the issuance layer but at custody. The tokenization platform itself — smart contracts, cap table, investor portal — can be operational in weeks. The custody infrastructure that satisfies institutional investors, regulators, and auditors takes longer to configure and has harder requirements.

This matters because custody is not a technical problem. It is a legal, operational, and regulatory problem that happens to have a technical component. Before an investment committee at a family office or institutional LP approves exposure to tokenized assets, their compliance team asks three questions: Who holds the keys? How are assets legally segregated? What happens in bankruptcy? The answers determine whether the deal closes.

---

Why Custody Is the Missing Layer in Most Tokenization Platforms

The standard narrative in tokenization focuses on issuance: smart contracts, transfer logic, compliance rules. This is the visible layer — it has demos, user interfaces, and marketing materials.

Custody is the invisible layer. It is the infrastructure that holds the private keys controlling those smart contracts, enforces legal segregation of assets, and provides the audit trail that regulators and auditors require.

Most early-stage tokenization platforms address custody with one of two unsatisfactory approaches:

Approach 1: Ignore it. The issuer controls the keys. This works for a prototype but fails immediately at institutional diligence. "The GP controls the multisig" is not an acceptable custody answer for a qualified institutional investor.

Approach 2: Outsource it incompletely. The platform integrates with a retail or semi-institutional custodian without addressing segregation, AML/sanctions screening on transactions, or cross-border regulatory requirements. This creates a compliance gap that surfaces during audit or regulatory examination.

Institutional custody infrastructure requires a specific architecture that addresses all three dimensions: legal, operational, and technical.

---

Types of Custody for Tokenized Assets

Self-Custody

The token issuer controls private keys directly. Technically simple, operationally risky, and generally unacceptable to institutional investors.

Self-custody creates commingling risk (investor assets and issuer assets controlled by the same key), eliminates bankruptcy protection (no legal segregation from issuer's estate), and provides no independent verification that assets exist.

Self-custody is appropriate only for issuers tokenizing their own balance sheet assets where they are also the investor. It is not appropriate for third-party investor funds.

Third-Party Qualified Custody

A regulated, licensed custodian holds private keys on behalf of the issuer and its investors. Assets are legally segregated — each client has distinct accounts, not a share of a commingled pool.

Qualified custodians for digital assets in major jurisdictions:

• US: Anchorage Digital (OCC national trust bank charter), BitGo Trust Company, Coinbase Custody Trust Company
• ADGM (UAE): Licensed under FSRA custody permissions
• EU (MiCA): Crypto-asset service providers with custody authorization
• Bahrain: CBB-licensed digital asset custodians under the Digital Asset Module

Multi-Party Computation (MPC) Custody

MPC is the dominant institutional key management technology in 2026. Rather than a single private key, MPC splits the key into cryptographic shards distributed across multiple parties. Signing a transaction requires a threshold of shards — typically 2-of-3 or 3-of-5.

Key advantages for tokenization infrastructure:

• No single point of compromise (an attacker who steals one shard gains nothing)
• No hardware dependency (shards can be distributed across data centers)
• Flexible governance policies (different approval thresholds for different transaction types)
• No key reconstruction during signing (the key is never reassembled in one place)

Major MPC infrastructure providers: Fireblocks, Copper, Qredo, Fordefi.

Hardware Security Module (HSM) Custody

HSMs are physical devices that store cryptographic keys in tamper-resistant hardware. They enforce access policies at the hardware level — a key stored in an HSM cannot be extracted, even by the device administrator.

HSMs are appropriate for:

• On-premise deployment (institutions that cannot rely on cloud-based key management)
• Air-gapped cold storage (keys that should never touch an internet-connected system)
• High-value transaction signing with physical approval workflows

FIPS 140-2 Level 3 is the minimum standard for institutional HSM deployments. Hardware providers: Thales, Utimaco, AWS CloudHSM.

---

Regulatory Requirements for Custody by Jurisdiction

United States

The SEC's custody rule (Rule 206(4)-2 under the Investment Advisers Act) requires investment advisers to hold client assets with a "qualified custodian." For digital assets, qualified custodians include state-chartered trust companies, national banks with digital asset custody permission, and federally chartered trust companies.

ADGM (UAE)

The FSRA requires an explicit custody permission as part of a Financial Services Permission for firms providing custody of digital assets. Requirements include segregated client accounts, AML/KYC on underlying beneficial owners, capital adequacy requirements, regular independent audits, and business continuity planning for key management systems.

See our ADGM digital asset licensing guide for full licensing details.

EU (MiCA)

Under MiCA, crypto-asset service providers offering custody must hold client assets in segregated accounts, maintain daily reconciliation, carry adequate insurance or capital, and publish custody policies. The segregation requirement is explicit: a custodian's insolvency cannot affect client assets.

Bahrain

The CBB's Digital Asset Module establishes custody requirements including segregation of client assets, monthly reconciliation reporting, and minimum capital adequacy.

---

Custody Integration Architecture

A tokenization platform's custody architecture has five components:

1. Key Management System (KMS): The core cryptographic infrastructure — MPC shards, HSMs, or a hybrid. Defines how keys are generated, stored, and accessed.

2. Policy Engine: Rules governing when transactions can be signed — amount thresholds, counterparty whitelists, approval workflow requirements, time-of-day restrictions, rate limits. This is where compliance rules are enforced at the custody layer.

3. Transaction Monitoring: AML/sanctions screening on all transactions. Every on-chain movement of assets should be screened against sanctions lists (OFAC, EU, UN) before signing.

4. Segregation Layer: Legal and technical separation of client assets. Each investor's tokens should be in addresses unambiguously attributable to them.

5. Audit Trail: An immutable log of every key access, transaction signing, and policy exception. This is what regulators examine.

Integration with Tokenization Platform

When a distribution is executed, the platform generates a transaction, which passes through the custody policy engine, gets signed by the MPC or HSM, and broadcasts to the network. The custody system logs the transaction and the audit trail updates.

---

Cross-Border Custody: Challenges and Solutions

Tokenization deals frequently involve issuers in one jurisdiction, custodians in another, and investors in multiple jurisdictions.

Challenge 1: Regulatory patchwork. A custodian licensed in ADGM is not automatically recognized in the US. Multi-jurisdiction deals require either a custodian with multi-jurisdiction licensing or a custody structure with chains of authority across licensed entities.

Challenge 2: Sanctions screening coverage. A US investor in a Bahrain-issued tokenized fund triggers OFAC obligations. Multi-jurisdiction custody infrastructure must screen against all applicable sanctions regimes, not just the custodian's home jurisdiction.

Solutions: For deals targeting MENA and Western investors simultaneously, the most common structure uses an ADGM-licensed primary custodian with sub-custody arrangements with US-licensed entities for the US investor tranche. This mirrors how traditional Eurobond structures work.

---

Frequently Asked Questions

What is tokenization custody infrastructure?

Tokenization custody infrastructure is the complete system for securely holding, managing, and controlling the cryptographic keys that govern tokenized assets. It includes key management technology (MPC or HSM), policy engines that enforce transaction approval rules, AML/sanctions screening, asset segregation, and audit trails that satisfy regulatory requirements.

What is the difference between MPC and HSM custody?

MPC splits a private key into cryptographic shards distributed across multiple parties, requiring a threshold of parties to sign transactions. HSM stores keys in tamper-resistant physical hardware. MPC is preferred for distributed, cloud-based institutional custody; HSM is preferred for on-premise or air-gapped cold storage. Many institutional deployments use both.

Do tokenized assets require a qualified custodian?

In the US, investment advisers holding tokenized fund interests on behalf of clients must use a qualified custodian. In ADGM, custody permissions are explicitly required. In the EU under MiCA, custody must meet specific authorization requirements. The short answer: yes, institutional tokenization requires regulated custody in all major jurisdictions.

Can tokenized assets be self-custodied by the fund manager?

Fund managers can technically control the private keys to their fund's tokenized assets. However, this creates commingling risk, eliminates bankruptcy protection for investors, and fails institutional due diligence requirements. For any fund with third-party investors, third-party qualified custody is required.

How does cross-border custody work for tokenized assets?

Cross-border custody uses a primary custodian with multi-jurisdiction licensing, or a principal custodian with sub-custody arrangements with locally licensed entities in each investor jurisdiction. The structure mirrors traditional Eurobond custody.

---

AssetHaus structures custody architecture for tokenized fund deals across UAE, Bahrain, US, and EU. For a technical assessment of custody requirements for your deal, contact us at asset.haus.