Core Banking Systems

Data held by banks represents one of the world’s most valuable assets, but what use is that data if it is trapped in aging mainframe systems that are unable to meet the demand’s of today’s consumers?

Mainframe systems literally enabled the rise of modern commerce. Their robust batch processing capabilities have allowed unprecedented growth in the financial sector during the last 70 years but now cause challenges for banks trying to scale to meet the demands of a modern banking customer who requires 24/7 realtime access and control of accounts from any device. As fintech disrupters and digital-first banks experiment with blockchain and other innovations of the digital era, established banks are in danger of being left behind. Established banks must modernize their core banking systems if they are to compete in our new digital-first reality.

The promise of modernization

In the years since the original mainframe systems were developed, the landscape of the technology industry has changed dramatically. Hardware, once a competitive advantage for the world’s premier institutions, has become increasingly commoditized. The exponentially increasing pace of technological innovation means firms can no longer risk being locked in to proprietary technologies. To leave firms prepared for the future, modernized core banking system must offer firms flexibility, agility, and scalability.


The world of fintech is a volatile one at the moment. Perhaps your organization has yet to decide what its vision of the “bank of tomorrow” looks like. No matter how it operates, we can be pretty sure this “bank of tomorrow” doesn’t run an IBM mainframe. A core banking system that is dependent on a specific hardware vendor leaves an organization far fewer options going forward; a core banking system based on open system leaves many more options.


Sure, you may be able to make your legacy core banking system work for the here and now, but want happens when the board demands you implement blockchain? What if your competitors offer to process payments in less than an hour? How will your legacy system adapt? Both your systems and your development teams need to be agile enough to adapt to the changing technological landscape.


Traditional batch processing was extremely efficient in that it freed up the system during the day for use and processed transactions overnight when the system was in lower demand. Modern online banking requires the system be available 24 hours a day, straining the computing power of legacy systems. With highly variable demand on the system across the day, month, and year, legacy computing environments require a surplus of computing power to meet peak demand. Modernized systems make use of distributed environments and cloud elasticity to more efficiently allocate resources, minimizing cost and maximizing performance.

Modernization Roadblocks

Given the obvious benefits of modernizing core banking systems, it would be easy to question why legacy systems, and especially legacy mainframe systems, continue to exist. Perhaps this is why so many people are surprised when confronted with statistics saying that “nearly 100 percent of all credit card transactions and 90 percent of Fortune 500 companies all depend on the IBM mainframe.” It’s important to remember that as old as these dinosaurs may be, they still work. The complexity, cost, and risk associated with modernization projects continue to discourage even many forward-thinking banking executives from taking the next step in digital transformation.


Core bank systems are often exceedingly complex. These systems are often several decades old, with decades worth of custom features and modifications there isn’t a shred of documentation for. Complex integrations with other critical systems only amplify the problems and the cascade of bank mergers have left many banks with redundant, incompatible systems.


Let no one tell you modernization is cheap, but, with maintenance, licensing fees, and increasing competition for disappearing legacy skill sets, neither is operating a legacy system. When comparing costs of various modernization options, make sure you take into account change management costs (often extensive) and integration costs (over 30% of a core banking system replacement cost is in handcoding legacy code for integration). Automated code transformation can decrease both reduce software costs and decrease the need for costly and disruptive change management through an incremental process of like-for-like transformation.


Cybersecurity is a top-of-mind issue for CIOs in every industry, but the specific privacy, data security, and regulatory compliance requirements in the banking industry pose an even greater challenge. It’s no wonder 46% of banks (and almost all large banks) report a high or very high risk with CBS replacement. As great as the risk of change may be, with the threat of fintech startups and digital-first banks ever growing and the near constant disruption in the financial industry leaving the future uncertain, the risk of doing nothing may be event greater.

Progressive Modernization

Financial institutions are no strangers to balancing risk and reward. There exist many options from complete replacement to short-term integration solutions leaving the legacy mostly as-is; between these two lie various progressive modernization options that slowly replace the legacy with modern, digital systems. At Blu Age, we are strong proponents of incremental, iterative processes as a way of reducing the overall risk of a modernization project. Systems can be prioritized for migration and replacement, costly change management can be minimized, and a modern, digital-ready can be achieved without the risk of a big bang project.

Danger: Disruption ahead

There is no denying, technological disruption is coming for the banking industry. As mobile technologies redefine where a bank is, blockchain redefines how transactions are processed, machine learning and big data analytics redefines what it means to know your customer, and artificial intelligence redefines customer service, the bank of the future will come to look very different from the ones we are accustomed to. Before it is too late, banking executives must ask themselves: is our core banking system digital-ready?



The Blu Age Approach to Legacy Modernization

Knowing your legacy modernization options

Most companies today have a strategy for—or at least some goals surrounding—digital transformation. But as much as a coherent digital strategy is recognized as a necessity in today’s business world, many companies still struggle to achieve their digital goals. One common barrier they face is their dependence on legacy software. Removing this barrier has the potential to accelerate a company’s digital transformation, but it is important to understand that there are a number of options when dealing with legacy applications:

Option 1: Replace

The simplest option conceptually—though often not the quickest or most cost effective—is to replace the existing application with a commercial off-the shelf solution. This is often a good option when an application’s functionality is no longer aligned with the business’s strategy or functional requirements. Although the process is conceptually simple (just buy new software!), COTS solutions often require a lot of work to integrate with existing systems. The complexity and risk increases with the number of legacy applications and databases and how central the application is to core business processes.

