logo

Why banks are re-architecting the core for speed, stability and scale

Why banks are re-architecting the core for speed, stability and scale
  • 83

Banks are moving beyond replacement-led modernisation towards a broader redesign of architecture, operating models and resilience capabilities. The challenge is no longer whether to modernise, but how to modernise continuously without destabilising the institution.

For much of the past two decades, core banking modernisation was framed mainly as a technology replacement problem. Banks with ageing platforms sought newer systems that promised greater flexibility, faster product development, lower maintenance costs and better digital capability. Yet the history of core replacement has been uneven. Large programmes often became expensive, prolonged and difficult to execute because the core sits at the centre of deposits, lending, payments, customer accounts, reporting, reconciliation, branches, digital channels and downstream operations.

The modernisation challenge has since widened. Banks are now expected to support real-time payments, digital onboarding, application programming interface (API) connectivity, cloud-native infrastructure, data-driven decisioning, embedded finance and higher regulatory expectations for operational resilience. These demands are difficult to meet where core systems remain surrounded by fragmented data, bespoke processes, legacy interfaces and manual controls that have accumulated over many years.

Increasingly, banks are not approaching transformation as a single technology replacement event. They are dealing with different questions: how to harmonise platforms across markets, how to sequence migration without disrupting customers, how to separate the systems that engage customers from those that hold records, how to keep the core lean, how to move selectively to cloud and how to sustain transformation after the formal programme ends.

The strongest thread across these institutions is that core modernisation is no longer only about the core. It is about the operating architecture around the core. That includes data, cloud, integration, cybersecurity, process design, workforce capability, governance and the ability to keep live banking operations running while the bank continues to change.

What emerges from these examples is that banks appear to be pursuing several common objectives even as they follow different transformation paths. Whether operating across dozens of markets or serving a single domestic franchise, institutions are seeking architectures that can absorb continuous change without creating instability. The issue is no longer how to execute a once-in-a-generation replacement programme. It is how to build an organisation capable of evolving repeatedly while maintaining customer trust, regulatory compliance and operational resilience.

Legacy complexity becomes a strategic constraint

MUFG’s Asia Pacific transformation shows why legacy complexity has become a strategic operating issue rather than a technology inconvenience. The bank operates across 18 diverse markets in the region, with long-established businesses, market-specific requirements and relationships with local banking partners including VietinBank, Krungsri, Security Bank and Bank Danamon. Victor Pang, Head of Operations Office for Asia, described the internal challenge as the harmonisation of different legacy systems and processes into a streamlined operating environment, while the external challenge came from diverse market dynamics and regulatory demands.

That framing is important. A bank operating across multiple markets cannot modernise only for internal efficiency. Multinational clients expect consistent service standards across jurisdictions. Regulators require local compliance. Markets differ in payments infrastructure, data requirements and operational practices. The result is that modernisation must balance standardisation with local flexibility.

MUFG’s regional modernisation programme reflects this attempt to create a more unified operating foundation. Pang said the bank’s first task was to establish a modern core banking environment capable of supporting consistent service delivery while standardising processes across branches. The effort was tied to real-time processing, automation and improved straight-through processing rather than technology replacement alone.

Vietnam Technological and Commercial Joint Stock Bank (Techcombank) reached a similar conclusion from a different starting point. Tuan Nguyen, Group Chief Information Officer, described the bank’s 2021 to 2025 transformation cycle as a foundational reset. When he joined in 2020, fragmented systems, infrastructure limits and delivery bottlenecks constrained both speed and scale. The objective was not merely to modernise individual applications but to transform the technology function into an engineering organisation capable of partnering with the business.

Nguyen’s description of the programme is useful because it avoids the common mistake of treating technology transformation as a sequence of isolated upgrades. Techcombank had to build platforms, people, engineering discipline and standard practices capable of supporting growth and continuous change. Core banking modernisation formed only one part of a broader strategy spanning cloud migration, data activation, customer platforms and merchant ecosystems.

State Bank of India (SBI), India’s largest bank by assets and customer base, adds a scale perspective. Balaji Rajagopalan, Chief Technology Officer, argued that banks must redesign their architecture before scaling new capabilities. His framework separates systems of engagement, systems of record, systems of integration and systems of intelligence. The point is that large banks cannot continue adding new customer-facing capabilities onto fragmented technology estates and expect enterprise-wide transformation to follow.

For Rajagopalan, systems of engagement are where customers and employees interact with the bank. Systems of record remain the authoritative source of customer, account and transaction information. Systems of integration connect applications, channels and services. Systems of intelligence sit above these layers and use data, analytics and AI to support decision-making. The value of this model is that each layer can evolve independently without forcing disruptive change across the entire estate.

