AI for Financial Services: Mapping to SR 11-7 and the NIST AI RMF

Financial services firms have a quiet advantage when it comes to governing AI: they have been governing models for decades. The discipline of model risk management did not arrive with large language models. It arrived with credit-scoring models, pricing models, and capital models, and it was formalised in the US by the Federal Reserve and OCC guidance known as SR 11-7.

The challenge is not that firms lack a framework. It is that modern AI systems, being probabilistic, opaque, and continuously drifting, do not slot neatly into governance designed for deterministic statistical models. The task, then, is translation: mapping fraud detection, AML monitoring, and KYC onboarding systems onto the model-risk discipline the firm already has, supplemented by the AI-specific structure of the NIST AI Risk Management Framework.

The AI systems that need governing

In practice, the AI systems creating governance pressure in financial services cluster into a few high-value, high-scrutiny categories.

Fraud and AML detection. These models decide whether a transaction is suspicious. Their central tension is the false-positive rate: too aggressive and you drown investigators in alerts and block legitimate customers; too permissive and you miss genuine financial crime and fail your regulatory obligations. Every threshold is a governed decision.

KYC and onboarding. AI that extracts data from identity documents, screens against sanctions and PEP lists, and assesses onboarding risk. Errors here are both a compliance failure and a customer-experience disaster.

Document processing and compliance monitoring. Systems that read contracts, filings, and communications to surface risk. These are exactly the document-heavy, high-stakes workloads where retrieval accuracy and citation traceability are non-negotiable.

Each of these is, in SR 11-7 terms, a model, and each therefore inherits the full weight of model risk management.

SR 11-7 in AI terms

SR 11-7 rests on a few load-bearing principles. Mapping each onto a modern AI system makes the obligations concrete.

"Model risk should be managed like other risks"

SR 11-7 treats a model as a source of risk in its own right: the risk of adverse consequences from decisions based on incorrect or misused model output. For an AI fraud system, that means the model's errors (both directions) are a quantified, owned, and mitigated risk, not an engineering detail. Someone senior owns the false-positive and false-negative rates, and their acceptable bounds are defined and monitored.

Effective challenge and independent validation

SR 11-7's centrepiece is effective challenge: critical review by objective, competent parties independent of the model's development. For AI systems this is demanding, because the "developer" may be a third-party model provider whose internals you cannot inspect.

The engineering response is to build the artefacts that make challenge possible even around an opaque model: a rigorous evaluation harness with representative and adversarial cases, documented performance across relevant segments (to expose disparate error rates), and clear articulation of the model's limitations and failure modes. You validate the system's behaviour even when you cannot validate the model's weights.

The three components: development, implementation, use

SR 11-7 asks firms to govern the whole lifecycle. Translated:

• Development. Data lineage, feature provenance, and design choices are documented. For an LLM-based system, this includes the retrieval architecture, the prompt design, and the grounding data.
• Implementation. The model is deployed with controls: input validation, output monitoring, and the integration integrity that stops silent upstream failures corrupting decisions.
• Use. Ongoing monitoring detects drift, the slow degradation as fraud patterns evolve or document formats change, and triggers revalidation before performance decays past tolerance.

Ongoing monitoring and outcomes analysis

Static validation is not enough for systems whose environment shifts. Fraud adversaries adapt; document distributions change. SR 11-7's demand for ongoing monitoring maps directly to production observability and a continuous evaluation harness that re-scores the system against fresh, labelled cases and alerts when accuracy drifts.

Where the NIST AI RMF adds structure

SR 11-7 tells you model risk must be managed. The NIST AI RMF gives you an AI-specific operating structure for doing it, organised around four functions.

Govern. Establish the culture, roles, and accountability for AI risk across the organisation. This is the connective tissue that makes the other three functions stick. This is where board-level ownership of AI risk appetite lives.

Map. Establish the context and identify risks for a specific system: its purpose, its stakeholders, the impact of its errors, and the ways it could fail or be misused. For an AML model, mapping surfaces risks SR 11-7's numeric lens can miss: bias, explainability gaps, and the downstream human consequences of a false alert.

Measure. Analyse and track the identified risks with quantitative and qualitative methods. This is the home of the evaluation harness, fairness testing across customer segments, and robustness testing against adversarial inputs.

Manage. Prioritise and act on risks: thresholds, human-oversight checkpoints, incident response, and the decision to deploy, constrain, or retire a system.

Used together, SR 11-7 supplies the regulatory expectation and audit posture; the NIST AI RMF supplies the AI-native taxonomy of risks and the process to work through them. Neither alone is sufficient for a modern AI system; together they are a workable governance spine.

A concrete mapping

For a firm deploying, say, an AI-assisted transaction-monitoring system, the combined mapping looks like this:

• Ownership (Govern / SR 11-7): a named model owner accountable for the false-positive and false-negative bounds and the model's inventory entry.
• Risk identification (Map): documented impacts of missed suspicious activity and of over-blocking, including bias and customer-harm risks.
• Validation (Measure / effective challenge): an independent evaluation harness scoring detection and false-positive rates across segments, plus adversarial testing.
• Controls (Manage / implementation): human review of high-value alerts, tamper-evident logging of every decision, and integration monitoring.
• Monitoring (SR 11-7 ongoing / Measure): continuous re-scoring against labelled outcomes with drift alerting and a defined revalidation trigger.

That is not a research project. It is production engineering plus governance artefacts, exactly the combination that keeps an AI system deployable in a regulated firm.

What we build

We build financial-services AI as governed systems from the outset: fraud, AML, KYC, and document-processing workloads on AWS-native infrastructure, with the evaluation harnesses, tamper-evident logging, human-oversight checkpoints, and documentation that map cleanly onto SR 11-7 and the NIST AI RMF. The ex-AWS engineering depth means the systems are production-grade; the governance-first design means they survive validation. You can see the pattern applied in our case studies and explore the range in our use cases.

The bottom line

Financial services firms do not need to invent a new governance regime for AI. They need to translate the model-risk discipline they already run onto systems that are probabilistic, opaque, and drifting, using SR 11-7 for the regulatory posture and the NIST AI RMF for the AI-specific risk structure. The firms that do this well treat governance as a design input, not a validation-stage obstacle. That is the difference between an AI system that reaches production and one that stalls in front of the model risk committee.

---

Deploying AI into a regulated financial services environment? Talk to our team about building it to pass model validation, not just the demo.