SAMPLE — AI Inventory and Risk Assessment

A representative mid-size mortgage lender/servicer

Prepared as an illustrative example. This is not an assessment of any actual institution. Vendor names below are the most widely adopted option in each category and are used to make the example concrete. Naming a vendor here is not a finding about that vendor, and no vendor has reviewed or endorsed this document.

How to use this document

LL-2026-04 asks a seller/servicer using AI or ML in origination or servicing to maintain policies and procedures governing that use, and — on Fannie Mae's request — to promptly disclose the types of AI/ML in use, the purpose and manner of that use, and the safeguards in place. It also requires that vendor and subcontractor AI use be governed no less protectively than the lender's own.

That is a program-level obligation. It is not satisfied by assessing one model well. It is satisfied by being able to answer, on short notice, what is running, where, who owns it, and what stops it when it goes wrong — across the whole estate.

This document is structured the way that answer has to be structured:

1. Part 1 — the estate. Every third-party category a lender of this shape uses,
the representative vendor, whether AI is present, and a risk tier.
2. Part 2 — depth where it matters. Full assessment on the systems tiered HIGH.
You do not write twenty-seven deep-dives. You tier, then you go deep on the ones that touch a credit, valuation, pricing, or loss-mitigation decision.
3. Part 3 — cross-cutting findings. The issues that are not about any one system.
4. Appendices — evidence expectations, and an optional continuous-monitoring layer.

On the limits of a template. Everything below is a starting point derived from public vendor documentation and the regulatory text. What it cannot know is your tenant configuration, which modules you actually licensed, what your underwriters override and how often, which vendor has been shaky, and what your last exam surfaced. That is the part only the institution can supply, and it is the part that makes the assessment true rather than merely complete.

Part 1 — The estate

Tiering rule used here. HIGH = the system's output enters or materially shapes a credit, pricing, valuation, eligibility, or loss-mitigation decision, or generates consumer-facing language. MEDIUM = operational impact with an indirect path to a consumer outcome. LOW = administrative, with human review standard.

Origination

Valuation and settlement

Insurance, tax, and risk

Servicing and default

Compliance and infrastructure

Estate summary

The number that matters: eleven. A lender of this shape typically believes it has "one or two AI vendors." The public announcement is usually about one of them. The estate is an order of magnitude larger, because AI arrived as a feature inside software already under contract — not as an AI purchase.

The single most common inventory gap is #20. Where servicing is subserviced, the subservicer's AI reaches your borrowers and your Fannie Mae obligations, and the letter's "no less protective" standard reaches through the contract. It is routinely omitted because nobody at the lender operates it.

Part 2 — Assessment of HIGH-tier systems

Each entry below follows the same structure: what it does, where AI sits in the decision, the regulations implicated, what to test, and what to ask the owner.

2.1 — Automated Underwriting (Desktop Underwriter, LPA, TOTAL)

Business purpose. Agency decision engines returning eligibility and documentation recommendations that drive the credit decision.

Where AI sits. In the recommendation itself. Whatever the engine's internal mechanism, the lender relies on its output to underwrite. Lender overlays and underwriting-assist models layered on top are separate systems and must be inventoried separately — this is a common omission.

Regulations implicated

• ECOA / Reg B §1002.6(a) — automated evaluation of creditworthiness is subject to the effects test
• ECOA / Reg B §1002.6(b)(1) — no prohibited basis in any system evaluating creditworthiness
• ECOA / Reg B §1002.9(b)(2) — specific and accurate reasons for adverse action
• FCRA 15 U.S.C. §1681m(a) — adverse action notice
• Fannie Mae Selling Guide B3-2 (AUS) and B3-3 (income)
• Interagency model risk management guidance, OCC Bulletin 2026-13 (April 2026), for institutions where it applies

Recommended testing

• Reconcile a sample of adverse-action reason codes against the actual drivers of the recommendation. The common failure is a notice that is technically compliant and substantively uninformative.
• Track overlay override rates by underwriter and by branch. Unexplained variance is a fair-lending signal before it is anything else.
• Confirm which engine version was in effect on the origination date for any loan under review.

Ask the system owner

