Buy-side and sell-side firms are steadily moving away from legacy platforms toward cloud-native, API-driven, AI-enabled operating environments. Research from WatersTechnology and OneTick reinforces this shift, highlighting growing demand for flexible access to both real-time and historical data across front-office functions.

Where this is heading is becoming increasingly clear:

• Standardized tech stacks built around RESTful APIs and cloud-based data formats
• Python-driven analytics establishing itself as the default for quant and data teams
• Platforms like Snowflake supporting high-performance data processing at scale

That said, the transition comes with real challenges. Cost, migration complexity, and vendor lock-in remain key concerns, even as the case for cloud continues to strengthen.

AI, meanwhile, is now firmly embedded in firms’ analytics strategies, particularly when it comes to surfacing insights and generating alpha. Its effectiveness, however, is entirely dependent on the quality of the underlying data.

This webinar explores these themes in depth, offering practical guidance on how firms can apply new technologies to strengthen their front-office operations.

The webinar focuses on:

• How cloud adoption is reshaping data management and analytics, including the shift toward APIs and cloud-native formats
• The role of real-time and historical market data in supporting trading and analytics across the business
• The practical realities of cloud migration: managing costs, transforming processes, and avoiding vendor lock-in
• How AI is influencing market data strategies—and why data quality is critical to producing reliable insights

Speakers:

• Mick Hittesdorf, Senior Cloud Architect at OneTick, KX

• Vishal Gupta, Executive Director at Mizuho and Leader in AI Governance & Institutional Design

• Peter Ottomanelli, VP & Head of Technology Investment Management and Compliance, American Century Investments

More About OneTick Cloud:

OneTick Cloud provides real-time, intra-day and historic data and analytics on trading activity leading to actionable insights for sales, trading, and surveillance. With hundreds of customers, you know that OneTick is a recognized platform you can trust. We will cover these many powerful advantages to OneTick, and show you how, together, we can meet your business needs.

Watch Today:

Webinar Transcript:

Hello and welcome to today's webinar, Rewiring the Front Office: Cloud, Data, and AI in Action. My name is Victor Anderson and it is my pleasure to be moderating today's discussion sponsored by OneTick.

Buy side and sell side firms are steadily moving away from legacy platforms towards cloud based and cloud native API driven AI enabled environments. Research from Waters Technology and OneTick highlights rising demand from right across the industry for flexible access to real time and historical data to support front office functions, while standardized stacks built on RESTful APIs, cloud data formats, Python data analytics and scalable platforms like Snowflake are fast becoming the norm.

And as we all know, AI is now embedded within most analytics tools across both sides of the industry buy side and sell side, and of course various other applications across the enterprise. Although the efficacy of such implementations depends on the availability of high quality data. This webinar will examine shifts and offer practical guidance for enhancing front office operations through cloud adoption, effective data use, and responsible AI deployment. But before we get to all of that, I'd like to welcome my panelists for today's session, including Peter Ottomanelli from American Century, Vishal Gupta from Mizuho Americas, Mick Hittesdorf from OneTick and OneTick as I mentioned at the top of this session. OneTick is today's sponsor. And as I mentioned, my name is Victor Hansen, I'm going to be moderating today's session.

Now, please note that the views expressed in this webinar are those of the speakers only and do not reflect the official policies and or the positions of the firms they represent. The end users in this webinar, in this instance, American Century and Azure, are not affiliated to and do not have a relationship with the sponsor. They do not therefore endorse its products and or its services.

Now, before we kick off today's discussion, I'd like to ask my fellow panelists to introduce themselves and let the viewers know a little bit about what they do within their respective organizations on a day to day basis with respect to today's topic of discussion. So, this order, firstly, Peter and then Vishal, if you wouldn't mind following Peter, and then finally, Mick, and then we will get into unpacking the first of today's very busy schedule. So, Peter.

Yep. Thank you. Good morning, everyone, and excited to join the session. My name is Peter Ardenelli. I'm a VP of technology at American Century across the front office, total portfolio life cycle, and back office. So you think of everything from our portfolio managers through middle back office, wants analytics, and research.

That is our team and pass to Vishal.

Thanks, Peter. I'm Vishal Gupta. Over the last fifteen years, I have been working across buy side, sell side and fintech and currently I lead front office technology for equity derivatives at Mizuho Americas. So my day to day task involves dealing with traders, structures, quants and sales. So this session is very relevant to me because this actually depicts what I do on a regular basis and some of the topics are very good and I think very relevant to today's capital markets.

Good, good, good. Thanks, Vish. Mick.

Hi everyone, pleasure to be here. Thanks, Victor. My name is Mick Hittesdorf. I'm a senior cloud architect and a product architect with OneTick. Joined OneTick about a year and a half ago to work on the product management team, contributing and leading product strategy with a focus on cloud migrations, cloud architecture, and also helping our key flagship customers migrate to the cloud and take advantage of the benefits of the cloud.

Good, good, good. Thanks everyone. Right, as I mentioned, we've got a packed lineup today, with some really interesting content that we're gonna unpack during the course of the session. Now, what I'm gonna do is, Peter, I want you to lead off on the first point of discussion today. So I'm gonna put it to you.

As a point of departure for today's discussion, where are buy side and sell side firms regarding their adoption of the cloud and cloud based services? And of course, in addition to that, the integration of APIs and decommissioning and or sunsetting their legacy technologies and infrastructure. There's a lot to unpack there. So, just to kind of paraphrase, where are firms on their cloud journey right now? Buy side and sell side firms. Is one side of the industry maybe slightly ahead of the other?

