So another year begins and for many this brings a New Year's resolution – getting fit to name but one.  For many financial institutions however I wonder if the resolution could be to (finally) start the process of overhauling creaking and aging payments processing technology.

It’s a never ending challenge for banks maintaining their IT infrastructure as well as having to meet the challenge of new entrants into the market (Third Party Providers or TPPs), ongoing regulatory challenges (Basel III, FATCA, MiFID II, etc.) and changing market drivers e.g. the move to real time payments across the globe.

So it is no wonder that Bank CIOs/CTOs/Heads of Payments businesses may baulk at starting a process that holds great risk with perhaps the reward simply being able to keep up with the pace of change. But for those that bite the bullet we salute you and wish you good luck in achieving a positive outcome and all the benefits that come with a successful payments transformation project. 

One of the biggest areas of risk for an organization in the process of migration to a new payments infrastructure is not necessarily selecting the right system to implement, but it is the process of integration of the new system into the bank’s existing IT infrastructure and interfacing to a wide range existing back office applications.

Having worked for a major Software Integration (SI) firm in a previous life, I know that the cost and difficulty of integration (not to mention the ongoing maintenance and change management challenges once a new system is installed) is ALWAYS underestimated by application vendors.  This is typically simply down to the fact that to win the deal the costs (and time) associated with system migration and integration to back office applications are wildly (and perhaps optimistically) underestimated (or should that be guesstimated). Thus the result is often a significantly underestimated project delivery cost for the vendor/SI partner and significant slippage when it comes to the bank’s delivery timescale expectations (not to mention Bank-Vendor relationship damage).

One suggested approach to significantly reduce the risks associated with the implementation of such a mission critical application, is to make a clear decoupling of core system selection with the system integration. That is, cleanly split the selection process (RFI/RFP/ITT etc) into two parts, one covering the core payments application (covering functional/non-functional requirements, etc.), the other procuring specialist technologies/solutions that are built to help simplify the complex challenges associated with new system integration.  This is an approach that I am aware that a major North American bank has recently taken and it seems eminently sensible to me.  A case of ‘divide and conquer’ helping de-risk such ambitious implementations.

I feel the above approach works well as it ensures the selection of best of breed solutions to meet both the bank’s overall core payments processing requirements, but also clearly disassociates the new system implementation process and the technology to help deliver significantly more efficient application integration. This of course, reduces the overall project implementation risk and thus the stress to those long suffering Heads of Payments!  

Happy New Year!