It is no surprise to many in the industry that we are at an inflection point in the life of our legacy core banking systems. Created in the 1960s and 1970s, they are now being asked to fulfill the requirements of an increasingly mobile and diverse client base, all while repelling the intruders at the gates—the FinTechs, innovators, and disruptors.
In the face of these challenges, technology organizations are not only afraid of touching the core banking systems, but unable to see a clear path to modernizing the core without significant cost and risk. NTT Data Consulting recently surveyed customers and banking executives about their efforts to modernize the core. We found that although 80% of business executives plan to perform assessments around core replacement, only 15% believe those plans will carry forward to an actual modernization initiative. (It also showed that only 4% thought the initiative would be completed within the next three years.)
Despite the widespread acknowledgment that the core is in need of replacement, organizations’ spending patterns showed a real fear of touching the core system: 80 to 90 cents of every dollar are spent on “bolt-ons,” integration, shadow systems, etc., all in an effort to not trigger a core meltdown. So I guess we can throw out functional decomposition as an approach to replacing the core banking system.
The resulting question is: How do you go about replacing the core banking system without touching it?
We’ve been helping our clients with a new approach that accomplishes these goals while decreasing the implementation risk:
Isolate yourself from the core. While working through business case, vendor selection, etc., make a conscious effort to isolate yourself from the core banking system. Other than your GL system, not many of your SORs will have as many integration points as core banking. By implementing a middleware layer between the core and the channels and upstream and downstream systems, you’ve effectively isolated yourself from the main issue.
Communicate using industry and business terminology. When isolating, ensure that all messaging takes place using industry vernacular. Use an industry model (e.g., IFX, Swift, MISMO, BIAN) as the base, and add elements and values to customize for your organization. This is as important as the isolation layer because you currently communicate with the core through its series of codes and configurations. Consider this your Rosetta Stone.
Now that you’re isolated, you have options as to how you want to replace the core. There are many ways to do this, but here are the three approaches we’ve been recommending:
- 1Big bang. Although this may work for smaller financial institutions, we wouldn’t recommend it for larger banks. Once the new banking system has been implemented, the middleware layer swings all integration points from one core system to another.
- 2M&A. This model reduces some of your risk by allowing you to stand up both core systems and letting the middleware layer decide which system to use based on your implementation approach. You can shift by location, segment, or any other cut of clientele you choose. Once all waves have moved to the new core, shutting down the old core is simpler, and the middleware all points to the new core.
- 3Shadow. In our experience, this option has the most upside in terms of aligning to business strategy and facing the competitive challenges of disruptors and innovators. Work with a vendor to create the core banking system that best meets your businesses capabilities and strategies (there are many options here, which we’ll talk about in an upcoming post). All new clients are transitioned to the new core banking system while the old core is still running. This may include new products and features available through APIs to share this customer data with third parties (think Connect with Facebook or Amazon Web Services). Customers of the old core can be moved over in a more methodical fashion, while certain segments or products can be left behind on the old system (should the cost not warrant converting to the new). The downside of this approach is maintaining two core systems for a very long time, but the old core has been minimized, and the new core has the advanced features you need to compete in the new marketplace.
In our next core modernization post, we’ll discuss some new core banking system options, the features they offer, and their suitability for institutions of various sizes.
Post Date: 4/27/2016