It is no surprise to many in the industry that we are at an inflection point expecting a lot out of our legacy of 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 after a long era of repelling the intruders at the gates—the FinTechs, innovators, disruptors and their direct competitors.

In the face of these challenges, technology organizations are not only afraid of touching the core banking systems but are unable to see a clear path to modernizing the core systems without facing significant cost and risk.  NTT DATA Consulting recently surveyed customers and banking executives  about  their efforts to modernize the core systems.  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.

"80% of business executives plan to perform assessments around core replacement, only 15% believe those plans will carry forward to an actual modernization initiative."    

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 “real-time” accounting systems, etc. as an effort to not trigger a core meltdown. With this in mind, functional decomposition as an approach to replace the core banking system can be dismissed.

The question here is: How do you go about replacing the core banking system without touching it?  There lies 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 an integration/services layer between the core and the channels and upstream and downstream systems, you can effectively isolate 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 canonical 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 that are recommended:

  1. The Big-Bang “Theory” – Although this may work for smaller financial institutions and in theory for larger institutions, it isn’t recommended forthe larger banks. Once the new banking system has been implemented,  the middleware layer swings all integration points from one core system to another.  
     
  2. “M&A” - This model reduces some of your risk by allowing you to build 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 layer points to the new core.
     
  3. “Shadow Bank” - In our experience, this option is most advantageous 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 business capabilities and strategies (that’s a whole different subject for another time – there isn’t a clear winner that meets all needs).  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 of 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 market place.

There are successful case studies across the banking landscape. While a few have been successful within the US, there are a number of great examples around the globe.