AI Explainability Documentation: How to Show Your Work to Examiners

TL;DR:

• OCC Bulletin 2011-12 and SR 11-7 are officially gone as of April 17, 2026 — replaced by OCC 2026-13 and SR 26-2, which are principles-based and explicitly exclude GenAI.
• For traditional AI and ML models: documentation requirements survive under the new framework, with more flexibility for proportionality to your institution’s size and risk.
• CFPB Circular 2023-03 still requires specific, accurate adverse action reasons regardless of model complexity — “the algorithm did it” still isn’t a valid explanation.
• Your AI explainability documentation package needs five artifacts: model card with explainability methodology, validation report with explainability testing, adverse action reason mapping, monitoring log for explanation drift, and an examiner-ready summary.

Your model risk framework just changed overnight, and your documentation is probably already outdated.

On April 17, 2026, OCC Bulletin 2011-12 and Federal Reserve SR 11-7 were jointly rescinded and replaced by OCC Bulletin 2026-13 and SR 26-2. The new guidance is principles-based. Generative AI and agentic AI are explicitly excluded from scope — separate guidance is “forthcoming in the near future.”

What didn’t change: the expectation that you can explain your models to examiners. CFPB Circular 2023-03’s adverse action requirements for AI credit decisions still stand. Examiners still walk into AI model reviews expecting a documentation package that shows how the model works, how it was validated, and how it produces results that are consistent, reproducible, and defensible.

If your explainability documentation was built around SR 11-7 prescriptions, you need to update it. If it was thin to begin with — because the old framework never specified exactly what “explainability” documentation should look like — this is your chance to build something that actually holds up.

Why Explainability Documentation Is Different from the Techniques Themselves

There’s a confusion point in how most MRM programs handle AI explainability: teams focus on implementing explainability techniques (SHAP, LIME, attention visualization), then treat that implementation as the compliance box checked.

It’s not. The techniques are the capability. The documentation is the evidence.

An examiner reviewing your AI model doesn’t care that you use SHAP — they care that:

• You documented WHY SHAP is the right method for this model type
• You tested whether SHAP explanations are accurate and stable
• You validated those explanations independently (not by the model team)
• You showed how those explanations connect to the adverse action reasons your customers receive

Understanding what regulators expect on explainability techniques is one conversation. What you’re documenting here is the governance chain that sits on top of those techniques — and that governance chain is what examiners are actually evaluating.

The Documentation Landscape After OCC 2026-13

Under OCC 2026-13 and SR 26-2, documentation requirements are principles-based:

• Documentation should “support examiner review” and demonstrate validation independence
• Practices should be “commensurate with the model’s risk profile”
• There’s no prescribed format or required section headings

That flexibility is real — but it doesn’t mean explainability documentation can be vague. Examiners now have more room to calibrate expectations to your institution’s size and complexity. What they don’t have is a reason to accept documentation that doesn’t let them understand how the model works.

For large institutions (>$30B in assets): OCC 2026-13 is your operative framework. Documentation rigor should be calibrated to the model’s risk tier — high-impact models (credit decisioning, fraud detection) warrant more rigorous explainability documentation than lower-risk models (internal reporting tools).

For community banks: The guidance applies when model risk is significant to your operations. A community bank with a handful of vendor credit scoring models has different documentation needs than one running proprietary ML for lending decisions at scale. The key phrase in OCC 2026-13: practices should be “commensurate with the bank’s risk exposures, its business activities, and the complexity and extent of its model use.”

For GenAI and agentic AI: Explicitly out of scope of OCC 2026-13. Your documentation standard for these systems should reference the NIST AI RMF and whatever AI governance policy your institution has adopted. The documentation obligation hasn’t gone away — it’s just not governed by the new MRM guidance yet.

The Five Documents in a Complete AI Explainability Package

Whether you’re under OCC 2026-13 or building GenAI governance documentation from scratch, these are the five artifacts your explainability package needs.

1. Model Card with Explainability Methodology

The model card is the intake documentation for every AI model in your inventory. For explainability, it should include:

This section tells validators and examiners what they’re walking into before they start reviewing the technical documentation.

2. Explainability Testing Section in the Validation Report

This is where most AI model documentation packages fall short. Validation reports routinely cover performance metrics — accuracy, precision, recall, AUC. They often skip explainability as an independent validation dimension entirely.

