Roadmap for Real-Time Gross Settlement service beyond 2024

Responding to this consultation

Why we are consulting

The Bank is in the process of renewing the Real-Time Gross Settlement (RTGS) service, with the move to enhanced ISO 20022 messages in April 2023 and new core settlement engine due to be introduced in Spring 2024. This consultation seeks industry views on what features they would like to see investment in for the next stage of roadmap for RTGS beyond 2024.

Who we would like to hear from

We would like to hear from a wide range of existing and future users of the RTGS service as well as other stakeholders. This includes banks and building societies, payment service providers, technology providers, other financial market infrastructures, end-users and trade associations.

Existing RTGS participants

We would be particularly interested in your feedback on:

• Features that could change how your organisation currently interacts with the RTGS service, such as new ways to connect, maintaining and enhancing RTGS resilience and extending the operating hours.
• New services, such as synchronisation, new ways to generate intraday liquidity or Application Programming Interfaces (APIs), which could allow your organisation to offer innovative services to your customers.

Firms interested in joining RTGS

We would be particularly interested in your feedback on:

• Features that might make it easier to access the RTGS service, including new ways to connect and APIs.
• New services that can support your ability to provide innovative value-added services to your users, such as synchronisation.

Operators of payment or securities settlement systems

We would be particularly interested in your feedback on:

• Features that could make your interaction with RTGS more effective. This includes extending the operating hours, new ways to connect and a new centralised RTGS identity service.
• New services (such as synchronisation and APIs) that can support your ability to provide innovative value-added services to your users.

Providers of technology services to financial institutions

We would be particularly interested in your feedback on:

• Features that affect how you provide services to your clients using RTGS. This could include new ways to connect, APIs and reconciling data.
• How you could contribute to or provide new services, such as synchronisation.

Users of electronic payments and their representatives (eg trade associations)

We would be particularly interested in your feedback on:

• How features, such as extended operating hours, APIs and synchronisation, might affect the speed, cost and efficiency of payment services you or your member organisations use.

Who in your organisation should respond to this consultation

We would like to hear from respondents who have a broad, strategic view of their organisation’s future priorities and how RTGS can support them. Responses should ideally include collated views from colleagues across their organisations, including those responsible for strategic investment in payment services.

When we need responses by and how to respond

We would be grateful for responses to this consultation by 30 June 2022.

Not all questions will be relevant to your organisation, but please do answer as many as possible. We are interested in gathering as much relevant feedback as possible to form a view of industry priorities.

Please indicate in your response if you believe any of the proposals in this consultation paper are likely to impact persons who share protected characteristics under the Equality Act 2010, and if so, please explain which groups and what the impact on such groups might be.

During the consultation period, we will also conduct further outreach via workshops and events.

Who to contact if you have questions

If you have any questions about this consultation, please email RTGSRoadmapConsultation@bankofengland.co.uk

Next steps

We will analyse the responses and publish a feedback summary in early 2023. This will include initial thoughts on how to prioritise the delivery of new features. We will then develop a roadmap, with the expectation that implementation will be gradual, through consistent close engagement with the industry.

Foreword

Payments are essential to the smooth functioning of any financial system. They ensure businesses can pay their suppliers and staff, that the wholesale and money markets can settle and they enable government to channel spending and revenue. They are also essential to individuals, allowing us all to buy goods and services.

The payments landscape continues to change at a rapid pace. Firms are adopting new technologies and business models to offer faster, cheaper and more flexible ways to pay. The market for payments has become more innovative and competitive, driving value for households and businesses that are so reliant on them. We have seen the transactional use of physical cash has reduced significantly, and the functionality of and demand for digital payments has grown. The private sector continues to innovate, and central banks globally are assessing the case to issue Central Bank Digital Currencies.

The Bank of England, as the operator of the RTGS service and the provider of central bank money (the ultimate sterling settlement asset), is at the heart of the UK payments. RTGS settles over £720 billion each working day, which represents a variety of economic activity from money markets to house purchases to online shopping. We want RTGS to continue to support and facilitate private sector innovation and competition in this fast changing world, always with a keen eye to resilience.

In 2017, the Bank announced an ambitious vision to renew the RTGS service to respond to the changing payments landscape. Since then, we have focused on designing and building a materially stronger, more resilient, flexible and innovative sterling settlement system. We are on track to implement the ISO 20022 messaging standard in April 2023 – moving to a common global language for payments. We will then introduce a new modern, flexible and efficient RTGS core settlement platform in Spring 2024. The new platform will offer enhanced resilience, improved access to data and liquidity management. These changes will offer opportunities for the industry to offer improved services to customers and reduce costs.

But we do not want to stop there. We are launching this consultation to seek industry views to help shape the Bank’s strategy for continued evolution of RTGS after the new core settlement engine is live. It outlines a range of ambitious new features, such as linking RTGS with other platforms to achieve synchronised settlement, enhanced resilience through new ways to connect to RTGS and extended operating hours. These features, if implemented successfully, will catalyse innovation in tandem with running and developing a highly resilient RTGS. Many of the features proposed will not just enhance domestic payments: they will also support achieving the Financial Stability Board’s roadmap for enhancing cross-border payments globally.

Unlocking the benefits of the renewed RTGS service will only be possible in close collaboration with the industry. We have actively engaged with stakeholders to develop the proposals in this consultation, but we are keen for more views and ideas in particular regarding the prioritisation of key elements for the roadmap. Your input will help us shape the long-term roadmap for RTGS and allow us to deliver the features that meet the needs of the industry.

Industry views are essential to us: they are the users, and they pay for the service provided by the Bank. We want to deliver features that the industry needs and to provide value for money. We have in parallel issued a consultation on the new proposed framework for recovering the costs of the renewed RTGS service.

We would like to invite your active and open contributions to this consultation – through written feedback as well as participating in our workshops and events.

Victoria Cleland, Executive Director for Banking, Payments and Innovation.

Executive summary

The Bank is progressing with the delivery of the renewed Real-Time Gross Settlement (RTGS) service. In April 2023, we will move our platform to the international ISO 20022 messaging standard. In Spring 2024, we will launch the new core settlement engine, which will be modular, flexible and based on open standards. These enhancements will deliver considerable benefits to the industry, and our operating model will enable the continuous evolution of the RTGS service and introduction of new features.

