2.3 The Tokenization Process: How It Actually Works
How tokenization works as an operating lifecycle covering issuance, exchange, servicing, and redemption, why claim design comes before the smart contract, and which traditional roles stay in place.
Tokenization is not a minting event. It is an operating lifecycle that links a traditional asset, a legal claim, a set of regulated intermediaries, and a programmable ledger. The visible step, the moment a token appears in a wallet, sits in the middle of a much longer sequence. Almost everything that decides whether a tokenized product behaves well or badly happens before the mint, after it, or in the connections between the two.
Section 2.1 settled what an RWA is. Section 2.2 sorted the asset classes that can be one. This section answers the practical question that follows. Given a real asset and a working definition, what actually has to happen for a token to exist, be transferable, pay its holders, and eventually be redeemed?
The Lifecycle Frame
The IMF treats the financial asset lifecycle as four phases: issuance, exchange, servicing, and redemption 1. That frame is stronger than the common "asset selection, mint, trade" diagrams because it includes everything that happens after the token exists. An RWA is not done once it is issued. It has to be priced, paid on, transferred under restrictions, reconciled with off-chain records, and eventually closed.
BIS/CPMI frames tokenization itself as generating and recording a digital representation of traditional assets on a programmable platform, and notes that token arrangements can provide platform-based intermediation across the end-to-end lifecycle of financial assets 2. Read together, the two framings give the section its shape. Tokenization is a representation choice applied across an existing financial lifecycle. The process question is what each phase actually requires.
The walk-through below uses BlackRock's BUIDL as a running example because the public record names every role. BlackRock is the investment manager. BNY Mellon is custodian and administrator. Securitize is the transfer agent and tokenization platform. Securitize Markets is the placement agent that distributes the fund to qualified investors 3. Other products use different combinations, but BUIDL shows the pattern cleanly: tokenization changes the recordkeeping and distribution layer while leaving investment management, custody, administration, audit, and the regulatory wrapper in place.
Phase 1: Issuance
The issuance phase covers everything from "we want to tokenize this" to "the first token sits in an investor's wallet." It is the longest and most legally heavy phase, and it is where most of the operational complexity actually lives.
Choose the asset and the claim
The first decision is not which blockchain to use. It is what right the holder will receive. A token can represent a share in a fund, a beneficial interest in a trust, a note, a receipt, a direct claim on a specific asset, or a synthetic exposure that tracks performance without granting underlying rights. The legal nature of that right determines what regulators care about, who can buy it, and how disputes will be resolved.
This is where the issuer-sponsored, custodial, and synthetic distinction introduced in Section 2.2 becomes a design decision rather than a label. Whether the token grants direct rights in the underlying instrument, a claim against a third-party custodian, or only a synthetic tracking exposure is settled here, at the moment the claim is chosen, and the SEC staff statement on tokenized securities draws exactly those lines 4. The same on-screen experience can sit on top of materially different claims. A reader who skips this step in their own analysis will misread everything that follows.
Create the legal wrapper
Once the claim is defined, it has to live inside a structure that can be owned, audited, and where relevant regulated. In most live products, the wrapper is a fund, SPV, trust, or note program governed by existing securities or banking law. The legal documents (fund prospectus, trust deed, subscription agreement) are what give the token its enforceability. The token, on its own, does not own anything. The wrapper does.
Appoint service providers
A tokenized product is built by a team of named, regulated intermediaries. BUIDL's cast, introduced above, maps one-to-one onto this phase: the investment manager runs the portfolio, the custodian-administrator holds and administers the underlying assets, the transfer agent keeps the on-chain ownership record and runs the tokenization platform, and the placement agent handles distribution to eligible investors 3. None of these roles is decorative. Each one carries regulatory and contractual obligations that pre-date tokenization and continue inside it.
Onboard eligible investors
Before the first mint, the issuer has to determine who is allowed to hold the token. For institutional and securities-regulated products, that means KYC, AML, eligibility checks, and in most cases a whitelist that the smart contract enforces. The IMF notes that programmability can hard-code transaction conditions, including which investors are permitted to hold certain assets, and can bundle contingent transactions into one atomic transaction 1. That is what most institutional tokenized products do at the contract level: the rules are not a separate compliance layer, they are part of the token itself.
Deploy the token and the compliance logic
The technical step is to deploy or configure a token contract that encodes the rules above: transfer restrictions, eligibility checks, decimals, supply mechanics, and the hooks needed for servicing. This is the visible part of the process. It is also, on most products, the smallest part of the total work.
Accept subscriptions and mint
The mint itself happens against an accepted subscription, against a delivery of the underlying asset, or against a payment in the relevant settlement asset. BUIDL allows qualified investors to subscribe through Securitize Markets, with new tokens minted into the investor's wallet once the subscription is accepted 3. The subscription flow is institutional. The minting is on-chain. The two are linked by the transfer agent that updates both the legal register and the chain state.
Phase 2: Exchange and Settlement
Once a token exists, the question is who can hold it, who can move it to whom, and how the payment leg settles against the asset leg.
Transfer under restrictions
A tokenized security is rarely a freely transferable token. Most institutional products restrict transfer to pre-approved investors, and the contract enforces those restrictions on every transfer. BUIDL is structured so qualified investors can subscribe and then transfer the token 24/7/365 to other pre-approved investors 3. "Permissionless trading" and "tokenized RWAs" are usually not the same sentence in production.
Settlement and the payment leg
Asset-side settlement is only half of a transaction. The payment side has to settle too. The OECD points out that delivery-versus-payment for tokenized asset transactions requires the payment leg to be on-chain as well, in the form of central bank digital currency, tokenized deposits, suitable stablecoins, or a connection to existing wholesale payment rails 5. Without a credible payment leg, the on-chain "instant settlement" claim collapses into one-sided automation that still needs a traditional cash leg to clear elsewhere.
This is where simplified tokenization diagrams tend to lie by omission. Asset tokenization does not automatically produce safe atomic settlement. It produces the asset half of a DvP design. The cash half has to be solved separately, and most live RWA products today rely on stablecoin settlement or on continuing to clear cash through traditional rails.
Phase 3: Servicing
Servicing is where most simplified explanations stop. It is also where most of the operating value of tokenization is created or destroyed.
Valuation and price data
For tokenized money market funds, the fund administrator publishes a daily NAV that has to reach the chain in a way holders, integrators, and downstream applications can rely on. For tokenized credit, valuations may be infrequent and depend on servicer marks. For tokenized commodities, the underlying market price is continuous and the token reference updates against it. In each case, the valuation source and cadence is an operating decision that pre-dates tokenization and continues through it.
DTCC's Smart NAV pilot is one example of off-chain fund data being routed into on-chain workflows so that downstream applications can consume the same number that fund administrators publish 6. That kind of plumbing work makes the difference between a tokenized fund that integrates with DeFi protocols and one that lives on-chain in name only.
Distributions and corporate actions
A tokenized product still has to pay its holders. BUIDL accrues dividends daily and pays them directly into investors' wallets each month as new tokens 3. That is a programmable servicing flow built on top of conventional fund accounting. Other products handle distributions through stablecoin transfers, off-chain payments routed through the transfer agent, or scheduled token rebases. Each design choice carries different tax, accounting, and operating implications.
Compliance, reporting, and ongoing eligibility
Investor eligibility is not a one-time check. Sanctions screening, jurisdictional restrictions, and qualification thresholds have to be maintained over the life of the token. Where the issuer manages eligibility through a whitelist, the whitelist becomes a continuing compliance system, not a launch artifact. Reporting requirements that apply to the underlying fund or security also apply to the tokenized version, since tokenization does not change the legal classification of the instrument.
Phase 4: Redemption and Reconciliation
The lifecycle closes when the holder exits the position or the product winds down. In an off-chain authoritative model, the issuer or transfer agent processes the redemption against the legal record and the token is burned to reflect it. In an on-chain authoritative model, the burn itself is the legally significant event.
The SEC staff describes the two patterns directly. In one model, an issuer-sponsored tokenized security integrates DLT into the systems used to record owners, so that a crypto-network transfer results in a transfer on the master securityholder file 4. In another, the issuer tokenizes a security where the crypto asset is not part of the master securityholder file and the on-chain transfer instead notifies the issuer or its agent to update the off-chain ownership record 4. Both patterns are in use today. Both are valid. They produce different reconciliation requirements, different failure modes, and different legal pictures when something goes wrong.
Reconciliation continues across the whole lifecycle, not only at exit. As long as an off-chain register, custodian, or transfer agent is the authoritative record, the operating model has to keep the token state and the legal state aligned at every step. As long as the ledger is authoritative, the legal wrapper has to recognize that ledger entry as the binding record. The question raised in Section 2.1 reappears here as a process question: who reconciles what, how often, and at what cost?
The Conservative Baseline
Tokenization does not have to be ambitious to be useful. The UK Investment Association's baseline fund-tokenization model is deliberately conservative: mainstream fund assets, existing fund valuation and settlement processes, and DLT used for sales, redemption transactions, and the register of holders 7. That is a much smaller change than "rebuild the fund industry on-chain," and it is exactly the model many regulated issuers are starting with.
RWA.xyz's process taxonomy makes a related distinction, separating on-chain native models, where the blockchain is the definitive ownership record and users can invest, sell, and receive distributions on-chain, from represented and digital twin models, where the chain is not the source of truth 8. This is the same axis Section 2.1 drew between "distributed" and "represented" assets, described from the process side rather than the definitional one: an on-chain native model is one where the ledger is authoritative, and a represented or digital twin model is one where it is not. Most production volume today sits in the represented and digital twin space, where the operating sequence still relies heavily on existing fund and securities plumbing. That is the realistic starting point for an institutional reader.
Where the Value Actually Comes From
It is tempting, having walked through the process, to conclude that tokenization is just old finance with a token. That is too cynical to be useful. The OECD warns that tokenization often replicates processes both on-chain and traditionally, which can prevent efficiency gains from materializing 5. That is a real risk, but it is not the whole picture.
The IMF defines a digital token as an asset or representation of an asset on a ledger that is shared, trusted, and programmable 1. The programmability piece is what makes the process matter. Hard-coding eligibility rules, automating distributions, settling against on-chain payment instruments where they exist, and bundling contingent transactions into atomic operations are real changes in how the lifecycle runs when the design supports them.
The honest answer is that the value is real only where the tokenized process actually reduces reconciliation, widens distribution, improves collateral mobility, improves transparency, or enables programmable servicing without adding equal or greater new complexity. Where it does, the lifecycle becomes lighter. Where it does not, tokenization adds a parallel infrastructure to maintain alongside the existing one.
Bridge to the Components
Once the lifecycle is visible, the three components covered in Section 2.4 are easier to read in their proper roles. Custody protects the underlying asset and, in some structures, the tokens themselves. Oracles move external facts (prices, NAV, identity attestations) onto the chain so the contract logic has data to act on. Smart contracts enforce the issuance, transfer, servicing, and redemption rules this section walked through step by step. None of them stands alone. Each one is the technical answer to a question the lifecycle has already asked.
With the process in place, Section 2.4 can focus on how each component holds the structure together rather than on what it is for.
- Tokenization is a lifecycle, not a minting event. The IMF's frame of issuance, exchange, servicing, and redemption is more accurate than "asset selection, mint, trade" because it includes everything that happens after the token exists.
- Issuance is dominated by legal and operational work: defining the claim, building the legal wrapper, appointing the custodian, administrator, transfer agent, and placement agent, onboarding eligible investors, and only then deploying the token and minting against subscriptions.
- Settlement is a separate problem. Asset tokenization solves the asset leg of delivery-versus-payment. The payment leg requires CBDC, tokenized deposits, suitable stablecoins, or a connection to wholesale payment rails before "instant on-chain settlement" claims are credible.
- Servicing carries most of the operating complexity. Valuation, distributions, corporate actions, and ongoing eligibility checks continue across the token's life, with the transfer agent or its on-chain equivalent keeping the legal and ledger states aligned.
- Tokenization adds value where it reduces reconciliation, widens distribution, improves collateral mobility, improves transparency, or enables programmable servicing. Where it duplicates traditional and on-chain processes without removing work, it adds infrastructure rather than saving it.