VetALM | AI-Assisted ALM Model Validation Audits and IRR Review

Who it's for

Two ways to use the same engine.

An ALM model validation audit or IRR review asks whether an institution's model and the program around it hold up: its documentation and assumptions support, its policy and limits, what ALCO and the board are shown, back-testing, and whether past findings were closed. Whether you're the independent party asking or the institution being asked, the evidence work is identical. It is also the part that eats the calendar.

Primary

Audit, review & validation firms

You perform IRR reviews, ALM audits, or model validations for financial-institution clients. Your constraint isn't demand. It's senior reviewer hours.

Send the document request from a built-in 44-item checklist, and let the institution answer it through its own portal
Arrive at the first meeting with the documents read, the tests run, and the program answered
Workpapers you'd build anyway: tests performed, a limits schedule, a document register, and an assumption inventory
On a full validation, VetALM takes the document and governance work, so your analysts' hours go to the quantitative testing

How firms use VetALM

Also for

Financial institutions

You own the ALM model, or the risk function that governs it. A review, audit, or exam is coming, and you'd rather find the gaps yourself.

Run the same tests and questions your reviewer will, on your own timeline
See which of the twelve core documents a reviewer tests against you can't currently produce
Catch stale studies, unsupported assumptions, and limit breaches before they're findings
Credit unions: two years of NCUA Call Reports are pulled in automatically

How institutions use VetALM

Scope

What VetALM covers, and what it doesn't.

VetALM reviews the program around the model: governance, limits, documentation, reporting, and outcomes. It does not re-perform the model or test it against the institution's raw data. Anyone who knows the difference between an IRR review and a full model validation will ask, so here is the line.

What it reviews and tests

Governance. Policy approval and review cadence, ALCO oversight, the age of deposit and prepayment studies, and whether prior findings were closed
Limits. A limits schedule built from the board-approved policy, every result measured against it, earlier quarters against the policy then in force, and limit bands checked for gaps
Assumption support. Whether each key assumption has a documented source, whether overrides have a rationale, and whether values sit within typical ranges
Reporting lineage. Whether the figures ALCO and the board saw match the model output they came from
Independent checks. Model balances tied to the Call Report or the books, and NII back-tested against actual results by VetALM itself

What it doesn't do

Re-perform the model. It relies on the model's reported output and the vendor's certification, as most reviews do
Test input data at the account level. Loan and deposit trial balances are summarized, not reconciled or sampled
Measure assumptions from the institution's history. It checks that betas, decay, and prepayment speeds are supported and reasonable, not that they match the institution's own behavior
Benchmark against a calibrated challenger. Its challenger model is uncalibrated, so it raises no findings
Sensitivity-test the assumptions. It doesn't stress them to show which ones move EVE and NII most

For an IRR program review or ALM audit, the left column is the core of the work. For a full model validation, the right column is the quantitative half, and it still needs an analyst. VetALM handles the documents and governance so that analyst's hours go to the testing.

The platform

Every screen is the working paper.

VetALM isn't a chat window bolted onto a document pile. It is the review workspace itself: an engagement moves through six stages (request, collect, test, review, sign-off, deliver), and each one holds the working paper for that step. AI makes the first pass through every one, and hands you the result in the form your workpapers already take.

1 Collect

The document request runs through the engagement.

Forty-four document types across seven categories, twelve of them core: the ones a review is tested against. Request any type with a due date, and the institution answers through its own portal: it uploads a folder at once, VetALM matches each file to its request line, and your reviewer accepts it or sends it back with a reason. Or upload the files yourself and let the AI classifier place each one. A document printed inside another, like minutes in an ALCO packet, counts as collected and links to the page it was found on. For credit unions, VetALM fetches the last two years of NCUA Call Reports on its own.

Only core and requested types are called missing, and a type can be marked not needed for one engagement
Nothing the institution sends enters the engagement until a reviewer accepts it
PDF (scans included), Excel, Word, and CSV, up to 100 MB a file

The Documents view: core documents in hand and types collected, files grouped by type, minutes found inside ALCO packets with the page they were found on, and Request, Upload, and Not needed actions on a missing type. — Nine of twelve core documents in hand. The minutes were never sent on their own; VetALM found them inside the ALCO packets.

2 Read

Every figure is tied to its page.

The AI reads betas, decay rates and average lives, EVE and NII shock results, policy limits, governance dates, and back-tests out of documents that were never built to be machine-readable. Then code checks each reading against the page it cites: the quoted text must be on the page, the figure must be on the page, and a product's figure must come from a page that names the product. A reading that fails is set aside and never used.