In this consultation, we invite your views on the new features we are considering for beyond 2024. We would like to understand your views on priorities, costs and benefits for your organisation and preferred implementation options. Your input will help shape the long-term roadmap for RTGS and allow us to deliver the features that our users need and will be ready to use.

Our long-term vision is for the renewed RTGS to act as an open platform for the UK finance industry to facilitate innovation and support safe and efficient settlement in central bank money. Our proposals are intended to support the payments industry as it evolves to meet demand for cheaper, faster and safer payments for the UK economy. Section 1 sets out the out our long-term vision in more detail.

Our vision is built around three focus areas:

The Bank will continue to engage the industry in ongoing product and policy development throughout the renewal and operation of the RTGS service.

The Bank launched on 29 April 2022 a consultation on the framework for recovering from industry the costs of building and running the renewed service (the RTGS/CHAPS tariff consultation). This focuses on the introduction of ISO 20022 messaging and delivering the new core settlement engine, which will lay the foundation for the continued evolution of the RTGS service beyond 2024.

The proposals in this consultation are not included in the RTGS/CHAPS tariff consultation. The Bank will consider how best to recover from the industry the costs for the proposals taken forward following this consultation once we agree the scope, timing and priorities of the roadmap for RTGS beyond 2024. In agreeing priorities, the Bank will take into account costs and benefits for the industry and the Bank’s public policy objectives.

The Bank is also continuing to explore the case for a UK Central Bank Digital Currency (CBDC). This is a separate initiative not covered in this consultation.

1: Our vision and roadmap for RTGS beyond 2024

1.1: RTGS Renewal Programme

Background

Following extensive industry feedback, the Bank published the RTGS Renewal Blueprint (the Blueprint) in May 2017, which focused on ensuring RTGS is capable of responding to changing demand while assuring high levels of resilience. The Blueprint outlined a wide range of proposals intended to provide higher resilience, broader access, wider interoperability, and improved user functionality compared to the existing RTGS. In Autumn 2017, the Bank took on responsibility for managing the CHAPS service to enhance end-to-end risk management of CHAPS.

Figure 1: RTGS renewal vision

Our vision for the renewed service is to deliver significant benefits for RTGS participants and the Bank’s objectives of maintaining monetary and financial stability:

• Higher resilience. The new core settlement engine will ensure that RTGS can continue to support the stability of the UK financial system in the face of evolving threats. It will also reduce the cost and risk of further upgrades.
• Broader access. New types of payment system providers have already joined RTGS following our policy changes. The renewed RTGS will lower the cost of connecting and make it more economical for a wider range of participants to join.
• Wider interoperability. The implementation of a common messaging standard through the UK’s ISO 20022 Common Credit Message will deliver wider interoperability between payment types making it easier to switch between payment systems should the need arise. Global standardisation will enable greater interoperability with other payment systems, leading to more efficient fraud detection and increased processing efficiency.
• Improved user functionality. The new service will offer new functionality that will save costs and offer improved integration with participant systems, such as enhanced liquidity management, the introduction of APIs and greater data availability.
• Strengthened end-to-end risk management. The Bank of England began to deliver the CHAPS service directly in November 2017, which ensured greater oversight and governance.

Programme transition approach

In 2018, the Bank created four ‘Transition States’ in order to deliver the features gradually and minimise risk for RTGS participants. Transition State 1, completed in 2020, has put in place the foundational infrastructure to deliver the enhanced functionality. The Bank is progressing with the delivery of the Transition States 2 and 3 of the Programme. The first major publically visible milestone in April 2023 will see RTGS migrate to ISO 20022 messaging standard (Transition State 2). We will then launch the new core settlement engine in Spring 2024 (Transition State 3).

The new core settlement engine and Programme’s benefits

The move to ISO 20022, coupled with the new core settlement engine, will deliver many of the enhancements outlined in the Blueprint. They also build the foundation, on which some of the most innovative features set out in the Blueprint can then be delivered. These features can be introduced gradually in line with industry preferences and cost and benefits analysis.

Figure 2: RTGS Renewal Programme benefits delivered through the new core settlement engine and the roadmap beyond 2024

Successful delivery of the benefits targeted in this roadmap is dependent on the foundations laid during earlier transition states and in particular, the move to ISO 20022 and the delivery of a new core settlement engine (see Figure 2). The new core settlement engine will be modular, flexible and based on open standards. Combined with a new operating model this will enable the continuous evolution of the RTGS service and the introduction of the features set out in this consultation at a cadence that meets the needs of participants and the wider industry.

The changes delivered by Spring 2024 will offer enhanced resilience, improved access to data and liquidity management. Section 1.2 sets out the progress we will have achieved in more detail.

1.2: What we will have delivered by Spring 2024

What the Bank has achieved so far

Since the Blueprint, the Bank has made several policy changes towards achieving the vision for the renewed RTGS service:

• In July 2017, the Bank extended access to RTGS settlement accounts to non-bank payment service providers (NBPSPs) to support competition and innovation in payment services. Half a dozen NBPSPs now hold accounts in RTGS.
• Since January 2018, CHAPS participants have had the option to connect to the service through a technical aggregator. This can reduce the connectivity costs without diminishing resilience.
• In January 2021, the Bank permitted CHAPS Direct Participants to outsource their infrastructure to a Cloud Service Provider, if it is done in a safe and controlled manner.
• In April 2021, the Bank introduced a policy to enable payment system operators to apply for omnibus accounts in RTGS to develop innovative payment services underpinned by central bank money.

Changes planned by Spring 2024

Table A outlines the additional enhancements and benefits that will be achieved by Spring 2024.

1.3: Our three focus areas for RTGS beyond 2024

In the long-term, we want the renewed RTGS service to act as an open platform for the UK financial services industry to facilitate safe and efficient settlement in central bank money. It will accommodate a wide range of participants, diverse means of connecting and enable new links to other systems. This will enable participants to offer cheaper, faster and safer payments for their customers.

There are three areas in which we are focussing our efforts, and seeking industry views, to further enhance RTGS beyond 2024: new ways to connect, innovative and flexible settlement services and world-class resilience. These are covered in detail in Section 2, 3, and 4 below.

