Currencies

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:

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:

Providers of technology services to financial institutions

We would be particularly interested in your feedback on:

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

We would be particularly interested in your feedback on:

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 [email protected]

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:

New ways of connecting

We aim to provide ways of connecting to RTGS that are cost-effective, based on open standards and compatible with a wide range of technologies. We will develop a centralised RTGS identity service (Public Key Infrastructure – PKI) to support the new services (Section 2.2). We also propose creating a new channel to send and receive payments (Section 2.1) and evolving our APIs (Section 2.3).

Innovative and flexible services

We seek to offer a wide range of innovative and flexible services to address the changing needs of our users. We propose introducing a synchronisation interface (Section 3.1), looking to expand our operating hours (Section 3.2) and creating more ways to generate liquidity in RTGS (Section 3.3).

World-class resilience

We will continue to maintain the highest levels of resilience. We will also leverage new technologies to provide more usable and available back-up and contingency services. In particular, we propose evolving or replacing our third settlement site (MIRS) to support new features (Section 4.2), evolving our reconciliation capability (Section 4.3) and enabling CHAPS to act as a contingency for retail payments (Section 4.4).

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

The new core settlement engine will lay the foundations for realising all nine RTGS Renewal Programme benefits. A number of benefits will be either enhanced with features of our future roadmap beyond 2024, or are fully dependent upon them for success.

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:

Changes planned by Spring 2024

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

Table A: Progress towards RTGS Renewal vision by Spring 2024

Key features of RTGS Renewal vision

What we will have achieved

Higher resilience

Strengthen resilience of RTGS to respond to emerging threats.

More flexible and resilient core settlement engine.

Updated third site to strengthen protection against extended outages.

New trusted independent store of data to increase confidence in data integrity.

New target operating model for the Bank to enhance resilience, responsiveness to industry and support continuous improvement.

Broader access

Facilitate greater direct access to central bank money settlement for a wider range of participants.

Ability to accommodate a substantial increase in the number of RTGS account holders.

Simpler process to join RTGS, including streamlined and automated testing required for joining CHAPS. Test simulator provided to participants to simulate incoming messages to facilitate onboarding.

Wider interoperability

Promote harmonisation and convergence with critical domestic and international payment systems.

CHAPS Direct Participants able to send and receive ISO 20022 messages containing enhanced data, including purpose codes and Legal Entity Identifiers (LEIs), improving Anti-Money Laundering and sanctions processing and creating opportunities for new data based services to users. 

Improved user functionality

Support emerging user needs in a changing payment environment.

API for richer access to payment and liquidity data.

Enhancements to CHAPS Liquidity Saving Mechanism, including improved matching algorithms and forward-dated payment submission, which will increase efficiency for participants and lower overall liquidity costs.

No technical barriers to moving to near 24×7 operation.

Functionality to facilitate tracking RTGS payments via SWIFT gpi.

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

Table B: Summary of features considered as part of roadmap for RTGS beyond 2024

New ways of connecting

  • 2.1 Alternative channel to connect to RTGS alongside the SWIFT network.
  • 2.2. New RTGS identity service (PKI) to support new types of secure communications.
  • 2.3 Continued improvement to our API platform to automate data transfers.

Innovative and flexible services

  • 3.1 Linking RTGS with asset ledgers and payment systems (synchronisation).
  • 3.2. Extending RTGS operating hours.
  • 3.3 New ways to generate intraday liquidity against collateral.
  • 3.4. Ongoing development of ISO 20022 messaging standard to adopt richer data and expand to new types of messages.*

World-class resilience.

  • 4.1 A comprehensive resilience framework.*
  • 4.2 Maintaining suitable contingency platform for settlement.
  • 4.3 Providing improved tools to reconcile data with our participants.
  • 4.4 Enabling CHAPS to act as a contingency for retail payment systems.

Footnotes

  • * Note these features are not being specifically consulted on at this time.

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.

Table C: Objectives of the consultation

Inform

  • We want to set out the principles that will guide our decision-making.
  • We want to inform you about the benefits of RTGS Renewal and the changes underway.