And so perhaps you just want to start with that. And then let's talk a little bit about the integration of APIs and decommissioning and or sunsetting their legacy technologies. And we know that there are large amounts still of legacy technologies on both sides of the industry. Peter, what would you say to that?

Yeah. The industry is at a point where we've crossed that decision. Everyone is fully committed to go in the cloud and moving into this hybrid architecture.

Where we see a lot of the challenges are when this execution gap.

Firms are ready, we're moving to the cloud, we're adopting AI, but we're fully operationalized.

Yep.

That's where we're hitting challenges.

And so as a result of that, hybrid and multi cloud is somewhat of the default architecture for firms that have this deep embedded legacy architecture.

And the reason isn't adoption or enthusiasm. It's really this kind of data gravity that exists on that legacy architecture.

So what that means is there's this huge wealth of data, historical information processing workflows integration exists prem. And so firms that are really kind of accelerating their migration, they are adopting more of this API centric model as far as what can we take out of these monolithic applications, break up into APIs, move those composable APIs into the cloud Yep. And microservice architecture with AI now, it's MCP and very similar journey there that can align to front office workflows. We're not looking at we will be a hundred percent cloud. We're looking at how we migrate intelligently.

Yeah. Good.

Michelle, are you with us? I can't see you at the moment. Yeah. Okay. You're with us.

Okay. I'm going put the same question to you. Where are buy side and sell side firms? Have they breached that inflection point as Peter suggested?

And where are they in terms of their integration of APIs? And crucially decommissioning legacy technologies and infrastructure because obviously that's kind of hamstringing their progress. Right?

Yes, I think I agree with Peter on that. Definitely firms are looking to move to cloud and I think we have moved away from should we go to cloud and right now we are looking at how do we modernize front office safely on cloud in a controlled manner and I think that is the key and I think the biggest difference between buy side and sell side is I think sell side has more regulatory oversight and I think that is why it is more challenging and also sell side have a list of legacy applications. So the cost of migrating in a big bang mode is extremely heavy.

So the way I see it, I think there is definitely an intention that all the architecture on the front office side will be AI native and API native and cloud based but it is going to be a gradual change. I think for the next few years, we will see firms operating in a hybrid model and build their trust on cloud applications and from there as trust builds up, then more mission critical applications like pricing and heavy computation can move to cloud.

Mick, you've got to come at this from a slightly different perspective. You're not a capital markets firm, you're a technology company that serves large numbers of capital markets firms on both sides of the industry. What are you seeing in terms of the clients that you're typically going and speaking to? How far are they down that of the cloud journey?

And to what extent have they kind of integrated APIs kind of right across the business in order to try to get mission critical data out of legacy technologies and infrastructure? To what extent are they trying to wean themselves off, decommission those platforms because they do represent a substantial operational risk, right?

Well, we are interesting. We actually see, I see in my job as a cloud architect, sort of two classes of customers. One is, and even within the two classes, there are different segments. So the classic customer who is looking to maximize time to value, they are very keen, for example, to get access to data and analytics as quickly as possible. This might be a customer who is spinning up a new pod on-site or maybe have a brand new fund, or maybe perhaps exploring a strategy for which they don't have the data, maybe a macro fund, right? That needs access to data in Brazil or India, NSE data.

That is an ideal customer for fully hosted, like OneTick Cloud offering, right? Where it's completely API driven, there's no infrastructure, register, sign up, start working.

One tech as event technology vendor, on the other hand, that's been around for over twenty years, we have a lot of customers with deployed infrastructure on prem. That's a customer who wants more control, who has invested in infrastructure, maybe has co-located low latency feeds, it's ingesting market data.

A lot of those customers are also moving to the cloud to take advantage of the elasticity, reducing capital costs, being able to upgrade hardware more quickly and take advantage of some of the just, you know, ability to move fast in the cloud. Right? Yeah. With that said, even those customers recognize that there are certain differentiators and sort of proprietary things that they do maybe with their data. Maybe they have a lot of data on-site.

Peter mentioned data gravity. And so they even even there, they want to maintain some of their infrastructure on prem and they're going more for a hybrid solution. So it's not one size fits all. The buy side, the sell side is definitely a dimension, the degree of control, and some of the other factors I mentioned play into that decision to move to the cloud fully or pursue more of a hybrid strategy.

Yeah. I think the issue of time to market or time to value that you mentioned a little bit earlier, I think that's going to come up. It's going to be a theme that recurs during the course of this discussion because what we see is firm, it's one of the kind of the critical factors that influences firms buying decisions. How soon can I be up and running? I don't want to spend a year or eighteen months on an implementation. I I it's, you know, it's just very, very difficult to justify. Right?

Correct.

Yeah.

Absolutely. Everything's moving faster these days. AI has also, you know, accelerated that process.

And, yeah, time to value is a key consideration and really a driver of decision making.

Yeah. There we go. Good. Okay. The second part of the opening theme is, and I'm gonna put this to you, Vishal, to lead with and then And then, Mick, you you can follow and Peter, you'll have the final word.

It's clear that firms on both sides of the industry are under increasing pressure to modernize their front office, tech and data stacks. As data volumes increase and workflows become more complex, we know this. Has the industry reached an inflection point? Or are there still large numbers of firms running hybrid environments that limit their ability to capitalize on modern day data and analytics capabilities.

