Digital Assets Have Standards. What They Lack Is an Architecture.

Tokenization is often described as a technology transition. For financial institutions, it is more accurately a standards-integration problem. A bond, fund interest, derivative, settlement asset or collateral position becomes dependable only when its legal rights, economic terms, identifiers, messages, ledger controls, custody arrangements and settlement rules remain aligned through issuance, trading, servicing, default and exit. This article presents the principal findings of the Intelligence Economy Institute's new report, Standards for Digital Assets: The Institutional Stack from Legal Rights to Ledger Finality, and introduces the staged September 2026 launch of the Digital Assets Standards Lab, which is designed to help institutions turn a fragmented landscape into implementable architecture.

A market rich in standards and short of architecture

The digital-asset industry does not have a standards shortage. It has a composition problem.

A financial institution preparing a tokenized bond can already draw on private-law principles, securities regulation, the ICMA Bond Data Taxonomy, the Common Domain Model, ACTUS, ISO identifiers, ISO 20022, FIX, token interfaces, identity frameworks, custody controls, payment rails and market-infrastructure rulebooks. The catalogue is long enough to create the impression that the hard work has been done. Yet none of those artifacts, alone or in a stack assembled by acronym, tells an institution precisely what a token transfer means, which record prevails after a discrepancy, when the cash leg is final, or how an erroneous corporate action is repaired.

This is why projects that appear technically complete can remain institutionally incomplete. A smart contract may mint the correct number of units but leave ownership dependent on a separate registrar. A settlement instruction may validate against an ISO 20022 schema but breach the market's usage rules. A common event model may calculate a coupon correctly while the paying agent works from a different record-date position. A digital identity can authenticate an organization without proving that the person or software agent had authority to trade that instrument at that time. An atomic transaction can complete on one ledger while failing to discharge the legal obligation that motivated it.

The Intelligence Economy Institute's report, Standards for Digital Assets: The Institutional Stack from Legal Rights to Ledger Finality, is published in September 2026 against that background. Its research base classifies 255 artifacts and 251 primary-source links across law, international principles, formal standards, financial taxonomies, protocol specifications, public programmes, production systems and open implementations. Its conclusion is less a call for another universal standard than a demand for a disciplined way to compose the standards that already exist, and to identify what they cannot do.

The report starts with a deceptively simple proposition: the token is not necessarily the asset. It may be the legally recognized record of a security. It may be an entitlement against a register held elsewhere, a digital twin of a CSD position, a receipt against assets held by a custodian, or an operational object used to coordinate workflow. Two tokens can expose the same transfer function and confer radically different rights. Conversely, two legally equivalent instruments can use different ledgers and interfaces. The legal and operating model has to be fixed before the technical representation can be judged.

That distinction becomes more important as tokenization moves from demonstration to balance sheet. The cost of ambiguity is no longer a failed pilot. It is an unclear claim in insolvency, a broken entitlement, an unreconciled position, a settlement exposure or a control that cannot withstand audit.

The four truths of a financial instrument

Every institutional digital asset has four truths that must remain aligned.

The first is legal truth: who holds which enforceable right, against whom, under what law, and at what moment transfer or settlement becomes effective. Its sources are legislation, issuance documents, register and custody rules, market-infrastructure rulebooks, agency terms and insolvency law. Ledger control can be legally decisive, but only where law or contract makes it so.

The second is economic truth: what the parties are owed. It covers principal, interest, amortization, optionality, collateral, valuation, net asset value, cashflows, events and state transitions. Product taxonomies and domain models can express this information. They do not displace the governing documents unless the legal arrangement gives them that role.

The third is operational truth: what has been instructed, accepted, rejected, repaired, confirmed and reported. This is the world of ISO 20022, ISO 15022, FIX, FpML and proprietary operating messages. A message can be syntactically perfect and still be unauthorized, duplicated, late or economically wrong.

The fourth is ledger and custody truth: which balances and states a technical system records, who controls the keys, how transactions are ordered, what the system treats as final, and how custody positions reconcile. That truth may be legally authoritative, derived from another record or merely evidential. The architecture must say which.

Tokenization scales when legal, economic, operational and ledger truths can be mapped, tested, reconciled and corrected without private interpretation at every institution.

