Welcome to the Public Accounts Committee on Monday 2 March 2026. I am pleased to say that today we are looking at a success story—the Bank of England’s Real-Time Gross Settlement System. This system is a critical part of the UK’s payment infrastructure, providing settlement services for sterling payments in the UK, worth about £790 billion a day. In 2016, the Bank announced its intention to modernise the RTGS system to respond to changes in the payments landscape, promote innovation and competition and enhance the system’s resilience and capability. In April ’25, the Bank successfully launched the new RTGS system, at a cost of £431 million, achieving its aim of implementing a new, modernised RTGS system. The Bank’s approach to renewal addressed many common problems that the NAO has identified in public sector digital programmes, so today we will be looking to identify the key success factors in working with commercial partners that enabled the Bank to deliver the RTGS Renewal Programme. We will also be examining the governance arrangements, accountability and culture that enabled the success of the Programme, and seeking assurance from the Bank that it is applying lessons learned from the Renewal Programme to its other transformation and modernisation programmes. We have, first, Sir David Ramsden. Sir David, would you like to introduce yourself for the record?

Thank you, Chair. I am Dave Ramsden, Deputy Governor for Markets, Banking, Payments and Resolution, and I had Governor-level responsibility for the RTGS Renewal Programme from September 2017, when I joined the Bank, through to the delivery in April 2025.

I see you are styled as Dave, so are you happy for us to call you Dave rather than David?

Yes.

Thank you. Victoria, would you like to introduce yourself?

Hello, I am Victoria Cleland, Chief Cashier and Senior Advisor to the Governors at the Bank. I was the business sponsor for the RTGS Renewal Programme from June 2018 until the end of last year, and that included running the Programme, but also the live teams responsible for the system.

Thank you. You had the decision of go or no go.

The ultimate one was for Nathan and me, yes.

Very good. Nathan, would you like to introduce yourself?

Thank you, Chair. My name is Nathan Monk. I am the Executive Director for Technology and the Chief Information Officer at the Bank of England.

You are all very welcome. Is this, for all three of you, your first time at the Committee?

indicated assent.

indicated assent.

Yes. I have been a public servant for 40 years, but this is my first time at the PAC.

A special welcome to all of you. I hope you will find the process interesting, if not enjoyable. To start us off today, we are very pleased to have Catherine McKinnell.

Thank you all for being here today. I have to say that it is quite unusual for this Committee to be looking at a success story and trying to extrapolate why, although, as ever, there will be challenge as to how we can do this even better in the future, right across Government, where we know much digital renewal needs to happen. I want to go back to the beginning of your process. This is probably a question for you, Victoria, and is about the very early work that was undertaken to establish what would be needed within the Programme to contribute to its overall success. Obviously, I am happy for anyone to answer. What were the very early factors and steps taken that you think contributed to it being a success in the end?

The most important thing was deciding what exactly we wanted to achieve—what our vision was for the new system. We knew from the very start that resilience was going to be at the heart of what we were doing. This is a piece of critical national infrastructure. It is a payment system—there is a load of plumbing—but ultimately, it is a thing that enables money to move around the country. It is key to all your constituents, if they are trying to move house; ultimately, all payments go across it, so we knew that this was a piece of critical national infrastructure. If we were going to change it, we wanted to make sure that we got the best from what we were doing. We were focusing on resilience, but also thinking, “What more can we do?” From the very start, we were thinking about competition and innovation. Having that clarity from the very start in terms of, “These are the end objectives,” was key. We then split that down into five key areas around resilience, access, interoperability, end-to-end risk management and thinking about what the best we could do for users was. We had that from the start, and it was not just, “What is the Bank’s view of this?” because we went and spoke to industry. One of the key parts of the success was understanding what industry wanted, to create a blueprint, which was then the golden thread through everything else we did in requirements. It was about, “What is that endgame?” in terms of what we built and how we run it. Sometimes, it can be quite easy to think that the end goal is to build something. We constantly said that it is not just going live, but staying live, that is important, as well as thinking across the whole range of stakeholders. Having that blueprint was important, as well as making some big decisions early on to buy or to build and work out whether there were any particular red lines. We talked with key experts such as the National Cyber Security Centre to get advice on what we needed to consider with critical national infrastructure. We asked, “Who are our stakeholders?” and “What do we want to do?” alongside taking time to stop and make sure that we understood that vision, by talking to people running the current system who were likely to run the future one, so that we were feeding in their needs, and not just what we thought we wanted. To my mind, that was key. It was sometimes a little daunting saying, “We have been going for a few months and we are still working on those requirements,” but actually getting the requirements right at the start was key.

Coming into the Bank of England in September 2017, I had no background in tech projects; I had only delivered policy projects at the Treasury. It was very clear that, for me coming in as the deputy governor, I needed to have a team of people who knew what they were doing. We were talking earlier about Nathan and Victoria making the final decision. I could help support the governance, chair the relevant committees, drive the strategy and keep the other governors and the Court sighted. In 2014, as the excellent NAO Report sets out, we had a major outage of RTGS. That was before my time but, on that day, the Court commissioned an independent report from Deloitte to look into what had gone wrong. That was really what framed many of the requirements, particularly resilience, as Victoria just emphasised. In that outage, I think 700 mortgage payers were delayed a day in being able to take out their mortgages, so they could not complete. That was because the system we had before, although reliable, was very difficult to change. It could go in a straight line, but it could not adapt to the new requirements of a 21st century settlement system with payment systems interacting in it. As Victoria set out, we published the blueprint in May 2017, and one of my top five priorities in my time as a deputy governor was always to deliver on that blueprint. That reflected the challenges we had had. Going back to the earlier point, there are challenges, and the Bank had had challenges with previous things it had tried to do. We learned from those lessons. There were ups and downs along the way, but we got there in the end.

The overall message I am taking from your response is that there is an overarching clear vision, which seems to have come out very strongly. You have mentioned the things that you wanted to achieve: resilience, which you have mentioned a number of times, competition and innovation. Coming to the procurement process, what was it about the earlier stages of your procurement process that resulted in you getting the results you wanted out of it at the end of the process?

Maybe I could just say a couple of words, and then Victoria and Nathan, who led on the detail of the procurement, will come in. Figure 2 in the Report sets out a helpful timeline for the Programme and highlights how we first developed the procurement strategy during 2018. This was during the planning, analysis and design phase. Back to what Victoria was emphasising, and as I think the NAO’s Report recognises, we took our time through those early stages in working out how best to set ourselves up for success. We did not actually embark on the procurement of the key partner, the technology delivery partner, until February 2019. The procurement phase was such a foundational phase. We did not sign the contract until July 2020. We were trying to get the foundations, including on that procurement, in place. I guess the key elements were ensuring that we were an intelligent customer and that we knew what we wanted. One thing that helped us in that was that, very early on in my term as deputy governor, we took on running the high-value payments scheme for the UK—the CHAPS system—so we knew what we needed from, if you like, the high-value, low-quantity, low-turnover scheme as opposed to the retail scheme. So we were an intelligent customer. We had this competed design exercise approach, and then we worked carefully with all the potential partners through that phase to make sure that they were understanding our needs and we were understanding whether they had the capacity and capability to deliver what we needed in what became an absolutely vital partnership.

We did a lot of pre-engagement before we went out to market and a lot of briefing with potential suitors. That made sure that they were clear about what we wanted and vice versa as we kicked the process off. I think that was massively helpful. The competed design was a really good thing for us as well, because we knew the high-level blueprint, as it were, but we wanted to go out and get further clarity. We had some “mega minds” from industry that were competing, so we wanted to make sure that we used the best of everyone’s designs. Part of the process was that we made sure that we could procure the IP of that process as well, so that we ended up containing anything done in that process. Through the procurement, we were able to go through a competed design process and come out with a really good design at the end of it. We consulted with lots of other third parties as part of the process, which was quite helpful. We also did some proof of concepts—that was really good—so we got to see the engineering capabilities at first hand as well. Talking and seeing slides is one thing; another thing is actually seeing engineers, hands on, building code and so on. We also went through that as part of the process, and I think that was a really good thing to do.

I was going to ask a slightly technical question. Did you encounter any challenges in taking that approach when it comes to the regulation around procurement? Were there challenges in getting the right balance between open communication with anyone who may be competing for a project, so that you get the best out of that competition, and making sure that it complies with all the competition rules?

Obviously, making sure we are always compliant is in the back of our mind, so it is something that we took very seriously. It was something we really focused on quite a lot throughout the process. It was a consideration right the way through. We had a lot of support. We had a dedicated procurement team working with us, which was really helpful, to guide us through the process as correctly as possible. I think it is a combination of that balance and making sure we are doing the right thing—giving as much information but being as open and fair as we possibly can be throughout the process.

I would not say that the legislation, and making sure that we were sticking by all the rules, turned out to be a constraint. It is obviously incredibly important that, as a public body, we are following all those rules. To go back to being able to call on really good expert advice at every stage, we did have that advice, but even so, this was a big procurement. Victoria had done another very big procurement in her previous role. I guess it comes back to the point that, as the Report rightly highlights, we ended up taking a bit longer overall with the four replans. Also, the procurement phase ended up taking a bit longer than we had originally planned in the business case—it ended up taking a year and a half. Again, you are trading off, “Okay, we’re going to have to assess this as we go along and into the big stages of the Programme to come,” against, “But this is still investment and time that we can afford,” because although the existing system did not have great functionality, it did work, so we could keep the show on the road with the existing RTGS. To go back to what Victoria was saying about how we could provide a platform for future innovation, greater accessibility and greater competition, that was all going to take a bit longer, but it seemed to be a sensible trade-off to make.

It is interesting to hear about the procurement process, because it sounds like it was a very thorough process and that although, as you acknowledge, it took longer, the results obviously speak for themselves. As well as the need to comply with all the legal requirements, there are also the security and commercial challenges around procurement. How did you manage to get the balance right in driving what sounds like quite an innovative approach while maintaining all those protections?