The framework also addresses a growing issue facing large banks. As AI, real-time services and ecosystem connectivity become more important, the ability to separate responsibilities across architectural layers becomes critical. Banks that fail to do so risk increasing complexity every time they add a new service, channel or intelligence capability.

These cases show why legacy infrastructure has become a strategic constraint. The problem is no longer only that systems are old. It is that accumulated complexity makes it harder for banks to change safely, launch faster, use data consistently, integrate partners and deliver resilient services across multiple channels and markets.

Victor Pang
Victor Pang, Head of Operations Office for Asia, MUFG Bank

Why banks no longer trust wholesale replacement

The banking industry has not abandoned full core replacement, but the credibility of one-off, large-scale replacement programmes has weakened. The more mission-critical the environment, the more modernisation becomes an operational risk exercise.

Habib Bank Limited (HBL), Pakistan’s largest commercial bank by assets, illustrates the shift. The bank’s transformation programme today supports more than 40 million customer accounts and approximately 20 million transactions daily across conventional and Islamic banking environments. The scale alone changes the economics of transformation. Any migration approach must be assessed not only for technical feasibility but also for customer impact, operational continuity and execution risk.

For Faisal Anwar, Chief Technology Officer, the issue was not whether the bank needed to modernise. It was how to modernise without interrupting a large national banking operation. A big-bang migration across the branch network would have required an outage of several days. That was not an acceptable option for a large incumbent bank serving customers across multiple channels and branch locations.

HBL therefore adopted a phased conversion strategy. Branch groups were migrated progressively and neighbouring branches were deliberately not converted at the same time. If one branch encountered problems, customers could still be served by another nearby branch. This reduced the operational blast radius of each migration cycle.

The practical implication is that sequencing became part of the architecture. The bank had to think through branch dependencies, customer servicing patterns, fallback arrangements, channel behaviour and exception scenarios. Anwar described the process as involving extensive planning and scenario analysis to identify possible risks and workarounds before migration.

MUFG’s approach also reflects the same move away from undifferentiated replacement. Its modernisation programme began in selected markets before expanding further across the region. The programme was not simply a technology deployment. It formed part of a broader regional operating strategy involving standardisation, automation, data management, cybersecurity and service consistency across markets.

The lesson is that full replacement remains possible where the case is clear, but the industry has become more cautious about treating replacement as a universal answer. The more relevant question is whether the transformation path matches the bank’s operational risk appetite, market structure, regulatory obligations and execution capability.

What is changing is not simply the pace of transformation but the philosophy behind it. Large banks increasingly recognise that transformation programmes succeed when they minimise disruption while building future capability. The objective is no longer to complete a migration as quickly as possible. It is to arrive at a more resilient operating architecture without destabilising the institution in the process.

Balaji Rajagopalan
Balaji Rajagopalan, Chief Technology Officer, State Bank of India

Modernisation increasingly favours incremental execution

The banking industry appears to be moving towards more incremental approaches to core modernisation, although the evidence does not suggest complete convergence around a single execution model. Large-scale replacement remains viable in some circumstances, particularly where legacy constraints have become severe or where institutions have relatively contained operating environments. However, the experiences described by MUFG, HBL, Techcombank and Vietnam Maritime Commercial Joint Stock Bank (MSB) suggest that many institutions are seeking ways to reduce execution risk while still progressing towards more scalable and modular architectures.

For large incumbent banks, the attraction is understandable. The question is not simply replacing technology. It is preserving customer service, operational continuity and regulatory compliance while transformation is taking place. Incremental approaches allow banks to manage these competing priorities in smaller and more controllable stages.

HBL’s programme shows how this can work in practice. The bank continued to operate legacy and modernised environments side by side while preserving customer experience across mobile banking, automated teller machines (ATMs), branches and agency banking networks. Anwar said the objective was to replicate a seamless customer experience even as the underlying environment evolved.

The architectural response was decomposition. HBL progressively separated parts of the institution into operational domains connected through middleware, APIs and service frameworks. Anwar said the bank developed an architectural blueprint that allowed customer-facing changes to occur without necessarily disrupting underlying systems of record.

This thinking extends to payments. HBL has evaluated whether payment capabilities should remain embedded within the core or operate independently as specialised domains. Anwar’s principle was straightforward: “Keep the core lean.” The implication is not that the core becomes less important. Rather, banks may need to become more selective about which functions belong inside the core and which can evolve separately.