Peter mentioned, specifically he mentioned hybrid environments and hybrid tech stacks. So to what extent you know, are there large numbers of firms still kind of running hybrid environments? Is that inevitable, given the fact that a lot of these firms, a lot of capital markets firms have been around for many decades now, and you can't just switch off legacy technologies? So to what extent is the hybrid model prevalent across the industry? Vishal?

So I think like Mick mentioned the time to market, Most firms operate at that model.

They are looking for reduced time to market but I think one of the biggest gaps in these things is time to control and that is what is the biggest gap. How do you govern when front office systems operate at machine tempo and I think that is becoming a very very big challenge. We have very recent cases where some industries like openly rolled out AI and they had to roll it back because they were not working. So I think there is definitely interest and there is definitely from a strategy perspective, I think firms have already reached that inflection point but from an execution perspective, they have not and I think it's not really a technology problem, it is more of a leadership problem.

Like what exactly and how should we start?

People are thinking that the cloud will solve everything and just migrating from on prem to cloud is the right strategy. But people are not redesigning their workflows and their processes. So essentially they are paying for the cost but they are not getting the cloud efficiency in the process.

Mick, is that consistent with your view of the world in terms of, you can't just embrace the cloud and hope that all your problems go away, right?

Right and governance is critical and this idea of control is an access. Right? A dimension that many firms do consider, especially in regulated industries, a degree of control is absolutely necessary. So we often see customers who may start with an API approach, you know, using, you know, our fully managed service.

And once they have maybe proven an idea or validated a strategy and they want to make the workflow systematic, you know, they they might bring that workflow more in house or maybe even get the data from us, but do some of the analytics using either OneTick or or another tool or or, you know, using their own, you know, quants and what whatnot.

I think we're gonna talk a little bit about, you know, the popularity of Python, you know, to do in house development and analytics later.

So I don't think hybrid is actually a pejorative in this case. Hybrid often implies a journey or where you go from taking advantage of the time to insights of a fully managed cloud service service. And as you mature, bringing some of that processing in house. And even in-house can be- is often the cloud these days.

It's just your cloud. Right? We have this concept of bringing your own cloud where the technology is still running in the cloud, but it's the client's cloud account. Right, as opposed to the vendor's cloud account.

And that provides some of the advantages of cloud in terms of the cost structure and whatnot, but provides a greater degree of control.

And, you know, and at one tip, we support both models.

Peter, you mentioned hybrid environments a little bit earlier in your first comments.

Is is is that inevitable given the history of the the industry in which we work And the fact that a lot of companies have been around for numerous years, they would have at one point, I remember back in the kind of the round the turn of the century, start of the new millennium, pretty much most firms are still building their own technology because you didn't have this large third party vendor community serving the industry. So of course they developed all their own technology, a lot of it was proprietary. So does that mean that it's inevitable that hybrid environments still exist, Peter?

It's, you know, going to that statement you said, building our own technology, and this is something a lot of firms have revisited, build by partner, Right? Yeah. Some firms are fully built still, but I think most firms are now going into that partners phase. There are vendors out there. They do wanna engage with us, and this is an opportunity to build together.

Know, Mick said, bring your own cloud. That's a great example of partnership as far as we're not gonna have to worry about third party. It's within our four walls. Yeah. That makes everyone in legal and compliance a lot more comfortable because data staying within our cloud instance.

And the hybrid environment, to Michelle's comment earlier, there is a leadership commitment item, and this is where you look at what is the best use of our time, effort, and energy.

We have a legacy database that's very important mission critical.

How much does it cost to migrate that? Do we wanna spend two years, three years, five years doing this large scale migration? Or do we wanna deliver new functionality in the cloud to support these new products, new insights, new portfolios, asset classes, etcetera. And so it is one of those things that everyone would wanna be a little more hundred percent cloud.

Yeah.

But until there's a certain point, what that event horizon is as far as we must retire the legacy, firms are prioritizing other things. Markets are moving so much faster than, you know, something Mick had commented earlier too.

Data access is a huge focus, but as we evolve in the cloud, we're looking for decision ready insight. And that's where the data has to be available, not just, oh, I have this dataset available. It's no. No.

Is this dataset available for me to act on it? Yeah. Yeah. Yeah. And that's where the cloud really excels versus traditional on prem ETL, ELT type constructs.

And that's where I see a little more of this natural evolution going to cloud. So at a certain point, I see most firms being more cloud, we'll say, the percentage of compute running on cloud will be higher, but there will be a long tail on the legacy on-prem architecture, that hybrid world.

That actually leads us really nicely onto the next discussion point for today's webinar. And Mick, I'm gonna put this to you. You can lead on this one and then Peter and then Vishal.

Now research from all this technology in OneTick that we conducted early on in the year indicates increased demand for streamlined access to real time and historic data across trading quantum analytics functions. This is exactly what Peter was referring to a minute ago. What is driving this shift in consumption patterns, Mick? And how do firms reassess and how are they reassessing how they store access and use market data across the front office?

Yeah. So the question I think is the real time versus historical data use cases. I think a lot of it comes down to a recognition that sourcing data, cleaning data, reconciling data, aligning data is extremely expensive. And recognition that you'd rather have quants looking for edge building models rather than cleaning data. There's more and more data all the time, more venues where trades are happening.

There's new types of data, alternative data, not just the stuff that we've all heard about, like images and and and and and and tweets.

