NIST AI Risk Management Framework 2023 Updates for Financial Institutions
Banks must map, measure, and manage AI systems across overlapping regulatory frameworks.
The NIST AI Risk Management Framework gives financial institutions a sound place to start, but banks still have to build their own control program. Banks put its four functions to work by translating them into named owners, system inventories, tests they can repeat, and controls that can stop an unsafe action. That translation becomes more urgent when AI moves from answering questions to moving money.
Why banks now face six overlapping AI governance documents instead of one clear rule
Financial institutions face six overlapping documents, including the NIST AI RMF from January 2023, the FS AI RMF from February 19, 2026, and ISO/IEC 42001:2023. The remaining documents are SR 26-2/OCC 2026-13 from April 2026, COSO GenAI guidance from February 2026, and the CSBS AI Supervisory Framework from September 2026. None has the force of law on its own. All, however, shape examiner expectations, audit exposure, and litigation risk.
Their labels do not make them interchangeable. Only NIST and the FS AI RMF are true frameworks, while the others are standards or guidance. SR 26-2 and OCC 2026-13 replaced long-standing model risk guidance but expressly leave out generative and agentic AI, so institutions still have to govern those systems properly without guidance that covers them directly. The CSBS framework builds on NIST and the financial-services framework, giving state supervisors a playbook for examining that governance.
What the NIST AI RMF actually is — and what it deliberately leaves unresolved
NIST published its AI Risk Management Framework on January 26, 2023, as NIST AI 100-1. It is voluntary, sector-agnostic, and non-certifiable. There is no NIST audit or badge, only self-attestation. Its architecture consists of Govern, Map, Measure, and Manage, organized into categories and subcategories. Govern runs through the other three functions rather than ending when an initial policy is approved.
The framework defines seven trustworthiness characteristics, namely valid and reliable, safe, secure and resilient, explainable and interpretable, privacy-enhanced, fair with harmful bias managed, and accountable and transparent. These are outcomes. They apply to machine-learning models, generative assistants, and automation that executes business processes because risk depends on what a system does and who is affected when it fails. Yet the framework leaves implementation choices to the institution. The NCUA points credit unions toward it, reinforcing its standing without turning it into a mandate.
How the FS AI RMF translates the NIST baseline into banking-specific control language
The Financial Services AI Risk Management Framework adds roughly 230 control objectives for financial services to NIST’s four-function structure. It explicitly covers generative and agentic AI. Its Adoption Stage Questionnaire places institutions at one of four maturity levels, which are Initial, Minimal, Evolving, and Embedded. Controls accumulate across those stages, so each stage inherits earlier requirements and adds more rigorous ones.
The chatbot serves a defined customer process, while access across the enterprise means banks must track more of how employees use it and what data it exposes. To fill out the questionnaire, banks must know where AI lives, including in products they buy, capabilities vendors deploy, and employee tools. When banks are unsure how to classify their use, choosing the more mature stage is safer because understating adoption can leave uses they already have without the right controls.
Govern — building the accountability infrastructure that the other three functions depend on
GOVERN 1.3 ties risk management activity to the organization’s risk tolerance. For a bank, that starts with a written statement of acceptable and unacceptable AI uses. Someone must also own each system once it is in use. A community bank or credit union can start with an AI security policy, a named owner or committee that is accountable, and a written record of its risk tolerance. The approval path for new uses belongs there too, before deployment.
Larger institutions illustrate how that foundation can develop. Goldman Sachs has a Firmwide Artificial Intelligence Risk and Controls Committee that reports to its technology risk committee. Citigroup’s board Technology Committee reviews management information about its approach to Generative AI, while Truist bases its AI program on NIST with board oversight. BNY brings model risk management into a cross-functional AI risk framework. Smaller institutions need lighter versions of those structures, because the operational test is the same at any size. If an alert arrives, who is responsible for acting?
Map — finding AI that arrived without a deployment decision
An institution’s approved AI projects are not its inventory. AI also arrives inside vendor products between formal reviews, including an ERP’s built-in assistant that a finance team may not regard as a deployment. Employee tools widen the gap further. This creates the largest sequencing risk in applying the framework, because an institution can build a careful governance program around only the systems it already recognizes.
MAP 5.1 calls for documenting the likelihood and magnitude of potential impacts for each system. A useful entry therefore records the process AI touches, its decision authority, what it reads and writes, and who is affected by errors. A product name cannot answer those questions. Within an existing risk program, AI may be an added capability, a new discrete system, or a change to already measured risks through new data types or shifted likelihoods. That framing avoids a parallel risk program, but it cannot replace discovery. A working inventory is a prerequisite for an honest maturity assessment.
Measure — turning “it seems fine” into a number that holds up under examination
MEASURE 1.1 calls for selecting approaches and metrics for identified AI risks, starting with the most significant. Begin by identifying a failure mode. For a system that approves, posts, or pays, useful measures include error rate, exception rate, override rate, and reproducibility. The last asks whether the same input gives the same output. Each metric gives a reviewer something more definite than reassurance that the system seems fine.
The trustworthiness characteristics sharpen the questions behind those numbers. Can a reviewer understand why a transaction received a particular treatment? Are comparable cases treated comparably? Because models drift as training, inputs, and the data behind them change, tests run at deployment cannot show that a model will stay reliable. NIST calls the ongoing discipline testing, evaluation, verification, and validation, or TEVV. It needs business participation as well as IT, because branch staff and operations personnel are often the first to notice wrong answers, and examinations increasingly ask how the business validates outputs.
Manage — the gap between having a risk roadmap and being able to pause a system that is wrong
MANAGE 1.2 prioritizes treatment by impact, likelihood, and available resources, while MANAGE 1.3 identifies four responses, which are mitigate, transfer, avoid, or accept. The practical output is a prioritized roadmap with owners and dates. The financial-services framework maps to NIST’s MANAGE 2.4 recommendation for shutdown and deactivation mechanisms that let banks disengage quickly and with control when performance becomes inconsistent. Continuous testing must also be planned before an incident.
Investigation requires more than a recorded model score. An adequate audit trail connects the action to the model version, consumed data, governing policy, granted authority, and timing of authorization. Agent workflows complicate that reconstruction because prompts, tool calls, intermediate reasoning, and responses may be scattered across systems or not captured at all. The lack of a consistent record leaves a bank unable to reconstruct why an agent acted, a weakness with much greater consequences for a payment than for a recommendation.
Why agentic AI makes the four functions harder to satisfy and raises the cost of getting them wrong
Agentic AI can act directly on systems it is connected to. FIS partnered with Anthropic to bring agentic AI into banking, starting with financial crimes, and named BMO and Amalgamated Bank among the first institutions deploying its Financial Crimes AI Agent. Fiserv launched agentOS. These developments also show why inventory must extend into core provider relationships rather than stop at projects commissioned directly by a bank.
The additional risk centers on privilege and accountability. Agents may have more entitlements than they need for their tasks, while service accounts, API keys, and tokens may have no clear link to a person who is accountable. Govern must address that authority, Map must record it, Measure must check how the agent behaves within it, and Manage must provide a way to interrupt it. The 2026 Singapore Consensus on Global AI Safety Research Priorities identifies principles including least privilege, traceable identity, auditability, runtime assurance, interruptibility, and human oversight. Those principles deepen the four functions rather than replace them, because a framework alone cannot constrain what an agent is allowed to do.
What governance of AI-executed payments and transfers actually requires in practice
Payment execution makes those permissions concrete. The migration to ISO 20022 messaging and the shift from overnight batches to real-time rails supplied cleaner, structured data available when an instruction arrives. Conversational and agentic platforms in production can move money between accounts or to saved recipients from a single sentence, applying the bank’s limits, verification steps, and fraud checks. The instruction may be short, but its control requirements are not.
For payment-executing AI, Govern means transaction limits per agent, named human workflow owners, written rules distinguishing permitted transactions from those requiring human approval, and change control for those limits. Map records accessible accounts, reachable rails, permitted counterparties, and service-account entitlements. Measure adds transaction error rates, exception rates, and override rates by transaction type, plus anomaly detection against the agent’s own behavioral baseline. Known fraud patterns alone are not enough.
Manage requires a tested shutdown path within a defined time window and a human takeover process that works without the agent running. Automated circuit breakers translate the shutdown recommendation into a control for outputs that cross defined financial logic boundaries. Deployment on existing banking rails preserves fraud controls, limit structures, and audit logging. That provides a practical advantage without rebuilding the control environment.
How voice and conversational interfaces fit within the compliance requirements the framework establishes
Voice adds data from regulated interactions to the transaction record. Calls involve non-public personal information, transactions are regulated events, and recorded turns can be subpoenaed. Voice workflows in production in 2026 include account services, payments and transfers, loan services, and card management. Eltropy announced general availability of its AI Voice Agents in September 2025, with core banking integrations, real-time data access, and contextual escalation to live agents.
Recorded audio is necessary, but it is insufficient. For a voice-authorized payment, accountability and transparency mean being able to show who authorized the action, what the agent was instructed to do, and what it actually did. A mid-interaction human handoff also needs enough context to reconstruct the customer’s instructions and the agent’s reasoning. That makes escalation a Manage concern. Explainability adds another test, because the institution must explain the action plainly to a customer, examiner, or court.
A sequenced path for applying the four functions without rebuilding the risk program from scratch
Begin with inventory. Before filling out the maturity questionnaire, institutions should include vendor-embedded AI, employee tools, and agentic capabilities in core platforms in that inventory. Next come the Govern artifacts, including the security policy, named system owners, documented risk tolerance, and approval path. Smaller institutions can keep these simple while making clear who is responsible.
Measure should then begin with the highest-impact systems and metrics matched to the failure modes identified in Map. A repeatable TEVV schedule should involve business units and IT. Manage turns the findings into a roadmap with owners, dates, and thresholds that trigger action. The shutdown path needs testing, and the audit trail needs enough detail to reconstruct what happened on a given day. Documentation alone does not establish operational readiness.
The maturity stages provide room for controls to grow. An institution at the Initial stage can work with fewer controls than one at the Embedded stage, but it must honestly classify how far its adoption has gone and keep earlier controls as it moves ahead. For transaction-executing AI, full audit trails and configurable controls on existing rails must be in place as part of that operating foundation from the start. Accountability and automation can support each other only when governance precedes deployment.
