Life beyond legacy: exploring the options

Amanda Gilmour is product director, payments, at Temenos.

The payment industry has never seen so much change or opportunity. It continues to be reshaped by shifts in the economic landscape, new technologies and customer needs and this is set to continue, writes Amanda Gilmour.

Being able to adapt is not just about compliance any more, it’s about survival.  Banks are not only looking to refresh their technology to cope with regulatory forces and improve process efficiencies, but to support customer retention and access new opportunities. However, with so many different development options to choose from, how do banks decide which approach to take?

Better the devil you know?

Upgrading a system may enable a bank to gain a quick win both in terms of delivery costs and time, causing minimal disruption to the business and low internal exposure. However, the process of adding new channels, adapting to various formats and accessing new clearing systems is likely to be a costly and time-consuming exercise, as legacy solutions cannot be fully agnostic. At the end of the day, banks that choose to upgrade may still be running on old architecture, and therefore a system which is often inefficient, inflexible and not equipped for today’s’ 24/7 multichannel banking. Sooner or later a new system will be required, so why spend time creating an instant legacy solution?

Alternatively, a new payments system could be built in-house. The solution would in theory meet all of a bank’s needs, but it is worth remembering that internally run IT projects generally experience a 70% failure rate. These failures can often be attributed to budget and timeline overrun, as well as the outright termination of the project before completion, due to veering off course or goals that become unreachable. In addition, even with the support of external payments consultants, a bank runs the risk of being too close to its existing system and current processes to evaluate what is needed to achieve the optimum solution. Usually, the risks of undertaking an internal project outweigh the benefits.

Let someone else do the work

If a bank has a short-term strategy, using a white-labelled payment solution might be suitable. It can allow a bank to focus on other business elements, rather than having to invest heavily in software development, data security, and the other associated costs of developing an in-house system. In addition, using an ‘off the shelf’ solution can dramatically reduce delivery time, since in theory a bank is offering a product that is already made, tested, and ready for use. It must be considered though, that a true white labelled solution can be very limiting and is not usually suitable for those that wish to configure elements of their system, develop new products or those that have increasing volumes as these will make costs unmanageable.

For a longer-term strategy, an established system from a software vendor is an obvious solution. Specialist vendors help banks to realise significant savings because they have already done the work. This ability to focus on core competencies can mean the difference between a software project that is bogged down by non-application specific details, and a project that successfully hits milestones and makes it to completion. However, if the ideal solution isn’t available within the market then banks may wish to consider working with a partner. But this is only suitable for those financial institutions that are able to invest significantly in terms of time, effort and of course funds.

Payments hubs can go beyond the now

So, there are lots of development options available. But, once a bank has selected the right approach, it must select a software solution. It is widely accepted that if a bank is looking to buy externally the only credible option is an end-to-end payment services hub model. A hub approach can greatly reduce complexity, enabling institutions to process any payment, in any format, for any customer. Supporting true straight-through-processing, key additional benefits of hub architecture include the ability to bring new products to market more quickly, all while reducing costs and improving compliance capabilities. Ideally universal, payments hubs can also offer functionality that gives control back to the bank, enabling payments to be prioritised, put on hold or managed according to client strategies ‘at the flick of a switch’. In addition, tools that support data virtualisation, big data analytics and components that reduce fraud, risks and errors make hubs so appealing.

Functionality is also available to support corporate treasurers, supporting a bank’s retention strategy by offering these added-value-services to clients. For example, tools that enable treasurers to ‘lookup current and previous balances with detailed and graphical summaries of individual and consolidated corporate accounts. This functionality can support liquidity management, including understanding surplus/deficit values, view the last n days balance summaries, average balances, interest rate on accounts and overdraft limits .’ [1]

The right development options and solution should depend upon the banks strategy. No matter how small a payments system project seems, the impact on the business (and its balance sheet) should never be underestimated. Therefore, if a bank wishes to address its legacy system it should look for a solution that is sufficiently agile to not only address its current issues and constraints but any that appear in the future. After all, ‘The only thing we know about the future is that it will be different’.[2]