India's tokenised corporate bond pilot has already reached ₹1,025 crore across three issuers, while the market it aims to serve is described in public coverage as roughly $620 billion. That contrast defines the engineering challenge. Demat 2.0 has demonstrated that regulated digital bond issuance and wholesale digital-rupee settlement can work, but banks still need to build the integration fabric for custody, investor records, APIs, reconciliation, servicing, and eventual secondary trading. Public reporting on the pilot captures the scale gap clearly.
This guide is for banks, brokers, depositories, custodians, fintechs, issuers, and institutional investors evaluating Tokenized Corporate Bond Infrastructure and Demat 2.0 Integration in India. The practical conclusion is straightforward: reuse the regulated securities stack wherever possible, add a permissioned DLT and CBDC settlement layer where the pilot requires it, and treat interoperability and operational controls as the primary delivery risk.
Table of Contents
- Why Tokenised Corporate Bonds Matter for India's Capital Markets
- What Demat 2.0 Really Changes for Bond Infrastructure
- The Tokenised Bond Lifecycle From Issuance to Settlement
- Core Infrastructure Components Banks Must Build or Integrate
- APIs, Reconciliation, and Audit Trails for Institutional Use
- Building Demat 2.0-Ready Infrastructure Step by Step
- Frequently Asked Questions on Tokenised Bonds and Demat 2.0
- What is Demat 2.0 in India?
- How do tokenised corporate bonds settle?
- Are tokenised bonds legally different from dematerialised bonds?
- Who can issue tokenised corporate bonds?
- Do investors need new KYC?
- What systems must a bank integrate?
- Can tokenised bonds trade in the secondary market?
- What are the main security requirements?
- What drives tokenised bond platform development cost?
- How should an institution approach implementation?
Why Tokenised Corporate Bonds Matter for India's Capital Markets
India doesn't need a new national ownership system for digital bonds. It already has an established dematerialised securities layer that can support account linkage, custody, investor identification, and transfer records. NSDL reported 4.51 crore demat accounts as of May 2026, supported by 315 depository participants, 57,065 service centres, and coverage across 99.38% of India's PIN codes. By late August 2026, NSDL reported custody of 6,29,973 crore securities valued at ₹552.70 lakh crore, with its footprint reaching 99.40% of PIN codes. These figures are reported in market coverage of NSDL's account expansion.
The corporate bond market provides a credible asset class for extending that infrastructure. NITI Aayog's 2026 report records net outstanding corporate bonds rising from ₹17.5 trillion in FY 2014-15 to around ₹53.6 trillion in FY 2024-25, with fresh issuance reaching ₹9.9 trillion in 2024-25. The same report is available through NSDL's industry report and CRISIL consent document. Tokenisation becomes commercially relevant when the underlying market has recurring issuance, institutional demand, and a substantial outstanding stock.
| Metric | Current scale | Relevance to tokenisation |
|---|---|---|
| NSDL demat accounts | 4.51 crore as of May 2026 | Provides an established account and custody foundation |
| NSDL PIN-code coverage | 99.38% in May 2026, 99.40% by late August 2026 | Supports broad digital securities access |
| Corporate bonds outstanding | Around ₹53.6 trillion in FY 2024-25 | Creates a sizeable addressable market |
| Fresh corporate bond issuance | ₹9.9 trillion in 2024-25 | Creates repeatable issuance workflows |
The right posture is extension, not replacement. A bank should preserve existing customer onboarding, custody, tax, reporting, and legal-title workflows unless the regulator or depository requires a specific change. The DLT layer should solve targeted problems, including atomic delivery-versus-payment, programmable servicing, and cleaner event histories, rather than forcing every downstream system to become blockchain-native.
For a practical view of how blockchain can support the bond lifecycle, see this guide to tokenised bonds and corporate bond lifecycle management. The useful design question isn't whether a bond can be represented as a token. It's whether the token can move through the institution's existing control environment without creating a second, ungoverned market.
What Demat 2.0 Really Changes for Bond Infrastructure
Demat 2.0 is a regulated digital securities architecture that represents corporate bonds as tokens on permissioned DLT maintained by statutory depositories, while the cash leg settles through the RBI's wholesale digital rupee. SEBI's pilot changes how issuance, holding, trading, and settlement can be coordinated without changing investors' legal rights or replacing the regulatory framework. A detailed overview of the SEBI pilot explains the DLT and wholesale CBDC structure. For the regulatory context, see this overview of the SEBI and RBI Demat 2.0 tokenised corporate bond pilot.
The infrastructure has four working parts.
Permissioned DLT maintained by depositories. The ledger is access-controlled and governed inside regulated market infrastructure. It is not an open crypto network. Banks should build integrations for approved identities, permissions, and transfer rules, not anonymous wallets or unrestricted token movement.
Existing depository rails. Investor access still relies on regulated account relationships, depository participation, custody, and market permissions. The token adds a digital representation and transaction workflow. It does not remove responsibilities for ownership records, investor servicing, or regulatory reporting.
Wholesale CBDC settlement. The cash leg uses the RBI's wholesale digital rupee through the Unified Market Interface. The material change is atomic delivery-versus-payment, linking bond and cash movements instead of processing them as separate legs.
Reuse of regulated onboarding. Map participants to established demat and KYC relationships wherever the implementation allows. A wallet or token account should not create duplicate onboarding by default. Each access path still requires documented permissions, suitability controls, and audit records.
Blockchain Development is therefore an integration discipline, not a standalone ledger project. Connect the DLT layer to depository controls, bank systems, custody records, and payment rails. Confirm legal title, ISIN mapping, settlement finality, tax treatment, and servicing with the relevant regulated entities. Software design alone cannot determine those obligations.
The Tokenised Bond Lifecycle From Issuance to Settlement
A tokenised corporate bond lifecycle begins with regulated issuer onboarding and ends with redemption or maturity servicing. The token is only one record in a larger workflow that includes disclosures, investor eligibility, allocation, cash settlement, custody, corporate actions, and reporting.
The core sequence is:
- Issuer onboarding and KYC. The issuer, intermediaries, and participating investors are configured within the approved market process.
- Allocation and DLT issuance. The bond is represented as a digital token on the permissioned ledger after issuance conditions are satisfied.
- CBDC settlement. The investor's wholesale digital-rupee wallet and the bond token exchange through atomic delivery-versus-payment.
- Secondary transfer. When approved secondary-market functionality is available, ownership transfers follow permissioned rules and the relevant depository processes.
- Coupon payment. A servicing engine or smart contract can calculate eligible holders and trigger payment instructions, subject to approved operating rules.
- Redemption. Principal repayment is matched to the final ownership record, after which the token can be retired or marked as redeemed.
- On-chain and off-chain control. The ledger records token state and transfers, while tax, disclosures, accounting, exception handling, and supervisory reporting may remain connected to existing systems.
The difficult seams sit between systems. An issuer's treasury or debt-management system must communicate with the depository's issuance workflow. The DLT node must reflect the approved token state. The CBDC integration must confirm cash finality. The custodian's books must reconcile holdings and cash. A webhook failure at any point can leave operations with an incomplete transaction state, even if the ledger itself is functioning.
A design therefore uses explicit transaction states such as initiated, authorised, cash pending, securities pending, settled, failed, reversed, and manually resolved. Each state needs an owner, timeout rule, retry policy, and evidence record. The Demat 2.0 secondary-market discussion is especially relevant because issuance is only the opening event. A production system must service the instrument throughout its life.
Core Infrastructure Components Banks Must Build or Integrate
Banks should not build every component from scratch. They should own the control model, integration contracts, security architecture, and exception process. Regulated rails and proven enterprise systems should remain in use where they provide authoritative records.
The five layers that determine production readiness
Permissioned DLT nodes connect the bank to the ledger and its transaction flow. The design requires node governance, redundancy, protected key storage, controlled upgrades, monitoring, and recovery procedures. Decide whether the bank operates its own node, uses a managed service, or connects through depository-operated infrastructure.
Smart contracts encode issuance rules, investor allowlists, transfer restrictions, coupon events, redemption logic, and failure states. They must match the bond's legal and operating terms. ERC-3643 may inform permissioned-transfer design, but the selected model must match the depository's approved ledger and operating rules.
Depository API gateways connect issuer systems, registrar functions, custody platforms, and investor records. Require idempotent requests, signed messages, versioned schemas, event callbacks, and a defined master record. If the DLT records success while custody fails, the transaction must enter a visible exception queue.
Wholesale CBDC connectivity manages wallet enablement, payment authorisation, cash confirmation, and atomic settlement coordination. Treasury controls, wallet permissions, operating-framework transaction limits, and procedures for failed or timed-out settlement belong in this layer.
KYC and AML services should reuse authoritative customer records where permitted, then apply token-specific eligibility and transfer controls. Separate identity verification from transaction authorisation. Preserve evidence for screening, approvals, and investigations.
| Layer | Function | Integration owner |
|---|---|---|
| Permissioned DLT | Token records, transfer state, ledger events | Digital assets and infrastructure |
| Smart contracts | Bond rules and lifecycle automation | Legal, product, and engineering |
| Depository APIs | Issuance, holdings, servicing, and transfer messages | Securities operations |
| Wholesale CBDC | Cash leg and atomic DvP coordination | Treasury and payments |
| KYC and AML | Identity, eligibility, screening, and controls | Compliance and onboarding |
Production readiness depends on deterministic behaviour, controlled access, recoverability, and evidence. Define service levels for ledger availability, API acknowledgement, settlement confirmation, reconciliation completion, and manual resolution. Do not promise “real-time” processing until every dependent system supports the same operating window.
The bank should map custody, banking, compliance, and reporting dependencies before selecting an integration pattern. Teams can connect your tech stack across those layers, but the bank must still assign ownership for each authoritative record and exception path.
For platform features, cost, and technology choices, review this corporate bond tokenization platform development guide. The corporate bond tokenization platform overview covers digital bond issuance, smart-contract automation, settlement, and investor management. These functions support implementation. They do not replace SEBI or RBI approval.
APIs, Reconciliation, and Audit Trails for Institutional Use
Tokenisation fails in production when institutions treat APIs as simple plumbing. The API layer is the operating contract between the issuer, depository, custodian, broker, bank, settlement venue, and reporting functions. It must define not only how data moves, but which system is authoritative for each event.
A workable integration fabric separates command APIs from event APIs. A command might request issuance, allocation, transfer, coupon processing, or redemption. An event confirms that the request was accepted, completed, rejected, or placed into exception handling. Webhooks should be signed, replayable, and linked to a transaction identifier that remains consistent across the issuer, DLT, CBDC, custody, and reporting systems.
Build a canonical transaction record
Every transaction should carry a shared identity across systems. Useful fields include the issuer reference, instrument identifier, investor or custody reference, instruction type, token quantity, cash amount, approval state, wallet reference, timestamps, and settlement outcome. The record should also capture the reason for rejection or manual intervention.
ISO 20022 mapping can help institutions represent the cash and securities legs consistently, but mapping alone won't solve reconciliation. The bank must decide how a DLT event maps to the securities master, how a CBDC confirmation maps to treasury entries, and how corrections are recorded without overwriting the original evidence.
A reconciliation engine should compare at least three states:
- DLT state, including token ownership, transfer status, and contract events.
- Depository or custody state, including holdings, investor mapping, and servicing eligibility.
- CBDC and core-banking state, including wallet activity, cash confirmation, and accounting entries.
Matching should run continuously for critical settlement events and on a defined operational cycle for holdings, coupons, and redemptions. Exceptions need severity levels. A cash-confirmed but token-unsettled event is different from a duplicated webhook, and both require separate runbooks.
Treat audit data as a product requirement
An immutable ledger event isn't a complete audit trail. Supervisors and internal auditors also need authorisation records, API payload hashes, user and service identity, key-use evidence, approval timestamps, manual overrides, and the final accounting outcome. Off-chain documents can be hash-anchored to prove integrity while remaining in controlled document repositories.
Practical rule: A regulator should be able to reconstruct the transaction without asking an engineer to query several unrelated systems.
A regulator-readable event store should support filters by instrument, issuer, investor, transaction, wallet, operator, and exception type. Access must be role-based, with separate permissions for operations, compliance, treasury, engineering, and external review. Retention and export rules should be agreed with the institution's legal and compliance teams.
The pilot proves a settlement pattern, not a complete market. SEBI's 2026 market review records total funds mobilised through debt issuances declining 8.4% year-on-year to ₹9,11,078 crore in 2025-26, even as corporate-bond activity has trended upward since 2021-22. The review identifies faster settlement, operational efficiency, programmability, and CBDC settlement as benefits being tested. SEBI market-review coverage provides context for that pilot architecture.
The scale gap remains material. The pilot's ₹1,025 crore in inaugural issues demonstrates live issuance, but it doesn't establish liquidity, secondary-market depth, servicing resilience, or routine refinancing for a market described as roughly $620 billion in coverage. The unresolved work includes dealer incentives, repo treatment, interoperability across permissioned networks, corporate tax handling, coupon and redemption servicing, default events, and migration between tokenised and conventional records.
For institutions designing post-trade controls, DLT post-trade processing, settlement, and reconciliation offers a useful reference point. The important architectural principle is to maintain one canonical operational view, even when several regulated ledgers and systems participate in the transaction.
Building Demat 2.0-Ready Infrastructure Step by Step
A bank should not begin with a token contract. It should begin with a control and dependency map. The first question is which existing system owns each record, and the second is how that record will be verified when the token ledger, custody platform, and CBDC rail report different states.
Start with discovery, not vendor selection
Map the issuer's treasury platform, registrar and transfer-agent processes, depository connections, custody books, KYC sources, treasury wallets, payment systems, accounting, risk, tax, and regulatory reporting. Record every hand-off and manual control. The output should be a system context diagram, data dictionary, RACI matrix, and exception inventory.
Next, define the target architecture. Decide whether DLT nodes are hosted on premises, in a controlled cloud environment, or through an approved service model. Set the key-management approach, disaster-recovery model, network segmentation, observability standards, and interface ownership before writing production smart contracts.
Run a contained integration pilot
A controlled pilot should test more than minting. It should include issuer onboarding, investor eligibility, allocation, atomic settlement, custody posting, failed transactions, reconciliation, coupon processing, reporting, and controlled redemption. Use test cases that deliberately create mismatched states, delayed callbacks, duplicate messages, unavailable nodes, and wallet failures.
The evidence pack should include:
- Architecture records: Data flows, trust boundaries, permissions, and integration contracts.
- Operational runbooks: Settlement failure, key compromise, node outage, rejected investor, and manual repair procedures.
- Control evidence: KYC decisions, smart-contract approvals, API signatures, and access logs.
- Reconciliation reports: Comparisons between DLT, depository, custody, CBDC, and accounting records.
- Security results: Threat models, code reviews, penetration testing, key-management tests, and recovery exercises.
Scale by business capability
Roll out issuance first only if servicing is already designed. Add custody and reporting before expanding participant access. Introduce secondary trading only after order, transfer, settlement, market surveillance, and exception workflows are operationally owned.
The production question isn't “Can the token be issued?” It's “Can the institution explain, service, reconcile, and recover every token position throughout its life?”
Blocsys Technologies can be evaluated as a technology and integration partner for DLT node deployment, smart-contract development, depository and CBDC connectivity, KYC and AML reuse, reconciliation engines, settlement APIs, wallet rails, and audit-trail design. The engagement should be structured around discovery, pilot integration, security hardening, and rollout. Blocsys cannot provide SEBI or RBI approval, legal advice, or regulatory authorisation, so those responsibilities must remain with the institution and its regulated partners.
The appropriate partner evaluation criteria are practical: experience with permissioned ledgers, secure API design, financial-grade key management, custody integration, test automation, observability, and the ability to work with internal compliance and operations teams. A vendor that delivers only the token contract leaves the highest-risk systems untouched.
Frequently Asked Questions on Tokenised Bonds and Demat 2.0
What is Demat 2.0 in India?
Demat 2.0 is a regulated infrastructure model in which corporate bonds are represented as digital tokens on a permissioned distributed ledger maintained by statutory depositories, with settlement connected to the RBI's wholesale digital rupee. It extends existing securities infrastructure rather than turning corporate bonds into unrestricted crypto assets.
How do tokenised corporate bonds settle?
The securities leg is represented by the bond token and the cash leg is handled through wholesale CBDC rails connected through the Unified Market Interface. The intended outcome is atomic delivery-versus-payment, where the bond and cash movements are coordinated as one settlement event.
Are tokenised bonds legally different from dematerialised bonds?
The pilot is intended to modernise issuance, holding, trading, and settlement without changing investors' legal rights or the existing regulatory framework. Institutions must still confirm the applicable legal, disclosure, listing, tax, custody, and servicing requirements with SEBI, RBI, depositories, and their professional advisers.
Who can issue tokenised corporate bonds?
The pilot has been tested by three issuers, including REC, L&T, and IIFL, with a combined ₹1,025 crore raised, as reported in coverage of the first phase. Future issuer eligibility depends on the approved market framework, depository processes, and regulatory permissions.
Do investors need new KYC?
Existing demat and regulated market relationships are intended to support access, but participants may also need approved wallet enablement and specific permissions for the tokenised workflow. Institutions should design KYC reuse carefully, ensuring that identity records, eligibility rules, wallet access, and transaction screening remain connected.
What systems must a bank integrate?
The minimum architecture includes depository and custody systems, a permissioned DLT connection, smart contracts, wholesale CBDC wallet and settlement services, KYC and AML systems, treasury, accounting, reconciliation, reporting, and audit platforms. The bank should define one authoritative record for every material state.
Can tokenised bonds trade in the secondary market?
The pilot has established a primary-issuance and settlement model, while broader trading and retail access remain later-stage objectives described in public coverage. Secondary-market readiness requires order handling, permissioned transfers, dealer participation, pricing, surveillance, liquidity, servicing, and reconciliation.
What are the main security requirements?
Institutions need secure key management, role-based access, node and API protection, smart-contract review, transaction signing, network segmentation, monitoring, incident response, and tested recovery procedures. They also need immutable event evidence that links ledger activity to approvals, custody records, cash movements, and accounting outcomes.
What drives tokenised bond platform development cost?
The major cost drivers are integration scope, DLT governance, smart-contract complexity, custody and depository connectivity, CBDC wallet workflows, KYC and AML reuse, reconciliation, security testing, reporting, operational resilience, and the number of participant roles. A scoped estimate should follow architecture discovery, not precede it. Institutions can use the Software Development Cost Estimator as an initial planning aid.
How should an institution approach implementation?
Start with system discovery and control mapping, then design the target architecture, build API and reconciliation contracts, run a contained issuance and settlement pilot, test failure scenarios, and roll out by capability. Production approval depends on the institution's regulated governance, partner readiness, security evidence, and operational ownership, not on tokenisation software alone.
Blocsys Technologies develops customised blockchain, tokenisation, smart-contract, API, settlement, custody, and digital-securities infrastructure for institutions evaluating Demat 2.0 integration. Discuss your issuer, depository, CBDC, investor-record, reconciliation, and production-rollout requirements with the team through Blocsys Technologies.
