For financial institutions
A finding raised by your reviewer or auditor becomes a remediation item, a board conversation, and a line in next year's exam. The same condition, found three months earlier by your own team, is just a task. VetALM puts an AI reader on your documentation and runs the reviewer's evidence pass on your schedule.
Review readiness
None of these are exotic. They're the ordinary consequences of a model that's been running for a few years while the people and priorities around it changed. They are also what an independent reviewer is trained to look for first, and what VetALM's AI reader is pointed at across your whole document set.
A deposit study from 2022 still driving betas and decay rates in 2026, with a policy that requires a refresh every twenty-four months. AI reads both dates from the documents. A deterministic rule compares them. The result is unarguable and high severity, and it was trivially avoidable if someone had checked.
An assumption set to something other than what the study recommended, because someone had a reason at the time. A language model reads across the study, the config, and the committee minutes looking for that reason. If it isn't written down anywhere, the reviewer can only record that it isn't.
The figure in the ALCO package doesn't tie to the model output it came from. AI reads both numbers and ties each to its page, and the comparison is arithmetic from there. Usually it's a version mismatch, occasionally something worse. Either way it's a governance finding.
The policy states limits, the model doesn't have them loaded, and nothing is breaching because nothing is checking. A control gap rather than a risk result.
A prior validation, exam, or audit item marked for remediation that the current evidence shows unchanged. Repeat findings read as a remediation-tracking failure, not just a technical one.
Twelve core documents a reviewer tests against, out of forty-four types they might ask for. AI classifies what you upload against that list, and finds documents printed inside others, like minutes in an ALCO packet, so you see the real gaps without sorting the folder yourself. Knowing which ones you'd struggle to hand over is a useful morning's work.
Independent testing
Your vendor's model produces a number. Your reviewer will test it: against your board's limits, against your books, and against what actually happened. You can know the answers before they ask.
VetALM builds a limits schedule from your board-approved policy and measures every result against it, never against the benchmark printed on the vendor's report. It ties the model's balances to your Call Report, back-tests projected NII against actual results over the same twelve months, and checks each product's betas, decay rates, and average lives against typical ranges. Each test is laid out as a workpaper, with the figures it compared and where each one came from.
An exception isn't automatically an error in your model. It can just as easily point at an assumption worth documenting. Knowing which, before someone else asks, is the point.
When to use it
Run it sixty to ninety days before your reviewer starts. Close what you can, document what you can't, and walk into the kickoff knowing what they'll find.
Interest-rate risk and model governance are standing exam topics. An evidence-backed self-assessment, with citations, is a better answer than a binder.
A new version, a re-parameterization, or a conversion is where assumptions quietly drift from their documentation. Re-run and compare against the prior engagement's record.
Questions institutions ask
No, and we'd steer you away from anyone who says otherwise. Independence requires a party outside the model's ownership and use, which a tool your own team runs cannot supply. That is true no matter how good the AI is. VetALM is for self-assessment and readiness. If your reviewer chooses to use it as well, that's their engagement and their sign-off.
No. VetALM reviews your IRR program: governance, limits, documentation, board reporting, and outcomes. A full model validation also tests the model against your own data, measures assumptions like deposit betas and decay from your history, and benchmarks the model against a calibrated alternative. VetALM doesn't do those, so it won't tell you whether your model's math is right. It will tell you whether the program around it would hold up.
No. AI reads the documents you already produce: policy, shock reports, deposit studies, assumption documentation, config exports, board packages, and back-testing evidence. Nothing connects to your model or core.
Your own portal. It shows the document request with due dates, takes a whole folder at once and matches each file to its request line, and tells you plainly when a file is sent back and why. If your reviewer releases findings to you, you can respond to each with support and comments. Their status and severity stay with your reviewer.
Only roughly. VetALM has its own challenger model, built from your Call Report and assumption register, that sets its EVE and NII beside your vendor's across the shock set. It is uncalibrated, so it stays in a workbench: it raises no findings and is not printed in the report. The testing it runs, against your limits, your books, and your actual results, doesn't depend on it.
It's the normal case, and it's partly the point. The document checklist will show you exactly which of the twelve core documents you can't currently produce, which is often the most actionable output of a first run.
AI does the reading and the writing. It classifies each document, reads every figure with a citation to the page or cell it came from, answers the review program, reads across the full document set for what no rule anticipates, and drafts findings and the report. Code does the rest: every reading is checked against its page, the seventeen detection rules are fixed comparison logic, the tests are arithmetic, and the audit trail is recorded, not generated. Every finding is then checked against its sources by a second AI read, and requires a human reviewer's decision before it appears in a deliverable.
Typically the ALCO/treasury function or model risk, with internal audit as a reader. Roles are enforced server-side, so read-only access for the people who need visibility without edit rights is straightforward.
We'll walk through a complete engagement on a sample dataset: the document checklist, the workpapers and tests, the review program, and the findings with their citations. Then we'll talk about running it on yours.