Techcombank approached the issue through application-level discipline. The bank adopted a cloud-first strategy, but Nguyen emphasised that the exercise was not a wholesale migration programme. Individual applications were assessed to determine whether they should be migrated, re-engineered, consolidated or retired. Within roughly two years, more than 60% of workloads had moved to cloud environments, but Nguyen’s broader point was that migration decisions should be driven by architecture and business requirements rather than technology targets alone.

The bank also used structured governance frameworks to sequence more than 100 applications across multiple transformation waves. Once priorities were established, delivery followed repeatable engineering processes rather than highly customised project execution. Nguyen argued that this discipline helped maintain trust between technology and business teams while reducing transformation fatigue.

MSB offers another example of incremental architectural evolution. Nguyễn Quốc Khánh, Deputy Chief Executive Officer and Chief Information Officer, described the bank’s effort to build an agile digital core spanning core banking, payments and enterprise data capabilities. The significance of this approach lies less in the individual technologies involved and more in the operating model it supports. Core services, payments capabilities and data services were designed to evolve independently while remaining connected through common integration standards and governance. This reduced the need for large-scale platform changes whenever one domain required enhancement.

Khánh’s broader argument was that modernisation should not create new dependencies as quickly as it removes old ones. Banks that successfully separate responsibilities across core banking, payments, data and customer-facing services may be better positioned to adapt future capabilities without repeatedly revisiting the entire technology estate.

These examples point towards a broader industry trend, but perhaps not yet a settled conclusion. Incremental execution appears attractive because it allows banks to manage operational risk while progressively improving architecture. At the same time, it introduces its own questions around governance, coexistence, integration complexity and programme duration.

The more important observation may therefore be that banks are becoming more deliberate in how they sequence change. Whether transformation occurs through phased migration, domain-led replacement, architectural decomposition or selective full replacement, the objective is the same: ensuring that each stage strengthens the future operating environment rather than creating another layer of temporary complexity.

Faisal Anwar
Faisal Anwar, Chief Technology Officer, Habib Bank Limited

Cloud-native architecture reaches operational maturity

Cloud has moved from a broad aspiration to a more disciplined component of core modernisation. The question is no longer whether banks should use cloud. It is what should move, what should remain, what must be redesigned and how institutions govern complex hybrid technology environments.

Early cloud discussions often focused on infrastructure economics. Banks were attracted by the prospect of reducing capital expenditure, increasing flexibility and accelerating deployment. In practice, many institutions discovered that migration alone did not automatically produce these benefits. Application design, integration complexity, data management, operational controls and engineering capability proved equally important.

Techcombank provides one of the clearest examples of this evolution. Nguyen said the bank’s cloud strategy was not driven primarily by cost reduction. Instead, the objective was to create a more flexible technology environment capable of supporting growth, ecosystem connectivity and faster delivery of new capabilities. Cloud adoption was therefore linked closely to application rationalisation, engineering discipline and business priorities.

The bank assessed individual applications to determine whether they should be migrated, redesigned, consolidated or retired. This distinction matters because cloud adoption is often presented as a binary decision. In reality, banks must make workload-by-workload assessments based on business criticality, integration requirements, security considerations and long-term architectural objectives.

At the time of Nguyen’s discussion, certain mission-critical systems remained outside production cloud environments while undergoing evaluation or modernisation. This illustrates a broader industry reality. Even institutions that embrace cloud aggressively do not necessarily move all systems simultaneously. Customer accounts, payments, card processing and other critical functions frequently require more extensive assessment because of their operational importance and regulatory implications.

SBI approached the issue from an architectural perspective. Rajagopalan argued that future readiness is not determined by the amount of infrastructure available but by whether applications are designed to scale. He linked scalability to modular architecture, strong API frameworks, microservices and clear separation between architectural layers.

His observation highlights a common misconception. Simply relocating applications into a cloud environment does not resolve underlying architectural weaknesses. Applications that were difficult to maintain, integrate or scale before migration often remain difficult afterwards unless they are redesigned as part of the transformation process.

This distinction becomes important as banks pursue real-time services and AI-enabled operating models. These capabilities place growing demands on integration, data movement and processing speed. The ability to scale infrastructure is valuable, but the ability to scale architecture is often more important.

HBL’s experience adds a resilience dimension to the discussion. Anwar described the bank’s objective as creating an environment capable of supporting continuous availability while remaining adaptable to future requirements. The goal was not simply to introduce new infrastructure but to reduce operational disruption during upgrades, maintenance and future transformation activity.

That objective reflects a broader shift in industry priorities. Historically, many banks accepted planned downtime as a normal consequence of technology maintenance. However, customer expectations, competitive pressures and regulatory requirements are pushing institutions towards continuous service availability.

