Flock

What is the Security and Covenant Monitoring System?

By Flock Research · Filings research desk

The Security and Covenant Monitoring System is where the paperwork behind a secured bond stops being paperwork. Before it existed, an issuer's claim about the assets backing an issue lived in documents that nobody outside the transaction could reconcile. The system puts issuers, debenture trustees and rating agencies on one depository hosted platform, with a record of who entered what and who verified it. This guide covers what the system records, who validates each entry, and the points where a trustee can stop an issue. It is not investment advice.

Definition

The Security and Covenant Monitoring System

is a platform hosted by depositories for recording the security created against listed debt securities and monitoring their covenants. Chapter III of SEBI's Master Circular for Debenture Trustees requires depositories to create, host, maintain and disseminate it using distributed ledger technology or similar such technologies. Source: SEBI.

What does the security and covenant monitoring system record?

Chapter III of SEBI's Master Circular for Debenture Trustees, SEBI/HO/DDHS-PoD-1/P/CIR/2025/117 dated August 13, 2025, introduces the platform to strengthen the process of security creation, monitoring of security created, monitoring of security cover, and monitoring of covenants of debt securities.

The circular says the system shall, among other things, capture three things: the process of creation of security including due diligence and charge creation, continuous monitoring of covenants by debenture trustees as applicable, and the credit rating of the debt securities by credit rating agencies.

Paragraph 4 then sets out the four areas in which stakeholders record information, aligned to how debt issuance actually works:

  • Security creation, security cover and covenants
  • Periodical monitoring of security cover and covenants
  • Interest and redemption payment, part and full
  • Credit rating information

Who builds and runs it?

Depositories do. Paragraph 3 requires them to create, host, maintain and disseminate the system using distributed ledger technology or similar such technologies, and then lists nine specific obligations.

ObligationWhat it requires
AccessSecure login credentials to issuers, credit rating agencies, debenture trustees and others for recording, verifying or viewing information
Data integrityAdequate safeguards for the integrity and security of data on the system
InteroperabilityShare information with the other depository to integrate and maintain a compatible system
AlertsAn alert mechanism for submission, acceptance and rejection of information, plus alerts for periodic and event based compliances
UploadsDocument upload for various stakeholders wherever necessary
Audit trailA trail or log of all communication and interaction among rating agencies, trustees, issuers and depositories, and of recording, verification and viewing
VersioningFunctionality to change already recorded information, with verification by the responsible stakeholder and logs, trails and prior versions retained
AccountabilityResponsibility for effective and smooth functioning, and a mechanism establishing accountability for rectifying issues and glitches
GovernanceOperational guidelines for the system after consultation with stakeholders

The interoperability requirement matters for anyone reading the data. Because both depositories must maintain a compatible system and share information, the record is not meant to fragment by which depository an issue sits with.

Where does the debenture trustee validate, and where can it block?

The system separates recording from validation. Issuers record, trustees validate, and the sequence is tied to the ISIN.

Under paragraph 5.1(a), the issuer records the details of proposed security creation or security cover including asset details and related documents, in the format at Annex IIIA, and must fill all the requisite fields at the time of creation of the temporary ISIN or ISIN. Paragraph 5.1(b) then provides that assets offered as security are recorded on the system pursuant to validation and verification by the debenture trustee under Chapter II.

Paragraph 5.1(c) is the enforcement point. Where the value and details of assets recorded are not in line with the terms of the proposed issue of debt securities, the debenture trustee shall not validate them and shall reject them on the system with remarks explaining why. The system intimates the issuer to rectify the discrepancy or record additional details before issuance of the temporary ISIN or ISIN is initiated, and the corrected entry again requires validation and verification by the trustee.

Before ISIN issuance

Point at which a debenture trustee's rejection of recorded asset details stops an issue proceeding on the system

Source: SEBI Master Circular for Debenture Trustees, SEBI/HO/DDHS-PoD-1/P/CIR/2025/117, Chapter III paragraph 5.1(c), dated August 13, 2025