But for example, you know, on chain data, right, from blockchain type systems. Right? We there's innovations happening there, new exchanges spinning up in the US and internationally, new asset classes, structured products, etcetera. So the the the the the market data sources continue to explode and and the costs of of of acquiring the data ingesting cleaning is just growing exponentially as well. So I as I see it, you know, moving faster is always an imperative, and that means real time data and some, like, sell side in in particular needs, you know, that real time data. But more than real time versus historical split, I I I see a recognition that just data overall is it's increasingly expensive to acquire and and structure and clean.

And so working with a vendor that does that is economical more so than ever.

Peter, I'm gonna put the same question to you. What is driving this increased demand for real time and historic data for trading quantum analytics functions?

Is driving this and what are the challenges facing? You're obviously a buy side organization, but what are the challenges around buy side and sell side firms with respect to all this incredible velocity, complexity, and just the sheer scale of the data that they're consuming?

Yeah. There has been this explosion in the data volume complexity across all the asset classes. We're looking at a world that is now twenty four seven trading.

This is a place where markets are moving constantly. And so what is real time versus historical? That line's getting blurred.

It's tomorrow in Asia. And so a lot of firms are looking at how do I blend this data? How do I version it, tag it, label it appropriately?

And, you know, going to mixed comments. Firms are taking that step back and saying, what do I do? What is my core function? What are my capabilities? If I'm a quant, if I'm an asset manager, we're on the buy side.

Our value to clients is not in cleaning data.

Our value is on insight and execution.

And so we are looking at places where how do we get the higher quality data? How do we move to that decision ready insight? And that's a place where we look at vendors, getting that mapping across them, getting that data consistency has been an exceptional challenge. One other comment on the buy side is the growth of ETFs has introduced a whole new level of complexity in this twenty four seven trading world. ETFs that are in Europe, Asia, and America may hold instruments that are settling in Europe, Asia, and America with all those combinations.

So having data that is consistent with that portfolio as opposed to this is a US security. That's all I need to worry about. Now we're concerned about multi asset, multi region, multi time zone.

So that has been this huge explosion of complexity that has changed the traditional, we'll say mutual fund model as far as I stamp a NAV, I go home and I'm done for the night.

Vish, I see that you're nodding in agreement. Do you wanna give the kind of the sell side's perspective on Yeah. On the challenge facing, you know, all this data just kind of flowing through the industry and buy side and sell side firms having to consume it, make and store it and act on it appropriately, interrogate that data in ever shrinking time windows too. It's a tough old challenge, isn't it?

It is like and I think historically like real time data and market data were completely separate domains.

Real time data supported trading and hedging and risk management in real time whereas historical data was helping quants, structures for analytics and back testing.

But that separation is now breaking and I think Peter mentioned that like now quants, structures, traders workflows are collapsing and they all need the data at the same time. So for example, structures like we have seen a lot of interest in structured products and structured products require a lot of historical data so that like the new strategies can be built, tested using the historical data and marketed. So I think that is where we have seen like a lot pressure and a lot of interest. Clients are becoming very bespoke, they are looking for products which are bespoke and that is not really possible without historical data.

So real time data definitely is needed but I think one of the things which I think Peter mentioned like buy side or sell side, they are not in the business of cleaning the data like that. I completely agree with that. However, I think again there is a point of data governance or data as a product instead of a service.

So who owns the data at the end of the day?

If there is a mistake from a vendor perspective and they are not able to clean the data, who is accountable for the financial loss which comes due to that data integrity. So I think that is where the bigger challenge is.

Right now we are trying to implement AI workflows but however, AI model output is as good as the data underneath. If the data is not good then your output will and AI we have seen like AI can be very persuasive. So even if your data is wrong, it can give you an insight and you might act on it.

So the speed comes with its own challenges and I think there has to be a need from all financial institutions to consider data as a product instead of a service.

Yeah, yeah. Actually that segues very nicely with the next discussion point that we're going to be kicking off right now. And Peter, I'm going to put this to you first, Vishal second, then Mick maybe you have the final word on this. We know that AI is now embedded within many firms analytics and market data workflows because of its effectiveness in generating insights and identifying hidden patterns and or signals within large complex data sets. This is a given, we know this, we've known this for a while now.

The really important question is, how important is data quality when assessing the effectiveness of these tools?

And how do firms ensure that the data feeding into their AI models is clean and therefore reliable? Vishal, you specifically mentioned this just a minute ago. Especially when it comes to mission critical applications and functions across the front office. Peter, do you want to have a stab at that? We're talking about data integrity, data reliability, and the outputs from AI models, the quality of the output is directly contingent on the quality of the data kind of feeding into the models, right?

Yeah. It's garbage in garbage out is exponentially amplified with AI. So the data quality governance, one thing that will come back, data lineage, All these things matter that much more with AI. Something we didn't touch on, but that is also heavily related to data. It's that data ontology, metadata tagging, semantic layer, all those kinds of words, which at the end of the day, really is just what are the extra attributes I can put on top of my data sets, data products to make it AI available.

What we've seen with AI is our desire is not to be dialed into one particular LLM version, one LLM model.

We want to be able to be portable. And the only way you can be portable is by building up that ontology. So that's something we're seeing with even more so than data quality is how do we have the data described? If I say the word performance, am I talking about a fun performance? Am I talking about the score in the basketball game or how I did my last round of golf?

These things matter when we're running the LLMs across it. And so if we're running LMA versus B, we want consistent results. And that's where we're really seeing even though data quality governance matters, having that metadata layer on top of it has become such a huge driver of AI usefulness.

