Tokenized Securities Interoperability

Begin with the holding model

An interoperability design should establish what the token represents before it maps wallets, contracts, or network endpoints. An issuer-sponsored tokenized security can be integrated with the issuer's master securityholder file so that a crypto-network transfer effects a transfer on that record. It can also use onchain information to support an update to an offchain master securityholder file. In either design, the programme needs a defined relationship between the token activity and the issuer-side ownership record.

A tokenized security entitlement has a different starting point. It represents an interest maintained through a securities intermediary and relates to the intermediary's recordkeeping and custody arrangements. The token holder can have an indirect interest in the underlying security rather than a direct registered-holder relationship with the issuer. Tokenized Security Entitlement and Security Entitlement explain this account-based model.

A third party can also issue a tokenized linked security or another synthetic exposure. Its holder may receive economic exposure to a reference security without holding an ownership interest in, or rights against, the issuer of that reference security. The required mapping, control, disclosure, servicing, and risk model will differ from a custodial tokenized representation. An architecture that treats all tokens bearing a familiar issuer name as the same financial object can create material errors.

Direct ownership, beneficial ownership, security entitlements, custody claims, and technical signing authority remain separate concepts. A wallet-key controller can differ from the beneficial owner, customer, and authorised instructing party. Beneficial Ownership vs Direct Ownership covers that distinction.

Five objects that must remain linked

The instrument is the first object: issuer, security type, class or series, terms, identifiers, and restrictions. A security master can relate a FIGI hierarchy, CUSIP, ISIN, ticker, internal identifier, contract address, and network-specific token identifier. It should retain source provenance and effective dates because mappings change through corporate actions, listing events, migrations, or corrections.

The position is the second object: quantity, account, encumbrance, entitlement, custody context, and availability. It can be eligible for tokenization, restricted from transfer, reserved for settlement, or subject to another condition. The position provides context that a token balance cannot supply.

The representation is the third object. A conventional book-entry quantity, an active token balance, and a record of a tokenized entitlement can be connected representations of one economic interest. The programme needs a precise control relationship between them. It should identify which representation is active, whether a conventional quantity is immobilised or otherwise controlled, and how the active token supply is compared with the corresponding source position.

The endpoint is the fourth object. It may be a depository participant account, custody account, wallet, token contract, or supported network. The endpoint record should connect the technical destination with the approved institutional relationship. A wallet address identifies a cryptographic destination; it does not, on its own, establish the legal owner, beneficial owner, account authority, or eligibility to hold the instrument.

The event is the fifth object. Tokenization, transfer, settlement, corporate action, wallet rotation, reversal, and de-tokenization each change position state. Every event needs an identifier, time, initiating party, authority, status, and evidence of the records affected. These objects provide the minimum operating context for interoperability.

Transfer and settlement across rails

A cross-rail transfer begins by resolving the instrument, representation, source position, and destination. The workflow then validates source authority, account status, restrictions, destination eligibility, and the requirements of the relevant service. It controls the source quantity, coordinates the required account-side and token-side state changes, records the evidence, and reconciles the outcome.

A workflow needs intermediate states because connected systems can process at different times. An instruction may be validated while a position remains reserved, or a token event confirmed while account reconciliation remains pending. The programme should specify each state, next instruction, wait time, and owner of a failure or timeout.

Delivery-versus-payment requires similar care. A token transfer can be one component of a transaction, while cash movement, funding, custody booking, netting, or other settlement conditions occur through separate systems. Technical finality on a token network does not by itself establish that all components of a transaction have completed. The applicable service rules and operating sequence determine the relevant settlement outcome.

Record hierarchy and authoritative facts

Several records can coexist without creating a defect. An issuer or transfer agent may maintain registered-holder information; a depository, participant-level position; and a custodian or intermediary, the customer account or security-entitlement record. A smart contract may record token movement, while a wallet map identifies the approved endpoint and a monitoring system retains evidence.

The programme must allocate authority by fact. One record may govern registered ownership, another a customer's entitlement, token supply, wallet status, or a reconciliation case. Documentation should specify their relationship, correction process, and treatment of discrepancies. Authoritative Record for Tokenized Securities and Onchain Records vs Offchain Records provide the related framework.

