Banking transformation used to be episodic. An institution could replace a core, renew infrastructure and then spend several years stabilising the new estate. That cadence no longer matches the environment in which banks operate. Customer behaviour, regulation, fraud patterns and technology now move while multi-year programmes are still being delivered.

The strategic question is therefore no longer simply whether banks adopt cloud or AI. It is whether they can make repeated change a normal institutional capability without destabilising the core, financial processing, compromising control or exhausting the organisation. Modernisation is becoming less a sequence of destination projects and more a permanent condition of banking that requires a different operating model from banks.

That was the central concern at a banking infrastructure modernisation roundtable held during The Asian Banker Thailand Awards, which brought together senior leaders from Siam Commercial Bank, Bangkok Bank, Kasikornbank, KBTG, TMBThanachart Bank, TISCO Financial Group, UOB Thailand, Krungthai Bank, Eximbank, Krungsri Securities, AWS and Sunline.

The discussion moved quickly beyond infrastructure as a technology conversation. The more important issue was how a bank should organise itself when the pressures to change are continuous, response windows are shortening and the consequences of failure remain material.

The first pressure is organisational, not technological

Executives began with concerns that were largely non-technical. Business leaders pointed to changing and volatile markets, changing customer behaviour, faster competitors and the need to make better, more responsible decisions. Technology leaders raised cost scrutiny, scarce cloud and AI skills, fading knowledge of legacy platforms and the difficulty of integrating new talent into established structures.

A recurring frustration was the boundary between business and technology. Business teams increasingly need enough technology understanding to redesign products and processes; technology teams need commercial outcomes rather than a list of systems to replace. Risk, compliance and operations cannot remain downstream reviewers when decisions must be made in months rather than years.

The biggest change is therefore a compression of response time across the whole bank. A modern platform may enable that response, but it cannot substitute for shared priorities, decision rights, funding discipline and cross-functional accountability.

The economics are in the capacity to change

For decades, banking infrastructure was designed primarily for stability and processing capacity. Those remain non-negotiable. The additional requirement is change capacity: how quickly a bank can configure a product, respond to a rule, connect an ecosystem, release software, scale a workload or recover from failure. Michael Araneta, financial services lead at Amazon Web Services (AWS) put the test simply: “The point is the ability of a banking infrastructure to support innovation, the ability to change and introduce new features and products enabled by AI.”

That changes the business case. A cloud-migration percentage says little about value if releases remain slow, integration stays expensive or consumption is poorly controlled. A lift-and-shift may ease infrastructure or talent constraints while preserving the same application rigidity. Participants repeatedly returned to cost and return, but the relevant economics were broader than hosting expense: product lead time, failed change, recovery, integration effort and customer continuity all matter.

Chetan Sharma, who leads FSI Solutions for AWS captured the shift: "The question is how we architect on the cloud for resilience and scalability, but most importantly, for continuous change."

Core modernisation is a transition problem

The discussion did not support one universal route for the core. A bank may retain a viable ledger and surround it with governed services, move selected domains progressively, or replace more extensively where structural constraints obstruct strategy. The choice depends on business urgency, legacy viability, risk appetite and the capacity to operate old and new environments together.

The harder practical problem is often the transition state. "One key element is also how fast you can build the new during the migration, because the business cannot stop,” said Sutee Srivorapetch, CEO of Sunline.  Two cores and surrounding systems may coexist while accounts, products and data move between them. Routing, orchestration, reconciliation, file interfaces, latency, customer communication and recovery then become first-class design concerns. Several migration experiences reinforced the need to architect this period as deliberately as the target state.

There was also no single position on downtime. Some participants described uninterrupted service as the new expectation; others considered a bounded outage manageable with strong communication and contingency support. The common point was that operational confidence is wider than uptime. It includes knowing how failure propagates, how quickly services can recover and how customer journeys and reconciliations will be preserved.

The core itself is only one component of a larger banking ecosystem. Payments, cards, lending, trade and cash-management capabilities may sit partly outside it. Protecting the core therefore means preserving transaction and accounting integrity while allowing governed change around it; it does not mean freezing the institution against change.

AI readiness begins with governed decisions

AI was treated as inevitable but not yet as a settled platform design. Participants raised uneven maturity, uncertain benefits, privacy, security and the speed at which fraud and scams are evolving. The discussion suggested that AI readiness should not be reduced to a procurement label or computing capacity.

The more useful test is whether governed data, models and decisions can move safely across channels, operations and systems of record. Personalisation and protection draw on the same data but require different thresholds, escalation paths and human judgement. Banks need to know not only what an automated decision can do, but who is accountable and how the action can be stopped or reversed.

Safe change is becoming the operating model

Making continuous change safe requires controls across the full path from an idea to a live customer outcome. Banks must limit the size and blast radius of releases, observe services and data flows, test recovery, maintain traceability and establish who can approve or reverse a change. Risk and compliance therefore need to be embedded in delivery rather than applied at the end.

This is also a workforce design problem. Separate cloud- and AI-capable teams may protect delivery speed but create new silos; integrating everything into established IT may slow the change being sought. The roundtable did not identify a winning structure. It did point to the need for deliberate convergence, shared accountability and retention of people who understand decades of legacy rules, customisation and data.

The emerging divide will not be between banks that possess cloud, a modern core or AI tools and those that do not. It will be between institutions that can put change into production safely and repeatedly, and those for which every new requirement becomes another disruptive transformation. Continuous change is already the condition. Making it safe is becoming the capability that matters.