Implementation Guide

How to Document AI Explainability for Credit Union Examiners

A structured approach to building AI explainability documentation that holds up under NCUA and state credit union examinations.

Explore Runtime Governance Talk to an Expert

Direct answer. Examiner-ready AI explainability documentation combines model risk management evidence (development, independent validation, ongoing monitoring), fair lending reason-code traceability required under ECOA and Regulation B, and runtime records that let the credit union reconstruct any individual AI decision on demand. No single artifact satisfies all three; the documentation package must map each AI use case to its specific regulatory obligation rather than relying on one generic template.

Three Pillars of Examiner-Ready AI Documentation

Examiners look for evidence across three complementary pillars. Documentation that covers only one or two leaves material gaps when a specific decision or model lifecycle question is raised.

Model Risk Management

Development, independent validation, and ongoing monitoring evidence in the SR 11-7 tradition.

Fair Lending Traceability

Reason-code level output for adverse action decisions under ECOA and Regulation B.

Runtime Decision Records

Logs sufficient to reconstruct a specific AI decision after the fact.

What Examiners Are Actually Assessing

Examiner-ready AI explainability documentation is not a single white paper or vendor PDF. Examiners assess whether the credit union can show governance over the model, produce compliant explanations for adverse actions, and reconstruct how a particular decision was reached. Those expectations cut across model risk management practice, fair lending rules, and operational recordkeeping.

In practice, that means the package must connect technical artifacts to regulatory obligations. A validation report without decision-level logs is incomplete. Reason codes without documented ownership and monitoring are incomplete. Examiners are testing whether the institution can defend both the system and the individual outcome.

Mapping AI Use Cases to Regulatory Obligations

Different AI use cases trigger different obligations. Lending models that influence credit decisions bring ECOA and Regulation B adverse action requirements. Fraud and account-monitoring models raise safety-and-soundness and member-impact questions. Governance programs need clear ownership, policy, and escalation paths regardless of use case.

Map each AI use case to the rules and expectations that apply before assembling evidence. That mapping drives which artifacts are mandatory, which roles must sign off, and how granular runtime records need to be. A generic template applied to every model tends to miss use-case-specific requirements examiners will ask about.

Organizing the Documentation Package Around Four Categories

A practical way to organize the package is around four categories aligned with the NIST AI Risk Management Framework: Govern, Map, Measure, and Manage. This structure helps compliance and risk teams place evidence where examiners can follow it, rather than assembling ad hoc folders before an exam.

Govern

Accountability structures, roles, and policies for AI governance, documented separately from technical model documentation.

Map

The AI system’s intended purpose, context of use, and potentially impacted members, established as a prerequisite to risk categorization.

Measure

Testing, evaluation, and evidentiary artifacts covering model performance and explainability characteristics.

Manage

Ongoing monitoring, outcomes analysis, and corrective action tied to the SR 11-7 ongoing monitoring pillar.

Runtime Traceability: The Gap Static Documentation Leaves Open

Static model documentation establishes how a system was built, validated, and approved. It does not, by itself, prove what happened when a specific member received a specific decision. Runtime traceability closes that gap: inputs, outputs, model version, and decision rationale logged with enough granularity to support after-the-fact reconstruction.

Examiners increasingly expect that capability for adverse action support and for incident or complaint review. Without runtime records, the credit union may be able to describe the model in general terms but cannot show why one decision differed from another. That is the difference between governance on paper and governance that holds up under examination.

Examiner Readiness Checklist

Use the following questions to pressure-test whether the documentation package is ready for examination review.

Can the AI system reconstruct and produce a specific, accurate reason for any individual adverse credit decision, consistent with ECOA and Regulation B?
Does the documentation include model development, independent validation, and ongoing monitoring evidence consistent with SR 11-7 style practices?
Are inputs, outputs, model version, and decision rationale logged with enough granularity to support after-the-fact reconstruction of a specific decision?
Is the documentation mapped to a recognized framework, such as the NIST AI RMF, rather than assembled ad hoc?
Is accountability for AI governance assigned to a named role and documented separately from technical model documentation?
Where a vendor AI model is used, is there a clear distinction between vendor-provided documentation and the credit union’s own validation and monitoring evidence?

Frequently Asked Questions

Is SR 11-7 legally binding on credit unions?

No. SR 11-7 is Federal Reserve and OCC guidance written for banking organizations. NCUA has not adopted it as a direct mandate, but examiners and compliance teams commonly use its three-pillar structure as a practical benchmark for organizing AI model governance evidence.

What if our AI model comes from a vendor rather than being built in-house?

Regulatory responsibility remains with the credit union regardless of who built the model. Documentation should separate vendor-provided model documentation from the credit union’s own governance, validation, and monitoring evidence, since examiners will expect to see the credit union’s independent oversight.

How often should AI explainability documentation be updated?

SR 11-7 style ongoing monitoring expectations call for continuous evidence, not a single point-in-time validation. Documentation should be updated whenever a model version changes, and monitoring records should be maintained on an ongoing basis rather than compiled only before an examination.

Build Runtime Evidence That Supports Your Documentation Package

Static model documentation establishes governance. Runtime records establish that a specific decision can be reconstructed on demand. Trussed AI provides runtime governance, audit logging, and policy enforcement for AI systems, giving compliance teams a factual basis for the decision-level evidence examiners increasingly expect.

Explore Runtime Governance