FFIEC IT Examination Handbook Requirements for AI-Integrated Core Systems

No single FFIEC document tells a bank how to run an AI agent inside its core systems. Instead, that job falls to eleven existing booklets in the FFIEC IT Examination Handbook, plus model risk guidance, consumer protection law, and GLBA data rules that were written before anyone at the agencies had "agentic AI" in mind. The compliance work maps AI deployments against the rules already in force. It's mapping AI deployments against the rules already in force.

The FFIEC itself is an interagency body: the NCUA, FDIC, Federal Reserve, OCC, and CFPB all sit under it, and together they publish the handbook that covers information security, business continuity, architecture, outsourcing, payments, and more. NCUA examiners pull straight from these booklets, so when the FFIEC revises one, credit unions feel the change on the same timeline as banks. The two supervisory worlds aren't separate; they're the same rulebook read by different agencies.

And regulators have said that they expect this integration to happen. The OCC's Spring 2026 Semiannual Risk Perspective states support for banks folding AI into core functions "while managing the risk in a safe and sound manner and in compliance with applicable laws and regulations," a conditional green light. That's a green light with conditions attached. That's a green light with conditions attached. Which raises the real question for anyone running an AI agent against core banking infrastructure right now: which booklet governs which risk, and has anyone actually done the mapping?

What has changed in the FFIEC IT Handbook recently, and what those changes signal for AI deployments

Two updates in a short window matter more than the rest.

The Development, Acquisition, and Maintenance (DA&M) Booklet was rewritten on August 29, 2024, under SR 24-6, replacing guidance that had sat unchanged since April 2004. Twenty years is a long time for a document to hold, and the rewrite shows it: the new version is principles-based, enterprise-wide, and process-oriented, with fresh attention to IT project management, system development life cycles, and supply chain risk. It applies to every entity the Federal Reserve supervises, including institutions with $10 billion or less in consolidated assets. So this isn't a big-bank-only concern.

The Architecture, Infrastructure, and Operations (AIO) Booklet, issued back on June 30, 2021 under FIL-47-2021, renamed itself from "Operations" for a reason: IT had stopped being a back-office function and started running the business directly. The booklet names artificial intelligence and machine learning outright as emerging technologies examiners assess, and it governs enterprise-wide architectural planning, common infrastructure risks, and how virtual and physical systems get built out.

The Business Continuity Management Booklet (renamed from Business Continuity Planning) took the same principles-based approach, built specifically to stay relevant as technology keeps moving. And in February 2026, the handbook dropped references to reputational risk across the board, consistent with Executive Order 14331 from August 7, 2025. That change added no new requirements. It just cleaned up language.

None of these updates hands a bank a new AI checklist. The shift toward principles-based language means an institution can't point to a box it checked and call the exam done. Examiners want to see that the approach taken was appropriate for the risk, and that the bank can defend it on the merits. For a conventional software rollout, that bar was manageable. For an AI agent making real decisions on core infrastructure, it's a meaningfully higher one.

DA&M Booklet requirements when an AI agent is developed, acquired, or maintained on core banking infrastructure

DA&M splits into three phases, and an AI agent touches all three whether the bank built it or bought it.

Development covers strategic planning to align IT development with business functions, plus development standards, testing discipline, and DevOps/DevSecOps practices. For an AI agent, this is where training data selection, prompt architecture, and output controls live. Skipping documentation here because "it's just a model, not code" misses the point: examiners will ask for it anyway.

Acquisition: policies, standards, procedures, vendor evaluation, and contracts all sit here, and they apply from the moment vendor selection starts, not after the contract is signed. A bank that buys an AI agent off a vendor's shelf and treats the purchase like a product order, rather than an IT project, has likely skipped acquisition governance steps that DA&M expects. That's a gap examiners can find just by pulling the procurement file.

Maintenance covers change management, change documentation, end-of-life planning, and preventive maintenance. An AI model that gets retrained or fine-tuned still falls under change control even though the update happened inside a model rather than inside a codebase. It's a change like any other, and it needs a paper trail like any other.

Supply chain risk deserves its own callout. DA&M explicitly covers it, and an AI agent built on a third-party foundation model adds a layer that most traditional software procurement frameworks never had to think about. Whoever built the model underneath the vendor's product is now part of the bank's supply chain, whether anyone wrote that down or not.

Documentation, too, looks different for AI. DA&M expects records throughout the development life cycle, and for an AI agent that means version history on model weights, prompt changes, and configuration adjustments, not just commit logs on application code.

The AIO Booklet's governance expectations when AI becomes part of the operational infrastructure

