토큰화 증권 결제: 온체인으로 이동하는 것과 오프체인에 남는 것

The first layer: the token and the chain record

The first layer is the easiest to see. A token exists on a crypto network. A wallet signs a transaction. Validators, sequencers, or another network process confirm that transaction. A block explorer, node, or institutional ledger interface can show that a token balance moved.

For crypto-native assets, people often treat this as the main event. With securities, it is only one event. The SEC staff's January 2026 tokenized securities statement describes a tokenized security as a security formatted as or represented by a crypto asset, where the record of ownership is maintained in whole or in part through one or more crypto networks. The phrase "in whole or in part" is doing real work. Some systems may make the chain part of the ownership record. Other systems may use the chain as a signal, mirror, or transfer mechanism while another book remains controlling.

An onchain transfer answers one technical question: did the token move under the network's rules? It does not automatically answer whether the buyer became the legal holder of a share, a security entitlement, a fund interest, a contractual claim, or synthetic exposure. It also does not prove that cash settled, that the seller had no restriction on transfer, that the wallet was eligible, or that a transfer agent accepted the change.

That is why allowlists and registered wallets matter. A permissionless wallet movement is not the same as an eligible securities transfer. In a regulated tokenized security, the token contract, transfer agent, issuer, custodian, or infrastructure provider may restrict transfers to wallets that have passed onboarding, jurisdiction, investor-status, sanctions, or participant checks. The blockchain can record the movement, but the permissioning layer determines whether the movement is allowed in the first place.

The second layer: the legal holder record

The second layer is the record that the market infrastructure, issuer, or intermediary treats as authoritative.

The SEC staff statement describes more than one model. In an issuer-sponsored model, the issuer or its agent may integrate distributed ledger technology into the master securityholder file. In that structure, a crypto asset transfer on the network can result in a transfer of the security on the master securityholder file. The chain is not just decoration; it is part of the issuer's recordkeeping system.

The statement also describes a different issuer-sponsored model. The issuer may issue the security offchain and issue a crypto asset to security holders, but the crypto asset and onchain record are not directly integrated into the master securityholder file. In that case, the transfer of the crypto asset operates like a notice or mechanism that prompts the issuer or agent to update offchain records. The token can move before the official offchain book catches up, or the official update can be subject to additional controls.

Third-party models add another layer of complexity. A third party can issue a tokenized security entitlement where the underlying security is held in custody and the crypto asset evidences an indirect interest. Or it can issue a linked security or security-based swap that gives synthetic exposure to a reference security. These are not the same risk. In a custodial model, the key question is how the token maps to the custodied security and the entitlement holder's rights. In a synthetic model, the key question is the issuer's contractual obligation and creditworthiness, because the token may not confer shareholder rights or a direct claim on the referenced issuer.

This is where many tokenized-stock discussions become sloppy. "Onchain stock" can mean a direct issuer record, a transfer-agent-integrated fund share, a DTC-style tokenized entitlement, a broker or custodian entitlement, a depositary-like receipt, a linked note, or a derivative. The label does not settle the legal analysis. The documents and records do.

The SEC staff also makes a boundary point that should stay visible: its statement represents staff views. It is not a Commission rule, regulation, guidance, or Commission statement, and it has no legal force or effect. That does not make it useless. It makes it a map of staff thinking, not a final legal shortcut.

The DTC example: token movement beside official books

The DTC tokenization service FAQ gives a concrete infrastructure example. DTCC says DTC will tokenize a security from a Participant's traditional DTC account only when instructed by the Participant and after risk controls are satisfied. DTC then moves the relevant traditional security out of the Participant's traditional DTC account into DTC's Digital Omnibus Account. That omnibus account holds the underlying traditional securities represented in tokenized form.

After that movement, DTC mints a token representing the security entitlement and delivers it into a registered digital wallet identified by the Participant. DTCC says its LedgerScan system will record the location of the token offchain and future onchain movements. It also says DTC will reconcile the number of tokenized securities entitlements recorded by LedgerScan against the number of traditional securities entitlements held in the omnibus account.

That description is important because it refuses the simplistic story. The token is not floating in isolation. It is connected to a DTC Participant relationship, a traditional DTC account, a digital omnibus account, registered wallets, DTC official records, and reconciliation. DTCC also says the custody relationship between DTC and its Participant does not change whether the assets are held in traditional or tokenized form. The token is a representation within a securities-infrastructure relationship, not a consumer wallet claim created out of nowhere.