Each truth has its own failure mode. Legal ambiguity creates an asset whose ownership or priority is uncertain. Economic ambiguity produces competing calculations and entitlements. Operational ambiguity creates failed matching, duplicate instructions and exception queues. Ledger ambiguity can produce excess supply, over-privileged administrators, lost access or conflicting views of finality. Standards are useful insofar as they reduce those ambiguities. They are dangerous when their presence is mistaken for proof that another layer has been solved.

This four-truth model changes the standards debate. ICMA's Bond Data Taxonomy, the FINOS Common Domain Model, ACTUS, FpML, FIX, ISO 20022 and ERC-3643 are not rival solutions to one problem. They operate at different depths and times. One can normalize issuance terms; another can express lifecycle events; another can carry orders or settlement instructions; another can control transfers. A dependable system needs to state where each begins, where it ends and how information crosses the seams.

Not all standards are standards in the same sense

The market uses one word for artifacts with radically different force. A regulation can be binding but technically sparse. An ISO standard can be formally approved but require a market profile before it becomes operational. An industry taxonomy can be semantically rich without legal authority. An Ethereum proposal can be marked "Final" while remaining unaudited or lightly adopted. A central-bank pilot can demonstrate feasibility without creating a production rulebook. A vendor platform can process large volumes without being a portable standard.

Putting those objects on one maturity ladder makes poor architecture look scientific. The report instead separates authority, native process status, implementation maturity, adoption, assurance, legal effect and portability. These axes are independent.

Consider the phrase "final standard". In the Ethereum Improvement Proposal process, Final is a native status: the document has reached a defined point in that process. It is not a conclusion that every implementation is secure, that regulators recognize the design, that the code has been audited or that market infrastructures can support it. The inverse is also true. The ERC-1400 family has influenced security-token designs despite never becoming a Final ERC. Usage does not rewrite formal status, and formal status does not prove usage.

The same caution applies to public initiatives. The EU DLT Pilot Regime is law within a defined scope. The Principles for Financial Market Infrastructures ↗ are international standards implemented through legal, regulatory and oversight arrangements. The Digital Asset Securities Control Principles ↗ published by DTCC, Clearstream and Euroclear are an FMI-led control framework. Project Guardian is a public-private experimentation and framework programme. Project Helvetia is evidence from central-bank-money settlement experiments. None should be cited as if it carried the authority of another.

An institution should therefore record at least four things for every selected artifact: its issuer and native status; the precise version or release; the role it plays in the proposed architecture; and the evidence that the proposed implementation conforms. Brand-level claims such as "ISO ready", "institutional grade", "MiCA compliant" or "based on a central-bank pilot" do not meet that test.

A financial instrument is a controlled composition

The practical unit of design is not the token contract. It is a versioned standards profile spanning the life of the instrument.

At the legal and claim layer, the institution defines the instrument, governing law, obligor, holder right, authoritative record, transfer moment, settlement discharge and insolvency treatment. The UNIDROIT Principles on Digital Assets and Private Law ↗ offer a rigorous framework for questions of control, custody, acquisition and secured transactions, but national implementation and transaction documents remain decisive.

At the product and event layer, it defines terms, calculations, calendars, lifecycle events and state. At the identifier layer, it distinguishes entities, instruments, products, transactions, venues, accounts, token implementations and ledger operations. At the message layer, it pins the business messages, usage guidelines, code lists, transports and acknowledgements. At the execution layer, it selects token interfaces, compliance modules, smart-contract roles and administrative powers. Settlement, custody, identity, security, accounting, evidence and governance form additional layers, each with its own authority of record.

The work also divides by time. During design, standards help define the claim, semantic model, identifiers, messages, controls and invariants. At issuance, they support registration, minting, account opening and initial distribution. During runtime, they shape orders, policy checks, transfers, settlement, custody and reporting. During servicing, they govern events, elections, valuations, entitlements and corrections. During change, they determine version impact, migration and backward compatibility. At exit, they must support redemption, detokenization, archive and recovery.

Composition is not achieved by linking APIs. Each boundary needs a mapping contract: source and target versions, field and event meaning, units, cardinality, code lists, conditions, provenance, ownership, validation rules and known information loss. That contract must be testable. Where a mapping cannot preserve meaning, the architecture should expose the gap rather than hide it in a narrative field or a developer assumption.