We worked very closely with the National Cyber Security Centre from the start, to make sure that we pinned down some of the security angles. We set out some clear guidance to potential bidders on using List X facilities—if they were going to be part of this, they needed to be accredited. We tried to be open and up front with the bidders in terms of saying where security would bite. We spent time understanding how we were going to exchange information—certain information could only be read within the Bank. We had a dedicated team with some procurement experts, and we brought in somebody from another area of Government who led the procurement. We had a separate piece of governance for procurement, which was helpful, because procurement tends to have its own timelines, so it was helpful to have people who could focus on that. We also made sure to bring in our own teams to say, “If we are going to do this for security, is that going to make it impossible to run it?” We were always trying to think, “You can make a decision now, but what does that really mean for the operator?” We were constantly challenging ourselves in that way, and we deliberately went for a competitive dialogue approach so that we could have this discussion. A number of times we did say, “Gosh, do we need all this bureaucracy around the procurement?” But the view we came to was that it was a really helpful discipline for us to make sure that we were asking ourselves the right questions. If you had gone in too quickly, there was a danger that you would then have had a whole load of questions to ask after the event, and you had not priced them or anything.

Victoria, how important was the competed design process? You had three different people giving you advice on how this thing should work, and you even went as far as to pay the two unsuccessful bidders in that process. How did you choose them, and how important was it?

I will let Nathan come in, because the tech bit was certainly his world. We found it incredibly important to do that because we had an idea of what we wanted, and we knew the vision, but we wanted to get some real experts and say, “Can you turn this into reality?” They came up with some useful ideas that we then used for the end programme. That was helpful—it could see how the teams work. After a while, we decided that we would incentivise all of the three to complete the design. We knew it was going to be a big effort for them, so we did not want to put up such big barriers that not enough people were going to come forward. The three were chosen through the procurement process to start with. We initially opened up with who would like to be part of this procurement. Then we had the security checks and PQQ and then another competition. These were the ones who had gone through the normal procurement approach to get there. Those were the top three at that stage, and then we used the designs. Nathan, do you want to come in?

We had very stringent criteria that we put forward at the outset to make sure we were grading all the different suppliers’ responses. That is how we went from many to five to three to one. We took them through a very structured process and looked at all the different attributes: the kind of engagement that we have with the partner, the technical solution they are putting forward, the team capability and the proof of concepts that they put forward. We used all those different bits of criteria to evaluate and then make a final decision. We had some really credible companies that were putting forward really good technical solutions. That is why we wanted to have the IP and own the IP for the design, so we could use the best of breed—the best of all the designs—and come up with the ultimate design at the end of the process.

Was it that process that enabled you to eventually sign a fixed-price contract with Accenture?

Absolutely.

It is very unusual in a digital transformation programme to have a fixed-price contract.

We had nearly 2,000 requirements at the outset. We had done a lot of work. Going back to the earlier point, we did a lot of work up front to make sure we were clear about what we wanted, so we had 2,000 requirements—functional and non-functional requirements—that we had already documented, which was helpful to be our north star as we went through this process. That really helped us.

In terms of how the high-level governance worked and the recommendations that were made, there was an awful lot of bottom-up detail with the marking of the final three, and then we had the relevant governance committee. As I recall, we had all the detail we needed to just go with the recommendation. The other thing to mention is the incentives that a fixed-price contract gives. We do not have our partners, Accenture, here with us, but given what was happening in the settlements and payment space globally, there was a lot of opportunity for them in partnering with us as an intelligent customer. On their incentives and why they might be willing to go in for a fixed-term contract, I cannot speak for them. At this point we had a lot of help from Ron Kalifa, who had made his name in the private sector and was on the Bank’s Court, and was the non-exec chairing the governance committee we had at this time. There was a sense that we were working with a partner who would also benefit in terms of future business if they did a good job. We could see why they might want to be willing to do it at a fixed-term price rather than keep being able to add things on. We were acutely conscious of our VFM responsibilities and not wanting to have an endless list of things that we were going to have to come back and pay up for.

Presumably you retendered at the second stage before you gave the tender to Accenture.

It was not so much that we retendered. We had been through the ITP, the invitation to participate in dialogue, and then the invitation to continue. There was never a retendering because it was the best and final offer stage. It was a single stage in February 2020. That set out the parameters of the tender. When we did the replans, as we can come on to discuss, there was a bit of creative tension between us at times on who was going to pay for what when things did go outside the contract. But it was a single tender.

The competed design was just part of the procurement process. We had whittled down and got to three in the competed design, and then Accenture won.

So you had already whittled it down to three. There was no chance of any other people coming in.

No, we went from eight down to five, down to three, down to one.

Thank you. Those are very helpful answers. Clive Betts is next.

On the issue of collaborative working, which is key to what you are doing, did you set out saying, “We want to have a partner that can work with us on this basis” and look for one, and Accenture came through, or did you get Accenture as your partner and then decide that you could work closely with them on that basis?

Very briefly, the big foundational decision we had to make through 2018 was that we would build the core settlement engine ourselves rather than buy it in. That comes back to Victoria’s emphasis on cyber. We had looked at the kinds of products that we might be able to use and made a strategic decision that none of them would be appropriate. We have bought in solutions for some of the Bank’s other operations that are not critical national infrastructure, but we realised that we needed to build the core settlement engine and the ledger. Although the Bank has 5,500 staff at the moment and a very significant technology function that Nathan leads, we did not have, nor would we be able to grow, the in-house capability to do all the work to build this thing and then add to it all the other components that we could buy in, which were less critical. That was the framing for thinking right from the start. We had to have an effective partnership. On your question, Mr Betts, we did not think, “This is our vision. This is how we are going to do it. Let’s see if we can do it ourselves, and then we will partner.” We knew that it would be a partnership model from the outset.

We thought that partnership would be absolutely key. As Dave said, we were going to build some of the underlying infrastructure and we needed them to build some of it. Trust and understanding were incredibly important. We had started to think about the best way to join the teams together—town halls and things. Unfortunately, by the time we signed the contract, we were in the heart of lockdown, so some of the events that we planned to bring the teams together did not work. We managed to do a lot on Teams. We had a partnership charter to talk through things such as what culture we wanted, where we could have co-located working and involving Accenture in our governance. We wanted to understand how we could create things together. We wanted to have full visibility from both sides in terms of where things were and were not working so well so that we could use their brain power to solve them. You will probably hear us talk a lot this afternoon about transparency and no surprises, which were key to our internal governance, but absolutely key to the partnership with Accenture. One of the things that we did from the start was to say clearly, “This is one team. We are joining Accenture, Bank technology, Bank operators, Bank programme people, and we need to think of ourselves as one.” You cannot have a rift between all that. When we were thinking about awarding the tender, that was one of the things that came out in the various questions. We needed people we could work with.

My reflection would be on the collaborative way of working. Although it is a fixed-price contract, we were keen to move to a more agile way of working. Rather than just commissioning someone to go off and build something for us and then come back in a couple of years and show us, we wanted to see it build together, as Victoria said. One of the first things Victoria and I did was to co-locate the technology and business teams. The partner came with us. We were navigating the little challenge of the pandemic at the start, but that was a key part of the way in which we wanted to work together. We did a lot of up-front work about how we wanted to operate together and work together, which helped us quite a lot.

There are a few points to explore there. Essentially, you looked at it and said, “What can we do in-house? We can’t do that—we’ll bring our partner in to do it.”

Yes.

I was very cognisant when reading your hearing with the Treasury and NS&I of the issues they have been having and their challenges with the systems integrator. Integrating the system, although we had those different parts, was always central. We were not going to get someone else to do that. In a sense, Accenture were on the hook for helping us with the core things, like the core settlement engine and all that, but they also had to provide that integration and deliver on that. We, and they, had challenges with that later on in terms of the testing, which explains some of what we had to do with replans 3 and 4, but it almost reinforced the partnership that they were so central to giving us an integrated technology solution at the end.

We did a lot up front around that RACI model about who was accountable for what and in what areas. We wrote down, “We will be taking the leads on these things” and we expected the partner to be taking the lead on other things. That gave us a good bedrock to work on.

I suppose my follow-up is, while this obviously went very well and you obviously had occasional differences that you managed to resolve, if there had been any major disputes, how would you have resolved that? Would the system be robust enough to cope with something like that?

The system as we managed the Programme? I think it would because we did test it with the replans and these questions of who had agreed to do what and who should pay for what. Compared to some of the challenges that programmes face, ours were maybe relatively minor. But I can remember being in situations where it was felt that, because I do not have a commercial background, that I should not get involved in the negotiations with Accenture and that the Bank’s COO at that time would lead on it, with either Victoria or Nathan. Those were hard-headed discussions. One other thing I would say is that as we went through late 2023 and into 2024, when we had to do the final two replans and the testing of the overall system was showing that we were not ready, it was a really challenging time for the Programme. We had been going for a number of years, and staff had had ups and downs, thinking they were about to go and then things got delayed and then that happened again. What was interesting about that was that the culture that we had with Accenture helped, not to smooth over those difficulties, but to manage them. If you look at figure 7 that talks about the governance, the top governance from 2022 onwards was the Renewal Executive Board that I chaired. For the first part of that meeting, which would often be over an hour and sometimes we were meeting every fortnight, the senior Accenture executive would attend with her technical experts and would be very much part of the discussion and acknowledge that we might have been held up on something that then held them up. They were also owning when they had problems when they had problems with something. In the context of a successful programme, those were difficult meetings because we would be admitting what we had got wrong or what they had got wrong that was slowing things down, or admitting that there were too many defects that we did not have enough time in the Programme to test. The relationship was tested, but the strength of it meant that it never broke.

To add to that, in terms of the contract there were various penalties so if they were late on particular things or things were not to the quality, we could fall back to the contract if we needed to. There was also some formal governance. There were two different levels, an Executive Liaison Group and a liaison group beneath that, which were looking at the relationship and trying to catch things. If things had gone very wrong, we had protections built into the contract.

Did you enact any penalties?

We enacted that they would pay for additional things.

