Agentic Approaches to Capital Markets

Speaker A: M welcome to Next in Tech, an S and P Global podcast where the world of emerging tech lives. I'm your host, Eric Hanselman, Chief Analyst for Industry research at S and P Global. And today we're talking about AI in the context of capital markets. We've talked a lot about AI, the move to agentic and autonomy, but when we start thinking about capital market impacts and some of the applications in this context, but we get into slightly different territory. With me to discuss it is Krishna Ventimuri, the CTO for Enterprise Solutions at S and P Global. Krishna, welcome to the podcast.

Speaker B: Hello. Thank you for having me.

Speaker A: It's great to have you here. Uh, as I was saying, we've talked about different aspects of AI and especially when we think about copilot kinds of applications and documents and image creation and astronauts riding horses on the moon and those sorts of things that can get fairly abstract in terms of the impacts and the concerns that roll around AI implementations. But when we think about putting agentic capabilities to work in capital markets, now we're working in an environment in which there are a set of additional constraints. And I guess to start off with, maybe you can give us some perspectives about your thoughts about why this matters at this point and really what those extra aspects are that we have to take under consideration.

Speaker B: Absolutely. So I'll start by taking a step back and thinking about the shift that we are seeing. And I think the shift is not just technology, it is about what clients now expect. Things have moved on from a narrow list of asks of, uh, make it faster and make it reliable to let me solve the whole problem. And as we introduce agentic technologies and agents across the board, the expectation from the clients is moving from not solve an individual narrow problem, solve the whole estate and solve the problem next door and also solve the problem, which I haven't imagined yet. That's the expectation of what is happening in the markets today. Now what makes it possible is the connection. Now when we implement open protocols like, for example MCPS and we can reach across multiple systems which were never built to talk to each other, and uh, when we do not have a coherent meaning behind the systems of what every single thing means, like for example, a counterparty is having different variations of what it means in different systems, or evaluation means something else, then it becomes really difficult for agents to be able to operate because they end up hallucinating. Now I'll uh, come back to the question which you asked. What makes it different from a capital markets one? Now the expectation is connect everything because it's the right thing for the customer to think that way, technically feasible. The unit of work has shifted as a result of agent TKI from doing an activity to reimagine solutions and deploying intelligent workflows that compose across multiple systems. Now coming to capital markets. The way I like to think about it is we need to only make a mistake once. That's good enough to actually lose the trust which we have with the industry, with the clients and everybody else. Because we cannot have ungoverned, um, agents making decisions giving a wrong answer. So you could see it as a tax, but it's actually one of those things which enforces a lot of discipline because of the nature of the industry we operate in. And it's just not only capital market. And now there are other industries where it does become equally important. I'm like healthcare, I'm like, I'm sure we do not want somebody in healthcare to have an agent hallucinate and give a wrong answer. So trust, reliability, governance makes important is really critical. But there are some instances where if you're getting data for information synthesis or it is more about, it's okay for it to be wrong. It's fine. I think that's the big shift I

Speaker A: see, Eric, and uh, in fact that aligns perfectly with conversation we had a couple episodes ago about AI and autonomous use in process control. Again, another area where trust is paramount and single errors have got very large consequences and of course break that trust, which is so critical. And that's, I think it's a really important point that you're bringing up because of course trust within the various parties that you're transacting in capital markets is the bedrock of that environment, of the systems that we're working with. And that trust is also a very fragile thing in those kinds of environments and the transactions that are running through them.

Speaker B: Yep, absolutely.

Speaker A: So if we think about, uh, approaches, I guess that really sets a bar for the kinds of things that we need to be able to accomplish. And we start thinking about the goals with which we're looking to apply agents. This is something where we've got to put some consideration in terms of how we actually assemble that environment. But up front, of course, understanding what those use cases are, how we're going to put them together and what they're actually going to be tasked with handling. This is a transformation that really is something that goes beyond some of the advisory and guidance capabilities that we thought about, moving beyond the copilot kind of function to, to really thinking about how we're actually integrating Capabilities within the workflows that are taking place as part of this environment.

