Can banks outsource core system replacement to vendors?

Top-tier retail banks in the main developed banking markets in the West and in Asia have historically been highly skeptical about the suitability of external universal core banking platforms for their crucial domestic banking operations. Daniel Mayo, head of financial services technology at the Ovum consultancy, asks if this prejudice is still fair or could …

July 15, 2013 | bobsguide

Top-tier retail banks in the main developed banking markets in the West and in Asia have historically been highly skeptical about the suitability of external universal core banking platforms for their crucial domestic banking operations. Daniel Mayo, head of financial services technology at the Ovum consultancy, asks if this prejudice is still fair or could banks gain from outsourcing their core banking system or contracting outsiders to help with specific upgrades?

In the wake of the computer problems at RBS, when its retail bank operations in the UK fell over for a week blocking payments and other needed transactions after what it says was a failed software upgrade, many in the financial technology (fintech) sector began to wonder if it might be time for established banks in developed countries to move away from their aging siloed core banking infrastructures to an outsourced vendor-supplied operational platform. Others questioned if it was the external RBS CA-7 batch scheduling software upgrade that was actually the cause of the problem at the bank.

Metro Bank have shown an alternative approach is possible. When they set up in the UK a few years ago they outsourced their entire core banking operation to Temenos and a range of other technology partners and Sainsbury’s Bank recently did a similar deal with FIS, but they of course have the privilege of being small. Likewise, it is easier for them to introduce upgrades into newer, more flexible infrastructures.

It is more difficult to do this at established, as opposed to newer banks, because the legacy burden is much greater and higher volumes and service demands are placed upon large retail banks. Another major issue behind most project failures in the past, such as the RBS example, is that the typical implementation approach required for packaged software upgrades is not conducive to the transformation path required by really top-tier banks.

A ‘big-bang’ approach to deployment is seldom realistic for very large retail banks, given the complexity of the existing banking application ecosystem. This invariably means a bank will look to deploy the new system alongside its existing ones in a phased transformation process. However, while most modern vendors have moved to modular application architectures that should facilitate this, relatively few have offerings where the individual modules themselves are truly enterprise-ready. This is changing, with both Oracle and Infosys recently announcing plans to target this market, a market that SAP has dominated in recent years.

Lower-tier Retail Bank Perspective
In terms of deals, the core banking systems market is unsurprisingly dominated by lower-tier banks from a vendor perspective because there are more projects undertaken. Successes here can, however, be used to try to justify similar projects at larger banks.

From a simple numerical perspective, there are more tier-4 and tier-5 banks (those with assets below $10bn) than upper-tiered banks, and from a technology perspective, the scale of investment required means that it would rarely make business sense for a bank to run, let alone develop, its own systems if its assets are under $10bn.

As the role and importance of technology as a fundamental enabler of banking has increased during the last two decades with growth of digital banking, the addressable market for vendors has subsequently increased. Indeed, Ovum would expect that most banks in the tier 2 category and below (those with assets up to $100bn) would look to the external market as the de facto choice in the future if considering core platform renewal.

The largest tier 1 bank segment has, however, been more problematic for vendors. The use of packages is not necessarily an issue from strategic perspective, with many using systems from the likes of FIS Global (such as Systematics) or CSC (Hogan), but banks typically use separate systems for the main product areas across their vast universal banking IT estates, and such systems are invariably heavily customized for specific uses.

In contrast, most top-tier banks have been skeptical about the capabilities of the universal (i.e. multi-product line) banking platforms that have emerged during the last decade at smaller institutions, concerned as they are about their ability to provide best-of-breed functionality and support the scalability requirements of customer bases that often run into the tens of millions of customers. This has not been helped by the industry’s track record of attempted projects that, until recently, more often than not ended in failure than success.

That said, I believe such cynicism is starting to disappear. Firstly, during the last decade, a number of banks in developing markets have moved onto packaged offerings that operate at such a high-scale in terms of customer numbers – such as Bank of China using TCS BaNCS to service 380 million accounts – that scalability ceases to be an issue. The technological approach has been proven. Secondly, such transformation is also starting to take place successfully in a number of major developed markets, such as in Australia – for example, CBA with SAP and NAB with Oracle – and in Germany, where SAP is working with Deutsche Bank. These examples prove that modern systems can support the complex functionality demands of mature retail banking markets.

The Implementation Path is Critical
While openness to universal vendor systems is broadening among tier 1 banks, a primary roadblock still remains. Vendor systems might credibly be able to support their bank requirements, but migrating existing systems to a new platform is a complex, risky, costly, and lengthy task. Migration management is a key demand. A ‘big-bang’ approach to switching systems over is often feasible for lower-tiered banks, where, in many cases they are replacing one or several systems with a new one. However, the complexity of the application ecosystem in top-tier banks means that they cannot simply switch systems over during a weekend. There are too many systems and too many customers.

The approach must be one of gradual migration, therefore, where elements of the old platform are replaced with the new system over time. This often means systems will run in parallel for years, with the new platform running as a secondary or slave system for much of this time. This does increase the cost and length of such projects. However, given the criticality of such systems to the bank, it provides a route to manage the significant operational risk and make such transformational projects feasible.

Vendors Must Accept Co-existence With Tier 1 Bank Systems
Vendors targeting top-tier banks must assume that their core banking platform will co-exist with the bank’s own systems for a number of years, rather than be the primary application upon installation. A managed, gradual migration is essential at large retail banks.

The challenge of this approach for vendors is that most offerings are developed on the basis that the platform is going to be the primary one. While most modern vendors have created modular application sets that allow retail banks to deploy different functional modules over time (e.g. lending, deposits, and customer information tools), such modules are largely constructed on the basis that banks will be using the vendor’s underlying platform infrastructure services and architecture. They are therefore designed to work across the vendor’s platform, rather than on a standalone basis across a diverse and non-vendor controlled external application ecosystem. While this can generally be worked around to create a transition path for mid-tier banks, it becomes much more problematic for tier 1 institutions.

A good example here is NAB in Australia, which originally planned to replace its system with Oracle’s Flexcube packaged offering. Although it is modular, the bank had struggled to create a viable transition path and Oracle and NAB have changed strategy, with Oracle recently announcing it has developed a new banking platform (Oracle Banking Platform) for top-tier banks. Rather than a single, integrated platform, it has a number of enterprise components that collectively provide an overall banking platform, but each are designed to co-exist and integrate with a bank’s current ecosystem to facilitate phased transformation.

Similarly, Infosys, with its Finacle core banking platform, has been developing this capability, providing a more packaged, ready-to-go offering (Finacle UBS) for lower-tier banks while also offering an component-based option (Finacle Enterprise) with enterprise components and modules that are more suitable for use as standalone services.

This is a necessary move, and these vendors are likely to pose a more serious threat to SAP’s position as the main option for tier 1 banks in developed markets (the SAP platform was designed to target this segment from inception so has had an in-built advantage up until now). Other vendors that wish to tap into this expanding market will need to make a similar move and there are signs this is beginning to happen.



Prometeia Credit Decision Management Platform - Egyptian Banks

Video | Banking Prometeia Credit Decision Management Platform - Egyptian Banks

Why Partner with NXTsoft?

Video | Banking Why Partner with NXTsoft?

Evolving APIs | NXTsoft Connectors For 40+ Banking Core Systems

Best Practice | Banking Evolving APIs | NXTsoft Connectors For 40+ Banking Core Systems

Banks have real opportunity in FX hedging for SMEs

Other | Banking Banks have real opportunity in FX hedging for SMEs