1. Do we run any proprietary overlay or underwriting-assist model on top of the agency engine? Who built it, and when was it last validated?
2. When a loan is denied, can we reconstruct which inputs drove it — for that specific loan, not in general?
3. Who is notified when an agency engine version changes, and what do we do about it?

2.2 — Automated Valuation Model (Cotality)

Business purpose. Machine-learning point estimate of property value with a confidence interval, used to size loans and inform LTV.

Where AI sits. In the valuation that feeds LTV, which feeds pricing, MI, and eligibility. On many refinance products the AVM is the primary valuation evidence.

Regulations implicated

• AVM Quality Control Rule, 12 CFR 34.222 — quality-control standards for AVMs used in covered credit decisions
• ECOA / Reg B §1002.6 and the Fair Housing Act — valuation discrimination
• ECOA 15 U.S.C. §1691(e) — appraisal and valuation copy requirements
• HMDA / Reg C — property-value field accuracy

Recommended testing

• Disparate-impact testing on AVM output segmented by census-tract demographics, at least annually. This is the single most scrutinized AI test in mortgage today.
• Portfolio-level accuracy against actual sale prices, monthly.
• Confirm the cascade to human appraisal fires when the confidence interval exceeds your threshold — and that the threshold is written down somewhere other than a vendor default.

Ask the system owner

1. What is our confidence-interval threshold for cascading to a full appraisal, who set it, and when?
2. Does the AVM QC Rule reach us for this use? It reaches credit decisions and covered securitization — a correspondent purchase where we make no credit decision may not qualify. Get this answered, in writing, either way.
3. When the vendor retrains the model, how do we find out?

2.3 — Income and asset verification (The Work Number, Finicity, FormFree)

Business purpose. Automated extraction of income, employment, and asset data from payroll records, documents, and bank transactions.

Where AI sits. In the extraction and the calculation. An income figure that is wrong by a few hundred dollars a month changes DTI, which changes eligibility.

Regulations implicated

• Fannie Mae Selling Guide B3-3 — income documentation and calculation
• ECOA / Reg B §1002.6 — accuracy of the input to the credit decision
• FCRA §1681 et seq. — where the data source is a consumer reporting agency, permissible purpose and accuracy obligations attach
• GLBA Safeguards, 16 CFR 314.4 — third-party access to borrower financial data

Recommended testing

• Measure the manual-review rate on AI-calculated income before underwriting sign-off. If nobody knows the number, that is the finding.
• Sample override frequency and direction. Systematic overrides in one direction mean the model is miscalibrated for your borrower mix.
• Test extraction accuracy across document formats and income types — self-employed, variable, and multi-source income are where extraction degrades, and they correlate with borrower demographics.

Ask the system owner

1. What percentage of files have AI-calculated income accepted without a human recalculation?
2. When an underwriter overrides the calculated figure, is the override and its reason captured anywhere queryable?
3. Which of these vendors is a consumer reporting agency for our use, and does our permissible-purpose posture match?

2.4 — Loan Origination System AI (Encompass)

Business purpose. The system of record. AI features are licensed modules inside it: income calculation, smart conditions, document-prep assist, LO assistant, fraud scoring.

Where AI sits. In several places at once, which is what makes the LOS the hardest inventory line. Each module is a separate system for assessment purposes, is enabled separately, and may be enabled without compliance's knowledge.

Regulations implicated

• ECOA / Reg B §1002.6(b)(1) — no prohibited basis in condition setting
• ECOA / Reg B §1002.9 — adverse-action content where AI-drafted
• TILA / Reg Z §1026.19 — TRID timing and accuracy where document generation is automated
• UDAAP — any AI-drafted borrower-facing language
• GLBA Safeguards 16 CFR 314.4

Recommended testing

• Pull the tenant admin panel and enumerate which AI capabilities are actually switched on, per workflow and per user group. Compare against what compliance believes is on. This single exercise closes more inventory gaps than any other.
• Sample AI-drafted borrower communications for accuracy and tone.
• Confirm legal has cleared any AI-drafted adverse-action templates.

Ask the system owner

1. Which AI modules are enabled in our tenant right now, and who approved each one?
2. Does anyone review AI-drafted text before it reaches a borrower?
3. What is our notification path when the vendor ships a new AI feature turned on by default?