Financial language must come before ledger execution

The strongest financial standards in the landscape solve different semantic problems.

The ICMA Bond Data Taxonomy ↗ creates a structured language for bond issuance data. It can improve the passage from term sheet to legal documentation, syndication, issuance and downstream processing. It is especially useful where one term has been re-keyed into several systems. It does not, by itself, calculate every lifecycle event, transfer the security or settle cash.

The Common Domain Model ↗, developed through FINOS with financial-industry domain bodies, provides a model for products, events and processes. Its value lies in turning lifecycle semantics into a form that can be implemented consistently. But a CDM event remains part of a larger legal and operational chain. The institution must determine how the event relates to governing documents, external messages, accounts and settlement evidence.

ACTUS ↗ approaches finance through standardized contract types and deterministic cashflow algorithms. It is powerful where institutions need a common computational representation of obligations and scenarios. It does not supply the full securities register, discretionary servicing process or market-infrastructure workflow.

FpML ↗ remains central to the representation and messaging of OTC derivatives and structured products. FIX dominates electronic trading workflows, with application semantics, session behavior and encoding selected separately. FIX application protocols ↗ describe orders, quotes, executions, allocations and related processes; they do not make an execution report the authoritative ownership record.

ISO 20022 is perhaps the most frequently misdescribed standard in tokenization. It is not a token standard and it is not simply XML. It is a methodology, metamodel, registration process and repository of financial messages. A practical implementation is not "ISO 20022" in the abstract. It is an exact message and version, business application header, code-set release, usage guideline, market-practice rule, transport profile and operating procedure. A schema-valid message can still fail the community's business rules or carry incorrect information. No blockchain is generically "ISO 20022 compliant"; a particular workflow can implement a specified profile.

The sequence matters. Semantics must precede messaging, and messaging must remain distinguishable from execution. If two institutions disagree on what a record date, business day, accrued amount or redemption event means, an interoperable message transports the disagreement faster. If an execution engine receives a semantically lossy mapping, deterministic code makes the error repeatable.

This is also why corporate actions are a decisive test. Issuance is comparatively clean. Servicing requires event announcements, replacements, cancellations, record-date positions, elections, proration, fractions, tax, cash confirmations, corrections and unclaimed entitlements. ISO securities messages cover much of the communication. Domain models cover parts of the economics. Token contracts can distribute or transform units. No accepted universal smart-contract standard supplies the entire operating model, and few prototypes are tested against the ugly history of real events.

Token standards are useful precisely where their limits are clear

Token interfaces reduce integration costs. ERC-20 gives wallets, exchanges and applications a common way to handle fungible units. ERC-721 and ERC-1155 support other ownership patterns. Signature and permit standards improve delegated execution. Those are significant gains, but an interface specifies callable behavior, not the legal substance of the instrument.

ERC-3643 goes further than a basic interface. It combines a permissioned token with identity claims, modular compliance, registries and administrative capabilities. For regulated distribution, this is closer to a framework than a simple transfer function. Yet its modules still need authoritative policies, trusted data, governance, role separation, privacy, operational continuity and a legal model for the asset. A transfer approved by the contract can be inconsistent with a stale credential or an external restriction. A forced transfer or freeze function can be necessary for legal and operational recovery while creating a powerful control that must itself be bounded and evidenced.

Vault standards illustrate the same distinction. ERC-4626 standardizes how vault shares relate to underlying assets. ERC-7540 adds asynchronous request flows; ERC-7575 addresses multi-asset vault arrangements. These conventions improve composability. They do not turn a vault into a regulated money-market fund. The fund still needs constitutive documents, transfer agency, NAV governance, dealing cut-offs, queues, gates, suspension, liquidity management, equalization, fees, tax, holder records and cash settlement. The standard interface is a component of the product architecture, not a substitute for it.

The gaps grow wider in private credit. Loans are amended, waived and serviced. Collateral changes. Transfers can require consent. Interest can be capitalized. Information is private, and agents exercise judgment. ACTUS, CDM and FpML provide valuable pieces, but there is no universal global model for the ownership and complete servicing of a tokenized loan or credit fund. The absence should be documented rather than papered over with an ERC label.

