Financial Services AI Risk
CRI Financial Services AI Risk Management Framework
FS AI RMF Readiness, Adoption Stage and Control Implementation
The Cyber Risk Institute published the Financial Services AI Risk Management Framework in February 2026, developed with the Financial Services Sector Coordinating Council, the US Department of the Treasury and more than 100 financial institutions. It takes the NIST AI RMF structure and closes the gaps that appear when a general-purpose framework meets a supervised institution. Elevate Consult determines an institution’s adoption stage, scopes the control set that follows from it, and builds the framework and the evidence that Internal Audit and an examiner will both accept.
WHAT IT IS
A financial-sector framework built on the NIST AI RMF structure
The CRI Financial Services AI Risk Management Framework, released at version 1.0 in February 2026, translates high-level AI risk principles into control objectives written for the financial services operating environment. It was developed through the Financial Services Sector Coordinating Council and the US Department of the Treasury, with contributions from more than 100 financial institutions and input from NIST.
It is explicitly a supplement rather than a replacement. The framework builds on the NIST AI RMF’s Govern, Map, Measure and Manage structure and is designed to integrate with the risk functions an institution already runs, including the CRI Profile where an institution uses it for cybersecurity.
The distinguishing feature is adoption-stage sensitivity. Rather than applying one control set to every institution, the framework establishes maturity first and assigns obligations from it, which is what makes the same document usable by a community bank and a global asset manager.
THE SUPERVISORY GAP
Why an AI risk framework is not covered by the model risk program you already run
The revised interagency model risk management guidance issued in April 2026 states that generative AI and agentic AI models are not within its scope. The assistants, agents, copilots and embedded vendor features most institutions actually run therefore sit outside the one model governance letter the agencies have published, while examiners still expect them governed.
That is the gap the FS AI RMF was written to close, and it is why an institution with a mature model risk program can still have no defensible answer to the question of how AI risk is managed. Model risk holds the validation methodology. It does not hold the AI footprint.
THE ADPTION STAGE DECISION
Four stages, three dimensions, one control set that follows
The framework opens with an adoption stage questionnaire that places an institution in one of four stages. The stage is not a maturity badge. It determines which control objectives apply, which means it is the single decision that sizes the entire program.
Each stage is assessed across three dimensions: business impact, technology implementation, and scalability. An institution does not need to match a stage on all three to land there.
Stage 1 Initial
Limited and protective methods
AI is not embedded in critical functions or business decisions. Predictive AI on legacy systems, no modern AI, no external-facing solutions, no internal model development. Confined to specific applications that do not support broader organizational processes.
Stage 2 Minimal
Low-risk implementations
AI is not embedded in critical functions or business decisions. Predictive AI on legacy systems, no modern AI, no external-facing solutions, no internal model development. Confined to specific applications that do not support broader organizational processes.
Stage 3 Evolving
High-risk production applications
Drives outcomes through external-facing solutions and sensitive data, but not critical decision-making. Expanded solution use and sensitive-data processing, still no internal model development. Deployed in extensive external-facing functions but not yet fully scalable.
Stage 4 Embedded
AI widely integrated across the organization
Drives outcomes through autonomous decision-making in critical business functions. Internal model development, high-sensitivity data, external-facing solutions. Fully scalable and integrated enterprise-wide.
Where the lines fall
Initial to Minimal: Crossed by adopting modern AI at all.
Minimal to Evolving: Crossed the moment AI touches sensitive data or an external-facing outcome.
CONTROL SCOPE BY STAGE
Most institutions resolve to a higher stage than they expect
The methodology resolves the stage for you. The questionnaire is a stop-at-first-match test run from Embedded downward: a single matching statement at a stage ends the assessment at that stage.
That mechanic matters because “we are somewhere between two stages” is not an available answer. An institution with a copilot reaching regulated data, or with AI features embedded in vendor products touching customer-facing outcomes, has already matched Evolving statements regardless of how immature the governance feels. The control set that follows is several times the size of the one the institution was planning for.
21
Control objectives at Initial
193
Control objectives at Evolving
230
Control objectives in the framework
The stage is therefore not a label to negotiate. It is the scoping decision, and getting it wrong in either direction is expensive: too low and Internal Audit writes it up, too high and the institution builds controls it does not carry.
FRAMEWORK ARCHITECTURE
Thirteen control domains, and what every control statement carries
Elevate builds the framework across thirteen control domains, each anchored to the applicable FS AI RMF control objectives. This is the board an institution receives, and it is the artifact the whole engagement resolves into.
Every control statement carries five attributes without exception:
- Domain
- Evidence produced
- Source anchor
- Named owner
- Frequency
The last two are what separate a framework from a policy. A control statement that does not name the evidence it produces cannot be tested by Internal Audit, and one without a source anchor cannot be defended to an examiner asking why the requirement exists.
DESIGN PRINCIPLE
Reference, do not restate
The framework sits above the programs an institution already runs and routes to them. It does not reproduce their content. Model risk management, third-party risk, secure SDLC and any agentic AI standard keep their own authority, and the framework defines scope, routing, risk tiering, roles and reporting.
Duplication is how a framework drifts from its sources. Once the framework restates a control that lives in the model risk policy, the two versions diverge at the next policy update, and the divergence becomes the audit finding.
WHO MUST ENGAGE
The framework reaches past the institutions that built the models
AI risk in financial services is a supply chain problem as much as a model problem. The parties below all sit inside the scope in practice, even where only some of them appear on a regulatory filing.
Banks and credit unions
Institutions deploying AI in fraud detection, credit decisioning, customer service or operations, where model outputs affect consumers and supervisors will ask how the risk is managed.
Insurers and asset managers
Firms where AI touches underwriting, claims, portfolio construction or client communications, each carrying its own conduct and fairness exposure.
Financial technology vendors
Providers selling AI-enabled products into regulated institutions, whose customers now pass FS AI RMF questions through security and third-party risk reviews.
Third-party and outsourcing providers
Service organizations whose systems support a regulated institution’s AI use, and who inherit expectations through the contract rather than through direct supervision.
WHO MUST ENGAGE
How the FS AI RMF fits alongside what you already carry
Financial institutions rarely carry one framework. The FS AI RMF was designed with that reality in mind and maps deliberately onto the structures already in place.
NIST AI RMF
FS AI RMF builds on the Govern, Map, Measure, Manage functions without replacing them
Work completed against the NIST framework transfers directly into the sector framework
FS AI RMF adds the control objectives and adoption-stage logic NIST leaves to the implementer
Same publisher, adjacent risk domain
CRI Profile
The CRI Profile covers cybersecurity risk and is aligned to NIST CSF 2.0
FS AI RMF covers AI-specific risk, which the Profile does not reach
Institutions already using the Profile know the CRI structure and vocabulary, and Profile version 2.2 includes a mapping to the FS AI RMF
Model risk management
Existing model risk programs cover validation, performance and documentation for quantitative models
FS AI RMF extends into bias, explainability, foreseeable misuse and third-party model opacity
Generative and agentic AI were placed outside the scope of the revised interagency model risk guidance in April 2026
ISO/IEC 42001
FS AI RMF produces supervisory-ready evidence, not a certificate
ISO 42001 produces an accredited certificate a counterparty can independently verify
Institutions serving enterprise clients outside financial services often need both
OUR PROCESS
From adoption stage to a framework Internal Audit accepts
Elevate Consult supports financial institutions and their technology suppliers through the full FS AI RMF lifecycle, starting with the adoption stage question the framework itself puts first.
Issue stakeholder questionnaires written to each executive remit, run the working sessions, and review the existing document set. Coverage is proven in aggregate through a domain coverage matrix rather than by meeting count. The adoption stage is confirmed at the end of this phase.
Discovery and adoption stage determination
Assess current practice against the control objectives applicable to the confirmed stage, with each gap stated as a risk with an owner and a remediation path. The read-out is a formal gate: it is accepted by the sponsor before any drafting begins.
Current-state and gap read-out
Draft the control set by domain, resolve routing and RACI against the programs that already exist, and establish the risk tiering methodology. Every control statement carries its domain, owner, frequency, evidence and source anchor.
Framework design
Issue the draft framework together with any dependent policy or standard updates, then run one consolidated feedback round with every comment dispositioned in writing. A single round with written disposition beats three informal ones.
Draft and stakeholder feedback
Issue the final deliverables, brief the board or the risk committee, and hand over an implementation roadmap that phases the control set rather than presenting it as a single cutover.
Finalization and board briefing
THE READINESS CALL
What the FS AI RMF readiness call produces
The engagement starts with a conversation, and the conversation has an output. Thirty minutes, no cost, and you leave with three things rather than a proposal to read later.
We walk the stop-at-first-match questions against your actual footprint, including the vendor-embedded AI most institutions have not counted. The stage is the decision that sizes everything downstream, so getting a working answer in the first thirty minutes changes the shape of the conversation.
A working read on your adoption stage
We mark the domains where your existing programs already carry the load and the ones where documents describe an intent but nothing operates. That split, not the control objective count, is what determines the size of the build.
Which of the thirteen domains you already cover
You leave with the order: what has to exist before the gap read-out, what the framework design depends on, and where your model risk, third-party risk and information security evidence gets reused rather than rebuilt.
What sequence the work runs in
Who you meet. The call is run by Elevate’s AI governance practice, led by Angela Polania, who holds CISA, CISM and CRISC and is an ISO 42001 Lead Auditor. The practice works across GLBA, FFIEC examination readiness, the CRI Profile, SWIFT CSP and FedLine, so the AI conversation stays inside the examination cycle your institution already runs. You do not have to track framework version changes yourself. We track them.
+18
500+
100%
85%
GET STARTED
Ready to determine your adoption stage and scope the control set?
Whether the driver is supervisory attention, a counterparty questionnaire, or a board asking where the institution stands on AI risk, Elevate Consult runs the adoption stage determination, the control objective gap read-out, the framework design and the board briefing that closes it. Thirty minutes and you leave with a working read on your stage.
WHO THIS IS FOR
Built for institutions and the vendors that serve them
AI risk work in financial services crosses functions that do not usually share a reporting line. These are the roles Elevate works with most often.
- Chief Risk Officers
- Compliance and regulatory affairs
- CISOs and information security leads
- Model risk management teams
- Internal audit
- Third-party risk teams
BEYOND FINANCIAL SERVICES
The method transfers even where the framework does not
The FS AI RMF is written for supervised financial institutions, and its control objectives assume that context. Organizations outside financial services should not adopt it as their primary framework.
What does transfer is the architecture: the thirteen control domains, the control statement anatomy, the reference-do-not-restate principle, and the practice of scaling obligations to a documented adoption stage rather than applying one control set to every environment. Elevate applies the same architecture on NIST AI RMF engagements for organizations outside the sector.
QUESTIONS
Common questions
What is the CRI FS AI RMF?
The Financial Services AI Risk Management Framework is a sector-specific AI risk framework published by the Cyber Risk Institute at version 1.0 in February 2026. It was developed with the Financial Services Sector Coordinating Council, the US Department of the Treasury and more than 100 financial institutions, with input from NIST. It translates general AI risk principles into control objectives written for the financial services operating environment, scaled to an institution’s assessed AI adoption stage.
How does the adoption stage questionnaire work?
It places an institution in one of four stages, Initial, Minimal, Evolving or Embedded, assessed across business impact, technology implementation and scalability. The questionnaire runs from Embedded downward and stops at the first stage with a matching statement, so an institution resolves to the highest stage it matches anywhere rather than to an average across the three dimensions. The result determines which control objectives apply, which makes it the single decision that sizes the entire program.
Is the FS AI RMF a regulation?
No. It is a voluntary industry framework published by a not-for-profit standards development organization, not a rule issued by a supervisor. Its weight comes from sector consensus and from the involvement of the Treasury and the Financial Services Sector Coordinating Council in its development, which makes it a common reference that institutions, counterparties and examiners can all read.
Should we build to our current stage or the next one?
Build to the higher stage and implement in tranches. A framework written below an institution’s actual footprint will be criticized by Internal Audit or an examiner, while one written to the higher stage and phased in will not. Where two stages differ on the same control objective, adopting the higher requirement is the defensible position. The adoption stage questionnaire should then be re-run annually, because internal model development is the trigger that moves an institution to Embedded.
Do we need this if we already run model risk management?
Usually yes, and the distinction now carries supervisory weight. The revised interagency model risk management guidance issued in April 2026 states that generative AI and agentic AI models are not within its scope. Existing model risk programs handle validation, performance monitoring and documentation for quantitative models, and that work transfers. What they generally do not cover is bias and fairness testing, explainability expectations, foreseeable misuse, opacity in third-party models, and the generative and agentic systems the agencies have placed outside model risk scope entirely.
What does a framework deliverable actually contain?
Control statements organized across thirteen domains, and every statement carries five attributes without exception: the domain it belongs to, the named owner, the frequency it runs at, the evidence it produces, and its anchor in the FS AI RMF. The last two are what separate a framework from a policy. A control statement that does not name the evidence it produces cannot be tested by Internal Audit, and one without a source anchor cannot be defended to an examiner asking why the requirement exists.
Does the FS AI RMF apply outside financial services?
The framework itself does not. Its control objectives assume a supervised institution and organizations in other sectors should not adopt it as their primary framework. The architecture does transfer: the control domain structure, the control statement anatomy, the reference-do-not-restate principle and the practice of scaling obligations to a documented adoption stage all apply to a NIST AI RMF program in any industry.