2.5 — Point-of-Sale agentic intake (Blend)

Business purpose. Borrower-facing application collection, increasingly agentic — conducting the interview, populating the application, clearing conditions.

Where AI sits. Between the borrower and the file. Data provenance matters: a field the borrower stated and a field the agent inferred are legally different, and if the system does not distinguish them, you cannot demonstrate the decision basis.

Regulations implicated

• ECOA / Reg B §1002.6 — the decision must rest on borrower-provided information
• UDAAP — hallucinated or misleading borrower-facing content
• TILA / Reg Z §1026.19 — application completeness drives disclosure timing; the six-piece trigger is an AI-adjacent question now
• FCRA — permissible purpose at pull
• GLBA Safeguards

Recommended testing

• Verify field-level provenance tagging exists: borrower-stated versus agent-inferred.
• Test whether an agentic flow can trip the TRID six-piece trigger without a human recognizing it.
• Review agent transcripts for guidance that reads as advice.

Ask the system owner

1. Can we show, for one specific loan, which application fields the borrower supplied and which the agent filled in?
2. What can the agent do without a human confirming it?
3. When did the foundation model behind it last change, and did anyone re-test after?

2.6 — Servicing decisioning (MSP)

Business purpose. Core, consumer, and default servicing. AI appears in delinquency prediction, loss-mitigation decisioning, payment-plan optimization, and borrower-facing assistants.

Where AI sits. In the highest-consequence decisions you make about a borrower already in distress.

Regulations implicated

• RESPA / Reg X §1024.41 — loss-mitigation evaluation and timing
• RESPA / Reg X §1024.39 and §1024.40 — early intervention, continuity of contact
• ECOA / Reg B §1002.9 — adverse action on loss-mitigation denial
• FDCPA / Reg F, where applicable
• Fannie Mae Servicing Guide D2 — delinquency management
• State foreclosure timelines and single-point-of-contact requirements

Recommended testing

• Confirm no automated step advances a loan toward foreclosure referral without human review. If one does, that is the finding, and it is urgent.
• Verify Reg X clocks are enforced independently of workflow automation — a timing rule does not pause because a queue is automated.
• Test loss-mitigation outcome distribution across demographic proxies at the portfolio level.

Ask the system owner

1. Which servicing decisions does the platform automate outright, and which does it merely recommend?
2. Are the compliance guardrails the vendor markets configured by us, or are we on defaults?
3. Can we produce, for one delinquent loan, the full decision trail including what the model contributed?

2.7 — Subservicer inherited AI (Cenlar)

Business purpose. A third party servicing your loans, using its own AI, under your Fannie Mae obligations.

Where AI sits. Outside your walls and inside your accountability. LL-2026-04 is explicit that vendor and subcontractor AI must be governed no less protectively than your own — you cannot delegate the governance along with the servicing.

Regulations implicated. Everything in 2.6, plus your servicing agreement, plus Fannie Mae's Information Security and Business Resiliency Supplement.

Recommended testing

• Obtain a written AI inventory from the subservicer. If they will not provide one, document the request and the refusal — that record is itself evidence of governance.
• Confirm your agreement's audit and information rights actually reach their AI use. Most agreements predate the question.
• Establish notification for material AI changes on their side.

Ask the vendor manager

1. Have we asked the subservicer, in writing, what AI they run on our loans?
2. Does our contract give us the right to ask, and to audit the answer?
3. If Fannie Mae asked us tomorrow what AI touches our serviced portfolio, could we answer for the subserviced book?

2.8 — Credit optimization (CreditXpert and similar)

Where AI sits. In modeling what would change a borrower's score, which shapes what the borrower is told and which product they land in.

Key regulations. ECOA / Reg B §1002.6; FCRA §1681m; UDAAP for what the borrower is told about score improvement.

Test. Whether guidance given to borrowers is consistent across similarly situated applicants, and whether any of it reads as a promise.

2.9 — Fraud and identity scoring (FraudGuard, SentiLink)

Where AI sits. In a score that can stop a loan. Fraud denials are adverse actions.

