Annual Model Re-Verification Checklist
Executive Summary
Key Takeaways
- ✓ Annual re-verification is a comparison exercise against a defined reference point, not a fresh, standalone audit performed in isolation.
- ✓ Drift should be classified into a defined state, structurally stable, drifted and remediated, drifted and degraded, or restructured, rather than described only in general terms.
- ✓ A model that has not changed at all is a genuine, positive verification outcome and should be recorded as such, not treated as a non-event.
- ✓ Findings identified in a prior cycle must be checked for actual resolution, not assumed resolved because they were not raised again.
Objective¶
This checklist verifies the structural mechanics specific to an annual model re-verification cycle: comparison against a defined reference version, drift classification, and resolution tracking for prior findings. It exists as a distinct checklist because re-verification is a comparison exercise against a prior reference point, not a fresh, standalone audit, and is not covered by the general Financial Model Audit Checklist, which this checklist assumes has already been applied to establish the baseline in the first place.
Models relied on year after year, in an ongoing lending facility or an asset under continued management, can drift silently between the version originally verified and the version currently in use. Annual re-verification exists to answer, directly and on a defined cycle, whether the model relied on today is still the model that was verified.
Applicability¶
Applicable when a financial model under an ongoing lending facility, credit line, or asset management relationship is due for its scheduled annual review. Relevant to lenders' portfolio and credit teams, and to asset managers or family offices whose ongoing decisions rely on a model established at an earlier point, typically financial close.
Checklist¶
| # | Check Item | Why It Matters | Evidence to Collect |
|---|---|---|---|
| 1 | A defined reference version exists — the custody baseline from close, or the prior year's re-verification deposit | Without a defined reference point, drift cannot be measured; it can only be described impressionistically | Reference version identifier and date |
| 2 | The current model is run through the same structural methodology used to produce the reference version | Comparing outputs of different methodologies produces a false sense of drift or stability that does not reflect an actual change in the model | Methodology version confirmation for both current and reference runs |
| 3 | Findings from the current run are compared item-by-item against the reference version's findings | A general summary comparison can miss a specific finding that appeared, disappeared, or changed in nature between versions | Finding-level comparison output |
| 4 | The comparison result is classified into a defined drift state — structurally stable, drifted and remediated, drifted and degraded, or restructured | An undefined, narrative-only drift description is harder to act on consistently across a portfolio of models reviewed on the same cycle | Drift classification with supporting basis |
| 5 | Findings closed in a prior cycle are individually confirmed as still resolved in the current model, not merely absent from the current findings list | A finding's absence from the current list could reflect a genuine fix, or could reflect the issue moving location within a restructured model | Prior-finding resolution confirmation |
| 6 | Any newly triggered finding not present in the reference version is flagged as new drift, distinct from a finding that persisted unresolved from the prior cycle | Conflating new and persisting findings obscures whether the model's condition is improving, stable, or deteriorating over time | New-vs-persisting finding classification |
| 7 | Where the model has not changed at all, this is recorded as a structurally stable outcome with a refreshed reference point, not left undocumented | A stable result is a genuine assurance outcome and should be captured with the same rigor as a drifted result | Structurally stable confirmation and refreshed reference record |
| 8 | The current cycle's output becomes the new reference version for the following year's comparison | Without updating the reference point, each subsequent cycle would compare against an increasingly stale baseline rather than the most recent verified version | Updated reference version record |
| 9 | Where the model has been substantively rebuilt or restructured since the reference version, it is classified as restructured rather than forced into a drifted classification | A rebuilt model may not be meaningfully comparable line-by-line to its predecessor, and forcing a drift comparison in this case can produce a misleading result | Restructuring assessment and rationale |
| 10 | The re-verification cycle's timing is confirmed against the facility's or governance framework's required review frequency | A re-verification performed off-cycle, early or late relative to the required frequency, may not satisfy the underlying governance or facility requirement it exists to support | Review cycle timing confirmation |
Common Failures¶
- No defined reference version exists, so drift is assessed impressionistically rather than through an actual comparison.
- A finding closed in a prior cycle is assumed still resolved because it does not reappear, without confirming the model still reflects the fix rather than having moved the issue elsewhere during a later change.
- A structurally stable result is treated as a non-event and left undocumented, rather than recorded as a genuine, positive verification outcome.
- A substantively rebuilt model is forced into a drift comparison against a predecessor it is no longer meaningfully comparable to, producing a misleading drifted or degraded classification.
Recommended Evidence¶
A completed annual re-verification should be accompanied by a drift register showing each finding's status across the current and reference versions, a documented drift classification with its supporting basis, and a refreshed reference record for the following year's cycle. This evidence set supports both the immediate credit or portfolio decision and the following year's comparison.
How to Use This Checklist¶
Apply the general Financial Model Audit Checklist to establish the initial reference version, then apply this checklist on each subsequent annual cycle, with particular attention to confirming prior findings are genuinely resolved rather than merely absent from the current list.
Continue Reading¶
Related Pillars¶
Related Checklists¶
Related Products¶
How OXXON tests thisRun a free structural check with FMAE
Frequently Asked Questions
What makes annual re-verification different from a first-time financial model audit?
It is explicitly a comparison exercise, testing the current model against a defined prior reference point, the model's custody baseline or the previous year's re-verification, rather than an audit performed without a prior reference.
What is a custody baseline?
The sealed, reference version of a model established at a defined point, typically financial close, against which later versions are compared to detect drift.
What are the drift classification states this checklist assumes?
Structurally stable, drifted and remediated, drifted and degraded, or restructured, each defined by testable conditions comparing the current model against its reference version.
Why does this checklist require checking prior findings for actual resolution?
Because a finding documented in a prior cycle that is not raised again in the current cycle could mean it was genuinely fixed, or could mean the model changed in a way that moved the issue rather than resolving it; both require verification rather than assumption.
Is annual re-verification a substitute for continuous monitoring?
No. It is a calendar-driven, point-in-time comparison performed on a defined annual cycle, not a continuous monitoring or alerting mechanism between cycles.
What happens if no prior baseline exists for a model?
The current cycle should establish one, since a re-verification exercise requires a defined reference point to compare against for the following year.
Who typically uses this checklist?
Lenders' portfolio and credit teams reviewing a model annually as part of an ongoing facility, and asset managers or family offices with models supporting assets under continued management.
Related Articles
What Is a Financial Model Audit?
A financial model audit is an independent, structured examination of an Excel based financial model to confirm that its mechanics, logic, and outputs are reliable enough to support a decision. It is not a check of whether the assumptions are optimistic or conservative. It is a check of whether the model actually calculates what its author believes it calculates. Every year, lenders extend debt, investment committees approve capital, and boards sign off on transactions using numbers that came out of a spreadsheet nobody outside the immediate deal team has independently verified. A financial model audit exists to close that gap before it becomes expensive.
What Is Model Risk?
Model risk is the risk that a decision is wrong not because the underlying business or investment case was flawed, but because the model used to evaluate it was. It is a distinct category of risk from market risk, credit risk, or operational risk, and it applies to any organisation that relies on a financial model, spreadsheet or otherwise, to support a material decision. Most published model risk content addresses statistical and regulatory capital models used inside banks. This page defines model risk specifically as it applies to Excel based financial models, the kind used every day for investment decisions, lending, and transaction evaluation, which is a related but distinct problem from the quantitative model risk literature most search results return.
Audit vs Validation — What's the Difference?
Financial model audit and model validation are frequently used as interchangeable terms, and specifying the wrong one in a lender requirement or an internal policy leads to real confusion about what has actually been checked. They test different things. An audit tests whether a model's mechanics are correct. Validation tests whether the model's methodology and assumptions are appropriate for its intended purpose. Both are legitimate, useful exercises. They are not substitutes for each other.