Assess

  • We want to understand benefits and costs for your organisations to help shape our business cases. We want to understand whether your organisations would be likely to use the new features.
  • We want your input to help us identify the best ways to achieve our outcomes and select implementation options.

Prioritise

  • We want to understand what you would prioritise to be in scope of the roadmap beyond 2024 and why.
  • We also want to hear your views on any priority features that are not currently considered.

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:

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.

Box A: Supporting improved cross-border payments

Despite their increasing importance, cross-border payments continue to suffer from a number of challenges around cost, speed, access and transparency. In 2020, the G20 set improving cross-border payments as a priority. Since then, the Financial Stability Board (FSB), working with the Committee on Payments and Market Infrastructures (CPMI) has identified the frictions affecting cross-border payments and developed a roadmap, consisting of 19 building blocks, to address them. In October 2021, the FSB set out global quantitative targets to be achieved to enhance cross border payments.

The Bank strongly supports the G20 initiative and has actively engaged in the international work to deliver the roadmap. The improvements to RTGS beyond 2024 discussed in this paper could help mitigate some of frictions in cross-border payments identified by the FSB.

  • Weak competition and long cross-border transaction chains. The Bank has already widened access to RTGS to NBPSPs. Our long-term roadmap for RTGS includes enabling access to RTGS via multiple channels, such as APIs, which should provide cheaper and more flexible ways to connect for a more diverse range of participants (Section 2).
  • Fragmented and truncated data formats. The transition to ISO 20022 messaging standard in 2023 will help address data quality restrictions and the interlinking of payment systems. As part of the Bank’s adoption of ISO 20022 in CHAPS, we will mandate the use of Legal Entity Identifiers for certain payments between financial institutions (Section 3.4).
  • Limited operating hours of payment systems. The renewed RTGS will have the technical capability to extend operating hours in line with industry demand (Section 3.2). Extending RTGS operating hours would allow more overlap with payment systems in other jurisdictions and could increase the speed of cross-border payments. This would also create more opportunities to enter into liquidity bridges and for synchronised Payment versus Payment (PvP) transactions to take place.
  • High funding costs:
    • We are considering establishing liquidity bridges with other currencies in addition to the current euro arrangement (Section 3.3). Such arrangements would allow for greater flexibility in intraday liquidity management and reduce the costs of holding liquidity in different jurisdictions.
    • Synchronisation services (Section 3.1) would help to link transfers in RTGS with transfers in payment systems in other jurisdictions, thus enabling payments in different currencies to happen near-instantly. This has a potential to mitigate settlement risk and ultimately lower the costs of cross-border payments.

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. ReadWhy this is important’. Do you agree that RTGS should introduce an alternative channel to send and receive payments?
  2. ReadCommon 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. ReadHow 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. ReadKey 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

Removing a single point of failure for the service and the participants

A significant second channel could reduce the impact of a SWIFT outage on the financial system.

Enabling innovation in settlement

Connectivity needs to support new services, such as new settlement models (synchronisation) and new ways of consuming data (APIs).

Changing connectivity requirements

Participants are increasingly adopting cloud infrastructures and renewing their technology stacks.

Making direct participation more economical

Connectivity is a major cost for new institutions seeking to join RTGS. We want to allow participants to choose the channel that suits them most.

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:

V-shaped networking

Currently, each CHAPS payment message is transmitted end-to-end on the SWIFT network, and RTGS receives a copy for settlement. This is known as a Y-copy networking. To enable secure communication over multiple channels, the Bank will need to move to V-shaped connectivity. Each message will need to be processed by RTGS and passed on directly to the recipient. Figure 3a and 3b show the difference between the two models.

Central identity service

The Bank will develop a new centralised identity solution (Public Key Infrastructure, or PKI). Participants would use Bank-issued credentials to ‘sign’ their communications to prove message origin and integrity. See Section 2.2 on our PKI approach.

Figure 3a: V-shaped model