Vish, see you nodding again.

To what extent do you see the outputs from these models being directly contingent on the quality of the data being fed into them?

Just to paraphrase what Peter was saying a little bit earlier, with AI, all you do is you're to get to that junk status a whole lot quicker. So if you're automating and you're feeding garbage into your models, you're going to get garbage. It's just out the other side. It's just going to be really quick.

That is true and I think what AI does, compresses the distance between data and the decision and that is why governance becomes much more important because as Peter said, garbage in garbage out but that compounds exponentially and very fast. So I think one of the things which firms have to look into it like, yes, data quality is important but like data lineage. Can you explain the data? Can you trace the data version and are different users on their desk using the same data or not? I think those kind of things become much more important. So I think data quality is more needed in an AI enabled world because right now as we move towards AI workflows or agentic AI, there will not be any judgment latency.

All that we have delegated to machines. So if everything is running at machine speed and then everything will fail at machine speed as well and by the time you will realize that something has gone wrong, I think that will be too late. So I think it's more at the inception like there has to be a clear accountability of the data, there have to be clear controls and there has to be full accountability whether it is the vendor who is responsible for it or whether it is the financial institutions when things go wrong. So I think AI has definitely changed the decision making capabilities but I think it's still like we are in the beginning phase, so we will have to see how it evolves over time. But as we delegate more work to AI, I think this data quality importance will increase in the future.

Vic, I'm going put the same question to you, but preface it by acknowledging that we've spoken before on the back of the research that we did in conjunction with OneTick. And one of the big, the strong, or one of your comments based on the outcome of that research was the extent to which data quality kind of trusts almost everything else when it comes to AI, right? You felt really strongly about how firms need to ensure that in order to get good quality results, you need really, really clean data feeding into your models, right, Mick?

Right. Right. And verifiably clean. How do you measure cleanliness? Right?

We actually see a large market opportunity. I'm I'm actually personally leading an effort to to launch a new a new product, which will be announced in probably a few months around data quality assurance, data quality monitoring, both intraday and end of day using verifiable metrics and and and data quality scores that can then actually be surfaced as metadata, right, on your data. So agents can, for example, assess whether the data itself is trustworthy and data can be scored and consumers of the data can look at the score of the data daily, intraday, over time to assess again whether the data is trustworthy.

So data quality itself is a new kind of metadata, which is extremely important for both human consumers of the data as well as agents. Right? And so we see data quality and as something that is absolutely essential to building trust in the data and relying on use you know, the outcomes, the insights, whether there was our, you know, derived by traditional analytics methods or or by agents. And I'm excited to see data quality's not been something that has been terribly sexy, you know, but now I think there's more and more recognition that it's absolutely essential.

And just just jumping in there. Yeah. Did. Mick had a great data trust is the most important thing.

If people trust it, then that is gonna drive everything else. So you may have the highest quality data, but if people are not sure of it, I don't really know. I don't know where it comes from. I don't know what value it is.

It's a different problem versus I already trust this data. I know it. I want to operationalize it. People will build on top of it. Wherever your most trusted set of data is, that's where your data warehouse is, that's where everyone's gonna build their reports. Everything will be built on top of your trusted datasets.

Yeah. Good point.

Moving on. Victor, I'm gonna put this to you, and again, we're gonna stay with AI for a moment. SBIRMs increasingly embed AI driven analytics and real time data into front office workflows. How should they redesign? And this is a really, really crucial point right now in the industry. How should they redesign governance, validation and operational controls, so that the speed of insight does not outpace accountability and resilience? We're talking about guardrails, we're talking about transparency, we're talking about breaks and checks and balances to ensure that actually the AI is not left completely unchecked and there are the necessary checks and balances to ensure that it does the job it's supposed to do with controls around it, right?

Yes and I think that is the core issue here.

Whenever we discuss front office modernization, we are always talking about speed and scale.

However, the deeper issue is whether the control architecture is evolving as fast as analytics architecture and I think that historically governance always comes as an afterthought.

However, what I have written about it and I think firms need to look at governance as an architecture. It has to be embedded in the architecture of analytics.

So you cannot govern anything which is running at machine speed using human insight.

So I think there is a concept going on as humans in the loop and I was reading an article in risk dot net and some regulators believe that humans in the loop is already outdated and I think that is partially true because you cannot control or validate everything coming out of AI agents.

People or firms have to look beyond that and try to find a common ground or some kind of framework where they can build, they can innovate but in a controlled manner and I think that is the key.

If humans are being kind of outdated, are we going to have agents supervising agents? Maybe some kind of regulatory agents supervising other kinds of AI applications across the industry because humans can't do it fast enough.

That is true and I think that you raised a wonderful point and I think HBR wrote about it as well. Like there is a new job vacancy coming up as an AI agent manager and their job is to manage AI agents. So yes, there is no limit to it but I think there are still some decisions which will require human interference.

A lot of things can be coded into AI agents and you can put AI agents on top of them but at some point of time, you will need accountability. You can't hold machines accountable for anything.

So for accountability, you need humans.

Mika, I'm going to put the same question to you. To what extent do you think that there is a danger across the industry that the speed at which the industry is developing right now might be outstripping the checks and balances, the guardrails that have been implemented to ensure that the AI behaves in a manner consistent with how it's supposed to?

Yeah. I mean, there certainly is risk.

Everything I've heard on this topic, you know, that Mitchell just mentioned is a hundred percent correct.

