The reconciliation that never quite closes
A fund controller closing the books on a digital asset position pulls four documents: the custodian's holdings statement, the exchange's trade blotter, the fund accounting system's position report, and, for a European counterparty, a transaction report filed with a regulator. All four describe the same asset. None of them necessarily use the same string to name it.
The custodian may list it by the ticker printed on its client portal. The exchange blotter carries its own internal symbol, which may or may not match that ticker. The accounting system, if it ingests a third-party price feed, stores that vendor's proprietary identifier. The regulatory filing, if it falls under a regime that has adopted a token standard, carries a code none of the other three systems store at all. A human matches these by eye, asset by asset, every close. For many firms that manual match is not a rounding error in an otherwise automated process; it is the process.
What actually identifies a digital asset
The contract address and chain
The only identifier a blockchain itself enforces is the pair of chain plus contract address. USDC on Ethereum lives at a single, verifiable address (0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48, per Etherscan and Circle's own developer documentation); USDC on Solana is a separately deployed instrument with its own address, issued by the same company, redeemable for the same dollar, but not the same on-chain object. A reconciliation system that treats "USDC" as one row loses the chain dimension; one that treats every chain deployment as a wholly separate asset loses the fact that, economically, these are fungible claims on the same issuer. Neither convention is obviously correct, and firms differ on which they pick, which is itself a source of mismatch between a custodian's ledger and a fund's book.
The ticker
A ticker is not registered, not unique, and not controlled by any authority. When Paxos changed its stablecoin's ticker from PAX to USDP in August 2021, a decentralised lending platform, Unit Protocol, had been calling its own token USDP since at least July 2020. Before the 2017 Bitcoin hard fork, both the Bitcoin and Bitcoin Cash communities claimed the BTC ticker; what settled it was not an arbitrator but the general public continuing to attach BTC to the original chain, leaving BCH to the fork. Bitcoin Cash's own 2018 split then produced ad hoc labels such as "BCH ABC" and "BCH SV" until one faction reclaimed BCH and the other became BSV (CoinDesk, 5 September 2021). A stock ticker is arbitrated by the exchange that lists it. A crypto ticker is whatever the deploying team put in a metadata field, and two unrelated teams can put the same string there with no one to stop them.
The Digital Token Identifier
ISO 24165 defines the Digital Token Identifier (DTI): a nine-character alphanumeric code, together with a reference-data record, for a fungible digital token. Part 1, published in 2021, sets out registration and assignment; Part 2 defines the data elements held for each token. The DTI Foundation (DTIF), a non-profit division of Etrading Software, runs the registry, and Etrading Software is the Registration Authority for the standard. DTIF states that the DTI "is open and may be freely reproduced, distributed, transmitted, or otherwise used by anyone for any purpose, commercial or non-commercial at no cost", while it recovers the cost of running the registry through fees set on fair, reasonable and non-discriminatory principles (DTIF, dtif.org, accessed September 2026). Bitcoin's own DTI is 4H95J0R2X, and that code is what EU derivatives reporting now uses as the underlying-asset reference for products written on it. Assignment is not automatic: an issuer, exchange, custodian or vendor applies, and until an asset is registered it simply has no DTI, a gap regulators have had to build explicit fallback codes around, discussed below.
ISINs, and when a token gets one
The International Securities Identification Number, ISO 6166, predates digital assets by decades and is administered by the Association of National Numbering Agencies (ANNA). ANNA and DTIF announced a memorandum of understanding on 31 October 2023 to align the two standards, alongside a first set of ISINs for crypto assets carrying a new "XT" prefix; ANNA's digital assets page states that DTIF is the Designated Numbering Agency for XT ISINs. The two identifiers are not interchangeable, and ANNA's own framing is blunt: "ISIN identifies the asset. DTI identifies the token." In practice, a token acquires an ISIN when someone, typically an issuer or a numbering agency acting for one, wants it treated as a security-like instrument inside systems built around ISINs: custodians, fund administrators, exchange listing systems. A bearer token traded purely peer-to-peer on a decentralised exchange may never acquire one. On 4 August 2026 ANNA announced that DTI lookup had been integrated into the ANNA Service Bureau, so the two registries are now queryable from one interface rather than two.
Proprietary identifiers
Data vendors mint their own codes on top of all of the above, because their products existed before any of these standards did and their customers' systems are already wired to them. CoinGecko keys its API to a slug-style coin ID. Bloomberg's older BBGID scheme for securities was adopted by the Object Management Group in 2014 and renamed the Financial Instrument Global Identifier (FIGI), given approved status by OMG's Architecture Board in September 2015; the structure is defined by OMG and Bloomberg is the Registration Authority (Wikipedia, "Financial Instrument Global Identifier", accessed September 2026). These identifiers are useful, often richer on descriptive metadata than the regulatory standards, but they are commercial products: access, coverage and continuity depend on a vendor relationship, not a public registry.
The same asset, four descriptions
Put a single asset through a custodian, an exchange, an accounting system and a regulatory filing, and the mismatch compounds rather than cancels. The custodian's statement might key the position by ticker and chain, because that is what its wallet infrastructure natively tracks. The exchange's trade file might carry its own internal instrument ID with no DTI or ISIN field at all, because matching engines were built around tickers long before either standard existed. The accounting system, if it prices from a vendor feed, stores that vendor's coin ID, and unless someone has built and maintained a mapping table, that ID has no formal link to the custodian's ticker or the exchange's instrument ID. The regulatory filing, if the position sits inside a reporting regime that has adopted the DTI, needs a field none of the other three systems populate by default.
None of these four records is wrong on its own terms. Each is internally consistent with the system that produced it. The cost sits in the joins between them: a control function reconciling custodian to accounting has to build and maintain its own crosswalk, by hand, asset by asset, and re-validate it every time a vendor renames a field, a token is deployed on another chain, or an exchange delists and relists under a slightly different symbol. That is expensive in a way that scales with headcount rather than volume, and it is precisely the kind of manual mapping that produces a wrong number in an audited financial statement or an incomplete regulatory return, not through fraud but through an unmatched row nobody flagged.
Where an identifier is now mandatory in reporting, and where it is not
The regulatory picture is more mixed than "identifiers are now required", and the differences matter.
Under the EU's Markets in Crypto-Assets Regulation, ESMA has stated that "in the absence of any alternative identifier defined at Union level, all CASPs and any other preparer of crypto-asset white papers should identify the crypto-asset by using a digital token identifier that is compliant with the ISO 24165 standard". The obligation sits in the record-keeping RTS and the white paper classification RTS, both of which entered into force on 3 April 2025 and apply from that date, as do the RTS on order book records and on transparency data; the implementing standards on the form and format of white papers apply from 23 December 2025. These are current obligations, not proposals. The statement is reproduced here from the third-party MiCA tracker mica.wtf, because ESMA's own PDF could not be parsed.
Under EU EMIR, crypto-asset derivatives in scope have needed a Unique Product Identifier since EMIR Refit took effect on 29 April 2024, and generating that UPI for a crypto-referencing derivative requires selecting a DTI as the underlier. Where no DTI exists for the underlying token, ANNA-DSB permits an "OTHER" value, with the result that two different crypto contracts can end up sharing one product identifier, which defeats the point of a unique identifier and is itself evidence the registry is still catching up with the market it describes (TRAction Fintech, a derivatives-reporting compliance vendor, 23 July 2025).
In the United States, the instructions for Form 1099-DA direct custodial brokers to "enter the nine alphanumeric characters of the digital token identifier issued by the Digital Token Identifier Foundation (DTIF)" in box 1a, with the name matching the DTIF registration in box 1b, and, "if the digital asset is not registered with DTIF, enter '999999999'". The IRS states that for 2025 the Form 1099-DA filing requirements generally apply to US brokers, so this is a live requirement rather than a draft; the instructions cited here were revised on 30 April 2026 and cover sales effected after 2025.
The OECD's Crypto-Asset Reporting Framework and its EU transposition, DAC8, are on a different footing again. Member States had to transpose DAC8 by 31 December 2025, reporting service providers began collecting data on 1 January 2026, and the first cross-border exchange between EU tax authorities falls due by 30 September 2027; on Regnology's count, 46 jurisdictions sit in the first CARF wave, reporting in 2027. Neither regime, on the sourcing available, prescribes a specific token identifier standard the way MiCA and the 1099-DA instructions do: CARF sets out what data must be collected and exchanged about a transaction without mandating the code used to name the asset. Anyone dealing with CARF and DAC8 filing mechanics should treat this piece as background rather than the primary reference; our separate post on CARF and DAC8 reporting covers the filing regime itself.
The pattern across these regimes is not uniform adoption of one identifier. It is several regulators independently reaching for the DTI because it is the only ISO-standard option that exists, while leaving gaps, the "999999999" box, the "OTHER" underlier, for the tokens nobody has registered yet.
What a data policy has to fix
The unglamorous fix is a single internal golden-source mapping table: one row per asset per chain, carrying the ticker in use at each counterparty, the DTI where one exists, the ISIN where one exists, the contract address per chain, and the vendor ID for whichever pricing feed the firm actually uses, with a named owner responsible for updating it when any one of those changes. That table is not a regulatory requirement anywhere cited above; it is what makes meeting those requirements, and closing the books without a manual reconciliation exercise every period, possible at all.
Three decisions belong in that policy rather than being left to whoever happens to be doing the reconciliation that month. First, the chain-granularity question: does a multi-chain asset get one internal record or one per deployment, and is that consistent with how the firm's custodian and accounting system already treat it. Second, what happens when an asset has no DTI: is it flagged, tracked and re-checked on a cadence, or does it sit as an unmapped row until an audit finds it. Third, who owns the table when a vendor renames a field or a token appears on a new chain, because a mapping that is accurate at go-live and unowned thereafter degrades exactly as fast as the market does. None of this is tax, legal or accounting advice, and firms should take their own counsel on how any of the reporting regimes above apply to their own positions; it is a description of an operational problem and the standards that currently exist to address it.
For the accounting and audit consequences of a mismatched or unmatched position, see our companion pieces on how digital assets land on the balance sheet and on fund administration and NAV; for what a custodian's own records can and cannot establish about a position independent of any identifier scheme, see what onchain data can and cannot tell an allocator. Tokenised real-world assets carry their own identifier questions from the moment of issuance, covered in our piece on RWA tokenisation moving from pilot to production.