This article discusses some of the risks and opportunities facing the retail banking sector looking to transform their legacy technology platforms, based on Bird & Bird’s in-depth experience advising banks on transformational projects. It also sets out a recommended approach to help to overcome some of the legal and operational bottlenecks banks may encounter when undertaking such projects.

In recent months problems with banks’ IT systems have been exposed as Lloyds and RBS customers have experienced difficulties ranging from being unable to withdraw cash from ATMs to the failure of their debit cards. Part of the problem originates from a chronic under investment in IT that has left banks with legacy systems that cannot cope with new demands. 

There is a growing acceptance that there is a technological revolution coming in the financial services sector and unless banks adapt their legacy IT infrastructure to meet this change they risk becoming obsolete.

Many banks have IT systems predicated on an out of date branch-based and batch-orientated business model. The assumption (perfectly legitimate in the 1960s or early 1970s when the systems were developed) was that customers accessed their account via a branch and banks closed in the afternoon and had until the next day to update systems and so data was processed overnight in batches. How things have changed!

New digital entrants are emerging

Against this backdrop, the spread of digital technologies is changing the way customers interact with their banks. They are used to the customer-focused platforms of online retailers such as Amazon and Apple and expect a similar service in the banking space. Following the banking crisis and the wave of disaffection with the incumbents, new digital entrants have emerged looking to disrupt the status quo through leveraging new technologies to provide a service that is more aligned with this mind-set; offering online, customer-focused, 24 hour systems. For example, Atom Bank, the UK's first "digital bank" is expected to launch in mid-2015 and Wells Fargo plans to pilot a new system that enables its customers to sign into their banking application by using voice and facial recognition systems on their mobiles. There is a growing acceptance that there is a technological revolution coming in the financial services sector (in the same way that it has already occurred in the music, insurance and publishing industries) and unless banks adapt their legacy IT infrastructure to meet this change they risk becoming obsolete.

Transformation projects

