Skip to content
AI Financial Services Governance

What Financial Services Got Right About AI (And What Everyone Else Can Learn)

Ian David Rossi
Ian David Rossi April 4, 2026 · 6 min read

TL;DR

The tech world treats AI governance like a new frontier, but financial services has been running this playbook for twenty years. MRM under the SR 11-7 framework is the gold standard for production engineering, forcing a level of rigor that every industry deploying LLMs should steal. Regulation didn’t slow these firms down; it gave them the blueprints to build systems that actually survive contact with reality.

Financial Services as AI Early Adopters

The sudden “discovery” of AI by the general public in late 2022 was a source of quiet amusement in the halls of global banks. While the rest of the world was marveling at a chatbot’s ability to write bad poetry, financial institutions were already two decades into the production ML era.

Fraud detection, credit scoring, and algorithmic trading aren’t just “software”; they are high-stakes statistical models that have governed trillions of dollars in assets since the early 2000s. Banks didn’t have the luxury of “moving fast and breaking things.” If a credit model breaks, people lose homes and banks collapse. If a trading algorithm enters a loop, a firm can be insolvent by the time the circuit breaker hits.

This history of high-consequence automation created a culture of engineering discipline that is sorely missing in the current GenAI hype cycle. They didn’t build these systems because they were bored; they built them because they were forced to by the most demanding regulators on the planet.

What They Got Right: Model Risk Management

The foundation of this discipline is SR 11-7, the 2011 guidance from the Federal Reserve and the OCC on Model Risk Management. While it was written long before the transformer architecture existed, its principles are timeless.

To operationalize these controls outside banking, map them to the AI governance and compliance framework.

I’m not going to give you a law school lecture. Practically speaking, SR 11-7 forces three pillars of sanity that most CTOs are currently ignoring:

  1. Model Inventory: You cannot manage what you don’t track. Every model in the organization must be registered, categorized by risk, and assigned an owner.
  2. Independent Validation: The team that builds the model cannot be the team that approves it. This is a structural “trust but verify” that prevents the optimism of the developer from overriding the reality of the risk.
  3. Continuous Monitoring: A model is not a static asset. It is a living process that drifts, degrades, and fails. You must have metrics to catch that failure in real-time.

At State Street, we’ve seen firsthand how MRM discipline translates to AI engineering. When we built multi-agent systems for internal decision support and runbooks, we didn’t just throw prompts at a wall. We applied the same rigor used in real-time trading systems: validation loops, adversarial testing, and strict operational guardrails.

The same approach appears in this internal developer platform for trading systems case study.

“The most expensive AI governance program is the one you build after the enforcement action.”

The Regulatory Advantage

Here’s the uncomfortable truth: compliance pressure created better engineering practices, not just overhead. In the valley, “compliance” is a dirty word that means “slow.” In financial services, compliance is the reason their systems don’t hallucinate a billion-dollar loss on a Tuesday afternoon.

These controls are an extension of lessons from DevOps for financial services and DevOps in FinTech.

The SR 11-7 framework forced banks to build LLMOps before we had a name for it. It mandated versioning, reproducibility, and auditability. When a regulator asks why a model made a specific decision, “I don’t know, the prompt was vibe-based” is not a valid answer.

The Model Risk Management Lifecycle

The MRM lifecycle is a continuous loop. It ensures that no model enters production without scrutiny and no model stays in production without verification.

graph TD
    A[Model Development] --> B[Independent Validation]
    B -->|Reject| A
    B --> C[Approval & Inventory]
    C --> D[Deployment]
    D --> E[Continuous Monitoring]
    E --> F{Revalidation Trigger?}
    F -->|Yes| B
    F -->|No| E
    E --> G[Model Retirement]

Model Risk Management Applied to LLMs

In 2025, the OCC released Bulletin 2025-26, which reaffirmed what many of us already knew: all AI systems used in decisions fall under SR 11-7. This includes your shiny new RAG system and your agentic workflows.

