Banking Process Orchestration: how to integrate legacy systems and new cloud-based digital services (Kubernetes)

Banking process orchestration is the key to enabling legacy platforms and new cloud-native services to coexist. This direction is driven by customer expectations: the global digital banking platform market is expected to grow at a compound annual growth rate (CAGR) of 10.66% between 2024 and 2033. This figure comes from a Grand View Research study, which identifies the increasing demand for mobile services, online payments, and remote account management as major growth drivers.

These demands accelerate the development of cloud-native or hybrid services that provide elasticity, resilience, and performance levels that would otherwise be unattainable. Legacy applications, which lack these characteristics, nonetheless encapsulate decades of business logic that organizations cannot easily replace. Traditional software is stable and reliable; decommissioning costs are higher than maintenance costs; migration skills are scarce; and outcomes are uncertain.

The only viable path forward is to build an application architecture capable of integrating both legacy systems and new cloud-native services. In other words, orchestration is needed to connect legacy platforms with modern digital services.

In this article you will learn:

• what legacy systems are used for today in finance;

• why legacy systems are important and strategic;

• how to integrate legacy systems with cloud-based digital services;

• what service orchestration means and how it works in practice.

The new rules of banking

The evolution of the financial market has made Open Banking one of its core paradigms. It is no coincidence that regulations such as FIDA (Financial Data Access) govern data exchange between financial institutions. New services (embedded services, Banking-as-a-Service, etc.) and new business models (FinTech) design workflows that involve applications owned by different organizations.

As a result, the API Economy (Application Programming Interface) has emerged, based on three pillars:

1. APIs are the standard way to connect different applications;
2. Cloud is the enabling technology for building highly flexible and scalable software;
3. Orchestrators such as Kubernetes govern and coordinate the entire set of services.

Legacy systems, which play a crucial role in modern digital processes, must become an integral part of this orchestration.

The Characteristics of Legacy Systems

In banking, the coexistence of legacy systems and new digital services is always a challenge. Mobile applications and new service paradigms (online payments, smart spending, etc.) often trigger backend applications that are typically very complex.

Consider instant payments, for example: the legacy core banking system and the fraud detection engine must be queried for validation, and the transaction must be completed within seconds. In addition, digital banking processes increasingly involve external operations. Embedded banking and Banking-as-a-Service, for example, include activities performed by third parties that once again require backend processing.

Legacy platforms, however, were designed before the cloud and based on very different architectural paradigms. They are structurally incompatible with the cloud. Legacy systems were developed as on‑premises, monolithic platforms, where external interaction was limited to file transfers for procedural batch processing. Even real-time teller transactions and direct database access took place within closed networks, designed and managed by centralized platforms.

New paradigms of communication (the Internet), distributed computing (cloud), and application integration (APIs) leave legacy systems at a disadvantage. Yet, these platforms contain invaluable corporate assets: historical data, highly refined application logic, and proven business processes.

A full migration—rewriting everything as cloud‑native—is theoretically possible, but in practice faces significant obstacles:

• the cost of rewriting is extremely high;

• full transformation is uncertain and high-risk;

• the skills required to master legacy logic are hard to find, both internally and externally.

The same applies to highly customized applications: even if they were developed in the cloud, they can still be considered legacy systems. Complete re‑engineering, while desirable, is often prohibitive due to cost and risk.

There are many banking processes where certain activities remain tied to legacy environments, including:

• Balance checks: accounting ledgers and posting logic originated on mainframes and guarantee strict data consistency.

• Digital payments: card authorization is the most critical step due to interbank certification requirements and often resides on legacy systems.

• Digital account opening: customer onboarding and account setup in core banking systems are legacy processes, deeply integrated with multiple platforms and historical policies.

• Instant loans: loan engines and amortization plans rely on complex financial logic hosted on legacy systems.

Despite their stability, legacy applications must evolve. Without modernization, they cannot be integrated into digital processes. Monolithic legacy platforms must participate in modern workflows and interact with other components.

The different levels of legacy migration

Legacy modernization can occur at different levels, depending on application complexity. These options are commonly referred to as the “5 Rs”:

1. Rehosting: moving the application “as is” to the cloud without changes.

2. Refactoring: partially rewriting code to improve maintainability and modularity.

3. Replatforming: adapting code to better leverage platform services, such as database access models.

4. Rebuild: rewriting the application entirely using a microservices architecture.

5. Replace: replacing the application with a completely new solution, often SaaS-based.

Choosing among these options is a strategic decision, not just a technical one. Functional boundaries become explicit, and applications participate in orchestration using APIs and events. Legacy logic remains unchanged but becomes part of the digital banking ecosystem as reusable microservices inside containers.

Techniques for orchestrating legacy systems

Transforming legacy architectures into on-demand services requires more than choosing the right migration path. It also involves designing a new application architecture.

In banking processes like those described above, legacy-dependent operations must become coordinated steps in distributed workflows. Banking process orchestration therefore requires technical measures external to the application logic itself:

• Application containerization: software is packaged into standard containers, ensuring portability across environments and isolation, while enabling scalable usage.

• Orchestration: engines such as Kubernetes manage the container lifecycle (deployment, scaling, execution).

• API management and API gateways: applications expose functionality in a standardized way, with lifecycle management (versioning, access) and security handling.

• Synchronous and asynchronous integration: services can be invoked synchronously (immediate response required) or asynchronously (via queues or events). The two models are combined to balance latency and throughput. In instant payments, for example, critical checks (authentication, balance validation, IBAN checks) must be synchronous, while ledger posting and interbank settlement can be asynchronous.

Legacy system integration—i.e., application orchestration—is made possible through progressive decoupling and modernization, based on containerized microservices governed by Kubernetes.

This new development paradigm creates a broader ecosystem that requires additional disciplines:

• Observability: monitoring applications and infrastructure to ensure availability and service levels.

• CI/CD: automating development and release processes through DevOps practices.

• Credential management: controlling tokens, passwords, and certificates to protect sensitive data and functions.

Application orchestration: ensuring security

Security is a mission‑critical concern. Cloud adoption and distributed architectures expose applications to multiple risks. Regulatory frameworks such as FIDA, PSD2 (and the upcoming PSD3), and DORA define threats and required countermeasures.

Orchestrating banking processes therefore includes specific security aspects, covering both service usage (for example, strong customer authentication required by PSD2) and infrastructure protection against outages or cyberattacks.

The evolution of financial services through Open Banking and competition from FinTech firms compels banks to deliver digital services aligned with customer expectations. Mobile banking, embedded services, and Banking‑as‑a‑Service all require integration with legacy software and data.

Legacy system integration requires application orchestration. Legacy services must be isolated from their original environments and migrated to modern architectures—a critical effort due to application complexity and the management demands of microservices and containerization.

Successful transition paths must consider:

• the chosen migration strategy (5 Rs);

• modern ecosystem practices (DevOps, API management, etc.);

• the use of orchestration engines such as Kubernetes.

This approach enables true banking process orchestration, allowing organizations to preserve application assets while ensuring long‑term business growth.