We did not need to use the penalties, per se, and some of those penalties could have gone the other way if we had been too slow in delivering our bit. We did have a number of negotiations with them around some of the change releases. For example when, under the replans we negotiated with Accenture, we tried to keep that away from the team who were working most closely with it. As Dave said, it was me and the COO who were going through that. We would ask what the cause was and look at sharing costs, but without having to go into the actual penalties.

A slightly unusual arrangement.

Yes, and while the NAO Report covers it in only a sentence or two—because it is an excellent, concise Report—it says that NAO colleagues interviewed Accenture executives, and they said that it was unusual to be invited into these executive meetings at the top level of governance. We were basically drawing on the trust that we had built up with them and the sense of joint accountability.

When you started out on your business case and critical path analysis, was the core settlement engine one of the major things? [Sir Dave Ramsden indicated assent] It is interesting that you built it to be one of the first bits, whereas NS&I still have not built it.

Well, NS&I’s programme, as I understand it, has four different elements. Obviously, they have 25 million customers. Ours was a pure tech programme and foundational tech, but was the last thing that went live within our programme. Originally, it was due to come in over summer 2023. Because of the various replans and so on, it did not end up going live until April 2025, but I think we finished most of the programming work in 2023 and then it took two years of testing.

You have mentioned the replans a few times, and I am keen to learn more about that. Could you explain to the Committee why there needed to be four replans?

Maybe I can start, and then colleagues will want to come in. There were four replans and they were quite different in nature. The NAO Report brings out the fact that the first one, which we carried out over the winter of 2021 and into 2022, was really significant. That was where we could step back and look at how the early stages of the Programme were going—we have talked quite a bit already about the procurement phase—and how the early build was going, and we look at not just our timelines for the Programme, but our governance and how we were organising the Programme. I think the NAO see that as the most strategic of the replans, because it really came from within. We realised that we were going to need more time, so we pushed back the introduction of going live on the core settlement engine to 2024 or maybe autumn 2023—I would have to look it up. Figure 8 is a very good replan table, which I should probably spend more time on. The first replan delayed the core settlement engine from September 2023 to spring 2024. The other thing we did at the time of that replan was to change the governance of the Programme that followed on from it. I have mentioned that we did have governance: we had something called the RTGS Renewal Committee, or the RRC—sorry, there are lots of initialisms—which was chaired by Ron Kalifa, because he knew this world and he was the key non-exec on our board, on Court. By the spring of 2022, we all felt that we needed to not only move out the timeline but change the governance as we went into the delivery phase. That was when we set up the RTGS Executive Board, which I chaired. The Bank’s COO was on it, because of all the dependencies with the Bank’s other systems and functions, and Victoria and Nathan were on it. We moved from non-exec-led governance to exec-led governance at that point. I totally understand why it was in the original plan and blueprint, but we descoped something called Transition Stage 4, which was a whole series of enhancements we were planning to make to the new core settlement engine. We decided to take that out of the Programme because it was a different set of capabilities. You needed to look ahead and predict what the industry was going to do, and what we might need to do to support it. It was things like extended operating hours and how we could ensure interoperability through synchronisation with other technologies—these things were in the original blueprint and in TS4, but we felt that they were of a different quality. We took those out at the time of the first replan, which sensibly focused and narrowed the scope, improved the governance and had a more realistic timeline.

Isn’t that the opposite of scope creep? You literally just took stuff out.

Yes, we did. We are doing it now, and we have budgeted for it, but yes, we took stuff out. It was a pretty ambitious blueprint, so we were comfortable doing it, and the industry were very comfortable with us doing it, because they were not sure when they were going to have the capabilities, and they saw that the change agenda, with the new messaging standard and everything else that we were demanding in TS2, in particular, was going to be challenging. The second replan was when we were hit by a shock. This comes back to the change agenda being so crowded across payments and settlements. When the ECB had to move their adoption of the ISO 20022 standard, industry said to us, “Look, there’s not enough time to keep to your original planning schedule,” and we did not feel that we could either, because other bits of the Bank’s systems had to move to that standard. That dependency really helped then. The third and fourth ones were really difficult for the Programme at the time, but they were much more tactical. The overall strategy was: “When we go live on this thing, it has to work.” They were strategic in that sense, but they were more about moving a few months in order that we could complete the testing, which was just throwing up too many defects that had to be either resolved or postponed. That was a really stressful period because of the turnover. I think the REB was meeting every week or fortnight during that time, asking whether we were on track. Those were the four replans. You might look at it ex post and ask whether we might not have needed one of them—you might argue which one, and we probably all have our own views on that—but although the NAO said that the overall delay was 18 or 19 months on a nine-year programme, so it was quite a bit longer than originally intended, with the overspends and stuff we felt that it was still value for money, and we were pleased that the NAO also concluded that.

Is there anything that either of you wants to add to any of that?

I think those are the key points, but I am happy to go into more detail. Doing a replan can be a brave decision, but as Dave said, front of mind was, “This is critical national infrastructure and we need to get it right.” That was absolutely key. The final replan was just looking at where we were: the main system was working fine, the contingency was not where we wanted it to be, and the monitoring system was almost too sensitive. I say to people that it is a bit like when your car sensors are helping you park and they pick up too many signals, and that was not going to work when you were looking at systems. Also, because we had been spending time on some of the other issues and defects, the operators just had not had enough time to use the system in absolute steady state. One of the things we were doing was giving surveys to the operators and asking, “How confident are you that you have had the training that you want? How confident are you that you can run this?” That just was not where we wanted it to be. It was a tough decision to make, because we would have dearly loved to have gone live that October, but there would have been a risk to it, and that extra time really helped. It gave the operators the confidence they needed, and we had the contingency we needed.

With those replans in mind, what was the biggest change to your approach or mindset that you had to make in order to get this programme delivered?

Some of it was thinking about the staff, because it was a long programme and it was intense, and we needed to keep people fresh enough to do what they were doing. There was some change in staff—as you go through a programme, you need different skills at different phases—but we needed our top people there throughout. How did we keep incentivising them to keep going, and so selling the vision? An absolute key part of it was the transparency, and people feeling confident that they could call out when things were not how they thought they should be. As I said, it is quite brave to replan, and with the first big replan, we did move quite significantly, but people could see, “Okay, we have flagged an issue, we have been listened to and we have got the support to do it.” I think people could see, “Okay, if we flag things, we can get results,” rather than being worried. I think that really helped going forward. Also, there was an emphasis on testing, and with industry, because, as Dave said, we were not the only player in the game. We were moving to ISO 20022, a global messaging standard; a lot of other central banks around the world were doing the same. We needed to find slots that were not taken by other central banks. London is a key financial capital, with lots of banks here. We needed to try to think, “What impact does this have on industry? How do we keep our staff going through this? How can we keep the transparency to make sure that we are ready to move and understand if we might need another replan?” Those are some of the things that come to mind.

Linked to what Victoria was saying, the team sentiment was really key. After the first replan, the whole process of listening to your operations and listening to your teams was really fundamental—so much so that in the later replans, team sentiment was one of the key criteria for us for go-live: “Are the team comfortable and are they happy?” Through the resets, one of the first things that we did was to get the teams together, understand what their concerns were and surface everything, as a reset moment.

Forgive me, but how big is the team we are talking about?

It was up to about 450 at the peak.

Yes, at its height, with Accenture and the Bank, it was up to 450.

There is a really useful table at the bottom of figure 10 on page 35 of the NAO Report. In 2023, we were still at 451 total staff, of which 144 were Bank staff, and then into 2024, we had to do the two replans in quite quick succession. On this point about the people, for me, that was most challenging through 2023 and 2024, because, as I said to you at the outset, I did not have any experience of this kind of programme and was learning how critical testing was, particularly on Nathan’s side—on the technology side—and how you just had to keep going until you got it right. But then the people issues really came to the fore in 2024, because we had already introduced the structure of the target operating model for what the new world was going to look like, and we had been recruiting people into that; meanwhile, the Programme was running and those new people, as Victoria was saying, were having to deal with the fact that things were not quite right. When you turn on your dashboard in the morning and it is flashing red, you are thinking, “Well, I’m going to be expected to run this thing in a few months. I don’t think they are going to be ready.” We had to manage. We are really strong on this “no surprises” culture, both with staff inside and, outside, with industry. When we got to deciding we would replan each time, we would say, “Well, how’s it going to go down with industry?”, because it was going to cost them as well. It was really interesting each time, because those were actually some of the easiest conversations. Because we had such a good relationship with them, they said, “Okay, no, we understand this.” The ECB one—the second replan—was straightforward because they were like, “Yeah, okay, you’ve been hit by a shock,” but then on the third and fourth ones, they said, “Well no, of course. If your infrastructure doesn’t work, I’m going to be held to account in my business”—in their commercial bank or whatever—“for it going wrong.” Their incentives were aligned with us on this “no surprises” culture.

That is really helpful.

Dave, you said something interesting in answer to one of Sarah’s questions. We have obviously looked at a lot of these big, complex projects, and governance is always key; it is usually the lack of governance that causes the problem. When you published your blueprint in 2017, did you envisage that, in the transition from the planning to the implementation stage, you would need to change the governance from non-exec to exec?

No, that was a kind of learning by doing and drawing on the experience—

What was it that you learned that caused you to want to change the governance?

I don’t want to put words into the mouths of my colleagues on the Bank of England board or Court, but I think they felt uncomfortable in late ’21 and early ’22. Court have to make any decisions involving the budget and have to be sighted on key strategic decisions, but they did not feel close enough to what was happening in the Programme. You can see Court mentioned in figure 7, which shows the governance. They are over on the right. I just do not think they felt close enough, the non-execs in particular—the chair of Court is a non-exec—and the other governors were not sighted. This was such a big, detailed programme that I think we probably could have worked it out for ourselves that we would have to make that non-exec to executive change, but the fact that we were doing replans enabled us to do that. It may well be that Victoria is about to say that, actually, it was always the plan to do it. I suspect it was, since Victoria had executive responsibility for other big programmes in the Bank. The other thing to say is that the Bank is quite—some would say we are a bit too good at governance. We have quite complicated governance already, so dropping this programme into it, it was clear that having a non-exec leading just was not going to work. I do not think the blueprint set it out in detail, but we made the right decision.