Speaker B: Yeah. So the slight difference I would say there, Eric, is copilot is a suggestive model that sits next to us versus and where we are still doing the work. And there's a very simple way to look at it, but that's how I look at it. To say I've got a copilot, which suggests. But I'm doing most of the work. An agent is different. It's in the workflow, it is carrying the task. That's why I said the unit of work has actually shifted. Now, the agent alone is not the real story. The real transformation is actually, I think, as three things that come together, which is automation, integration and governance. Now, each one of them independently is. It wouldn't necessarily fall dark. And if I look at capital markets and back to the theme of the first question we just were talking about, right. Automation without governance isn't a feature, it's a liability you'll be spending years to unwind later. Right. And it would never stand in front of the regulator. So the mental model I find useful is it's a controlled, predictable workflow with intelligent steps inside. It is how I like to look at it. The scaffolding is fixed. The intelligence lives in a few places that really need judgment. And that's what helps you build it safely and be able to explain to the regulator, explain to our clients, and continue to hold on to the trust, which is what the clients put on us.

Speaker A: And that fundamental element of intelligence means you really have to ensure that's integrated into the design of that system and the capabilities that you're looking to leverage. And I guess when we start thinking about approaches towards managing intelligence, this, uh, is something where we get back to, I think one of the challenges that we've seen and one of the themes we've been talking about on the podcast quite a bit, which is building foundational automation capabilities is certainly useful. As you're pointing out, though, the actions of that automation have to be sufficiently trustworthy, but that in building that environment, it's not just the activity and the scaffolding and the capabilities that are actually going to manage the actions that are taken. That, of course, the raw material from which AI capabilities are built is really the data that is the foundation of what's actually being able to be delivered as value. And we've talked about this quite a bit in terms of a number of different contexts, both in technology side, in terms of a number of AI applications. But this is the thing that I think often doesn't get overlooked, but its criticality is not often fully understood. We've come from an environment in which data has of course been critical, but it's typically been a retrospective view. Data has been the thing that we've analyzed afterwards, as opposed to AI applications in which data is the thing from which all of this value is being built. And that's I think, one of the challenges and it's that shift in understanding that I think is critical to understanding this. But I'm curious on how you see that evolving and what's really necessary to ensure that that really is that core part of this equation in establishing intelligence and trust.

Speaker B: Absolutely. Uh, and like you said, data is the underlying foundation. But let's take a step back and think about AI or an agent. When an agent makes something up, let's say it's usually one of the three things and none of them are really the underlying model's fault, or, uh, at least that's the way I see it. The three things would be the ground truth was not retrievable, so therefore it made something up. Uh, or the data was there, but it was ambiguous. So two systems using the same word mean different things. So for example, in capital markets you take an instrument counterparty exposure position, each subtly different depending upon the system. So the agent interpreted with the best of its knowledge, which resulted in it hallucinating and giving you an answer. So the fix is actually the foundation. So technically the fix is found in the foundational semantic layer. It's not a data dictionary. It is the ontology, a formal machine readable definition that allows us to say every entity explicitly in how they relate, so that every agent works on the same conceptual ground. Now we're not millions of years away from that concept really. So the industry has a whole bunch of open standards. And um, we don't need to reinvent this with the common Damian model, which is now under phenos, or the FIBO model, which has been defined. So these models exist. Now if we get our data mapped back onto those common domain models and then expose them against that model, and then you overlay that with a policy on top of it, which is we use OPA as our policy agent. So every action now is governed means the same thing, it is auditable. And when you architect this with a data mesh on top of it, each domain owns its own data so that you don't have any data restrictions, jurisdictional challenges behind it, and then the agents will do their job phenomenally well. But to be fair, this is Boring work for most people. But this is the foundation of how everything, uh, how you get the most exciting work later. And these things take time, they don't come overnight. So I could get a really good agent overnight, but if I can't swap a model, and the models are changing every single day, so the model I use today is not the model I want to use tomorrow. So that is not the problem. The problem is do I have a semantic foundation on which I can build in all of these services? And going back to what we said in the beginning, that is going to enable me to build an interconnected ecosystem. That's how we are thinking now, uh, how to solve the problem.

