The following scenario is a composite illustration drawn from common patterns in AI governance readiness gaps, not a report of any specific institution. In early 2026, the chief risk officer of a mid-sized community bank sat across from her model-risk team, holding a printed copy of OCC Bulletin 2026-13, and said something that stopped the meeting cold: "We read it. We understood it. We even wrote a two-page summary for the board. But I could not tell you today whether we are actually operating inside it." The bank had purchased an AI pre-scoring tool from a fintech vendor in late 2024. The vendor had provided a performance certification, an explainability module, and a contract. The compliance team had run a fair-lending screen. But nobody had built a program around the bulletin's requirements. There was no model inventory entry with a risk rating. There was no validation file documenting how the bulletin's expanded model definition had been applied. There was no scheduled cycle for fair-lending monitoring or board reporting. The institution had read OCC Bulletin 2026-13 (the April 2026 interagency model-risk guidance issued by the OCC, or Office of the Comptroller of the Currency, the Federal Reserve, and the FDIC, which superseded OCC Bulletin 2011-12 and explicitly pulled AI and generative AI under model-risk, fair-lending, third-party, and board-governance expectations) as a rule. What it had not done was turn the rule into a running program. This lesson is the bridge: the operating model, the cadence, the roles, and the artifacts that convert "we read the bulletin" into "we operate inside it every day."

From Bulletin to Program: The Translation Problem

Regulatory guidance arrives as a document. It describes obligations, expectations, and standards. It does not arrive with a project plan, a RACI (responsible, accountable, consulted, informed) matrix, a calendar of activities, or a list of artifacts to produce. The institution's job is to translate the document into operations, and that translation is where most compliance programs stall. The gap between "we are aware of the requirement" and "we operate in compliance with the requirement" is a gap of design, ownership, and cadence.

For OCC Bulletin 2026-13, the translation problem has several layers. The bulletin is interagency guidance, meaning the OCC, the Federal Reserve, and the FDIC all issued it in coordinated form. For nationally chartered banks, the OCC is the primary issuer. The bulletin superseded OCC Bulletin 2011-12, which had governed model risk management (MRM, the institutional discipline of identifying, measuring, monitoring, and controlling the risks that arise from the use of quantitative models and AI systems) for fifteen years. The update is not cosmetic. It expands the model definition to include AI and machine learning systems and large language models (LLMs, large-scale generative AI systems trained on text), makes fair-lending risk a formal dimension of model risk, establishes new expectations for third-party and vendor AI, and places board oversight of AI squarely in the governance expectations for senior management.

Translating these provisions into a running program requires answering five operational questions:

• What is in scope? Which AI systems at the institution meet the bulletin's expanded model definition and must be governed under the program?
• Who owns what? Which roles are accountable for model development, independent validation, fair-lending testing, and board reporting?
• What must be produced? Which documents, reports, and records constitute the program's evidence base?
• When must it happen? What is the cadence for validation, monitoring, testing, and reporting?
• What triggers an out-of-cycle action? Which events require an unscheduled response: model changes, performance alerts, examination requests, or incident escalations?

Each of these questions has a bulletin-grounded answer, and the program design must connect the answer to an institutional owner, a calendar date, and a document template. The sections below build that connection.

Defining Scope: The AI Model Inventory

No governance program can operate without a defined scope, and in the MRM context, the scope is the model inventory. The model inventory is the institution's register of every model, including AI and GenAI systems, that it uses in any function with business, financial, regulatory, or compliance consequences. OCC Bulletin 2026-13 requires that the inventory be comprehensive, maintained, and risk-rated.

The first operational act in building a 2026-13 program is scoping the inventory by applying the bulletin's expanded model definition to every AI system the institution uses. The definition covers any AI-driven approach, including machine learning models, LLMs, and generative AI systems, that is used to support decisions or produce outputs with material consequences. This definition is deliberately broad, and its breadth is intentional: the bulletin's drafters knew that some institutions had argued that GenAI tools were not "models" under the 2011-12 definition. The 2026-13 language closes that argument.

A practical scope exercise for the inventory starts with the institution's list of AI tools and asks four questions for each:

Does this tool produce an output that influences a credit, compliance, or risk decision? A pre-scoring model that assigns a risk band to a mortgage application clearly qualifies. A generative AI tool that drafts an adverse-action notice, which under ECOA (Equal Credit Opportunity Act) and Regulation B (Reg B, 12 CFR Part 1002, the CFPB's implementing regulation for ECOA, requiring specific and accurate adverse-action reasons) must state specific and accurate reasons, qualifies. A GenAI tool that summarizes Suspicious Activity Reports (SARs, regulatory filings under the Bank Secrecy Act, or BSA, required when a financial institution suspects a transaction involves the proceeds of a crime) for a compliance officer's review qualifies. A general productivity AI that helps an operations analyst draft internal emails probably does not qualify, though the institution should document that conclusion.

Is this a vendor-provided tool or an internally built system? Both qualify, but the governance obligations differ. Vendor tools require additional documentation around contractual transparency, validation access, and vendor notification requirements. Internally built systems require documentation of development decisions, training data governance, and the development team's own model-risk analysis.

What is the risk rating? The inventory must assign each model a risk rating, typically High, Medium, or Low, based on the model's consequentiality (the severity of errors), complexity (how opaque the model's behavior is), and uncertainty (how well the model's performance is understood). An AI credit pre-scoring model deployed in mortgage underwriting is almost certainly a High-risk model: errors could produce discriminatory outcomes, the model's behavior may not be fully transparent, and the regulatory consequences of failure are severe. A GenAI tool that drafts internal draft credit memos for human review, with no output going directly to a borrower or a credit decision without human verification, might be a Medium-risk model. The rating drives the depth of validation and the frequency of monitoring required.

When was this model last validated, and by whom? The inventory must include validation status for each model, with the date and the name of the validator. Under the 2026-13 framework, validation must be independent of the model development function. A model validated only by its developer is not validly validated under the bulletin's framework.

The inventory is a living document, not a one-time project. New AI tools must be inventoried before deployment. Changes to existing tools trigger an inventory update. Retired tools must be formally closed out of the inventory. Assigning an inventory owner, a specific role accountable for maintaining the inventory's completeness and accuracy, is the first staffing decision in the program design.

What a Complete Inventory Entry Contains

For each AI model or GenAI system in scope, the inventory entry should document: model name and version identifier; model owner (the named individual accountable for the model's performance and documentation); vendor name and contract reference (if applicable); model purpose and the specific decisions or outputs it supports; the user population (who interacts with the model and who relies on its outputs); risk rating with the rationale; validation status and date; fair-lending testing status and date (including LDA, or less-discriminatory alternative, documentation status, meaning the documented search for a model configuration that achieves equivalent credit-risk prediction with less disparate impact on protected classes); third-party management status; open findings and remediation timeline; and the date of the next scheduled review.

This entry structure serves a dual purpose: it is the institution's internal governance record, and it is the document an examiner will ask to see in the first hour of an AI-related model-risk examination. Building the inventory entry to answer examination questions before they are asked is not bureaucratic excess; it is the operating discipline that separates a defensible program from a reactive one.

Roles and Ownership: The MRM RACI

A model-risk program without explicit role assignments is a compliance aspiration, not an operating program. OCC Bulletin 2026-13 establishes expectations for board oversight, senior management accountability, independent validation, and model ownership. Translating those expectations into named roles and clear accountabilities is the second design task.

The core roles in a 2026-13 compliant MRM program are:

Model Owner. The model owner is the business-line leader accountable for a specific AI model's purpose, performance, and governance. In a lending context, the model owner is typically the head of lending, the chief lending officer, or a designated manager in the origination or underwriting function. The model owner is responsible for ensuring the model is used as intended, that performance monitoring is conducted on the agreed cadence, and that findings from validation or monitoring are escalated appropriately. The model owner is the person who signs the model's risk documentation and who answers for the model's outcomes if an examiner asks.

Model Developer (or Vendor Relationship Owner). For internally built models, the model developer is the team or individual that built the model and is responsible for maintaining its technical documentation. For vendor-provided models, the vendor relationship owner is the internal role accountable for managing the vendor contract, ensuring contractual notification requirements are in place, and serving as the interface between the institution and the vendor when the institution's validation team needs access to model information. The 2026-13 framework makes clear that the institution's model-risk obligations do not transfer to the vendor: the institution must be able to produce model-risk documentation even for vendor models where it does not have access to the model's internal architecture.

Independent Model Validator. The independent validator must be organizationally separate from the model development function. This is a hard requirement of the bulletin, not a recommendation. For community banks without a dedicated model validation team, independent validation may be performed by a qualified internal group (such as internal audit with appropriate technical expertise) or by an external third-party validator. The validator conducts conceptual soundness review, testing of model inputs and outputs, benchmarking against alternative approaches, and fair-lending testing that includes disparate impact analysis and LDA documentation review.

Fair-Lending Officer (with MRM Integration). Under the 2026-13 framework, fair-lending testing is not solely a compliance function's responsibility. It is an element of model-risk governance. The fair-lending officer, or a designated fair-lending analyst, must be embedded in the MRM workflow so that disparate-impact testing results and LDA documentation are routed through the model-risk governance structure, not maintained only in a separate compliance file. The institution needs a defined process for how fair-lending findings move from the fair-lending team's analysis into the model-risk record and the board reporting cycle.

Board and Senior Management. The 2026-13 bulletin requires the board to approve the institution's model-risk management policy, including its treatment of AI and GenAI, and to receive periodic reporting on the AI model inventory, model performance, validation findings, and fair-lending monitoring results. Senior management is responsible for establishing the institutional risk appetite for model risk and for ensuring that model accountability structures are in place. A board that approves AI deployment without an approved model-risk policy, without a model inventory briefing, and without a scheduled reporting cycle is not meeting the bulletin's governance expectations.

The RACI for the program's core activities maps these roles to each major process: inventory maintenance, model deployment review, independent validation, ongoing performance monitoring, fair-lending testing and LDA documentation, board reporting, vendor management, and incident response. Each process needs a single accountable owner (the A in RACI), which prevents the diffusion of accountability that produces compliance gaps.

The Validation Cadence and What It Must Produce

The model validation cycle is the program's operational spine. Under OCC Bulletin 2026-13, all models must be independently validated, with the depth and frequency of validation calibrated to the model's risk rating. High-risk models, including AI credit-decisioning models used in mortgage or consumer lending, require comprehensive validation that covers conceptual soundness, data quality and governance, testing and benchmarking, ongoing monitoring design, and fair-lending analysis including LDA documentation.

The standard validation cadence for a High-risk AI credit model under the 2026-13 framework is:

Pre-deployment validation: Before any AI model goes into production in a credit-decisioning function, an independent validation must be completed. The pre-deployment validation is the most comprehensive validation in the model's lifecycle: it establishes the baseline performance benchmarks, the monitoring thresholds that will trigger alerts, the fair-lending testing results and LDA conclusion, and the model's risk rating. The validation report from this stage becomes the founding document in the model's risk file. No AI credit model should be deployed without a completed, signed pre-deployment validation report in the inventory.

Annual validation: High-risk models require at minimum annual independent validation. The annual validation updates the pre-deployment validation: it reviews changes made to the model since the last validation, tests current performance against the established benchmarks, assesses whether the monitoring program has been operating as designed, and updates the fair-lending testing with current data. The annual validation does not need to repeat the full conceptual soundness review if the model has not materially changed, but it must document why a full review was not conducted and confirm that the original conceptual soundness finding remains valid.

Event-triggered validation: Any material change to a model triggers an out-of-cycle validation requirement. Material changes include: changes to the model's feature set (adding or removing input variables); changes to model thresholds or decision boundaries; retraining on updated data (even with the same architecture, a retrained model may have different performance characteristics and a different disparate-impact profile); changes to the decision logic downstream of the model's output; and vendor-initiated model changes, which is why vendor notification requirements in the contract are a compliance control, not a negotiating point.

What the validation report must contain: The validation report for an AI credit model under 2026-13 must include: an executive summary with the validation's conclusion (satisfactory, satisfactory with conditions, or unsatisfactory); the model identification and version under review; a conceptual soundness assessment addressing whether the model's design is appropriate for its stated purpose; a testing section documenting the data used, the testing methodology, the performance metrics, and how they compare to benchmarks; a fair-lending section documenting the disparate-impact testing methodology, the results across all ECOA-protected classes, the LDA search scope, the alternatives tested, and the LDA conclusion; a monitoring assessment confirming that the ongoing monitoring program is designed to detect performance deterioration, output drift, and emerging disparate-impact concerns; findings and recommendations with assigned owners and target remediation dates; and a sign-off by the independent validator with the date.

The validation report is the document an examiner looks for when they want to understand how the institution manages the risk of a specific AI model. A validation report that is missing the fair-lending section, that does not document the LDA search, or that was produced by someone in the model development chain rather than an independent reviewer will generate a finding. The report is also the primary evidence that the institution's model-risk program is operating, not just documented. A model with a well-designed program that has not produced a current validation report has, functionally, no program.

Ongoing Monitoring: The Program's Early Warning System

Validation is periodic; monitoring is continuous. The monitoring program is the mechanism by which the institution detects, between validations, whether a model's performance is deteriorating, whether its outputs are drifting in ways that were not anticipated, and whether emerging disparate-impact concerns are developing. Under OCC Bulletin 2026-13, ongoing monitoring is a required element of the model-risk program, not an optional enhancement.

For an AI credit-decisioning model, the monitoring program should track three categories of metrics on a monthly cadence, with board-reportable quarterly summaries:

Performance metrics: The model's predictive performance against the benchmarks established in the pre-deployment validation. For a credit pre-scoring model, this typically includes the AUROC (area under the receiver operating characteristic curve, a measure of the model's ability to distinguish creditworthy from non-creditworthy applicants, with 1.0 being perfect and 0.5 being no better than random chance), score distribution stability, and the rate at which model-recommended decisions are overridden by underwriters. A material decline in AUROC from the validated baseline, or a significant increase in override rates, is an alert that the model may have drifted from its validated state and requires an out-of-cycle review.

Fair-lending monitoring metrics: Disparate impact is not a static property of a model. As the population of applicants changes, as economic conditions shift, and as the model's feature distributions evolve, the adverse-outcome rate ratio between protected and non-protected class applicants can change. The monitoring program must track adverse action rates by race, national origin, sex, and other ECOA-protected classes, the adverse-action rate ratio between the highest-disparity protected class and the control group, and any statistically significant change in those ratios from the baseline established at pre-deployment validation. An alert threshold should be defined in advance: if the adverse-action rate ratio for any protected class exceeds a specified level, an escalation to the fair-lending officer and the model owner is triggered, and an out-of-cycle LDA review may be required.

Output quality metrics (for GenAI models): For AI systems that produce text outputs, such as adverse-action notice drafters or credit memo drafting tools, the monitoring program must track the accuracy and regulatory compliance of the outputs. This means sampling a defined percentage of outputs monthly, reviewing them against the ECOA and Reg B requirements for specific and accurate reasons, and tracking the error rate. An error rate above a defined threshold triggers a review of the system prompt, the model configuration, and the human verification process. Under the 2026-13 framework, a GenAI adverse-action tool that regularly produces inaccurate or non-specific reason codes is a model with a performance problem, not a technology limitation to be tolerated.

The monitoring program should produce a monthly monitoring report for the model owner and a quarterly monitoring summary for the governance committee. The quarterly summary is the input to the board reporting cycle and is also the first document an examiner will ask for when assessing whether the monitoring program is operating as designed.

Board Reporting and the Governance Committee

OCC Bulletin 2026-13 is explicit that model risk management is a board-level governance responsibility. The board must approve the model-risk management policy, including its treatment of AI and GenAI. It must receive periodic reporting on the model inventory, model performance, validation findings, and fair-lending monitoring results. This is not a "nice to have" governance addition; it is a hard expectation that examiners will test by asking to see the board minutes and board reporting packages that show AI model risk was actually reviewed.

The governance structure that satisfies this expectation has two levels: a management-level AI model governance committee that meets regularly to review model performance, validation status, and monitoring alerts; and a board-level reporting cycle, typically quarterly, that receives a summary of the committee's work.

The management-level committee should include the chief risk officer or equivalent, the chief lending officer or head of the relevant business line, the fair-lending officer, the model risk manager or designated MRM lead, and the technology leader responsible for AI system deployment. This committee reviews and approves model inventory changes (new deployments, material changes, retirements), reviews validation findings and tracks remediation, reviews monitoring alerts and escalation decisions, and prepares the board reporting package.

The board reporting package for AI model risk should cover: the current model inventory (number of models by risk tier, number of models with current validation, number of models with open findings); a summary of validation activity in the period (validations completed, key findings, remediations approved); a fair-lending monitoring summary (disparate-impact monitoring results for each High-risk credit model, with any alerts triggered and the response taken); vendor management updates (any vendor-initiated model changes received and assessed, any contract compliance issues); and any AI-related incidents or near-misses, with the response documented.

The board package need not be technically dense. Board members are not expected to evaluate AUROC values or conduct LDA analysis. The package should translate the technical findings into business and risk language: "Model X is performing within benchmarks, with no fair-lending alerts triggered this quarter" or "Model Y's adverse-action rate ratio for Hispanic applicants increased from 1.12 to 1.31 in Q2; an out-of-cycle LDA review has been initiated; the results will be presented to the committee in July." The board's role is oversight, not analysis, and the reporting format should enable oversight rather than bury it in technical detail.

Vendor and Third-Party Obligations Under 2026-13

Many institutions operate AI credit models that are vendor-provided, not internally built. OCC Bulletin 2026-13 addresses this directly: the institution's model-risk management obligations do not transfer to the vendor. The institution remains fully accountable for the model-risk governance of any AI system it uses, regardless of whether it built the system or purchased it.

The practical implications for the operationalized program are:

Vendor contract requirements: Every contract for an AI model used in a model-risk-relevant function must include specific provisions. These include: the vendor's obligation to notify the institution of any material change to the model (change in architecture, retraining, feature set modification, output behavior change) before the change goes into effect; the vendor's obligation to provide sufficient information for the institution to conduct its independent validation, which may mean providing output samples across diverse input scenarios, performance metrics, and fairness testing results even where the vendor claims the model architecture is proprietary; and the vendor's obligation to cooperate with the institution's examiner if the examiner requests information about the vendor's model during a model-risk examination. A vendor that refuses to include these provisions in the contract is a vendor the institution should reconsider, because a model whose governance obligations the institution cannot meet is a model the institution should not use.

Validation of vendor models: For vendor AI models where the institution does not have access to the model's internal architecture, the validation must use alternative approaches. Output-based testing: run the model across a large, diverse set of test inputs and analyze the outputs for accuracy, consistency, and disparate impact. Scenario analysis: test the model's behavior on specific scenarios designed to surface failure modes. Performance monitoring against external benchmarks: compare the vendor model's performance metrics to published benchmarks for similar models. And contractual assurance: document the vendor's representations about the model's design and performance, and treat those representations as part of the model's validation evidence with the caveat that they are unverified vendor claims rather than independently validated facts.

Change management for vendor models: When a vendor provides notice of a material model change, the institution must treat that notice as triggering an event-driven validation review. The review should assess whether the change affects the model's disparate-impact profile, whether it changes the model's performance characteristics relative to the validated baseline, and whether any of the fair-lending monitoring thresholds need to be recalibrated. The review should be documented in the model's inventory entry and in the next governance committee report.

Key Takeaways

• OCC Bulletin 2026-13, issued in April 2026 as interagency guidance by the OCC, Federal Reserve, and FDIC, superseded OCC 2011-12 and explicitly pulled AI, machine learning, and generative AI under the model-risk management framework, including fair-lending, third-party, and board-governance expectations.
• The translation from bulletin to program requires answering five operational questions: what is in scope, who owns what, what must be produced, when must it happen, and what triggers an out-of-cycle action.
• The model inventory is the program's foundation: a comprehensive register of every AI and GenAI system with business, financial, regulatory, or compliance consequences, with a risk rating, validation status, and a named owner for each entry.
• Independent validation must be organizationally separate from the model development function; for High-risk AI credit models, comprehensive validation is required before deployment and at minimum annually, with event-triggered reviews for any material model change including vendor retraining.
• Ongoing monitoring must track performance metrics (including AUROC), fair-lending disparate-impact ratios by protected class, and output quality for GenAI systems, on a monthly cadence with defined alert thresholds that trigger escalation to the model owner and fair-lending officer.
• The board must approve the model-risk management policy and receive periodic reporting on the model inventory, validation findings, and fair-lending monitoring results; a management-level governance committee reviews and acts on these items between board cycles.
• The institution's model-risk obligations for vendor-provided AI do not transfer to the vendor; contracts must require notification of material model changes, sufficient information for independent validation, and examiner cooperation provisions.
• Exam readiness is not a separate project: it is the operating program executed with the awareness that the model inventory, validation reports, monitoring records, board minutes, and vendor contracts constitute the artifact trail an examiner reconstructs to determine whether the institution operates inside the bulletin or merely understands it.