Model‑Evidence Demand Letters: Force Lenders & Scorers to Produce AI/Model Proofs (with Fill‑In Letters)

Introduction — Why demand model evidence now

When a lender, credit scorer, or fintech denies credit or reports an adverse action, the consumer has rights to an explanation — and those rights are increasingly interpreted to require meaningful, model‑level evidence when automated models or AI are involved. Regulators (and interagency guidance) now expect institutions to document how models reach decisions and to provide specific reasons for adverse actions rather than generic checkboxes.

This article explains the federal and state legal hooks you can use, the exact model artifacts to request (reason‑code mappings, model cards, validation and audit logs, SHAP/LIME or other attribution outputs for your file), and how to send airtight fill‑in demand letters that make it easy for a lender, scorer, or vendor to produce responsive evidence — or create a paper trail you can use with regulators or in court. We include three practical, ready‑to‑send templates: an ECOA/Regulation B adverse‑action model‑evidence demand, a state‑law UDAP/AI‑transparency demand, and a vendor/CRA data & logs request.

Note: this is informational, not legal advice. If you plan litigation or a high‑stakes enforcement action, contact an attorney experienced in consumer financial services or algorithmic‑bias litigation.

Legal foundations — the hooks you will use

There are three common legal bases to compel model evidence from lenders, scoring vendors, and furnishers:

• ECOA / Regulation B (Adverse‑action reasons): When a creditor takes adverse action, Regulation B requires a statement of specific reasons or a disclosure that you can request a statement of specific reasons within a set time frame. Regulators have warned creditors they cannot rely on boilerplate checkboxes if they do not reflect the actual principal reasons the creditor used. Use this to demand the reason‑code mapping, the specific score or decision output used, and the evidence that tied that output to your application.
• FCRA / score disclosures: If a credit score (including proprietary or vendor scores) was used to set terms or take action, federal rules require disclosure of the score, the score range, the date, the source, and the up‑to‑four key factors that adversely affected the score. That disclosure obligation provides a statutory path to ask for model‑level factor information and the mapping between the model's internal drivers and the key factors you received.
• State consumer‑protection and AI laws: Recent state AI/transparency and UDAP statutes or enforcement actions give additional leverage. Many states now require or encourage transparency for automated high‑impact decisions and allow state attorneys general or private plaintiffs to obtain documents showing how decisions were made. These laws vary by state, so cite the relevant statute or enforcement authority in your demand.

On the supervisory side, interagency model‑risk guidance expects firms to retain model documentation, validation results, and audit logs — documents that regulators view as discoverable evidence a consumer can credibly demand. That expectation strengthens your leverage when you ask for vendor validation reports, change logs, and the version of the model that processed your file.

Takeaway: Reg B/ECOA, FCRA score rules, state AI/UDAP laws, and supervisory model‑risk guidance form a stacked legal and regulatory argument to demand model evidence.

Exactly what to request — a prioritized evidence checklist

Be specific. Below is the checklist of model and decision artifacts to request (organized by priority). Tailor the list to your situation (denial, pricing, re‑reporting, or reinsertion).