Identity is a graph, not a blockchain address

Institutional finance has spent decades assigning identifiers to distinct objects. Tokenization adds new objects; it does not make the distinctions obsolete.

An ISIN identifies a financial instrument within its scheme. A CFI classifies it. A FISN supplies a standardized short name. A DTI identifies a digital token at the technical layer. A UPI identifies an OTC derivative product; a UTI identifies a transaction. A MIC identifies a market organization. A BIC supports business identification and routing. An IBAN identifies a bank account under participating formats. An LEI identifies a legal entity. A wallet address, contract address and ledger transaction hash identify still other things.

Using any one as a universal key creates false equivalence. A token can have several deployments. One instrument can have multiple token representations. A transaction can generate several messages and ledger operations. A legal entity can control several accounts through different intermediaries. The solution is a typed relationship graph with provenance, validity periods, predecessor and successor links, and an authority for each mapping.

The Global Legal Entity Identifier Foundation's architecture deserves particular attention because the LEI is often treated as a twenty-character label rather than a governed data system. The global chain runs through the LEI Regulatory Oversight Committee, GLEIF, accredited Local Operating Units and the legal entity. Level 1 data answers "who is who" through maintained entity records. Level 2 data reports direct and ultimate accounting-consolidating parents, together with reporting exceptions. Those exceptions matter: an absent reported parent is not automatically proof that no relationship exists.

The verifiable LEI adds cryptographic organizational credentials. Under the vLEI Ecosystem Governance Framework ↗, GLEIF anchors a governed chain through Qualified vLEI Issuers, legal entities and organizational roles. Official Organizational Role and Engagement Context Role credentials can make organizational authority more portable and machine-verifiable. This is more than reference data, but it is not a universal permission slip.

A production transaction still needs a last-mile chain: current entity and relationship data; valid issuer and credential status; current key state; the organizational role; a binding to the relevant account, wallet or software workload; and a scoped transaction mandate. The mandate should define the assets, actions, limits, counterparties, venues, period and delegation rights. A valid CFO credential does not authorize every payment. A current LEI does not prove KYC, sanctions clearance, solvency or wallet control. Identity, eligibility, technical control and authority are different assertions.

This distinction will become fundamental as institutions allow software agents to act. The question will no longer be only "which organization is this?" It will be "which workload is acting for which principal, under which role and mandate, on which account, for this action, at this time?"

Money is defined by the claim, not the token label

Tokenized money is one of the fastest-moving and most confused parts of the standards landscape. A currency code and a transfer interface can sit on claims of very different quality.

Central-bank reserves are liabilities of a central bank to eligible account holders. A wholesale CBDC or tokenized-reserve design remains a central-bank liability under its own rulebook. A tokenized commercial-bank deposit is a claim on the issuing bank, subject to its balance sheet and resolution regime. An electronic-money token or payment stablecoin is a claim under a distinct regulatory and reserve arrangement. A private settlement token depends on consortium or issuer rules. A tokenized money-market fund is an investment fund share with NAV and liquidity risk, not a deposit. A synthetic crypto asset may have no general legal right to par conversion at all.

The same ERC-20 function can move each of them. It says almost nothing about the obligor, reserve assets, segregation, redemption, access, insolvency priority or discharge of a payment obligation.

That is why there is no global tokenized-money standard. There are regulatory regimes, international recommendations, message standards, technical interfaces and public experiments. In the European Union, MiCA distinguishes electronic-money and asset-referenced tokens, while financial instruments remain under financial-services law. The European Banking Authority has separately examined tokenized deposits. The US GENIUS Act establishes a federal payment-stablecoin framework with future effectiveness and implementing work. Hong Kong, Singapore, Japan, Switzerland, the United Arab Emirates and the United Kingdom use their own legal categories, dates and supervisory models. A cross-border architecture needs a dated jurisdictional matrix, not a boolean field called "regulated".

Internationally, the Financial Stability Board's stablecoin recommendations ↗, the Basel framework, FATF standards and CPMI-IOSCO guidance on systemically important stablecoin arrangements ↗ address governance, prudential treatment, financial crime, stabilization, redemption and infrastructure risk. None defines a universal smart contract.