New ways to connect to RTGS (Section 2)

Secure connectivity is fundamental to joining any RTGS service. It is also an important element of participants’ costs of connecting. We aim to provide ways of connecting that are cost-effective, based on open standards and compatible with a wide range of technologies. Flexible connectivity can help us encourage more participants to join and enhance the resilience of RTGS.

The SWIFT network is currently the only way to connect to RTGS. We propose introducing a new channel to send and receive payment instructions. We also propose evolving our API platform to enable participants to automate more data queries and instructions.

Flexible and innovative services for our users (Section 3)

RTGS already provides settlement services for a variety of payment systems. Platforms like CREST and CLS benefit from close integration with RTGS to eliminate risks for securities and FX transactions. However, there are multiple areas where we are looking to broaden our service provision.

We see potential in closer integration between RTGS and other ledgers. This could mean linking RTGS with new digital asset platforms. This could involve closer links to RTGS systems in other currencies to transmit cross-border payments or support smooth liquidity management. We propose developing a new synchronisation interface to enable this.

The new settlement engine will already have no technical barriers to operating on a near-24/7 basis in the future. Based on your feedback, the Bank will work with the industry to consider when and how to extend the operating hours of RTGS.

We propose that the new service will expand the range of ways to generate intraday liquidity against collateral and reduce participants’ liquidity costs. We also want the renewed RTGS to offer simple and flexible tools to manage the accounts, and monitor settlement activity.

More recently, some central banks have been exploring whether and how they could develop new wholesale settlement platforms often using distributed ledger technology (often referred to as wholesale Central Bank Digital Currency (CBDC)). Box B explains how RTGS Renewal could support similar objectives.

World-class resilience (Section 4)

The resilience and integrity of RTGS are essential for the stability of the UK economy. We are committed to always put resilience at the heart of RTGS design.

We will continue to maintain the highest levels of resilience as our services evolve. We will also leverage new technologies to provide more usable and available back-up and contingency services. We will consider evolving or replacing our third site (MIRS) to support new services, reducing our dependency on SWIFT, and enabling CHAPS to act as a contingency for critical retail payments.

Summary: The new features proposed

1.4: Objectives of this consultation

In this consultation, we would like your views on the new RTGS features proposed beyond 2024. Your input will help shape the long-term roadmap for RTGS and allow us to deliver the features that meet the needs of the industry in the light of the changing payments landscape, and deliver optimal value for money.

The Bank launched on 29 April 2022 a consultation on the framework for recovering from industry the costs of building and running the renewed service (the RTGS/CHAPS tariff consultation). This focuses on the costs of the introduction of ISO 20022 messaging standard and delivering the new core settlement engine, which will lay the foundation for the continued evolution of the RTGS service beyond 2024.

The proposals in this consultation are not included in the figures in the tariff consultation. The Bank will consider how best to recover from the industry the costs for the proposals taken forward following this consultation once we agree the scope, timing and priorities of the roadmap for RTGS beyond 2024.

1.5: Next steps

How we will decide on priorities for delivery in the RTGS roadmap beyond 2024

When deciding on the priorities for RTGS roadmap, we will consider a number of factors:

• The Bank’s objectives. We will assess the extent to which the features support the Bank’s objectives: to maintain financial and monetary stability and support competition and innovation in the payments sector. That includes enhancing cross-border payments in line with G20 commitments (see Box A).
• User demand. We will build on our understanding of the features that users need.
• Value for money. We will make sure that we introduce only the features that deliver value for money for the users.
• Complexity and costs of implementation. We will consider the amount of time, resource and complexity required for the Bank and the industry to develop, test and implement the new features.
• Dependencies among the features. We will prioritise the changes that enable other features or unlock industry innovation.
• External dependencies. We will consider how the timing of other major change projects in the UK and globally might affect users’ ability to implement features in RTGS. This includes the launch of the New Payments Architecture (NPA).

Next steps

We will analyse all responses and publish a feedback summary in early 2023. This will include initial thoughts on how to prioritise the delivery of new features.

We will then work with industry to start developing more specific delivery plans and timelines for the features that are determined as priorities.

We are committed to ongoing user engagement. Throughout the delivery of the roadmap and beyond, we will work with users to shape our implementation approach and give sufficient advance notice of any upcoming changes.

Consultation questions

The questions below are intended to provide context to the more detailed points later in the consultation. Sections 2, 3 and 4 include further questions on specific features proposed beyond 2024.

Role of your organisation

1. Is your organisation currently a user of RTGS?
2. Is your organisation a direct/settlement participant in a Financial Market Infrastructure?
3. What is your organisation type?
4. Is your organisation interested in joining RTGS or expanding its use of RTGS services?
5. Is your organisation interested in providing services to RTGS account holders? If so, in what capacity would your organisation be interested?
6. If your organisation is interested in connecting to RTGS and/or CHAPS, what are the barriers that have prevented you from doing so?

Questions on general trends

1. In your view, what are the most important trends, driving the need for further enhancements to settlement in RTGS?
2. What do you think are the key opportunities to improve the efficiency of settlement in central bank money in the UK? Which type of payments have the highest potential for improvement?

Questions on priorities

These questions will be important in helping us to prioritise changes. We recommend reading Sections 2, 3 and 4 before answering this group of questions. It might helpful to consider these as you read the document.

1. See Table B in Section 1.3. Out of the features outlined in this consultation, what do you consider as the highest priorities that would bring the most benefit to your organisation beyond 2024? Please explain the reason for your selection, including an indication of implementation urgency of particular features.
2. See Table B in Section 1.3. If you had to choose to deprioritise up to three of the features outlined in this consultation, what would they be? Please explain the reason for your selection.
3. Are there any additional features that the Bank of England should introduce as part of the long-term roadmap for RTGS that are not outlined in the consultation paper? If so, please explain how they would be beneficial for your organisation.

2: New ways to connect to RTGS

We aim to provide ways of connecting that are cost-effective, based on open standards and compatible with a wide range of technologies. Flexible connectivity can help us encourage more participants to join and also enhance the resilience of RTGS.

2.1: A new channel to send and receive payments

