Listen To Our Podcast🎧
What does model risk management mean for financial-crime AI?
Model risk management for AI in financial crime is the operating discipline that decides which AML, sanctions, fraud and KYC systems count as models, who owns each one, how hard each is tested, and who can stop it. In 2026 that discipline got harder to run on one rulebook. The US agencies replaced SR 11-7 with SR 26-2 and put generative and agentic AI outside its scope, while the Reserve Bank of India's draft model risk guidance pulls decision-based rules and AI models, including third-party ones, inside its definition.
A CRO with a global footprint can't wait for those regimes to converge. You need one operating model that classifies every financial-crime system, tiers it by materiality and autonomy, gives each tier a named owner and an independent reviewer, and keeps a person who can override, suspend or switch the system off. This guide sets out that model and the evidence each step should leave behind.
- How the 2026 US, UK and India model risk texts treat financial-crime AI.
- How to decide whether a rule, score, matcher or AI agent is a model.
- How to tier systems by materiality, complexity and autonomy.
- What a model card for a financial-crime system should contain.
Request a model card walk-through
Model risk management for financial-crime AI means classifying every AML, sanctions, fraud and KYC system under each regime that applies, tiering it by materiality and autonomy, naming its owner and independent validator, and keeping a person who can override, suspend or switch it off.
What changed for model risk management in 2026?
Two supervisory moves reset the baseline this year, and the UK principles that took effect in 2024 still apply. On April 17, 2026, the Federal Reserve, OCC and FDIC issued revised model risk guidance that supersedes and replaces SR 11-7 and SR 21-8. SR 21-8 was the 2021 interagency statement written for systems supporting Bank Secrecy Act and anti-money laundering compliance, so its retirement lands directly on financial-crime teams. The Federal Reserve says the letter is most relevant to the banking organizations it regulates with over $30 billion in total assets.
- SR 26-2 replaced SR 11-7 and SR 21-8 in the US. The RBI released draft model risk guidance for comment on June 24, 2026. The PRA's SS1/23 sets five model risk principles in the UK. One AML scenario engine can sit outside one regime's model definition and inside another's, and the operating model records that difference.
The revised guidance is principles-based. It says it doesn't set enforceable standards or prescriptive requirements, and it adds that supervisory action may still follow from unsafe or unsound practices caused by weak management of model risk. It also states that generative and agentic AI models aren't within its scope, while telling banks to apply their own risk management and governance to systems the guidance doesn't cover. Our SR 11-7 and SR 26-2 regulation page covers the US supervisory history, and our guide to what examiners ask under SR 26-2 covers the US examination file.
India moved in the other direction. On June 24, 2026, the RBI released its draft Guidance on Regulatory Principles for Model Risk Management for public comment, with comments invited until July 24, 2026. The RBI says the draft applies to all models used by regulated entities, including third-party models and models employing AI or ML. It is still a draft: the page we checked on October 12, 2026 carried a placeholder date, so treat its paragraphs as the direction of travel and check the RBI site for the final text before you write policy against it.
In the UK, the PRA's SS1/23 sets five model risk principles for banks, building societies and PRA-designated investment firms with internal model approval for regulatory capital. The original version took effect on May 17, 2024, and the PRA lists a current version published and effective on April 23, 2026. Its principles apply to models used to inform business decisions, whether built in-house or bought from vendors.
The practical result is that one AML scenario engine can sit outside one regime's model definition and inside another's. Your operating model has to record that difference instead of hiding it.
Which financial-crime systems count as models?
Start with definitions, because every later control depends on them. SR 26-2 excludes simple spreadsheet arithmetic and deterministic rule-based processes and software where no statistical, economic or financial theory underpins the design. The RBI draft goes the other way for rules: its model definition includes algorithms, analytics, interfaces, applications, decision-based rules and other computational tools that materially affect decision-making, whether or not the institution calls them models. SR 26-2 also places generative and agentic AI outside its scope, while the RBI draft names AI and ML models as in scope.
- The financial-crime estate is mapped in a classification table. SR 26-2 excludes deterministic rule-based processes and places generative and agentic AI outside its scope. The RBI draft includes decision-based rules that materially affect decisions and names AI and ML models as in scope. Excluded systems still need an owner, a test record and a way to stop them.
For a financial-crime estate, that produces a classification table you should fill in before anyone argues about validation cadence.
| System in a financial-crime stack | SR 26-2 position | RBI draft position | Operating-model track |
|---|---|---|---|
| Deterministic transaction monitoring rules and thresholds | Excluded where no statistical theory underpins them | Included where the rules materially affect decisions | Register, own and test as a governed control either way |
| Statistical customer risk rating or scoring | Likely in scope as a quantitative estimate | In scope | Full model lifecycle |
| Fraud or alert-priority scoring built on statistical methods | Likely in scope | In scope | Full model lifecycle with outcome monitoring |
| Name-matching logic in sanctions screening | Depends on whether statistical methods drive the match | In scope if it processes inputs into results used for decisions | Classify per system and document the reason |
| AI agent that gathers evidence and prepares a case | Outside scope as agentic AI | In scope as an AI model | Separate AI governance track with human oversight and a kill switch |
| Generative drafting of case narratives | Outside scope as generative AI | In scope as an AI model | Separate AI governance track with output review |
The table records questions to settle, not legal conclusions. Your legal and model risk teams should confirm each row for each entity and jurisdiction.
Key insight: an exclusion from one regime's definition doesn't remove the risk. SR 26-2 itself says a bank's broader risk management and governance should guide controls for anything it doesn't cover, so excluded systems still need an owner, a test record and a way to stop them.
How should you tier financial-crime AI?
Tiering decides how much scrutiny each system gets, so it's where the program's validation effort is won or wasted. SR 26-2 ties model risk to a model's inherent risk, exposure, purpose and use, and it says models developed to help meet regulatory requirements are generally treated as higher risk than models that aren't. Most AML, sanctions and fraud models sit in that higher-risk group by purpose alone.
- Score materiality from the regulatory consequence of an error, customer impact and volume. Score complexity from data sources, explainability and how hard the output is to challenge. Score autonomy from what the system may do without a person. Set the tier from the highest of those scores, not the average, and record who approved it.
The RBI draft adds two factors that matter for AI agents. When an institution tiers a model, it should consider the extent of reliance and the level of autonomy placed on model outputs for decision-making. It also warns that low complexity shouldn't drag down the tier of a highly material model, and it expects every model's tier to be reviewed at least annually.
A workable tiering method for financial-crime systems runs in five steps:
- Record the decision the system supports, such as alert generation, alert priority, customer risk rating, screening disposition support or case preparation.
- Score materiality from the regulatory consequence of an error, customer impact and volume.
- Score complexity from data sources, explainability and how hard the output is to challenge.
- Score autonomy from what the system may do without a person: suggest, prepare, queue or act within a configured boundary.
- Set the tier from the highest of those scores, not the average, and record who approved it.
Using the highest score follows the RBI draft's warning against one factor offsetting another. It also stops a simple-looking agent with broad permissions from landing in a light-touch tier.
Who owns what across the three lines?
Clear ownership is what makes the rest of the program enforceable. The RBI draft expects three lines of defence: model owners as the first line, an independent model risk management and validation function as the second, and independent internal audit as the third. SR 26-2 expects clear roles with well-defined accountability, including attention to conflicts of interest between development and validation groups, and it says internal audit generally shouldn't duplicate development or validation work. The PRA expects responsibility for the whole framework to sit with the most appropriate Senior Management Function holder.
- The head of the business may want a monitoring change live, but the validator can delay it. Validation reports reach the board's Risk Management Committee within three months of completion, and the committee approves deployment of high-risk models. Internal audit gives assurance that the framework works as written without duplicating validation.
Effective challenge needs more than a separate team name. SR 26-2 describes it as challenge from people with the right expertise, enough independence to stay objective, and the organizational standing and influence to force change. In practice, that means the validator can delay a monitoring change even when the head of the business wants it live.
| Role | Owns | Should not |
|---|---|---|
| Model owner in financial crime operations | Purpose, use limits, performance against outcomes, change requests | Validate its own model |
| Developer, internal or vendor | Design, testing evidence, documentation | Approve deployment |
| Model risk and validation | Independent validation, tier review, effective challenge | Run daily alert operations |
| Approver or risk committee | Deployment, exceptions, retirement | Approve without validation evidence for the tier |
| MLRO or Head of Financial Crime | Regulated decisions the system informs | Delegate filing or clearing decisions to a system |
| Internal audit | Assurance that the framework works as written | Duplicate validation |
The RBI draft gives the board's Risk Management Committee the job of reviewing validation reports for high-risk models and approving their deployment. It also expects validation reports to reach that committee or its delegate within three months of completion. If your committee packs arrive later than that, the draft gives you a measurable gap to close.
What should validation and monitoring look like for AML and fraud models?
Validation should match the tier and the system type, and it should happen before first use. SR 26-2 says validation generally occurs before a model is first used. When an urgent business need forces earlier use, sound practice includes closer attention to limitations, telling stakeholders about them and setting controls such as use limits or tighter monitoring. For a new fraud score rushed live during an attack, that means a written use limit and a dated validation plan, not a verbal promise.
Ongoing monitoring carries extra weight in financial crime, because typologies, products and customer behavior shift. SR 26-2 describes ongoing monitoring as checking whether a model still performs as expected given changes in products, exposures, activities, clients, data relevance or market conditions. The RBI draft expects data drift and concept drift to be monitored and addressed on an ongoing basis. It also asks each institution to define what counts as a material change, so that crossing that threshold restarts validation and approval.
For AML and fraud systems, set the monitoring plan before go-live:
- Define the outcomes you'll compare against, such as alerts escalated to investigation, cases referred for reporting decisions and confirmed fraud.
- Set thresholds for alert volume, escalation rate and population shift, with a named owner for each breach.
- Record every threshold, scenario or score change with its impact assessment.
- Treat a material change as a new validation event.
- Report open issues and exceptions to the approving committee on a fixed cadence.
SR 26-2 also warns that using a model beyond its intended purpose adds uncertainty and risk. A sanctions matcher tuned for retail payments and reused for trade documents is a new use, and it should go back through validation for that use.
How do vendor models fit the operating model?
Buying a model doesn't buy out the accountability. The RBI draft says a regulated entity is accountable for the outcomes of all models it uses, and it expects the institution's own independent validation notwithstanding any validation, certification or assurance from the vendor. When a vendor won't disclose enough about an AI model, the draft expects the institution to identify the resulting risks and apply mitigants such as limiting use. SR 26-2 says the principles of model risk management remain applicable to vendor products even when proprietary components limit access to code or data, and the PRA's principles also cover vendor models.
In procurement, that turns into four contract and onboarding questions for any financial-crime vendor, including FluxForce:
- What documentation will you provide so our validators can assess design, assumptions and limits?
- What evidence does each output carry, so an investigator and a validator can replay it?
- How are your updates notified, tested and approved before they change behavior in our environment?
- What audit and exit rights do we and our supervisor have?
Where do human oversight and the kill switch sit?
Human oversight is the control that separates an AI agent that prepares a case from one that makes the call. In a governed workflow, the AI agent investigates the alerts it receives and prepares the case, and the analyst's decision is logged against the evidence the agent prepared. The RBI draft expects human oversight for AI models, including human-in-command arrangements and override, suspension or deactivation mechanisms, including kill-switch arrangements. It also asks institutions to consider automation bias, over-reliance on model outputs and decision fatigue, and it expects oversight staff to understand the model well enough to challenge, override or escalate its outputs. NIST's AI Risk Management Framework makes a similar point in voluntary terms: processes for human oversight should be defined, assessed and documented.
- The AI agent investigates the alerts it receives and prepares the case. The analyst's decision is logged against the evidence the agent prepared. Human oversight is the control that separates an agent that prepares a case from one that makes the call, with override, suspension and kill-switch arrangements. A list of overrides with reasons tells validators where the system is weak and shows an examiner that people exercised judgment.
For agentic AI, US guidance leaves the design to you. SR 26-2 puts agentic AI outside its scope and tells banks to use their own governance for systems it doesn't cover. That isn't an exemption. It means your operating model has to state the oversight design in your own words.
A practical oversight design for a financial-crime agent records:
- The autonomy level for each task: suggest, prepare or act within a defined boundary.
- The decisions that stay with people, such as clearing an alert, escalating a customer or approving a report.
- Who can override the agent, suspend it or switch it off, and how fast that takes effect.
- How overrides, incidents and near misses are logged and reviewed.
The last item feeds your evidence file. A list of overrides with reasons tells validators where the system is weak and shows an examiner that people actually exercised judgment.
What belongs in a model card for a financial-crime system?
A model card is the one-page record that lets a validator, an auditor or an examiner understand a system without reading its full documentation. The RBI draft lists minimum inventory details: model owners, developers, validators and approvers, risk tier, intended use, dependencies with upstream and downstream models, and the main observations from validation, monitoring and audit. It says no model should be used, relied on or deployed unless it's in the inventory. SR 26-2 expects the inventory to hold enough information to understand model risks at the individual and aggregate level, and NIST's framework also calls for mechanisms to inventory AI systems.
For financial-crime systems, a model card should add the fields that matter in an investigation review:
| Model card field | What to record |
|---|---|
| Classification | Model, governed rule set or AI agent, with the reason under each applicable regime |
| Decision supported | The alert, score, match or case output and who acts on it |
| Tier and autonomy | Materiality, complexity and the autonomy level allowed, with the approver |
| Owners | Model owner, developer, validator, approver and the accountable human decision-maker |
| Inputs and dependencies | Data sources, upstream lists or scores, downstream systems |
| Validation status | Last validation date, scope, open findings and next due date |
| Monitoring | Thresholds, breach owners and the latest results |
| Oversight | Override, suspension and kill-switch arrangements, with the people authorized to use them |
| Change log | Versions, material changes and approvals |
| Retirement | Decommissioning date and retention period |
The RBI draft expects decommissioned models to stay in the inventory for at least ten years from decommissioning. Put the retirement field on the card from day one so the record survives the system.
Our model risk management policy template gives you the policy structure these cards sit under, and our model risk management and AI governance guide covers the wider governance program.
- Classify each system under every regime that applies, and record the reason.
- Tier by materiality, complexity and autonomy, using the highest score.
- Keep validation independent of the owner, including for vendor models.
- Name the people who can override, suspend or switch off each AI agent.
Conclusion
Model risk management for financial-crime AI in 2026 depends on classification, autonomy-aware tiering, named ownership and a person who can stop the system. The US, UK and Indian texts disagree on what counts as a model, so the operating model has to record each system's position under every regime that applies to you.
Pick one live financial-crime system this quarter and complete its model card. The fields you can't fill in will tell you where the program needs work first, and they'll give the committee a concrete list instead of a policy debate.
Request a model card walk-through
Frequently Asked Questions
About the author
Sahil Kataria
Founder and CEO of FluxForce
Share this article