Public projects are nevertheless producing important architecture evidence. Project Agorá ↗ tested a two-tier model combining tokenized commercial-bank deposits and central-bank reserves on a programmable platform. Project Helvetia has examined wholesale central-bank money for tokenized-asset settlement. The Swiss Bankers Association has developed a deposit-token model; UK banks have explored tokenized deposits; Swift has tested orchestration for bank liabilities. These efforts reveal a convergence around programmable commercial-bank money and central-bank settlement. They have not erased the differences between issuers, jurisdictions or balance sheets.

The essential control questions are old banking questions expressed in a new system: Who owes the holder? What supports the obligation? Is conversion at par a legal right? Who has direct access? Which record is authoritative? What happens in resolution? When is a payment irrevocable, and what legally discharges the debt? Programmability is valuable only after those questions have answers. A token that moves around the clock while its redemption and liquidity rails close overnight can turn continuous transfer into a continuous exposure.

Atomic code is not settlement finality

Delivery-versus-payment is often presented as the signature benefit of tokenization. The promise is real: coordinated asset and cash transfers can reduce principal risk, manual reconciliation and settlement latency. The shorthand is often wrong.

DvP is not the mere co-occurrence of two transfers. Both legs must be valid, recognized and final under their respective systems, and their conditional relationship must survive failures. The architecture has to define reservation, commit, timeout, cancellation, partial settlement, rollback or compensation, reorganization policy, operator intervention and the moment of legal discharge. If one leg is a security recorded by a CSD and the other is a tokenized commercial-bank claim on another network, single-chain atomicity is not even the relevant model.

The PFMI remain the anchor for systemically important payment, clearing and settlement arrangements. The Digital Asset Securities Control Principles translate key concerns (legal basis, governance, asset protection, settlement, resilience and interoperability) into the digital-securities context. Project Meridian ↗ showed how a synchronisation operator can coordinate transfers across conventional settlement systems. The lesson is not that one mechanism has won. It is that connectivity, conditionality and legal finality must be analyzed separately.

Cross-chain systems sharpen the same point. A message bridge may prove that a message was observed. It does not prove that a destination token carries the same rights, that total supply remains controlled, that the policy state is equivalent or that recovery works after a route fails. Legal, semantic, identity, policy, state and settlement interoperability are separate properties. "Connected" is not a synonym for "interoperable".

Digital twins create an additional precedence problem. If a token mirrors a registrar, CSD, ICSD or transfer-agent record, the system needs an explicit authoritative source, synchronization objective, permitted discrepancy window, suspension rule, supply control, correction authority, reconciliation frequency and detokenization path. Without that hierarchy, the architecture has one asset and two plausible truths.

Agent-to-agent finance needs a mandate layer

Software agents are arriving just as financial assets and money become programmable. The combination is likely to change discovery, execution, treasury and operations. It also exposes a standards gap more fundamental than the payment API.

The Agent2Agent Protocol ↗ provides a way for agents to advertise capabilities, exchange messages and manage tasks. The Model Context Protocol ↗ allows a host to discover and invoke tools, resources and prompts. Commerce and payment initiatives such as AP2, UCP, ACP, x402 and MPP address different parts of intent, checkout or payment initiation. OAuth, FAPI, GNAP, HTTP Message Signatures and workload-identity frameworks secure authentication and delegated API access.

These protocols are complementary. None, by itself, confers financial authority.

An Agent Card is a discovery object, not a regulated identity. A completed A2A task is a protocol state, not proof that a trade was valid. An MCP tool call can be authenticated and still exceed the principal's mandate. A payment protocol can produce a merchant acceptance or rail response without establishing ultimate settlement finality. A technically successful chain may therefore connect the wrong legal principal to the right API with the wrong economic instruction.

Institutional agentic finance needs a machine-readable mandate bound to the principal, organizational role, workload, accounts, assets and permitted actions. It must define limits, counterparties, jurisdictions, effective time, delegation depth, revocation and human-escalation conditions. It must also preserve domain semantics. An agent moving between A2A and MCP should not lose the UTI, instrument identity, unit, event lineage, ISO message profile or settlement condition.

