Agentic Approaches To Capital Markets

TITLE: Agentic Approaches to Capital Markets CHANNEL: S&P Global Market Intelligence DATE: 2026-06-16 ---TRANSCRIPT--- Welcome to Next in Tech, an S&P Global podcast where the world of emerging tech lives. I’m your host, Eric Hanselman, chief analyst for industry research at S&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, [music] but when we start thinking about capital market impacts and some of the applications in this context, [music] we get into slightly different territory. With me to discuss it is Krishna Venkatamuri, the CTO for Enterprise Solutions at S&P Global. Krishna, welcome to the podcast.

Hello. Thanks for having me. It’s great to have you here. As I was saying, we’ve talked about different aspects of AI, and especially when we think about co-pilot 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 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 which there there are set of additional constraints. And I guess to start off with, maybe you can give us a perspective about your thoughts about why this matters at this point and really what those extra aspects are that we have to take under consideration. Absolutely. So, I will 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 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 solving 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 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 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 agents making decisions giving a wrong answer. So, you can 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 markets, and now there are other industries where it does become equally important. I mean like health care. I mean like I’m sure we do not want somebody in health care 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 a big shift I see, Eric. And 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 market is the bedrock of that environment, of the systems that we’re working with. And that that trust is also a very fragile thing in those kinds of environments and the transactions that are running through them. Yep. Absolutely. So, if we think about 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 that really is something that goes beyond some of the advisory and guidance capabilities that we thought about, moving beyond the co-pilot kind of function to really thinking about how we’re actually integrating capabilities within the workflows that are taking place as part of this environment. Yeah, so the slight difference I would say that in the case co-pilot 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. This is I’ve got a co-pilot 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, uh three things that come together. Which is automation, integration, and governance. Now, each one of them independently is between necessarily folded up. And if I look at capital markets and back to the team 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 and which 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 client, and continue to hold on to the trust, which is what the clients put on us. And that fundamental element of intelligence means that 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 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 in the podcast quite a bit, which is building foundational automation capabilities is certainly useful. As you’re pointing out though, the 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. Absolutely. And you like you said, data is the underlying foundation. But let’s take a step back and think about AI automated. 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 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. 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 we don’t need to reinvent this. With the common domain model, which is now under FINOS, 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 the 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’re thinking of how best to solve the problem. 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 the 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 through an MCP interface, but you have to have done that up-front work to ensure that those definitions of context align, that data definitions throughout this environment align. And again, to to your point, it it may be boring, but it is certainly challenging. Now, you mentioned OPA. I’m curious in terms of governance and management of this, this is the 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. Yeah, see I’m liking the few autonomy and autonomous agents quite a bit. And more and more I think about it and more and more I talk to the 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 the reason I say that is the real question is how much of responsibility do we want to safely hand over to an agent? Is how I would like to think it 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 did my team did. 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 naughty things you ever see in a demo usually, right? And then when back we 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 of 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 bit. Now, to 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 OPA comes into play. And I’m not suggesting it is easy. We’re 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, how can you add these models?” I said, “No, Krishna, can you have a baseline?” I 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 is hard work. Well, much the same way 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 Yes. in terms of where these 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 that we could pull out of these capabilities? But this is links back to the three fundamental foundational principles we talked about. So, one is about making sure we have got 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 kind of 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 guardrails and extended actually as you need. And then basically, make sure that we’ve got autonomy inside the boundary and the control at the edges. And when you put all of those things together, our 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, there’s I’ve got connection, but it’s not there’s no shared meaning. So, it’s effectively 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 have open up an avenue of opportunities where you can have reimagined products, sub-products, adjacencies, which kind of span that class of the entire ecosystem. 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 Agentyc capabilities are becoming parts of other platforms. I guess the bigger question that we wrestle with so often in so many parts of this is that matter of 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 Agentyc operations, that starts to become a more complicated question. What’s your take on what that calculus is and how organizations should approach it? It’s always a tricky debate of build versus buy. It’s never been an easy answer. The way I would think about it is if it is a commoditized piece of a software or things that are going to get commoditized, buy So, for example, I wouldn’t necessarily want to go and build a frontier model. I would rent a frontier model and 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 up tempting into 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 an architect that the standard issue eight-time 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 you have swappable mechanisms within the model. You can go across well multiple models across the board. The prices are falling down. It’s 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. Well, at least that’s the theory. [laughter] But it those are wise words though because especially when you think about what we do know about the environment today is that what we’ll see next month, next week, next year is guaranteed 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’re pointing out, it just the simply co-pilot advisory capabilities are going to be sufficient for. There 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 hopefully some guidance in terms of folks are out there. Thank you, Vinnie. It’s been a pleasure. 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, Faran Medadian, Kira Smith, and Dylan Scheibel on the marketing and events teams. If you liked this episode, please subscribe or like us. I hope you’ll join us for our next episode because there is always something next in tech.