The limits schedule comes from the board-approved policy in force, never from a limit printed on a vendor report
Excel and Word citations resolve to the real cell or paragraph; PDF citations open the page
The same documents give the same readings, and each re-run shows how far it moved

The limits schedule: each board-approved limit with its watch level, the policy's own wording, a link to the policy page, and its status. — The limits schedule, quoted as the policy writes it and linked to the page it came from.

3 Test

The workpapers a reviewer builds, already built.

The Workpapers view holds the tests performed, each with its criterion, the figures it compared, where each one came from, and a result: results measured against the board-approved limits, limit bands checked for gaps and overlaps, the limits on the model's reports checked against the policy, board figures tied to the model, model balances tied to the Call Report or the books, NII back-tested against actual results, and product assumptions checked against typical ranges. Alongside them sit a document register and an assumption inventory that flags where sources disagree.

Every exception becomes a finding
A test the evidence can't support is marked not performed, not quietly passed
All of it prints in the workpaper and the Excel register

The Workpapers view: a list of tests performed, each with its area, a one-line result, and a Pass or Exception badge. — Tests performed, with a Pass or Exception on each. The findings are the exceptions.

4 Analyze

A review program, answered with citations.

Seventy-three questions across ten areas, from governance and policy limits to assumptions, back-testing, and issue management. The AI answers each one from the engagement's documents with verbatim citations. An answer whose citations don't resolve becomes "Unable to determine" rather than a guess, and a No or Partial raises a finding.

Your firm's question bank, tailored per institution: reword, retune, suppress, or add
Reviewers override any answer, and a re-run never replaces a reviewer's answer
A consistency check flags answers that contradict each other

The Analysis view: review program questions grouped by area, each with its answer, a note explaining it, and its citations. — Every question answered from the documents, with the citations behind it.

5 Review

Decide each finding beside the page it cites.

Seventeen deterministic rules run against the workpapers. The AI reads the whole document set three times and keeps only what a majority of reads agree on. Analysis exceptions join them. Each finding is written the way a reviewer writes one, with the condition, the criterion it was measured against, why it matters, and a recommendation, from facts the workpapers already settled. A gate in code refuses any figure, limit, or document that isn't in those facts. Then the finding lands on the review desk: the open queue on one side, the finding with its evidence and source check in the middle, and the cited page beside it with the cited line highlighted.

PDF pages, spreadsheet cells, and Word paragraphs, each opened at the cited spot
Accept, override the title, class, or severity, or dismiss, all from the keyboard
Every finding has passed the source check before it reaches the desk

The All findings view: a source check summary, decision and severity filters, and a limit breach finding with what it was measured against, why it matters, and a recommendation. — A limit breach, measured against the board-approved policy and against the policy in force at each prior quarter.

6 Sign off & deliver

Workpapers, not a transcript.

Sign-off has its own checklist: every finding decided, every program answer confirmed, the outputs generated, and no document still being read. Signing locks the engagement and seals its audit trail. The deliverables come in Word, PDF, and Excel: an executive summary, the workpaper, and an issues register. The workpaper carries the findings, the tests performed, the limits schedule, and the analysis exceptions, with the full program and the document register as appendices. The AI drafts the prose; the approved record supplies every number in it.

Only reviewer-approved findings reach the deliverables
A final check corrects figures that contradict the model's own report, and stops the report on anything it can't fix
After sign-off, documents, readings, and findings are read-only

The Sign-off view: a checklist confirming every finding has a decision, every question has a confirmed answer, outputs are generated, and no documents are still being read, beside a Sign off and finalize button. — Each stage on the left is worked out from what the engagement already holds. Sign-off waits until every item is in place.

Source check

Every finding is checked against its pages before you see it.

The risk with AI in a review is a confident sentence the documents don't support. VetALM doesn't leave your reviewers to catch those. It checks for them.

A second read, against the source.

After a finding is written, a reasoning model reads it alongside the pages it cites, the document register, and the limits schedule, and it can search every stored page of the engagement. Each claim in the finding is tested. A finding that holds stands. One with a wrong figure is corrected from the source and checked again. One whose conclusion doesn't hold is withdrawn, with its reasons, for a reviewer to confirm.

A figure that can't be found on the page fails; it is never assumed
The model's own report governs over a summary that restates it
Earlier policy versions govern earlier dates
Every correction shows the source quote it came from

A finding withdrawn by the source check, followed by each claim that failed and the page quote that contradicts it. — A finding the source check withdrew: the two reports it called inconsistent were different rate scenarios. Each reason cites its page.

How it works

One auditable pipeline, with a person in the middle of it.

AI does the classifying, the reading, the answering, the drafting, and the checking. Human-in-the-loop isn't a setting on top of that; it is a hard control. The pipeline will not produce a deliverable while any finding is still waiting on a reviewer.