As a result, cloud strategy is becoming closely linked to resilience strategy. The discussion centres on workload portability, recoverability, operational flexibility and the ability to maintain services while technology environments continue to evolve underneath them.

The cloud conversation is also becoming inseparable from data strategy. As institutions expand analytics, automation and AI initiatives, they require technology environments capable of supporting greater volumes of data while maintaining governance, security and control. The issue is not merely storing more information but ensuring that information can be accessed, integrated and governed consistently across the organisation.

For this reason, cloud maturity may be less about where systems run and more about how they are designed, governed and operated. Banks that derive the greatest benefit from cloud adoption tend to combine infrastructure modernisation with application rationalisation, engineering discipline, data governance and architectural clarity.

The evidence from these institutions suggests that cloud adoption is moving beyond experimentation and selective deployment. At the same time, there is little evidence that a single operating model is emerging. Public cloud, private cloud and hybrid environments continue to coexist. The more relevant distinction appears to be between institutions that have developed a coherent architecture strategy and those that continue to treat cloud migration as an objective in itself.

Cloud therefore remains an important enabler of transformation, but not a substitute for transformation. The institutions making the most progress are using cloud to support broader goals around scalability, resilience, engineering productivity and operational agility rather than viewing migration itself as the end state.

Brian O'Neill
Brian O'Neill, Global Head of Group Transformation, Standard Chartered Bank

Rebuilding the operating model around the core

Core modernisation is proving to be as much an operating model question as an infrastructure challenge.

For many years, technology programmes were often evaluated through implementation milestones, budget performance and system functionality. Yet the experiences of these institutions suggest that the long-term value of modernisation depends less on technology deployment itself and more on whether organisations change how they operate around the technology.

Standard Chartered’s Fit for Growth transformation programme provides one of the clearest illustrations of this shift. Brian O’Neill, Global Head of Group Transformation, described a mandate spanning enterprise transformation, technology investment, process redesign and workforce capability. The programme delivered $754 million in run-rate savings through more than 300 initiatives by 2025, but O’Neill repeatedly argued that financial metrics alone do not capture the significance of transformation.

“Fit for Growth has been very successful, but that’s just one aspect of our transformation,” he said. “What matters most is improving turnaround times, client service and resilience.”

That distinction is important because it changes how success is measured. A programme may achieve technology milestones and financial savings while leaving underlying operating practices largely unchanged. In such cases, institutions often discover that new technology inherits old complexity. Processes remain fragmented, decision-making remains slow and operational inefficiencies reappear in new forms.

O’Neill illustrated the issue through examples from wealth management and trade finance. In wealth management, digitised onboarding removed manual paperwork and allowed relationship managers to devote more time to client engagement. In trade finance, document-intensive workflows are being automated. The common objective is not automation for its own sake but the creation of processes that are more scalable, repeatable and resilient.

This highlights a broader lesson for core modernisation. Replacing technology without redesigning surrounding workflows often produces limited benefits. Sustainable gains emerge when institutions redesign how work moves across business units, operations teams, customer channels and risk functions.

Techcombank’s experience reinforces the same conclusion from a different perspective. Nguyen described the bank’s objective as transforming the technology organisation into an engineering organisation capable of partnering with the business. Cloud adoption, engineering practices and platform development were important components, but they were ultimately intended to support a broader organisational shift.

The emphasis on engineering capability is particularly significant. Many banks have historically relied on project-based technology delivery models that separate business teams, operations teams and technology specialists into distinct functions. As transformation programmes become more continuous, institutions require product ownership, cross-functional collaboration and engineering disciplines capable of supporting ongoing change.

Nguyen argued that internal capability matters because architectural knowledge cannot be delegated entirely to external parties. Banks may rely on specialised partners, but they remain responsible for understanding how systems interact, how risks are managed and how future changes are introduced. Maintaining internal capability therefore becomes part of the operating model itself.

SBI’s Rajagopalan approached the challenge through execution governance. He argued that problem statements and strategic priorities often need to be established centrally, but implementation requires engagement with frontline operations and business units. Large institutions cannot rely solely on central programme teams to understand the practical realities of branches, operations centres, compliance functions and customer servicing environments.

This observation reflects a recurring question in large transformation programmes. Complexity often accumulates far from the centre of the organisation. Processes evolve to address local requirements, regulatory expectations or customer needs. Over time, those adaptations can become embedded in the operating model. Transformation efforts that fail to understand these realities frequently underestimate implementation complexity.