Consultation questions

We propose enabling an alternative channel to send and receive messages.

1. Read ‘Why this is important’. Do you agree that RTGS should introduce an alternative channel to send and receive payments?
2. Read ‘Common contingency messaging channel’. Do you agree that RTGS should implement a contingency messaging channel in the event of an outage of the primary network?
3. Do you expect your organisation to use an alternative channel? If yes, what would your organisation use the alternative messaging channel for? If not, what is the reason for this?
4. Read ‘How it would work’. How would you assess the complexity and cost to your organisation from (a) adopting V-shaped networking and (b) using an alternative channel?
5. In your estimation, how long might it take your organisation to implement (a) an alternative channel; (b) a contingency messaging channel?
6. Read ‘Key outstanding questions and next steps’. How would you suggest the Bank should implement an alternative connectivity channel?

What we are proposing

Currently, the only way to access RTGS is via the SWIFT network. We have heard from participants that they would benefit from an alternative way of connecting. Beyond 2024, we propose creating a new channel to connect to RTGS and to send and receive payment instructions.

Who this is relevant to

• Our current participants and users.
• Our prospective participants and users.
• Providers of networking and connectivity services.

We welcome feedback on your demand for new ways of connecting. We also want to hear your views of the technologies we should use to ensure that the alternative channel is secure, efficient and low cost.

Why this is important

How it would work

We are looking for feedback on how the alternative channel should be designed. This includes whether that should be traditional ‘messaging’, API or any other technology. Two aspects would form the core of our approach:

Figure 3a: V-shaped model

Figure 3b: Y-shaped model

Impact on participants and users

Connecting to alternative channels will be optional for CHAPS participants in the foreseeable future. Our foundational principles are that the new channel needs to be secure, resilient and cost-effective for users. To the extent possible, we also want to avoid imposing specific hardware or technology choices on users.

Under the proposed model, CHAPS participants would need to obtain security credentials from the Bank. They would need to ‘sign’ ISO 20022 payment messages using their secure keys (see Section 2.2).

Key outstanding questions and next steps

We would welcome feedback on the following implementation options:

• Open or closed networks. We are considering how to reduce the physical barriers to connectivity to RTGS. Particularly, we are considering if it is possible to ensure adequate security without proprietary ‘closed’ networks.
• Physical infrastructure. Our design objective is to make sure that we can support participants using cloud infrastructure (subject to meeting our rulebook requirements).
• Rulebooks and assurance. We will review the connectivity requirements in our rulebooks to ensure that they are proportionate to the size of the participant and promote access.
• Use of APIs. We are considering how we can enable payment instructions to be submitted via an API while ensuring an adequate level of security.

Common contingency messaging channel

The new connectivity channel will allow participants to have multiple connections to RTGS and eliminate a single point of failure. We anticipate that some will take advantage of this opportunity. At the same time, it is unlikely every participant will find it practical to maintain multiple fully-fledged connections.

We are considering whether we should also provide a contingency solution available to all participants, including a protocol and an infrastructure for data transfer. For instance, this could be a simple file-based protocol with files being transferred securely over the internet. We would design both with a view to maximising value for money for the participants.

However, we are also aware of the risks related to building contingencies that are seldom used. They risk becoming unreliable or conversely, creating a disproportionate testing burden.

We welcome any feedback on how we can design a contingency solution that meets our participants’ needs.

2.2: Centralised RTGS identity service

Consultation questions

We will deliver a centralised identity service for RTGS to support the future security model.

1. Please read ‘The principles we will follow’. To what extent do you agree with the proposed design principles for the development of the Bank of England’s PKI? Are there any other principles or design considerations we should consider?
2. Please specify any design considerations for PKI that the Bank should consider.
3. Read ‘Potential to expand to more payment systems’. Do you agree that our PKI credentials should be available to other payment systems?

We will deliver a PKI that will act as a centralised identity service for the renewed RTGS. It will be the foundation of security in the multi-channel RTGS.

How PKI works

A PKI enables all secure communications to be ‘signed’. This proves that messages have originated from the right sender, and have not been tampered with. The recipient of the message will also be able to verify that the sender’s certificate is still valid. This additional security can protect messages from being intercepted in transit.

Compatibility with Distributed Ledger Technology

The renewed RTGS is being developed to be able to interface with infrastructures based on wide range of technologies, including Distributed Ledger Technology (DLT). Our DLT Proof of Concept demonstrated that RTGS needs to be able to generate suitable cryptographic proofs. We expect the PKI to be an important part of our future approach.

The principles we will follow

• Security. The PKI will be designed in line with the highest industry standards, following guidance from the National Cyber Security Centre.
• Cost-effectiveness. The PKI will be cost-effective for participants to use. Our requirements will be proportionate to the participant’s use of our services.
• Flexibility. The PKI will support participants using both on-premise and cloud infrastructures.
• Openness. The PKI will be available on any channel that is connected to RTGS.

Potential to expand it to more payment systems

Currently, a financial institution that wants to be a part of the UK’s main payment and settlement systems needs to connect to multiple PKIs. We have heard from some participants that this can be inefficient and costly. Different PKIs can have diverging operational, hardware and assurance requirements. We are considering whether we can enable the credentials issued by our PKI to be used in other payment systems.

2.3: Automating data transfers with RTGS via APIs

Consultation questions

We will continue introducing new APIs based on industry demand and evolving our ecosystem.

1. How do you think the RTGS API platform should develop further to meet the requirements of the participants and the wider payments industry?
2. How important are each of the additional use cases in terms of their prioritisation for addition beyond 2024? Do you have any additional use cases to suggest? Please comment on the rationale and an indication of ranking among them.

APIs in the new RTGS platform

APIs allow two applications to exchange information. The renewed RTGS will allow organisations to use APIs for bespoke or automated data queries.

The benefits of API adoption include closer integration with participants and wider access. Our long-term vision is to enable all types of user interaction with RTGS to happen via APIs.

What we have done so far

We have already taken the first steps towards API enablement. In October 2021, we published the API specifications of read-only access to CHAPS transactions for user feedback. In June 2022, we are aiming to introduce this first API, which uses the SWIFT API Gateway, into the RTGS Pilot Platform.