Figures show how messages are sent to and from RTGS in the current Y-copy model and proposed V-shape network 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. ReadWhy this is important‘. Do you agree that RTGS should offer an interface for synchronised settlement?
  2. ReadWho 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. ReadWho 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. ReadParticipant requirements‘. In your estimation, how long might it take your organisation to implement the relevant changes to use or provide synchronised settlement?
  5. ReadApplications’. 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:

Synchronised settlement for a broader range of assets

Using risk-free central bank money.

Offering customers a faster, cheaper and safer method of transactions

Allowing market participants to create innovative services.

Lower liquidity costs and settlement risk

Eliminating settlement risk from more markets.

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

The synchronisation operator sits in the middle of the transaction, coordinating the information exchange and movement of assets and funds between settlement participants.

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.

Table D: Responsibilities of parties involved in synchronisation

Synchronisation Operator

Orchestrate the synchronised settlement

  • Connect to RTGS, other ledgers and banks.
  • Earmark and release funds and assets.
  • Track information about the status of settlement and earmarks.
  • Agree the terms of service.
  • Promote the service to new ledgers.
  • Set data standards and policies.

Settlement Participants

Agree a relationship with operators and use services

  • Grant permissions to the operator to move funds.
  • Set limits of the value of earmarks.
  • Monitor the operators’ activities on earmarking and releasing of their funds.
  • Confirm the availability of funds to the operator.

Asset Ledgers

Agree a relationship with operators and transfer asset ownership

  • Agree the relationship with synchronisation operators.
  • Confirm the ownership of assets to the operator.
  • Earmark and transfer ownership of assets upon request from operators.

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 24×7 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. ReadImpact 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. ReadImpact 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

Enhancing cross-border payments

Longer RTGS operating hours would increase the overlap with RTGS systems in other jurisdictions and help to increase the speed of cross-border payments. Extended hours create better opportunities to enter into liquidity bridges and benefit from PvP arrangements. All this would support the G20 goal to enhance cross-border payments (see Box A).

Helping support innovation and competition

Extended hours support a greater variety of business models and increase flexibility for end-users, who can take corporate funding and investment decisions later in the day.

A global focus

Recently, the focus on extending operating hours has been increasing. Some central banks either have moved, or announced their plans to move, their RTGS system operating hours to 22×5 or 24×7. Private sector solutions focusing on 24×7 have also emerged, creating a stronger case to adopt longer operating hours across jurisdictions. The recent CPMI report on extending operating hours has highlighted the benefits of working towards a common global settlement window.

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 22×5 operation, with settlement windows on weekends. It will also have no technical barriers to moving to a near 24×7 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. ReadWhat 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. ReadImpact on participants and users’. How would you assess the complexity and cost to your organisation from adopting these features and using them?
  5. ReadImpact 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

The diagram sets out the timelines for migration to ISO 20022. Major milestones are ISO 20022 cutover in April 2023 and new RTGS core settlement engine in Spring 2024. The phase beyond that will see enhanced data become mandatory and further functionality added for CHAPS participants.

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.

Box B: Wholesale Central Bank Digital Currency (CBDC)

What is wholesale CBDC?

A CBDC is a digital form of money issued by a central bank.

The Bank has been providing access to digital sterling central bank money to wholesale payment providers and infrastructures through RTGS since 1996. Recently, central banks around the world, including the Bank of England, have been actively exploring the possibility of issuing digital central bank money to the general public (a ‘retail CBDC’).

Some market participants have called for a ‘wholesale’ version of CBDC. Unlike the retail CBDC, a wholesale CBDC is more likely to be an innovation in the settlement operations and technology, not a new form of digital money. Typically, wholesale CBDC developments focus on improving the settlement of securities, foreign exchange and cross-border payments.

Figure A shows how wholesale CBDC could interface with RTGS and other systems to achieve interoperability, using securities settlement as an example.

Figure A: Wholesale CBDC potential interfaces with RTGS

RTGS issues wholesale CBDC into the external platform. Delivery versus payment settlement happens in an external platform. Then the wholesale CBDC is destroyed.