1Request

2Collect & read

3Tie out & test

4Answer the program

5Detect

6Source check

7Human review

8Sign-off

9Deliver

Documents are immutable

Every upload is hashed and stored as received, so the original is always recoverable. An unchanged file keeps its reading, which is what makes re-runs repeatable.

Roles are enforced server-side

Firm administrator, engagement lead, senior reviewer, reviewer, and read-only, plus institution roles that can respond but never approve. Who may approve a finding or sign off is a capability check, not a hidden button.

The trail is append-only

Every action is recorded with an actor, a timestamp, and before/after hashes. Entries are never edited, so tampering is detectable.

The audit trail screen: a table of timestamped actions with the entity acted on and before and after content hashes. — Every approval, run, and generated output, with before and after hashes. Sign-off seals it.

Detection engine

Seventeen rules, an AI read, and a check on both.

Deterministic rules run first against the workpapers: fixed comparison logic, thresholds taken from the institution's own board-approved policy rather than hard-coded into the product, and a plain explanation attached to every hit. The AI then reads the whole document set for what no rule anticipates, and keeps only the findings a majority of its reads agree on. Every finding, from either source, goes through the source check.

Check	What it catches	Type	Default severity
Policy limit breach`R-LIMIT-BREACH`	A shock result more adverse than the board-approved limit, or a shock report printing the vendor's benchmark in place of the board's limit.	Deterministic	High
Investment duration breach`R-DURATION-LIMIT`	Investment portfolio duration longer than the policy maximum.	Deterministic	High
Inconsistent governance reporting`R-BOARD-INCONSIST`	A figure reported to ALCO or the board that doesn't match the corresponding model output.	Hybrid	High
Unsupported override`R-OVERRIDE-UNSUP`	A model input set to an override value with no documented rationale behind it.	Deterministic	High
Stale governance review`R-STALE-REVIEW`	A policy approval, deposit study, or prior validation past its required refresh cadence.	Deterministic	High
Balances don't tie`R-BALANCE-RECON`	Model balances that differ from the Call Report or the books by more than materiality.	Deterministic	High
Inconsistent limit bands`R-LIMIT-BANDS`	Policy limit bands that overlap or leave gaps between them.	Deterministic	Medium
Repeat finding`R-REPEAT-FINDING`	A prior validation, exam, or audit finding that the current evidence shows is still open.	Hybrid	Medium
Missing assumption support`R-MISSING-SUPPORT`	An assumption with no source reference or supporting evidence behind it.	Hybrid	Medium
Independent back-test`R-INDEPENDENT-BACKTEST`	Projected NII that misses actual results past tolerance, tested by VetALM over the same twelve months.	Deterministic	Medium
Missing back-testing`R-MISSING-BACKTEST`	A metric or period with no back-testing evidence supplied at all.	Deterministic	Medium
Unexplained back-test variance`R-BACKTEST-VAR`	A back-test variance beyond the stated tolerance with no explanation recorded.	Deterministic	Medium
Limit monitoring control gap`R-LIMIT-MODULE-OFF`	Policy limits that are not actually loaded into or monitored by the model.	Deterministic	Medium
Missing expected content`R-MISSING-EXPECTED`	An expected document or key assumption absent from what was collected.	Deterministic	Medium
Assumption outside typical range`R-ASSUMPTION-RANGE`	A product's beta, decay, average life, or prepayment speed outside typical reference ranges.	Deterministic	Low
Balance classification`R-BALANCE-CLASS`	A balance the model files under a different category than the books do.	Deterministic	Low
Scenario coverage gap`R-SCENARIO-GAP`	A policy-required shock scenario missing from the shock report.	Deterministic	Low

Each rule is independently testable and explainable. Where a rule is marked hybrid, the AI supplies the reading and the rule supplies the comparison, so the conclusion stays checkable even though the evidence came out of prose. Severity can rise with the size of the exception.

Challenger model · uncalibrated

A rough benchmark, kept on the workbench.

A full model validation compares the model with an independent alternative. VetALM's challenger isn't that yet. It is uncalibrated, so a variance is a prompt to look closer, not a test result. It raises no findings and stays out of the report.

Its own model, not a reproduction.

The challenger builds the balance sheet from the Call Report and the model's key-assumption register, projects monthly cash flows, and produces economic value of equity and twelve-month net interest income across the parallel-shock set. It sets them beside one current, verified run of the institution's model, never a stress test. The model is ordinary financial mathematics, and it computes the same answer every time. It is not yet tuned to the institution's own base case, which is why its variances stay on the workbench.

