Banks across Asia Pacific (APAC) are under pressure to modernise for a real-time, AI-enabled and always-on operating environment. Growing digital transaction volumes, accelerating AI adoption and rising customer expectations are placing new demands on core banking systems, data platforms, cloud architecture and operational resilience. This was the central theme of the TAB Global Heads of Technology Roundtable at The Asian Banker Summit 2026, which brought together senior technology leaders from ANEXT Bank, AmBank, Bank Rakyat, China Construction Bank, CIMB, Development Bank of Sarawak Berhad, HSBC, Maybank, Nabil Bank, NatWest Group, OCBC Bank, RHB Bank, Siddhartha Bank, UOB, and other institutions, alongside executives from Visa. The question is no longer whether to modernise, but where to absorb risk. Two tensions surfaced sharply: between the urgency of digital transformation and the practical difficulty of modernising decades-old systems, and between moving at the pace of technology companies and meeting resilience and regulatory obligations. Technology cycles are moving faster than bank planning horizons A central concern was the mismatch between technology development cycles and banking transformation timelines. One participant argued that banks need to start thinking more like technology companies, not in mandate, but in how they understand technology depreciation and emerging risk. That means moving beyond incremental upgrades and long transformation horizons. Post-quantum cryptography was the sharpest example. Many banks are planning post-quantum readiness with horizons of 2032 to 2035. Google has already set its own internal deadline to 2029, having concluded the transition is happening faster than expected. Given that a post-quantum migration programme can take five to ten years to complete. Participants stressed that early preparation is critical, even as banks operate under different regulatory and systemic constraints from technology companies. This prompted a broader challenge. What happens if customers begin to trust technology companies more than financial infrastructure? The argument was not that trust is shifting away from banks, but that banks must manage technology renewal, learning and network scale with greater urgency to keep pace with customer expectations increasingly shaped by technology platforms. One participant noted that banks face constraints technology companies simply do not. Core banking and payment systems run 24 hours a day and cannot easily be touched. A critical outage is not a product incident. It reaches the chief executive, the board, regulator and customers simultaneously. Public company scrutiny, trust obligations and operational continuity requirements create a fundamentally different risk environment for banks. Regulators are not viewed as a constraint. In some markets, they push banks to accelerate resilience and transformation. Regulatory engagement is an ongoing, iterative process where banks must continuously communicate execution challenges, test assumptions and demonstrate alignment between innovation, operational objectives and compliance. The speed problem is therefore shared across banks, regulators and internal governance structures. A show of hands confirmed the discomfort, and almost no participant believed their institution was moving fast enough. Without a clear destination, every technology choice becomes a detour Several participants questioned whether banks have a clear North Star for modernisation. One participant described the need for a future-state architecture capable of supporting generative AI, digital currencies, tokenisation and stablecoin experimentation. Emerging technology cannot remain a collection of pilots. It needs a governance model, responsible AI controls and dedicated teams, otherwise experimentation becomes fragmented and unmanageable. Another participant reframed the issue. The first question is whether the bank has a clear direction, before which technology to adopt. Traditional views of what a bank should be still influence decisions, and banks that benchmark only against each other risk staying in a shallow comparison pool, missing the standards set by large technology platforms and digital ecosystems. A third participant offered a more operational perspective. Banks need agility to deliver products and services at the pace business teams demand, driving adoption of microservices and modular architecture. Yet the transition is constrained by legacy systems and regulatory requirements. Starting points differ, as some institutions have dedicated architecture programmes and emerging technology teams, while others are still aligning business demand with infrastructure and compliance readiness. Legacy is accumulated operational debt, not just old technology A participant highlighted that unlike technology companies, which can harmonise infrastructure and patch standardised environments quickly, banks contend with multiple operating systems, databases and tightly coupled infrastructure, making even basic upgrades complex. Network infrastructure is further entangled with live production systems. Banks are not modernising in a clean laboratory. They are changing systems that support customers, payments, transactions and regulatory reporting every single day. Participants posed a stark choice: carry accumulated debt forward, or design platforms supporting both legacy and future workloads. Moving monolithic applications to microservices, setting shared standards and building reusable platforms are all necessary work, spanning many years. Legacy systems present several problems at once: old infrastructure, technical debt, fragmented standards, non-elastic applications, live production dependencies and a limited ability to decommission. One participant summarised the principle. In technology, retiring systems is as important as building new ones. The typical path follows infrastructure upgrades, data centre and network redesign, cloud-native layering, then containerisation, yet many monolithic applications remain, limiting elasticity. AI is creating infrastructure demand before many systems are ready One participant warned that consumer AI agents querying databases, interacting with chatbots and acting on behalf of customers could create unprecedented infrastructure demand before quantum risk even becomes a practical concern. Current back-end systems may simply not be able to handle the volumes that widespread consumer-grade AI would generate. The harder issue emerging is internal. Small AI pilots can run on limited resources. But scaling enterprise-wide requires the AI team to coordinate with infrastructure, architecture and core banking teams, as larger use cases impact the core directly. Business leaders want fast, visible progress; technology teams are still modernising the infrastructure needed to support it. The recommendation was to deliver small but meaningful value, build support gradually and educate management and boards so that expectations do not run ahead of enterprise readiness. One point was made without qualification. AI and data are inseparable. Data residency, scalability and readiness will determine which banks can differentiate through AI and which cannot. This is an infrastructure, data and governance question rather than a model-selection question. Front-end modernisation is creating a new bottleneck Varun Dudeja, head of business development at Pismo, observed that most modernisation discussions still focus on front-end applications, mobile interfaces and customer-facing channels, meaning banks may only be touching the starting point of the problem. "When we talk about modernisation, microservices, or moving to cloud, the discussion still focuses on front-end applications. Very few banks are considering moving their core to the cloud. If we don't, the front-end may look modern, but every transaction still hits the same core, creating the same delays and hurdles as today," Dudeja said. When asked how many institutions are actively moving their core to the cloud, no hands went up. Modernising only the customer-facing layers is insufficient. If the underlying systems remain slow or tightly coupled, banks are merely building a modern interface over legacy constraints. Some banks prioritise digital channels for immediate gains, which is understandable, but it risks making transformation channel-led rather than infrastructure-led. Banks are taking core modernisation seriously, making it leaner, more modular and more decomposed, while keeping it, for now, on-premises or in trusted private cloud environments. Cloud is not one strategy; participants described several models The discussion revealed no single consensus on cloud. One participant noted that cloud is only part of the picture. The more important issue is the institution's overall infrastructure strategy, with customer data, regulatory requirements and risk appetite determining what can move and where. Another clarified terminology, arguing that “cloud” does not necessarily mean public cloud. Their bank follows a multi-cloud-native principle, using internal platforms on on-premises data centres designed for scalability, operational efficiency and agility. Private or trusted cloud, rather than a hyperscaler, is often the chosen model. A third participant used a vivid metaphor. Moving core systems feels like performing a heart transplant while the patient is alive. On-premises infrastructure provides control, while cloud offers agility, but the challenge is containing risk during the transition. Banks are working through public, private, trusted and on-premises cloud-native models, with decisions shaped by regulatory comfort, data residency, risk appetite and legacy complexity. Public cloud also sparked debate around resilience, not just security. Varun Mahindru, head of value-added services for Regional Southeast Asia at Visa, challenged the assumption that public cloud is inherently less secure. "From Visa’s perspective, cloud is viewed as an increasingly viable solution to both security and resilience challenges, particularly when implemented within a well‑governed, multi‑layered operating model that supports flexibility and continuity." A participant cautioned that infrastructure elasticity is insufficient if applications, testing and release processes cannot keep pace. Can applications fail over reliably? Can testing and deployment be automated? Cloud alone does not solve operational constraints. Another participant cautioned against assuming cloud is cheaper. The right question is what the bank is trying to achieve, whether cost savings, resilience, scalability, data residency, speed or operational efficiency. Cloud is an enabler rather than an end goal. Regulatory interpretation differs by market and by institution One participant emphasised that regulatory engagement is a continuous dialogue rather than a one-time approval. Banks must clearly define their objectives internally and assess risk, as regulatory requirements are not checklists. The intent of a rule matters more than its literal wording. Mahindru pointed out that most cloud guidelines do not restrict banks to public or private cloud. They provide a general framework for assessment. The binding constraint is often internal. "What happens is the banks' internal risk teams and compliance teams are looking at it, do they really understand cloud as a technology or not? Because their perception of it would frame the whole bank's approach." Participants highlighted differences across markets, with regulatory engagement on issues such as disaster recovery and data movement varying in duration and complexity depending on jurisdiction. Regulatory pressure also flows the other way. One bank described how the Reserve Bank of India's payment data localisation mandate forced restructuring across hundreds of ecosystem participants. Another said that recovery time objectives vary from 30 minutes to eight hours depending on jurisdiction, and one participant estimated that compliance consumes nearly 40% of technology budgets. Regulatory requirements, they stressed, shape transformation decisions at every level, not just the margins. Core banking modernisation is shifting from replacement to decomposition The core banking discussion revealed several pathways. One digital bank described a core designed to be decomposable from the outset, not entirely microservices-based, but with key services such as ledgers and regulatory interfaces built more modularly. This gave the institution confidence that in a severe disruption, it could migrate to another cloud environment more straightforwardly. The same participant raised a forward-looking concern. As AI becomes central to how employees and customers access core banking, banks will need a translator layer inside or around the core, to store verifiable intent, manage credentials for AI agents and handle know-your-agent controls. AI is changing the access model to core systems entirely, beyond adding workload. For larger institutions, the direction is progressive modernisation, hollowing out the core, extracting peripheral capabilities and keeping the central platform focused on essentials. Dudeja framed where the industry is heading. "The core is no longer everything together. Conceptually, it resides around three key elements: data, ledger and processing. When you combine these three, you can divide it by transaction banking, corporate banking, retail banking and then specific products. Now everything is decoupled." Three models are now visible: rip-and-replace for smaller institutions, progressive hollowing for larger banks and building new digital verticals on separate cores alongside legacy systems, migrating volumes over time. Each carries different risk, cost and regulatory implications. Regulation can complicate even sound decomposition. In some markets, a bank may want know-your-customer (KYC) data outside the core, but the regulator may require it to stay inside. Even well-designed architectural decisions need regulatory approval before they can be implemented. Real-time banking changes how banks think about risk and resilience One participant argued that time is a critical variable in technology decisions. Longer intervals between batches, ledger updates, or recovery points increase exposure, affecting funding, operational risk and the ability to reconstruct positions. Accelerating processes reduces both cost and risk. Ledgers were described as snapshots of reality. If the worst happens, whether a cyber attack, geopolitical disruption or a quantum-enabled threat, a bank must know how to rebuild them. Resilience therefore means ledger continuity: the frequency of capture, the ability to reconstruct positions, the geographic distribution of backups and the risk of depending too narrowly on specific locations. Cloud, one participant noted, may eliminate the need for a full duplicate data centre, but only if regulators accept the model and the bank can prove it through testing. For decades, resilience was treated as an afterthought. Today, every business plan leads with resilience first. Designing it in from the start, rather than retrofitting, is essential for scalability. Resilience is also a customer question. One participant made the point plainly. It is no good if the bank stays operational while its customers cannot function. Resilience planning must extend to whether customers can access funds, complete transactions and maintain financial continuity during a disruption, not only whether systems can be restored. Organisational learning is becoming part of infrastructure readiness Cloud, AI and core modernisation decisions involve more than technology teams. Risk, compliance, legal, operations, management and boards all shape execution, and gaps in understanding can slow or fragment transformation. Participants shared several approaches such as board-level training, internal talks on AI, quantum, blockchain and cloud. "Learning Fridays" were cited as giving employees dedicated time for new concepts, alongside enterprise AI tools with knowledge-based virtual assistants to build AI fluency at scale. Dudeja described a specific application at Visa following the acquisition of Pismo, an AI agent that allows employees to query everything about Pismo's platform, including capabilities, endpoints and how to speak about it. The takeaway is that speed of organisational learning directly constrains transformation. Boards and senior leaders who do not understand cloud, AI or quantum risk cannot confidently approve changes. Closing that gap is a prerequisite for execution. The path forward is iterative, but it cannot be slow Asia Pacific banks are not on one uniform path. A large global bank may be focused on future-state architecture and decommissioning legacy platforms. A Malaysian bank may be balancing microservices ambitions against live production constraints. A bank with a long infrastructure history may be working through containerisation and data centre redesign. A digital bank may have a decomposable core but face new questions around AI access and data sovereignty. The starting points differ, but the destination does not. The real-time bank will not be built through isolated programmes. Success requires integrating infrastructure harmonisation, core decomposition, cloud strategy, AI governance, data readiness, resilience and organisational learning. Cloud and modernisation are enablers rather than the agenda. Cycle times are shrinking rapidly, but banks aiming only to catch up may never do so. Quantum computing, accelerating technology risks and uneven regulatory readiness are converging, and the window to get ahead is limited. The structural advantage banks hold over technology companies is their network and the trust placed in them over decades, an advantage that is real and theirs to lose. Modernisation must be both practical and urgent. Banks cannot ignore trust, regulatory or operational constraints, but they cannot allow these constraints to justify insufficient pace. Infrastructure will increasingly determine which banks can deliver real-time services, scale AI responsibly and preserve customer trust. Institutions treating it as a strategic priority rather than an operational task will define banking in the next decade.