AIO names AI and machine learning directly as emerging technology within its scope. So the governance bar examiners apply to a bank's core network, its cloud infrastructure, its API layer, extends to the AI agent sitting on top of it. No separate standard, no lighter touch.

A few questions fall straight out of AIO's focus areas. Where does the agent sit in the architecture? What systems does it actually touch, and what data flows through it along the way? Those are the exact questions AIO expects a bank to be able to answer on demand. They're the exact questions AIO expects a bank to be able to answer on demand.

Risk governance under AIO for an AI agent looks different from a typical server or app, too. Model drift, hallucination, adversarial prompting, unauthorized data access: these are the new failure modes, and AIO expects them to be governed with the same seriousness as uptime and failover for any other production system. An agent executing real payments needs the same operational resilience commitments as any other system moving money, arguably more, given how new the failure modes are.

AIO also names microservices, containers, and APIs specifically, which matters because agentic architectures tend to run on exactly that: chains of API calls invoking one tool after another. That architecture choice puts the agent's infrastructure design squarely inside AIO's scope, not adjacent to it.

The three-lines-of-defense model gives a useful frame here. The first line consists of the agent's built-in controls: transaction limits, escalation rules, confidence thresholds, full logging of every action taken. Line two is an independent risk function that reviews model performance, looks for patterns in escalated cases, and can suspend the agent. Line three is internal audit, confirming line one actually works and line two stays independent from the team that built the thing.

That independence is where governance often breaks down in practice. If the same technology team owns all three lines, there's no real check left. It's one team grading its own homework.

Examiner attention in 2026 has sharpened around two specific questions: can the AI system access or infer data outside what it was authorized for, and can the bank actually pull the plug on a system that starts behaving unexpectedly? A Wolters Kluwer survey of 230 banking professionals found 72% named either kill-switch protocols (34%) or regulatory reporting of AI failures (38%) as the area where they felt least prepared. That's nearly three-quarters of the industry admitting a gap in exactly the control examiners are asking about.

Information Security Booklet requirements and the specific risks AI agents introduce to data access, access control, and incident response

The Information Security Booklet sets out how to assess information security risk and evaluate whether a security program holds up. An AI agent with access to core transaction systems sits squarely inside that scope. It's squarely inside it.

Access control is the first place this gets tested. Examiners want to know whether an AI system can reach, or infer, data it wasn't authorized to touch. An agent connected to core banking data needs its own explicit, auditable permissions, not inherited access from whatever service account happened to be convenient during setup.

Shadow AI is the quieter risk, and it's a big one. IBM's Cost of a Data Breach report found 63% of organizations lacked AI governance policies strong enough to manage AI use or catch unsanctioned tools, and among organizations that had already suffered an AI-related security incident without proper access controls in place, 97% said shadow AI was involved. Shadow AI of this kind can surface anywhere employees find unsanctioned tools more convenient than approved ones. An information security program that only accounts for sanctioned AI deployments is missing most of the actual exposure.

Incident response plans need updating, too, and not just around the edges. Hallucination, adversarial prompting, an agent calling a tool it shouldn't have called: these are failure modes that didn't exist in a pre-AI incident response playbook, and examiners are asking directly whether a bank can actually shut a misbehaving system down, not just whether a policy document says it can.

Third-party AI doesn't get a pass here either. Using a vendor's model, or a model accessed through some external provider's API, doesn't transfer accountability for that model's data handling or failure modes. The bank remains responsible for governing the relationship directly under established third-party risk principles. Vendor contracts need language on data residency, model access logs, and how fast the vendor has to notify the bank when something goes wrong.

All of it needs to be evidence, not intention. Policy documents, access logs, incident playbooks: examiners are increasingly treating AI oversight questions as part of standard audit scope, not a separate exercise.

The Outsourcing Technology Services Booklet's application when AI capability is delivered by a third-party vendor

Most community and mid-size institutions are buying AI rather than building it in-house. They're buying it. That makes the Outsourcing Technology Services Booklet a front-line compliance document here, not a footnote.

An AI model reached through a vendor's API is a third-party relationship, and the FFIEC framework expects the bank to govern it directly. The vendor's failure is the bank's risk. There's no clause that moves that liability somewhere else.

The layered vendor problem is where this gets genuinely hard to track. A vendor's AI product may itself run on top of a foundation model from a separate provider entirely, and most third-party risk frameworks were built to assess one layer down, not two or three. That layered structure means a bank's due diligence file needs to reach further than it used to.