The explainability section of your validation report should document:

Accuracy testing of explanations: Does the SHAP explanation accurately reflect what’s actually driving the model output? Techniques like deletion testing (remove the top feature and verify the prediction changes as expected) and consistency checks verify this. Document the methodology and results, not just “SHAP was implemented.”

Stability testing: Do explanations change significantly for similar inputs? Unstable explanations — where small input changes flip the top factors — signal that the explanation method isn’t reliable for this model. Document the test design and acceptable instability thresholds.

Consistency with domain knowledge: Do the top factors align with what subject-matter experts say should matter? A credit model where zip code appears as the top SHAP factor may signal a proxy discrimination issue, not just an explainability problem. AI model documentation requirements cover this as part of the bias review.

Independent validation sign-off: Explainability testing must be performed and documented by independent validators — not the model developers. If the model team owns the explainability testing, that’s a governance failure, not a documentation gap.

3. Adverse Action Reason Mapping Documentation

This is the piece most directly tied to regulatory risk. CFPB Circular 2023-03 is explicit: creditors using AI models must provide specific and accurate adverse action reasons — not generic sample-form language, not “multiple factors in your credit history.”

Your adverse action documentation package should contain:

Factor-to-reason code mapping: For each model feature that can influence an adverse action, document the corresponding reason code sent to the applicant. This mapping should be specific enough that any combination of top contributing factors resolves to a specific, individualized reason.

Reason code generation methodology: How does the system translate model output into reason codes? Is it top-N SHAP features? A decision tree overlay? A rules-based converter? Document this process and validate that it produces accurate, reproducible outputs across the model’s range of decisions.

Exception handling: What happens when top factors produce ambiguous or contradictory reason codes? Document the resolution logic and any human-in-the-loop review steps.

Audit trail per adverse action: For any adverse action taken, maintain a record showing which model version was used, the top contributing factors with their values, which reason codes were generated, and when the decision was made. This is your paper trail if a consumer dispute or exam finding arises.

The CFPB’s Innovation Spotlight on AI adverse action notices remains an important reference here, even under the current CFPB’s changed enforcement posture. State attorneys general have demonstrated they’ll enforce ECOA adverse action requirements independent of federal action.

4. Explanation Drift Monitoring Log

Explainability isn’t a one-time validation activity. Model explanations can drift over time as input distributions shift — even when overall performance metrics look stable. In consumer credit models, this is common when economic conditions change the feature landscape.

Your monitoring documentation should track:

• Periodic refresh of SHAP importance rankings (monthly or quarterly, depending on model usage and risk)
• Alerts when top contributing factors shift materially from the baseline validated state
• Comparison of current explanation distributions to validation-era distributions
• Remediation actions taken when drift is detected (revalidation trigger, model retirement, documentation update)

This monitoring log is evidence that explainability isn’t just validated at deployment — it’s actively managed as a model risk dimension over the model’s operational life.

5. Examiner-Ready Explainability Summary

The four documents above are technical artifacts. Examiners walk in expecting to understand your explainability approach without spending three hours parsing validation reports. Build a single-page summary that answers:

1. What is this model doing and what decisions does it support?
2. What explainability technique is used and why is it appropriate?
3. Was the technique independently validated? What were the results?
4. How do explanations connect to adverse action notices?
5. What ongoing monitoring is in place for explanation stability?

Think of this as the model’s executive summary for regulators. It gets reviewed first. If it’s thin or evasive, examiners will dig harder into the supporting documentation.

The GenAI Documentation Gap

Here’s the documentation problem most AI risk programs haven’t resolved yet.

OCC 2026-13 and SR 26-2 explicitly exclude generative AI and agentic AI from scope. Until the agency-promised AI-specific guidance drops — which could be anywhere from 6 to 18 months out — your LLM-powered customer service tools, GenAI document review systems, and AI agents in fraud or compliance workflows have no formal MRM documentation framework.

What to do until then:

• Reference NIST AI RMF MEASURE 2.5: Document trustworthiness characteristics including transparency, explainability, and interpretability, tailored to what the system can actually provide. For LLMs, that may mean documenting prompt-level reasoning, chain-of-thought analysis, or grounding in retrieved sources — not SHAP values.
• Apply your internal AI governance policy: If your institution has adopted an AI governance policy, its documentation requirements are your current standard for GenAI.
• Tier documentation to risk: GenAI systems used in consequential decisions (credit, fraud screening, compliance determinations) warrant more rigorous explainability documentation than internal productivity tools. A GenAI tool summarizing regulatory updates for staff has different documentation needs than one generating adverse action letters.

Don’t wait for the formal guidance. When it lands, having documented explainability practices already in place is dramatically better than scrambling to retrofit.

What Examiners Actually Flag in Explainability Reviews

The GAO’s May 2025 report on AI oversight in financial services (GAO-25-107197) and common exam finding patterns point to the same deficiency categories:

Circular documentation: “The model uses SHAP to explain its outputs” — with no testing of whether those outputs are accurate, stable, or connected to adverse action notices. This is the most common gap. Implementing the technique and documenting the governance around it are not the same thing.

Developer-owned explainability testing: Validation reports where the model developers ran and documented the SHAP analysis themselves. Independent validation of explainability is just as important as independent validation of performance metrics. If the same team builds the model and validates its explanations, that’s a segregation-of-duties finding.

Generic adverse action reasons: Reason codes that apply generically to any applicant rather than the specific factors driving the individual decision. This is a direct CFPB Circular 2023-03 violation. “Too many inquiries” applied the same way to every applicant isn’t a specific reason — it’s a form letter.

No explanation monitoring: Explainability testing done at initial validation with no ongoing monitoring. Feature importance distributions shift. The explanations that were valid at deployment may be misleading 18 months later. If there’s no log showing that monitoring happened, there’s no evidence the issue was managed.

Shadow AI with no documentation: Models deployed by business units without going through the MRM process. Under OCC 2026-13’s explicit treatment of vendor and third-party model governance, “we didn’t know about it” is a harder defense than it was under the old framework. Model inventory completeness is a foundational documentation requirement, and shadow AI directly breaks it.

So What?

Your explainability documentation needs to answer one question for an examiner: can you demonstrate what this model does, how its explanations work, and how those explanations connect to what customers are told?

If your current documentation answers that question for every model in your inventory — traditional ML, vendor models, and GenAI — you’re in good shape. If it can’t, start with the highest-risk models: credit decisioning, fraud detection, BSA/AML screening. Build the five-document package described above, starting with the adverse action reason mapping if you’re a consumer lender.

The framework changed. The documentation expectations didn’t.

Looking to build an AI model risk documentation package that holds up in an exam? The AI Risk Assessment Template & Guide includes model card templates, validation documentation frameworks, and CFPB-compliant adverse action documentation guidance.

Frequently Asked Questions

What explainability documentation does OCC 2026-13 require?

OCC Bulletin 2026-13 doesn’t prescribe specific formats — it’s principles-based, requiring documentation that supports examiner review and demonstrates validation independence. For credit models, CFPB Circular 2023-03 adds specificity: lenders must generate specific, accurate adverse action reasons for each applicant.

What explainability documentation do examiners actually review?

Examiners look for four things: documentation of how explainability is achieved, evidence that explainability was independently tested during validation, adverse action documentation showing the link between model outputs and specific denial reasons, and evidence that validators independently reviewed the explainability approach — not the model developers.

How do you document adverse action reasons for AI credit models?

For each adverse action, document the top contributing factors with their actual SHAP or LIME values, how those factors translate into human-readable reasons matching the applicant’s actual data, and a mapping table showing which factor combinations trigger which reason codes. Maintain a per-decision audit trail.

Does GenAI need explainability documentation under OCC 2026-13?

GenAI and agentic AI are explicitly excluded from OCC 2026-13’s scope. Until separate AI guidance arrives, reference NIST AI RMF MEASURE 2.5 and your internal AI governance policy for documentation standards. Risk-tier your documentation requirements based on the system’s use in consequential decisions.

What’s the difference between explainability technique documentation and examiner documentation?

Explainability techniques documentation covers how you generate explanations — the mathematical approach and tool selection rationale. Examiner documentation covers what you did with those explanations — how you tested them for accuracy and stability, how they feed into adverse action notices, and how validators independently verified the approach. Examiners care more about the governance chain than the technical methodology.