EVE discounted on the shocked curve; deposit rates follow the shock by their beta
NII on a static balance sheet, so repricing risk is isolated from growth assumptions
Adjust balances, the curve, and assumptions to see which one drives a variance
Every position says where its figures came from

7Parallel shock scenarios, -300 to +400 bps

EVE + NIIBoth metrics compared per scenario

±5 ptsVariances past this are highlighted

The challenger model workbench: challenger EVE by rate shock beside the institution's reported change, with large variances highlighted. — Challenger and reported results side by side, with variances past five points highlighted for a reviewer to investigate.

Security, privacy & compliance

Built for the people who audit software like this.

Model documentation is confidential, and your clients will ask how it's handled. VetALM holds itself to the model-risk controls it helps you check.

Strict tenant isolation

Every business record carries its firm, and every query is scoped in the service layer. Institution users see only their own requests and the findings released to them.

Encrypted in transit and at rest

TLS on every connection. The database and file storage are encrypted at rest, and files are served only through authenticated, permission-checked routes.

No training on your documents

Document content is processed by Anthropic's Claude models through the commercial API, whose terms exclude customer content from model training.

Immutable audit trail

Append-only, attributable, time-stamped, and carrying before and after hashes. It is sealed when the engagement is signed off.

Sign-off is a hard control

No deliverable is generated while a finding is still a draft, and no engagement is finalized without an authorized reviewer's sign-off.

No consumer data, by design

VetALM reviews model documentation, not customer records. Role capability checks are enforced server-side.

Regulatory references are advisory mappings to assist reviewers. VetALM does not render legal or regulatory opinions.

Results

Less time transcribing. More time deciding.

40–80h → 10–25hTarget review effort per engagement

100%Recall of seeded issues on the golden dataset

0False positives on the clean control

100%Findings traceable to source evidence

Detection is scored against a golden dataset of seeded issues before every release, alongside regression checks on the workpapers, the source check, and the report gate. The build fails if recall drops below 90% or the clean control produces more than one false positive, so these numbers cannot silently regress.

Questions

The ones that come up first.

Is VetALM a model validation?

Not on its own. A full model validation also tests the model against the institution's data: input data reconciled and sampled at the account level, assumptions measured from the institution's own history, a calibrated benchmark, and sensitivity testing. VetALM doesn't do those today. What it does is the IRR program review: governance, limits, documentation, reporting, and outcomes, with its own checks on balances and NII. On a validation engagement it does that half, so your analysts can spend their time on the other. The scope section draws the line in full.

Does VetALM replace the reviewer?

No, and it's built so it can't. The AI does the evidence pass: reading, testing, answering the program, and drafting. A reviewer can override any answer, and every finding waits for a qualified reviewer to accept or dismiss it. No deliverable is generated while any finding is still undecided. The judgment, the conclusion, and the signature stay with a person.

Do you re-run the institution's ALM model?

No. VetALM relies on the outputs the institution reports and the vendor's certification, and runs its own tests on them: results against the board-approved limits, board figures against the model, balances against the Call Report, and its own back-test of NII. Its challenger model runs from the institution's figures in a workbench, but it is uncalibrated, so it raises no findings and stays out of the report.

What if a document is a scan, or the format is unusual?

Digital PDFs are read with their column layout kept, so tables stay readable. Scanned pages are read by the AI from the page image. Excel and Word are parsed so that citations resolve to a real cell or paragraph rather than an approximate guess. Wherever a page has text, every reading is checked against it, and a reading that doesn't tie out is set aside rather than used.

Can we use our own review program?

Yes. Your firm keeps its own question bank, and each institution can have questions reworded, retuned, suppressed, or added. Rule thresholds come from the institution's own board-approved policy rather than being fixed in the product.

How does the institution take part?

Through its own portal. It sees the document request with due dates, uploads a whole folder at once, and, if you choose, responds to the findings you release with support and comments. It can never change a finding's status, severity, or evidence, and nothing it sends enters the engagement until your reviewer accepts it.

What happens to our clients' documents?

They're encrypted at rest, scoped to your firm, and served only through permission-checked routes. Document content is processed by Anthropic's Claude through its commercial API, under terms that exclude it from model training. See Security for the full posture.

How do we get started?

A demo on a sample dataset takes about thirty minutes, and shows the whole path from document request to signed workpaper. If it looks right, the next step is a pilot on one of your own engagements.

See it run on a real review.

We'll walk through a complete engagement on a sample dataset: the document request, the workpapers, the review program, and every finding decided beside the page it came from. Then we'll talk about your documents.

30-minute guided walkthrough, no slideware
Tailored to the documents you actually receive
Works from the documents you already have, with no connection to the model or core

The ALM model audit, with the evidence work already done.