The runtime chain should be reconstructable: identify the legal principal; authenticate the workload; resolve the role and account binding; validate the current mandate; evaluate product and jurisdiction policy; preserve the financial instruction; execute through the selected rail; establish settlement evidence; reconcile the result; and retain enough context for audit and dispute. Model non-determinism does not justify non-deterministic authority. The agent may reason flexibly; the boundary of what it is allowed to do should be explicit and provable.

This is where the LEI/vLEI stack, workload identity, financial messaging and payment standards begin to compose. It is also where the industry has the most work left. Today, protocols are advancing faster than the legal and operational model of multi-hop delegation, liability, reversal and evidence.

Jurisdictions and public models are design inputs, not universal templates

Institutional tokenization is developing through a patchwork of legislation, sandboxes, central-bank experiments and market-led frameworks. The patchwork is useful. It becomes dangerous when context is stripped away.

Switzerland's ledger-based securities regime gives legal recognition to a defined form of rights recorded through distributed-ledger technology, while Swiss projects have explored central-bank and commercial-bank settlement. Singapore's Project Guardian has produced fixed-income, funds and interoperability frameworks; Purpose Bound Money separates a conditional wrapper from the underlying medium of exchange; Global Layer One explores shared market-infrastructure and programmable-compliance models. Hong Kong's Project Ensemble and stablecoin regime address different layers. The EU combines MiCA, the DLT Pilot Regime and existing financial-services law. The UK Digital Securities Sandbox modifies selected rules for controlled live experimentation. Japan, the UAE and the US use other classifications and implementation timetables.

These models should be mined for explicit design choices: Which operator is regulated? What is the asset's legal form? Who can participate? Which cash leg is used? How is compliance expressed? What data can move? What happens on failure? Which code or documentation is actually open? They should not be cited as generic regulatory approval for architectures they did not test.

Public access also needs precision. A report can be public without its implementation being open source. A repository can be visible without a production licence or governance commitment. Regulator participation does not endorse every component used in a pilot. An announcement does not create general availability. Institutions need an evidence register that preserves these distinctions alongside each architecture decision.

The implementation risk sits between the layers

Most institutional failures will not arise because ERC-20's transfer function was misunderstood or because an ISO schema was unavailable. They will arise at the boundaries: a term copied differently into code and documentation; an identifier relationship that changed without propagation; a message version upgraded by one participant; a credential revoked after a cache was populated; a final ledger transaction that the legal register did not recognize; a corporate-action correction that the token contract could not reverse.

The operating environment imposes constraints that standards catalogues tend to hide. Permissioned and public networks offer different access, confidentiality, ordering and recovery assumptions. A protocol may depend on public reference data that cannot be redistributed under the required licence, or on a market-practice guide available only to participants. Legacy CSD, transfer-agent and core-banking systems may support only older messages and batch cut-offs. Gas, latency and data-availability costs can make on-chain servicing impractical. Privacy rules can prevent the replication of beneficial-owner or transaction data even where a schema permits it. Administrative powers needed for sanctions, court orders and key recovery can weaken composability or concentrate risk. These are not reasons to reject a standard. They are parameters that must be carried into the implementation profile and tested under the proposed deployment.

That shifts assurance from component testing to cross-layer invariants. Total token supply should equal, or reconcile under a stated rule to, the authoritative issued amount. Every ledger holder should correspond to an eligible holder or controlled intermediary arrangement. Every payment should map to an economic obligation and settlement evidence. Every corporate action should produce entitlements from the authoritative position and event state. Every administrative action should have a valid role, mandate and audit record. Every transformation should preserve identifiers, units, version and provenance.

A smart-contract audit remains necessary, but it proves only a bounded part of that system. Legal analysis, semantic validation, message conformance, identity testing, custody controls, operational resilience, accounting lineage and migration drills are separate forms of assurance. Evidence should identify the exact environment, code, model, profile, configuration, date, scope and unresolved findings. "Audited" is not a portable property of a product across upgrades and deployments.

Change governance is therefore part of the standards profile. A production architecture needs a version tuple covering legal documents, semantic models, identifiers and reference data, messages and code lists, smart contracts, deployment configuration, policies and evidence. When one element changes, a dependency graph should identify which mappings, tests, opinions and controls become stale. Proxy contracts and upgrade keys are implementation mechanisms, not governance.

