An end-to-end solution for loan covenants and post-disbursement obligations. Guard captures the covenant, schedules the reporting, reads what the borrower submits, checks it against the terms in force, and carries a breach through to a recorded outcome. Every result is confirmed by review before it stands.
Post-disbursement obligations are agreed once and then monitored forever: quarterly, per tranche, per document, by teams working from a workbook and an inbox. The failure is rarely dramatic. It is an obligation with no owner, a breach found a quarter late, and no clean trail when an inspection asks what was actually in force.
When a covenant is amended, most registers overwrite it, and with it the ability to say what the borrower was actually held to before. Guard supersedes instead of overwriting. Every version carries the dates it was in force, so every past reporting period stays assessable against the terms that applied then. Re-open any period and the register answers as it stood.
Covenants arrive as clauses in documents and rows in someone's workbook. Guard takes them from wherever they are today and holds them in a single register, with the source clause recorded against each one.
Capture each covenant against its source clause, with term, threshold and reporting cadence together, so every entry traces back to the document it came from and its monitoring schedule follows from it.
Bring across the spreadsheet you track covenants in today, as a structured import rather than a re-keying exercise.
Start from a library of common financial, affirmative and negative covenants, then adjust the thresholds and frequency to the facility.
A covenant, and any later amendment to it, is drafted by one person and reviewed by another before it takes effect. This is the governance RBI expects, built into the software rather than left to process discipline.
Covenant, threshold, frequency and source clause captured against the facility.
A different person approves, returns it with remarks, or rejects it.
The version is stamped with the dates it is in force and begins to apply.
The action is written to an append-only trail: who, what, when, and against which version.
The reporting cadence is extracted from the sanction letter along with the covenant itself, then put on a monitoring schedule. When the submission arrives, the engine reads it, tests it against the term in force for that period, and returns a result: complied, or not complied.
Quarterly, half-yearly, annual or event-based: the cadence is extracted with the covenant and scheduled, so each period opens on time with its own due date and expected submissions.
Whether a borrower sends figures by email or uploads a document, the submission lands against the period it belongs to. Where the covenant needs a figure the borrower did not state, the engine derives it from the document submitted.
Guard keeps the distinction explicit. A number that arrived but has not been certified is tracked as exactly that, not quietly treated as compliance.
Each value is tested against the version of the covenant that applied in that period, not today's, and the engine returns complied or not complied. The result is proposed, not final: it stands once an authorised reviewer confirms it.
Detecting a breach is the easy part. What an inspection asks for is what happened next: who justified it, who confirmed the result, whether a cure period ran, and on whose authority it was waived or penalised. Each step is authorised and recorded.
The engine reads the submission, tests it against the term in force for that period, and returns not complied, recording the comparison it made.
The explanation and supporting documents are recorded against that period, not against the covenant in general.
An authorised reviewer, never the person who logged it, confirms or overrides the engine's result and accepts, returns or escalates it, with remarks on the record.
Where a cure window applies, it is tracked to its deadline so the clock is visible rather than remembered.
The outcome your team decides, whether waived, penalised or escalated, is recorded with who authorised it. Nothing closes silently.
Post-disbursement documents and tranche conditions are agreed at sanction and then depend on someone remembering them. Guard holds each one as an open item with an owner and a deadline, and keeps it open until it is actually closed.
Covenant compliance is your institution's responsibility, and Guard never pretends otherwise. The engine does the work of reading and testing every submission, but no result stands until an authorised person confirms it, and what follows from a breach is always your call. Maker-checker controls and an append-only audit trail sit under every action, so the record of who decided what, and when, is complete.
Book a 30-minute walkthrough. Bring a sanction letter and the spreadsheet you track covenants in today, and we will show you how the same obligations read once they are on an effective-dated register.
Request a demo →LendShield Guard is a covenant compliance management tool provided by LendShield Technologies Private Limited, a technology company. LendShield is not a lender and does not provide credit. Compliance results produced by the covenant engine are proposed for review and take effect only once confirmed by an authorised user of the regulated entity. Guard does not declare an event of default, interpret contractual terms, certify the accuracy of a borrower's submitted figures, or provide legal or financial advice. All decisions, waivers and communications remain the responsibility of the regulated entity. Screens shown are illustrative of the product's structure and do not represent any client's data.