What we are doing next

The Bank plans to expand the set of APIs which will be available from Spring 2024. We have prioritised APIs for frequent processes that can be easily automated, based on previous feedback from our users.

These APIs will enable access to:

• All of the participant’s transactions.
• Account data.
• Payment and liquidity controls.
• Notifications.
• Statements.

We will also aim to make the API platform easy to use. This will include an enhanced sandbox and documentation that will include instructions, examples and code samples.

For the foreseeable future, the use of APIs will be optional. All the API functionality will also be available through alternative user interfaces – though there might eventually be a case to make certain functionality API only.

Further changes beyond 2024

From 2024 onwards, we expect there to be two focus areas for our further API development:

1. We will further evolve our API ecosystem. We expect to provide participants with a complete set of try-out tools (eg advanced sandbox environment, API explorer) and a community feedback channel. Once we introduce alternative channels (Section 2.1), we will seek to enable APIs to be accessed outside of the SWIFT network.
2. We will introduce new APIs based on user demand and to support new functionality. The additional use cases we will consider currently include:

• Additional liquidity management features.
• Reporting and analytics.
• Management of network preferences (see Section 2.1).
• Submission of payment instructions (see Section 2.1).
• Account management.
• Reconciliation (see Section 4.3).

3: Flexible and innovative services for our users

We seek to offer a wide range of innovative and flexible services to address the changing needs of our users. We want to enable users to build on these services and innovate to create value-added propositions for the end customers in domestic and cross-border payments markets. This will help deliver safer, faster and cheaper payments to the people of the UK.

3.1: Synchronisation: linking RTGS to other ledgers

Consultation questions

We propose to create a generic interface into RTGS which would allow a wider range of ledgers to connect to RTGS to synchronise transactions.

1. Read 'Why this is important'. Do you agree that RTGS should offer an interface for synchronised settlement?
2. Read ‘Who this is relevant to’. Would your organisation be interested in using or providing synchronisation services? Please explain what your organisation would use synchronisation services for.
3. Read ‘Who this is relevant to’. How would you assess the complexity and cost to your organisation from preparing to (a) provide synchronised settlement and (b) use synchronised settlement?
4. Read 'Participant requirements'. In your estimation, how long might it take your organisation to implement the relevant changes to use or provide synchronised settlement?
5. Read ‘Applications’. What are the most valuable use cases that would bring benefits for your organisation? Are there any other use cases not listed in this section that you would suggest?
6. Look at Figure 4 and Table D. Do you agree with the proposed implementation approach for synchronisation?
7. What are your organisation’s thoughts on the technical design or policy framework for synchronisation (eg data standards, connectivity and earmarking functionality)?

Who this is relevant to

• Firms interested in providing synchronisation services.
• RTGS account holders.
• Operators of digital asset ledgers (eg property or securities).
• Payment system operators in the UK and other countries.

We welcome feedback on your demand for synchronised settlement, the type of transactions it should be used for, and the proposed model. We want to understand how to design the service in a way that is cost-effective and provides the right safeguards.

Why this is important

Synchronisation allows linking transfer of two assets in a way that one asset moves if and only if the other asset moves. Such conditional settlement is already widely adopted in securities settlement (eg via the CREST service) and foreign exchange settlement (via CLS). Synchronised settlement can be either Delivery versus Payment (DvP) or Payment versus Payment (PvP), depending on whether the other leg is a payment or an asset movement.

We are proposing to create a generic interface into RTGS which would allow a range of ledgers to connect to RTGS. The key benefits synchronisation would bring are:

Applications

We have engaged widely with our stakeholders via a Synchronisation Call for Interest and industry workshops. Our stakeholders identified a range of potential applications of synchronised settlement, including:

• Housing transactions (DvP). Processing of housing transactions can be inefficient and require multiple parties. Many countries are replacing paper-based processes with digital ledgers and integrating property transfer with the payment. Industry participants suggested that synchronised settlement could help to streamline the transaction process, reducing costs and enhancing efficiency and transparency.
• Cross-border payments (PvP). Cross-border payments are typically more expensive, slower and less transparent than domestic payments (see Box A). Linking payment infrastructures in different currencies could reduce delay, costs and operational complexity.

The industry also identified other use cases of synchronisation, including security transactions, trade finance and corporate actions. This feedback has given us confidence that building this interface could help the Bank unlock and encourage industry innovation.

Figure 4: Synchronisation model

Prototype development

We are also collaborating with the London Centre of the BIS Innovation Hub and a private sector consortium on Project Meridian, which will trial a range of applications of synchronised settlement. This project will take place during 2022 and test an end-to-end flow of a synchronised transaction. It will seek to produce an open-source prototype and set out clear recommendations for any RTGS operator seeking to introduce synchronised settlement.

Participant requirements

The Bank would create a generic synchronisation interface to allow external ledgers to connect to RTGS. We expect this linkage to be facilitated by a new type of firm: a synchronisation operator. Synchronisation operators would orchestrate settlement between RTGS, market participants and other platforms.

Figure 4 and Table D show how synchronisation could work and the responsibilities of each parties involved. We currently anticipate that the solution would utilise the ISO 20022 messaging standard.

Key outstanding questions and next steps

We want to build the technical design and policy framework for synchronisation in more detail. The key outstanding questions include:

• The relationship between the synchronisation operator and the RTGS settlement participants.
• The policy framework for the synchronisation operator’s access to the RTGS.
• Technical requirements such as data standards, earmark functionality and possible liquidity saving features.

Based on the nature and scale of the functions undertaken by synchronisation operators, they might be recognised by HM Treasury and regulated by the Bank as a systemic payment system operator or a specified service provider under the Banking Act 2009.

Alongside answering these questions, we want to identify the priority use cases by working together with industry stakeholders. We also aim to invite firms interested in providing synchronisation services to collaborate on the further development of the technical design and policy framework.

Omnibus accounts

We also introduced a new type of account called omnibus accounts in 2021. Omnibus accounts allow payment system operators to develop innovative ways of facilitating payments, including synchronised settlement.

3.2: Extended operating hours in RTGS

Consultation questions

The renewed RTGS will be able to move to near 24x7 operation. We will consider extending the operating hours in line with the industry’s demand.