Speaker A: You mentioned MCP earlier and I think oftentimes we get into discussions about it's the model context protocol. And through the interface you now have the ability to define context around that data. And that's certainly better than raw APIs without ability to handle it. But you pointed out that thing that, however boring, is still so critical, which is the ontology that ensures that you have agreement about the way in which that data is being referenced and leveraged. And that yes, you'll get some definition of context through an MCP interface, but you have to have done that upfront work to ensure that those definitions of context align. The data definitions throughout this environment align. Again, uh, to your point, it may be boring, but it is certainly challenging. Now, you mentioned opa. I'm curious in terms of governance and management of this, uh, in an environment, we talk very blithely about autonomy and allowing agents to act on their own. But of course there has to be governance around the actions that are taken. What are considerations around that in terms of how we integrate governance in a capital markets application?

Speaker B: Yeah, see I'm like, and I hear autonomy and um, autonomous agents quite a bit. And um, more and more I think about it, and more and more I talk to my colleagues, the peers and everybody else. I'm actually starting to think that the noise about autonomy is probably the wrong question to a certain degree. And um, the reason I say that is the real question is how much responsibility do we want to safely hand over to an agent is how I would like to think about it. So I'll give an example. Maybe it's going to bring this to life. So early on, all of us, like everybody else in the industry, we got very excited about Agent I there, mateen there, and we built a demo. It was honestly wickedly cool. It lit up the room, everybody was excited. And I was sitting thinking, this is Great. But demo was phenomenal. But if I put this into production, how do I know that the actions the agent is taking is right? How do I know the data underneath of that one is actually right? Where do I put a stop? Where do I basically say you cannot touch the boundaries outside of this. This is where the boundary of the agent sits. And these are the not things you ever see in a demo usually, right? And then we come back and I said to the team, guys, this is all good, I love it. And the lesson for me was actually the leverage was not in making the agent cleverer, but it's actually on the envelope on which I want to bound the agent to where I can actually say that you build in the evaluation, the regression test, you build in the monitoring the agent behavior of what is actually happening, monitoring for drift or what it's actually doing, and then ultimately defining what the security model behind that one is supposed to be. Because an agent surface is a broad surface prompt injection, data leaking across boundaries. All of that is complicated. Tech bed. Now, coming back to your question, the way we're thinking about solving this is bundling all of that into a policy based governance where you run the agents by a policy and if there is a low risk step that can be fully automated, as the policy defines the agent executes it. Where you think that you need to have a settlement transaction that requires a human in the loop intervention, the policy defines it. So the agent remains both deterministic and non deterministic. So it is autonomous in that nature, but it is bounded by a policy which kind of says these are the boundaries in which you operate. So that's where the ops comes into play. And I'm not suggesting it is easy. We are still working through that one. It gets complicated every day, even literally even before this one. I went to the team and I said, okay, can you add these more rules and say Krishna, can you have a baseline? They said, no, never. Because every single thing I see, there's going to be a new OPA regular policy I need to add to make sure that it is safe and it's never going to be 100% complete. So it's just hard work.

Speaker A: Uh, much the same. We design any sort of safety critical systems. You're building an operational envelope, you're attempting to bound the action that it can take and ensuring that there are appropriate guardrails.

Speaker B: Yes.

Speaker A: In terms of where those actions are going, 100%. So we start thinking about what this integration process looks like. We often talk in terms of automation about ensuring that we're able to appropriately manage the workflows that are taking place, to be able to ensure that the individual tasks are well crafted and well bounded. The difficulty though is that in managing that, we need to make sure that we're moving beyond isolated islands of activity. How do we move across that and what are the approaches that we can take to ensure that. In fact, we're able to fully realize the many potential benefits that we could pull out of these capabilities.

