Insights

Some of you will remember last year's amazing insights from the team at Capital One and the great Prem Natarajan, PhD. Unfortunately I missed this year's Cap One presentation, but I did hear from the senior technology executives from RBC, Wells Fargo, and BNY. This panel talked through four key questions for financial services companies on agentic AI at scale.

1. How are financial services companies moving agentic use cases to production?
2. What special considerations are there for agentic AI in highly regulated spaces?
3. What metrics are being used to measure return on investment?
4. What predictions do you have about the next year in agentic AI?

How Are Financial Services Companies Moving Agentic Use Cases to Production?

At Royal Bank of Canada, they have "elevated" AI into a top enterprise strategic function while embedding its use cases into business lines. I'm sure there are tradeoffs here and I wonder how they handle the likely proliferation of business units bringing their own AI (BYOAI).

RBC Went Deep

The "showcase" AI use cases here were in the capital markets research space. Their core AI platform is called AIDEN, and started ten years ago as a AI-powered electronic trading system that used reinforcement learning (RL) to continuously learn from market conditions and optimize trades in real time. Yeah, that sounds hard. They have extended it to become a broader AI platform used across capital markets for trading algorithms, research automation, and insight generation for clients. To do agentic AI in the cap markets space at scale is a pretty impressive feat even though the specific use cases implemented feel to me like fairly classic deep research agents, which are pretty mature.

BNY Went Wide

Bank of New York described their AI strategy as "AI for everyone, everywhere, for everything". They described this as meaning AI should be used by every employee for every interaction across every process, which is a pretty bold statement. I have questions about the actual viability of this as a practical strategy but the point was well taken. I continue to this we will have many use cases and applications where the accelerated delivery of classic deterministic solutions is the right way to go.

They had some use cases that made my ears perk up, noting main agentic use cases in dynamic asset pricing, lock box processing, data insight generation, and, of course, data extraction. The lock box one I have questions about, I'm guessing it's exception research and illogical condition mining, and not actually payment processing but they did not get into this. They take a platform mindset, with use cases deployed across a range of AI platforms. It seemed to me that RBC went really deep in one area, where BNY went wide. Both valid strategies, just different.

Wells Fargo Went Customer

Wells Fargo pointed out their biggest hurdle as the "verifiability of agent actions at scale" in an automated way, which is one I have heard from at least one enterprise leader in mortgage. They started their agentic journey with "Fargo", which began as a virtual assistant. They extended it into intent extraction and classification, next taking smaller baby steps for specific agent capabilities like make a payment and initiate a claim. Now they have moved into personalized capabilities with an emphasis on the verifiability of results. WF noted that if we can verify the result, then we can automate the action.

What Special Considerations Are There for Agentic AI in Highly Regulates Spaces?

We really heard hear two main themes - verifiable risk management focus and culture.

Risk and Model Management

We heard multiple times about the need for verifiable risk management frameworks, evidence that the framework is in place, and actually being able to prove that a particular implementation actually followed the framework and risk was mitigated. That sounds really hard. This tells me that it's not enough to have guardrails implemented at a use case level. Yes, that's important guardrails need to be part of a connected framework.

