What happens in one covenant review cycle?
The cycle starts before the package arrives. Each reporting requirement in the agreement sets a due date, usually the period end plus a fixed number of days, and a grace period after that. CovenantShield marks a requirement due soon 14 days ahead by default, then due, overdue and, once the grace period passes, an exception for credit administration.
The package arrives under its borrower, loan and period, and the memo records what is missing, late or stale. Each covenant is then recalculated from the statements with the definition approved for that loan and that period, including any step-down or amendment. The borrower’s certified figure sits beside the recalculated one. If an input has no source page, the test does not run; it goes to an analyst.
Each result is labeled, compared with prior periods and written into a review memo with a decision box, a test table and an evidence appendix. The OCC’s Lending and Loan Portfolio Risk Management booklet lists "monitoring the status of required periodic borrower financial statements and loan covenant testing" among loan administration functions, and its Commercial Loans handbook asks how a bank checks "the ongoing accuracy and reliability of borrower certifications." A memo that shows both the certified and recalculated values answers the second question on every test.
Why are potential breach and breach different statuses, and who confirms?
A failed calculation is a fact about numbers. A breach is a conclusion about the loan, and it can lead to default notices, reservation of rights letters or a waiver negotiation. Before reaching it, a reviewer has to confirm the definitions, the inputs, the period and whether a waiver or amendment applies.
CovenantShield keeps those two steps apart. Every failed test is labeled potential breach until a reviewer confirms it. Terms such as breach confirmed, event of default, default notice, reservation of rights, acceleration and waiver accepted can only leave the bank after reviewer sign-off. Each potential breach opens one exception for that borrower, loan, covenant, period and trigger, with evidence, severity, owner and next action, and repeat alerts for the same exception are suppressed unless severity rises.
A waiver does not erase the failure. The OCC booklet counts "Covenant breaches (even if waived)" among financial exceptions a bank should track, and the Rating Credit Risk handbook tells examiners to "be alert for covenants that have been waived or renegotiated." CovenantShield marks a waived failure waived non-compliance and keeps the failed calculation, so the history is there when the next period is tested.
How much of covenant testing should run without a reviewer?
CovenantShield has three modes: audit, assist and automate. In audit and assist modes, a person reviews the results before a status is published. In automate mode, a compliant result can close on its own when every input meets its confidence threshold and no review gate fired, and the reasons are logged.
Every new policy starts in audit or assist mode. Moving to automate mode needs at least a 99 percent pass rate on a backtest of clean historical cases and a reviewer override rate no higher than 2 percent over the last 50 comparable cases. Promoting a policy needs approval from both the policy owner and a workflow administrator.
Some decisions stay with a person in every mode: a new covenant definition, a potential breach, a waiver or amendment, restricted legal language, a low-confidence input that could change a status, a source conflict that could change a status, and any manual override. Each override needs a reason code and records the value before and after.
