Disclosure on demand: what LL-2026-04 actually requires

What the letter says

Fannie Mae issued Lender Letter LL-2026-04 on 2026-04-08, effective 120 days from publication — 2026-08-06. To the extent a Seller/Servicer uses AI/ML in connection with origination of loans sold to or guaranteed by Fannie Mae, or servicing loans on Fannie Mae's behalf, the Seller/Servicer must comply with applicable law and the Lender Contract and must satisfy the letter's governance requirements — the same framework reaches an income-extraction model reading a purchase or refinance file destined for Fannie Mae at underwrite time and a hardship-package classifier servicing a Fannie Mae loan.

The core obligations, as the letter's analysts summarize them:

• A written, actively maintained governance framework: "policies and procedures regarding the development, implementation, use and maintenance of any AI/ML system," including measuring and managing AI/ML risks — reviewed at least annually, with a designated owner, communicated to staff, and grounded in legal and regulatory requirements.
• Vendor reach: the same governance standards apply to AI/ML used through vendors and subcontractors — outsourcing the model does not outsource the obligation.
• Disclosure on demand: Fannie Mae "reserves the right to request detailed disclosures regarding a Seller/Servicer's use of AI/ML, including the types of technologies deployed, their intended purposes, and the safeguards in place to mitigate associated risks."

Sources: Fannie Mae, Lender Letter LL-2026-04 (primary; singlefamily.fanniemae.com) · Compliance Cohort, "Fannie Mae issues guidance for AI and machine learning use in mortgage operations" (fetched and verified 2026-08-17) · Cooley Finsights, "Fannie Mae issues AI/ML governance framework for sellers and servicers" (fetched and verified 2026-08-17).

What the letter does not prescribe

LL-2026-04 does not prescribe a transaction-evidence architecture, an append-only decision chain, an exact rule-version record, a maker/checker schema, or any other specific implementation mechanism. It establishes governance and disclosure expectations. The argument that follows — that durable, action-level records make those obligations easier to answer and defend — belongs to wetink, not to the letter.

The question inside the question

"What safeguards are in place" sounds like a policy question, and the market is answering it with policy artifacts: governance binders, model inventories, readiness guides. Those satisfy the paperwork half of the obligation. But a disclosure request is really a reconstruction request: on the files where AI acted, show what it did, under which rules, with whose approval. A written framework describes how the system should behave. It cannot, by itself, show how the system behaved.

A governance framework describes the system. A record reconstructs it.

The gap shows up the day someone questions a specific decision. If the answer lives in a conventional workflow database, it is testimony: the operator states what happened, and someone could — in principle — have edited the record to agree. If the answer is an append-only, tamper-evident record, it is evidence: each judgment carries who judged, against which version of which rule, citing which page of which document, and the chain shows whether anyone touched history afterwards.

What an answer built to be checked looks like

Fannie Mae now requires covered Seller/Servicers using AI/ML to maintain governance and to be able to disclose specified information on request. The argument that action-level, attributable records make those disclosures more supportable and less dependent on reconstructing history after the request arrives belongs to wetink, not to the letter. Concretely, a record built this way has four properties:

• Attributed: the record ties every AI action to a named actor and every approval to a distinct one — separation the database enforces, not a policy someone follows. A maker physically cannot seal its own work.
• Versioned: each judgment records the exact rule version live at the moment of judgment, so "show me the rule as it read that day" has an answer.
• Anchored: each extraction cites the document and page it read from. The schema refuses an extraction that cannot say where it read.
• Recomputable: the asker can verify the record — recompute the chain, check the math — rather than trust the answerer.

wetink builds on exactly this architecture, and the claim stops at its honest boundary. No verified vendor¹ currently answers the disclosure obligation with an independently recomputable record; most answer it with governance documents. See what runs today.

Notes

What to do now that the effective date has passed

The letter has been effective since 2026-08-06. For a mortgage operation using AI today, the plain reading suggests three moves: inventory where AI/ML actually acts on files (origination and servicing both — the letter spans the pipeline); put the written framework in place if yours does not exist yet, with an owner and an annual review; and decide, before a request arrives, whether your disclosure answer will be a memo or a record. The first two are table stakes, and plenty of vendors will sell them to you. The third is an architecture decision, and it is the one this company exists for. Post-close QC is a natural place to start: the mandate already exists, and the department's output is already an evidence pack.