Next in Tech | Ep. 272: Agentic Approaches to Capital Markets

View Full Transcript

Eric Hanselman   00:00:02

Welcome to Next In Tech, an S&P Global Podcast with 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. But, we start thinking about capital market impacts and some of the applications in this context, we get into slightly different territory. With me to discuss it is Krishna Vinjamuri, the CTO for Enterprise Solutions at S&P Global. Krishna, welcome to the podcast.

Krishna Vinjamuri   00:00:36

Hello. Thank you for having me.

Eric Hanselman   00:00:39

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 copilot kinds of applications and documents and image creation and astronauts writing 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.

Krishna Vinjamuri   00:01:29

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 make it faster and make it reliable to let me solve the whole problem. And as we introduce agent 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 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 very 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 and 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 not only capital markets. And now there are other industries where it does become equally important. I'm like health care. I'm 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.

Eric Hanselman   00:04:20

And in fact, that aligns perfectly with the conversation we had a couple of 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.

Krishna Vinjamuri   00:05:04

Yes, absolutely.

Eric Hanselman   00:05:06

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 upfront, 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 really thinking about how we're actually integrating capabilities within the workflows that are taking place as part of this environment.

Krishna Vinjamuri   00:05:56

Yes. So the slight difference I would say there really is Copilot is a suggestive model that sits next to us versus -- and where we are still doing the work. And it'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, has 3 things that come together, which is automation, integration and governance. Now each one of them independently is -- it wouldn't necessarily hold up. 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.

Eric Hanselman   00:07:28

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 is something where we get back to, I think, one of the challenges that we've seen and one of the themes that 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 on the 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.

Krishna Vinjamuri   00:09:22

Absolutely. 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 1 of the 3 things. And none of them are really the underlying models fault or at least that's the way I see it. The 3 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 2 systems using the same word mean different things. So for example, in capital markets, you take an instrument counterparty exposure position, each certainly different depending upon the system. So the agent interpreted with the best of its knowledge, which resulted in hallucinating and giving you an answer. So the fix is actually the -- so technically, the fix is found the foundational semantic layer. It's not a data dictionary, it is the oncology. 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 FNOS or the feeble 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 the 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 wants 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 -- how you get the most exciting work later, and these things take time. They don't come overnight. So I can 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's 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 of how to solve the problem.

Eric Hanselman   00:12:09

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. And again, 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, this is -- in an environment, we talk very lightly 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?

Krishna Vinjamuri   00:13:28

Yes. See, I'm like I hear autonomy and autonomous agents quite a bit. And 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 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 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 not things you ever see in a demo usually, right? And then went back and 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 clever 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 recreation 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 bid. 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 nondeterministic. 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 are still working through that one. It gets complicated. Every day, literally even before this one, I went to the team and I said, okay, can you add these more rules? And like, 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. It's never going to be 100% complete. So it's just hard work.

Eric Hanselman   00:16:44

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 in terms of where those actions are going.

Krishna Vinjamuri   00:16:59

100%.

Eric Hanselman   00:17:00

So when 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.

Krishna Vinjamuri   00:17:43

I mean this is -- links back to the 3 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 guardrails and extend it actually 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 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 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 open up an avenue of opportunities where you can have reimagined products, subproducts, adjacencies, which kind of span across the entire ecosystem.

Eric Hanselman   00:19:10

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 what do we take on ourselves, what do we partner with, what do we purchase, all of the 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. What's your take on what the calculus is and how organization should approach it?

Krishna Vinjamuri   00:20:04

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 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 up tempting 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 lock-in kind of a scenario, you can't get out of. But it's natural in architect that the standard issue, AAM 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 suggest we don't -- we rent a frontier model, make sure that the models are -- you have swappable mechanisms within the model that you can go across 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. But at least that's the theory.

Eric Hanselman   00:22:16

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 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're 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, just 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 who are out there.

Krishna Vinjamuri   00:23:27

Thank you, Eric. It's been a pleasure.

Eric Hanselman   00:23:29

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, Feranmi Adeoshun, Kyra Smith and Dylan Scheiblel on the marketing and event teams. If you like 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!