Before You Onboard: Five Decisions to Make Before Participating in Tokenized Markets

Tokenization is moving from exploration to implementation. For firms preparing to onboard to a tokenization service, including the DTCC Tokenization Service, the hardest questions are not so much about the technology, but more about operating models: what the firm wants to achieve, what problem the firm is solving, who is accountable, how operations and controls will change and how new connections will be integrated with existing systems.

This article outlines five decisions to work through before onboarding. Readiness will vary by organization, but settling them early helps align stakeholders and surface gaps.

1- Decide What You Are Trying to Achieve

Start with a business need, not a technology choice. A focused use case gives legal, risk, operations and technology teams a shared basis for judging value, feasibility and investment, and it shapes decisions that follow.

What to consider:

• The specific challenge to address, such as improving collateral mobility, reducing operational friction or connecting traditional and digital infrastructure
• The assets, counterparties and stakeholders in scope, and how success will be measured
• The capabilities, providers and market connections the use case requires

2- Decide How Governance, Ownership and Compliance Will Work

Depending on the structure, tokenization may change how an asset is represented and transferred. It does not change the need for legal certainty, clear ownership records or regulatory compliance. Firms should be able to explain what the token represents, who holds enforceable rights and how obligations apply across the asset lifecycle.

What to consider:

• Decision rights and accountability across business, legal, compliance, risk, operations and technology
• How anti-money laundering (AML), know-your-customer (KYC) and sanctions controls extend to tokenized activity, from counterparty due diligence and wallet onboarding to monitoring and escalation
• How eligibility requirements, agreements, entitlements and third-party arrangements will be managed as one coordinated model

3- Decide How Operations and Custody Will Run

Every stage of an asset’s lifecycle, from issuance and settlement to custody, servicing, corporate actions and reconciliation, still needs a defined process and a named owner when activity spans traditional and blockchain-based systems.

What to consider:

• The end-to-end journey from setup to ongoing support, including who owns user access, reconciliation, escalation and day-to-day operations
• The wallet and custody model: whether wallets are managed internally or through a provider, and who is responsible for keys, access, approvals, monitoring and recovery

4- Decide What Must Be Proven Before Production

Moving from pilot to production calls for the same institutional rigor applied in traditional markets, adapted for blockchain networks, wallets and smart contracts.

What to consider:

• Where existing controls must be extended, including cybersecurity and operational resilience, key management, transaction authorization, financial crime compliance, third-party risk, liquidity and recovery
• What testing must cover for the use case: connectivity, permissions, end-to-end workflows, reconciliation and recovery
• What evidence supports a go-live decision, and how teams will be trained before activation

5- Decide How Technology Will Connect, Interoperate and Evolve

The business need and operating model should guide technology choices, including which networks and connectivity models are appropriate for the use case. Networks, wallets, identity, data, applications and existing systems must work together within a secure and resilient architecture. Simply connecting to a blockchain is not the objective. The real goal is an architecture that spans existing infrastructure, counterparties and, eventually, multiple networks

What to consider:

• Which network or networks fit the use case, counterparties and providers
• How secure access, credentials and permissions will work and how tokenized activity will integrate with existing systems
• Critical dependencies across internal systems and third-party providers

These connection choices should support not only the initial use case but also how the firm will work with counterparties, providers and market infrastructure over time. That requires interoperability, the ability of different systems and networks to work together built into the design from the outset, without creating new silos or weakening controls.

From Decisions to Onboarding

These decisions are interdependent. The use case shapes governance, governance shapes the operating model and the operating model determines what must be tested and which technology is needed. Working through them together helps firms identify gaps, assign accountability and decide where, when and how to participate in tokenized markets.

Firms should also confirm the eligibility, onboarding and testing requirements of any service they plan to join. For the DTCC Tokenization Service, the FAQs in the Tokenization Hub on DTCC.com explain who can participate, how the service works and how governance, risk and compliance controls may apply.

This article is not a substitute for detailed legal, regulatory, technical or implementation guidance.