What Does an Examiner Want to See in a Covenant Monitoring Audit Trail?
One unbroken chain per test: the covenant as written in the executed agreement, the test date and the data as at that date, the source documents behind each operand, who computed the ratio and how, the independent recomputation, the determination, and any waiver or cure with the approval authority that granted it. Any missing link is the finding.
Key facts
- YuSight cites 100% of figures with one-click source verification. For a covenant test that is the whole examination: an examiner points at 3.36x and asks where it came from, and the answer is a page in the audited accounts, not an analyst's recollection.
- "Demonstrate appropriate administration and monitoring of a loan" is a written standard. The Interagency Guidelines Establishing Standards for Safety and Soundness require loan documentation practices that do exactly that, and that "enable the institution to make an informed lending decision and to assess risk, as necessary, on an ongoing basis" (12 CFR Part 30, Appendix A, II.C).
- The examination handbook was rewritten in June 2026. OCC Bulletin 2026-29 (25 June 2026) issued the "Lending and Loan Portfolio Risk Management" booklet, version 1.0, and rescinded the "Loan Portfolio Management" booklet, the related OTS handbook sections and OTS Thrift Bulletin 78a. The new booklet covers "risk management practices applicable to all phases of a loan's life cycle" (OCC).
- The leveraged lending benchmark is gone; the documentation expectation is not. On 5 December 2025 the OCC and FDIC rescinded the 2013 Interagency Guidance on Leveraged Lending and its 2014 FAQs, and now expect banks "to manage leveraged lending exposures consistent with general principles for safe and sound lending" (OCC Bulletin 2025-44). Examiners lost a checklist, not an interest.
- The unit of examination is one test, not one borrower. The checklist below is 31 items across seven links, and it is scored per covenant per test date.
Why the covenant trail is examined separately from the credit file
The credit file answers should we have lent. The covenant trail answers did we keep watching, and did we act. They fail differently.
A complete credit file with a strong memo and a stale monitoring record is the more common finding of the two, because origination is staffed and monitoring usually is not. The file-level view is in the examiner-ready credit file documentation checklist; what follows is the covenant-specific chain, which is narrower, deeper and reconstructed one test at a time. Where the memo itself was AI-drafted, the parallel expectations are set out in what examiner review requires from an AI-drafted credit memo.
How to assemble the trail: seven links
- Fix the covenant as written. Pull the definition from the executed agreement — clause number, page, and the amendment history that governs the test date.
- Fix the test date and the reporting deadline that the agreement sets, not the date the document happened to arrive.
- Assemble the data as at that date and record its as-of, not its receipt date.
- Identify every source document feeding every operand, down to the note and page.
- Record the computation — who, when, by what method, and every intermediate figure.
- Record the independent recomputation and reconcile it to the borrower's certified number.
- Record the determination and its consequence — compliant, breached, waived or cured — with the approval authority named.
The 31-item checklist
Owner key: RM = relationship manager · CA = credit administration · AN = credit analyst · CO = credit officer / approver · LR = independent loan review · LG = legal or documentation.
A. The covenant as written
# | Item | Owner | Evidence artefact |
|---|---|---|---|
1 | Executed facility agreement on file, signed and dated | LG | Signed PDF, execution page |
2 | Covenant clause extracted verbatim with clause and page reference | LG | Clause extract with citation |
3 | All amendments, waivers and side letters affecting the covenant, in date order | LG | Amendment register |
4 | The version of the definition that governs this test date identified | CA | Version-effective register |
5 | Defined terms resolved — EBITDA, Fixed Charges, Net Debt, add-back caps, cash-netting limits, frozen GAAP date | AN | Definitions worksheet, clause-cited |
B. Test date and schedule
# | Item | Owner | Evidence artefact |
|---|---|---|---|
6 | Test frequency and each test date derived from the agreement | CA | Covenant calendar |
7 | Reporting deadline per the agreement, and the date documents actually arrived | CA | Receipt log with timestamps |
8 | Late or missing deliveries logged with the chase record | RM | Correspondence log |
9 | Grace or cure periods identified and dated | LG | Clause extract |
C. The data as at the test date
# | Item | Owner | Evidence artefact |
|---|---|---|---|
10 | Financial statements as at the test date, audit status stated | RM | Statement PDF, auditor's report |
11 | Compliance certificate, signed by an authorised officer | RM | Signed certificate |
12 | Lender-side data as at the test date — drawn balances, interest charged, scheduled amortisation | CA | Core system extract, dated |
13 | Restricted vs unrestricted cash split evidenced | AN | Cash note extract |
14 | Off-balance-sheet and lease obligations captured | AN | Lease note extract |
D. Source documents
# | Item | Owner | Evidence artefact |
|---|---|---|---|
15 | Every operand traced to a document, note and page | AN | Citation index |
16 | Documents retained in the system of record, not in mailboxes or shared drives | CA | Repository link per document |
17 | Any figure taken from management accounts flagged as unaudited | AN | Source flag on the operand |
E. Computation
# | Item | Owner | Evidence artefact |
|---|---|---|---|
18 | Named person who computed the ratio, with date and time | AN | System user record |
19 | Method stated — formula as applied, not the market-standard formula | AN | Computation worksheet |
20 | All intermediate figures shown, not just the result | AN | Line-by-line working |
21 | Any judgement applied (an add-back allowed, a lease classified) written down with its reason | AN | Judgement note |
22 | Version history preserved where a figure was corrected | CA | Change log with before/after |
F. Recomputation and reconciliation
# | Item | Owner | Evidence artefact |
|---|---|---|---|
23 | Independent recomputation performed by someone other than the preparer | CO | Second-preparer record |
24 | Certified figure and recomputed figure shown side by side | AN | Reconciliation sheet |
25 | Each difference attributed to a named definitional treatment and clause | AN | Delta attribution table |
26 | Headroom stated, not just pass or fail | AN | Headroom calculation |
G. Determination, breach and remedy
# | Item | Owner | Evidence artefact |
|---|---|---|---|
27 | Determination recorded — compliant, breached, or unable to test — with date | CO | Determination record |
28 | Breach classified and escalated per policy, with the escalation timestamped | CO | Escalation record |
29 | Waiver documented: scope, period, conditions, consideration charged | LG | Executed waiver letter |
30 | Approval authority evidenced against the delegated authority matrix in force at the date | CO | Approval record plus authority matrix version |
31 | Independent review sampled this test and its conclusion recorded | LR | Loan review workpaper |
Print this, score one column per test date, and treat anything unevidenced as absent. An examiner will.
A worked example: reconstructing one test eighteen months later
Facility: $250m revolving credit. Covenant: Total Net Debt / EBITDA ≤ 3.50x, tested quarterly. Test date: 31 December 2024. File pulled: June 2026. Figures in $'000 and illustrative.
Net debt, built from the accounts:
Component | Amount | Source |
|---|---|---|
Term debt | 120,000 | Borrowings note, p.41 |
Revolver drawn | 42,400 | Bank's own core system extract, 31 Dec 2024 |
Finance lease liabilities | 25,000 | Lease note, p.44 |
Total debt | 187,400 |
|
Cash and equivalents | 21,300 | Balance sheet, p.28 |
less restricted (escrow) | (6,400) | Cash note, p.39 |
Nettable cash (agreement caps netting at 15,000) | 14,900 | Clause 1.1, p.12 |
Net debt | 172,500 |
|
EBITDA, to the agreement's definition: Reported EBITDA 48,900. Permitted add-backs claimed 2,400. The cap is 5% of pre-add-back EBITDA = 5% × 48,900 = 2,445, so the full 2,400 is allowed. Covenant EBITDA = 48,900 + 2,400 = 51,300.
Leverage = 172,500 ÷ 51,300 = 3.3626 → 3.36x. Covenant ≤ 3.50x. Compliant.
Headroom, which is the answer to the follow-up question: Maximum net debt at 3.50x = 3.50 × 51,300 = 179,550. Headroom = 179,550 − 172,500 = 7,050. Or in the direction that actually moves: EBITDA could fall to 172,500 ÷ 3.50 = 49,286 before the covenant trips — a fall of 3.9% from 51,300.
That single "compliant" needs eleven cited artefacts behind it: the clause, the netting cap, the add-back cap, four notes, one core-system extract, the certificate, the preparer record and the approver record. The ratio mechanics themselves are in covenant testing for DSCR and leverage, and the full testing cycle in covenant monitoring in commercial lending.
The three gaps examiners actually find
- A status field with no arithmetic behind it. Item 20 is where most institutions fail: the result is stored, the working is not. Whether the working sat in Excel or in a purchased platform makes no difference — see covenant tracker vs covenant monitoring software.
- The wrong version of the definition. A covenant amended in March 2024 tested on the pre-amendment definition in December 2024. Item 4 exists solely for this.
- A waiver granted below authority. The waiver letter is on file, the approval is on file, and the delegated authority matrix in force at that date is not — so nobody can show the approver had the authority. Item 30.
FAQ
What does an examiner want to see in a covenant monitoring audit trail?
An unbroken chain for each individual test: the covenant as written and the version that governed that date, the test date, the data as at that date, every source document behind every operand, the named person who computed it and their working, the independent recomputation, and the determination with its approval. A green status field with nothing underneath it is the finding.
How is a missed test explained?
In writing, at the time, not retrospectively. Record why the test could not be run — documents not delivered, borrower in a permitted grace period, entity restructured — the chase correspondence, the date the gap was escalated, and the remediation with a date. An acknowledged and escalated gap is a control working. An undated blank is a control failing.
Who must sign off a covenant test result?
At minimum, someone other than the person who prepared it, holding authority under the delegated authority matrix in force on the determination date. A breach determination, and any waiver or cure, should escalate to the authority level the policy assigns to that exposure — and the matrix version has to be retrievable alongside the approval.
How far back do examiners reconstruct?
Assume the full review period and be ready for older tests where a facility has an unresolved issue. The practical planning rule is that any test which fed a risk rating should be reconstructable for as long as that rating is relevant, which in a multi-year facility is longer than most retention schedules assume.
Does the recomputation have to be done by a person?
No. It has to be attributable, reproducible and reviewable. A system that recomputes from cited source data and records who accepted the result satisfies the same control objective as a second analyst, provided the acceptance is a named human act and the working is visible.
What if the borrower's certified ratio and ours differ?
Document both, attribute the difference to a specific definitional treatment and clause, and record which one your determination relies on and why. A difference that is explained is a monitoring control operating. A difference that is silently resolved to the borrower's number is the problem.
Is a covenant test a model for model risk purposes?
Usually not — a covenant computation is deterministic arithmetic over defined inputs. But if the extraction feeding it is machine-driven and the output feeds a risk grade, the governance question is live rather than settled; see what SR 26-2 changed.
Key takeaways
- The unit is one test, not one borrower. Score the 31 items per covenant per test date, and treat unevidenced as absent.
- Items 4, 20 and 30 are where files fail — the governing version of the definition, the arithmetic behind the status, and the authority behind the waiver.
- Headroom is the follow-up question. "Compliant" invites "by how much", and a trail that cannot answer it in the same breath is half a trail.
YuSight's Workflow and Audit Trail keeps every covenant test as a single record — the clause, the cited operands, the preparer, the recomputation and the approver — with 100% of figures cited back to their source document and page.
See the audit trail an examiner would see — book a live demo.
