Somewhere in your shop there is a binder, or a folder on a shared drive, that did not exist in 2025. It lists every piece of software that reads, scores or drafts anything on a loan, and both agencies now expect to be able to ask for it. This note is about what goes in it, section by section, and what a vendor has to give you so that its row is complete.
- What the two documents say
- The inventory
- Roles and escalation
- Validation on your own files
- Monitoring and the audit log
What the two documents say
Freddie Mac added Section 1302.8 to the Single Family Seller/Servicer Guide with effect from March 3, 2026. In plain terms it asks each Seller/Servicer for an auditable governance program for artificial intelligence and machine learning: an enterprise wide inventory of AI and ML tools that includes third party vendor solutions, documented roles and escalation paths, risk controls for performance, security and bias, a monitoring and audit cadence, and alignment to a recognized framework such as NIST or ISO 27001.
Fannie Mae's Lender Letter LL-2026-04 set out its own governance framework for AI and ML in origination and servicing, with a compliance date of August 6, 2026. The two are written differently and land in the same place. Know what you are running. Know who owns it. Prove it works on your loans. Watch it. Keep the record.
The inventory
One row per tool. The vendor, the product, the version, the date it went live. What it touches: which documents it reads, which figures it calculates, which loans it runs on (every conventional file, FHA only, above a certain loan amount). Whether its output reaches a person before it reaches anything else.
Financing Bot's row, for example, reads: reads the uploaded loan file, recalculates income, sources deposits, reconciles AUS findings, drafts conditions, delivers a package to a named underwriter, decides nothing.
Most shops find the inventory has more rows than they expected. The OCR inside the document system counts. The fraud score inside the LOS counts. If a vendor cannot tell you whether a feature uses a model, that row stays open until they can, and an open row is itself a finding worth having on paper.
Roles and escalation
Each row needs three names, or three titles that resolve to names on the day someone asks. Who is allowed to turn the tool on for a loan type. Who reviews its output as part of their job (here, the underwriter of record). Who is called when the output is wrong, and what they are allowed to do about it: pause the tool, roll back a version, pull the affected files. Write the escalation as steps with a phone number at the end of each one. A path that ends at "contact the vendor" is not a path.
Validation on your own files
A vendor's accuracy figure was measured on the vendor's files. Both agencies want to know how the tool performs on yours, and the only way to know is to run it on loans you have already funded and compare its output with what your underwriter signed. That comparison is the validation record: recalculated income beside signed income by income type, sourced deposits beside the ones your underwriter accepted, drafted conditions beside the ones you actually placed, the page cite on both sides, and every difference explained in a sentence.
This is why the $0 Pilot Order exists in the form it does. Fifty funded files, the same process a paid file receives, and a variance and defect report at the end that is written to be filed in this section of the binder. After that, the monthly variance report on the 500 File Pack and the Enterprise Block keeps the section current without anyone building a spreadsheet.
Monitoring and the audit log
Monitoring is a cadence you can show: monthly variance, a quarterly review of what changed in the tool and what changed in the variance, an annual model review. The evidence behind the cadence is the audit log. On the Enterprise Block every read, calculation, edit, routing and signature event is logged with the user, the timestamp and the before and after values, exportable as CSV. That file answers the question a reviewer will actually ask, which is never "does the tool work" and always "on this loan, what did the tool say, what did the underwriter change, and who signed."
What the vendor's documentation pack has to contain
Your inventory row is only as complete as what the vendor handed you. Ask for a documentation pack with, at the least, a system description in plain language (what goes in, what comes out, what it does not do), a data handling statement (where files are stored, for how long, who can see them, how deletion works), validation results on your own files rather than a benchmark, a change log with dates and a description of each change to the rules or the models, and a stated cadence for updating the pack. Financing Bot's pack, on the Enterprise Block, is updated each quarter and is written to be dropped into the inventory as it stands.
| index | the pack contains |
|---|---|
| 01 | a system description in plain language (what goes in, what comes out, what it does not do) |
| 02 | a data handling statement (where files are stored, for how long, who can see them, how deletion works) |
| 03 | validation results on your own files rather than a benchmark |
| 04 | a change log with dates and a description of each change to the rules or the models |
| 05 | a stated cadence for updating the pack |
What the binder does not do
It does not move risk. The representation and warranty relief the agencies offer attaches to data verified through their own programs and to findings from their own models, DU and LPA. It does not attach to a vendor's tool, and it does not attach to this one. A lender that uses Financing Bot keeps its reps and warranties whole, keeps its adverse action duties under Regulation B, and keeps a named underwriter's signature on every decision.
The governance file exists to prove that last fact to anyone who asks, on any loan, at any time. That is a reasonable thing to be asked for. It should be a quick thing to produce.