Covenant Monitoring for Indian Private Credit: Beyond Quarterly PDFs

Here is the uncomfortable arithmetic. A borrower breaches a DSCR covenant in the quarter ending June. Their reporting pack is contractually due 45 days after quarter end, so it arrives mid-August — often later. An analyst works through it in the last week of August. You learn about a June breach in September.

By then the borrower has had roughly three months to keep operating on the assumption that nobody noticed. Whatever cash was available to protect your position in June has often been deployed elsewhere by September. Your covenant package worked exactly as designed — and it still gave you a stale answer.

This is the central problem in Indian private credit risk management, and it is not a discipline problem. Funds chasing submissions harder does not fix a structural lag built into quarterly reporting. What fixes it is changing the data you test against.

Why Indian borrowers are actually easier to monitor continuously

This is the part most funds have not internalised. Indian mid-market borrowers generate a far richer high-frequency data trail than their Western equivalents — because compliance requires it.

• GST returns, monthly. GSTR-1 and GSTR-3B give you revenue, buyer concentration and filing discipline every single month, filed with the government rather than prepared for you.
• Credit bureau records. Refreshed monthly, and they cover the borrower's behaviour with every other lender — not just you.
• Bank statements via Account Aggregator. With periodic consent under the AA framework, actual cash movement becomes an ongoing feed rather than a one-time underwriting pull.
• E-way bills and HSN data. For goods businesses, evidence of actual movement, not just invoiced revenue.

A US mid-market borrower has no monthly government-filed revenue return. An Indian one does. That is a structural monitoring advantage, and almost no fund is using it — because the platforms available were designed for markets where it does not exist.

Write covenants you can actually test

Continuous monitoring only works if the covenant package was drafted with testability in mind. Most are not — they are drafted to be legally sound, which is necessary but insufficient.

Define the input, not just the ratio

"Debt Service Coverage Ratio of not less than 1.25x" is legally clear and operationally ambiguous. Coverage measured on what EBITDA — reported, adjusted, trailing twelve months, annualised from the latest quarter? Debt service including or excluding the bullet? A covenant that requires a judgement call every time it is computed cannot be automated, and worse, it cannot be argued cleanly when you need to enforce it.

Add high-frequency proxies alongside the hard covenants

Keep the quarterly financial covenants — they are the enforceable ones. But add monthly information covenants that give you a leading signal, and make the failure to provide them itself an event:

• GST filing covenant. Borrower shall file GSTR-3B within statutory timelines and consent to filing-status verification. A missed filing is one of the earliest stress signals available.
• Monthly revenue reporting against GST-declared turnover — so declared revenue and filed revenue can be reconciled rather than taken on trust.
• Account Aggregator consent maintained for the facility's life, giving you banking data continuously.
• Bureau consent for periodic refresh, so deterioration with other lenders surfaces to you.

The last one deserves emphasis. In practice, a borrower under stress almost always starts missing payments to someone before they miss yours. Bureau data is how you see that, and it is monthly.

Distinguish maintenance from incurrence covenants explicitly

A maintenance covenant is tested every period regardless of borrower action. An incurrence covenant is tested only when the borrower does something — takes on debt, pays a dividend, disposes of an asset. These require completely different monitoring: the first is a scheduled computation, the second is an event trigger. Systems that treat them identically either spam you with irrelevant tests or miss the event entirely.

The three-tier monitoring model

The practical architecture that works for Indian private credit separates monitoring by frequency and consequence.

Tier 1 — Continuous signals (daily to weekly)

Bounced payments, GST filing status, bureau alerts, unusual banking patterns. These are not covenants and cannot be enforced on their own. Their job is to tell you where to look. A borrower who bounces an EMI to another lender and misses a GST filing in the same month deserves a phone call, not a diary note for next quarter.

Tier 2 — Monthly proxy tests

Compute an approximate version of your key covenants from monthly data — GST turnover trend against your revenue assumption, banking inflows against modelled debt service. These are indicative, not enforceable, and that is fine. A proxy DSCR trending from 1.6x toward 1.2x across three months tells you the quarterly test is going to be tight, months before it is run.

Tier 3 — Contractual covenant tests (quarterly)

The formal, enforceable computation from the reporting pack. This still matters — it is what you rely on to issue a notice. But when Tiers 1 and 2 are running, Tier 3 stops being a discovery mechanism and becomes a confirmation mechanism. You should already know the answer before the pack arrives.

What to do with a breach once you see it early

Early detection is only valuable if it changes the response. Seeing a breach four months sooner and doing the same thing four months later wastes the advantage.

• Get to the borrower before the formal test. A conversation off the back of a proxy signal is cooperative. A conversation after a formal notice is adversarial. The same facts produce different outcomes depending on which one you have.
• Decide deliberately whether to waive, reset or enforce — and document the reasoning. Serial informal waivers are how funds lose the ability to enforce later.
• Tighten information covenants first. Where the stress looks temporary, moving from quarterly to monthly reporting is a proportionate first step that preserves the relationship.
• Know your enforcement route before you need it. For Indian exposure that means understanding which of SARFAESI, the DRT, arbitration or the IBC applies, and the sequencing constraints between them.

That last point is where funds most often lose value. Admission of an IBC application before the NCLT triggers a moratorium that freezes SARFAESI enforcement — so if security enforcement was nearly complete, triggering insolvency can destroy more value than it protects. Early detection buys you the time to sequence properly instead of reacting.

A realistic implementation sequence

1. Inventory your existing covenants and mark each as automatable, partially automatable, or judgement-dependent. Most funds find a third are ambiguously drafted.
2. Fix the definitions on new deals. You cannot retrofit a covenant package, but you can stop adding untestable ones.
3. Add information covenants for GST filing, AA consent and bureau consent to all new documentation.
4. Stand up Tier 1 signals first. They need no covenant changes at all — bureau and GST filing status can be monitored on existing consents in most cases.
5. Build proxy tests for your two or three most important covenants only. Resist modelling everything.
6. Automate the quarterly computation last. It is the least urgent, because by then you already know.

Note the ordering. Most funds start at step 6 — automating the quarterly report — because it is the most visible pain. It is also the step that changes your risk position least.

The point

Covenants are not a compliance exercise; they are an early-warning system that most funds run at the wrong frequency. Indian borrowers happen to produce more monitorable high-frequency data than borrowers in almost any developed market — monthly GST filings, monthly bureau records, consent-based banking data. A fund still learning about June breaches in September is not short of data. It is testing the wrong data on the wrong clock.