Speaker B: This links back to the three fundamental foundational principles we talked about. So one is about making sure we have got the semantic foundations right, so that when we go across multiple systems and multiple processes, the field means the same thing, if you will, number one. The second one is open protocols, which MCPS provide that to a large degree. So the ability for us to integrate using open protocols is going to help us integrate multiple systems the way we never imagined before. The third one, my favorite policy we talked about, do it with base guard rails and extend it actually, uh, as you need, and then basically make sure that we have got autonomy inside the boundary and the control at the edges. And when you put all of those things together, our uh, products are going to be reimagined because a connection without a shared meaning is just plumbing. This is the way I look at it. I'm like, it's like there is no meaning. So I've got connection, but it's not, there's no shared meaning. So it's affecting in a raw plumbing, which doesn't make any sense. But when you kind of have the shared meaning on it, that connection is going to open up an avenue of opportunities where you can have reimagined products, sub products, adjacencies which kind of spanned across the entire ecosystem.

Speaker A: When you talk about that span, we start to get into some of the questions around scope and of course that evolves into implementation. How do you actually put these capabilities in place? And this is something we see in technology so often, which is that decision about where do these capabilities get integrated. Of course over time more and more agentic capabilities are becoming parts of other platforms. I guess the bigger question that we wrestle with so often and so many parts of this is that matter of fact, what do we take on ourselves? What do we partner with? What do we purchase all of those sort of fundamental build versus buy kinds of questions. When we start thinking about new areas like agentic operations, that starts to become a more complicated question. Uh, what's your take on what the calculus is and how organizations should approach it?

Speaker B: It's always a Tricky debate of build versus buy. It's never been an easy answer. The way I uh, would think about it is if it is a commoditized piece of a software or things that are going to get commoditized by. So for example I wouldn't necessarily want to go and build a frontier model. I would rent a frontier model and that is moving at such a rapid pace and I want the flexibility and the fungibility to move in and out of models to meet my needs both commercially and operationally and functionally the build is going to be where the actual IP sits, which is your knowledge graph, which is your system of record. How do you connect your multiple systems of record? How do you orchestrate the multiple systems of record and the business flow which makes the organization unique? And that is the build side of the world. Now I would be lying that if I had said that it was very clear and binary as that because every now and then we get ended uh up tempting it to build things that actually exist already and they're going to become in fully knowing they're going to get commoditized or buying something when you actually know that you're going to get into a complex when the lock in kind of a scenario you can't get out of. But it's an actual architect that the standard issue ATAM trade off analysis you need to do because no decision is good in perpetuity, it's going to be at that point in time. So based on today's scenario I would not, I would suggest we don't, we rent a frontier model. Make sure that the models are uh, you have swappable mechanisms within the model. You can go across, well, multiple models across the board. The prices are falling down just not only for commercially but also technically. Build your orchestration, build your policy, build your semantics because that is where the IP sits. Because once you have that you can build any product, any day with any model that exists. Or at least that's the theory.

Speaker A: Those are wise words though because especially when we think about what we do know about the environment today is that what we'll see, uh, next month, next week, next year is guaranteed to be very different than what we're working with today. This is, we have only to look at our recent history to see that the rate of change in these capabilities is so significant that you have to be cautious about how you pick and choose around this. Especially when you look at systems in which regulatory and governance requirements are that much more significant. I'm fond of referring to Microsoft's old clippy assistant from back in the day. And these are not the kinds of things that as you were pointing out, just the simply copilot advisory capabilities are going to be sufficient for. There's much more that we've got to consider in how we look at this. This has been great. Thank you so much for all of the insights and I will refer our listeners to some of the links in the show notes to some follow on. It's got some perspectives about the ways in which they can approach these capabilities. But Krishna, thank you very much for all of the thoughts and uh, hopefully some guidance in terms of folks who are out there.

Speaker B: Thank you Eric. It's been a pleasure.

Speaker A: That is it for this episode of Next in Tech. Thanks to our audience for staying with us and thanks to our production team including Sophie Carr, Farhan Miyadhian, Kira Smith and Dylan Scheibel on the marketing and events teams. If you like this episode, please subscribe or like us. I hope you'll join us for our next episode where because there is always something next in Tech.