Tokenization in Capital Markets: How it Works

By: Dean Hanson

In the previous post, we looked at why tokenization is back on the agenda for capital markets, and which pressures are pushing it from pilot to production. This post steps down one level and explains, in practical terms, how tokenization works and what it changes in day‑to‑day operations.

We stay at a business‑friendly level and avoid network‑specific details. Later posts in the series will cover infrastructure design and operating models.

What Is a Tokenized Asset, Really?

Stripped of jargon, tokenization means representing a financial instrument as a set of programmable positions and rules on a ledger.

A tokenized asset is not just a “coin”. It is three things working together:

1. A legal claim

The underlying instrument remains a bond, fund unit, deposit, or note, defined in familiar documentation: offering circulars, fund documents, deposit agreements, and so on. The legal terms do not disappear; they are linked to the digital representation.

2. A set of token or smart‑contract rules

These contracts encode how the instrument behaves on the ledger. They define:

• Who is allowed to hold it (for example, eligible investors, whitelists).
• How transfers work (offer–accept flows, DvP conditions).
• Which lifecycle events can occur (issuance, income, redemptions, freezes, clawbacks).

3. Positions and events on a ledger

Accounts on the ledger hold balances. Transactions update those balances and record events such as transfers, coupon payments, pledges, and redemptions. The ledger provides a shared, time‑stamped history that multiple institutions can rely on.

The ledger itself might be a public network, a permissioned platform, or a consortium chain. The choice affects privacy, access, and interoperability, but the basic pattern is the same.

What Moves on‑Chain, and What Stays Off‑Chain?

For each product, you can ask three simple questions:

1. What exactly are we putting on the ledger?
2. What do we keep in existing systems?
3. Where are the hand‑offs between the two?

In most institutional designs, the answer looks like this.

On‑chain

• The tokenized instrument itself (for example, units in a fund, notes in a securitisation, a deposit, or a stablecoin).
• Positions and transfers between accounts, including settlement of asset versus cash where appropriate.
• Basic settlement and lifecycle logic, such as DvP conditions, scheduled redemptions, or the ability to freeze and claw back under defined circumstances.

Hybrid (linked to the ledger)

• Trading workflows: orders, quotes, and matching often remain in existing OMS/EMS and trading venues, with the ledger used for final settlement and position management.
• Risk, P&L, and limits: risk engines consume on‑chain positions as inputs, but models and calculations remain in the bank’s systems.
• Servicing and reporting: corporate actions, income events, and position data are read from the ledger and distributed through current reporting and client channels.

Off‑chain

• Legal documentation and regulatory filings: prospectuses, ISDAs, CSAs, fund documents, and court processes continue to live in legal and document‑management systems.
• KYC/AML and client due diligence: client files and screening processes remain in existing compliance systems, but their outcomes can feed into on‑chain allow‑lists.
• Credit decisions and internal risk policies: risk appetite, product governance, and approval processes are defined off‑ledger and then reflected in how the token contracts are configured.

The key is not to put everything onto a ledger, but to make the boundaries explicit and well‑governed. That is where many pilots succeed technically but fail organisationally.

A Concrete Example: A Tokenized CRE Credit Note

Consider Acme Capital Partners, a fictional asset manager focused on commercial real‑estate (CRE) credit. Acme originates CRE loans and funds them via a private credit note backed by a pool of senior loans. A global custodian acts as security and paying agent, while a pension fund and an insurer are anchor investors.

The traditional setup

In the traditional model:

• Loan performance data sits in servicing systems and spreadsheets.
• Covenant checks are periodic and manual.
• The credit note exists in CSD or local custody systems, updated through batch processes.
• Investors receive reporting with a lag, via PDFs and static dashboards.
• Any amendments to the deal flow through slow email chains, with multiple “golden sources” of the same information.

The tokenized setup

In a tokenized model on a permissioned network:

• The credit note is represented as tokens held in institutional wallets at the custodian, with explicit rules about who may hold or receive it.
• Transfers, pledges, and redemptions of the note are recorded on a shared ledger, with atomic DvP against tokenized cash or deposits where appropriate.
• Covenant data feeds into the ledger. When a threshold is breached, the smart‑contract logic can:
  • Flag the event on‑chain.
  • Restrict transfers or new subscriptions until the issue is resolved or a waiver is recorded.
  • Notify relevant parties through integrated systems.
• Regulators and auditors, under controlled access, can replay the event history to see what happened and who approved which actions.

The economics of the credit product do not change. What changes is how information, control, and settlement move through the system.

Frictions and Constraints That Remain

Tokenization shifts where certain problems live; it does not make them vanish.

• Privacy and confidentiality Public ledgers expose positions and flows by default, which can conflict with client and trading confidentiality. Permissioned or privacy‑preserving networks address this, but require governance about who can see what.
• Regulatory treatment Tokenised instruments must still fit into regimes for securities, deposits, funds, and payments. Questions about CSD roles, custody chains, investor protection, and insolvency treatment must be answered explicitly in the design.
• Interoperability with existing infrastructure Trading venues, custodians, and CSDs will continue to play central roles. Tokenization projects must map on‑chain accounts to existing account structures, and define how on‑chain settlement interacts with netting, clearing, and existing payment rails.
• Key management and operational risk Moving assets onto a ledger does not remove operational risk. It changes the focus to secure key management, policy engines for approvals, segregation of duties, and auditable workflows across teams.

Recognising these constraints early is what separates projects that stay as proofs of concept from those that become part of production infrastructure.

How This Connects to Designing the Stack

Once you understand what is on‑chain versus off‑chain, it becomes easier to talk about how to build the stack:

• Which networks and token standards to use.
• How to handle custody and key management (for example, MPC‑based institutional wallets).
• How to connect the ledger to existing risk, finance, and operations systems.
• Which controls and behaviours must be expressed directly in the token logic.

These are the questions we tackle in How to Design a Compliant Institutional Tokenization Stack, where we take the Acme example one step further and walk through the reference architecture, including networks, token standards, custody, and integration patterns.