
The covenant nobody tested
A loan covenant is a promise to check something on a schedule. Its entire protective value depends on the check actually happening, and the check is exactly the kind of quiet, recurring task that lapses. Nobody decides to stop testing covenants. The test date simply arrives when everyone is busy, the borrower's financials are late, and the deadline slides, and then slides again, until a covenant that was supposed to catch deterioration early catches it at the workout.
This is one of the most common gaps an examiner finds, and it is never a competence problem. It is a rhythm problem. The covenant was negotiated carefully and then orphaned operationally, because testing it was nobody's clearly owned, scheduled job.
What routine testing actually requires
Covenant testing that happens is a small system, not a burst of diligence:
- The covenants abstracted into fieldsNot left in the loan agreement's prose. A covenant living only in a document nobody reopens is a covenant that will not be tested.
- Test dates as diaried obligationsEach with an owner and a reminder that fires before the date, not after the borrower is already late.
- A defined borrower-delivery stepThe borrower knows what to send and when, so the financials that feed the test arrive on time.
- The result recorded, pass or failOn the record, with the calculation, so the next reviewer and the next examiner can see the test happened and what it found.
Make it routine, and it stops being heroic
The reason covenant testing lapses is that it is treated as a task to remember rather than a routine that runs. Memory does not scale across a portfolio; a hundred loans have a hundred test dates, and no analyst holds all of them. The fix is to move the obligation out of memory and into the system that services the loan, so the test date announces itself, the borrower is prompted, and the result is captured, the same way any well-run recurring obligation works.
This is the servicing tail of the same discipline that makes closings clean: obligations tracked as lines with owners and dates, on a record that remembers. A loan boarded that way from a clean closing file arrives in servicing with its covenants already abstracted and dated, so testing is a routine the system runs rather than a fire the analyst fights. The payoff is not just a passed exam. It is the actual thing the covenant was for, catching a problem while it is still small, which only happens if the test happens on time.
The same recorded-obligation discipline that runs across Prodeal's 56,000 closings is what keeps covenant tests from lapsing.
Questions lenders ask
- Why does covenant testing lapse?
- Because it is a quiet, recurring task treated as something to remember rather than a routine that runs. The test date arrives when everyone is busy, the borrower's financials are late, and the deadline slides, until a covenant meant to catch deterioration early catches it at the workout. It is a rhythm problem, not a competence one.
- What does reliable covenant testing require?
- The covenants abstracted into fields rather than left in the loan agreement's prose, test dates diaried with owners and reminders, a defined borrower-delivery step so financials arrive on time, and the result recorded pass or fail with its calculation, so the test is provably done.
- How do you keep tests from being forgotten across a portfolio?
- Move the obligation out of memory and into the servicing system, so the test date announces itself, the borrower is prompted, and the result is captured. Memory does not scale across a hundred loans with a hundred test dates; a record that remembers does.