What are examiners actually looking for in these relationships? Contracts that address data handling, subcontractor relationships, and clear incident notification timelines. Due diligence that reaches into how the AI system itself is governed, extending beyond the vendor's general security posture. Ongoing monitoring of how the AI performs in production, rather than periodic vendor attestations alone. And, critically, the bank's own ability to check model behavior independently instead of taking the vendor's word for it.

A vendor's security certification is a starting point, not a substitute for the bank's own oversight. It doesn't excuse the institution from its own ongoing duties.

The baseline governance infrastructure this all rests on is simple to state and hard to build: a complete inventory of every AI tool and agent running in production, including ones delivered by vendors and their subcontractors. Without that inventory, none of the outsourcing oversight above is even possible to demonstrate.

SR 26-2 model risk guidance's application to AI-integrated systems, and the deliberate gap it leaves around agentic AI

SR 26-2 landed on April 17, 2026, issued jointly by the Federal Reserve, OCC, and FDIC, and it supersedes SR 11-7, the model risk guidance that had stood for a good many years. It came out simultaneously as OCC Bulletin 2026-13 and FDIC FIL-15-2026, and it keeps the core discipline intact: model inventories, independent validation, ongoing monitoring, and governance over third-party models, scaled to the size and risk of the institution.

The guidance is careful about its own reach. It states directly that it "does not set forth enforceable standards or prescriptive requirements," and that it's "expected to be most relevant to banking organizations with over $30 billion in total assets." Smaller institutions aren't off the hook on principle, though; the reasoning still applies, just with a lighter enforcement expectation.

Credit underwriting models, market-risk models, BSA/AML models: these sit squarely inside SR 26-2's perimeter, with the full weight of model inventories, independent validation, and ongoing governance behind them.

SR 26-2 places generative and agentic AI outside its scope on purpose, calling them novel and still moving too fast to pin down with prescriptive rules. It directs banks to apply the existing risk-management principles by analogy while the Federal Reserve gathers more input, and the agencies have announced a planned interagency request for information specifically on how banks use generative and agentic AI. That request for information hasn't happened yet. The scope decision has.

What does that mean in practice? An agent that chains several validated models together, deciding to execute a payment, move funds, or route a transaction, doesn't itself sit inside SR 26-2's governance perimeter, even though the models it's calling might. The institution has to apply the existing principles by analogy, using the FFIEC booklets already discussed, alongside structures like the Treasury AI Risk Management Framework (organized around Govern, Map, Measure, and Manage, with 230 control objectives scaled to how far along an institution is in AI adoption) to fill in what SR 26-2 deliberately left open.

The posture shift from SR 11-7 to SR 26-2 tracks the same shift seen in the handbook itself. The old question was whether the required process got followed. The new question is whether the approach taken was appropriate, and whether the bank can actually defend it under scrutiny. That's a heavier lift than procedural compliance, and it's the standard agentic AI now has to meet without a rulebook written specifically for it.

A defensible AI governance program mapped across all applicable FFIEC booklets

None of these layers are optional add-ons a bank picks from a menu. They stack, and all of them have to hold at once.

DA&M governs the agent inside the development life cycle: acquisition governance, development controls, change management, supply chain documentation. AIO governs the agent inside the enterprise architecture: operational resilience, independence across the three lines of defense, real-time monitoring built for AI-specific failure. Information Security governs access scoped tightly to what the agent is actually authorized to do, a shadow AI policy that accounts for unsanctioned use, and an incident response playbook that covers hallucination and unexpected tool calls, not just breach and outage. Outsourcing is caused by every vendor contract touching AI, and it requires visibility into sub-vendors and the foundation models beneath them, plus ongoing monitoring rather than an annual review. And the model risk layer under SR 26-2 governs any decision models the agent relies on, with independent validation for the ones that matter most, plus a documented rationale for how those principles were stretched to cover the agentic pieces that sit outside SR 26-2's stated scope.

What do examiners actually want to see sitting on top of all that? A complete, current inventory of every AI tool and agent running in production. Monitoring built around how these systems actually fail, not how conventional software fails. Full traceability back to source data and source models. A human in the loop at every decision point that carries real weight. Change documentation that would survive an audit without anyone scrambling to reconstruct it after the fact.

Institutions serious about this are increasingly building a standalone AI governance policy rather than scattering AI language across five other documents. That policy tends to include board-level reporting built specifically for AI risk, alongside a defined process for evaluating whatever AI capability appears embedded inside a third-party vendor's product, since that's often how AI actually enters a bank's infrastructure: quietly, through a vendor update, with no one ever filing a formal request to add "an AI agent" to the tech stack.