When the Programme moved from the blueprint and the vision to needing to put together the full business case and so on, we thought about the governance, and partly because there were going to be a number of big procurements, it was a significant-costing programme, as you will have seen, so Court needed sight of it. What we were doing did not necessarily fit into the overall timeline of Court, if we needed to fit into a particular procurement piece, but we needed a lot of time and we wanted their expertise. For the first couple of years of the Programme, having the RTGS Renewal Committee chaired by Ron and one of the other non-execs was really powerful, because they were bringing their input on things around commercials, procurement and the overall business case. By the time we were moving to the first replan, that had been done, and we were moving much more into delivery. It was just a change in focus; different things were being looked at, and that is where it became more important for the exec to be more involved and fully sighted. We still went to Court pretty much every meeting. If we did not go to Court for a meeting, there would be a written update, because this is a significant programme for the Bank. They wanted to follow the story and know what was happening. It was key for the Bank’s reputation and for the financial system. That was really helpful, because it meant we could update them. I used to say that it was a “warts and all” view, so when we approached the replans, they were not surprised. That meant we got some really healthy challenge from them, but that we felt comfortable saying, “Actually, we are going to need to replan.” It was the fact that the Programme got to a different stage, hence we needed to look at the governance. We looked at the governance of the Programme Board that I chaired. We changed the frequency after TS2.1, because we did not need as much, and we changed some of the people. Governance needs to evolve through different stages of programmes.

I happened to be looking at the minutes of Bank Court meetings, because I was looking for something else. Because of the way Court do their minutes while things are in flight, like our programme was, quite a bit of the discussions that we had was not published at the time, but last week we published quite a lot of the minutes from 2023, and they include quite a bit more about RTGS. As Victoria says, we were a standing item at Court, but often the minutes would just say, “The Programme was discussed”—obviously, at the time, there are all kinds of sensitivities—and then subsequently there is a bit more detail, and we are obviously giving you a lot more detail now. It was really helpful for us that we always felt supported by Court, because they believed that we got the culture right. One question they always asked us was: “Are you being open and honest with the challenges you are facing?” That was where we really felt held to account, because they did not want surprises; obviously, their reputation as the Bank’s governing body would be hit if we were doing things for the wrong reasons.

That is very helpful. Thank you very much.

It is a really good question. Creating that culture is something we have been really passionate about, especially with a partner coming in. There are multiple things that we have done over the time. There are little innocuous things, like if you are a third-party contractor and you come into the Bank, you have a different coloured lanyard. I know it sounds silly, but we made decisions to make sure that the identity of everybody on the Programme was the same, so everyone had the same lanyard and stuff like that. We were trying to create the sense that we all belonged together; we were all co-located in one area. When the pandemic happened, we moved to online meetings, and we are still quite successful in our ability to do that. We had just rolled out Microsoft Teams back then, so we were able to host quite big, significant calls online, which was great to be able to get contributions from absolutely everybody so that they could feel they were part of those big calls. The way we approached the work was to try to chunk it up into big deliverables every quarter. We would have big planning meetings, where we would all come together virtually, and when the pandemic was over, we would get together in meeting rooms to plan the next phase of the delivery. It is all about us picking up the work and having shared outcomes and shared visions for what we are trying to do, and trying to move those forward each time. The culture started from the very top. We had lots of very open conversations with the leadership in Accenture about the culture that we wanted. We had a manifesto that we created jointly, which is referenced in the documents that you have in front of you—a joint charter about how we want to proceed and operate together, about treating everyone with mutual respect and all that good stuff. There was a ton of stuff that we did around the edges to try to create a one-team ethos, all focused on these shared outcomes and visions, and using technology or co-location as the key enablers for that. Bear in mind that our partner had a significant footprint in List X, with a secure facility in Newcastle, so we had a divide. We spent a lot of time with the leadership team going up to Newcastle and then coming back down; we spent a lot of time travelling to and from Newcastle to make sure that the team felt integrated as much as possible. We embraced new technology to try to bring the teams together and then really embraced more agile ways of working. I talked about the ceremonies—the weekly meetings and stuff—that we had. We did a hell of a lot in the early days to try to build camaraderie and relationships and help people get to know one another. We were a big team at one point, but it did feel like we had created quite a family.

The one-team approach was absolutely key, partly with Accenture and technology, but also in bringing in the operators as well. Initially, there were a few comments that, “The Programme said this, but the business said that”. We felt that was not going to work. We moved to having joint town halls and bringing everyone together. There were joint newsletters and quizzes to try and have a bit of fun along the way. A lot of cake got eaten—there were bake-offs. We were just trying to bring a sense of “We’re all in this together”. We had a number of dress rehearsals that involved practising cutting the system over and back over weekends. People were literally working in shifts. They would sometimes have a theme for that and would share snacks. Nathan and I would go to all of those. I was not much use on a dress rehearsal, but it showed that the leaders cared about the teams and that we were prepared to put in some of our time as well. I think that was important. That idea of transparency was key. What I tend to say in meetings is that, to me, red means that we can go and ask for help. Red does not mean that you should be hiding it—that you should be scared. Bringing that up, and actually looking into things if people flagged them up, was key. We had something called the Transparency Channel for if people had concerns about the Programme but did not want to raise them with anyone in particular. That provided an anonymous way of flushing out any concerns. Celebrating successes was also key. It was a long programme, but there were a number of times along the way where we could say, “Yes, that was a good dress rehearsal”, or, “Yes, we have gone live with that.” We helped them to understand how everything fitted into the bigger picture and just kept reminding people why we are here.

It was because all that really good but quite obvious stuff happened. We were also good at linking it back to the core mission of the Bank. I did not get up to Newcastle as much as Nathan and Victoria and other colleagues did because there was a lot else going on. It was not just the pandemic; there were a lot of other shocks that I was dealing with in my wider responsibilities, such as Russia’s invasion of Ukraine and banks failing in early 2023. But when I did go up to Newcastle, I would re-emphasise that, although the Programme is all about real-time gross settlement, it is supporting all the payments that happen in the UK in the sterling system, as Victoria was saying in answer to the first question. RTGS is also how we operate the Bank’s balance sheet. When I am setting bank rate as an MPC member—one of the nine people who votes on bank rate—that is affected through RTGS. When we are deciding how big our balance sheet is and what operations we are going to use, all of those are operationalised through RTGS. That meant that we were able to break down any sense of “them and us” on the Programme. I imagine that some technology colleagues within the Bank might feel a bit detached from those kinds of core things that the Bank of England is known for doing. It was about trying to get us across. It probably sounds a bit woolly, but that sense of common purpose helped knit it all together. All those different elements did add up to conveying why it is critical national infrastructure and why it is central to the day-to-day running of the Bank of England. You never quite know why things work as they do, and it will probably work differently in different organisations. Compared to some civil service departments, I think the Bank probably has a reputation for being quite hierarchical. We tried to break that down a bit as well by, as Victoria said, having leaders who were willing to turn up for a Saturday afternoon dress rehearsal. We would do that—it was symbolic. It was even more symbolic in my case. Victoria would have actually been able to do something, but I was literally just saying, “Look, like you, I have had to give up my Saturday as well.” It seems like an obvious thing to do as a leader.

Yes, but also some big top-down messages about why RTGS is central to what the Bank does.

The shared vision—the shared outcome—was the key bit. That is about why we are there, what we are trying to do to bring the case for change and why we are doing it as a team together rather than separately. That was key, wasn’t it?

Yes, I think that was important, as was the co-location, so they could see things happening. We also enabled the technical specialists to see what the live operators were doing on a day-to-day basis, so that they could understand it and it was not such an alien bit. Very early on, we moved some of the operators on to the Programme itself, which meant that they could bring their skills. They were beginning to feed in at the very early stages, for example, by saying, “If you are creating a screen for us, it’s not going to work if you do that.” There was a bit of co-creation between business and tech. Initially, we did not quite get it right; they were seen as a bit too distant. Then we thought, “We’re building this for the operators. Let’s get them in earlier so they can help shape it a bit.”

The Bank of England has a lot of different things that it is responsible for and a lot of different operational systems. Again, it may be a bit easier for us than for some bodies, because we are quite big—certainly compared with the Treasury, where I used to work. We have 5,500 staff. All our systems are quite centralised. Today we are talking about RTGS settlements and a bit on CHAPS, the payment system, but all our market operations that run off the balance sheet—my markets directorate—are running things like quantitative tightening auctions and doing other things for our repo balance sheet. We have a whole programme of change there to bring those systems up to date, and we are learning that when we make technology changes with those systems, it is really important for the technology side to see the consequences for the Bank’s operations in those other areas. That is something Nathan and I have focused on. We have a big ongoing agenda, which the NAO brings out, to modernise our other systems, because we have quite a lot of obsolescence. We are seeing changes in all those systems happening now. We are seeing changes on the RTGS system. With the other changes, they are learning from what RTGS got right to make sure that if you are introducing a change—and nearly always, you have the testing right—the operation the next day, if it is a Monday, is not upset. But occasionally, we have had issues where we have not spotted something in testing. It is about having the culture where the business and technology sides are as close as we can get them in their understanding of why this is being done. As I say, I think that is easier for us, because we are quite centralised—it is all happening in Threadneedle Street, pretty much, though obviously not with our data centres and stuff like that. It is easier for us compared with, for example, a very big Government Department where you might have arm’s length bodies doing a lot of it. We have certainly benefited from it.

I will say something that echoes Victoria. The Bank has learned this. We did a technology project back in 2003 called Globus, and there were some problems when that went live. I think there was some reporting at the time that said that we needed to move to more of a “no surprises” culture, rather than a culture where it is assumed that things will be all right. It does require all the institution’s leadership to buy into it; if, as Victoria says, every time you see a red flag in a risk report you come down hard on the person who is revealing it, you challenge them, you do not ask them “What is the path from amber and then to green?”, and instead you say to them, “Well, how did that happen? What went wrong?”, your “no surprises” culture is going to fail at the outset. You have to have the leadership capacity and the culture to enable that to happen. We were fortunate that RTGS was just running every day. I will come back to that point. It was not a very flexible, functional, state-of-the-art system, but it was running while all this was happening, which helped us to set the right tone. Setting the tone from the top is absolutely central, particularly in a relatively hierarchical organisation like the Bank. The way to success involves people hearing someone like Victoria saying, “I can see that you have got a red now. I understand why you have got it. How are you going to get back to amber or green?”.

