Skip to content

7.5 DLG monitoring

See 2.5 DLG / FLDG for the regulatory rules. This page is the operational implementation.

Per partner / per pool, store:

  • agreement_id, counterparty_LSP_or_party, RE (the regulated entity the DLG is provided to).
  • pool_definition — product, segment, vintage, ticket range, channel — exact eligibility for which loans fall under this DLG.
  • dlg_amount.
  • instrument_type — cash / FD / BG.
  • instrument_ref — bank, account no / FD no / BG ref.
  • valid_from, valid_to.
  • invocation_rules — typically NPA + 120 days, but per agreement.
  • replenishment_rules — if invoked, when does provider top up.
For each DLG agreement:
pool_outstanding = sum(loans matching pool_definition with status active+NPA)
cap_ratio = dlg_amount / pool_outstanding
if cap_ratio > 0.05 → IN COMPLIANCE
if cap_ratio < 0.05 → BREACH (DLG is now sub-5% — actually intentional; flag review)
Wait — re-read: the 5% rule is "DLG must not EXCEED 5% of portfolio".
So:
if cap_ratio > 0.05 → EXCEEDS CAP (illegal) — alert risk
if cap_ratio = 0.05 → at cap — flag for review (may shrink to under 5% if portfolio grows)
if cap_ratio < 0.05 → fine

The risk to monitor is portfolio shrinkage faster than DLG reduction — if loans pay off but DLG stays static, the ratio climbs and may cross the cap. Build alerts at 4% and 4.5% thresholds.

  • Compute pool_outstanding per agreement.
  • Compute cap_ratio.
  • Alert at thresholds.
  • Emit dlg.cap.warning / dlg.cap.breach events.

Every loan is tagged to zero or one DLG agreement (none if no DLG covers it). The tag is set at sanction based on the pool definition.

1. Loan classified NPA (per IRACP).
2. NPA + 120 days elapsed (or per agreement timeline).
3. Eligibility check: loan tagged to DLG agreement? Yes.
4. Invocation queue: this loan is eligible for DLG invocation.
5. Periodic batch (weekly or monthly) compiles eligible invocations.
6. Invocation file generated:
- Loan list with evidence (NPA date, current outstanding, days since NPA, recovery to date).
7. Notify DLG provider (LSP).
8. Provider validates; if disputes, resolution workflow.
9. Execute draw:
- if cash deposit: NBFC debits the deposit; credits the NPA's outstanding (in NBFC's books).
- if FD with lien: NBFC instructs bank to break / debit FD per lien terms.
- if BG: NBFC invokes the BG with issuing bank.
10. Funds received → reduce NPA outstanding in NBFC's books.
11. Update accounting:
- Reverse provision against P&L.
- Recognise DLG recovery.
12. Update DLG monitor:
- dlg_amount = dlg_amount - invoked_amount
- notify cap monitor; pool size may need adjustment too.
13. Replenishment trigger (if agreement requires):
- Provider tops up DLG instrument.
- System tracks compliance.
  • Pre-NPA: DLG sits as contingent asset off-balance-sheet; disclosed.
  • NPA, pre-invocation: same; provisioning on NPA proceeds normally per IRACP.
  • On invocation: cash inflow recognised; reduces NPA outstanding; reverses provision proportionally.
  • DLG fee / premium: recognised as cost of DLG arrangement; usually accrued.

The DLG does not substitute for credit-risk weighing — the RE’s IRACP provisioning and capital adequacy is independent of DLG cover. The DLG is a contingent recovery mechanism only.

Per the DLG Guidelines:

  • Annual public disclosure of total DLG cover received, by LSP, in audited financials.
  • Internal monthly cap report to board / risk committee.
  • Quarterly review of all DLG agreements.
  1. Target DLG well under 5% — operate at 2.5% – 3.5% to leave headroom for portfolio shrinkage.
  2. Tag loans precisely to pool — ambiguity in pool definition causes invocation disputes.
  3. FD with lien preferred over cash — LSP earns interest, reducing their DLG cost; the lien is enforceable.
  4. Automate invocation — don’t rely on manual lists; missed invocations are real economic loss.
  5. Quarterly tabletop of DLG invocation runbook — surfaces operational gaps before real stress.

A single loan must belong to at most one DLG pool. Overlapping pools (loan covered by two DLGs) violate the regulatory intent and create cap-computation ambiguity. The platform enforces “one DLG tag per loan” at sanction.

  • Per agreement: pool size, DLG amount, cap ratio, instrument validity, days to expiry.
  • Per agreement: invocation pipeline — eligible / submitted / paid.
  • Per agreement: recovery rate (DLG recovered / NPA in pool).
  • Per agreement: replenishment status.
  • Alerts: cap warning, expiry warning, invocation aging.