Some RTGS operators internationally have experimented, eg through proofs of concept, in developing separate DLT-based platforms for central bank money. Importantly, these experiments have focused on use cases far beyond the payment leg of a transaction. They have involved market participants and other infrastructure providers to build end-to-end solutions for a specific use case such as bond issuance or settling equity trades.

RTGS renewal and interoperability

This consultation is seeking input on ways in which the Bank of England can enhance the wholesale payment settlement functionality we provide.

The objective of modernising the RTGS service is to offer a more accessible, functional and resilient platform for digital settlement in central bank money. We have already made important strides in enhancing accessibility for new players. For example, in 2017, we opened direct access to settlement accounts to non-bank Payment Service Providers. In 2021, we launched an omnibus account offering to innovative high-value payment services, underpinned by the security of central bank money.

While we are delivering the renewed RTGS service on centralised infrastructure, it will be able to interface with a wider range of innovative payment systems and providers, including those using DLT. Our market engagement gives us reassurance that we can build bridges between RTGS and the new technologies. Figure B below shows how RTGS can interface with new types of ledgers.

This consultation sets out ways in which renewal can improve the functionality offered by RTGS, in particular:

  • We will create a new channel to connect to RTGS (Section 2.1), making it accessible to a wider range of market participants.
  • Synchronisation (Section 3.1) will provide an interface to connect RTGS to digital asset ledgers and payment systems in other currencies. Figure B shows how synchronisation can be used to enable interoperability in a similar way to wholesale CBDC.
  • Extending the operating hours of RTGS (Section 3.2) will improve our ability to settle cross-border payments across multiple time zones.

We will also work with the newly established BIS Innovation Hub in London to test the use of new technologies in wholesale settlement.

Figure B: Synchronisation model

Synchronisation operator instructs earmarking and releasing of funds and assets to RTGS and the securities platform to achieve synchronised settlement. 

Wholesale functionality

In this consultation, we are interested in industry views about how new features in RTGS can meet their expectations of what a modern central bank settlement platform should offer.

We also want to hear about ways in which we need to go beyond the enhancements outlined here, and enable interoperability between different platforms (as part of your responses to Questions on priorities listed in Section 1).

Bank of England has not made any decisions about issuance of a separate wholesale CBDC. This will be taken in light of industry developments and the extent to which similar outcomes can be achieved in RTGS. We are monitoring industry experiments with interest, and keeping an open mind.

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:

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

This diagram sets out the 4 goals set across the 5 impact dimensions that make up our resilience framework for the RTGS Renewal Programme.

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

CHAPS Participants, net settlement schemes and CREST all connect to RTGS via SWIFT.  MIRS is a standby platform that is closely integrated with the SWIFT message flows.

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.

Table E: Candidate principles for Settlement Contingency

Simple. The functionality made available when Settlement Contingency is active should be kept to a minimum.

A solution which captures current balances in the simplest appropriate account structure and allows for critical payments to be settled.

Suitable. Settlement Contingency must allow settlement to continue in all extreme but plausible scenarios of varying nature, severity and duration.

High levels of independence in terms of technology and operations so that the scenarios that disrupt the RTGS service cannot also disrupt the contingency.

Resilient. Settlement Contingency must be consistent with our broader resilience objectives.

A solution that does not prevent channel agnosticism and does not introduce single points of failure in the end-to-end payments system.

Flexible. Settlement Contingency must not permanently tie the RTGS service to a specific solution.

Designing the architecture of the renewed RTGS and the interface to the Settlement Contingency so that the latter can be replaced in future.

Value for money. Our implementation and design choices for Settlement Contingency must represent value for money.

The costs associated with the solution will be outweighed by the risk mitigation that is achieved.

Easy to use. Settlement Contingency must be able to be invoked and revoked quickly, automatically, and with minimal participant impact.

A solution that is transparent and always online, either eliminating the need for a reconciliation process at the point of invocation or simplifying it as far as possible.

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:

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.



Source link

Leave a Response