1. Read Section 3.2. Do you think that the Bank should extend RTGS operating hours? If you agree, which RTGS services would benefit from extended operating hours?
2. If the Bank of England were to extend operating hours, to what extent do you expect your organisation to use the extended hours for CHAPS and wider RTGS?
3. Please specify what extension to operating hours would deliver the most benefit to your organisation, taking into consideration what is feasible for your organisation to support? Please answer separately for CHAPS and wider RTGS operating hours.
4. Read ‘Impact on participants and other users’. How would you assess the complexity and cost to your organisation from adopting and maintaining extended RTGS operating hours? Please specify whether your response differs depending on the length and type of extension, including any difference between extending CHAPS and wider RTGS operating hours.
5. Please specify any practical constraints to implementing extended operating hours to your organisation.
6. Read ‘Impact on participants and other users’. In your estimation, how long might it take your organisation to implement the changes required to extend operating hours? Please specify if your response would differ depending on the length and type of extension.

Who this is relevant to

• Current and potential future participants in RTGS and CHAPS.
• Financial Market Infrastructures (FMIs) using RTGS.
• End-users.

We would like to hear your views on your potential demand for any extension in operating hours and the complexity for you to implement any required changes in your organisations. We would also like to get any feedback on lessons learnt during the previous process to extend RTGS operating hours that took place in 2016.

Why this is important

What we are proposing

Currently CHAPS operates 06:00–18:00 on business days. RTGS is open slightly longer, with some windows outside of CHAPS operating hours to allow certain transfers and liquidity movements.

The renewed RTGS will be capable of supporting 22x5 operation, with settlement windows on weekends. It will also have no technical barriers to moving to a near 24x7 operation in the future.

Any decision to extend the operating hours of RTGS or CHAPS will consider the industry’s demand and readiness to adopt it alongside public policy considerations. However, even before we take any decision to extend operating hours, the new core settlement engine will enable longer availability for RTGS participants to make internal transfers.

Impact on participants and other users

We recognise that any decision to extend operating hours will require careful industry coordination and significant changes to operating models. For instance:

• Participants and the Bank would need to consider how to enable changes, upgrades and testing to take place during the operating hours and how to enable further automation.
• Participants will also need to consider what this means for customer payment deadlines, operational staff and timing of internal payment processing.

The impact of extending hours reaches beyond RTGS, including into money markets. Therefore, we will consider any decision to extend hours from a wider central bank and industry perspective.

For these reasons, we currently do not anticipate extending hours to be a priority for 2024–2025. However, we are keen to hear your views on when your organisations would be willing and ready to implement relevant changes. In this context, we encourage respondents to consider the steps required from central banks and industry to fulfil the G20’s commitment to enhance cross-border payments.

Key outstanding questions and next steps

If the feedback gathered in this consultation indicates that extending hours is a priority for the roadmap, we will consider further how such extension should be designed. This will include:

• Length of the extension.
• The services the operating hours would be extended for.
• Whether it would be mandatory or only affect a subset of participants.

3.3: More ways to generate intraday liquidity

Consultation questions

We are considering two new ways to generate intraday liquidity in RTGS:

1. New ‘liquidity bridges’ with RTGS systems in other currencies.
2. Generating liquidity in RTGS using securities in CREST as collateral.

1. Read ‘What we are proposing’. Do you agree that RTGS should introduce these features?
2. Would your organisation be interested in using either of these features?
3. For liquidity bridges, please specify which currencies you would like the Bank to explore for further liquidity bridges. Is your organisation interested in using reciprocal liquidity bridges (ie also use your liquidity in RTGS to generate liquidity in other currencies). If so, in which currencies?
4. Read ‘Impact on participants and users’. How would you assess the complexity and cost to your organisation from adopting these features and using them?
5. Read ‘Impact on participants and users’. In your estimation, how long would it take your organisation to implement the relevant changes?

Who this is relevant to

• Current and future participants in RTGS.

Why this is important

We are considering more ways to generate liquidity, which could help RTGS participants to streamline liquidity management across currencies, time zones and systems.

• More flexibility and choice in liquidity management, including in stressed circumstances.
• Potential to lower cost and improve speed and efficiency of cross-border payments. The FSB’s roadmap notes that liquidity bridges can release trapped liquidity and reduce the funding costs of cross-border payments.

Longer operating hours and broader access to RTGS and other international payment systems in the future would enhance the benefits of liquidity bridges further.

What we currently offer

Currently, the Bank offers a range of tools to generate and manage liquidity in RTGS:

• Intraday liquidity. The Bank lends intraday liquidity to participants against collateral held at the Bank.
• CHAPS Liquidity Saving Mechanism (LSM). CHAPS participants can use the LSM to reduce their intraday liquidity requirements by matching up groups of offsetting CHAPS payments and settling them simultaneously. The Bank plans to enhance the LSM in the new core settlement engine.
• A euro liquidity bridge. This allows CHAPS Direct Participants to use their euro liquidity in TARGET2 to generate sterling intraday liquidity for CHAPS payments.
• Auto collateralised repo (ACR). This mechanism with the CREST securities settlement system allows settlement banks to use government securities held in CREST as collateral to generate intraday liquidity for CREST settlement.

What we are proposing

We are proposing two additional ways to generate intraday liquidity in RTGS, both of which are optional to users:

1. Creating new liquidity bridges with other currencies, such as US dollar, Japanese yen, or Swiss franc (subject to agreement with respective central banks and payment systems). This would allow RTGS account holders to use funds in other currencies to generate sterling intraday liquidity in RTGS. We are also considering supporting reciprocal liquidity bridges (ie liquidity in RTGS used to generate liquidity in other systems).
2. Generating liquidity in RTGS using securities in CREST as collateral. Together with Euroclear UK and International (EUI), we are considering how to extend the ACR mechanism so that intraday liquidity can be used in RTGS beyond what is needed for settlement in CREST.

Impact on participants and users

To benefit from liquidity bridges, RTGS participants would also need to be participants in RTGS systems with which we establish a liquidity bridge. Participants would also need to have appropriate operational and legal arrangements in place.