Thank you, Chris. I am sorry that I did not warn you at the beginning, but we have a habit of taking a break in the middle of sittings. We will take a five-minute break, which means we will be back at a quarter to five. Just a small word of warning: the microphones will be on, so just be careful what you say. Sitting suspended. On resuming—

We will start with Tristan.

I will ask some questions about the lessons for the Bank’s wider programmes. I will reflect on some of the lessons of this project and where we are going in future, in the light of some of the NAO Report. Broadly, paragraph 3.14 talks about “19 high-level lessons from the Programme that could be applied more widely to managing change projects in the Bank”. Have you risk-rated those 19 recommendations in terms of ones that are much more substantive for future change management? Can you elaborate on what some of those 19 recommendations were?

I will start, and then I am happy for others to join in. Although, on one level, you could say that the RTGS is very different—it is an enormous programme and critical national infrastructure—I think a lot of programmes have the same fundamentals. One of the lessons is around governance. Those programmes may not all want the same governance as us, but the fact that you should think very carefully about a programme, whether you need a bespoke governance framework and how you would flex it, is important. Some of the key things that we are doing are, for example, embedding people who have rolled off the Programme into other programmes in the Bank so that we can use that skillset. We have held a number of deep dives for some of the key programmes that are taking place in the Bank at the moment saying, “These are our lessons learned,” so we have been presenting those lessons learned to others in the Bank. The central Change and Planning function has been rolling out across virtually everyone that they should have a more formal lessons-learned approach to these. I think there might be a figure that has the 19, otherwise I will have to share that afterwards. Some of them are much simpler; some of them are big and around governance. There is a lot about culture and a lot about staff location. It is on page 39—I do not want to read out a whole load of icons to you. We are really trying to understand which are the ones that are most relevant to a particular programme; it will not be one-size-fits-all. What has been absolutely key is that we have had the lessons learned and we have shared that with Change and Planning and that is being rolled out across other programmes. I can delve into some more of those lessons learned if you want, or pick a few.

I have one or two points on some of those lessons, but I am happy to hear the wider overview first.

I would come back to what we were touching on before the break. In the markets and banking directorates—my responsibilities—we carry out a lot of the other functions of the central bank. Quite a few of those systems are either nearing obsolescence or are not as flexible as we want them to be, given what we are now asking them to do. We have been looking at investing and the priorities for which bits of obsolescence to deal with first. I stress that this is not just us. A lot of commercial banks across the financial system have obsolescent systems that they are having to update as technologies improve—we went for one technological solution—and we move away from these very clunky, mainframe-based approaches. We are already learning the key lessons in a couple of ways. One, as I was talking about before the break, is around testing—absolutely making sure that we are as rigorous as we can be. As RTGS is so critical and it is designated as CNI, for example with the first replan we were talking about before the break, we had to build an entire new infrastructure fabric, because we could not trust the testing to be done on the Bank’s enterprise estate. We had to create a separate testing environment. With most of our systems, that will not be possible, so we will have to prioritise how far we can take the testing. We will usually be able to do weeks or months of testing, but not the years that we did in the case of RTGS. It is about learning the criticality of the testing—that is obvious, but it matters for the business and the technologists who are producing the new code or systems, so that they can work together to understand, “That has almost worked. We can make that work with the workaround and that can be dealt with quickly.” That would be the first thing. The second thing is a lesson for us at the Bank. Nathan started off just on RT, and then he became CIO in 2023. He is now responsible for the whole of the Bank’s tech estate. He has had a strong ally in me on this. A big lesson is that we cannot keep pushing the investment to the right. There comes a point where you have to do the investment. We did that in RTGS, responding to the outage in 2014—a multi-year programme, taking that more strategic approach right across our estate. That is not just in my areas of central banking operations; it is true of what we are doing on finance modernisation and with our basic records handling system. We are upgrading these systems and prioritising investment to do that, and we are going into that in a more strategic way. Compared with when I started at the Bank eight years ago, that is a key lesson we have learned from RTGS: you have to be strategic about this and prioritise investment. Those would be a couple of high-level lessons. One more prosaic lesson, which Victoria was touching on, is that across my area, but also across the changes we are making to how we do monetary policy following the review that Professor Bernanke did for us, we are getting the experience exchange from people who have worked on RTGS. We have people running these other significant projects who have been associated with a successful project in RTGS and then have been exported. They have not left the Bank—that is good for the Bank and the public sector, as I am sure they could have done—but they moved on to other projects. Getting that transfer not so much of knowledge, because RT is quite specific, but of experience of what worked is probably one of the most valuable lessons for me. There are lots of others, but it was to try to hold on to those staff, within public sector pay and career planning, so that they can go on to, hopefully, greater things with other projects.

I want to focus on one or two elements that have come out of the Report and I would appreciate your answers to them. One of those things is referred to in paragraph 2.7 and is specifically about contingency risk. It was identified at the start of this project that the “final business case budget of £375 million included contingency of £40 million (11% of the budget) which was under the 15% to 25% industry standard”. Could you give me some commentary on why 11% was used? This was a very risky project. It was new, innovative and exciting, but it had not been pioneered elsewhere, so why opt for—in my reading—a lower contingency than the industry standard? Can I ask that question?

Yes. As I have said, our senior governance would be quite bottom up, whether it was governance on the procurement or on the overall business case, but then it would be challenging things. It would be taking account of the details, but then it would be challenging those kinds of things. I think the reason why we felt comfortable at the time with 11%, rather than something that was more the industry standard, was—remember that the final business plan was in 2020; we had done three years of work since the blueprint before that. We had done all that plan, analysis, design phase pretty much to get to that point, so by then we had a pretty good idea, including of all the technical requirements we were going to have. Nathan and the team had been working on this for the best part of two years by the time we got to that final business plan and the costing of it. So we knew, within the scope we had at the time—as I was saying earlier, in the replan we did narrow the scope and take some of the TS4 things out, which helped save us some money relative to that, which had to be spent on the rest of the replan. With hindsight, would I change that and go for a bigger number? Given the way we were thinking we were going to be approaching the procurement, given how confident we were in our technical requirements—I probably would have put it up a bit in order that it would have met an industry standard, but it did not feel to me as if it was hugely off at the time. Given how tightly the thing was specified and that we were reasonably confident, from the early stages of the procurement, that we would be able to do this, it did not feel unrealistic.

We did break down each item and give a range of costs that there could be, and then we took the middle of the range—to Dave’s point—so we did a lot of work on what the risks could be and what the range of those could be, and then obviously were taking a management decision on what we thought was appropriate at the time.

It was quite bottom up in looking at the likely risk to individual sections, rather than taking a set number. I think that at the time it said this would exclude big exogenous shocks as well. I think part of the driver was that, in the Bank, we would not typically go for big contingency numbers, because we need to be pushing hard on governance and value for money and sticking to them, but when we needed to move and could explain to Court what had happened, they did extend. But it’s a different way of doing it.

Thank you for that answer. I appreciate your candour on the contingency level in hindsight, because that is part of what we are trying to get to the detail on. My other question concerns resource risk. It was highlighted in the Report, in paragraphs 2.11 and 2.12, that this did have an impact on other Bank technology or change programmes. It was mentioned in the Report that you were utilising other skills within the Bank, which had to come into this programme. Can I get some detail on that? Obviously, if you are taking resource from one programme and moving it to another, that might have a material impact on other programmes, which are not mentioned here and which have a lower risk profile, I suspect. Can I get some detail? You have alluded to this, but was resourcing a strategic challenge, and how are we mitigating that for future projects?

I will start on this. Certainly through the first replan, Victoria had responsibility for one of these other very big programmes—I am thinking of the ISO programme for the Bank. It is kind of implicit in the NAO’s Report. All of our systems are important, but RTGS is the crown jewels in terms of how we think about it, so it did get priority. As you read in the Report and as we planned it, it typically would get its own dedicated teams on things like procurement. It would not be competing. The budgeting was done outside. As we just discussed, that’s not to say that the budgeting was unconstrained, but it was not in our BAU budget for running the Bank. Inevitably, there were dependencies that we were very conscious of and priority was given to RT. I will give you one example. The next biggest project that the Bank did over this period was itself moving to the ISO 20022 messaging standard, because that affected a lot of our other functional areas and operations. I can remember this happening a couple of times with the SRO for that project, who also worked for me. They came along and said, “RTGS’s needs mean I am having to give a project management function or something across.” So that is one dependency. On the second one, as RT got replanned, the rest of the Bank’s technology projects had to move in line, because there was not the staff or capacity. Although we had distinct staff on RT, there would be consequences, particularly when you were looking at the calendar of change and when you could drop these other go lives of these other projects. RT got priority and then the other things had to fit in. I would say that early on that created some challenges, and I think the NAO Report singled this out: on dependencies through the 2021-22 period when we were doing the first replan, we learnt more and more. We knew about the ISO dependency, but some of the other dependencies with the Bank’s other change agenda became more and more apparent. Then, as we got through the main hump of RT and staffing started to go down a bit in ’23 and ’24, and as the Bank was able to begin to breathe out a bit and think about what else it wanted to do, that dependency picture was also really clear. So when our RT stayed on track—you were always having to plan in case it did not—other things could come in and we could start to spend money and use resources elsewhere that we were getting freed up. We had this big plan as people rolled off the Programme. We really wanted to make use of them, as I was saying, with some key people: where might they be able to go and help with another of our bits of change? I would say that was an area where, as an organisation, because we had to stretch out RT, we also learnt by doing to sort out those dependencies. And we will not lose that learning—that is the key point. It was quite an experience to go through it with our biggest ever tech project. Now we have much more of a portfolio of projects where they are having to compete more with each other, rather than one being the priority. Probably the Court would say that Bernanke is the priority, but I would make the case for some of my projects. We are very conscious now. As an organisation we are managing that strategic plan around those dependencies. That is not to downplay that there are trade-offs and it is challenging.