Exit is equally important. Securities can outlive networks, vendors, cryptographic algorithms and API versions. The architecture needs export, archival validation, key and provider failure procedures, identifier continuity, migration and detokenization. A token swap that leaves duplicate claims or loses servicing history is not a successful migration.

The research agenda is now an engineering agenda

Some of the market's most important standards gaps are no longer conceptual. They are suitable for joint specifications, test suites and reference implementations.

First, the industry needs tested semantic mappings between bond, derivatives, contract and message models. Field-name crosswalks are insufficient. The mapping must capture units, cardinality, conditions, provenance, lifecycle state and information loss.

Second, DvP and tokenized-money profiles need legal finality matrices and failure tests across asset and cash rails. Singleness of money, par conversion, liquidity and resolution cannot be inferred from technical atomicity.

Third, corporate actions need an end-to-end tokenization profile built on existing ISO messages and market practice. Historical edge cases (replacements, elections, withholding, fractions, claims and corrections) should become public conformance vectors.

Fourth, the GLEIF identity stack needs a conformance profile that reaches from current entity and relationship data through vLEI credentials to account, wallet, workload and transaction mandate. Negative tests should include stale roles, key rotation, revoked credentials, expired mandates, wallet reassignment and verifier outage.

Fifth, custody needs a common control-evidence model separating beneficial ownership, book ownership, signing capability, policy authority and safeguarding responsibility. Recovery should be judged by preservation of rights, not simply restoration of a key.

Sixth, cross-network profiles need supply-conservation rules, canonical-asset definitions, route and finality assumptions, incident procedures and exit. Bridge connectivity without asset continuity is not interoperability.

Seventh, funds and private credit need event and evidence models for asynchronous, privacy-sensitive and exception-heavy workflows. NAV corrections, queues, gates, waivers, amendments and collateral changes are not edge cases; they are the product.

Eighth, accounting, tax and regulatory reporting need event-to-book lineage. Ledger evidence, valuation, journal entries, tax lots and report facts should be connected without pretending that a public token balance answers the accounting question.

Finally, agentic finance needs a standard mandate object, domain-preserving A2A and MCP profiles, liability rules and reconstructable evidence. Task completion, policy authorization, payment acceptance and legal finality should appear as separate states.

Progress should be measured in operational terms: the share of material fields with tested mappings; the number of independent implementations passing the same negative vectors; time to detect and repair a reconciliation break; manual exceptions per lifecycle event; successful migrations without duplicate claims; and the percentage of assurance statements with explicit scope, version and expiry triggers. Counting pilots and acronyms rewards activity. These measures reward control.

From the report to the Digital Assets Standards Lab

The Intelligence Economy Institute will begin a staged launch of the Digital Assets Standards Lab in September 2026 alongside the report. The Lab is designed around a practical observation: financial institutions rarely need a general answer to "which token standard is best?" They need an architecture for a particular instrument, jurisdiction, operating model and distribution strategy.

A Eurobond issued through an ICSD structure, a native digital bond, a tokenized money-market fund, a private-credit vehicle, a collateral network and an exchange do not have the same legal record, servicing events, cash options, privacy needs or exit routes. Even within one product, the architecture changes if the token is native rather than a twin, if investors hold directly rather than through custodians, or if settlement uses central-bank money rather than an issuer stablecoin.

The launch begins with the report's 255-artifact, source-backed research foundation. The Lab will maintain that landscape as a structured knowledge base rather than a static list, while architecture workflows and product profiles move through controlled early access. Artifacts will be classified by authority, maturity, layer, lifecycle phase, jurisdiction, implementation availability, licence and known constraints. Status changes will be recorded without converting a proposal, pilot or service into something it is not.

Institutions will be able to begin with the product they are trying to build, a bond, Eurobond, fund, private-credit instrument, exchange, collateral arrangement or tokenized-money workflow, and specify the relevant legal and operating choices. The system will then assemble the available standards options, expose incompatibilities and missing decisions, and produce a token-architecture dossier. The output is intended to include the claim model, authority-of-record matrix, economic taxonomy, lifecycle functions, identifier graph, message profiles, token and compliance controls, settlement design, custody and identity requirements, evidence plan, version manifest and open gaps.