I think we're still early in the journey as we adopt agents and we're all learning collectively how to take advantage of this very powerful technology.

There absolutely needs to be some governance and some formality around how AI and data that is, you know, provided AI is acquired and validated.

I think again, I think that's another reason I kind of touched on why quantifying data quality is so important.

You need to have an objective way of measuring the quality of data that's being, you know, used as the fuel, you know, for these agentic workflows. But also the same methodology can be used to quantify, you know, the the outputs, you know, of of agents.

If that output is, it can be structured, you know, in a way that you can test it and and and score the quality. So I think to the extent possible applying quant you know, techniques to quantify the inputs and outputs to AI is one way of eliminating some of the gray associated, you know, with AI and and and helping everyone be more objective about what AI is doing. But, yeah, absolutely, governance is super important and continues to be a challenge.

Peter, do you wanna have a stab at that as well? Just kinda give maybe Century's kind of perspective on or your perspective on the whole kind of governance issue around AI right now?

Yeah. The analogy I always say is, we pick your favorite sport. We have the World Cup starting in a few weeks. We enjoy soccer, football because there are rules.

Inbounds, out of bounds.

Here's the goal. Here's what offsides is. And someone can explain offsides. That's the best LLM already.

We enjoy these things because there are rules. And that's what we need for AI to be successful. So governance, what we can do, what we can't do. What is public data versus private data, what's restricted data versus open data, all these nuances that we've talked about for years are being brought to the forefront, and being put in front of our business partners in a way that has never been there before.

Governance, we led with governance in our AI journey, which meant maybe we were a little slower at the start, but locking down that governance framework means you can start running real fast. So instead of looking at places where oops, I downloaded the wrong model, or I did this problem on your team, someone's trying to move fast and they pull an LLM that is not even licensed or appropriate for the firm.

We've already solved that case. And so now we are running faster.

One of the things Vish had said though, human in the loop is outdated.

That does ring true.

But there will be a human in the loop because, again, that accountability. So for a long time, as firms started going into AutoX and moving into that area, far as how do we execute trades at scale, and we were removing humans from that role, you still had a human who had effectively on their screen, a big red button that said pause.

And that's what that role was. So the roles are going to change.

And at least for now, I see humans in the loop being required because that legal regulatory framework is always so far behind the technology and the advancements.

We still want to be able to say, who owns this risk at the end of the day? You can't just say, well, the bots did it or AI. That's not a good answer for regulators or clients. So we are still going to have humans here, but we wanna increasingly minimize the bottlenecks of a human. Yep. The decision points are there. You're gonna build monitors and everything to observe it, but you still need a human who's gonna have a terminal on their desktop ready to pause LLM, pause output, pause trading.

Good. Okay. We've been going for about forty five minutes now. So, we need to move on.

And Mick, I'm going to put the next theme to you. You mentioned Python a little bit earlier. And one of the really stark takeaways from the research we did together was that Python is being used extensively across the industry right now, especially bespoke versions of the language.

And it's now the programming language of choice for many quant analytics and engineering teams. My question to you then is what is, to what extent is the popularity impacting this is the popularity of bespoke Python, or Python bespoke. To what extent is the popularity impacting front office workflows and supporting collaboration between trading, technology, and data functions? And perhaps the second part of the question, is there a risk that its popularity might inadvertently create some kind of new challenges for user firms around governments governance and model oversight? Mick?

Yeah. So I don't think I have any deep insight here into Python other than that it's, you know, it's no surprise how popular the language has become over the years.

You know, university graduates are taking courses in Python. There's a, you know, large pool of skilled users. The accessibility of the language makes it easy for both IT professionals and front office professionals to collaborate, to learn the language, and to learn the basics.

And there's an enormous, you know, number of libraries and and and open source packages of, you know, devoted to data analytics that again, you know, amplify the, you know, the efficacy of Python and and and that knowledge. So you know, the language itself continues to improve. Right? Python's biggest Achilles' heel was performance.

Yes. It's still not as fast as some compiled languages, and it's not meant for everything. I wouldn't necessarily build a trading system or an execution system in Python. But as far as analytics, modeling, machine learning, AI analytics, you know, data access APIs, It's proven itself as a, you know, very, very effective, easy to use language.

And I I don't really see, you know, any any downsides or that Python has actually been around for a long time now. And so that there's a lot of knowledge even that has been accumulated around managing Python packages, managing Python projects, etcetera. So I think it's pretty much understood at this point that that's the language that most quants, data analysts, people working in AI machine learning are using want to learn.

Peter, do you want to take a stab at that as well? Kind of comment. I don't know whether you can comment from your perspective on the popularity of Python and especially bespoke versions of language, the programming language and the extent to which it's used extensively across the front office, specifically for functions that Mick just laid out. Peter?

Yeah, it's, you know, Python's greatest problem is Python.

And it's not so much we have all these different bespoke versions, it's the libraries. So with various quant libraries as an open source platform, people will build something that's incredible and then stop support for it. And you'll find, hey, this Python version, half my quant libraries no longer work. What is our alternative? And that's been the biggest challenge with Python because it's so ubiquitous in the market now.

Most of our college grads, no matter what role they're coming into the firm, have worked in Python. And so you see now people in HR with Jupyter Notebooks, you see people in roles that you would never even imagine coding, writing Python code. And so that is the reality. And it's presented a new challenge as far as which versions of Python do we support? How do we certify a new version? And that changed the release process.

