Banks choosing the smartest AI model may be solving yesterday's problem

Written by Russell Pereira

Jun 10, 2026
8 min

As benchmark gaps narrow and model prices fall, a broader debate on frontier artificial intelligence points to a new enterprise question: how safely and economically can AI be embedded into institutional data, controls and workflows?

Banks have spent much of the past two years asking which artificial intelligence (AI) model is the smartest. That question made sense when the performance gap between leading AI systems and their challengers appeared wide, visible and commercially meaningful. It gave technology teams, innovation units and procurement committees a clear signal, even if an incomplete one, when comparing vendors.

At SuperAI, a broader discussion on frontier AI models raised issues that matter as organisations move from experimentation to regulated deployment. Hemant Mohapatra, partner at Lightspeed India Partners, argued that the debate has moved beyond leaderboard performance. "Today, that layer is getting commoditised," Mohapatra observed. "The gaps between the previous generation and next generation are shrinking."

In Mohapatra's view, each additional improvement in model capability beyond a certain point requires substantially more capital, making pricing a more important selection variable. Commoditisation, he said, does not mean the technology becomes free or loses value. "It just means that it is fungible," he said. "Intelligence from model one is no different from intelligence from model two. Oil from gas station one is no different from oil from gas station two." Model quality still matters, but it is becoming a threshold requirement rather than the main source of advantage.

Banks are entering a more demanding stage of AI adoption, moving from low-risk productivity pilots into customer operations, compliance review, fraud monitoring, onboarding and credit support, where cost, controls, accountability and resilience matter as much as raw model capability.

A model that performs well in public benchmarks may still fail internal bank tests if it cannot run within approved data environments, meet local regulatory requirements, integrate with existing workflows, or operate at a cost that makes high-volume use cases viable. The relevant question is not which model is the smartest in the abstract. It is which model can become part of the bank's operating fabric.

Model performance is only one part of the decision

Cherie Shi, global business manager at MiniMax, described frontier capability in terms of adoption rather than leaderboard position. "How many people in the real world are actually using your frontier models every day?" she asked.

A model can perform well in a test and still be unsuitable for a bank that must understand, justify and record AI-supported outputs across large volumes of interactions. Readiness for live use depends on whether the institution can explain how an answer was generated, monitor the model's use and keep it within approved controls.

Shi also pointed to a pricing shift. She said newer large language models were being priced at a fraction of comparable frontier models at the time of the discussion. As model prices fall and performance gaps narrow, banks will find it harder to justify selection based only on marginal performance differences. Cost matters because many banking AI use cases involve repeated, high-volume activity, including customer service support, internal knowledge search, compliance review, fraud alert triage and document processing.

The value is moving from the model to institutional context

Geoff Soon, vice president of revenue for Asia Pacific at Mistral AI, framed AI as moving from an extractive phase, where value accrues to producing capability, to a distributive phase, where value lies in applying that capability inside industries and workflows. "It's no longer important to be the best oil extractor," Soon argued.

Banks will not gain durable advantage simply by accessing the same model that competitors can also buy. They gain advantage when they use AI to reflect their own customer base, product rules, credit history, compliance policies, risk appetite, service standards and operational processes.

The model supplies capability, but institutional context determines whether that capability becomes useful, safe and differentiated. In a bank, that context includes proprietary data, policies, controls and operating knowledge. Soon made this point directly: "Subscribing to an application programming interface (API) to a very powerful general intelligence without imbuing it with your enterprise context is an anomaly. It's just a temporary productivity improvement."

Access alone does not create durable advantage if the model does not understand the bank's data, controls and workflow logic. Customer service shows why institutional context matters. AI that answers customer queries must also apply customer policies, escalation rules, product knowledge and conduct standards consistently.

The model needs to connect to approved internal data, policies, risk controls and escalation rules before it can support decisions or customer-facing processes. That creates a different asset from giving employees access to a general chatbot.

Banks need to separate experimentation from controlled deployment

General-purpose models can help teams test ideas quickly, while more specialised tools can support validated use cases more efficiently. The obligations change when sensitive data enters the workflow at scale.

Live use cases require the bank to manage the operating environment around the model, including access rights, data flows, monitoring, governance, incident response and accountability. Once AI touches customer records, credit decisions, compliance processes, fraud review or regulated communications, the bank must assess where data is stored and processed. It must also determine whether outputs can be audited, how access is controlled, how the model behaves and whether the arrangement is operationally resilient.

At that stage, the issue is not whether a model can produce a good answer. It is whether the bank can rely on it inside a controlled process. Banks cannot separate AI performance from the obligations that govern customer data, conduct, outsourcing, resilience and accountability.

Sovereignty and control are becoming banking issues

Data sovereignty and control become central once AI moves beyond low-risk internal drafts into onboarding, risk review or customer servicing. Banks must ensure data remains subject to the laws and regulatory expectations of the jurisdiction where it is collected, stored or processed. Once sensitive data enters the process, the bank must know where the model runs, where the data flows, who can access it, how outputs are monitored and whether the arrangement can withstand regulatory scrutiny.

Asian banks also face a concentration-risk question. Soon stated the point clearly: "It's really important that organisations everywhere know that it's not just a two-horse race, where you have the option of China or the United States (US) when it comes to a choice of AI partner." Institutions operating across markets with different data, outsourcing and technology-risk requirements need procurement choices that support resilience as well as capability.

Shi noted that demand for open-source models deployable in local data centres was strong across Southeast Asia because of privacy and local deployment requirements. Across the region, the relevance lies in deployment control rather than in any single provider's model. Banks need approaches that align with local rules, internal risk policies and the expectations of regulators who may ask where data flows, who can access it and how the bank controls the system.

Open models matter less as an ideology than as an architectural option. Banks may use cloud-based systems for experimentation, locally deployable models for sensitive workflows and specialised applications for defined business functions. They do not need to resolve the philosophical argument about open access, but they do need to test what any model approach means for control, support, sustainability and long-term vendor incentives.

Vendor durability belongs in the AI checklist

The same production lens changes how banks should assess vendor risk. Mohapatra argued that model providers face structural pressure unless they control more of the infrastructure stack, from models to graphics processing units, energy and land. Commoditisation may benefit users by lowering costs and broadening access, but it also puts pressure on model providers' business models.

Banks already assess technology vendors for resilience, service quality, regulatory acceptability and long-term viability. They should apply the same discipline to AI model providers, testing deployment control, data sovereignty, integration depth, monitoring, cost at scale, auditability, vendor support and the ability to absorb bank-specific context. A provider may meet institutional requirements if it supports local deployment, language needs, data controls or specific banking workflows, but suitability for the operating environment should matter more than vendor positioning.

The question is whether the operating model around the model can support regulated deployment over time, including service levels, regulatory change and bank control requirements.

From model access to institutional capability

Enterprise AI selection is moving from model ranking towards deployment readiness, governance and cost at scale. Banks should treat model choice as part of the wider AI operating model: which data can be used, where it can be processed, how outputs are validated, who remains accountable, and whether the provider can support regulated deployment over time.

AI will create more durable value when it is built into the controls, data architecture and business processes that already define the bank, rather than treated as a standalone tool or vendor subscription. That is where AI moves from generic intelligence to institutional capability, and where banks create operating capability that is harder to replicate through vendor access alone.