Key regulations. ECOA / Reg B §1002.9(b)(2); FCRA §1681m(a) and the Red Flags Rule; ECOA effects test.

Test. False-positive rates segmented by borrower demographics. Fraud models are among the least examined and most consequential systems in the stack, and a false positive is indistinguishable from a denial to the person receiving it.

2.10 — Borrower-facing servicing AI (IVR, chat, voice agents)

Where AI sits. Talking to your borrowers, unsupervised, at scale.

Key regulations. UDAAP; RESPA / Reg X §1024.39–§1024.41 where the conversation touches loss mitigation or triggers a request; FDCPA / Reg F; state call-recording law.

Test. Whether the assistant can receive something that legally constitutes a loss-mitigation application or a notice of error and fail to route it. That is the scenario that turns a convenience feature into a violation.

2.11 — HMDA and fair-lending analytics

Where AI sits. In the tool you use to find your own problems. A false negative here means you believe you are clean when you are not.

Key regulations. HMDA / Reg C; ECOA / Reg B §1002.6; Fair Housing Act.

Test. Validate the tool against a known-issue sample. Ask the vendor what its detection thresholds are, and whether they are tuned to minimize false positives — because a tool tuned for a quiet dashboard is worse than no tool.

Part 3 — Cross-cutting findings

1. The estate is roughly ten times what most institutions believe it is. Eleven HIGH-tier systems in a stack nobody bought "AI" for. Every one arrived as a feature inside software already under contract.

2. Vendors enable AI features by default. The most common way a lender acquires an unassessed AI system is a vendor release note. There should be exactly one person who reads those, and a defined path from release note to inventory entry.

3. ICE appears in seven categories. LOS, PPE, recording, servicing, compliance QC, and more. Concentration is not itself a finding, but it means a single vendor's AI roadmap moves a large share of your estate at once, and your vendor-management posture toward that one relationship carries disproportionate weight.

4. Adverse-action reason accuracy is the thread that ties it together. AUS, fraud, credit, valuation, income — each can contribute to a denial. Reg B asks for specific and accurate reasons. "Accurate" means reflecting what actually drove the decision. That is a systems question before it is a notice-template question.

5. Testing that exists on paper and not in a file is the most common gap. Every recommended test above should produce an artifact with a date and a name on it. Absent that, the program is a description of intentions.

6. The subserviced book is the blind spot. See 2.7.

Appendix A — Evidence an examiner will ask for

For each HIGH-tier system:

1. Inventory entry: business purpose, owner, lifecycle scope, provider type, risk tier
2. This assessment, dated and signed
3. Vendor documentation: model card or equivalent, SOC 2, data-processing terms, AI-specific contract provisions
4. Test results with dates and named performers
5. The override or exception log, where human review is claimed as a control
6. Change history: vendor model versions, feature enablement dates, who approved
7. The governance policy this all rolls up to, with evidence of annual review

Note the pattern: a claimed control that produces no artifact is not a control. Where you assert human-in-the-loop, the log demonstrating humans in that loop is the evidence, not the assertion.

Appendix B — Optional: continuous monitoring layer

This appendix is optional. The body of this assessment is complete without it.

Everything above is point-in-time. It is accurate on the date signed and begins decaying immediately — vendors ship, models retrain, features flip on.

A continuous layer addresses the decay by logging AI interactions as they happen, so that the evidence in Appendix A is a query rather than a project, and so that vendor-side changes surface when they occur rather than at the next annual review.

Institutions implementing such a layer typically want:

• An append-only record of AI system invocations with tamper-evidence
• Automated detection of vendor model-version changes
• Attestation from vendors as to their own AI governance, in a verifiable form
• Correlation across vendors, since no single vendor sees your whole estate

This is a program design question, not a compliance requirement. LL-2026-04 does not mandate any particular monitoring architecture.

Sign-off

I have reviewed this assessment. The systems identified reflect the institution's AI estate as of the assessment date. The testing described has been assigned to named owners with defined cadence. Where gaps are identified, remediation is tracked to completion.

Chief Compliance Officer: _______________________ Date: ____________

Prepared with Claude for Compliance. Regulatory citations link to verbatim text. This is an illustrative sample, not legal advice, and does not create an attorney-client relationship.