At some point in nearly every credit union AI conversation, somebody says the phrase “model risk management” and the room goes quiet. The project pauses. A working group forms. Six weeks later the working group reports back that the credit union needs a model risk framework before anything can deploy, and the framework it has in mind was designed for a bank forty times your size.

We have watched this sequence stall more pilots than any regulator ever has. The frustrating part is that the working group is half right. Model risk deserves attention before an AI tool touches member decisions. Where things go wrong is the borrowed yardstick, so below is the history of where the expectation comes from, followed by the file we would build at a $250M to $5B credit union: a two-page memo plus attachments, most of it documenting checks your team would run anyway.

Where the expectation comes from, and where it does not

The term traces to SR 11-7, the Federal Reserve’s guidance on model risk management, issued in April 2011 for the banking organizations the Fed supervises. The OCC issued the same text as its own bulletin, and the FDIC later adopted it. It is a serious document with sensible ideas, and it was written for institutions running portfolios of internally built models with dedicated quantitative staff.

NCUA never adopted it. We made this point in our read of NCUA’s published AI expectations and it bears repeating because the claim keeps showing up in vendor decks and consultant proposals: citing SR 11-7 as an NCUA requirement is inaccurate. Credit unions are not directly bound by it.

What NCUA has published is narrower and more useful. The agency’s AI resource page names managing model risk as one of the challenges that comes with AI vendor relationships, alongside algorithmic transparency, fair lending, and data privacy. For frameworks, the page points to NIST’s AI resources and the COSO paper on AI and enterprise risk management as materials that “may help” credit unions, which is reference-shelf language, and nothing on the page converts either document into a requirement. NCUA’s supervision FAQ says examiners evaluate the same five things they evaluate for any technology: safety and soundness, legal compliance, internal controls, ongoing monitoring, and third-party due diligence.

That framing is your design brief. Examiners will not ask to see your SR 11-7 program. They will ask how you evaluated the tool, what controls sit around it, and how you know it still works. Proportionate model risk management is simply the organized answer to those questions for tools that produce predictions or generated content instead of deterministic output.

Size the effort to the decision, not the technology

The mistake in most borrowed frameworks is scaling effort to the sophistication of the technology. A large language model sounds exotic, so it gets the heavy process. The right scaling variable is what the tool decides.

Three tiers cover nearly every AI deployment we see at credit unions.

Tier 1: tools that decide or recommend decisions about members’ money. Credit decisioning, fraud holds, collections prioritization, anything that changes what a member can do or pay. Wrong output here harms a member directly and creates fair lending exposure. This tier gets the full treatment.

Tier 2: tools that touch member data with a human approving the output. Document processing, call summarization, dispute intake, member-facing chat with escalation paths. The human checkpoint is the primary control, so the work centers on proving that checkpoint functions.

Tier 3: internal tools that never touch member data. Drafting, meeting notes, policy search. A usage policy and periodic spot checks. We have watched committees debate validation studies for note-taking tools, and the debate reliably costs more than the tool.

Most institutions we talk to have zero or one Tier 1 system, a few Tier 2 systems, and a spreading population of Tier 3 tools they have not inventoried. Which brings us to the file.

The five artifacts

1. The inventory. One page. Every AI tool in use: vendor, underlying model provider, workflow, member data touched, tier. Include the AI features your core, LOS, and fraud platforms switched on without a separate contract, because that is the first exam question most institutions fail. Assign each line a tier and the rest of the file follows.

2. Validation, proportional to tier. Tier 1 gets the heavy lift: collect the vendor’s own validation evidence, run outcome testing against a sample of your historical decisions before cutover, get performance figures from institutions your size on your core, and complete a fair lending analysis for anything in the lending path.

A structured pilot already produces the Tier 2 evidence, since the parallel run compares human output against tool output over several weeks and yields agreement rates by category; production then needs only a written sampling regime. Tier 3 is covered by the usage policy. Banks staff an independent validation department for this step. You are assembling paperwork the pilot generated on its own.

3. Vendor documentation. The due diligence file for a Tier 1 or Tier 2 vendor should contain, in writing: what the system does and what data trained it, whether your member data trains anyone’s models, who the underlying provider is, advance notice of material changes, and ongoing performance reporting. The change notification clause matters more than it looks, because a vendor can swap or retune what runs under the hood and silently shift your risk profile. Contractual notice beats discovering the shift in your monitoring numbers. Our AI vendor contract guide covers the negotiating detail.

4. Monitoring with a cadence and an owner. Four numbers per tool: volume, override rate, error rate, cycle time. Monthly review for Tier 1, quarterly for Tier 2. The absolute readings matter less than the trend, because the thing you are watching for is drift: the slow divergence between what the model was validated on and what your members are actually doing. An override log that staff keep current is the single best drift detector available at this scale, and it doubles as your most persuasive exam artifact.

5. The memo that ties it together. Two pages, signed by the accountable owner: the tiering scheme, the inventory, validation performed per tool, the monitoring cadence, and escalation triggers (an override rate above X, an error class affecting members, a vendor model change). This is the proportionate model risk memo that belongs in the examiner file from our exam readiness checklist. Board visibility is a short standing agenda item where the inventory and the latest monitoring numbers get presented. A separately ratified model risk policy is optional; minutes showing the oversight happened are not.

Total build effort for an institution with one or two live tools: figure a few working days spread across the owner, compliance, and the vendor’s responsiveness. Not a quarter, and not a consulting engagement, unless the vendor file fights back.

What the big-bank playbook includes that you can skip

Worth being explicit, because over-restriction blocks more credit union AI than examiners do.

You do not need an independent model validation unit, or external quantitative validation of a vendor tool that operates behind human review. Annual revalidation of every system on a fixed clock is also skippable; revalidate when the monitoring trend breaks or the vendor ships a material change. The same goes for a standing model risk committee, since a recurring item at your existing risk or ops committee covers governance. And documentation written to the standard of a capital model is wasted effort, because nothing in your Tier 2 document-routing workflow is a capital model.

Two honest exceptions. If you build an in-house model that makes credit decisions, you have crossed into territory where borrowing heavily from SR 11-7 is prudent, because materiality went up and vendor evidence went away. And if your credit union is approaching $10 billion, CFPB supervision and larger-institution expectations start applying regardless of what this article says about proportionality.

The exam conversation this file wins

Picture the exchange. The examiner asks what AI is in use, and you produce the inventory. Asked how you know the lending tool is fair, you hand over the outcome testing and the fair lending analysis. The performance question gets three quarters of monitoring readings and the escalation triggers, and the board oversight question gets the minutes.

That exchange takes twenty minutes and ends the topic. The institutions that struggle in it were rarely missing a framework with the right name; they were missing an answer to the inventory question, and once that answer is a shrug, every subsequent question lands harder.

More on the compliance-safe adoption path lives in the NCUA and compliance pillar.

If you want a second set of eyes on your tiering, your vendor files, or the memo itself before your next exam cycle, Advisor Labs runs a 45-minute AI readiness audit: book a conversation.

Get one substantive analysis like this every Tuesday: subscribe to the AiForCU newsletter.