My follow-up before I move on is that when you did have those resource challenges, was that flagged within your three lines of defence risk framework? Were audit, assurance and control aware of that?

I think the dependencies challenge came through more and more from the second line, because the first line was focused on the Programme. The Bank’s risk function became more and more focused. For example, in the Renewal Executive Board they would be flagging those sensitivities. The Bank’s audit function had a dedicated bit that was RT, but then the rest of the audit function was doing everything else. That was able to flag those respective concerns and in my regular meetings before every ARCo with the Bank’s chief auditor, he would tell me about RT and then would tell me about the risks to my other issues from the trade-offs and then the risks to the wider Bank. I think that was certainly part of the third line approach.

Internal audit and risk attended all of the Programme Board meetings that I chaired. They also attended the REB meetings; they were having full sight of that. For a period where the dependencies between RTGS and the other Bank programmes were at their height, there was a dedicated slot at the REB meetings to look at those dependencies—some of them in terms of actual people and some of them just in terms of how much tech change any organisation can absorb.

Lastly, looking for forward programmes, in paragraph 2.6 there is a sentence at the end, which I think is quite general, but, in relation to the timeline on this programme, it says, “The Renewal Programme delay is at the lower end of the range of delays we have observed in our work on government digital change programmes of between one and eight years”. That shows you that the project has been relatively successful, but going forward you obviously have an ambitious programme of future projects: extending the operating hours, a 24/7 market and resilient channels. Do we have the capacity within the organisation—having learnt the lessons now—to build on those future initiatives within appropriate timeframes, based on the commentary that we have had around previous delays and on-average delays in projects that have been delivered? I do not mean this one specifically, but in relation to that point.

What you just set out was three key elements in the RTGS future road map. When we descoped transition stage 4 and took it out of the Programme, we replaced it with the sense of, what is the future road map working with industry? We have resourced the RTGS BAU. The team that is running the new RTGS system has change as an integral part of what it is doing. For example, last week we put out our proposal on extended operating hours. We are going to open RT at 1.30 am every morning from September 2027. That is consistent with a previous consultation we did. We are absolutely resourced within the ongoing run of RT. There is then all the dependency that has with the Bank’s wider tech modernisation and systems modernisation agenda. Those two things can co-exist because RT has been resourced. We are telling the industry now we are going to 1.30 am opening; there will then have to be further discussions about how close to 24/7 operation we get. But all of that RT piece and the three elements you mentioned are distinct, but compatible with, the Bank’s wider modernisation agenda. That will have to be managed in the Bank’s overall footprint, but we are very aware of those dependencies ex ante, rather than learning about them as we go. Some of that is internalised due to the fact that I am the deputy governor for three of the biggest operational areas in markets, banking and payments. I cannot say, “I can internalise them to me”, but I am conscious of the trade-offs. We are in a good place to be as strategic as we can. Going back to finances, ultimately we fund these changes to RT through a levy. In the short term, we recoup most of the Bank’s running costs from different levies, but we are very conscious of VFM. We are subject to trade-offs on these things, but we know what is a priority.

On the build of RT so far, we have done the main technical piece. That has already built in the capacity and capability for some of these other things. We have already built in the capacity for more players and the capability to move to near 24/7. That piece is more about business change and industry change. We are running some experiments on synchronisation with industry. We have a synchro lab. One of the lessons we have taken away is to make sure you do stuff in absorbable chunks for both the Bank and industry. One of the key bits of extending the operating hours—opening at 1.30 am, and potentially going longer—is, as Dave said, the impact across the rest of the Bank. How quickly can the rest of the Bank move? That is how we have opened it up. We always remember that this is not just a tech change; this is a business transformation and an industry transformation.

A term we use all the time is “evergreening”. It was pleasing that the NAO picked up on it. It comes up in part three of the Report. RT was introduced in 1996. Mainframe language and all of that is not easy to change in response to a changing world. Our TOM—target operating model—for RT is based around the notion of evergreening. You invest as you go. As Victoria says, a lot of the foundational investment has been done with what we have produced with the new RT system, but the business change involved in doing that evergreening means that you have to work alongside your technology capacity all the time. We will need a bigger standing technology function to be able to evergreen RT, some of my systems or other bits of the Bank’s systems, rather than doing these big once-in-a-generation projects and bringing in lots of contractors. That means that the Bank’s balance and number of technologists will change over time.

I am going to move us along from where Tris was. Today’s Conveyancer publicised that, as you have just told us: “The Bank of England has confirmed it will extend the operating hours of the high value payments system CHAPS from its current core operating hours of 6am to 6pm, as efforts to operate settlement on a 24 hours a day…basis continue”. Can you explain to us the importance of being able to operate these systems 24 hours a day?

We are not at 24 hours a day yet, but—this is a key point—RTGS is a wholesale system. It is operating in settlement in wholesale financial markets. It is settling wholesale payments in the way it operates. The main retail payment systems dock into it; I think it is at figure 1 or 2 in the Report. RT is operating in that wholesale space, and wholesale markets are global. Being able to open as long as is practical will help with different time zones. Equally, some of the more modern systems—certainly some of the ones built on modern technologies—have distributed ledger technologies, so they can be confident, if they work in the security of settlement, that they can settle instantaneously, potentially at any time. We need to be interoperable with those, even though we have not built RT with that technological solution at its core. We need to think about the global markets perspective, as well as being fit for the future in terms of how settlement will work. That is why we knew that we needed to extend the hours from the blueprint. We do not want to build something that people will not be able to use. That would be my high-level view, but Victoria will probably give you a better answer.

With RT, we very much built it for industry, and it is there to meet industry demand. There will be an increasingly 24/7 world in the time RT is around—that is important for cross-border payments, and it could be important for retail payments—but RT is not something that the Bank can switch on 24/7. We need industry to be ready, so we have been working closely with industry, through a period of co-creation, to understand what hours would make sense to it. The move to 1.30 am, first of all, is to do with industry demand. It will give an opportunity to start settling at the time when, for example, the European Central Bank has started. They are not seeing as much demand for later opening at the moment. We are going to have a separate consultation very soon about moving further towards that near-24/7 world to understand what industry would do with it. Some of the players are keen and some are not at this stage. We do not want to open a system until industry is ready to use it, but it is key to build in the capacity and capability for the system to do so once industry is ready.

I have a few questions to test whether the RT system has obsolescence avoidance built into it, with future possible trends. Does the Programme have a clear pathway to synchronised settlement services?

On synchronisation, we are really talking about the ability to link RTGS, the core ledger that holds central bank money, to another asset. For example, we could run some tests with a real estate ledger to see if it is possible. That means that you can have a clean, clear transaction that happens quickly. In the last month, we have awarded 18 different participants a role in our synchronisation lab. They will be testing how the technology works and whether they can link into the lab properly, and also trying to understand a bit more about the use case. Again, it comes back to industry demand. With real estate, there is a potential use case. There are players in that—some in the FX world. At the moment, we are working with industry to see whether our solution is right and whether it will use it. The hope is that we will move to near-live next year, with some tweaks depending on what industry want.

On Victoria’s point, the fact that we have had 18 going into the lab successfully—we even ruled some out—gives me more confidence. There is always a slight worry that you will build something and then a few years later it will be obsolescent. Given the way technological solutions are moving so quickly, particularly in the wholesale space, there is real potential to reduce some of the inefficiencies in settlement. We took a strategic choice not to go down the distributed ledger technology route, but we want to be interoperable with that. I feel more confident in answering yes to your question now that I have 18 people who want to experiment in our synchronisation lab than if, say, I had only three or four. It suggests that there is a lot of enthusiasm for using that kind of route to dock back into RTGS to access the Bank’s balance sheet and central bank money.

Does the system support atomic settlement, where both legs of the transaction are completed either simultaneously or not at all? In my property world, that would be a purchaser and a seller. Does it support that, because it could move us on to where you may go eventually, into digital currencies? Can you say a bit about that?

We sometimes use the words “atomic settlement” and “synchronisation” almost interchangeably. What we will be testing in the synchro lab is the atomic settlement of linking the two ledgers, and the payment will settle if and only if they are both ready. That is what we are experimenting on with industry at the moment. You mentioned the question whether a central bank could issue digital currencies. There is a separate piece of work looking at the digital pound, and the Bank is working closely with the Treasury to understand what the demand is for that. That would not take place in RT itself. It would be quite a different way of operating—much more high-volume and consumer-facing—but we are clear that it could interoperate with RTGS. That was one of the drivers for some of the earlier work we did when moving to ISO 20022, which is the new messaging language. It is essentially enabling different systems to all take the same language. That interoperability is something that we think should help with reducing any obsolescence and connecting to domestic and international systems. Chair: Victoria, you must have been reading my script, because that leads on to my next question.

My eyesight is not that good!

Do you have a published operating model for interoperability, including governance of access, messaging standards and contingency?

ISO 20022 is a global messaging standard—sorry, it gets quite geeky—that essentially does two things. First, it says, “If you want to write an address, it should be in this order.” That is about getting the language right. Secondly, it gives the ability to add enhanced information. You can put a lot more data in there, which is very helpful for firms in understanding a bit more about their customers. Some of it we take as a global standard, and some of the teams in the Bank are on international committees that are refining that. We have also done some work in the UK on what we call a common credit message, which is looking at housing payments, for example, and saying, “If you are going to have a housing transaction, these are the key fields that you need to fill in.” That includes how you can use the enhanced data a bit more. We have also set some parameters that mean that if there is a priority payment, we can pick it out. If there were a problem with RTGS or with one of the participants using this ISO data, they now know how to flag which are the priority ones. If there is only the capability to process 10, we can pull them out. Some stuff we are doing in the UK, and we are also working internationally to spread the word as more systems adopt ISO 20022.