But here is where it gets tricky. SR 11-7 was designed for deterministic models—linear regressions where the same input always produces the same output. LLMs are stochastic. They are probabilistic engines of non-determinism.

The “stochasticity gap” is the biggest challenge facing the industry right now. Traditional validation expects a single right answer. LLMs give you a distribution of possible answers. Regulators are filling this gap through examination findings rather than new formal guidance, essentially telling firms: “We don’t care how hard it is; if you can’t prove it’s safe, don’t ship it.”

Lessons for Every Industry

If you are a CTO in healthcare, manufacturing, or retail, you might think you don’t need this level of rigor. You are wrong. The EU AI Act is already here, and it explicitly classifies credit scoring and insurance pricing as high-risk. By August 2, 2026, the obligations for high-risk systems become mandatory, with penalties that make GDPR look like a parking ticket: up to €15M or 3% of global turnover.

Here is what you should steal from the banks right now:

1. The Model Inventory

The most common examination finding in 2025 was the “Shadow AI” problem. Business units were deploying LLMs as desktop tools and classifying them as “software utilities” rather than “models.”

If it uses probability to make a decision or generate content that affects a business process, it’s a model. Put it in the inventory. If you don’t know where your LLMs are running, you have no governance.

2. Challenger Models

In high-stakes finance, you don’t just validate a model in a vacuum. You build a “challenger” model—a simpler or different statistical approach—and run it against the “champion” to see if the champion’s complexity is actually adding value or just hiding risk.

In the LLM world, this means running a smaller, cheaper model (like Llama 3 or Claude Haiku) alongside your flagship model. If the results diverge, that’s your signal to investigate.

3. Revalidation Triggers

A model shouldn’t just run until it breaks. You need explicit triggers for revalidation:

  • Data Drift: Is the input data significantly different from the training/tuning set?
  • Model Drift: Is the output quality degrading over time?
  • Platform Changes: Did the model provider (OpenAI/Anthropic) push a “stealth update” that changed the behavior of your system?

Where Financial Services Are Struggling

I’m not saying the banks have it all figured out. They are struggling with the same things you are, just under more pressure.

The FSB issued a major warning in October 2025 regarding “third-party concentration risk.” If every major bank in the world is relying on the same two or three model providers (OpenAI, Google, Anthropic), a single outage or a single “jailbreak” becomes a systemic global vulnerability. This is the new “Too Big to Fail,” and nobody has a good answer for it yet.

Prompt injection is another nightmare. Traditional financial security is built on firewalls and IAM. But how do you secure a system where the “code” and the “data” are both just natural language strings? The FS AI RMF published in February 2026 includes 230 controls for AI, and a significant portion is dedicated to the unique security failures of generative systems.

“The new ‘Too Big to Fail’ isn’t a bank. It’s the API endpoint that every bank’s AI depends on.”

What You Should Steal (The Actionable List)

If you want to survive the next two years of AI deployment without ending up in a hearing, implement these this quarter:

  1. Stop treating LLMs as “Tools”: Update your internal policy to define LLMs as models. This triggers your existing (or future) risk management workflows.
  2. Establish a Model Inventory: Even if it’s just a spreadsheet for now, track every API key, every system prompt, and every use case. 85% of Fed examinations now include an AI/ML model risk review—be ready for yours.
  3. Implement Performance Monitoring: You need more than just “thumbs up/down” from users. You need automated evaluation (LLM-as-a-judge) and deterministic unit tests for your RAG pipelines.
  4. Define an Exit Strategy: What happens if your primary model provider goes offline or changes their terms? Can you hot-swap to an open-source model running on your own infrastructure? If the answer is “no,” you don’t have a production system; you have a dependency.

Financial services didn’t get AI right because they are smarter or faster. They got it right because they had to learn the hard way that when you automate decisions at scale, the cost of being wrong is higher than the cost of being careful.

For another regulated implementation path, see ML operations for claims intelligence.

Every other industry is currently in the “moving fast” phase. The “breaking things” phase is coming. My advice? Steal the bank’s playbook before you’re the one being broken.