The trustee also puts its own work product on the platform. Paragraph 5.1(d) requires the debenture trustee to upload reports and documents including the valuation report, ROC search report, title search report or appraisal report, security cover certificate, and the due diligence certificate in the Annex IIA format, along with other related reports and certificates as applicable.

How is charge creation recorded and checked?

Charge details follow the same record then validate pattern, but the validation reaches outside the system entirely.

Under paragraph 5.2(a), once the charge is created in favour of the debenture trustee, the issuer uploads the details of the charge in the Annex IIIB format together with supporting documents such as the pledge master report. Under paragraph 5.2(b), the debenture trustee then validates those details from the sub registrar, the Registrar of Companies, CERSAI, an information utility registered with the Insolvency and Bankruptcy Board of India, or any other independently verifiable source, confirms them on the system, and updates any subsequent changes if there is a discrepancy.

Paragraph 5.2(c) closes the loop with the exchange. Once the debenture trustee issues its due diligence certificate to the stock exchange in the Annex IIB format, the issuer uploads that certificate on the system.

Changes later in the life of the issue are also gated. Paragraph 5.3 covers any change to recorded information on charge creation or registration, and any modification in the value or details of the security because the issuer provided additional security or reduced or substituted existing security. Those changes are made only after verification and validation by the debenture trustee, and the documents and any permission or consent obtained are recorded on the system too.

How do covenants get onto the system?

Through the issuer, on a five working day clock. Paragraph 5.4(a) requires the issuer to enter the covenants of the issuance in the system and to upload the debenture trust deed within five working days of signing the deed, including covenants as to title of security among others.

That upload is what makes ongoing covenant monitoring possible on the platform, since the deed is the document the covenants are drawn from.

The due diligence that produces the reports uploaded here is described in how does a debenture trustee do due diligence, and the two certificates that pass through the system are distinguished in what is a due diligence certificate for debt securities. The deed itself is covered in what is a debenture trust deed. For a separate SEBI database covering corporate bond information, see what is the centralised database for corporate bonds.

The Security and Covenant Monitoring System is a recording and verification platform, not a public price or credit feed. Flock reports what issuers and trustees disclose, with the source and the date attached. It is not investment advice.

Frequently asked questions

What is the Security and Covenant Monitoring System?

A platform hosted by depositories for recording and monitoring the security created against listed debt securities and the monitoring of their covenants. Chapter III of SEBI's Master Circular for Debenture Trustees requires depositories to create, host, maintain and disseminate it using distributed ledger technology or similar technologies. Source: SEBI.

Who hosts the Security and Covenant Monitoring System?

The depositories. Under Chapter III paragraph 3 of SEBI's Master Circular for Debenture Trustees dated August 13, 2025, depositories create, host, maintain and disseminate the system, provide secure login credentials to issuers, credit rating agencies and debenture trustees, and share information with the other depository to keep a compatible system. Source: SEBI.

Can a debenture trustee reject an entry on the system?

Yes. Under Chapter III paragraph 5.1(c), if the value and details of assets recorded are not in line with the terms of the proposed issue, the debenture trustee shall not validate them and shall reject them on the system with remarks. The system then intimates the issuer to rectify before issuance of the ISIN is initiated. Source: SEBI.

When must a debenture trust deed be uploaded to the system?

Within five working days of signing. Chapter III paragraph 5.4(a) of SEBI's Master Circular for Debenture Trustees requires the issuer to enter the covenants of the issuance in the system and upload the debenture trust deed within five working days of signing the deed. Source: SEBI.

Flock tracks these filings, sourced, dated, and linked back to the original. See what smart-money entities disclosed, without the guesswork about what it means.

Disclosures shown are public regulatory filings. Data may be delayed or incomplete. Smart-money entities may no longer hold positions shown. Not investment advice.

The Smart Money Digest

A free weekly email of notable disclosure activity — every line with its filing date and source link. No advice, just filings. Unsubscribe anytime.