I must be totally transparent: when I said “in my world”, I meant that I am a chartered surveyor. I declare that as an interest. What do you see as the biggest future benefits of the Programmes for those using RTGS? Where are the future developments? How long will the Programme remain in process? Will it be able to transfer into these new technologies, or will there come a time when it is obsolescent and you have to go on to a new programme?

The way it has been built means that it has a much more flexible and modular architecture; Nathan can come in on that point if he wants to. It enables us to change pieces much more easily and to build on to it. With some things, we have really been trying to think about how the world might change. As Dave said, although we decided not to build RTGS itself on distributed ledger technology, we ran some proofs of concept a number of years ago to make sure we could link into that. We are trying to keep it there. We built in capacity for a lot more players. One thing we were really keen to do is attract more players into RTGS as direct participants, with the benefits that they can get, such as bringing in more competition and innovation, which hopefully will lead to better results for the end consumers. We have been trying to think about those pieces. Synchronisation could be a real game changer, if that comes through and there is the demand for it. The extended hours help, particularly with cross-border payments. We are already seeing some things we can do with it. There is much greater use of APIs; we have introduced APIs for the first time and we have seen some strong take-up from industry, which we want to increase. We are always looking to refine it. For example, there is what we call a liquidity saving mechanism, which essentially sets out how much of a float an institution needs to put in at the start of the day to ensure that it can pay what it needs to pay. We are speeding up those algorithms to make the use of capital much more efficient. There are changes that we are bringing along, but we need to keep evergreening it. We have the teams to do that and we have the governance, but we do not have perfect vision. Nathan, do you want to say a bit more about the modular approach?

Part of the design is that, whereas before it was basically a big behemoth box, we now have lots of different modules that we can swap out. You can think of it as a platform that will constantly evolve and adapt. We have some big things like synchronisation, which has big industry engagement and is therefore like a big project. We also have the day-to-day operations—what I call the feeding and watering that we need to do to make sure that it stays supported and we stay on top of it. We have a team sized and scaled to do the constant feeding and watering, and then we have the team who do the more strategic and functional changes. It will evolve over time. We have learned so much from operating it for over a year now. We are constantly doing monitoring changes, operational changes and so on. It is a live platform, and we have made well over 1,000 changes to it since it has been live. We could never have done that with the old system: just testing the old system used to take three months. We used to do something called regression testing, but we have now automated the testing and can do it overnight. It makes it a very different platform to maintain and manage. It is complex—don’t get me wrong—but we have lots of new controls in place. The way to think about it is as a constantly evolving platform.

The day after we went live last April, I took the risk of giving a speech, noting that we had gone live and looking ahead to the notion that what we have provided is a platform for innovation, but also that we can help to steer and drive that innovation. We have talked quite a bit about synchronisation and how encouraging it is. When you look at wholesale markets globally, although the paper has been digitalised, the process of settlement is not digitalised. There are real gains that you can make in the efficiency and speed of wholesale markets. It also goes back to your chartered surveyor role, Chair. This is why some of our proofs of concept have been around a housing transaction—there are so many legs. We are just trying to make sure that we have that platform that will really support innovation across the UK economy. The UK is a global player here. On the cross-border agenda and more generally, we have the Governor, Andrew Bailey, as chair of the Financial Stability Board, which has been driving a lot of this with the G20. The G20 might have some political challenges at times, but we have real experts who want to see improvements to wholesale payments. In the UK, thinking more parochially, a key wholesale asset is UK gilts. They are the risk-free asset of duration; we have reserves. We are very keen to support the whole agenda with DIGIT—the digital gilt instrument pilot—as part of digitalising the UK wholesale market. They recently made some announcements about the procurement, which we were talking about earlier. I am sure that in time the NAO will be interested in that project. It is in its infancy at the moment, but it has huge potential, given the core role of gilts as the risk-free asset, for the digitalisation of UK wholesale markets. Whether it is through RTGS or through our other systems and how they interact with gilts, we want to be part of the way forward.

Golly. We went to the Debt Management Office and saw one of its auctions. I can begin to see where this is all going.

Exactly.

Rupert will ask the final questions, but let me first say that in 12 years on this Committee, I do not think that I have ever been involved in a hearing on a digital transformation programme that has been so successful. Clearly, there are lots of lessons, as we have tried to bring out this afternoon. What can we all do together to help Government produce some of these big, transformational programmes? We know of some very big ones at the moment—you mentioned NS&I. How can we provide a blueprint so that people avoid the obvious mistakes?

Let me start on that; I am sure colleagues will have views. There are a lot of general lessons from this project—we have touched on all of them—that will have a read-across. Obviously, there are also some specifics that I have tried to emphasise. We are quite lucky in some ways in the Bank of England; given our size and focus, we have a lot of capacity. I am sure the NAO, given their experience, will be very good at bringing out those general lessons while also recognising the differences. We were very proud of the achievement of going live and of it going well. We were thrilled to get a positive report card from the NAO. Of course, when the NAO writes a Report that says, “Public sector digital change programme goes well,” it does not tend to get the headlines that many of its Reports do. We put out a low-key press statement, but there is a lot more to do—hopefully this hearing can help with that—and the follow-up can help in terms of dissemination. Reflecting on this as a former civil servant, if I were still one, I would expect to be invited to explain something that has worked to “Wednesday morning colleagues”—if it is still called that—where all the perm secs get together, because I am sure they have to talk about things that have not worked. We are not as plugged into that world as a Government Department would be. I know that colleagues are taking part in a big NAO event in April—I think Victoria and Nathan are taking part. If I can, I will go along, if that would be useful. We have to look for every opportunity; I should stress we are already doing so. Thanks to the NAO—but I think they would have been in touch anyway—NS&I have been engaging very closely with Nathan and Victoria on what they can learn, because they are the ones in flight at the moment. We obviously have other things to do, but within reason, we want to help the NAO. The Report—I was saying this to Simon and Yvonne in the break—is fantastic for many reasons, not just because it is nice about us, but because it does a great job of synthesising what we did. I was always keen to get some of the figures and tables as we were going along, but we never quite got there, so to have the NAO bring it all together—hopefully still “warts and all”—is incredibly helpful. Others can then see whether that works for them, or does not quite work. I think the NAO is probably best placed, with you, to come up with a blueprint.

Gareth, that is high praise indeed from the Bank of England.

I just wanted to mention, if Dave had not, the event we have lined up for April, where we have invited civil servants to understand more about the lessons here. It is also the only Report in my time that I have written to every permanent secretary about, with a copy of the Report, to draw it to their attention. I have had replies back as well saying they are going to use it within their teams. We are going to make sure those lessons are disseminated fully.

Well done. Last, but by no means least, Rupert Lowe.

Thank you, Chair; you have been very active today, but I think I still have a bit left to ask. I cannot tell you what a pleasure it was to hear the write-up you have been given by Yvonne and Simon in our briefing, and to hear that you all appear to be so well over your brief. I am tempted to say we should put you in a bag with most other public sector bodies, shake you up and hope a bit of you rubs off on them, having sat round this table and listened to very different stories of less success than you have achieved. You went live in April ’25. Have you had any hiccups or issues since then?

You start, Nathan, and then I will come in.

We have had a few small issues. We have still met all our SLAs so that, 99.9% of the time, the system has been up and running. Like any new platform or system, there have been some challenges, but they have been very small in nature. Settlement has continued throughout the majority of that time as well. We have learned a lot from the system going live. For every little event that we have, we do instant reviews on the back of them and we learn from them again. There have been a few interruptions, but nothing fundamental, and we have still hit the main, primary SLA that we need to.

The SLA is for a very high degree of availability. Victoria will probably be able to remind me, but it is something like 99.9%. There have been some incidents, but the good thing is that we have always been able to learn from those and establish the root cause. My vantage point on this is that I am chair of the RTGS/CHAPS board, which oversees the operation of RTGS and CHAPS. I mentioned earlier that we brought CHAPS in-house at the end of 2017, just after I started. At that point, we made—I have said that the Bank likes governance—the governance more senior, so I run a board with, I think, five non-execs on it, all of whom have a background in payments. The risk committee has to explain to them when things have gone wrong. They will get an incident report if there is an incident. I am on the hook day to day from chairing that. It so happens that Andrew, the Governor, has a real background in the operation; even if it is just a minor thing, he will always want to know about it. We have also had to deliver a lot of change over that period. Back to this evergreening, we had to introduce all these upgrades during that period. We also had to deal with a backlog of defects that we decided we could postpone until we had gone live. They were not critical, and they came out of the testing process that we talked about in the context of TS3 and TS4. I am very pleased to be responsible and to be on the hook for our payment operations, but it does mean that you are only as good as you have been that day.

So the implementation has been pretty successful, other than a few bits and pieces?

Yes.

I am interested in the support. In my experience of writing the kind of software that you need to do this, it is not just about implementation support. I see that there are still 125 people on the project: I think you have 32, Accenture has 84, PA Consulting has five and there are four contractors. Part of it is implementation, but are you confident that you have the actual structuring of the support right? In my experience, when you get involved in writing bespoke software, particularly with people like Accenture, if you are not careful, you end up running up a very big downstream bill. Have you got that covered off, as far as the taxpayer is concerned?

I think we have. Rightly, you would expect the NAO to point out that the running costs have gone up. A key part of the contract with Accenture was that it would pass everything back to us to run, so we are not contracting out. In fact, I think Friday was the last involvement of Accenture, so as part of our increased running costs, we have had all the knowledge transfer from Accenture back to our staff. That comes back to what I was saying to a comment from Mr Osborne about how we have had to change not just the RTGS target operating model, but the way the Bank is staffed. We have to have these technology experts. Usually the RTGS is silent running, and they are just dealing with the change, but when we have one of these incidents, they can get to what has happened and work out from the code why it happened so we can fix it. To go back to the innovation agenda that we have been talking about with the Chair, these are also the people who are going to be enhancing the system in the future.

So if you need to innovate, you have the skills in-house to do it.

Yes.

It is great that you are comfortable that you have that covered off, because otherwise, in my experience, people suffer huge downstream effects.

It has come at a cost. Our running costs have gone up from £21 million to £40 million, as is mentioned in the Report. That money is buying us a lot more in-house technological capacity for this critical aspect.