1. Decision summary for my file: the actual score, decision output, date/time stamped decision, and any reason codes or key factors provided to you. (Use this first; it's the simplest demand and often the law requires it.)
2. Reason‑code mapping: a document that maps the issuer’s or bureau’s reason codes (the text you got) to the model features, thresholds, or logic that produced them (how the model turns an internal driver into the reason code you received).
3. Model identity and version: the model name, version number, release date, vendor (if any), and configuration/thresholds used for your decision. This identifies whether a proprietary or third‑party model was used.
4. Model card and specification: high‑level documentation describing inputs, outputs, training data categories (not necessarily raw PII), intended use, limitations, validation metrics, and fairness/bias assessments. Many vendors produce model cards for published models.
5. Validation & audit reports: the internal or third‑party validation report(s) used to approve the model for live use (including performance metrics, back‑tests, and fairness/disparate‑impact analyses).
6. Feature‑attribution for your decision: per‑instance explainability outputs (e.g., SHAP values, LIME explanations, counterfactuals) that show how each input influenced your score or decision for your file. If the model uses proprietary encodings, request the mapping that shows how your personal inputs were encoded.
7. Decision logs & data provenance: time‑stamped logs showing the inputs fed to the model for your application (including the specific credit report snapshot, data feed IDs, and any pre‑processing steps), and vendor audit logs showing the call that produced the decision. These are critical to verify the model actually used the data claimed.
8. Change history & governance records: release notes, retraining dates, drift/monitoring reports, and any governance or override memos that explain manual adjustments to model outputs around the time your decision was made.

Why this ordering? Start with what the law most clearly requires (score and reasons) and escalate to technical artifacts if the first responses are evasive. Many vendors will produce score, reason mappings, and a model name/version without producing raw training data; the latter may be legitimately withheld for IP reasons — but you can still insist on validation reports, mappings, and per‑instance attributions that are highly probative.

How to send demands — tactics that increase compliance and preserve leverage

Follow a deliberate process to maximize results and create an audit trail:

• Start with the simplest statutory demand. If you received an adverse action, use Regulation B/FCRA routes first (they usually require a 30‑day or similar response window and are well‑tested binding rights). Cite the exact notice and give the recipient a clear deadline (e.g., 30 days).
• Send to the right addresses. Send letters to: the creditor’s compliance/legal department, the named decision maker listed on any adverse action notice, the vendor (if the creditor used a third party), and the consumer reporting agency that supplied any score. Use certified mail (return receipt) and preserve copies of all communications.
• Be precise in scope and format. Ask for specific document types (e.g., “model card, validation report, SHAP values for my file, logs for decision ID #XXXXX”) rather than vague phrases like “all documents.” Specify acceptable delivery formats (PDF for reports, CSV for logs, redactions allowed for trade secrets but not for the mapping between your inputs and outputs).
• Preserve escalation paths. Tell the recipient you will file complaints with the CFPB and the relevant state attorney general if they fail to respond; that warning often increases compliance. The CFPB has issued circulars and guidance specifically about AI and adverse‑action notices.
• Use state law leverage when applicable. If your state has AI transparency or UDAP statutes, cite those statutes in your demand — they can permit faster disclosure or broader discovery in enforcement. Check the state AI law text before citing.
• Preserve discovery potential. If you get a partial response or an evasive refusal citing trade secrets, keep the refusal in writing — it becomes valuable evidence if you escalate to regulators or litigation. Ask that redactions be accompanied by an unredacted indexing document showing which portions were withheld and why.

Timing: Regulation B requires either the reasons in the notice or a written offer to provide the reasons on request. If you request reasons, the creditor generally must respond within 30 days. FCRA score disclosures also have timing rules for risk‑based pricing notices. Use those timelines in your letters to set expectations.

Fill‑in demand letters (copy, paste, send)

Below are three practical templates. Replace bracketed fields, sign, and send by certified mail. Keep copies and track dates.

Template A — ECOA / Regulation B Model Evidence Demand (Adverse Action)

[Date]
Certified Mail: [tracking #]
[Creditor name]
Attn: Compliance / Legal Department
[Address]

Re: Request for statement of specific reasons and model evidence under ECOA / Regulation B
Applicant: [Your full name]
Application date: [mm/dd/yyyy]
Account / application ID: [ID from notice]

Dear Compliance Officer:

I received an adverse action notice dated [date]. Pursuant to the Equal Credit Opportunity Act (15 U.S.C. §1691) and Regulation B (12 C.F.R. §1002.9), I am exercising my right to obtain a statement of the specific reasons for the adverse action and, to the extent a scoring model or automated decision model was used, the model evidence necessary to evaluate that decision.

Please provide the following information and documents within 30 calendar days of receipt of this letter:
1) The specific adverse action(s) taken and the specific reason codes supplied to me in the original notice;
2) The name, version, and vendor (if any) of any scoring or automated decision model used to evaluate my application and the date/time stamp of the decision that produced the adverse action; 
3) The score or decision output value used in my case and the score range for the model used; 
4) The mapping between the reason codes I received and the model features or thresholds (reason‑code mapping);
5) Any per‑instance feature attribution output used to generate my reason codes (for example, SHAP values, LIME results, or counterfactual explanation) or a statement that no per‑instance attribution was produced; 
6) Any validation or audit reports and governance change logs relevant to the model version that processed my application (redactions for trade secrets permitted but accompanied by an index describing withheld material);
7) The identity and contact information of any third‑party vendor that produced or operated the model.

If you decline to provide any portion of the requested materials, please provide a written explanation for each refusal, including the statute or privilege relied upon and a description of the documents withheld sufficient for me, my counsel, or a regulator to evaluate the legitimacy of the refusal.

This request is without prejudice to any other statutory rights, including under the Fair Credit Reporting Act and applicable state consumer protection laws.

Sincerely,