Commissioner Hester Peirce's December 2025 statement describes the DTC program as a pilot subject to operational limitations. It says registered DTC participants will be able to transfer tokenized entitlements directly to registered wallets of other DTC participants, while DTC's software system tracks each transfer for official books and records. That is a useful sentence for readers: the wallet transfer and the official books are tied together, but they are still distinguishable layers.

The third layer: the cash leg

Securities settlement is normally about two things moving: the security and the money. Delivery versus payment, or DvP, is the mechanism that tries to ensure the securities leg and the payment leg complete together, so one party is not left having delivered value while waiting for the other side.

Tokenization changes how a system might coordinate those legs, but it does not remove the need for the cash leg. BIS research on future securities settlement describes token-versus-token settlement where both securities tokens and cash tokens can exist on one ledger. In that case, an atomic settlement smart contract can coordinate an instant and simultaneous transfer of both tokens. The point is not "blockchain good." The point is that the system can reduce principal risk when both legs are controlled together and the rules make the exchange simultaneous.

But many real systems do not put both legs on the same ledger. A security token might move on one chain while cash settles through a bank account, central bank money, stablecoin, tokenized deposit, broker ledger, or payment system. In that structure, the blockchain confirmation only proves one side of the transaction. The buyer may have received a token while the seller waits for money, or the seller may receive money while the security leg still depends on a record update.

DTCC's own FAQ keeps this boundary visible. It says digitized settlement will not be offered at the launch of the tokenization service. It may be included in future phases, subject to rule filings and regulatory approval. That means the launch tokenization service should not be described as full onchain DvP merely because tokenized entitlements can move. Tokenization of the securities entitlement and digitized settlement of the cash leg are related, but they are not the same feature.

The fourth layer: finality and reconciliation

Finality is the point at which the transfer cannot be unwound through ordinary settlement mechanics. In a blockchain conversation, people often use "finality" to mean the network will not reorganize or reverse the transaction after enough confirmations. In securities settlement, finality also has legal, operational, account, and infrastructure meaning.

BIS settlement research is useful here because it separates failure modes. In one-ledger atomic settlement, if trading details are not agreed or the ledger validation fails, the tokens may remain with their owners. That may leave replacement-cost risk, but not necessarily principal risk. In a cross-ledger DvP setup, BIS describes an additional problem: one leg can be delivered while the other leg is not. That is where principal risk can reappear, and governance or arbitration may be needed to resolve disputes.

Reconciliation is the daily discipline that keeps the system honest. If tokens represent entitlements to traditional securities held elsewhere, somebody has to compare token balances, wallet locations, entitlement records, omnibus account holdings, transfer-agent books, and exception reports. DTCC's FAQ explicitly describes reconciliation between tokenized entitlements recorded by LedgerScan and traditional securities entitlements held in the omnibus account. That is not a small back-office detail. It is the control that prevents the token supply and the underlying records from drifting apart.

This is also why "instant settlement" can be a misleading phrase. A network may settle a transaction quickly. The securities record may update later. The cash leg may settle on a different clock. Exception handling may identify a mismatch after the event. A fully designed settlement system must define which event controls, what happens if records disagree, who has authority to correct errors, and how participants receive evidence of finality.

Custody and synthetic exposure are not footnotes

Custody decides where the asset is and what the holder actually has.

In a custodial tokenized-security model, the underlying security may be held by a custodian or central securities depository while token holders own an entitlement or indirect interest. The token can improve transferability or visibility, but the holder still depends on the custodian, intermediary, governing documents, and operational controls. A custodian bankruptcy, wallet compromise, failed reconciliation, or participant default can matter even if the token contract worked.

In a synthetic model, the token may reference a security without giving the holder ownership of that security. The holder's exposure comes from the issuer's promise, linked note, or swap-like obligation. That can be useful in some market structures, but it should not be sold as ordinary ownership. The settlement question becomes: did the contract obligation settle under its terms, and did the reference exposure behave as promised? That is different from asking whether a share was delivered.