O’Neill expressed a similar view in organisational terms. “You can’t enforce culture. You have to influence it,” he said. He argued that successful transformation requires local teams to identify inefficiencies and challenge complexity themselves rather than waiting for direction from central programme offices.

“You are never going to be able to sit in the centre and understand every process,” he said.

The observation goes beyond culture. It reflects a practical reality that modern banks are complex organisations operating across products, customer segments, channels and regulatory environments. Sustainable transformation therefore depends on creating mechanisms that allow continuous improvement to emerge from within the organisation rather than relying exclusively on periodic central programmes.

The operating model question becomes even more important as institutions introduce AI, automation and advanced analytics. New technologies can increase productivity and improve decision-making, but they also require new governance frameworks, new skills and new accountability structures. Organisations must decide who owns models, who validates outcomes, how exceptions are handled and how risk oversight is maintained.

This reflects a wider industry trend. As banks become more data-driven and automation becomes more pervasive, governance shifts from supervising individual projects to supervising operating capabilities. The issue is no longer simply implementing technology successfully. It is ensuring that technology continues to operate safely, effectively and transparently after implementation.

The conclusion is that modernising the core without redesigning the operating model is unlikely to produce lasting results. Banks need governance, engineering capability, workforce engagement, product ownership, risk controls and organisational alignment if technology investment is to translate into sustainable operating capability.

The institutions making the greatest progress appear to understand that architecture and operating models evolve together. One provides the technical foundation for change. The other determines whether that change can be sustained.

Nguyễn Quốc Khánh
Nguyễn Quốc Khánh, Deputy Chief Executive Officer and Chief Information Officer, MSB

Resilience becomes the defining design principle

Operational resilience is no longer a secondary benefit of modernisation. It is becoming one of the primary design considerations shaping how banks approach architecture, governance, execution and technology investment.

Historically, resilience was often viewed as a control function sitting alongside transformation. Systems were modernised first, while resilience, recovery and operational controls were assessed later. The experiences of these institutions suggest that this sequencing is becoming less viable. As technology estates become more interconnected and customer expectations move towards continuous service availability, resilience has to be designed into transformation from the outset.

HBL’s architecture reflects this shift. The bank’s phased migration strategy was designed to minimise disruption during implementation. Its decomposed architecture was intended to reduce dependency between systems. The broader objective was not merely to modernise technology but to create an environment where failures could be isolated without affecting the entire institution.

Anwar illustrated this principle through a simple example. If a credit card platform experiences difficulties, customer-facing applications should continue functioning. The objective is not to eliminate failures entirely. Rather, it is to prevent individual failures from escalating into broader service disruptions.

This way of thinking represents a significant departure from traditional banking architectures. Legacy environments often evolved around tightly coupled systems where disruption in one component could affect multiple functions simultaneously. Modernisation seeks to reduce those dependencies by separating responsibilities across distinct architectural domains.

The concept extends beyond migration and architecture. HBL has also explored how engineering automation, AI-assisted operations and infrastructure observability can support resilience. As technology environments become larger and more complex, institutions are seeking ways to identify issues earlier, accelerate remediation and improve operational visibility across systems.

The broader implication is that resilience depends on operational intelligence as well as technical controls. Banks are managing growing volumes of infrastructure, applications, interfaces and data flows. The ability to monitor, diagnose and respond quickly becomes a strategic capability in its own right.

MUFG’s regional transformation highlights another dimension of resilience. Operating across multiple jurisdictions introduces complexity that extends beyond technology. Different regulatory environments, market structures, payment systems and customer expectations all influence how resilience must be managed.

Pang linked resilience closely to standardisation. Harmonising systems and processes across Asia Pacific is not simply an efficiency exercise. Greater consistency allows the bank to establish more predictable operating standards, improve governance and respond more effectively to operational and regulatory demands.

The relationship between standardisation and resilience is sometimes underestimated. Complexity can create vulnerabilities even when individual systems operate effectively. Different processes, inconsistent controls and fragmented operating models often make it harder to identify issues and coordinate responses. Standardisation can therefore strengthen resilience by reducing operational variability.

Cybersecurity adds another layer to the discussion. Anwar noted that transformation changes both the surface and vector of attack. As institutions adopt APIs, ecosystem connectivity, cloud-native environments and more distributed architectures, the number of potential points of exposure increases.

This creates an important question for transformation leaders. Modernisation often seeks to increase openness, integration and flexibility. At the same time, banks must maintain strong security controls and ensure that new capabilities do not create unintended vulnerabilities. The result is that cybersecurity becomes an architectural consideration rather than a separate technology function.

