The once buzzy sector has fallen on hard times as debt gets more expensive, and consolidation seems inevitable.
Ken Beinert is Chief Technology & Operations Officer at London Stock Exchange Group (LSEG), where he leads the development of its technical and operational architecture. The Goldman Sachs veteran joined the global markets infrastructure and data provider in summer 2025 – and is responsible for its AI transformation strategy.
The big focus? “Enabling sustainable growth and stability of our customers and their communities.” Among his tactical challenges: delivering that in an exceptionally fast-moving technology landscape – one where data discipline, innovation, and fiscal precision are all paramount. Beinert joined The Tokenomics Foundation’s Executive Director J.R. Storment to talk AI agents, economics, governance, and more.
The below is from the transcript of their conversation, lightly edited for brevity.
Q: Tell us about your AI strategy
“We think about our AI transformation strategy really in three pillars.
“The first is AI-ready data, where we're focused on making sure that our customers have access to our trusted high quality data in APIs and formats that are extremely accessible to AI. The second is transformative products where we embed AI directly into our existing products and evolve those products so that they're truly AI-native, and the third, of course, is what we call intelligent enterprise, where we're focused on enabling our internal colleagues with the right tools and practices.”
Q: When we think about AI economics, [The Tokenomics Foundation] finds that it's about the total cost of AI, because models and tokens are often a quarter of the spend. When we're talking about AI, what's included in that equation for you?”
15:31 When we think about the investment for an AI solution, I think really about it in two different phases. The first is [to…] focus on the problem that we're trying to solve, secondly on the success metrics that we'll use, the spend, the quality, the user experience are all part of defining the problem and defining the right solution.
We're not just planning for token spend. We're also planning for other infrastructure.. We're planning for data cleansing and preparation to make sure that the data is ready for AI solutions, and then of course we're also planning ahead for real-time guardrails, recurring evals, and comprehensive observability and telemetry, so that we can manage both the cost and the quality of our AI solutions over time.
Q: The Stake of Tokenomics survey showed that companies are increasingly investing in different model options [and building] governance layers in. How do you ensure that [your teams are] using the right tool for the job?
“One of the factors that I think is most key to model selection is doing comprehensive evals of a model in situ for each solution before we launch it, and then of course continuing to monitor those evals over time, and determining as new models become available, as new solutions become available, whether or not we get better outcomes, whether it is user experience, latency, or cost optimization…
Q: We've got frontier models that everybody's using. We've got open weight models. We've got SLMs. Are you using a mix of those? What does that look like?
We are using a mix of them. You can imagine quite a lot of our customer-facing solutions and our more advanced solutions do leverage frontier models, but increasingly we're finding that many of our solutions can be solved with non-frontier models, smaller models, in some cases custom models. We're beginning to see open weight models that really compete successfully with closed weight models, and that's both at the frontier level of model as well as a smaller level of model…
Q: Let's dig in a little bit about how the variability of AI models is cascading into potentially pricing model changes for you, or maybe just margin management. In the historic capex-heavy world, there was more straight predictability on how much you were going to spend. And with AI usage, both for developer productivity as well as the mission-critical AI, there's a lot less predictability. So, how are you seeing that variability cascade into how you're having to price for your customers?
I think the most important part of pricing AI-based solutions is to make sure we understand the business case upfront, and that we do very thorough evaling for quality and cost ahead of time, so we do understand the unit economics.
The second most important part of that is to bake in the right assumptions into those unit economics, so that we have the opportunity to continue to make them successful over time. Like the rest of the industry, certainly what we're seeing is that prices change very rapidly in multiple dimensions for potential AI solutions, but at the same time, what we're often seeing is that unit economics for an existing solution can improve over time, especially as newer models become available or as we tune our solutions based on our observations through our own telemetry and ongoing evals.
Overall cost, on the other hand, certainly can increase as we see customers and colleagues using those same products even more.
Q: You mentioned unit economics a few times. Is that a granular unit economic, like our cost to serve this customer, or is it a bigger concept?
The unit economics really can vary based on a specific use case. But for me, the example that comes most immediately, most accessibly to mind, is cost per task, where what we really want to understand are the typical tasks that a user uses a given AI solution for, so that we can develop the right evals for each of those tasks to measure both accuracy, quality, latency, feel and experience as well as cost.
Q: How do you enable those trade-offs between cost, value, speed, latency, and are there certain jobs or use cases where you heavily index toward one versus another?
Within LSEG, we have a number of use cases where we use AI for an input to our products, but we [also] have data preparation, data cleansing work that runs perhaps overnight and essentially is not latency sensitive, not part of the direct user experience. There, clearly we have an even greater range of models that we can select from, as opposed to use cases where a customer is engaging directly in an experience with a model. If we're talking again, 12 months from now, one problem that I'd love to see us as an industry solve is the challenge of running agents safely at scale. Today, when we select an agent platform, we're selecting solutions for identity management, entitlements, containerization, runtime infrastructure, sandboxes, and of course observability and telemetry. And each of the solutions that we could use has its own differences, its own potential gaps, which can make it quite hard to switch between platforms and between models and between providers. If we solve this problem, it will really help the industry as a whole to deliver better AI solutions.
Q: How are you driving accountability for AI spend in the firm?
“Well, first and foremost, we believe that the person who owns the P&L for the product also owns the AI spend. That aligns incentives and responsibility.
And secondly, we believe in providing central platforms and controls around AI, both for evals and cost controls, as a joint venture between enterprise AI and finance. And the reason for that is that while the accountability needs to remain with the P&L owner, centrally we have the opportunity to stay abreast of best practices and transformative AI solutions that can be rolled out across these use cases.”
Q: How does Tokenomics differ from FinOps for you?
I see AI economics really, in some ways, as an evolution of cloud FinOps, clearly it is more complex. The pace of change of model selection is much greater, with changes in new types of compute, storage, network infrastructure, etc. There's much more variability in cost, and there's just so many different dimensions of cost. For example, caching and fine tuning… These are things that FinOps didn't have to deal with!
Look, I think that the practices that we have in place for FinOps today, we're going to continue to have all those same practices. But we're going to raise the standard for how we do financial management so that it is more real-time… add an increased element of managing for user experience, because certainly what we find in AI, unlike compute, unlike storage, is that there's a much greater element of variable user
The thing that I'm most excited about is understanding the real potential of AI and putting it in place within our organization, it seems like every day there's new insights into practices that we can apply. Almost every day we're seeing new models that have capabilities in advance of what we expected, but entirely new model paradigms that enable use cases that literally did not seem feasible even a week ago.
Delivered in partnership with the Tokenomics Foundation. To learn more read the 2026 State of Tokenomics report.
HSBC’s Group CTO Mario Shamtani likes fast cars and track days in a Radical. It’s hard, from a distance, to know how radical he is being with his reform efforts. But it is clear from previous conversations that The Stack has had with others in the organisation, that trying to drive change fast at HSBC has sometimes been a bruising experience. Many reform-minded technologists have left after a few years, chastened and a little battle-sore. It’s hard to transform people, process, and technology at a company over 160 years old, active in 57 countries and with over $3 trillion in balance sheet assets; change-aversion is also a thing and for years the unspoken motto may as well have been “move slowly and please don’t break anything; particularly the mainframes.”
HSBC is notably more reform-minded under Group CEO George Elhedery, who took the role in September 2024. He has reorganised its global operations into four business divisions, effective January 1, 2025, and there is a renewed sense of urgency at the bank around organisational modernisation; something felt across a sprawling technology function – some 60,000 engineers – with a mix of trepidation and anticipation. New leadership abounds in many quarters, including the CTO’s office.
The Stack joined Shamtani for an exclusive first interview. We talked mainframe modernisation, streamlining container platforms, AI “boiling our brains” and more.
Group CTO Shamtani joined HSBC in 2024. He is a technologist’s technologist – and has been since his degree in computer science back in the halcyon days of Manchester in the early ‘90s. His career has taken him from Citi – where he was global head of fixed income and currencies technology – to JPMorganChase, where he was on the leadership team as head of markets technology for its Commercial Investments Bank.
Sitting down in the bank’s Canary Wharf headquarters for an exclusive interview with The Stack, and asked to summarise his priorities, Shamtani describes himself as focused on “modernising infrastructure and building an optimal hosting strategy; driving our data strategy; simplifying our data architecture; delivering value for the business; improving automation of controls; AI for tech – that means productivity of our engineering, and delivering enablement for the rest of the business in terms of all of our colleagues using AI across across their work” – and more; a sweeping mandate.
That’s a smorgasbord of entry points for a journalist. Where to start?
It’s a bank: mainframes, let’s start with the mainframes.
HSBC, like most large banks with a storied history, is a typical case of old meets new on the infrastructure side. Alongside the approximately 7,000 Kubernetes clusters, 2.4 million containers, nearly 65,000 namespaces and more than 1,900 IT services across public and private cloud, is a stubborn suite of mission-critical applications written in COBOL and other languages from Times of Lore, running on mainframes.
What’s the plan? (Plenty of organisations continue to try and get out, at great time, expense, and the sweat of semi-retired developers.) Asked if there is a bank-wide directive to Exit The Mainframe, Shamtani takes a beat: “When Stuart [Group CIO Stuart Riley, who took on the role in February 2024] first arrived here, there was a plan to do that, and he didn't believe the plan was credible and would work. So we've taken a much more incremental approach to hollow them out,” he responds.
What does that mean?
“That means take capabilities out of them that don't belong there,” he says, pointing to the need to access mainframe data and adding that “you want to sort of take some of the orchestration out… hollow it out means simplify them, take functionality out.”
“Mainframes have a purpose in terms of large… transactions. They're also cheaper to run [but] harder to change… they're tightly coupled, and therefore when you make a change, you have to understand what that affects,” HSBC’s CTO adds – suggesting (without going into further detail) that there is also an ongoing technology leadership debate at the bank around whether mainframes are, perhaps, more secure.
“Mainframe providers don't work in the same way as the software providers generally do, where they'll say to you, ‘this piece of software's out of date now. You can't use it anymore,’ Shamtani muses. “Mainframe providers don't do that. They want you to keep using them, because you have to keep paying for support…”
He is, he suggests, working closely with IBM on this (“we actually have a very good relationship with IBM”) and pressing for a more proactive approach from the world’s last mainframe-maker on which applications and systems it sees as most at need of modernisation – adding that even Big Blue struggles with skills: “If you’ve got something on an operating system that was modern 40 years ago, it's very hard to keep people around that want to work on that. Even if you're IBM.
“So, mainframe modernisation is something we're doing incrementally.
“Hollowing out” these mainframes is also part of a larger data priority.
There’s no good AI without good data. HSBC, with its globally scattered, architecturally diverse, range of businesses, has some work to do on this front.
Asked by The Stack what the “the stickiest and most intractable challenge” at the bank is, Shamtani says “Probably the most difficult is data, I would say, because it touches every aspect of the bank… everything gets boiled down to a data problem.”
He adds: “I think we are getting lots of traction there in terms of the way we're executing around controls and automation and risk reduction; architectural simplification and tying that into our AI enablement, and then driving business value.”
HSBC appointed its first Chief AI Officer, David Rice, on April 1, for extra muscle here.
Rice, previously COO for HSBC’s Corporate and Institutional Banking business, is an operator and HSBC veteran who knows how to move the lines of business along.
How do they work together?
Shamtani describes Rice as being focused on “deeper reimagining of business workflows… working with all of our colleagues around skills uplift; also working with regulators and the total second and third line around building the right controls and risk processes around how we think about AI at scale. My part [...] is delivering the enablement technologies, the platforms… an AI platform that starts to codify controls and codify our ability to serve different use cases; so we're sort of two-in-the-box.”)
More broadly, HSBC has made progress with its infrastructure modernisation, says Shamtani, explaining: “I think we were very quick to move to the public cloud.
He is focused on putting in “much more of an optimal hosting strategy, modernising some of our internal infrastructure and going to a private cloud,” the CTO says.
What does he mean by a “much more optimal hosting strategy?” The Stack asks.
Is HSBC repatriating some cloud workloads?
Shamtani does not answer that latter question outright.
The bank is putting workloads where they most “cost-effective,” whilst being mindful of sovereignty requirements, he says. “We've done a lot of work around FinOps… work to either mature workloads in terms of being efficient, or to pivot them.”
Critically, the bank has been “pretty good” at containerising, but has “ended up with multiple container platforms; we're now merging those into a much more cohesive container environment,” he explains. It is doing that via an internal application platform called app.HSBC that brings multiple container and hosting platforms together with a common platform interface, customer API and control plane.
Asked for more detail in a subsequent email exchange, he explains that “the aim is to give teams a consistent paved path from code or container through build, vulnerability scanning, change management, artefact promotion and production deployment… Rather than each team assembling its own pipeline, credentials, approval process, release evidence, observability and operational controls, teams declare what their application needs and consume a managed platform contract.
The platform is “declarative and infrastructure-agnostic,” he says.
“A team can specify requirements and constraints such as region, data residency and service levels; app.hsbc then determines how those requirements are implemented across Kubernetes, virtual machines, AWS, Google Cloud and on-premise infrastructure. The intended model is for workloads to be portable and, where appropriate, stateless, allowing the platform to optimise placement across providers.”
app.HSBC also exposes managed capabilities, including databases, queues, caches, storage, event streaming, API gateways and data ingestion, through a single console.
Its adoption moves responsibility for more of the implementation, controls and ongoing maintenance from individual teams to platform engineers.
On the AI front, there has been a lot of “localised innovation” he adds. (The bank is using AI across customer service, cybersecurity, fraud detection, risk assessment and transaction monitoring, as well as to support credit analysis write-ups, it says.)
HSBC’s CTO has a central AI engineering team in his group with “strong talent” he says. “We're beginning to build capability up… we're starting to use smaller language models for very bespoke tasks, and also where we're trying to get more predictability, more control over the outcomes, and more deterministic outcomes,” he adds.
Where’s the alpha here? The Stack asks.
"The alpha is fundamentally serving our clients better… to be more trusted, to be able to serve them in the best ways possible to create the best experiences for them,” he says, adding “we do want to retain human judgment. We do want to retain trust, so it is important that we are still, innately human in how we approach our customers.”
He concludes “It can feel overwhelming when there's so much change happening.”
“Earlier this year it was boiling our brains because there was so much happening so quickly. [but] we're trying to take people on a journey with us, and particularly with AI, where people are feeling really anxious, we really care about humans being in the loop. That doesn't mean that we're not automating a lot. It doesn't mean that we're not going to use AI to create even better experiences for our customers…
“But it's a great time to be a technologist. I really believe in a brighter future.”
For Amsterdam-based exchange Bitvavo, the speed at which its customers can trade is everything.
"Every network latency that we cut, or every request that we serve faster, means a lot of revenue, a lot of opportunities, also for our users," Bitvavo engineering leader Ibrahim El Moufti told The Stack.
"We deal with a lot with high frequency trading and market makers and low latency systems, and our systems need to serve those requests as soon as possible," he said.
And while increasing speed by milliseconds, and sometimes nanoseconds, can make a difference for its customers, like many other companies, Bitvavo wants to focus on managing its core business rather than infrastructure. The company's. requirements are a system with zero downtime and the ability to accommodate bursty spikes in traffic.
"Imagine you have a busy day in crypto," Moufti said, perhaps due to a typical Elon Musk tweet. "Suddenly we have a high spike in traffic that was unprecedented. And we want to deal with those events really fast."
A private datacenter that requires a phone call to provision more capacity would simply not cut it. So, from its earliest days, Bitvavo has been cloud-native, and that decision has proven wise in a highly cyclical market for a company that wants to iterate fast.
When there is a surge in interest, Moufti said, its system centred on Kubernetes through Amazon EKS scales automatically, and cleanly, with low operational overhead.
Bitvavo particularly appreciates Aurora's separation of compute and storage, which AWS says improves availability, failover capabilities and operational efficiency compared with self-managed database deployments. For Bitvavo, those characteristics have become increasingly important as regulatory requirements have tightened.
The company recently completed work associated with Europe's Digital Operational Resilience Act (DORA), which requires financial institutions and critical service providers to demonstrate operational resilience and disaster recovery capabilities.
Moufti said Aurora's cross-region failover capabilities significantly reduced the engineering effort required to test and demonstrate resilience. Tasks that once demanded detailed playbooks, dedicated war rooms and extensive operational preparation are now more routine, allowing teams to focus on customer-facing development rather than infrastructure management.
According to the Bitvavo engineering leader, Aurora beat out other AWS services with its low operational overhead.
"We used RDS, for example. We tried managing our own databases on EC2s. I think the reason Aurora really sticks out for us is its low operational effort… We don't want to deal with the complexity of managing databases on the cloud."
The cloud-first strategy also shapes Bitvavo's approach to artificial intelligence. Like many technology companies, the exchange is attempting to move beyond AI-assisted workflows towards what Moufti described as becoming "AI-native". The goal is to mature past giving employees access to generative AI tools, to integrating AI throughout engineering, product, legal and operational processes.
One example is incident management. Bitvavo is experimenting with AI agents that can analyse logs, metrics and alerts during production incidents, helping engineers identify likely causes more quickly. Rather than rearchitecting systems around AI, Moufti said the larger challenge has been improving documentation and knowledge management so that agents can understand internal systems and processes. In practice, that has meant changing how product specifications, architectural decisions and operational knowledge are recorded.
AWS is also becoming part of that AI strategy. Bitvavo recently began using Amazon Bedrock and AWS's emerging agent tooling, attracted in part by the ability to route tasks to different models while maintaining governance controls. For a regulated financial platform, Moufti said, identity management and access controls remain as important as model performance.
This interview was delivered in partnership with AWS.