[Signature]
[Printed name]
[Address]
[Phone, email]

(Cite this letter in regulator complaints or in state enforcement filings. If you receive an evasive response, preserve it.)

Template B — State UDAP / AI Transparency Demand

[Date]
Certified Mail: [tracking #]
[Institution / Vendor name]
Attn: General Counsel / Privacy Officer
[Address]

Re: Model transparency request under [State statute or UDAP citation]
Consumer: [Your name]
Decision date: [mm/dd/yyyy]

Dear [Counsel / Privacy Officer]:

State law [cite exact statute, e.g., "[State] AI transparency statute, §XXX" or "Unfair or Deceptive Acts or Practices statute, §XXX"] requires transparency for automated decision systems used in high‑impact consumer decisions. I request the following records for the automated decision that affected me on [date]:

• Model card or specification for the model and version used;
• Per‑instance attribution results (e.g., SHAP / LIME, counterfactuals) for my file or an explanation why such outputs were not produced;
• Validation/ fairness/ disparate‑impact assessments performed for the deployed model version;
• Logs and evidence showing the input data (including the credit report snapshot ID) used for my decision and the timestamped call that returned the decision.

Please provide these records within [statutory or reasonable timeframe] or state the legal basis for any refusal. If you refuse in whole or part, state the statute or privilege relied upon and provide a privilege log.

Sincerely,
[Signature]

Template C — Vendor / CRA Data & Logs Request

[Date]
Certified Mail: [tracking #]
[Vendor / CRA name]
Attn: Compliance / Records
[Address]

Re: Request for logs and data provenance for decision ID [ID]
Consumer: [Your name]
Decision ID / call ID: [if known]

Dear Records Custodian:

Please provide all logs, request/response records, and data provenance for the automated decision identified above, including but not limited to:
• The input payload used (redact PII not required for mapping if necessary but preserve encoding mappings);
• The response record returned to the creditor (full JSON/XML or other structured response);
• The timestamped call record, IP or host that executed the call, and any correlation ID linking the call to the creditor's request;
• Any pre‑processing or feature engineering steps and their code or specification (redacted for IP), and an explanation of how my personal data were transformed;
• The vendor's internal decision audit or any manual override notes related to my decision.

Please produce these materials within 30 days or provide a written refusal explaining any claimed privilege.

Sincerely,
[Signature]

Practical drafting tips: (1) Attach the adverse action notice or screenshot; (2) attach a copy of your government ID and a short affidavit of identity if requested by the vendor; (3) require delivery in machine‑readable form where possible (CSV/JSON) for logs and SHAP outputs; (4) state willingness to accept redacted proprietary code but not redacted mappings between your inputs and outputs.

These templates are intentionally pragmatic. If a party refuses, keep the refusal and escalate to the CFPB, the appropriate state AG, and consider counsel for litigation. The CFPB has been explicit that generic checkboxes do not satisfy reason‑giving obligations when complex models are used.

When to escalate — regulators, state AGs, and litigation

If the creditor/vendor produces nothing meaningful or gives a boilerplate refusal, escalate in stages:

• File a CFPB complaint (include copies of the demand and any responses). The CFPB has issued circulars and guidance clarifying expectations for adverse‑action notices and algorithmic decisions.
• File a complaint with your state attorney general — if your state has AI or UDAP enforcement, the AG may open an investigation and issue a subpoena for the underlying model evidence.
• Consider small‑claims or civil action where appropriate — many state consumer protection statutes allow private suits; preserved written refusals and certified‑mail records create a strong record. Cite the state statute and attach the demand and response when you file.
• Preserve evidence for discovery: keep all emails, call records, and any information from chatbots or automated responses. If a party claims trade secrets, ask for a privilege log and a narrowly tailored protective order if the matter advances to litigation.

Regulators and examiners also view model governance and documentation as supervisory evidence — the interagency SR 26‑2 guidance (April 17, 2026) makes clear firms are expected to keep validation reports, governance logs, and monitoring records that you should be able to request or that a regulator can compel.

Final note: vendors sometimes offer a mediated or redacted production (e.g., model card + per‑instance SHAP values) to avoid exposing proprietary training data — that production can be very useful. Be pragmatic: press for per‑instance attributions, mappings, and validation evidence first; fight for raw training data only if necessary for an enforcement or litigation strategy.

If you want, I can produce customized fill‑in letters for your state (including the exact state statute citations) and a short cover email you can send to the creditor and vendor. Tell me the state and the decision date and I’ll draft them.