SBI’s Rajagopalan approached resilience through governance, architecture and software discipline. He argued that security, data protection, engineering controls and cloud governance become more important as banks introduce AI and intelligent operating environments.

His observations are particularly relevant because AI introduces new forms of operational dependency. Banks must manage model governance, data quality, explainability, access controls and software supply chains alongside traditional infrastructure risks. Rajagopalan’s example of reducing proposed open-source components in an AI initiative from approximately 2,000 to fewer than 200 demonstrates how software discipline itself can become a resilience mechanism.

The difficulty is not simply technological. It is organisational. As technology environments become more interconnected, banks must decide how responsibilities are assigned, how risks are assessed and how governance is maintained across complex ecosystems.

Standard Chartered’s transformation governance provides a useful example. O’Neill argued that AI and technology programmes should be explainable, traceable and auditable. The bank evaluates new capabilities through the combined lenses of cyber risk, data governance, operational resilience and business accountability rather than treating technology initiatives as stand-alone projects.

This reflects a broader evolution in industry thinking. Early discussions around AI often focused on capability and productivity. However, banks are paying equal attention to governance, transparency and accountability. The question is not simply whether a model performs well. It is whether decisions supported by that model can be understood, challenged and governed appropriately.

The bank’s approach also highlights an important distinction between experimentation and production deployment. Innovation can occur rapidly, but critical banking capabilities require more rigorous controls. Risk specialists, business owners, technology teams and governance functions all play a role in determining whether new capabilities are suitable for enterprise-wide deployment.

AI therefore becomes a resilience issue as much as a productivity issue. Models that cannot be explained, monitored or governed effectively may introduce new forms of operational risk regardless of their technical performance. The institutions that appear most advanced are integrating AI governance into broader operational and risk frameworks rather than managing it separately.

The common theme across these institutions is that resilience can no longer be added after architecture decisions have been made. Recovery capability, cybersecurity, operational controls, software discipline, governance and organisational accountability all influence whether modernisation succeeds.

Resilience is therefore evolving from a supporting requirement into a design principle. Banks are not simply building systems that perform efficiently under normal conditions. They are seeking architectures, operating models and governance frameworks capable of adapting to disruption, recovering quickly and maintaining trust even when conditions become less predictable.

As transformation becomes a permanent organisational capability rather than a periodic programme, resilience may ultimately become one of the most important measures of success. The institutions best positioned for long-term change are likely to be those that can continue evolving while maintaining control over risk, service quality and operational stability.

Tuan Nguyen
Tuan Nguyen, Group Chief Information Officer, Techcombank

The economics of transformation

Core banking transformation is expensive, but the economic rationale extends beyond technology costs. The institutions featured in this article are investing not because transformation is inexpensive, but because the operational and strategic costs of standing still continue to rise.

Historically, transformation business cases were often built around technology efficiency. Banks sought to reduce maintenance costs, consolidate systems and lower infrastructure expenditure. Those objectives remain relevant, but they no longer appear sufficient to justify large-scale programmes on their own.

Standard Chartered provides one of the clearest examples of how the economics of transformation are evolving. The bank’s Fit for Growth programme delivered $754 million in run-rate savings through more than 300 initiatives by 2025. Yet O’Neill repeatedly framed the programme in terms of operational performance rather than cost reduction alone.

This distinction is important because many of the benefits generated by transformation do not appear immediately in technology budgets. Faster onboarding, shorter turnaround times, improved process consistency and reduced operational friction can influence productivity, customer experience and growth capacity without necessarily producing direct technology savings.

The bank’s experience in wealth management illustrates the point. Digitised onboarding reduced manual processing and administrative effort, allowing relationship managers to devote more time to client-facing activities. In trade finance, automation has helped reduce dependence on document-intensive processes that traditionally required significant operational intervention.

The economic value in both cases comes not simply from doing existing work more cheaply, but from increasing the institution’s ability to handle greater volumes of activity without a corresponding increase in complexity. Productivity improvements therefore become linked to scalability.

Techcombank’s experience points towards a similar conclusion. Nguyen argued that transformation decisions should be evaluated in terms of business capability rather than infrastructure economics alone. The value of modernisation came from the bank’s ability to accelerate delivery, support ecosystem development, improve data utilisation and simplify future change.

This reflects a broader shift in how banks assess investment decisions. Technology platforms are becoming less valuable as isolated assets and more valuable as enabling capabilities. Institutions are investing in environments that allow products, services and customer experiences to evolve more rapidly over time.

The economic implications are significant. A bank that can launch products faster, integrate partners more efficiently and respond more quickly to changing customer expectations may generate benefits that are difficult to capture through traditional technology return-on-investment calculations.