To benefit from the extended CREST ACR mechanism, RTGS participants would likely need to make changes to their internal processes. For example, they would need to set the parameters in RTGS user interface for triggering ACR requests. If relevant, they would also need to obtain a legal agreement from their clients to use their securities.

The gilts used to generate ACR liquidity are considered High Quality Liquid Assets (HQLA) to calculate regulated firms’ liquidity buffers. Where a benefit is received by reducing liquidity usage positions, such gilts should then be treated as encumbered and not included in wider liquidity buffers.

Key outstanding questions and next steps

Both proposals are in their exploratory stage, so there are a number of outstanding considerations:

• Extension to other currencies. We want to hear from you about your demand to use other currencies as collateral to generate liquidity in RTGS. We are also interested in your demand to raise liquidity in other currencies. Our work on liquidity bridges will require collaboration with the relevant central banks and RTGS operators. We will also be guided by the outcomes of the FSB’s cross-border work, including the upcoming CPMI report on liquidity bridges, due for publication in mid-2022.
• Whether liquidity bridges would allow liquidity to be generated only in CHAPS or wider RTGS too.
• Other users of these features. We are considering whether non-CHAPS participants could use liquidity bridges and CREST ACR.
• Whether client securities could be used as collateral for extended CREST ACR mechanism.

Generating liquidity using securities in CREST as collateral is primarily relevant to current and potential future CREST settlement banks. However, EUI and the Bank will explore whether other RTGS account holders could also use this mechanism.

Depending on the responses, we will collaborate with relevant external stakeholders (EUI, other central banks and users) to define more detailed service propositions.

3.4: Harnessing the benefits of richer payments data in CHAPS

There are no consultation questions in this section.

The UK payments industry is moving to ISO 20022, the global standard for payments messaging. This standard creates a common language for payments data across the globe. The Bank is already engaging our stakeholders extensively on our implementation of ISO 20022. The following provides an update on our progress and future plans.

Implementing ISO 20022 within the RTGS Renewal Programme

The Bank is implementing the ISO 20022 messaging standard in stages as detailed on the Bank’s website.

Beyond the transition to ISO 20022 for RTGS, net settlement services and CHAPS, the Bank will implement enhancements and migrate additional services to the ISO 20022 messaging standard. These include the use of the ISO 20022 methodology for APIs and synchronisation.

We expect that the use of ISO 20022 messaging will need to evolve to meet changing market needs and support access for new players. As more jurisdictions make use of ISO 20022, there will be a need to establish and maintain common market practice, while continuing to ensure that the Bank achieves its policy objectives. To this end, the Bank has committed itself to:

• Define a clear change/maintenance cycle. It would allow all CHAPS participants to submit change requests to the Bank and discuss emerging needs of the market. We expect to introduce the Change Management Framework ahead of November 2025.
• Collaborate with other international operators (such as other central banks) to define and document an annual change management cycle for all high-value and cross-border implementations of ISO 20022. This includes ongoing, systematic alignment of technical artefacts and market practice.

Working with industry to realise the benefits of enhanced data

The Bank is working with CHAPS Direct Participants and other stakeholders to consider how to maximise the benefits of ISO 20022. For instance, adoption of payment Purpose Codes and Legal Entity Identifiers can enable more sophisticated fraud identification models.

Figure 5: ISO 20022 migration dates for existing services

From 2024, the Bank will consider mandating the usage of certain enhanced data. We will only do so where there is a clear benefit and the implementation costs to the market are not overly onerous. The Bank’s view (based on industry consultation) is that this will elevate the quality of enhanced data transmitted.

We also continue to work closely with domestic and international colleagues (including Pay.UK, as operator of the future New Payments Architecture) on the ISO 20022 implementation to ensure alignment where appropriate.

4: World-class resilience

4.1: How we will ensure that RTGS stays reliable and resilient over time

There are no questions in this section.

Since its inception in 1996, resilience has been at the heart of RTGS. The current service continues to fulfil its mandate of providing a safe and reliable means of settling payments in central bank money.

Resilience sits at the forefront of the vision to renew the RTGS service. The renewed RTGS settlement engine is being built to be highly resilient through capabilities such as its modular architecture, the introduction of a testing simulator and a built-in ability for quicker change.

Just as the payment landscape continues to evolve, so too must the capabilities that underpin the resilience of the RTGS service. There are two main drivers for the high standard of resilience for RTGS:

• Loss of data integrity or prolonged unavailability of settlement in central bank money is a risk to financial stability that warrants high regulatory expectations for resilience. We want RTGS at least to comply with the international Principles for Financial Market Infrastructures (PFMI).
• Loss of data integrity or unavailability of settlement directly impacts the users of RTGS and their customers. The inability to settle some forms of payments can disrupt activity in the real economy, for example housing transactions.

Resilience on the Renewal Programme

The approach to resilience for the Renewal Programme has two main areas of focus: maintaining the current high level of resilience and enhancing resilience through new capabilities.

This two-fold approach is underpinned by the Resilience Framework for the Programme, focusing on active capabilities of the organisation as well as the reliability of the technical system. This framework is made up of four goals: to anticipate, withstand, recover and evolve from disruption. These are set against five impact dimensions: people, organisation, process, information and technology. This provides a comprehensive approach to enable the service to recover quickly and smoothly from an unforeseen disruption.

Figure 6: Goals and impact dimensions of the Resilience Framework

Maintaining existing level of high resilience

It is crucial that the changes being made in renewing RTGS should enhance the already high level of resilience in the current service. As the Bank evolves RTGS, we will assess the impact on resilience of the service across each of the five impact dimensions. This allows gaps to be identified and enables steps to be taken to ensure a high level of resilience can be maintained. An example of this is through the approach to maintain a suitable settlement contingency (see Section 4.2) in light of new services and ways of connecting.

Enhancing resilience

We will also introduce new capabilities that will bring enhanced resilience. These pieces of functionality will help to fulfil the four key goals of the framework set out above. For example, the enhanced participant reconciliation process (Section 4.3), will contribute to the ‘Recover’ goal by providing a more frequent last known good point from which to rebuild.

4.2: Maintaining suitable contingency for settlement

Consultation questions

We will review the design of our third site contingency solution in light of the evolution of the RTGS.