It's a good problem. You want people to be efficient. You want people to be highly productive, but it is an issue, especially with the libraries and not so much again, custom Python versions, just custom libraries.

Vish, I see that you're nodding there and do you want to take a stab at that as well? Obviously, you should imagine you're very familiar with the language and also you're familiar with the relationship between your front office staff members etc. And also the guys in the middle office to a certain extent I should imagine. In terms of their kind of hands on use with the language. Do you want to talk a little bit about specifically what it allows them to do? And is there a risk, Peter mentioned that Python's biggest problem is Python.

Is there a risk that its popularity might inadvertently create new challenges for user firms around governance and model oversight?

Definitely, I think Python has definitely become the front office language for experimentation.

The way I see Python is the new Excel.

Right now you go to trading floors, everyone is writing in Python.

However, like I think as Mick mentioned or I think Peter that not everything is made for Python like low latency Monte Carlo simulations. I think they are still being coded using C++. Now the biggest challenge of Python is all these people are writing code using bespoke Python versions or these libraries but as their usage increases, more critical code goes into these bespoke versions.

From an IT perspective, how do you govern these?

What will be your business continuity plan?

All these things become like a shadow IT and they keep on creating codes. There are times which I have no idea what was built and I think Peter mentioned like we have no way of supporting it. So I think that is one of the challenges with Python and Python is not the risk. I think Python is a very good language because it allows fast experimentation, more collaboration. So it's definitely used heavily from a front office applications perspective.

The biggest risk with Python is the ungoverned Python like that is the problem. So Python will remain the language of innovation but we need to create an engineering discipline around it.

Good, good, good, Okay, we've got maybe ten minutes left, so moving on, Mick and I'm gonna put this question to you, given your cloud experience and your cloud specialty. As firms increased their reliance on cloud ecosystems, Mick, how concerned should there be about concentration risk escalating costs and long term vendor lock in?

And beyond pure cost considerations, what are the key criteria firms should consider when vetting cloud services and providers? And how important are time to market considerations in this context? So a lot to unpack there, Mick. So escalating costs, long term vendor lock in, all those issues. And then how should firms on both sides of the industry, in your opinion, kind of vet and evaluate providers of cloud services, you know, to support the business going forward, Nick?

Yeah. Like you said, a lot there to unpack. So let's – excuse me – Let's start with the cost consideration.

So everyone knows that when you start your cloud journey and you adopt cloud, controlling costs is critical.

Most of the cloud platforms do provide tools that allow an organization to implement a FinOps program with alerts, with budgets.

And I can emphasize more the importance of investing, you know, in discipline and process around those things, you know, whether it be Azure, GCP, AWS.

We've all probably had an experience or at least heard of an experience, you know, where someone spins up a, you know, a virtual machine and forgets about it and then gets an enormous bill. It's even more important now with AI tools. Right? So now it's all happening in the cloud.

Right? We got we're all learning the new language of tokens, right, in context and the cost per token and all that kind of stuff. And I’m starting to, again, you know, hear stories, you know, about these enormous bills, you know, from Anthropic or OpenAI, you know, some developer who has left his agent running over the weekend and spun off other agents and whatnot. So I think it's become even more imperative.

Again, with the power of the cloud and AIs all in the cloud, putting in place measures to and and discipline around FinOps is extremely important more so than ever.

And as far as evaluating vendors in the cloud, I don't, again, think there's anything new here, whether you're a vendor providing a service in the cloud or not. I think a lot of the traditional ways of vetting a vendor still apply.

You know, what is the reputation of that vendor?

You know, what guarantees do they provide?

You know, you know, what contractually, you know, is the vendor obligated to provide, let's say, in terms of SLAs of, you know, that data, that vendor providing data, let's say, from an exchange, you know, how long after the close? Data quality guarantees. Right? What is that vendor doing to measure the quality of the data?

And can that vendor make those data quality guarantees and transparent to you. Right? So you're aware if there are issues with data, whether it's available, whether it's complete, etcetera, Is that transparent? Right?

So those are some of the considerations that come to mind. There's a lot of other things. That's a big, you know, big, question there that you asked.

Yeah. Yeah. Yeah. Good. Peter, do you wanna, take a stab at that as well? And then, Vish, you can have the final word.

So Peter, just to paraphrase, will you comment on escalating costs and long term vendor lock in? And then on the other hand, how should firms like American Century, what are the kind of criteria that you would typically consider when looking at cloud vendors?

Yeah, one of the things we've seen with escalating costs, this goes back to kind of the first question, As firms move to cloud, there was this big push about a decade ago to just get everything in the cloud. And so a lot of firms did a lift and shift approach.

And where you see these costs kind of running high would be on some of this legacy architecture where we did not look at it to take advantage of the cloud. The cloud does certain things very well. It's not optimal for other things that might be in a legacy pattern. So one of the low hanging fruits firms can do is look at, hey, what if we migrate to the cloud a few years ago? Revisit some of those decisions architectures. Another thing you look at is that kind of, we'll say that vendor lock in that concentration.

If you want to have the most optimal cloud, you have to be more locked in with the vendor. If you're implementing a container strategy and you want that cloud portability, that will cost more than if you're doing something very native to that particular cloud provider. And that is a balance the firm has to make as a decision. Do I want to have a strategy that allows me to port across the hyperscalers or am I all in?

Because you will be more efficient if you kind of say, alright, we're all in.

But certain instances, and this goes into that vendor selection item is, we do want a vendor to have multi cloud. We want a vendor to allow us to have that choice, that portability and transparency, because vendors we know are also paying cloud costs.