Option 2: Traditional Rewrite

The next option to consider is a traditional rewrite of the software. A traditional rewrite goes through the full Software Development Lifecycle, including specification, detail design and development. This option will provide modern, cloud-ready technology and the flexibility to add new features and functionality. Unfortunately, traditional rewrites often fail; even successful rewrites are frequently delivered past their due date and well over budget.

Legacy systems often have decades worth of embedded business logic hidden within their code that even subject matter experts may have difficulty discovering. The burden on the company becomes, therefore, not only to define the target architecture, gather test cases, develop a new application, and integrate the application into their existing IT ecosystem, but also to retroactively specify the existing functionality and business logic that have been achieved through countless cycles of development, improvement, and debugging.

Without this knowledge developers are basically left reinventing the wheel, contributing to cost and time overruns. A lack of functional equivalence may only be discovered at the end of a months or years long project. Therefore, while the desire to build the ideal replacement application from the ground up is undoubtedly enticing, it is important to keep in mind the risk it entails.

Option 3: Modernize the Legacy, Wrapper to the Cloud

This is a common intermediate step, a digital-era version of the classic lift and shift. The legacy applications are modernized to make them maintainable without actually transforming the code. The result is still written in the legacy programming language but is in a variety that can be maintained using modern IDEs for the time being. Wrappers and middleware can be used to combine and integrate these applications with some modern digital technology or to migrate them as is to cloud environments.

While this may be a cost effective solution in the short term, and may be desirable in situations where speed is more important than long-term maintainability and security, such a solution increases a firm’s technical debt and doesn’t really solve the problems associated with the legacy software, which remains technically and conceptually unchanged, so much as provide a temporary work-around. In the long run, the firm is still dependent on disappearing legacy skills and burdened with a higher total cost of ownership.

Option 4: Automated Code Transformation

In recent years a fourth option has emerged. Rather than getting rid of the legacy application, slapping a band-aid on it, or attempting to recreate it, an automated process can be used to perform a functional like-for-like transformation. The functionality supported by the legacy application will still exist with all its complex embedded business logic, but it will be transformed into modern, re-architected code like Java, JavaScript, or .NET.

The automation reduces human error, increases speed by 3 to 4 times compared to the traditional rewrite, and may or may not include automated database modernization/migration. This process covers not only the transformation itself but also verification that the business rules have been preserved during the process. This option appeals to many IT leaders, because it accelerates their digital transformation efforts while simultaneously reducing the risk of failure.

When choosing a partner for this type of modernization project, it is critical to consider the code quality of the output. For instance, many providers will provide quick automated code translation from procedural languages to modern languages which nonetheless retains the procedural flavor of the original rather than producing truly modern, object-oriented code (In the case of a COBOL to Java translation, this is known as JOBOL). Be sure to choose a partner who uses tools such as SonarQube or CAST to measure code quality.

The Blu Age Approach to Legacy Modernization - LEARN MORE

Iterative, Automated, and Incremental – A DevOps Approach to Legacy Modernization with Blu Age

Way back in 2001, a small group of people issued a manifesto that came to revolutionize the world of software development. The principles underpinning this movement, known as agile development included a commitment to the end user, an ability to adapt to changing requirements, frequent delivery, collaborative work environments, results orientation, maintainability, simplicity, and constant improvement.

The secret behind successful modernization projects

Migrating applications from aging programming environments (e.g., Cobol, Pacbase, etc.) to modern Cloud-ready technologies (Java EE, .NET…) is a challenging task both at functional and technical levels. Unlike classical software projects -usually initiated from scratch- modernization projects start with millions of lines of code to be explored, understood and transformed.

Functional Equivalent Modernization of Legacy Applications

Technology is evolving at an exponential speed. So do applications, code and the complexity of IT legacy. Maintenance costs for legacy applications are constantly increasing, and require rarefying IT skills. Modernizing business strategic applications, freeing them from aging technologies and opening the way to new functionalities and Digital is now key to sustainable growth.

Looking forward to developing Batch Applications with C# .NET: take a look at Summer Batch

For a number of years the Java world has addressed the challenges of Batch processing with Frameworks such as Spring Batch and IBM WebSphere Compute Grid. Well known for their performance and robustness, they are now widely used, in particular by the Financial Industry.

With the open source Framework Summer Batch, you can now create Batch Jobs in .NET C#, with checkpoint restart, chunk processing and parallel processing.

How to start a successful Big Data Application from scratch

Let’s imagine that you are a Software Developer working in a highly innovative data-driven start-up delivering a cutting-edge product called “Data Digger Solution”. It gathers raw data from various heterogeneous sources (e.g. social medias, websites, CRM, online sales, servers, emails, etc.) and process them to gain tangible insights using fresh semantics. These insights can be used to provide concrete and profitable interpretations (e.g. in terms of sales and web presence) to the clients.

Modernize Legacy Batch Applications to a C# .NET Target Architecture

The Java world has been addressing the main challenges of Batch processing, performance and robustness, for a number of years with frameworks such as Spring Batch or more recently with “liberty Batch” by IBM. With Summer Batch, an open source .NET Batch Framework, you can now create Batch Jobs, with checkpoint restart, chunk processing, EBCDIC file readers and writers, GDG like behavior in C#.

Blu Age Community

The Blu Age® Community
Application modernization & Generation




All trademarks and registered trademarks referreded in this website are the exclusive property of their respective owners.
MDA, UML and MDD are either registered trademarks or trademarks of OMG, Inc. in the United States and/or other countries.