HBL presents another dimension of the economic argument. Its phased migration approach may appear slower than more aggressive implementation strategies, but Anwar’s discussion suggests that speed itself is not always the most relevant measure of value.

For a large institution serving millions of customers, avoiding service disruption can carry substantial economic importance. Customer dissatisfaction, operational stress, reputational damage and regulatory scrutiny can all impose costs that far exceed the savings generated by an accelerated implementation timetable.

Viewed through that lens, a longer transformation programme may be economically rational if it materially reduces execution risk. The objective is not to minimise project duration at all costs but to balance progress against operational stability.

MSB introduces yet another perspective. Khánh linked modernisation to the bank’s ability to support growth in customers, accounts and transaction volumes. In this context, transformation functions less as a cost-management exercise and more as an investment in future capacity.

This distinction is relevant across the industry. Many banks are modernising in environments where digital activity continues to expand rapidly. The difficulty is not only reducing existing costs but ensuring that future growth does not require proportional increases in operational complexity, infrastructure expenditure or workforce requirements.

The economics of transformation therefore extend beyond efficiency. They encompass capacity, adaptability and strategic flexibility. Institutions are increasingly investing in architectures and operating environments that can accommodate future growth without requiring repeated large-scale restructuring.

The experiences of these banks suggest that the strongest business cases combine multiple sources of value. Cost savings remain important. So do productivity gains, risk reduction, service improvements and growth capacity. No single metric fully captures the benefits of transformation.

This may explain why transformation programmes continue despite their complexity and expense. The question facing many institutions is no longer whether modernisation will generate immediate savings. It is whether the organisation can continue competing effectively if the underlying architecture, operating model and delivery capability remain unchanged.

The broader lesson is that transformation economics are becoming more strategic. Banks are investing not simply to improve today’s performance, but to ensure that future change becomes less costly, less disruptive and easier to execute.

Who controls the future banking architecture?

As banks modernise, architecture is becoming a strategic discipline rather than a purely technical one.

Historically, many technology decisions were evaluated at the level of individual projects. Business units selected solutions to address specific needs, technology teams implemented them and operations teams absorbed the resulting complexity. Over time, however, successive waves of projects often created increasingly fragmented technology estates, overlapping processes and inconsistent operating models.

The question facing banks today is therefore not simply how to introduce new capabilities. It is how to ensure that successive rounds of transformation contribute to a coherent long-term architecture rather than creating new layers of complexity.
MUFG’s regional programme illustrates the scale of the issue. Operating across multiple jurisdictions requires the bank to balance local requirements with regional consistency. Pang described the objective as harmonising systems and processes while maintaining the flexibility required by different markets and regulatory environments.

This balancing act becomes difficult as institutions expand digital services, integrate external partners and respond to changing customer expectations. Every new capability creates choices about how systems interact, where data resides and how responsibilities are distributed across the organisation.

The question is not whether banks should evolve their architecture. Change is unavoidable. The more important question is whether that evolution occurs deliberately or incrementally through a series of disconnected decisions.

Techcombank’s experience highlights the importance of internal capability in this process. Nguyen repeatedly emphasised the development of engineering disciplines, architectural governance and internal expertise. Technology partners can provide specialised capabilities, but long-term architectural direction remains the responsibility of the institution itself.

This distinction matters because architecture influences decisions that extend far beyond technology. Product development, operational processes, customer experience, data management and risk controls are all shaped by how systems are organised and connected. Banks that lose visibility over those relationships may find themselves constrained by complexity even after substantial investment.

Nguyen’s focus on internal engineering capability reflects a broader industry trend. As transformation becomes continuous rather than episodic, institutions increasingly require permanent architectural capability rather than project-based oversight. The issue is no longer delivering a single programme successfully. It is governing a technology environment that continues evolving year after year.

HBL’s experience reinforces the same point. Anwar’s discussion consistently returned to architectural choices around decomposition, separation of responsibilities and simplification of the core environment. These decisions were important not because of the technologies involved but because they determined how easily the institution could adapt in future.

Architecture therefore becomes a mechanism for preserving optionality. Decisions made today influence how difficult future changes will become. Institutions that reduce unnecessary dependencies may find it easier to introduce new services, modify processes or respond to changing market conditions without repeatedly revisiting the entire technology estate.

SBI’s framework provides perhaps the clearest conceptual model for understanding this challenge. Rajagopalan’s separation of engagement, record, integration and intelligence layers is valuable because it clarifies responsibilities within the architecture. Different components can evolve at different speeds without forcing simultaneous change across the entire organisation.