This allocation prevents a common analytical mistake: reading an observable onchain event as a complete statement of legal and operational outcome. A ledger event is important evidence. Its effect depends on the token's terms, holding model, account relationship, programme rules, and designated records. The appropriate question is which specific fact the event establishes and how that fact is reflected elsewhere in the lifecycle.

Lifecycle interoperability

The lifecycle starts before a token is minted. Issuance or onboarding establishes the instrument, holding model, account structure, permitted endpoints, restrictions, and service responsibilities. Tokenization then converts or creates a defined representation through an authorised instruction and controlled quantity process. Subsequent transfers need current authority and endpoint checks, as well as an evidence trail that connects the token event to the relevant account and position.

Servicing extends the requirements. Dividends, coupons, splits, votes, tenders, redemptions, mergers, and other corporate actions depend on record dates, account relationships, tax status, election authority, fraction treatment, and delivery instructions. An onchain token balance can contribute useful evidence, but it does not independently resolve these facts. Corporate Actions for Tokenized Securities examines the operating process.

The programme also needs controlled procedures for wallet rotation, custody changes, holds, erroneous entries, lost credentials, fraud, legal instruction, and other exceptions. De-tokenization retires the token representation and returns quantity to a designated format. Securities De-Tokenization covers that process.

Controls that preserve coherence

Canonical mapping should relate the instrument and its representations to approved accounts, networks, contracts, wallets, providers, and lifecycle rules. Changes require ownership, versioning, test evidence, release controls, and safe supersession.

Role and authority controls identify who can submit an instruction, approve an exception, manage an endpoint, change an instrument configuration, or initiate a remediation process. These controls should distinguish technical key control from account authority and beneficial ownership. They also need supporting evidence from the responsible source systems.

Unique event identifiers and idempotency protect against duplicate action. If a message is retried after an outage or a callback is received twice, the workflow should identify the prior instruction and prevent duplicate account postings or token creation. Reconciliation then compares instrument-level quantities, account states, token supply, wallet holdings, and lifecycle status across the defined record hierarchy.

Exceptions need named owners and time limits. A break should record its severity, affected instrument and quantity, linked events, responsible parties, investigation path, containment action, and resolution evidence. An unmatched difference can be small in quantity but still expose the programme to a larger recordkeeping, servicing, or customer-impact issue.

DTC's stated tokenized-entitlement model

DTC's December 2025 staff no-action letter offers a specific example of the linked controls described above. In the stated preliminary service design, a DTC Participant would submit a Tokenization Instruction for eligible securities credited to its conventional DTC account. Once accepted, DTC would debit the participant account and credit the Digital Omnibus Account, which would reflect the total tokenized-entitlement quantity held in Registered Wallets.

DTC stated that its Factory system would mint and deliver the token representing that security entitlement to the participant's Registered Wallet. Transfers between Registered Wallets would be tracked by LedgerScan, an offchain system that scans the supported blockchains. DTC stated that LedgerScan's record would constitute its official books and records for recording Tokenized Entitlements, while registered ownership of the underlying securities would remain in the name of Cede & Co.

For de-tokenization, the stated design burns the token, debits the Digital Omnibus Account, and credits the participant's conventional account. The Digital Omnibus quantity would not be transferable through the centralized ledger until the corresponding token was burned. This is a controlled relationship among the account, omnibus quantity, token supply, Registered Wallet, and monitoring record. It demonstrates why institutional tokenization depends on more than an isolated smart contract.

The staff response was fact-specific and addressed DTC's stated facts and circumstances. It is not a Commission rule, approval of every tokenized-security design, or a general legal conclusion. DTC Tokenization Service, DTC Digital Omnibus Account, and LedgerScan and Tokenized Securities Monitoring provide more detail.

Tokenized securities interoperability in Devancore

Devancore can connect instrument, representation, account, wallet, custody, provider, instruction, event, and reconciliation data across conventional, tokenized, and onchain rails. It can support operating visibility, configured lifecycle workflows, evidence retention, and exception routing while allowing each responsible provider to retain its own records and decision rights.

Devancore does not create legal title, decide investor eligibility or legal compliance, custody assets or keys, or operate as a transfer agent, broker-dealer, clearing agency, custodian, or depository. Those functions remain with the responsible institutions and governing records.