Allowlist design sits across both models. It controls who can receive or move the token. Poor allowlist governance can freeze legitimate transfers, permit ineligible transfers, or create a mismatch between what the blockchain allowed and what the legal documents require. A well-run allowlist is not just compliance theater. It is part of the settlement machine.

Interoperability: the hard part after the demo

The strongest tokenization demos often work because the environment is narrow. The asset set is known. Participants are permissioned. Wallets are registered. Cash and securities may be on the same ledger. The legal documents are written for the test. Exceptions are handled by the project team.

Production markets are messier. BIS's next-generation monetary and financial system chapter notes that tokenized systems need interoperability between existing account-based systems and emerging tokenized infrastructures. It also flags booking, reconciliation, messaging standards, and fragmentation as challenges. That maps directly to securities settlement. A broker, custodian, issuer, transfer agent, CSD, payment provider, regulator, and investor may not all see the same ledger as the source of truth.

The deeper question is not whether a token can move. It is whether every necessary party can read, trust, reconcile, and legally act on the movement. If the answer is no, tokenization still may help, but the market is not truly running on one shared settlement layer.

Practical checklist for readers

Use this checklist before treating a tokenized securities transfer as settled.

1. Identify the product model. Is it issuer-sponsored, a custodial entitlement, a broker or DTC entitlement, a receipt-like claim, a linked security, or a derivative? 2. Identify the official record. Is the blockchain the master securityholder file, part of it, a mirror, or only a trigger for offchain updates? 3. Identify the eligible holders. Are wallets registered or allowlisted, and what happens if a transfer reaches an ineligible wallet? 4. Identify the cash leg. Does money move on the same ledger, through tokenized deposits, through stablecoins, through central bank money, or through ordinary bank/payment rails? 5. Identify DvP mechanics. Are both legs simultaneous, conditional, manually matched, netted, or settled on different clocks? 6. Identify finality. Which event is final: block confirmation, transfer-agent record update, DTC book entry, cash confirmation, or a rule-defined settlement timestamp? 7. Identify reconciliation. Who compares token supply, wallet locations, official books, omnibus holdings, and exception reports? 8. Identify correction authority. Who can reverse, burn, reissue, freeze, or administratively adjust records after an error?

If a product page cannot answer those questions, it may still be legitimate, but it has not given enough information for settlement analysis.

NexuAlpha view

NexuAlpha should treat tokenized securities as a market-structure category, not a marketing label. The useful comparison is not "onchain versus offchain." The useful comparison is record by record: which record controls ownership, which record controls cash, which event defines finality, which system reconciles mismatches, and which party bears risk when something breaks.

That framing also keeps the article distinct from earlier NexuAlpha pieces. A tokenized Treasury product article asks what the product owns and how investors access it. A tokenized stocks versus perpetuals article asks what economic exposure or derivative exposure the holder has. This article asks a narrower settlement question: after a trade or transfer, which records have actually changed?

The answer is usually mixed. Some parts can move onchain. Some parts remain in transfer-agent, DTC, custodian, issuer, broker, payment, or reconciliation systems. Serious tokenization work is not about pretending those systems disappear. It is about making the interfaces between them clearer, faster, safer, and easier to audit.

FAQ

Does an onchain transfer prove legal ownership?

Not by itself. It can prove that a token moved under network or contract rules. Legal ownership, security entitlement, or contractual exposure depends on the issuer record, transfer-agent record, DTC or intermediary books, and governing documents.

What is DvP in tokenized securities settlement?

DvP means delivery versus payment. The securities leg and payment leg are coordinated so one side does not deliver value without receiving the other. Tokenized systems may use atomic settlement if both legs are represented on the same ledger, but many systems still settle money elsewhere.

Why does reconciliation matter if the blockchain is transparent?

Transparency does not guarantee that token supply equals underlying securities or entitlement records. Reconciliation compares blockchain movements and balances against official books, omnibus accounts, transfer-agent records, and exception reports.

Are DTC tokenized entitlements the same as tokenized shares issued directly by a company?

No. DTC's described model involves DTC Participants, registered wallets, tokenized entitlements, DTC official books and underlying securities in a Digital Omnibus Account. An issuer-sponsored tokenized security may integrate the issuer's master securityholder file differently.

Is this legal or investment advice?

No. This is an educational market-structure explainer based on official SEC, DTCC and BIS sources. Product documents, jurisdiction, account relationship and counsel matter for any real transaction.