And so, what is that value at above the compute costs for our cloud of a vendor?

And we want to make sure we have that measurement, that visibility as we onboard new vendors.

Vish, do you want to have a stab at that as well just to give the kind of the sell side perspective on all these cloud issues?

Yes and I think like it's I have seen like cell site firms like they definitely diversify their risk on the cloud side like they will have something on Azure, something on AWS, something on other vendors and I think that again like that is a leadership problem than a technology problem because to take the full benefits from a cloud provider, you need to make it efficient and it can only be efficient when you are vendor logged in. If you are using multiple vendors, you will have different processes, different workflows and also how these vendors interact with each other. If AWS has services which can be run on Azure and vice versa. So that is one of the biggest problems.

Another thing which I have seen in the front office on the sell-side is the compute problem and I think Peter mentioned it.

Compute is becoming the new commodity and if you see CME has already started the process of launching new compute features and those compute features actually are very good for the industry and from an IT perspective, they will help you give you the spot rate and the future rate. So they will have a forward curve. So industries like any industry who has AI usage which they anticipate is benign threes, they can look at the forward curve from compute futures and then they can decide whether they want long term vendor lock in or they want short term vendor lock in or if they need to buy the hardware or they need to rent the hardware. So I think that is something which is very very interesting as we are moving forward like we will see more of this compute features become liquid and it will see all the market participants whether it is cloud provider, whether it is GPU producers or the market participants. So they all will have something in that market.

Good, okay. We've been going for just on an hour now and so we need to wrap up. But before we go, I'd like to just ask everybody to comment very briefly on the future of front office technology of the industry's front office technology landscape evolving over let's say the next three to five years, what might it look like?

So Peter, I just want to give you thirty or forty five seconds to wrap this up and then Vishal and then finally, Mick, you can have the final word. Is it inevitable that the industry will continue to move toward fully cloud based and cloud native API driven operating models? Or are there practical and regulatory constraints that might slow down that move? Peter, forty five seconds.

Sure. The hybrid will be the future. And there will be places where regulatory constraints, especially in the EU, where the data has to stay there. And so for certain firms, may make more sense to store it on prem there as opposed to working through the cloud issues and challenges that provides.

The use cases for cloud, that's one of those places where firms that are operating in this hybrid legacy model need to take a step back and say, where do we want our compute to be running? And what is our requirements? What are our usage patterns? If you have a twenty four by seven market price or risk calculation engine that's crunching through a lot of data in out, that may have to stay on prem without a substantial rearchitecture.

Because that is something that is gonna have very high cost in the cloud. But if you have some batch based jobs, stuff that is just running overnight or pre market, post market, etcetera, Those are great use cases for cloud. Because if you can go wide, spend more compute, run hot, you will catch up, you'll go faster. And it's a great tool to be able to have that.

And so I see firms doing both in the future, particularly as they hit that level of maturity.

Smaller firms will be one hundred percent cloud, but larger firms, especially firms that have a long history, they will be hybrid.

Vish, do you agree with Peter's assessment there? Forty five seconds just to wrap up.

So I think the industry is definitely moving towards cloud native and API driven operating models but the front office will be on a hybrid operating model and there are various reasons for it regulation, latency, vendor dependency and very complex workflows.

So the firms who will come out of this will not be the ones which migrate fast but the firms like which will combine speed, scale and resilience and governance and that is the key and I think the direction is definitely cloud native but the more interesting question is whether governance and operating models are also becoming AI and cloud native.

So the next phase of front office modernization is not just like technology, it is more control model and governance modernization.

Mick final words to you for today's session. What does the future look like from your perspective with respect to cloud and the various operating models that buy side and sell side firms choose to run their technology and data.

Yeah. There's always danger trying to predict the future. I'll do my best. So just to extrapolate current trends.

So the cloud is, you know, one part compute and and sort of one part data. Right? You think about, you know, compute versus storage.

The theme of cloud for many years has been largely on the compute model. And that continues to be an important, you know, benefit of the cloud.

The way you pay for compute, the elasticity of compute, the ease of procuring compute, you know, on demand. Those are super important. However, I'm seeing maybe the locus sort of the gravity shifting more towards the data story. We haven't even talked about the investment in open data formats such as Parquet and Iceberg and the benefits that that provides in terms of interoperability across compute platforms.

That's super important.

Data governance, data quality, we have those things. I think those will only increase in importance and will eclipse, you know, the focus that's been historically on compute as something that the cloud delivers. The ability to get access to data quickly, easily on demand through open common APIs and programming languages enabled, you know, by the cloud and the networks, the high speed networks, you know, that we all enjoy even for this call. Right?

So I think, you know, data's always been important. It's always been something that we talk about and when we talk about cloud, I think data is really moving to the forefront now in the cloud conversation.

Yep.

Okay. Good. Good. That's a really good point to finish our conversation on today, Mick. So thanks for that. That just leads me to thank today's panelists for their amazing hour-long session with us.

So Peter Ottomanelli from American Century Investments. Peter, thanks very much for your time. Vishal Gupta from Mizuho. Vishal, thanks for your help with this.

And of course, Mick Hittesdorf from OneTick. OneTick was today's sponsor. Mick, you've been amazing. Thank you.

And I look forward to catching up with all of you at some point in the not too distant future. Thank you and have a good rest of your day.

Okay, thanks Victor.

Thanks everyone. Cheers.