IT transformation projects come in a variety of shapes and sizes as each bank's issues will be different.  For example:

  • big bang approach: the aim is to replace the relevant legacy technology with a new system. This is expensive and risky given the scope of such projects and in our experience can take a minimum of 5-6 years to complete. But, the results can be far-reaching. Nationwide, following the implementation of their real-time SAP banking platform, stated that they believed the platform had equipped them to become the number one financial services provider for customer service;
  • build and migrate: the bank will set upa new branded line of business using the latest technologies.  Once the line of business is up and running and profitable it acquires the books of business (e.g. mortgages, current accounts) from the host bank and the old banking system underpinning the host bank is wound down by natural attrition as accounts expire and customers are encouraged to move to the new brand; and
  • hybrid: another option is to retain the legacy back end and build new front end channels that leverage new technologies (e.g. Barclay's PingIt mobile payment service) to meet customer demand and communicate with the legacy core banking systems via interfaces. This will provide the benefits of new technologies whilst saving costs and complexity as the core banking backbone remains. Over time, as business processes are streamlined and new technology developed to augment the front end customer-facing systems, the bank will look to transform its core banking system. 

Whatever the option, there will be risks and our recommended approach section below can help reduce them.

The core drivers for IT transformation projects

Many banks appear to be complacent as to the threat of new digital entrants. They have seen this all before and survived; whether it was the threat of the internet banks such as Egg or the emergence of the building societies. So what has changed?

Dramatic changes are happening in the financial services sector driven by new technologies, regulation and consumer behaviour and this is highlighting the unsuitability of banks' legacy IT systems. This has been exacerbated by the loss of the ownership of the customer as new regulations in the UK have made it easier for customers to switch current accounts. Banks will need to refresh their systems to adapt to an increasing customer—focused industry or risk losing business and becoming redundant.

A bit more detail on the key reasons driving IT transformation projects:

  • new technologies: as much as 10% of a bank's revenue can be spent on maintaining a bank's IT systems and that is driven largely by the complexity of the legacy infrastructure.  Banks can save money by replacing the multiple technologies and interfaces they have built up over the years with a coherent, singular banking framework for technology. Technological investment can also increase profitability for affected banks through capital investments in cheaper software that automates business processes to replace more expensive labour;
  • regulation: increased regulation and political and economic uncertainty have led to lower returns and an increase in overall costs as legacy technology struggled to cope with new regulatory requirements;
  • consumer behaviour: banks' customers are evolving with the technological landscape and are demanding mobility, transparency and greater access through a variety of alternative distribution channels (e.g. mobiles and tablets). Banks are having to respond with a shift towards customer-centric IT architecture to meet these demands; and
  • competition: technology start-ups, retail companies and telecommunications providers have all entered the financial services sector and are challenging the traditional players. Banks are investing in technology to offer products and services that seek to differentiate themselves from these new entrants, or at least keep pace with them.

Contracting options

There are two main contract structures that can be adopted for an IT transformation project:

  • single services agreement: one supplier contracts with the bank and takes responsibility for the end to end delivery of the project; or
  • multi-vendor framework: multiple suppliers working together under separate contracts to deliver the project.

Single services agreement

This structure reduces operational and legal risk for the bank as it employs a "one throat to choke" model. The contracting supplier will provide some of the services directly to the bank via the prime contract and then subcontract other elements to specialist third party service providers, but will remain liable for the end to end delivery (including the performance of its subcontractors). In the event of a default, the bank has the benefit of only having to seek redress from the contracting supplier.

The risk for the supplier is that it is liable for the successful delivery of the entire project. This enhanced risk may translate into higher costs which may deter some banks. However, the size of the liability exposure for the supplier may mean it is still reluctant to take on responsibility notwithstanding the financial upside.

A practical example: the supplier's liability under the prime contract with the bank may be significant (e.g. a percentage of the fees paid or payable for the entire project, such as £100m), but it is rare for it to be able to replicate the liability structure agreed in the prime contract in its subcontracts (in particular the level of the liability cap which may be a smaller figure, such as £1m). The risk to the supplier is that the subcontractor defaults on its obligations under the subcontract causing a breach of the prime contract by the supplier. The bank would recover its losses from the supplier under the prime contract up to the £100m cap, but the supplier would only be able to recover up to £1m of the damages paid to the bank from the subcontractor under the subcontract.

Multi-vendor framework

This may be deployed where the bank has been recommended a number of IT solutions from various suppliers who will then, for example, implement each IT application and then the bank may use a system integrator to ensure all the different applications can communicate with each other.

The risk to the bank in a multi-vendor framework derives from there being multiple suppliers implementing each IT application together with a systems integrator trying to integrate these applications. Each supplier will have a separate contract with the bank.

In such a multi-vendor environment, a default may occur but it may not be solely caused by one supplier: it may be a breach that is caused by a number of suppliers (e.g. supplier X failed to provide a deliverable to supplier Y who then defaulted in its contract with the customer). This can lead to unhelpful finger pointing between suppliers as neither party wants to admit responsibility. This can lead to delays and an inability of the bank to easily identify responsibility for defaults and seek redress (when compared to the single services agreement model).

A way forward

Set out below are a few of the legal and operational bottlenecks that can be encountered and some of the solutions available to overcome them. 

Ensure there is business buy-in

Projects often fail when there are uncoordinated IT decisions being made by individual business units which contribute to a fragmented implementation. Time spent planning is never wasted!  The project team and executive sponsor must be carefully selected and clearly communicate the purpose of the project to all the bank's relevant business units and stakeholders, including CIOs, so that they are aligned with its goals and provide support where required to drive the IT transformation forward. 

Do your due diligence and stay flexible

The bank needs to understand the old ecosystem and how it will interoperate with the new system and identify whether the old ecosystem is satisfactory or whether it should be replaced. This requires careful due diligence of the current environment. If the old ecosystem is not fit for purpose then outsourcing the project will not improve the situation, it will merely result in the customer outsourcing its problems to another party. The software architecture chosen must also have sufficient flexibility to adapt to changes in scope post contract signature – many IT projects fail because the specification agreed at the start was too rigid and could not evolve with changing requirements.

Find the right supplier

The success of the project will be dependent on the quality of the supplier. An IT transformation project is complex and will pose multiple challenges for the supplier who will need to understand the bank's business requirements and culture and provide an effective solution to implement. 

Make sure your contract protects you

The contract must be drafted to maintain legal and operational accountability whether the bank adopts the single services agreement or multi-vendor framework approach.

Given the cost implications and risk appetite of suppliers, in most circumstances the structure will involve a variation on the multi-vendor approach. However, there is the risk of loss of legal and operational control due to finger pointing between the suppliers.

One way to mitigate this risk is for the bank and all relevant stakeholders to enter into a collaboration agreement that is separate to the IT agreements. The collaboration agreement will describe the suppliers' obligations therefore providing the bank with contractually enforceable rights against them in the event of default.  Such an agreement should cater for:

  • inclusive governance regime: the suppliers should be required to notify each other of issues or defaults.  In the event of a default, the suppliers must meet to determine who is at fault, creating a forum for all interested parties. If this cannot be agreed the dispute should be escalated through an agreed procedure and immediately notified to the bank, thereby accelerating the resolution of issues; and
  • collaboration: an obligation on the parties to work together, share reports and provide assistance with other suppliers that interface with the services. 

Key points for inclusion in your contract

Below is a (non-exhaustive!) list of some of the issues to consider during the negotiation of the contract which will make the transformation process much easier to manage:

  • data migration: transformation projects will involve the migration of data held in multiple legacy systems. Without careful planning and understanding of the data structures in the existing system, the migration plan can be executed incorrectly and this can lead to bottlenecks in the timetable and additional costs.
  • governance: major projects involve multiple stakeholders with differing interests and methodologies.  The project will need to be backed by a senior member of management and an experienced project team that can drive the process forward and have access to the executive committees in the event of key issues arising.
  • incentivise performance: termination for underperformance is a nuclear option given the costs associated with re-procurement (even if such costs can be recovered under the terms of the agreement). It is important to include ‘teeth’ in the contract to incentivise performance. This can include service credits for failure to meet agreed levels of performance or the payment of liquidated damages for missed milestones.
  • group companies: where the project is a global implementation that will benefit banks' affiliates it should be made clear that they can take the benefit of the services. This can be done by making the affiliates contracting entities, requesting that the bank signs the agreement as agent on their behalf or by stating that the affiliates have rights as third parties to receive the benefit of the services and potentially exercise rights under the agreement.
  • continuity of service: if the service fails then this will potentially lead to lost profits, reputational damage and potential claims from third parties (e.g. fines from the regulator or the bank's customers).  The bank should consider building in protections to ensure continuity of service such as audit rights to monitor performance, business continuity and disaster recovery services, exit assistance, source code escrow and a parent company guarantee.

Too big to fail, too big to manage

Disruption within the retail banking sector brought on by changing customer demands means banks will need to invest in IT to improve the quality of their service and update their systems. There is no one size fits all solution to the problem: replacement of IT infrastructure and even the build and migrate model are highly complex and risky endeavours, but are important projects if the banking sector wants to remain relevant.

Overseas, innovation is taking place. Polish banks such as Bank BPH have introduced high-tech ATMs that identify their customers by scanning the vein patterns in their fingertips. In Spain, CaixaBank has announced a "wearable banking" application that permits its customers to follow the stock markets and convert currencies using Google Glass or their smartwatches.

No bank is too big to fail.  But, some banks have perhaps become too big to manage and this has led to a certain amount of inertia and lack of clarity on how best to undertake the necessary transformation journey.  Banks have also tended to view transformation too narrowly, focusing only on the front-end features and not thinking about how these changes will impact the back-end and internal processes. This has led to incomplete transformation projects where front-end systems are replaced but the back-end systems remain untouched and struggle to keep up.

Banks need joined up discussions to decide what changes are required at the front end to meet customer demands and how the back end will need to transform to deliver these changes.

As banks start to embrace cloud-based solutions, shared services models and even the concept of buying software as a utility then the trend could be towards sharing duplicative systems, or licensing platforms on a utility / SaaS basis. This would certainly help to keep costs down and speed up the process of transformation. Recently, Metro Bank opted to use the Temenos T24 core banking system – a cloud-based product that runs on Microsoft Windows Azure platform.

The worry is that rather than innovate now to adapt to the changing environment the banks will continue to put off the changes that are required. But they cannot afford to delay in today’s fast-moving digital market.  If the likes of Google or Apple or Alibaba decide to enter the UK banking market, the traditional banks may not be able adapt their systems fast enough, and customers will move with a few clicks of a mouse or taps on a smart-phone.