The significance of this approach extends beyond technology. Clear architectural boundaries help institutions manage accountability, governance and risk. They also provide a structure for introducing new capabilities while maintaining stability in critical systems.

This becomes particularly important as AI assumes a larger role within banking environments. Institutions must decide where intelligence capabilities belong, how they interact with systems of record and how decisions remain governed and accountable. Without architectural clarity, AI risks becoming another source of complexity rather than a source of value.

The future banking core is therefore unlikely to be a single platform sitting at the centre of the institution. Increasingly, it functions as part of a broader environment connecting products, accounts, payments, channels, data and intelligence capabilities through governed interactions.

This shifts the focus of leadership. Success is no longer defined solely by selecting the right technologies or completing major programmes. It depends on maintaining coherence across a growing number of moving parts.

Architectural ownership therefore becomes more important, not less. Banks may work with a wide range of specialised providers and external partners, but responsibility for resilience, governance, customer experience, data integrity and execution risk remains with the institution itself.

The institutions making the most progress appear to share a common understanding: technology decisions are ultimately organisational decisions. Architecture determines how information flows, how work is performed, how risks are controlled and how future change occurs. In that sense, architecture is becoming one of the most important forms of institutional strategy.

The question is no longer who supplies the technology. The more consequential question is who defines how the institution evolves around it.

The next generation banking core

The next generation banking core will not be defined by a single technology, architecture pattern or implementation model.

The institutions examined in this article differ significantly in scale, market structure, regulatory environment and strategic priorities. MUFG operates across multiple jurisdictions with complex regional requirements. SBI manages one of the largest banking franchises in the world. HBL serves a large domestic market while modernising critical infrastructure. Techcombank and MSB are pursuing ambitious growth and digital transformation agendas. Standard Chartered is reshaping processes, operating models and organisational capabilities across an international banking network.

Despite these differences, several common themes emerge.

The industry appears to be moving away from the idea that core modernisation is primarily a technology replacement exercise. Technology remains important, but the question increasingly revolves around architecture, governance, operating models and execution discipline. Institutions are investing not only in new platforms but also in the organisational capabilities required to sustain change over time.

Banks are placing greater emphasis on architectural separation and simplification. Whether expressed through Rajagopalan’s framework of engagement, record, integration and intelligence layers, Anwar’s principle of maintaining a lean core, Nguyen’s focus on engineering discipline or Khánh’s emphasis on independently evolving domains, the underlying objective is similar. Institutions are seeking ways to reduce dependency, improve flexibility and avoid creating new forms of complexity as they modernise.

Resilience has become inseparable from transformation. Modernisation programmes are evaluated not only by what they deliver but by how safely they are delivered. Architecture, cybersecurity, governance, recovery capability and operational discipline are becoming embedded considerations rather than downstream controls.

The economics of transformation are broadening. Cost reduction remains important, but the strongest business cases involve operational leverage, scalability, customer experience, productivity and future adaptability. Banks are investing not merely to lower expenses but to improve their capacity to evolve.

Finally, institutions are recognising that transformation is becoming a permanent capability rather than a periodic programme. The pace of technological, regulatory and competitive change means that few banks can expect long periods of stability between major transformation cycles. The challenge increasingly lies in creating environments that can absorb continuous change without repeated disruption.

These observations do not imply that the industry has settled on a single destination. The banks featured in this article continue to make different choices regarding architecture, migration sequencing, cloud adoption, operating models and governance structures. Nor is it clear that one approach will ultimately prove superior across all markets and operating environments.

What is becoming clearer is the direction of travel. The traditional model of periodic transformation followed by long periods of relative stability appears to be giving way to a more continuous approach in which architecture, operating models and technology capabilities evolve together.

In such an environment, the core itself becomes only part of a broader strategic question. Competitive advantage increasingly depends on how effectively institutions connect customer channels, products, payments, data, intelligence capabilities and operational processes into a coherent and governable whole.

The future core functions as part of an organisational capability that allows institutions to introduce new products, support new customer journeys, incorporate new technologies and respond to changing market conditions without repeatedly rebuilding the bank around them.

The strategic question is no longer whether banks should modernise the core. Most large institutions already know they must. The difficulty is determining how to modernise continuously while preserving control over architecture, governance, operational stability and execution risk.

The institutions most likely to succeed may not be those that move fastest or spend the most. They are more likely to be those that can repeatedly adapt while maintaining coherence across technology, operations and governance. In an industry defined by continuous change, that capability may prove more valuable than any individual technology decision.

Chat with us WhatsApp