It has been a conscious decision. We embedded people in the Accenture team really early on and have grown that capability throughout the time as well.

That is great. I understand that you have discussed this with the users, because in your document you mention ultimately charging for this system. As you know, the banks often used to be accused—including by myself—of getting between the wall and the wallpaper, in that it took a long time to get your money to go from A to B, and very often it was the banks that were sitting on the money. If you are going to start charging users for this, is that going to be the banks or the people making the transfers? Are the banks less able to get between the wall and the wallpaper with your new system than they were before?

Victoria can give you chapter and verse on who pays the RTGS and CHAPS levy, but it is the same people paying it now as were paying it before. As the Report points out, we have changed the fee structure to allow for those who are very significant users relative to those who are not. However, everyone is having to pay for the renewal of the system on a 20-year payback. We thought that was reasonable, given how much of a leap forward this is. As we increase access to the system—which goes back to one of the five key priorities in the blueprint—we are going to have more and more interesting people using it and paying. We have our first omnibus account with Fnality, and more and more non-bank payment system providers. However, they will then pass the cost on to their end customers, so I am not sure how it works with your analogy.

I am a great believer in transparent charging.

The charging is transparent.

Then everybody knows what they are dealing with. People can then see the frictional costs of making a transfer. If we are trying to collectively help British industry, commerce and trade, we want a system that is transparent and that serves the end user and does not just enrich the banking system—which is arguably a parasite on the back of the productive animal.

The costs to RT get spread between the key users. For some of the CHAPS direct participants, we will charge the individual direct participants there. Another chunk is paid by the CREST securities settlement system and other chunks are paid by the retail systems and Visa—so different organisations pay different chunks. The CHAPS direct participants would then pass that cost on to their customers. However, as Dave said, we have been trying to bring in new players to the access regime. That began with the policy change. We are the first G7 central bank to enable non-bank payment service providers direct access to our RTGS. As part of the Renewal Programme, we have also been increasing the capacity for more players and looking to streamline the onboarding process. The idea is that that will enable more of the smaller players—the non-bank payment service providers—to come to us direct. That will take out one of those middle banks, so to speak, and get a bit more competition, which should ultimately enhance it for customers.

That sounds great. Can you commercialise this yourselves and turn it into something that you sell to other countries or people who might use it, and defray the cost further, or is it something you want to keep proprietary?

Going back to the original security considerations, there is no way we are going to directly commercialise the core settlement engine. That had to be built under the tightest conditions, and no one has access to that code—not even Accenture in Newcastle. However, even with central banks, I give quite a high priority to the security of RTGS and access to our balance sheet. What we are doing, though, through the work that we have been talking about—through the FSB, cross-border—is, where we can, to share lessons about how our technological solutions work with other countries, some of whom might be going down more of a wholesale digital currency route than we are. We are all working at different speeds in that sense, and we can share and then improve our accessibility, through hours and staff, to break down the barriers that way. I would argue that it was that way. More generally, we do not typically think of ourselves as commercialising what we provide as a central bank.

But you have Accenture bolted down from an intellectual property point of view?

Yes. Totally.

It is our IP; we own it.

You have that absolutely bolted down?

They can go around and say, “We’ve got a track record of delivery. Look what we did for the Bank of England”, but we have got them bolted down on IP.

I have two other questions, really just from my interest. First, was this in any way driven by the advent of central bank digital currencies? I ask that because I know that the Governor is quite keen on them, as was—certainly—Rishi Sunak. I am less keen on them. But was that any motivation for this development? You did say that the old systems were clunky but functional.

What you have got to distinguish between is money and the rails on which money operates. I would argue that at the Bank—including Andrew Bailey, the Governor—we want to make sure that we have the best technological solution that ensures the singleness of money. For me, that comes back to money created on our balance sheet—electronic money or notes. CBDC is one option—retail CBDC as a different type of money—but that is very distinct from the rails that money is operating on. That is where I would argue that everything we have talked about today—money and assets—is settled. We are still in the design phase with the Treasury. We have to make a decision—I think this year—on our retail CBDC. Equally, we are really pushing hard on stablecoin, which is where the US is going. Again, that comes back to making sure that, regarding the Bank’s balance sheet and operations, if a sterling stablecoin came along, as opposed to a digital pound, we could deal with that. Would that meet our standard of singleness of money, along with the commercial bank money or notes? That world has got more complicated even since we introduced the thinking on the digital pound. This is all very much in flux. We are just trying to make sure that we are providing both the infrastructure and the technological platform that innovation can take place on. Let’s see what form that takes. When you look at the ECB, they have gone much further on retail CBDC, with the digital euro. We are still at the design phase.

I have a final question, reading the document and thinking about this issue. Have you any thoughts about how the rapid development of AI is likely to affect what you are doing? It strikes me that the software industry is very much at risk from AI. Whereas AI was probably quite inaccurate a year ago, and is still vaguely inaccurate, in a year’s time it is probably going to be very accurate. How do you see that affecting your operation?

Given that Nathan is our CIO and has got to think about how AI might impact on the labour inputs, as it were, and how coding is done, I will try to reassure you, narrowly and then more generally. One thing that we get with RT is a much bigger capability to analyse data. We now have the capacity through the new system to ingest vast quantities of payments data and we can then look for patterns. You can easily imagine how—other central banks have done this—an AI application would look for an outlier payment that might tell you something: a problem with the payment, which could be because there was something dodgy about it, or that there was something interesting about it economically. We need to make more progress on using machine learning techniques analytically, now that we have them. That is one example of an analytical application. More generally across the Bank, as I am sure you are aware, like every institution we have to have an AI strategy; we are thinking about how it could impact on everything that we are doing.

Like Dave said, we have been really focused on the AI strategy, the policy, the ethics framework and all that kind of stuff, which is in place. We have a lot of experiments going on, I think it is fair to say. They break down into productivity-type areas and—to Dave’s point—use cases for more analytical purposes. On the actual platform that we built, we are already exploring how AI “ops” can help us by giving us insight into incidents and that type of stuff. I would say, “Watch this space”. It is something that we are working on. It gives us a big dataset to play with, basically. We have a lot that we could be doing and we are already exploring a lot at the moment. That is more enterprise-wide, as well as specifically for RT.

But we are thinking about how it could impact every part of our workforce, whether that is coders or people doing policy analysis. Could MPC members, in future, be replaced by agents?

Very definitely.

With the very last question, my able deputy Clive Betts.

This is an example for the rest of Government to follow. It has gone all round the permanent secretaries; they are looking now and saying, “Off we go; we’re going to follow it.” The problem is that it took nine years, and most of them will probably say, “Actually, politically, whether it’s welfare reform or NHS reform, we need it much more quickly than that.” Are there any lessons you can learn about how things might have been done more quickly with hindsight?

How we could have shortened the nine years?

And still got it right.

Maybe if we had spent less time at the outset thinking about the “fit for the future”, descoped that and really focused on everything else we might have saved a small amount of time. To be honest, I realise that the nine years is going to be very challenging with perm secs or with CEOs, but that is why I think that the Report is so good: you can break it all down into the constituent parts. One of the big problems that other schemes have had—I am not able to mention them, but your NAO team would—is not spending enough time on the planning, analysis and design stage. I am saying that if we had descoped in that stage we could have maybe saved a few months, but that is just my hunch—I might be wrong on that. Actually, that stage was money incredibly well spent and time well spent; we went into the procurement with a clear sight of what we wanted and what the technical requirements are. Those are lessons—or if not lessons we could go back to the Chair’s idea of producing a sort of blueprint or guide. I have some of the NAO Reports; you already have such guides. We can give an example of where it does apply to one of the NAO’s lessons. The NAO has lots of lessons where it has not worked; we can say that it did work. It did not work in every case with us—I want to stress that. To your point, Mr Betts, we are not Government. We are not constrained by the political cycle and we did have a system that was still operating.

Yes, that is really important.

Yes, it is. I look at NS&I. As NS&I told you, it has 25 million customers, including you and me, with my app. The app may not do very much, but it does the basics. We do not have any of that to worry about. The NS&I is keeping its service going and its net financing went up, so it is doing other things for the Government. You have to always bear in mind that context, but there are some real lessons from the different phases of what worked for us, which we have talked about today.

I know that it has been nine years in duration, but we delivered in phases. We delivered within the four or five years and we have had different releases on the back of that as well. The total is nine years, but we have been delivering benefit before that, if that makes sense.

So there are some reforms in some systems where you could gain some benefit if you go along.

Yes, incremental benefit has been delivered throughout the nine years.

One of the biggest points I would make is to take time on what we call the PAD phase—the planning and design phase. That is set out really well in figure 2 of the Report. There is a very clear timeline, and within that you have the lessons you have talked about today from PAD, procurement and delivery, so you can map that across, as the NAO would, to where things are common with another transformation and what would work and what would not in a different context. Just as we learned from our challenges in the past, I am sure we will learn from others, and I am sure there are bits we could have learned from Government that we could have done better—

The one thing I was going to say—

I think Victoria should have the last word.

This was a big critical national infrastructure programme. There are other things. We will take these lessons in the Bank, and there will be things that we will be delivering a lot more quickly. I think it is about picking the bits that are most relevant to particular programmes and thinking, “Is the governance right for you?”. You probably do not need something as complicated as RT for everything, but sometimes you do. This Report, which is really great, makes it look as if we are a swan—there is a lot of foot-paddling underneath, so I do not want anyone to go away and think this was easy; there was a lot of work from a lot of people to get there.

It is a pleasure to have a swan rather than the ugly ducklings that we often have in this Committee.

I thank all three of you very much. It is a real pleasure to have had you in front of us and to see a project that has been so successful, even though it is one of the most complicated projects that we have come across. I thank you hugely for delivering such a successful project. We will certainly be doing all we can to publicise your successes. I know you are all very busy people, so thank you very much indeed. An uncorrected version of the transcript will be available in the coming days, following which we will produce a Report with recommendations, which I hope you will look at. Depending on the answers to those recommendations, we will do our best to publicise your success.