Insights
The Bond Was Already Digital: What India’s First Tokenised Bond Actually Changes
REC’s ₹500 crore issuance under India’s regulatory sandbox is the country’s first tokenised corporate bond, but the underlying bond market was already dematerialised. The important change is therefore not that a paper bond became digital. Demat 2.0 moves the securities record onto distributed-ledger infrastructure while the RBI’s wholesale CBDC provides a digital cash leg, allowing atomic delivery-versus-payment and same-day pay-in, allotment and listing. The experiment exposes a broader...
This starts a temporary private draft. It is not public, listed for sale or shared automatically.
The first question in a tokenised-bond story is usually:
What was tokenised?
India’s first live corporate-bond pilot makes a more interesting question possible:
What actually changes when the bond was already digital before the token arrived?
On 7 September 2026, state-owned infrastructure financier REC Limited raised ₹500 crore through India’s first pilot issuance of tokenised corporate bonds under the Securities and Exchange Board of India’s Regulatory Sandbox Framework.
The transaction had:
- a ₹100 crore base issue;
- a ₹400 crore greenshoe option;
- ₹796 crore of bids;
- a 7.30% annual coupon; and
- a tenor of one year and nine months.
Bidding took place through the National Stock Exchange’s electronic bond platform.
The tokenised securities were then represented through Demat 2.0, a distributed-ledger securities infrastructure developed by India’s depositories, while the payment leg used the Reserve Bank of India’s wholesale central bank digital currency.
Public reporting says the architecture enabled atomic delivery-versus-payment, and that pay-in, allotment and listing were completed on the same day.
Financial Express: REC raises Rs 500 crore via tokenised bonds
Business Standard: India’s first tokenised bond — what changes when debt moves to blockchain
Financial Express: What tokenised bonds mean for India’s debt market
The headline is:
India’s first tokenised corporate bond
The deeper infrastructure story is:
An existing digital securities market
->
adds a distributed ownership / settlement layer
->
and connects it to digital central-bank money
That is much more useful for DaDepo.
The bond was already dematerialised
Tokenisation is sometimes explained as:
Paper certificate
->
Digital token
That is not the relevant transformation here.
Indian corporate bonds already exist in dematerialised form.
An investor can already hold an electronic securities position.
The bond already has:
- an issuer;
- issue documents;
- principal;
- coupon;
- maturity;
- investor rights;
- an instrument identifier;
- a depository environment;
- exchange listing where applicable;
- record dates;
- corporate actions; and
- electronic ownership records.
REC did not need blockchain to make the bond stop being paper.
The bond was already digital.
The tokenisation pilot changes how the ownership position and settlement process are represented and synchronised.
That distinction matters.
Digital is not the same thing as tokenised
A useful progression is:
Paper security
->
Dematerialised security
->
DLT-represented security
The second step already removes the physical certificate.
The third step changes infrastructure.
This means a tokenised bond should not be treated as a completely new asset simply because it uses DLT.
The first question remains:
What bond is this?
Only then:
How is the holding represented?
The legal bond terms do not disappear
The basic rules of the bond remain.
REC still owes principal and coupon according to the issue terms.
The investor still has conventional bond risks.
The issuer can still default.
Market yields can still change.
Liquidity can still be weak.
A token does not replace:
- credit risk;
- interest-rate risk;
- liquidity risk;
- legal documentation;
- issuer obligations;
- record dates;
- corporate actions; or
- investor rights.
The infrastructure changes.
The underlying obligation remains a corporate bond.
Instrument identity must survive the new representation
Suppose the conventional security record says:
Issuer: REC Limited
Coupon: 7.30%
Maturity: defined maturity date
Identifier: authoritative instrument identifier
The DLT record must refer to that same instrument.
The token layer should not create ambiguity such as:
Traditional system:
REC 7.30% Bond A
DLT system:
REC Token 7.30% Bond X
without a durable mapping between them.
A digital-security architecture needs:
Legal instrument
<->
Instrument identifier
<->
Depository record
<->
DLT representation
If that relationship breaks, the market has created two descriptions of one economic asset without a reliable bridge.
The token should represent the bond—not reinvent it
A tokenised security can be understood as a digital representation of rights arising from the underlying issuance framework.
It should not require the investor to guess whether:
the bond
and:
the token
are two different assets.
A robust record should answer:
- what legal instrument the token represents;
- which issue documents govern it;
- which identifier anchors it;
- which ledger records the digital position;
- how the position relates to the depository record;
- who can create or extinguish the representation;
- what happens if records conflict; and
- which system is authoritative for each purpose.
Those are infrastructure questions.
Demat 2.0 changes the ownership-record layer
Reuters reported before the issuance that India’s depositories were developing DEMAT 2.0 to record tokenised bond holdings on distributed-ledger infrastructure.
The completed REC pilot gives that architecture a live corporate bond.
Reuters: India plans first tokenised bond issue in September
The design is significant because India already has mature dematerialised securities infrastructure.
The experiment is not asking:
Can India maintain electronic bond holdings?
It already can.
It is asking:
Can a distributed ledger improve the way those holdings move and settle?
A securities wallet is not the bond itself
The investor needs a securities wallet capable of holding the tokenised position.
That wallet is an access and control mechanism.
The bond is the underlying security.
The relationship is better represented as:
Investor
->
Authorised account / wallet
->
Digital holding
->
Underlying bond
not:
Wallet = bond
This distinction matters when:
- the investor changes wallet;
- custody arrangements change;
- access credentials are replaced;
- an institutional participant changes technical provider;
- the security moves to another eligible participant; or
- the ledger is migrated.
The asset identity must survive account-infrastructure changes.
Private keys are control tools, not complete ownership analysis
DLT systems can make control look simple.
A participant possesses the credential needed to authorise a transfer.
That matters operationally.
It does not answer every legal question about ownership.
Institutional securities markets also care about:
- account holder;
- beneficial owner;
- custodian;
- pledgee;
- trustee;
- nominee;
- regulatory restrictions;
- court orders;
- insolvency;
- sanctions;
- settlement finality; and
- the legal effect of the relevant book entry.
Therefore:
Can sign transaction
is not automatically identical to:
Legally owns security
The relationship must be defined by the market framework.
Depositories remain central to the experiment
Tokenisation was once frequently presented as a way to remove market intermediaries.
India’s pilot does something more institutional.
The depositories themselves are involved in the architecture.
Reuters identified NSDL and CDSL as participants in developing the Demat 2.0 securities infrastructure.
That suggests a more realistic model:
Existing regulated infrastructure
+
DLT
rather than:
DLT
replaces
regulated infrastructure
For serious financial markets, that distinction matters.
Tokenisation becomes market infrastructure when the record is governed
A token can be created by almost anyone.
An institutional securities record cannot.
The market needs rules for:
- issuance;
- participant eligibility;
- account opening;
- identity;
- token creation;
- transfer;
- cancellation;
- correction;
- settlement;
- corporate actions;
- recovery from technical failure;
- dispute;
- data retention;
- regulatory access; and
- legal finality.
The value of Demat 2.0 is therefore not simply that it uses distributed ledger technology.
It is that DLT is being tested inside a regulated securities framework.
The cash leg is another asset
A securities transaction has at least two sides.
For the REC pilot:
Bond
and:
RBI wholesale CBDC
are different assets.
The securities side represents the corporate bond.
The cash side represents central-bank money in digital wholesale form.
The settlement transaction connects them.
The system therefore needs separate identities and states for both.
Wholesale CBDC matters because settlement money matters
Tokenised securities can settle against traditional bank money.
But that can leave the cash leg outside the same digital workflow.
India’s pilot uses the RBI’s wholesale CBDC.
The architecture therefore has:
Digital security leg
+
Digital central-bank-money leg
This allows the two transfers to be coordinated more tightly.
That is the foundation for atomic DvP.
Atomic DvP is a state transition across two assets
A simplified state before settlement is:
Investor has cash
Issuer / seller has security
After settlement:
Investor has security
Issuer / seller has cash
Atomic settlement attempts to make the transition indivisible:
Security moves
IF AND ONLY IF
cash moves
The important concept is not blockchain itself.
It is synchronised state.
The bond and the cash still need separate records
Atomicity should not collapse the two legs.
The platform still needs to know:
Security
- instrument;
- quantity;
- seller;
- buyer;
- account; and
- settlement status.
Cash
- amount;
- currency;
- payer;
- payee;
- CBDC wallet; and
- payment status.
Link
- trade or allotment identifier;
- DvP condition;
- settlement timestamp; and
- finality state.
A single transaction hash is useful evidence.
It should not replace the underlying asset definitions.
Same-day issuance is operationally significant
The REC pilot completed:
- pay-in;
- allotment; and
- listing
on the same day.
Traditional issuance has multiple operational hand-offs:
Bidding
->
Allocation
->
Payment
->
Securities creation
->
Account credit
->
Reconciliation
->
Listing
Each hand-off can introduce delay.
A synchronised digital workflow can compress that sequence.
The result is not merely a faster token transfer.
It is a shorter issuance lifecycle.
Faster settlement moves readiness upstream
If settlement happens later, participants have more time to correct:
- wrong account details;
- insufficient cash;
- investor eligibility issues;
- allocation errors;
- instrument mismatches;
- failed instructions; and
- reconciliation breaks.
If settlement is compressed, those problems need to be resolved earlier.
The faster the settlement layer becomes, the less tolerance there is for ambiguous instrument identity.
Settlement speed and settlement finality are different
A technical transaction can complete in seconds.
Legal finality is a separate concept.
A ledger can show:
Transfer complete
The market still needs a framework defining:
- when the transfer becomes irrevocable;
- which ledger entry has legal effect;
- whether reversal is possible;
- how errors are corrected;
- how insolvency affects unsettled instructions;
- whether a court can freeze the asset;
- how failed transactions are treated; and
- which system prevails if records conflict.
Therefore:
Fast
does not automatically mean:
Final
DaDepo should never infer settlement finality from transaction speed alone.
The authoritative record matters more when there are several digital records
Before tokenisation, a dematerialised securities workflow can already contain:
- issuer records;
- depository records;
- exchange records;
- custodian records;
- broker records;
- investor statements; and
- internal accounting.
DLT can add another record.
That is useful only if it reduces ambiguity.
The system must answer:
Which record is authoritative for which fact?
For example:
Bond legal terms
-> issue documents
Instrument identity
-> security master / depository framework
Current DLT position
-> Demat 2.0 ledger
Cash movement
-> wholesale CBDC infrastructure
Exchange listing
-> exchange records
Corporate action
-> issuer / registrar / depository process
One ledger does not need to become authoritative for everything.
A source of truth can be federated
Financial-market infrastructure frequently has several authoritative systems.
The goal is not necessarily:
One database controls all facts
The better model can be:
Each fact has an authoritative source
+
all sources refer to the same asset identity
That is especially relevant to DaDepo.
An Asset Passport can connect authoritative records without pretending to replace them.
Corporate actions survive tokenisation
The bond pays coupon.
The bond matures.
Those events still need processing.
Tokenisation does not remove:
- interest calculations;
- record dates;
- payment entitlement;
- maturity processing;
- issuer notices;
- default notices;
- restructuring;
- call or put events if applicable; or
- amendments.
A serious digital security needs the same lifecycle awareness as a conventional bond.
Coupon payment tests the asset mapping again
At a coupon record date, the system must identify:
Which investors are entitled?
If the DLT ledger says:
Investor A: 100 units
but another authoritative record says:
Investor A: 80 units
the corporate-action process has a problem.
The value of tokenisation depends on consistency of the ownership record.
Maturity is another lifecycle state
At maturity:
Outstanding bond
becomes:
Redeemed bond
The investor receives principal.
The securities position must move into the correct terminal state.
The system should preserve:
Issued
->
Outstanding
->
Transferred
->
Coupon events
->
Maturing
->
Redeemed
->
Closed
Tokenisation should make this lifecycle easier to observe.
It should not reduce the asset to a permanent token that still appears active after legal maturity.
Burn or cancellation must match the legal event
A token may be technically burned.
That does not automatically prove the bond was legally redeemed.
Likewise, a bond can be legally redeemed while a technical representation remains incorrectly active.
The system needs both:
Legal redemption event
and:
Digital representation extinguished
with reconciliation between them.
Secondary trading is the next harder test
The primary issuance proves that:
issue
+
cash
+
allotment
+
listing
can be connected through the new infrastructure.
Secondary trading introduces more complexity.
Reuters reported before launch that the pilot would include an initial three-month lock-in, while Financial Express reports that secondary trading remains pending during that initial period.
That means the primary issuance is only the first stage.
Secondary transfer will test:
- buyer eligibility;
- seller holdings;
- pricing;
- order matching;
- wallet compatibility;
- cash availability;
- DvP;
- settlement finality;
- record dates;
- restrictions; and
- interoperability.
Liquidity is not created by tokenisation alone
The REC issue was strongly subscribed.
Bids totalled ₹796 crore.
That demonstrates investor interest in this issuance.
It does not prove that every tokenised bond will be liquid in the secondary market.
Liquidity still depends on:
- issuer credit;
- market demand;
- pricing;
- investor participation;
- market-making;
- transfer restrictions;
- wallet access;
- settlement infrastructure;
- issue size;
- regulation; and
- market conventions.
A token can reduce settlement friction.
It cannot manufacture buyers.
Wallet compatibility can itself become a liquidity constraint
Reuters reported that participants need both:
- a compatible wholesale CBDC wallet; and
- compatible Demat 2.0 securities infrastructure.
A willing investor may still be unable to participate if it lacks the required technical and regulatory access.
The market therefore needs to distinguish:
Investor wants bond
from:
Investor is technically and legally eligible to receive tokenised bond
This is another asset-state relationship.
The same instrument can have several identifiers
A security market needs durable identifiers.
If the tokenised representation has another digital identifier, the system should not force users to choose between:
official instrument identifier
and:
token / ledger ID
They answer different questions.
A useful model is:
Instrument
->
Official / market identifier
->
Digital representation identifier
The digital ID identifies the representation.
The instrument identifier anchors the legal security.
One instrument can have several technical representations
Future infrastructure may allow one security to appear through:
- conventional demat;
- a DLT environment;
- a custodian representation;
- a collateral representation; or
- another regulated settlement rail.
That does not necessarily mean several bonds exist.
The system may instead contain:
One legal instrument
->
Representation A
->
Representation B
->
Representation C
where permitted by the market framework.
The asset model needs to support that possibility.
Representation state needs reconciliation
For each representation, the system may need:
- representation type;
- network;
- wallet or account;
- quantity;
- creation event;
- mapping rule;
- current status;
- authoritative source;
- reconciliation timestamp; and
- extinguishment event.
This is especially important if assets can later move between infrastructure layers.
Tokenisation does not remove custody questions
Institutional securities still need robust arrangements around:
- custodians;
- depositories;
- account providers;
- key-management services;
- segregation;
- recovery processes;
- authorised signatories;
- operational controls;
- sanctions controls; and
- succession arrangements.
Possession of a cryptographic key is not a sufficient institutional custody model by itself.
Corrections still need governance
Distributed ledgers are often described as immutable.
Financial markets make mistakes.
An allocation can be wrong.
A participant can enter the wrong account.
A transaction can fail.
A court can issue an order.
A corporate action can be corrected.
The market therefore needs controlled correction procedures.
A serious ledger must distinguish:
History cannot be secretly overwritten
from:
Errors can never be corrected
The first is useful.
The second would be operationally dangerous.
Immutability should preserve corrections, not prevent them
A good state history can show:
Original instruction
->
Error detected
->
Correction authorised
->
Reversal / replacement event
->
Current valid state
The prior event remains visible.
The current state becomes correct.
That is how an auditable Asset Passport should behave too.
The depository perspective is especially important
The most interesting participant in this story may not be the issuer or investor.
It may be the depository.
Depositories exist to make securities identity and holdings reliable across the market.
Tokenisation changes their technical tools.
It does not eliminate their core problem.
The depository still needs to answer:
What security?
How many units exist?
Who holds them?
Which account?
What changed?
When did it change?
Which event is final?
DLT can improve the machinery.
The need for trustworthy records remains.
A tokenised-security Asset Passport needs several layers
For DaDepo, the useful lesson is not to build a blockchain.
It is to model the relationships that tokenised infrastructure makes visible.
Legal instrument
- issuer;
- instrument type;
- issue date;
- face value;
- total issue size;
- currency;
- coupon;
- maturity;
- seniority;
- secured or unsecured state;
- governing documents;
- governing law;
- official identifier;
- exchange listing; and
- current legal status.
Instrument identity
- instrument identifier;
- issuer identifier;
- issue or series;
- security-master source;
- depository source;
- current version;
- amendments;
- superseded identifiers;
- corporate-action history; and
- reconciliation status.
Depository representation
- depository;
- account structure;
- issued quantity;
- outstanding quantity;
- current holder;
- position;
- record date;
- transfer state;
- freeze or restriction;
- pledge or encumbrance;
- source timestamp; and
- authoritative-record status.
Digital representation
- infrastructure;
- network;
- Demat 2.0 or equivalent representation;
- token or ledger identifier;
- representation type;
- creation authority;
- creation event;
- quantity represented;
- mapping relationship;
- wallet;
- current state;
- burn / cancellation process; and
- reconciliation status.
Investor position
- investor;
- account;
- wallet;
- participant identity;
- beneficial owner where relevant;
- quantity;
- acquisition date;
- transfer restrictions;
- pledge;
- freeze;
- current position; and
- as-of timestamp.
Cash leg
- settlement asset;
- currency;
- wholesale CBDC or other cash form;
- payer;
- payee;
- payer wallet;
- payee wallet;
- amount;
- instruction;
- payment state;
- timestamp;
- failure; and
- reversal or correction.
Settlement
- transaction identifier;
- securities instruction;
- cash instruction;
- DvP rule;
- settlement venue;
- matched state;
- pending state;
- atomic execution;
- settlement timestamp;
- finality source;
- failure;
- correction;
- reversal; and
- reconciliation.
Corporate actions
- coupon;
- record date;
- entitlement;
- payment date;
- issuer notice;
- redemption;
- maturity;
- amendment;
- default;
- restructuring; and
- completed-status evidence.
Participant eligibility
- investor class;
- regulatory eligibility;
- wallet eligibility;
- CBDC access;
- depository access;
- technical compatibility;
- transfer restriction;
- lock-in;
- effective date; and
- reviewer.
Provenance
- issue document;
- issuer source;
- exchange record;
- depository record;
- DLT transaction;
- wallet transaction;
- CBDC settlement record;
- corporate-action notice;
- regulator;
- AI-extracted field;
- user-confirmed field;
- professional review;
- effective date;
- version; and
- last updated timestamp.
This is a much richer model than:
Tokenised: Yes
“Tokenised” should never be one checkbox
A platform field that says:
Tokenised security: Yes
does not answer:
- what is represented;
- where it is represented;
- who controls the ledger;
- what the authoritative instrument is;
- whether the holding reconciles;
- how transfer occurs;
- how cash settles;
- what determines finality;
- how corporate actions work; or
- how the representation is extinguished.
Tokenisation is an architecture.
Not a status badge.
The ownership record needs provenance
Suppose an investor says:
I own ₹10 crore of REC bonds.
A serious system should be able to trace that statement to:
Investor identity
->
Account / wallet
->
Current ledger position
->
Instrument identity
->
Acquisition / allotment
->
Settlement event
If any link is missing, the ownership statement becomes harder to rely on.
DLT makes provenance easier to record—but not automatically correct
A distributed ledger can preserve a strong event history.
It can show:
- creation;
- transfer;
- timestamp;
- wallet;
- quantity; and
- transaction reference.
That is valuable.
But the ledger can still receive wrong input.
For example:
Wrong instrument mapped to token
or:
Wrong investor wallet
or:
Wrong quantity
Blockchain can preserve the mistake very reliably.
The value comes from combining event history with correct asset identity and governance.
AI can reconcile digital-security records—but should not declare ownership
Tokenised securities create highly structured data.
AI can help identify and reconcile:
- issuer names;
- instrument identifiers;
- coupon terms;
- maturity;
- issue size;
- ledger identifiers;
- wallet references;
- allotment records;
- depository positions;
- transaction references;
- CBDC payment references;
- settlement timestamps;
- corporate-action dates;
- listing records; and
- amendments.
Across a larger market, AI can also flag:
- a digital quantity inconsistent with the issued quantity;
- a wallet position inconsistent with a depository record;
- duplicate digital representations;
- a security mapped to the wrong identifier;
- a coupon record date using stale holdings;
- a redeemed bond still represented as active;
- a failed cash leg with a completed securities leg;
- inconsistent participant identities;
- a transfer during a lock-in period; or
- a wallet no longer linked to the authorised investor.
That is useful.
AI should not independently determine:
- that legal title transferred;
- which ledger is legally authoritative;
- that a DLT entry has settlement finality;
- that a token represents a valid security;
- that a security was validly issued;
- that investor eligibility requirements are satisfied;
- that a depository record can be disregarded;
- that a transaction can be reversed;
- that a wallet controller is the beneficial owner;
- that a digital corporate action is legally complete; or
- that a tokenised security is suitable for investment.
Those remain legal, regulatory and market-infrastructure determinations.
What DaDepo can contribute
DaDepo does not need to issue tokenised bonds.
It does not need to operate Demat 2.0.
It does not need to provide CBDC settlement.
The useful role is the asset-information layer.
A structured security record can connect:
Legal instrument
->
Instrument identity
->
Depository record
->
Digital representation
->
Investor position
->
Trade / allotment
->
Cash leg
->
Settlement
->
Corporate actions
That makes it easier for an authorised reviewer to understand:
- what the security actually is;
- which terms define it;
- which identifier anchors it;
- how the digital representation maps to the instrument;
- where ownership or holdings are authoritatively recorded;
- which account or wallet contains the position;
- what transaction moved it;
- how the cash leg settled;
- which source establishes settlement state;
- whether a lock-in or other restriction applies;
- how coupon and maturity events are processed; and
- whether every digital record still reconciles to the underlying instrument.
Tokenisation does not make the Asset Passport less useful.
It makes the relationship map more important.
What DaDepo does—and does not do
Creating or reviewing a tokenised-security Asset Passport does not mean that DaDepo has:
- issued the security;
- created the token;
- validated the issuance;
- assigned an official instrument identifier;
- operated a depository;
- maintained the legally authoritative securities register;
- provided custody;
- provided a securities wallet;
- provided a CBDC wallet;
- moved central-bank money;
- matched a trade;
- cleared a transaction;
- settled a transaction;
- determined settlement finality;
- transferred legal title;
- confirmed beneficial ownership;
- approved an investor;
- determined investor eligibility;
- operated an exchange;
- provided brokerage;
- processed a corporate action;
- guaranteed coupon or principal;
- valued the security;
- recommended an investment; or
- provided legal, regulatory, depository, custody, settlement, brokerage, investment, tax, accounting or valuation advice.
Important: DaDepo provides technology and information tools. It does not provide securities issuance, depository, custody, brokerage, clearing, settlement, CBDC, payment, legal, regulatory, investment, tax, accounting or valuation advice or services unless a specific service is expressly identified and lawfully provided. The legal effect of securities issuance, ownership records, DLT entries, wallet control, transfer, settlement finality and corporate actions depends on the applicable market infrastructure, governing documents, law and regulatory framework.
A practical digital-security checklist
Before a tokenised security is presented to an investor, depository participant, custodian, settlement provider or other authorised reviewer, ask:
- Instrument: What exact security does the digital representation refer to?
- Issuer: Which legal entity owes the security obligations?
- Terms: Which issue documents define principal, coupon, maturity and investor rights?
- Identifier: Which official or market identifier anchors the instrument?
- Representation: What does the token or DLT entry represent?
- Mapping: How is the digital identifier linked to the underlying instrument identifier?
- Issued quantity: How many units legally exist?
- Digital quantity: How many units are represented on the DLT layer?
- Reconciliation: Do those quantities match?
- Depository: Which regulated depository or record-keeping infrastructure is involved?
- Authoritative record: Which record is authoritative for current holdings or legal ownership?
- Investor: Which legal entity holds the position?
- Wallet: Which wallet or account represents that participant?
- Control: Who is authorised to operate the wallet?
- Eligibility: May that participant legally and technically receive the security?
- Restriction: Does a lock-in or other transfer restriction apply?
- Cash asset: Which payment asset settles the transaction?
- Cash wallet: Which account or wallet provides the cash leg?
- DvP: How are securities and cash transfers linked?
- Settlement: What event indicates that the transaction completed?
- Finality: Which rule or authoritative system determines legal settlement finality?
- Failure: What happens if one leg cannot complete?
- Correction: How is an erroneous transaction corrected without hiding the history?
- Coupon: How are entitlement and payment determined?
- Record date: Which holding record controls a corporate-action entitlement?
- Maturity: How is the security redeemed?
- Extinguishment: How is the digital representation cancelled when the legal security ceases to exist?
- Secondary trading: Which participants and venues can transfer the security after any lock-in expires?
- Interoperability: Can the position move between conventional and DLT infrastructure if the framework permits it?
- Custody: What happens if access credentials are lost or compromised?
- Provenance: Can every material state be traced to the issuer, depository, DLT ledger, exchange, wallet and settlement evidence?
- Consistency: Can an authorised reviewer confirm that every system is still talking about the same bond?
If the answer to “what exact security does this token represent, and which record proves who owns it now?” is unclear, the digital-security infrastructure is incomplete.
India’s pilot reveals the real tokenisation transition
The REC transaction is important because it removes an easy marketing story.
This was not:
Paper
->
Digital
The bond market was already electronic.
The more meaningful transition is:
Dematerialised security
->
DLT-based ownership representation
->
Digital central-bank-money settlement
->
Atomic DvP
That is a market-infrastructure experiment.
The token is not the innovation by itself
A token identifier is easy to create.
The difficult part is connecting it to:
- a legally valid security;
- a regulated depository framework;
- an eligible investor;
- a reliable ownership position;
- a cash asset;
- settlement rules;
- finality;
- corporate actions; and
- later transfer.
India’s pilot begins to test those connections.
That is why it matters.
A faster rail increases the value of a durable asset record
As settlement becomes faster, there is less time to resolve ambiguity after execution.
The market needs to know before the transaction:
Which security?
Which investor?
Which wallet?
Which quantity?
Which cash leg?
Which restrictions?
Which authoritative record?
Better settlement infrastructure does not reduce the need for asset identity.
It increases it.
The same lesson applies outside listed bonds
Private assets are moving toward more digital infrastructure too.
A receivable can have:
Underlying contract
+
Asset Passport
+
Digital representation
+
Financing position
A loan can have:
Loan agreement
+
Servicing record
+
Participation
+
Tokenised interest
A claim can have:
Cause of action
+
Funding right
+
Economic participation
+
Digital representation
In each case:
The digital representation should remain attached to the legal and economic asset it represents.
Tokenisation cannot substitute for asset identity.
The next question is not how many tokenised bonds exist
The market will probably see more pilots.
The useful metric will not be:
Number of tokens minted
It will be whether the infrastructure can support:
- repeat issuance;
- secondary trading;
- corporate actions;
- interoperability;
- institutional custody;
- reliable settlement;
- regulatory oversight;
- correction;
- asset servicing; and
- eventual maturity.
The first issuance proves that the route can operate.
The harder test is whether the asset can remain coherent through its full lifecycle.
The bond was already digital
That is what makes India’s first tokenised bond such a useful case.
The pilot is not evidence that financial markets have finally discovered electronic securities.
They did that decades ago.
It is evidence that mature electronic securities infrastructure can itself be redesigned.
The opportunity is to reduce reconciliation and settlement friction.
The risk is to create another digital representation that becomes detached from the legal asset it is supposed to represent.
That leads to a broader rule for market infrastructure:
Tokenisation is valuable when a new digital representation makes a trusted asset easier to move without making its identity, ownership or legal state harder to understand.
REC’s bond already had an issuer.
It already had terms.
It already had an electronic securities identity.
It already created legal payment obligations.
The token did not create those things.
What the pilot changes is the infrastructure through which the market records and settles them.
That is a much more important transformation.
Further reading
- Financial Express: REC raises Rs 500 crore via tokenised bonds
- Financial Express: What tokenised bonds mean for India’s debt market
- Business Standard: India’s first tokenised bond — what changes when debt moves to blockchain
- Reuters: India plans first tokenised bond issue in September
- WebIndia123 / REC release: REC Limited successfully issues India’s first Pilot Issue on Tokenized Corporate Bonds under SEBI Regulatory Sandbox Framework
- CDSL: Corporate Bond Database