The value lies as much in exclusions as selections. If ERC-4626 is chosen for fund share mechanics, the output should show what remains outside it. If ISO 20022 is selected for settlement messaging, it should require an exact profile and keep finality separate. If vLEI is used for organizational roles, the account and mandate bindings should remain visible. If a public programme supplies design evidence but not a production licence, the distinction should survive the export.

The resulting dossier can be exported for procurement, legal analysis, product governance, implementation or assurance. Institutions that want to move from architecture to delivery will also be able to request implementation through the IEI platform, with work scoped against the same versioned profile. This creates a traceable bridge from research to build: decisions made in the architecture should become requirements, tests and evidence rather than disappear into a slide deck.

The Lab is not intended to certify every digital asset or declare a winning stack. Standards authority is distributed across lawmakers, regulators, ISO committees, industry associations, financial market infrastructures, open technical communities and market participants. The Lab's role is to make that distribution navigable and testable for a specific institutional use case.

The standard is the agreement between the standards

Tokenization has spent a decade making units easier to issue and move. Institutional finance now has to make the movement mean the same thing to the contract, the ledger, the custodian, the paying agent, the supervisor, the accountant and the investor.

That will not be achieved by finding a single universal protocol. The most credible architecture will often look plural: BDT for issuance terms, CDM or ACTUS for events and calculations, FIX for trading, ISO 20022 for settlement and asset servicing messages, LEI and vLEI for parts of organizational identity, an ERC or platform-specific framework for ledger control, and an FMI or payment-system rulebook for finality. The decisive artifact is the controlled agreement between them.

Such an agreement names the authoritative source for each state. It pins versions. It defines mappings and loss. It assigns manual decisions. It specifies failure and correction. It tests adverse conditions. It governs change and exit. It says, in terms an auditor and operator can verify, not only how the token moves but what the movement means.

The digital-asset market already has enough standards to build serious infrastructure. It now needs the discipline to stop treating their coexistence as composition. The next phase of tokenization will be won in the seams.

Selected primary sources and standards

• UNIDROIT, Principles on Digital Assets and Private Law ↗, private-law analysis of control, custody, acquisition and secured transactions.
• ICMA, Bond Data Taxonomy ↗, structured bond issuance terms and data.
• FINOS, Common Domain Model ↗, financial products, events and processes, developed with industry domain bodies.
• ACTUS Financial Research Foundation, Data and Algorithmic Standards ↗, contract types and cashflow algorithms.
• ISO 20022 ↗ and CPMI harmonised data requirements ↗, financial messaging methodology, repository and cross-border payment data.
• FIX Trading Community, FIX application protocol ↗ and FpML ↗, trading workflows and OTC financial-product representation.
• GLEIF, Legal Entity Identifier ↗ and vLEI Ecosystem Governance Framework ↗, legal-entity reference data and governed verifiable organizational credentials.
• CPMI-IOSCO, Principles for Financial Market Infrastructures ↗ and DTCC, Clearstream and Euroclear, Digital Asset Securities Control Principles ↗, settlement, infrastructure and digital-securities controls.
• ERC-3643 ↗ and ERC-4626 ↗, permissioned-token and vault interface frameworks, whose native technical scope does not establish the complete financial product.
• BIS Project Agorá ↗, Project Helvetia ↗ and Project Meridian ↗, public architecture evidence for tokenized money and synchronized settlement.
• Financial Stability Board, Global Stablecoin Recommendations ↗ and CPMI-IOSCO, Application of PFMI to Stablecoin Arrangements ↗, international policy and infrastructure expectations.
• Agent2Agent Protocol ↗, Model Context Protocol ↗ and OpenID FAPI 2.0 Security Profile ↗, agent coordination, tool invocation and high-security API authorization.
• Bank of England and FCA, Digital Securities Sandbox ↗, MAS Project Guardian Fixed Income Framework ↗ and Global Layer One ↗, jurisdictional experimentation and public-private market-infrastructure models.

This article accompanies the September 2026 publication of Standards for Digital Assets: The Institutional Stack from Legal Rights to Ledger Finality. It is independent research by Zakaryae Boudi, Chair of the Intelligence Economy Institute, and does not constitute legal, regulatory, investment, accounting, tax or technical assurance advice.