Digital Token Identifier (DTI)
A globally unique identifier under ISO 24165 that fingerprints a digital token by blockchain network, smart contract address, and genesis parameters.
Definition
Every securities identifier is a bet on how the world is organized. The ISIN (ISO 6166) was designed for a world where instruments are issued by legal entities, registered with national numbering agencies, and traded on centralized exchange order books. That architecture works well for equities, bonds, and listed derivatives — instruments that exist in one form, on one registry, administered by one issuer. It does not work well for digital tokens, which can exist simultaneously on multiple blockchain networks, be created by smart contracts rather than legal entities, fork into multiple successor tokens with shared history and different futures, and settle on rails that have never heard of a national numbering agency.
The Digital Token Identifier (DTI), standardized under ISO 24165, was designed for the world as it actually exists for tokenized assets. Where an ISIN identifies a legal instrument, a DTI identifies a digital object: a specific token, on a specific network, created by a specific contract, at a specific genesis block. Two tokens representing the same economic exposure — the same tokenized bond issued on two chains — are the same ISIN and two different DTIs. That distinction is not a technical nicety. It is the reference data fact that determines which settlement rail carries a given instruction, which custodian sub-account receives the position, and which regulatory report reflects the transaction accurately.
Anatomy of ISO 24165: What the DTI Actually Encodes
Traditional identifier vs. DTI — reference data scope comparison
| Dimension | ISIN / CUSIP | DTI (ISO 24165) |
|---|---|---|
| Governing standard | ISO 6166 / ANSI X9.6 | ISO 24165 (DTIF registry) |
| What it identifies | Legal instrument — issuer and class | Digital token — network · contract · genesis |
| Registry authority | National numbering agencies | DTIF, Geneva — ISO-appointed |
| Network awareness | None — exchange-listed only | Native — blockchain · layer 2 · fork-specific |
| Smart contract scope | Not applicable | Contract address + version encoded |
| Fork handling | Single record — no fork resolution | Distinct DTI issued per fork branch |
| Hybrid mapping | ISIN alone — ambiguous on-chain | ISIN + DTI — deterministic cross-rail routing |
A DTI encodes four categories of token-specific data that together produce a globally unique fingerprint. The token class identifies whether the token is a native layer-1 asset (a protocol token with no contract overhead), a distributed ledger token issued under a smart contract framework, or a derivative or asset-backed token representing an off-chain claim. The originating network specifies the blockchain — down to chain ID and network version — on which the token exists. The genesis parameters record the block height and transaction at which the token was created. And for contract-based tokens, the specific contract address and standard (ERC-20, ERC-1400, or comparable) are encoded.
Fork handling is where DTI diverges most sharply from any traditional identifier. When a blockchain forks, tokens that existed before the fork moment continue to exist on both resulting chains — but they are no longer the same object. They have the same genesis, the same history up to the fork height, and the same economic intent, but they live on different networks and may behave differently going forward. The DTI standard handles this explicitly: each branch of a fork receives its own DTI, preserving the shared history in the registration metadata while assigning distinct identifiers to the post-fork tokens. A post-trade system that cannot resolve fork branches independently cannot route settlement instructions to the correct chain — it will either reject the instruction or guess, neither of which is acceptable for institutional operations.
The ISIN-DTI Mapping Relationship
The operational model for a hybrid portfolio is not ISIN versus DTI — it is ISIN plus DTI, maintained in a deterministic mapping layer within the instrument master. A tokenized bond has an ISIN that identifies the legal instrument (the bond as a claim on the issuer) and a DTI that identifies the on-chain token (the specific digital vehicle through which that bond is held). The mapping can be 1:1 (one tokenization on one network) or 1:N (one bond tokenized on multiple networks for different distribution channels). In either case, the settlement instruction must carry the DTI — not the ISIN alone — to be dispatched to the correct on-chain destination. An instruction that carries only the ISIN in a 1:N portfolio has no deterministic routing: both DTIs match, and the system cannot know which chain holds the client's position without the DTI to resolve the ambiguity.
Institutional adoption of this model is already underway at the infrastructure level. SDX (SIX Digital Exchange), the Swiss regulated DLT exchange and CSD, adopted DTI identifiers for all its digital securities services. 21X, the first licensed DLT Transferable Securities System (TSS) in Europe under the ESMA DLT Pilot Regime, adopted the DTI standard in April 2025 — making DTI support a baseline expectation for regulated digital securities infrastructure in Europe. See ESMA DLT Pilot Regime. For post-trade platforms integrating with these venues, DTI-native reference data is not optional: it is the identifier vocabulary that the counterparty infrastructure speaks.
Regulatory Integration and ISO 20022 Messaging
The regulatory case for DTI is not narrowly European. ISO 20022 — securities settlement message schemas accommodate DTIs as instrument identifiers within the OtherIdentification field of securities identification blocks — meaning that a settlement instruction can carry both the ISIN and the DTI in the same message envelope, without requiring receiving systems to translate between identifier vocabularies. FIX protocol — trade capture similarly supports extended identifier fields that can carry DTI values alongside traditional security IDs in execution reports and trade confirmations. The effect is that DTI flows through the entire institutional messaging stack — from trade confirmation to settlement instruction to custodian notification — using the same channels and protocols that the traditional workflow already uses. A platform that natively embeds DTIs in its outbound ISO 20022 and FIX messages eliminates the identifier translation overhead that accumulates at every system boundary when DTIs are treated as an afterthought. See straight-through processing for the STP architecture that this enables.
ISIN/CUSIP vs. DTI — reference data scope
Devancore Glossary · devancore.com
How it works
1. Token Creation and DTI Application
When a digital token is created — whether by deploying a smart contract on a permissioned settlement layer or by genesis block initialization on a public blockchain — the token's technical parameters become fixed: network, contract address, token standard, genesis block. The token issuer or operator submits these parameters to the DTIF registry to initiate DTI issuance. DTIF validates the submission against the on-chain state — confirming that the contract exists at the specified address on the specified network — and issues the DTI once validation is complete. For tokens that already exist without a DTI, the same registration process applies retrospectively; the genesis parameters are recoverable from the public ledger history.
2. DTI Registry Ingestion into the Instrument Master
Once issued, the DTI record in the DTIF registry is available for consumption by reference data systems. Devancore's platform subscribes to the DTIF registry feed and automatically ingests new and updated DTI records into the instrument master, alongside data from national numbering agencies (ISINs) and entity registries (LEIs from GLEIF). Each DTI record brings the full token parameter set: network, contract address, token class, genesis block, and fork lineage where applicable. This automated ingestion eliminates the manual data entry that would otherwise create both lag and error in the reference data record. See instrument master — securities and reference data management for the data model.
3. ISIN-DTI Mapping and 1:N Resolution
After DTI ingestion, the instrument master runs the mapping process that links each DTI to its corresponding ISIN (or confirms that a DTI has no ISIN — as is the case for native protocol tokens that represent no traditional legal instrument). For tokenized securities, the mapping is established using the issuer's registration metadata: the same entity that filed for the ISIN with the national numbering agency typically registers the DTI with DTIF using consistent legal entity and instrument identifiers. Where a 1:N relationship exists — the same bond tokenized on multiple networks — the instrument master holds all DTIs linked to the single ISIN, with each DTI tagged to its specific network and contract. The platform can therefore resolve any incoming trade or settlement record to the correct DTI based on which network the transaction touches, without manual intervention.
4. Trade Enrichment with DTI
When a trade is captured — whether from an execution venue, an OMS feed via FIX protocol, or a direct on-chain event — the trade enrichment process uses the instrument master to attach the full identifier set: ISIN, LEI, and DTI. For digital asset trades, the DTI is the key enrichment element: it confirms that the execution record references a known, registered token and resolves which network the settlement instruction must route to. Trades that cannot be enriched with a confirmed DTI — because the token is not in the registry — are flagged as reference data exceptions before they enter the settlement workflow. The exception fires before any settlement instruction is generated, preventing the downstream trade break that would result from routing an unidentified token to the wrong network or sub-account. See trade break management.
5. Settlement Instruction Routing via DTI
With the DTI confirmed, the settlement instruction is generated and dispatched to the correct settlement rail. The DTI's network parameter maps to the settlement layer: a DTI identifying a token on a permissioned DLT network routes to that network's settlement interface; a DTI identifying a token on a public blockchain routes to the corresponding on-chain settlement workflow; a DTI identifying a CSD-issued digital security routes to the CSD settlement instruction channel. The account segregation enforcement layer uses the DTI to confirm that the settlement instruction targets the correct on-chain wallet address or custodian sub-account registered for that specific token class and network. Two tokens with the same ISIN but different DTIs route to different settlement destinations — deterministically, without manual review. See settlement finality — DLT and blockchain.
6. Regulatory Reporting with DTI Payload
The completed settlement record — carrying both ISIN and DTI in the instrument identifier block — flows into regulatory reporting outputs in ISO 20022 format. The DTI appears in the OtherIdentification field of the securities reference block, alongside the ISIN in the standard SecurityIdentification field. Regulators and counterparties receiving these reports see both the legal instrument identifier and the digital token identifier, with no ambiguity about which specific on-chain token was transacted. For European participants operating under the ESMA DLT Pilot Regime or subject to MiCA transaction reporting, this dual-identifier reporting format satisfies the technical standard expectation that digital asset transactions be identified at the token level, not only at the legal instrument level.
DTI lifecycle — token creation to trade routing
Devancore Glossary · devancore.com
DTI lifecycle — token creation to trade routing
Devancore Glossary · devancore.com
In Devancore™
Devancore — DTI-native reference data architecture
Devancore Glossary · devancore.com
Devancore's reference data architecture treats DTI as a first-class identifier, not a field appended to a traditional instrument record. The platform ingests DTI data from the DTIF registry on the same automated basis as ISIN data from national numbering agencies — both arrive through the same reference data pipeline, both are stored in the same instrument master record, and both are available to every consuming system without translation overhead.
Native DTIF Registry Integration
Devancore subscribes to DTIF registry feeds directly, ingesting new DTI records and registry updates as they are published. When a new tokenized instrument is registered with DTIF, the DTI record is automatically matched against existing ISIN records in the instrument master to establish the ISIN-DTI mapping. Where a match is confirmed — same issuer LEI, same instrument class, consistent technical parameters — the mapping is recorded and immediately available for trade enrichment and settlement routing. Where no ISIN match exists, the DTI record is held as a standalone digital asset reference, correctly representing the reality that many digital tokens have no underlying traditional security identifier. This processing happens without manual data entry at any stage. See reference data management and instrument master — securities for the supporting architecture.
Fork-Aware Mapping and Network-Specific Routing
Devancore's ISIN-DTI mapping layer maintains full fork lineage: when a blockchain fork produces two successor tokens from a single predecessor, both post-fork DTIs are added to the mapping table with their respective fork heights and network identifiers. The mapping layer stores the fork event as a relationship between the pre-fork DTI and each post-fork DTI, so that historical positions held before the fork are correctly attributed to the successor token that the client elected to retain or receive. Settlement instructions generated after a fork use the post-fork DTI, ensuring routing to the correct chain without requiring manual position reconciliation to resolve which token the client holds. The hybrid settlement infrastructure dispatches instructions based on the DTI's network parameter — the same instruction format, the correct destination.
Trade Enrichment and Break Prevention
When a trade capture event arrives without a DTI — from a counterparty using a legacy identifier, or from an execution venue that identifies tokens by contract address alone — Devancore's trade enrichment engine resolves the identifier against the instrument master using the available parameters. Contract address, network, and token standard are sufficient to retrieve the confirmed DTI and attach it to the trade record before the settlement instruction is generated. If resolution fails — because the token is not in the registry, or because parameters are ambiguous — the trade is held as a reference data exception rather than passed to settlement. This exception-first posture means that reference data failures surface as enrichment exceptions, not as trade breaks discovered during post-settlement reconciliation, when the cost of resolution is substantially higher.
ISO 20022 and FIX Outbound Identifier Embedding
Devancore embeds both ISIN and DTI in all outbound settlement instructions and confirmation messages. ISO 20022 settlement instructions carry the DTI in the OtherIdentification block of the securities identification section; FIX protocol execution reports carry the DTI in the extended security identifier fields. Counterparties and custodians receiving these messages have full identifier context without requesting a separate reference data lookup. For regulatory reporting submissions — transaction reports, position reports, and audit records — the DTI is included in every record that involves a digital token, ensuring that the firm's regulatory submissions reflect the precision that DTI-aware reporting frameworks require. The identifier is not translated at the outbound boundary; it flows from the instrument master through the message to the receiver in the same form in which it was ingested. That continuity is the operational definition of reference data integrity for a hybrid post-trade system.