DXC Legacy2Digital Transaction Engine
Successful Banking Digitalization with DXC
The banking market environment is evolving rapidly. Banks respond to the changing customer expectations and the ever-faster technological progress by investing in the digitalization of their services. Examples of areas for such investments are modern payment options, personalization, enabling ecosystems by means of open banking, or support for crypto assets.
Digitalization creates huge opportunities—but is also a big challenge. A challenge that can only be mastered if the foundations are laid right. And a key piece of the foundations are the IT systems at the core of the bank: all digital services and processes are built on top of these.
The core’s flexibility is key
Established banks often run rock-solid but dated IT systems that implement the backbone of the bank’s operations. These so-called legacy core banking systems typically consist of dedicated silo applications for each main functional block, such as partner management, contract management, account management and payment services. At larger banks it is common to have heterogeneous and redundant application landscapes in place, due to their complex organizational structures and historic mergers & acquisitions. This leads to an application zoo that is hard to tame and manage efficiently.
Legacy core banking applications are usually expensive in maintenance, of rigid structure and very inflexible. They represent a major obstacle to change when addressing new business needs like digitalization. Adopting them is expensive and time-consuming, leading to an inacceptable time to market for new functionalities, such as:
- the provision of real-time transaction data for customers,
- the deployment of own APIs as well as the usage of external APIs,
- the implementation of new payment options,
- the introduction of digital identities,
- the launch of new products or product bundles,
- the enablement of new and agile business models.
Consequently, some 70 percent of banks are reviewing their core platforms (according to a McKinsey survey conducted in May 2019).
Improving the core is highly challenging
There are three main options for modernizing legacy core banking systems
1. Big-Bang
In a traditional ‘big bang’ migration the complete core banking system is replaced with a modern COTS (commercial off-the-shelf) platform in a single step. Such a migration involves a major cut-over procedure.
2. Parallel operation
Deployment of a second core banking platform for a new product or new customers, that will be operated next to the existing legacy system. The new platform can be made from scratch built on a state-of-the-art microservices architecture or it can also be a modern COTS system. Existing products/customers can then be moved with subsequent migration(s) onto this platform.
3. Smart transformation
Evolutionary core banking transformation that performs a stepwise, selective replacement of legacy modules with modern, commercially available applications
‘Big bang’ core banking migration projects are extremely expensive and risky as the impacted functionality is of highest business criticality and the available skills and knowhow are scarce. Moreover, such large-scale migrations typically come with long innovation freeze periods, making the business unable to respond to market changes in a timely manner.
The ‘parallel operation’ approach offers a speedier introduction and a lower risk level when the newly created or purchased platform is rolled out in context of a new product or to host newly acquired customers. This way a ‘big bang’ migration can be avoided (existing products and customer are to be moved onto the new platform with subsequent releases) at the price of introducing new dependencies and redundancies. This results in further digitalization challenges as long as the migrations are not complete.
It is no wonder that decision makers wish to be able to selectively modernize or consolidate parts of their legacy core banking landscape. Instead of a ‘big-bang’ or ‘parallel operation’ approach, they seek smooth, iterative—in one word: smart transformation options, which promise early results and better risk control. The bank’s ability to respond to changes in its environment is to be maintained at all time.
Smart core banking transformation enabled
The DXC Core Banking Platform is designed exactly to fulfill these requirements. It implements a modern service-oriented architecture that allows for selective deployment of business functionality. With its strict modular structure, it offers highest possible flexibility when it comes to integration with a legacy core banking system.
The co-existence of the legacy system and the DXC Core Banking Platform is enabled by the Legacy2Digital (L2D) Business Transaction Engine (BTE) which efficiently orchestrates transaction processing cross-platform. For more details about the engine, please refer to the information box below.
Flexible transaction orchestration with the L2D Business Transaction Engine (BTE)
The DXC Core Banking Platform features a dedicated transaction processing component, the L2D Business Transaction Engine, that orchestrates the relevant business applications such as Account management, Position keeping, Fees and commissions, etc. for each type of banking transaction. The process definitions can be managed separately using the Process Builder and loaded into the transaction engine for steering the transaction execution. For the support of efficient process composition, the product comes with a library of proven standard banking processes that can be used.
The surrounding business applications are integrated with the engine through standard connectors. These connectors are responsible for the verification of all incoming and outgoing messages and their transformation between the connected systems’ data representation and the engine’s internal ISO 20022-compliant reference data model.
In operation, all running and completed transactions are monitored over the Administration Dashboard. The dashboard also offers failure-management features such as online message correction or transaction re-initiation. This architecture is visualized in Figure 1:
Figure 1. Scalable and flexible messaging-based transaction engine
To minimize migration risks, the L2D Business Transaction Engine also offers support for parallel operation of the legacy application and the new system that will replace it. The parallel operation can be set up in various constellations such as Master-Slave (transactions are routed to both systems where the Slave processes them only for testing purposes) or even Master-Master (transactions are split based on attributes such as transaction type or customer segment and routed to one system or the other). In a Master-Slave setup, the engine allows the efficient implementation of control circles with automatic verification of transaction results. The details of this approach are presented in the following information box.
Automated control circles in Master-Slave operation for highest risk control
The L2D Business Transaction Engine was built with the very purpose to enable smooth legacy core migrations: and was deployed effectively in the replacement of an old banking mainframe application landscape. Using this highly flexible and scalable component, the old functional monoliths were successfully migrated in an iterative manner. New clients of DXC now can benefit from this proven method and tooling for legacy core migrations.
Thanks to the Standard Connectors and the Master-Slave & Control Circle Toolkit, both legacy and modern components can be integrated, and their parallel operation is established quickly. During the transition phase, the legacy application keeps its master role in transaction execution, whereas the new application processes the same transaction in ‘slave mode’. The purpose of the slave operation is to verify the new component’s functionality and output in a productive, but low-risk environment using automated control circles. After the successful verification, the roles get switched and later the legacy component can be decommissioned. This can be done conveniently and without any code changes in the transaction engine itself! Figure 2 shows an overview of the transformation process:
Figure 2. Transformation process using control circles
To achieve a smooth transition, the DXC project methodology expects the effective collaboration of multiple roles. A process designer is responsible for defining the transaction processing rules and procedures. A migration specialist sets up the required connectors to the legacy and the new application, amends the process definitions with the configuration for parallel operation and deploys the control circle mechanism. In the transition period, an operations specialist monitors the transaction processing and the control circle outputs—and initiates changes in the technical implementation if necessary. This perspective is visualized in Figure 3.
Figure 3. Control circles with the L2D Business Transaction Engine: technical perspective
State of the art integration and transformation facilitation capabilities are necessary but not all ingredients needed to create a flexible core banking landscape that enables banks to efficiently compete in the digital age. The DXC Core Banking Platform consists of modern and easily adaptable applications that can be selectively deployed into an existing landscape. Thus, banks can enhance their core’s flexibility exactly where it is needed most.
Such advanced capabilities make the DXC Core Banking Platform—and especially the L2D Business Transaction Engine—an ideal candidate for augmenting or replacing legacy core banking systems, ultimately enabling the successful digitalization of banking services.
Various implementation schemes supported
The DXC L2D Business Transaction Engine and Core Banking Platform can be deployed in various ways to facilitate legacy core transformations. It supports the following implementation schemes:
- Legacy Integration
Multiple existing legacy modules are integrated to interact with each other (e.g., an e-banking contract order tool gets connected to the contract management application to eliminate a media break, or multiple payment services systems are integrated to streamline the use of SWIFT, optimizing transaction costs). The flexible L2D Business Transaction Engine allows the efficient integration of a wide range of existing applications, as displayed in Figure 4. In this case, the DXC Core Banking Platform plays the role of the transaction orchestrator and does not take over any business functionality from the existing applications.
Figure 4. Integration of legacy modules with the L2D Business Transaction Engine
2. Redundancy Consolidation
Redundant legacy applications are consolidated and replaced by a modern single application. Building upon the “Legacy Integration” implementation scheme, the L2D Business Transaction Engine allows for a low-risk, step-by-step consolidation of redundant legacy applications, as visualized in Figure 5.
Figure 5. Step-by-step consolidation of redundant legacy applications
3. Selective Replacement
Existing legacy modules are selectively replaced with the help of the L2D Business Transaction Engine (BTE). For example, the migration of a dated and inflexible payment services module onto the modern DXC Payment Services application, as displayed in Figure 6.
Figure 6. Selective replacement of an existing legacy application
4. Iterative Migration
Legacy core banking systems are migrated in iterative steps. Figure 7 visualizes how the selective replacement of legacy modules can be applied for a step-by-step transformation of existing core banking platforms.
Please note that the L2D Business Transaction Engine does not only play an important role in the seamless application migration, but becomes an integral part of the architecture, providing high flexibility for changes in the future. And whenever automated propagation of changes in underlying master data (e.g., partner details modification, account closure, access revocation, etc.) is necessary, banks can profit from DXC’s Master Data Notification application that can be plugged into the architecture with ease.
Figure 7. Evolutionary, smart transformation of a legacy core system
Applicable in business critical domains
The above described low-risk implementation schemes have been designed to be applicable even in the most critical business domains, such as account position keeping, booking or payment services. The following table presents a set of example areas, where the L2D Business Transaction Engine creates unparalleled business value.
Transform your core smartly with DXC and win the digitalization race
Digitalization requires high flexibility on the channels with extended access to the core business funtions via standardized APIs. To gain this flexibility on the channel side, banks first need to make sure that their core is flexible enough. This is exactly where DXC can help. No matter if it is about the selective replacement of single legacy modules, the consolidation of redundant functionality or the transformation of the whole core banking landscape, DXC provides you with the right tools to make it happen. Smoothly. No ‘big bang’. The digital way.
About the author
Dr. Marc L. Brogle brings over 28 years of IT industry and research experience to his current role as CTO Banking Switzerland at DXC Technology. His responsibility is to shape the growth and innovation strategy for DXC’s banking services portfolio in Switzerland aligned with the business strategies of its banking customers. Furthermore, he drives the IT strategy for DXC Technology’s core banking solution in Switzerland, introducing new concepts such as micro services, cloud computing, hyper converged infrastructure and open APIs. Marc is leading the CTO office at DXC’s banking service center in Switzerland, taking care of the whole architecture capability and governance. He is actively engaged in various Swiss banking IT communities and represents DXC as founding member of openbankingproject.ch, with the goal to operationalize open banking in the Swiss financial services market. Marc also has commercial industry research experience in cloud computing, Intelligent transportation systems, and eMobility. He holds a PhD in Computer Science.