1. What models for Settlement Contingency should we consider beyond the third site arrangement that we currently operate (MIRS)?
2. Does the list of principles set out provide a suitable framework for selecting or designing a Settlement Contingency solution? How should we prioritise between these principles? Are there any other principles that should be added to this framework?
3. What should we consider when deciding how participants will be able to connect to the Settlement Contingency solution?

Current arrangements for Settlement Contingency

The renewed RTGS core settlement engine will provide a highly reliable and flexible service. The new core settlement platform will be powered by a modern and highly flexible service running with redundancy over two sites.

However, there will still be plausible scenarios in which settlement could become unavailable. These include a failed change, geographical events that impact both sites; and a cyber-attack (eg an attack through the software supply chain).

Our business continuity objective is to restore settlement services in two hours or by the end of day in extreme scenarios. We would not be able to meet this objective in some plausible scenarios without a form of contingency to allow settlement in central bank money to continue.

Our current approach to Settlement Contingency is to maintain a ‘third site’. We define this as:

(a) Settlement engine that is highly independent from the primary service that
(b) Maintains near-real time balance positions; and
(c) Allows settlement to continue if the primary service is disrupted.

This is not the only model for Settlement Contingency. For example, an RTGS service could use a Settlement Contingency solution which allowed settlement to resume from a zero-balance position and required participants to provide collateral to generate new liquidity.

We currently use the Market Infrastructure Resiliency Service (MIRS) as our Settlement Contingency. The Bank was the first central bank to adopt MIRS in 2014, and the service is currently used by two other RTGS operators.

MIRS is operated by SWIFT, and is closely integrated into the SWIFT messaging network. This arrangement has several advantages:

(a) The operations, suppliers, and technology of SWIFT are suitably independent from those of the Bank’s primary RTGS service.
(b) All transactions are stored by SWIFT under the Y-copy model.
(c) All Direct Participants are already using the SWIFT network to connect to RTGS.

Figure 7: Current third site

Drivers for change

MIRS in its current form does not support the Bank’s broader vision for RTGS Renewal. Locating our settlement contingency inside our primary network provider creates a single point of failure that undermines our resilience ambition. It also requires all participants to be connected to SWIFT – undermining our ambitions for a channel-agnostic service.

Additional capability is required to meet industry expectations. A Settlement Contingency must be able to be invoked quickly and with confidence to allow it to be used for a diverse range of incidents. Time taken to move to MIRS, including reconciliation of balances with participants, means that we would currently only invoke it for disruption expected to last more than a couple of hours. We have heard from industry that this aim can be best met by a solution that allows participants to inspect and reconcile balances in real time. Further additional features may be required to support our new services and responses we receive to this consultation.

Settlement Contingency after Renewal and beyond

Our position remains that a Settlement Contingency is necessary and will be mandatory for all participants. However, the nature of our Settlement Contingency solution may change materially. To establish how we will develop our new model, we have set out candidate principles below.

4.3: Reconciling data with participants

Consultation questions

We propose to enhance the functionality and policies to enable improved reconciliation.

1. The Bank is minded to make positive confirmations of reconciliations compulsory at end-of-day. In your estimation, how long might it take your organisation to implement relevant changes?
2. Does your organisation currently reconcile your balance in RTGS intraday?
3. If not, what are the technical barriers for your organisation to introduce intraday reconciliations, and how could these barriers be overcome?
4. What would be the best medium for your institution to send and receive data for reconciliation (eg APIs, ISO messages)?

The Bank intends to enhance processes and functionality for reconciling account balances and transaction data between RTGS and the account holders. Reconciliation is an important tool both for providing a last known good position to rebuild balances from in an incident and for detecting any discrepancies between data held by RTGS and the account holders.

We propose to enhance reconciliations through the following policy changes and improved functionality:

• Requiring positive confirmation of reconciliation. Participants are currently only required to contact the Bank in the event of a discrepancy in their reconciliation process. To provide greater assurance, the Bank is considering whether it would be proportionate to move to a model where participants are required to report the outcome of all reconciliations within a limited time.
• More frequent reconciliations. Participants are currently only required to reconcile their records with RTGS once a day. The Bank will develop the capability, and is considering introducing a requirement, to reconcile more frequently. These could include reconciliations at predefined points during the business day, and the ability to trigger ad hoc reconciliation.
• Utilising new functionality. The Bank intends to increase automation in the reconciliation process to make it easier to meet new requirements. This could include making account statements and transaction data available both using ISO messages and via the API channel, and allowing participants to submit outcomes of reconciliations using these methods.

This will allow our reconciliations process to provide more frequent last known good positions and to detect discrepancies earlier, improving the ability to detect disruptions in RTGS services and then to recover from them.

The Bank expects this to enhance the resilience of our participants as well as RTGS. In particular, it can enable participants to identify issues in their own systems more promptly.

4.4: A retail contingency solution

Consultation questions

The Bank is considering how CHAPS could provide a contingency for critical retail payments.

1. Is your organisation interested in potentially using CHAPS as a contingency route for critical retail payments in the future (eg to increase options available for meeting operational resilience objectives)?

Since 2018, we have been working with Pay.UK and other industry stakeholders to explore how CHAPS could provide a contingency for critical retail payments (CHAPS As a Retail Alternative, or CARA). We have been considering a model where:

• Payment Service Providers (PSPs) would be able to bulk multiple retail payments in files grouped by each receiving PSP.
• The header of the bulked file would be submitted to RTGS and settled as a single CHAPS payment.

CARA would have several benefits as it could:

• Support the RTGS Renewal objectives of wider interoperability and greater resilience. It would allow critical retail payments to settle in CHAPS in unlikely scenarios, such as an outage at the central infrastructure (NPA) level or network level.
• Serve as an important tool to help PSPs meet operational resilience requirements and achieve the FPC’s impact tolerance for completing critical payments.
• Help protect CHAPS from the risk of potential rerouting of high volumes of retail payments to CHAPS in an outage.

We consulted the industry on a potential solution and published our stock-take survey response in Autumn 2020.

In July 2020, we paused CARA work pending further information on the design and features of the NPA. When the work is resumed, we will work with the industry to assess whether there is a suitable business case for CARA. If so, we will work to develop a more detailed service proposition.