Just before Christmas 2022, TSB was fined a total of £48.65million by the FCA and PRA for failings related to its migration to its new parent’s, Sabadell, technology platform, Proteo, in 2018. The impact on customers was considered material and resulted in findings of breaches of a number of the Principles set out in the FCA Handbook. The fine would have been 30% higher but for TSB’s agreement to resolve the matter. TSB also reportedly incurred in the region of £32.7million in customer redress payments.

But rather than being an isolated or “freak” incident, there are a number of warnings in the FCA’s final notice relating to technology projects and outsourcing in the financial services sector that are worth attention. Clearly, hindsight makes the analysis of what TSB could have done significantly easier, but financial services organisations planning for and undertaking large scale technology projects and outsourcing ought to consider carefully the issues and plan appropriately for them, so as not to be exposed to the same regulatory censure.

Planning

Even though the migration programme was delayed, and was being re-planned, TSB committed itself publicly to a new go live date. The replanning exercise did not assess (and therefore did not take into account) why there were delays, and soon after replanning the programme fell behind again, and key overarching “Guiding Principles” were not followed. The governance in respect of the migration was not sufficiently exercised, especially, at a senior level, and there was not enough overall challenge relating to the plans.

Trying to meet a stated go live date and planning backwards from that date can result in the allocation of less time than is actually required to complete the relevant tasks, compromising quality and detail. Whilst project costs and a commitment to progress do need to be addressed, this should not be done at the expense of properly assessing what it actually takes to go live, and making sure there is appropriate time to achieve this. Allowing for some form of independent (outside of the programme team) “stress testing” might help to manage these risks. What is clear is that it is better to miss a go live date than not be able to deliver a service to customers or fail to meet regulatory responsibilities.

Testing

Because of the delays, testing which should have been sequential was run in parallel, and the scope of testing was reduced without appropriately skilled oversight and approval. Testing was concluded only the day before migration.

There is always a temptation to go live subject to a severity classification of test issues, which could be resolved in some hypercare period immediately following go live. This approach would need to be carefully considered especially in terms of the potential impact of the permissible test issues. The resolution path and manner of dealing with the apparent deficiencies whilst they were being resolved would need to be carefully set out and managed. Similarly, it is interesting that the FCA seems to consider that there was not enough time to consider and validate the readiness to go live, even after testing was complete; perhaps this lends itself to a “cooling down” period before the go / no go decision is taken, especially if this will allow for some careful consideration of overall readiness.

Outsourcing analysis and oversight

TSB engaged Sabadell’s subsidiary, SABIS, as the service provider to build and then migrate it to, and then run on an outsourced basis, the Proteo platform. For TSB, the Proteo platform was being specifically built and was new to the UK market. SABIS itself relied on 85 third parties (TSB’s fourth parties) to deliver the migration and the run of the platform. SABIS confirmed readiness to go live but with a number of caveats, especially relating to the third parties.

Third party and fourth party risk is a continuing and increasing focus for UK regulators. Most technology and outsourcing contracts will sufficiently deal with the allocation of risk as between the client and the service provider, especially with regards to responsibility for subcontractors (which many customers will consider from a delivery perspective to be “invisible”), but it will be increasingly important for the precontractual stage to assess and analyse the ability of these fourth parties, together with the structure and viability of the principal service provider’s oversight and control of the fourth parties. The contract itself ought to make sure the customer can sufficiently interrogate and directly engage with the fourth parties for the purposes of understanding capability and readiness, without transferring delivery risk (even in an indirect / inadvertent way) back to the customer.

Risk management

TSB did not assess risks associated with outsourcing to SABIS, especially as a service provider with no or very limited experience of managing such a large number of UK subcontractors. Similarly, TSB did not properly assess the risks associated with its own limited experience in managing and overseeing such a large-scale IT change management programme.

It will not be possible to eradicate entirely any risks associated with large scale technology and outsourcing programmes (this is why the contacts tend to run to hundreds of pages trying to address and allocate responsibility for dealing with them). However, operationally, it will be key for the programme governance to continually look for and address risks and challenges, rather than plough on regardless. The contract will need to facilitate this activity, as well as reporting and the provision of relevant information. Having the ability to address manifested risk should form an important part of the terms, via governance and other mechanisms such as the ability of the customer to halt activity and to have issues addressed, together with the associated consequences such as replanning and commercial impacts.

Business Continuity

Shortly after go-live, when customers were unable to access digital services and telephony services (as a result of the increased number of calls), TSB was not able to react appropriately to the crisis situation, and its planning for this event was found to be insufficient. TSB had previously identified issues with the incident management processes but these were not addressed, having been considered low impact. TSB’s assessment of SABIS’ incident management capability and readiness was found wanting.

Many contractual migration plans end at or shortly after go live, with a completion of a hypercare period or satisfactory performance against service levels for a period of time. It would be sensible for the plan to have a reverse side to it to allow for a roll-back, or a plan predicated on a series of scenarios, including where there are immediate service delivery issues. Contractually it will be important to deal with the issues associated with these alternative approaches, including the customer’s (unilateral) ability to invoke it, the impact on charges and payment (especially if charges become payable on go live), the requirement to provide additional remedial resource and assessment of new readiness to go live, after resolution of the relevant issues.

To discuss any issues arising out of this paper, please contact the author at Duncan.Pithouse@dlapiper.com, or your usual DLA Piper contact.