Think about providing evidence on some subset of 40,000,000 logins a day (yes, that's a real number), being able to prove that the risk management framework was followed. Identifying which of these interactions was agentic, what use case it implemented, and the specific controls and guardrails triggered.

So guardrails need to be part of a larger, evidenceable strategy - which is much harder than implementing risks management in a single use case. We heard from one leader that they have had the same standing weekly meeting with their legal and risk partners for 2.5 years. Imagine the discipline and forethought that takes. Wow. Every week for years.

We also heard about model management but, again, with a focus on the scale consideration of how model management fits into a broader systems-based approach. Evaluating, for each model choice, the degree to which the model increases the risk in the overall system or decreases it. Looking at the materiality of the risk, the complexity of the model, its degree of openness and how explainable it is (or is not - black box AI). Finally, looking at the degree of reliance upon AI within market infrastructure.

Culture

Of course we heard about process reimagination and the need to rethink the whole problem. Culture as a deeply ingrained attitude towards rethinking a process as a whole. This was described a a move from the trend of "I have AI magic, where can I use it?" to "what does AI-native actually mean?". For example, one of the panelists described having 1700 use cases defined in 2024, with AI "all over the place" and the need to aggregate.

I loved this statement, and I've heard it from the OCC as well - there is a big cost to playing it safe. The new comptroller of the currency expressed this sentiment last year as "not innovating is a big risk". I wonder if these attitudes are related. You need one perspective to allow the other. This statement came on the heels of another gem: "if you need to get really big things done, you need a small team with the right thinker/doer ratio and the right leader". And this one: "keep going - keep breaking glass".

We heard culture as the long pole in the tent, with one panelist noting that "99% of employees have gone through AI training". I'm not sure that's the greatest success measure (attendance is not the same as application), but I do have to give him credit for measuring something.

What Metrics are Being Used to Measure Return on Investment?

Bit of a mixed bag here, and what is impressive is that agentic AI was implemented at scale at all. Again, my $0.02 is that the use cases themselves are not profound. What is profound is how hard it must have been to get the use cases implemented across millions of interactions under intense regulatory scrutiny. Here is a list of all the metrics I heard about from these leaders:

1. # people trained
2. # agentic uses out of total interactions
3. % time reduction in time spent producing analysis
4. Revenue per managing director
5. Clients covered (out of 1500 total)
6. Reduction in time spend producing credit memos (from 3-4 weeks to 1-2 days)
7. Call "deflection" meaning inquiries contained that did not become calls - Wells Fargo noted that in the 1.5 years they have had fargo, they have has 500M Fargo interactions, with between 2 two and three millions calls deflected.
8. Complex account opening from 18 days to 15 minutes
9. 25% increase in developer "burn rate"
10. # platform capabilities
11. Training breadth
12. Degree of organizational enablement
13. How fast a use case is implemented from concept to cash
14. Risk capabilities implemented in the automated pipeline

What Predictions Do You Have About the Next year in Agentic AI?

Themes here were continuous agentic loops, process reimagination, and pace of change.

1. Agentic loops. Certainly this is an extension of the OpenClaw mania that we heard so much about throughout the whole conference. The idea that we will see more and more agents that loop continuously, and based on self-reflection, improve themselves.
2. Process reimagination. The statement here was "banks that leverage and redesign with agents will pull away from the pack in the next year".
3. Pace of change. As training and inference converge, the pace of change will be even faster. That we will see the "bank as a system that learns every day and becomes even more personalized".

What this Means to Us in Mortgage

This was a really cool panel because it was real people talking about real, regulated AI at real scale. Without a ton of time to reflect this morning, I think my main takeaway for us is that the use cases people (are willing to) talk about at scale are not super profound, which is not to say they are uninteresting or trivial to implement. What I heard was a lot of useful, customer or operator enhancing solutions to problems we have today. With all the agent mania, I think the message here is, again, to scope the problem tight and iterate. I will also say again that this is not where the differentiation will ultimately come from.

We really have two paths to take simultaneously. The first is about being faster. Whatever we do today, do it faster. For a time, there will be advantage here. At the same time we have to look at redesigning a mortgage ecosystem that is specifically designed to be accelerated. Just like the innovation of accelerated computing that changed everything, so too will accelerated mortgage change everything. Mortgage is designed to be slow. It's a big, hairy decision where a lot of money changes hands and dreams are made. It's heavily regulated. the processes and technology are outdated. These are all natural throttles to respect and overcome, but this acceleration - native acceleration - is where the real edge will come.

‍

By Tela Mathias, CTO and Chief Nerd at PhoenixTeam

For mortgage executives, the challenge with AI is no longer whether to invest, but how to scale responsibly and effectively. Join Tela Gallagher Mathias of PhoenixTeam and Chris McEntee of ICE Mortgage Technology for a strategic discussion on ICE’s AI execution and the broader state of AI adoption across the industry. The webinar will highlight where lenders and servicers are realizing value, the risks that often emerge during execution and the strategic decisions that shape long-term success.

What you’ll learn:

Mortgage leaders are past the question of whether AI matters. The real challenge now is how to deploy it in ways that scale, manage risk and deliver measurable value. This webinar offers a grounded, strategic look at what that takes.

Viewers will gain insight into how ICE and PhoenixTeam is approaching AI across the mortgage lifecycle and hear an independent view of how lenders and servicers are adopting AI in practice today. Drawing from real-world examples, the discussion will highlight where AI initiatives are delivering results, where they commonly break down and what leadership teams need to consider as they move from experimentation to execution.

Watch now:

Machine learning (ML) operations (MLOps) is the set of practices, tools, and associated culture that bridges the gap between building ML models and running them reliably in production. MLOps is as much about science and engineering as it is about systems thinking. Some of learnings in this article come from a session at GTC focused on explaining why MLOps is needed, and what changes with MLOps when generative technologies are introduced.

Why does MLOps matter?

Let’s start with why this matters. Especially in financial services, we have to be able to answer at least four key questions:

1. What is this model doing and where is it in production?
2. What was it trained and validated on, and is production still consistent with that?
3. Who approved it, who owns it now, and what changed since approval?
4. Is it still performing safely, fairly, and within policy, and what happens if it does not?

MLOps is at the heart of many of these questions. Model management is not new to us in mortgage and has significantly evolved from the early days of automated underwriting and securitization. With the financial crisis of 2008, model risk became increasingly central to fair lending, risks assumptions, and stress testing. The introduction of generative models into our ecosystem only increases the importance of good operational practices around this new kind of ML system, hence the idea of MLOps as central to the new AI-powered mortgage ecosystem.

Famous Examples of MLOps Gone Wrong

There are many examples of MLOps "gone wrong", or cases where an engineering operations focus could have created better outcomes. A few examples mentioned at the NVIDIA conference:

• Ariane 5 Flight 501 (1996): Ariane 5 was a European rocket, and on its first launch it went off course and had to be destroyed less than a minute after takeoff. Part of its guidance software accepted a value larger than it was built to handle, causing the system to fail at a critical moment. The MLOps lesson is that a system can break fast when real-world conditions go beyond what the system was designed and tested for.
• Mars Climate Orbiter (1999): NASA intended for the Mars Climate Orbiter to, well, actually orbit Mars, but instead it burned up in the Martian atmosphere. One part of the system was using English measurement units and another was expecting metric units. The numbers appeared valid but in execution meant different things. The MLOps lesson is that a system can when different teams or tools are not using the same measurement rules.
• Millennium Bridge (2000): Under pedestrian traffic shortly after it opened, London's Millennium Bridge swayed side to side much more than expected and had to be closed for safety reasons. Engineers found that once the bridge began moving under foot traffic, people naturally adjusted how they walked, these unexpected lateral forces unintentionally made the side-to-side motion worse. The MLOps lesson is that a system can seem fine in design and testing, then behave very differently once real people interact with it at scale.
• Knight Capital (2012): A bad software rollout caused Knight Capital's core financial system to initiate huge numbers of unintended trades. During the first 45 minutes of trading, the system turned 212 customer orders into more than four million orders and led to more than $460 million in losses. This demonstrated that a system can fail not because the idea is wrong, but because a bad production rollout can make the live system behave in a completely different way than intended. The MLOps connection here is less about machine learning itself and more about how you safely release and control live decision systems.

Failure Through an MLOps Lens

Looking at a robust MLOps framework like the one used at NVIDIA, we can pinpoint the failure points.

• Ariane 5 failed because the live system encountered values outside what the software could handle. In this framework, that should have been caught by defining the operating limits early and then testing the system against extreme but plausible conditions during validation and simulation.
• Mars was really an interface meaning problem: the numbers were there, but one side meant English units and the other meant metric. In this framework, that belongs first in data federation, cleaning, and labeling, where data definitions and contracts should be aligned, and then in validation and simulation, where those handoffs should be tested before deployment.
• The bridge looked fine until real people started walking on it, which created a feedback loop nobody had fully accounted for. In this framework, that means you need stronger validation and simulation before launch, but also continuous monitoring and validation after release because some behaviors only appear in the real world at scale.
• Knight Capital was mainly a bad production rollout problem. In this framework, the strongest controls should have been in production deployment, making sure the release was consistent and safe, and in continuous monitoring and validation, so the issue was detected and stopped immediately.

How MLOps Changes with Generative Models

Generative models are simply a new and more complicated model to manage. Even a simple retrieval augmented generation (RAG) bot is actually a relatively complicated MLOps system.

We still start with problem definition, that hasn't changed. And we still have to make our data "ready" for use in retrieval. This data, which will be used to enrich and further contextualize the base knowledge of the large language model, has to be converted to vector embeddings, which requires, chunking, tokenization, and use of an embedding model. All steps in an MLOps pipeline flow. We should probably also store the original natural language data, yet another thing to manage. And don't forget change, how we govern the process of updating our embeddings is kind of a big deal. More MLOps.

We have this new problem of prompt management and evaluation, which requires golden standard data sets with both the questions and the answer (also called QA pairs for question and answer). It also requires us to have a good natural language versioning solution, again because the problem of change and optimization is a big deal. Prompts are a significant asset to understand, version, evaluate, test, optimize and control.

And of course model management, not exactly new in a generative scenario, but perhaps more fluid. Even if we are not training foundation models, we still have to preserve optionality, adapt the behavior of the model (perhaps going so far as to fine tune it), and customize how it behaves under real workloads and in the real world. More work with the intersections of prompting, data, and evaluation. Ensuring the model performs with edge cases, unanticipated scenarios, and over time (detecting and addressing model drift) would all be the purview of MLOps.

Although not expressly called out in our diagram above, latency management seems more significant with the addition of generative technologies. Users have come to expect instant answers, regardless of how complicated the request it. We have to think about when to offload workloads to an asynch process, when to use streaming so users can at least see the answer as it builds, paralellization.

Finally guardrails, again not exactly new to traditional MLOps, but something acutely important for understanding, controlling, and evidencing an AI system. Proving the responsible implementation, demonstrating safety, evidencing harm prevention - all essential to managing a good AI system, and all the purview of MLOps if you want it done well.

By Tela Mathias, CTO & Chief Nerd and Mad Scientist at PhoenixTeam

Vision AI is a not-new-but-hotter-than-it-used-to-be capability. The thing that changed is the opportunity in physical AI, as physical AI gets increasingly real. As a refresher, vision AI is AI that can look at images or video and understand what is in them, while physical AI is does not just understand information – it can sense, reason, and act in the real world through machines like robots, cars, drones, or factory systems. Vision AI might see a box, but physical AI can see the box, decide what to do with it, and then pick it up or move around it.

The Problems Working with Video

Low search accuracy is a problem with traditional video searching. This is because traditional search is limited to trained attributes. With a single embedding model, we can move search from retrieval based on trained attributes to generative. Traditional approaches might fire alters when a triggering event happens in a video (think a dog walks by your security camera and you get an alert). This is great, expect we all get “alert fatigue” amirite? At first you look at every alert and then, after a while, you look at nothing. It is difficult for a human to filter the important alerts (sketchy looking human passing the video camera in the middle of the night) from the unimportant (squirrel!). We want to find the true positives, things that need to be escalated, and things where we need to act. It’s the classic needle in a haystack problem.

What is Video Search and Summarization (VSS)?

Video search and summarization (VSS) is a set of vision aware tools that can connect to agents so the agents can understand what they are seeing. Think about tools for decomposing, searching, retrieving, critiquing, and summarizing context of a bunch of video. VSS is a hard problem – think about what you would have to do to summarize a video – you’d have to find it, watch it, figure out what’s important, maybe watch it again, pick out some highlights, summarize it, and then check your work. That’s what a VSS does. And it can do that for a one-hour video in about six minutes. Wow.

The Value Proposition

The KPIs here were pretty strong. 80% quicker onboarding for a training company, 80% reduction in incident reporting fatigue in a manufacturing company, 95% cost reduction for a training company. Let’s take an example, imagine you want to find all the places in a soccer game where a particular person scored a goal. You know how you would do that and can estimate how long it would take. If the game is an hour, it would take… at least an hour.

Now imagine that you could process the video in six minutes and then ask a natural language questions and get verified evidence of every time that person score a goal. All in about six minutes to process the video, and two seconds to answer the questions (with evidence!). That’s literally a 90% performance gain, conservatively.

The Technical Solution Architecture

It won’t surprise you by now that “there’s an NVIDIA solution for that” and it’s their VSS blueprint. NVIDIA VSS turns video from passive footage into an AI-readable system you can search, summarize, and act on. It is interesting because it treats video as a first-class enterprise data source, combining computer vision, VLMs, LLMs, and RAG so organizations can move from watching footage to querying and operationalizing it.

By Tela Gallagher Mathias, CTO at PhoenixTeam

‍