Roadmap for the Real-Time Gross Settlement service beyond 2024

Consultation Response Paper
Published on 13 February 2023

Foreword

In April 2022, we issued a consultation on the roadmap for the Real-Time Gross Settlement (RTGS) service beyond 2024 (Roadmap). In the light of the rapidly changing payments landscape we were keen to understand the industry’s views on what innovative features they would like the Bank of England to focus on following the introduction of the new core RTGS settlement engine in 2024. The exciting menu of features we consulted on spanned new ways of connecting to RTGS, innovative and more flexible services and enhanced RTGS resilience.

RTGS is at the heart the UK payments industry, and through its provision of settlement in central bank money – the ultimate sterling settlement asset – is fundamental to both monetary and financial stability. RTGS now settles over £750 billion on average every working day, and in Autumn 2022 saw record peak days reaching over £1 trillion.

Our consultation marked an important milestone in shaping the long-term vision and roadmap for RTGS and realising the significant benefits that the new core settlement engine will provide. In addition to being very resilient, the new settlement engine has been designed to be modular and flexible, which will allow the Bank to introduce enhancements more quickly and easily to meet the changing needs of the industry.

Understanding the needs of RTGS users is critical when exploring and designing future RTGS services in a way that provides the desired services, promotes competition, innovation and value for money. I am very grateful to the industry for the active engagement with our work so far – we have received 34 formal responses to the written consultation and additional views through informal industry sessions.

Encouragingly, responses supported our general approach to shaping the Roadmap, and early industry engagement. Responses have given us valuable insights into high-level industry priorities – which align with our vision to facilitate safe and efficient settlement in central bank money through continuing to enhance RTGS resilience and supporting innovation and global initiatives.

I believe that it is important that close and continuous industry collaboration is at the heart of our continued evolution of RTGS after the new core settlement engine is delivered. Following the publication of this response document, we will initiate a process of industry co-creation to explore business cases for priority features: resilient channels to connect to RTGS, extended RTGS operating hours and synchronisation. These priority features – if delivered in the future – would help not only to enhance domestic payments but would also support achieving the Financial Stability Board’s roadmap for enhancing cross-border payments through making them cheaper, faster and safer globally.

Victoria Cleland, Executive Director for Payments

Executive summary

Background to the roadmap for RTGS beyond 2024

In Spring 2022, we consulted the industry on a set of ambitious and innovative features that could be implemented in the renewed Real-Time Gross Settlement (RTGS) system, once the new core settlement engine goes live in 2024. The features include new ways of connecting to RTGS, innovative and more flexible services (such as extended operating hours and synchronisation) and enhanced resilience. In the consultation, we set out a long-term vision for 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.

We received 34 formal responses from the consultation. We received additional views in a series of industry workshops held in Summer 2022. We would like to thank all involved for their active engagement with this work and their considered responses.

This document summarises the industry feedback we received and sets out our way forward for leveraging our investment in a modern and flexible RTGS service to meet the evolving needs of the UK payments industry beyond 2024.

Our vision

In the consultation, we set out a long-term vision for the renewed RTGS service beyond 2024: to act as an open platform for the UK financial services industry and to facilitate safe and efficient settlement in central bank money. The migration to ISO 20022 messaging and delivery of a new core settlement engine will give us the platform to continue to innovate. We intend to enhance the renewed RTGS service further and to introduce changes that could enable participants to offer cheaper, faster and safer payments to their customers.

Progressing the priority features set out in this Roadmap will be key to allowing us to offer the highest degree of resilience while facilitating innovation and competition in the fast-changing payments landscape.

Key takeaways and next steps

Respondents strongly welcomed the opportunity to provide early input in designing the Roadmap. Overall, they agreed that the Bank had considered the right features for RTGS beyond 2024. Respondents acknowledged the benefits that the features could bring to their organisations and the wider industry. The benefits included the potential to reduce costs for users in the long term through new ways to connect to RTGS (such as further development of the RTGS Application Programming Interface – API – platform) and innovative services (such as synchronisation, which could help reduce the current frictions in cross-border payments).

The feedback has given us a good sense of industry’s relative priorities, together with high-level views of how the features might be implemented. Next, we will conduct further work to define detailed service propositions and assess business cases before deciding which features to introduce and in what order.

Respondents emphasised the need for the Bank to continue to work collaboratively with the industry to create detailed propositions to enhance RTGS. We will respond by launching a phase of industry co-creation: establishing forums to enable stakeholders to input into high-level design of the features and inform our cost-benefit analysis. The forums will also provide input to the potential timing and sequencing of delivering priority features. Over time, these forums will also advise on any additional features that could be added to the Roadmap as we continue to support the evolving payments landscape.

Having taken industry’s feedback into account, we have decided to prioritise work on two categories of features.

Following the publication of this response document, we will develop and publish a plan for the industry co-creation work on priority features. We plan to start co-creation in 2023 Q2. We acknowledge the extremely busy change agenda in the payments landscape, so we will aim to make the process efficient and focused.

We will not actively progress the work on the remaining features listed in the consultation for the time being: more ways to generate intraday liquidity, changes to reconciling data with participants (enhanced reconciliations) and a retail contingency solution (CHAPS as a retail alternative – CARA). Respondents deemed these features lower priority because the business cases were less clear, they were less urgent or depended on introducing other features first. However, we will monitor and review the demand for these features through our ongoing industry dialogue.

1: Consultation themes

1.1: Background to the consultation

In April 2022, we issued a consultation on the Roadmap for Real-Time Gross Settlement service beyond 2024 (the Roadmap). The consultation set out an ambitious menu of innovative features that we are considering introducing in RTGS after the new core settlement engine goes live and sought industry views on which features they would like to see developed further.

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

The consultation set out three focus areas of the vision for the RTGS service beyond 2024:

  • New ways of connecting to RTGS that are cost-effective, based on open standards and compatible with a wide range of technologies. We proposed: developing a centralised RTGS identity service using PKI to support the new services; creating a new channel to send and receive payments; and/or evolving APIs.
  • Flexible and innovative services to address the changing needs of RTGS users. We sought feedback on proposals to introduce a synchronisation interface; expand RTGS operating hours; and/or create more ways to generate liquidity in RTGS.
  • World-class resilience. We noted the need to leverage new technologies to provide more usable and available back-up and contingency services. In particular, we proposed evolving or replacing our third site contingency solution (currently Market Infrastructure Resiliency Service – MIRS) to support new features, enhanced reconciliations and enabling CHAPS to act as a contingency for retail payments.

In the consultation, we asked which of the features within these focus areas the industry would prioritise to be in scope of the Roadmap and why. We also asked whether there were any additional features we should consider. To help shape our business case analysis, we consulted to understand the benefits and costs for the industry and whether organisations would be likely to use the new features.

The consultation closed on 30 June 2022. This document summarises the responses we have received (Section 2 and Annex). Building on this feedback, it sets out the plans for further work to shape the Roadmap (Section 3 and Section 4).

1.2: Features we proposed in the consultation

2: Key messages from industry feedback

We received 34 formal responses from a diverse range of organisations, comprising of large and small financial institutions, service providers, trade associations and consultants (see Chart 1). Responses included organisations who wish to expand their use of RTGS services or to provide services for RTGS in the future. In Summer 2022, we also engaged with the industry through a series of workshops to understand views in greater detail. The summaries of the workshops are published on the Bank’s website.

Chart 1: Respondents by type

Number and type of respondents to the consultation

Most responses (13) were received from large users, followed by 8 responses from small users and 8 from services providers, and finally 5 other industry actors.

2.1: General themes

Overall, the feedback acknowledged that the proposed set of features was comprehensive. Generally, respondents welcomed all the features considered and recognised the benefits that the features could bring to individual organisations and the wider industry. Respondents did not identify significant additions to the proposed scope of the Roadmap and welcomed the opportunity to input their views on designing the Roadmap at an early stage. Responses strongly encouraged the Bank to continue close co-operation with the industry moving forward.

In the consultation, we asked the industry for their thoughts about key trends that drove the need for further enhancements in RTGS and the main opportunities to improve settlement. The key themes identified are highlighted below, with further detail provided in the Annex.

While responses were overall positive about the features considered as part of the Roadmap, respondents caveated their feedback:

  • Many respondents noted they needed greater detail on the service propositions to assess business cases. Views on supporting features may change once a comprehensive cost-benefit analysis has been undertaken.
  • Several respondents expressed concern over contention with the current high level of change occurring in the industry and supported an incremental and co-ordinated approach to the Roadmap.

Respondents also called for the Roadmap to be adaptable to future changes over the short, medium and long term. This was particularly relevant for mechanisms for liquidity generation due to geopolitical uncertainties and quantitative tightening policies.

Respondents strongly supported continued close collaboration between the Bank and the industry in order to develop and shape business cases. Coupled with the detailed feedback received on each individual Roadmap feature, this has provided valuable insights for shaping our prioritisation strategy through a process of co-creation set out in Section 3.

2.2: Overview of priorities

The consultation gathered feedback on the relative prioritisation of each Roadmap feature based on the benefit it was expected to bring to organisations. Respondents scored each feature between one and seven, with one representing the lowest benefit, and seven representing the highest.

The charts below summarise the respondents’ views on prioritisation. Many respondents’ views were caveated as they noted that their assessment of priority of various features depended on completing a cost and benefit assessment.

Chart 2a: Views on feature prioritisation

Features providing the most benefit beyond 2024 (ranked by scores of 5 or higher)

Features that respondents consider as the highest priorities that would bring most benefits are: Evolving APIs, Public Key Infrastructure and settlement contingency. The lowest priorities are: extended CREST ACR mechanism, Retail contingency solution and new liquidity bridges.

Footnotes

  • Consultation question: 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? (34 responses scoring all features by selecting a score from 1 as the lowest benefit to 7 as the highest benefit.) Please note figures may not add to 100% due to rounding.

Chart 2b: Views on feature prioritisation

Net positive responses for features providing the most benefit beyond 2024

Highest net positive responses were for Evolving APIs, Settlement contingency, and Public Key Infrastructure. Retail contingency solution, CREST ACR and New liquidity bridges had net negative scores.

Footnotes

  • Consultation question: 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? (34 responses scoring all features by selecting a score between 1 and 7. Chart shows percentage difference between score 5–7 and score 1–3.)

2.2.1: Focus on resilience

Resilience-related features were often selected as the highest priorities. A reason for this provided by a large number of respondents was the interlinkages and dependencies that resilience features have with other Roadmap features.

  • Respondents supported a new channel to send and receive payments because it would reduce entry barriers for new players to foster innovation and increase resilience.
  • Some respondents noted that a common contingency messaging channel would not be required if a highly available, efficient alternative channel that can be tested with minimal manual effort is in place.
  • Respondents agreed with the drivers for maintaining a suitable contingency for settlement and the consideration of settlement contingency models beyond the third site arrangement that we currently operate. The drivers included the opportunity to remove a single point of failure within the system and the need to update settlement contingency to be available over additional payments channels.
  • Responses emphasised that Payment APIs support new services and propositions, including the delivery of a new payments channel in a reliable and efficient way. APIs have a dual benefit as they may also provide effective and efficient interfaces for other features (eg synchronisation).

2.2.2: Focus on innovation and global initiatives

Respondents also recognised the benefits that synchronisation, extended RTGS operating hours and liquidity bridges can bring to drive forwards innovation and competition. Feedback highlighted their potential in enhancing interoperability between the UK and other payment infrastructures internationally.

  • There was majority support (59% of respondents agreed or strongly agreed) for extending RTGS operating hours, with respondents acknowledging the benefits of doing so (see Section 3.2.4).
  • Some respondents who were less supportive of extended operating hours noted that they did not yet see a clear use case for their clients and highlighted the costs predominately related to the changes required to staff and technology.
  • However, most respondents considered extending RTGS operating hours to be the way forward for the future. Generally, respondents preferred a gradual transition to materially longer hours rather than a single big-bang approach if the Bank were to pursue an extension.
  • There was majority support (62% of respondents agreed or strongly agreed) for the introduction of an RTGS interface for synchronised settlement from a wide range of organisations. Synchronisation will allow a wider range of financial market infrastructures to provide innovative payment services backed by the security of settlement in central bank money. Respondents widely acknowledged the benefits of lowering liquidity costs and settlement risks associated with different types of transactions. Various use cases were deemed to be valuable, with cross-border transactions, housing purchases and complex corporate actions being mentioned as the top use cases.
  • There was a strong support for certain API use cases. Three use cases were considered important or very important by more than 60% of respondents: reconciliation, reporting analytics and additional liquidity management features. 40% or more respondents deemed the submission of payment instruction and account management use cases as important.

2.2.3: Lower priorities

Features that respondents viewed as lower priority were a retail contingency solution and more ways of generating liquidity in RTGS by using securities in CREST as collateral (CREST ACR extension). Respondents explained lower scores by the lack of clarity on business cases (in the case of retail contingency) and lower urgency (in the case of CREST ACR).

Respondents also attributed lower scores to new liquidity bridges with RTGS systems in other currencies. Such arrangements would allow RTGS account holders to use funds in other currencies to generate sterling intraday liquidity in RTGS. While a portion of respondents agreed that more liquidity bridges would be useful, they did not prioritise this feature as highly as the others. They also noted that the demand for liquidity bridges was impacted by the external environment quite significantly and could therefore change in the future. Responses highlighted the importance of ensuring a flexible approach to the Roadmap due to such changes in the future environment.

A detailed feedback summary on cross-cutting priorities and each individual feature is provided in the Annex, including a breakdown by organisation type.

3: How we are responding to the feedback

We have listened to and incorporated the industry’s feedback when planning our further work. This section sets out our approach for shaping the Roadmap.

3.1: Prioritisation approach

Continuing to listen to industry’s feedback is key so that we can deliver the features that the users of RTGS want and will be ready to use. In addition to the industry’s views on benefits, potential costs and complexity, we have considered other factors that affect the priorities for further work. They are summarised in Table A.

Table A: Factors considered when assigning priorities to features

A picture containing graphical user interface

Description automatically generated

Interdependencies

Some features are better implemented before others.

Some features are interlinked by a common strategic goal.

A picture containing text

Description automatically generated

Industry benefits

Some features entail more benefit to users.

Some features have less certain benefit cases.

A picture containing building, window

Description automatically generated

Bank priorities

Some features directly support the Bank’s core purposes of monetary and financial stability.

Graphical user interface, icon

Description automatically generated

Costs and complexity

Some features will be more expensive and complex to implement. This will be weighed against other factors in determining value for money.

A picture containing dark, light

Description automatically generated

External dependencies

The delivery of some features is closely connected to events or initiatives outside of the Bank’s control.

In practice, the features in the Roadmap were often prioritised due to combination of multiple aligning factors.

3.2: Approach for further work on the roadmap

3.2.1: Overview of priority features

The feedback to the consultation has helped us understand industry’s relative priorities and views on implementing the features as part of the Roadmap. However, we need to undertake further work to define more detailed service propositions and assess business cases before we can decide which features to introduce and in what order.

Having considered the industry’s feedback and other factors set out in Section 3.1, we have grouped the features proposed in the consultation in three categories (see Figure 1). The categories will help us structure and prioritise how we conduct further work in shaping the Roadmap. However, they do not necessarily indicate the order of priority or sequencing of how we will deliver new features, as further work and consultation will be required before the Bank can take a decision on delivery.

  • Resilient channels. The first category covers the priority features that help achieve resilience outcomes: PKI, maintaining suitable contingency for settlement and a new channel to send and receive payments (via traditional ‘messaging’ or new payment APIs).
  • Innovation and global initiatives. The second category covers priority innovative services that would be offered to the users of RTGS. It consists of synchronisation (an interface to RTGS which would allow linking RTGS with other asset ledgers and payment systems), extended RTGS operating hours and APIs to improve data transparency (Non-Payment APIs).
  • Lower priorities. The third category covers all remaining features that were listed in the consultation. Respondents deemed these features lower priority because the business cases were less clear, less urgent or dependent on introducing other features first.

Figure 1: Three categories for shaping further work on the Roadmap

From 2023, we will be focusing our assessment work on the first two categories. The decision on which features to introduce and when will be taken at a later stage, subject to developing detailed business cases, assessing costs and benefits, and seeking industry’s views.

The features considered as part of the Roadmap are not included in the RTGS/CHAPS tariff recovery approach set out in the RTGS – CHAPS Tariff Consultation Response. The Bank will consider how best to recover from the industry the costs for the proposals taken forward once we agree the scope and timing of delivering the features beyond 2024.

At this stage, we do not plan active work on the lower priorities category. However, we will monitor and review the demand for these features as part of our ongoing work with the industry.

We also asked whether the industry would like to see any other functionality added to our Roadmap, including functionality that could realise the potential benefits often associated with a wholesale CBDC (see Box A). Responses indicated a general support for prioritising the features we identified in the consultation document.

Section 3.2.3, Section 3.2.4 and Section 3.2.5 discuss the three categories in more detail.

3.2.2: Long-term vision for RTGS

Progressing the priority features is key to achieving our long-term vision for RTGS to act as an open platform for the UK financial services industry to facilitate innovation and support safe and efficient settlement in central bank money. These features would allow the Bank to offer the highest degree of resilience while facilitating innovation and competition in the payments landscape.

In the long term, we envisage that the RTGS service will:

  • Continue to meet the highest standards of resilience in the face of evolving threats.
  • Facilitate industry innovation through the provision of new flexible services, for example extending operating hours closer to 24x7 and introducing synchronised settlement.
  • Be interoperable with a range of innovative technologies (eg it would be fully API enabled). Global standardisation (due to the use of ISO 20022 messaging standard) will enable greater interoperability with other payment systems, leading to increased processing efficiency.
  • Enable access by a wide range of diverse participants and financial market infrastructures and accommodate diverse means of connecting.
  • Allow smooth and continuous further enhancements over the life of the service.

3.2.3: Resilient channels category

The resilient channels category comprises:

  • PKI;
  • Maintaining suitable contingency for settlement (third site); and
  • A new channel to send and receive payments (whether based on Payment APIs or a new message network).
Benefits

The resilient channels category is focused on enabling resilient connectivity to RTGS through alternative channels. The ability to continue to make payments and access settlement is important to financial stability, especially in periods of operational or market disruption. The benefits from improved channels are set out in Table B.

Table B: Benefits associated with the resilient channels category

A picture containing text, clipart

Description automatically generated

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

SWIFT messaging services currently represent a single point of failure for settlement as this is the only channel over which participants can submit payments to RTGS. A new channel would remove this single point of failure.

A picture containing light

Description automatically generated

Enabling innovation in settlement

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

Icon

Description automatically generated

Changing connectivity requirements

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

Icon

Description automatically generated with low confidence

Making direct participation more economical

Connectivity is a cost for new institutions seeking to join RTGS. We want to promote competition and innovation in connectivity so that costs are lowered and participants have more options.

A picture containing text

Description automatically generated

Enhancements to the third site

Improved connectivity and other enhancements that improve the usability of our contingency for settlement.

Based on the prioritisation approach (Section 3.1), there are three drivers for prioritising the features in the resilient channels category for further work.

  1. The features are industry priorities. They were identified as high priority for a substantial number of respondents. By some measures, these features had the highest overall levels of support based on expected benefits and costs, and so likely represent best value for money.
  2. Resilience is a key priority for the Bank. Safe settlement in central bank money is a key contributor to financial stability, and RTGS plays a key role in the transmission of monetary policy and the Bank’s capability to act as lender of last resort.
  3. Delivering the benefits associated with these features does not have external dependencies. The Bank and the industry will be able to set timelines with higher confidence and have higher certainty around benefits and business cases.
Further work

Detailed design and procurement of our centralised RTGS identity service

Within this category, we will prioritise the work on PKI – a centralised RTGS identity service. As set out in the consultation, our PKI will be the foundation of security in the multi-channel RTGS and is required to enable the other features in this category. Consultation responses validated this stance. Therefore, we will work to deliver PKI as the first priority feature in the Roadmap. The work in 2023 will focus on detailed design of the PKI.

Co-creation on other features in the resilient channels category

The other features in this category are highly interdependent, and we will consider the best sequencing and the best way to realise the associated benefits through the co-creation process with the industry. Section 3.4 sets out our plans for co-creation in more detail.

We will prioritise further work on this category, focusing on the best way to achieve resilient channels and designing the associated features. We will consider high-level design choices, explore business cases and evaluate delivery options.

3.2.4: Innovation and global initiatives category

This category includes:

  • Additional API functionality (Non-Payment APIs).
  • Extended RTGS operating hours.
  • Synchronisation.

Based on the prioritisation approach (Section 3.1), there are three drivers for prioritising the features in this category for further work.

  1. The features are industry priorities. A number of respondents identified them as high priority given potential benefits for their organisations.
  2. The features help support the Bank’s long-term vision for RTGS to facilitate innovation in the payments landscape. If implemented successfully, these features can enhance payments domestically and support achieving the Financial Stability Board’s (FSB’s) roadmap by enhancing cross-border payments globally.
  3. The features do not have hard dependencies on each other. However, their benefits depend on external developments and international collaboration, including in the context of the FSB’s roadmap on enhancing cross-border payments.

Respondents agreed that these features can be a powerful tool to drive innovation in the UK payments landscape and support the implementation of international initiatives such as to enhance cross-border payments (see Box B). The feedback recognised the benefits of extending RTGS operating hours, introducing synchronisation and additional Non-Payment API functionality (see below). However, given the busy industry change agenda and in some cases operational cost, respondents noted that these features need further analysis on business cases and a cost and benefit assessment.

Additional API functionality

Those APIs that support use cases outside of a new channel to send and receive payments are included in the Roadmap under the Non-Payment APIs feature. Non-Payment APIs will allow information to be extracted from the RTGS system directly and automatically by the systems of our participants and other stakeholders.

The industry’s feedback agreed that Non-Payment APIs have the benefits of facilitating innovation in payments, enabling better use of data and reducing participants’ costs (see Table C).

Table C: Benefits associated with Non-Payment APIs

A picture containing text, night sky

Description automatically generated

  • Innovation in payments services. Data transparency in RTGS can enable payment services to provide more transparency in turn to their end users.
  • Improved use of data. Participants and other stakeholders can use data for their own operational, risk management or analytical purposes.
  • Reduce participants’ costs. Existing uses of data can be automated, requiring less manual intervention and lowering burdens on operational teams.

We expect to deliver Non-Payment APIs on an ongoing basis, and the prioritisation of use cases will reflect the sequencing of the broader roadmap and how external developments shape demand. The Non-Payment API use cases that were most prioritised in the responses to the consultation were:

  • Additional liquidity management features;
  • Reconciliation; and
  • Reporting analytics.
Extended RTGS operating hours

Benefits from extended RTGS operating hours support public policy objectives. While respondents noted that further business case analysis was required, they generally agreed that extended operating hours would have the benefits of enhancing cross-border payments, improving customer experience and mitigating operational risk (see Table D).

Responses also highlighted the challenges for institutions in moving quickly closer to 24/7 operation. Respondents noted they were interested in exploring the potential future business cases though highlighted the preference in any case for a phased approach rather than a big-bang implementation.

Table D: Benefits associated with extended RTGS operating hours

A picture containing text, night sky

Description automatically generated

  • Opportunity to improve customer experiences, as extending by even a few hours could help smooth liquidity flows and could lead to increased business (flagged by smaller users).
  • Further flexibility and system interoperability. Extended operating hours could be helpful in times of UK interbank payments outages. It could also play a supporting role in providing further contingency and increased interoperability within domestic payment schemes and RTGS systems.
  • Support international work to enhance cross-border payments. Extended operating hours would reduce settlement delays caused by RTGS system closures and facilitate innovation in cross-border payments services, including through synchronisation (see below).
Synchronisation

Many respondents agreed that synchronisation would have the benefits of using central bank money to a wider range of assets (see Table E).

Table E: Benefits associated with synchronisation

A picture containing text

Description automatically generated

  • Allowing a wider range of financial market infrastructures to provide innovative settlement with risk-free central bank money. A synchronisation interface into RTGS would enable ‘atomic settlement’ between RTGS and other asset ledgers.
  • Lower liquidity costs and settlement risks associated with different types of transactions (such as housing or foreign exchange).
Dependencies relevant to this category

The features in this category can support each other (eg extending RTGS operating hours can increase opportunities for using synchronisation for cross-border payments). However, they do not have hard dependencies on each other so the delivery could be accelerated or pushed back depending on industry’s demand and capacity.

The benefits and feasibility of these features depend on several external developments:

  • Maximising benefits for some Non-Payment APIs requires co-ordinating with international payment system operators and standards bodies to achieve harmonisation.
  • The full benefits for extended RTGS operating hours would depend on whether/when operators of RTGS in other major currencies do the same.
  • The successful introduction of synchronisation requires a synchronisation operator to be in place and willing to provide the service.
Further work

We will prioritise the features in this category. We will explore business cases with the industry in more detail and will conduct further policy work on potential service propositions. More detail is provided in Section 3.4.

3.2.5: Lower priority features

This category contains features that we deemed to be lower priority, taking industry’s feedback into account. It was less clear how to realise the associated benefits of these features, they were less urgent or more dependent on introducing other features. We will periodically monitor demand for these features but have no active plans to develop them in the near-term. This group includes common contingency messaging channel, enhanced reconciliations, more ways to generate liquidity in RTGS (new liquidity bridges and CREST ACR) and a retail contingency solution.

Common contingency messaging channel

The consultation suggested introducing a common contingency messaging 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. It would be available only in situations where networking is disrupted.

While the majority of respondents supported maintaining some form of capability to submit payments in a network outage, they also noted that this contingency would need to be always on and used regularly. Therefore, many respondents indicated that having dual live channels (ie that can be used interchangeably during the course of ordinary operations) would better meet this need.

Taking this feedback into account, we will address the need for participants to have an option to connect through two live channels under the resilient channels category as a priority. However, we recognise that this solution will not necessarily be the preferred model for all participants, and so we will then review the residual need for solution that would only be used in contingency scenarios and prioritise or deprioritise accordingly.

Reconciling data with participants

We have proposed to enhance the functionality and policies of the renewed RTGS to enable improved intraday reconciliation. The respondents generally agreed this was important to support higher resilience. However, they noted that relevant changes would be most helpfully introduced after APIs have been introduced to facilitate rapid and regular exchange of reconciliation information. We will therefore postpone further detailed work on this feature until relevant APIs are implemented.

New liquidity bridges

This feature received majority support, although was seen as lower priority compared with some other features (see Section 2.2).

The Bank already has a euro liquidity bridge arrangement, which allows CHAPS Direct Participants to use their euro liquidity in TARGET2 to generate sterling intraday liquidity for CHAPS payments. Therefore, the general functionality has been built into RTGS, and technical discovery work with the industry on this feature is less relevant at this stage.

The introduction of new liquidity bridges requires other central banks and RTGS operators in relevant currencies being willing to enter into such arrangements. This topic has currently been a lower priority at international cross-border work under the Committee on Payments and Market Infrastructures (CPMI) roadmap.

For the above reasons, we concluded we can postpone active work on this feature until liquidity bridges are prioritised at international or domestic level.

Generating liquidity in RTGS using securities in CREST as collateral (CREST ACR)

We consulted on extending the current ACR mechanism so that securities in CREST could be used to generate intraday liquidity in RTGS beyond what is needed for settlement in CREST. Respondents thought this feature could be useful but less urgent compared with other functionality and may more readily be absorbed in the upcoming CREST replacement programme.

A retail contingency solution (CARA)

We have consulted on using CHAPS as a contingency for critical retail payments. Respondents deprioritised this feature mostly because they deemed the business case uncertain. They noted that the industry would need more clarity about New Payments Architecture’s (NPA’s) operational resilience approaches to assess the usefulness of a retail contingency solution.

3.2.6: Summary of next steps for each Roadmap feature

Table F summarises the next steps for each feature covered in the consultation.

Table F: Treatment of features considered in the consultation on the Roadmap for RTGS beyond 2024

Category

Feature

Stage

Next steps 2023

Resilient channels

PKI

First to be delivered within the Roadmap

Detailed design

New channel to send and receive payments

Co-creation

Identify the best sequence of the features

Payment APIs

Settlement contingency

Innovation and global initiatives

Extended RTGS operating hours

Co-creation

Business case and feasibility analysis

Synchronisation

Co-creation

Policy and design exploration

Non-Payment APIs

Continuous evolution from the current RTGS renewal

Prioritise use cases

Lower priority

Common contingency messaging channel

Deprioritise

No active work but monitor developments on an ongoing basis and review

Enhanced reconciliations

Retail contingency solution (CARA)

Extended CREST ACR

New liquidity bridges

3.2.7: How the three categories align with the focus areas of the original consultation

Our vision for the Roadmap set out in the consultation had three focus areas: new ways of connecting, innovative and flexible services and world-class resilience. The grouping of Roadmap features into three categories shown in Section 3.2 as a result of the feedback gathered through the consultation are aligned with these original focus areas. Several insights provided by respondents have resulted in some exceptions to this alignment. This is reflected in Figure 2.

Figure 2: Comparing categories for further work with three features of the vision in the consultation

New categories for prioritisation are generally aligned with the features of the vision set out in the consultation. One of the main changes is splitting evolving APIs platform into Payment APIs in the resilient channels category and non-Payment APIs in the innovation and global initiatives category.

New ways of connecting were among the most prioritised features by respondents. The main reason for this is the operational resilience benefits these features are likely to bring to organisations and the payment ecosystem. These resilience-related features (PKI, a new channel, and Payment APIs) were noted by respondents to not only be interlinked with each other, but also with maintaining a suitable contingency for settlement. This has resulted in our first grouping of Roadmap features supporting resilient channels.

Innovative and flexible services have the potential to drive forward global collaboration. Industry feedback also acknowledged these features as key initiatives to improve cross-border payments, while noting their dependency on international initiatives and work in other jurisdictions to enhance local payments infrastructure. The broad range of use cases for APIs identified by respondents has allowed this feature to be split across two groupings dependent on use: resilient channels and innovation and global initiatives.

World-class resilience was strongly supported as a priority by the industry. However, there was a majority view that other Roadmap features provided resiliency benefits ahead of enhanced reconciliations and a retail contingency solution (CARA). While the benefits of these features were acknowledged by respondents, they presented lower urgency and greater uncertainty over the strength of their business cases. In addition, respondents expressed the view that a new channel to send and receive payments in itself offered a form of contingency messaging channel. This has resulted in the grouping of lower priority features.

3.2.8: Harnessing the benefits of richer payments data in CHAPS

In parallel to progressing the work on the Roadmap, the Bank is also working to implement ISO 20022 global standard for payments messaging. The stages for this work are detailed on the Bank’s ISO 20022 webpage.

The Bank continues to work with CHAPS Direct Participants and the wider payments community on how the UK payments industry will benefit from the greater flexibility of the standard, the wider enhancements to resilience resulting from message interoperability with other infrastructures, and through the structured use of ISO 20022 enhanced data, eg purpose codes and legal entity identifiers. We expect that a consistent approach for using structured enhanced data will enable key benefits, such as faster straight-through processing, greater information and analysis capabilities, and fraud prevention.

In order to drive these benefits, from November 2024, the Bank will start mandating the usage of certain enhanced data – please refer to our webpage for more detail. In terms of the end-user experience, the Bank is mandating enhanced data only where it deems the benefits outweigh the challenges posed by delivering such data.

The Bank continues to work closely with domestic and international colleagues (including Pay.UK, as operator of the future NPA) on the ISO 20022 implementation, to ensure alignment where appropriate and to define a clear change/maintenance cycle to updates to ISO 20022 messaging.

3.3: Co-creation approach

Close collaboration between the Bank and the industry is essential when shaping and delivering the Roadmap features to ensure value for money. We will establish industry co-creation forums to advise the Bank on business cases, speed and sequencing of priority features in the Roadmap. We will consider the views of these forums alongside public policy considerations and other factors set out in Section 3.1 when taking decisions on delivering the Roadmap.

3.3.1: Objectives of co-creation

The objectives of the co-creation process are to obtain industry steers on:

  • Strategic shaping of the Roadmap features. This includes providing input on which features should be delivered and how they should be sequenced, taking into account any dependencies, the wider industry change agenda and outcomes of further work on individual features. We will obtain cross-feature steers via a strategic engagement forum, consisting of strategic-level stakeholders from a diverse range of current and future users. The co-creation process will also consider when there is the right time to review the treatment of the features in the lower priorities category (eg to start active work on them or to remove them from the backlog of features to consider).
  • Developing individual features in priority categories. This includes advising on service design options, conducting cost and benefit assessment and helping to shape policy on each priority feature. We will invite engagement on specific features via thematic working groups.

Initially, the co-creation process will focus on the priority features:

  • Resilient channels category (maintaining a suitable contingency for settlement and a new channel to send and receive payments, including Payment APIs). The work on centralised RTGS identity service will not be part of co-creation;
  • Extended RTGS operating hours; and
  • Synchronisation.

Over time, industry co-creation will also invite suggestions on any potential new additions to the Roadmap. Co-creation forums will advise on whether such features are worth considering and if so, how they should be prioritised in the context of the other features we are developing.

Section 3.4 describes the approach for priority features in more detail.

3.3.2: Principles for designing the co-creation process

We are aware of the potential bandwidth issues for the industry to participate in the co-creation process at a time of rapid change in the payments landscape (including Transition State 3 of the RTGS Renewal Programme and the NPA in addition to global change). We will aim to address this by keeping the co-creation sessions focused. We will also use the sessions to gather more insight about likely implementation resourcing constraints. We recognise that we may need to review timings if other industry milestones change.

While the detailed approaches will need to be tailored to the key topics and will take further consideration, we have set out some common principles to obtain effective inputs while minimising the burden to the industry.

  • Focused. We will form carefully targetter working groups to tackle a set of specific priority questions.
  • Representative. We will seek to ensure diverse representation of a range of current and potential future users of RTGS.
  • Transparent. We will communicate regularly with a wide group of industry stakeholders (including those who may not directly participate in working groups). We will invite (but not require) wider input on a ‘little and often’ basis.
  • Accountable. We will publish the summary of the analysis and advice developed as part of co-creation working groups. We will invite wider industry scrutiny and views before we take decisions on new features.

3.4: Co-creation work plan on priority features

The co-creation efforts from 2023 will initially focus on the two priority categories: resilient channels category and innovation and global initiatives category.

3.4.1: Resilient channels category

These features share the common theme of removing a single point of failure from the ecosystem while creating new opportunities for innovation in networking infrastructure (see Figure 3). This will be enabled by changing the way payment messages are transmitted, from the current ‘Y-Copy’ mode, which is optimised for use within the SWIFT network, to ‘V-Shape’ which allows messages to be sent across multiple networks.

Figure 3: Benefits of features in resilient channels category

A move to a 'V shape' with PKI would have the benefit of end-to-end signing enhancing security. Updated settlement contingency would have the benefits associated with selected model. A launch of a new channel would remove networking single of failure and would have benefits associated with competition and innovation.

We will work with the industry to identify the best sequence of features in this category to deliver the primary strategic outcome of removing the single point of failure in networking. This will require collaboration on developing more detailed assessments of the design choices that can be made in developing a new channel to send and receive payments and maintaining suitable contingency for settlement.

Key areas for focus in co-creation

  • Weighing the case for seeking to connect an additional message network for RTGS/CHAPS against the case for the Bank directly providing payments via API functionality. This will include security and resilience considerations, as well as potential benefits to innovation and competition.
  • Assessing whether maintaining dual channel connectivity would be mandatory, optional or tiered.
  • Analysing the business case across all stakeholders (costs/benefits) for changing the high-level architecture for the settlement contingency system, or for making improvements within the existing architecture. This would include assessing the benefits and industry impact of the identified models.
  • Analysing the possible delivery sequences for the technical changes that will be required to support the features in this category (‘V-shape’ network topology; changes to settlement contingency; connecting another message network; and enabling payments via APIs).
  • Providing inputs to the Bank’s assessment of the choices associated with this category from a value-for-money perspective.

3.4.2: Innovation and global initiatives category

Non-Payment APIs

Responses indicated that a collaborative approach to the implementation of APIs was key to maximising benefits. A key step in this approach will be to harmonise API standards as far as practical both domestically and internationally.

The Bank and Pay.UK are working closely with industry through the Standards Advisory Panel to propose a framework for the domestic harmonisation of API technical standards in payments and will consult the industry on a proposal soon. More broadly, the Bank is contributing to the international work to harmonise API protocols for data exchange as part of the G20 Roadmap for enhancing cross-border payments.

Key areas for focus in co-creation

The Bank is already collaborating closely with industry regarding the implementation of APIs through the RTGS Renewal Programme. This work will continue in the near term with a focus on APIs that will be introduced before the future Roadmap.

Once the Renewal Programme has concluded, this collaboration will continue as part of our co-creation process and the focus will be:

  • Monitoring and updating the sequence of further use cases that will receive API support;
  • Identifying and working through harmonisation issues; and
  • Shaping our long-term vision for all RTGS interactions to be available through APIs.
Extended RTGS operating hours

We will work with the industry during 2023 to identify the business cases and feasibility of potential extensions, analyse the preferred end-state operating hours and consider how to address any potential challenges and risks of implementation.

A CPMI report published in May 2022 identifies potential future end-states for extending RTGS operating hours alongside the risks, policy considerations and potential mitigating actions for jurisdictions to consider. It encourages central banks to work with stakeholders to review domestic operating hours in a strategic light, considering the long-term impact domestically and internationally for the whole payments ecosystem. By using the CPMI’s framework and continuing to engage with our international partners, we hope to maximise alignment and facilitate the greatest benefits from extending operating hours.

Key areas for focus in co-creation

  • Analysing the business case (costs/benefits) across all stakeholders for extended operating hours to different end-states and identifying which is the most suitable in the UK. We will assess three ‘end-states’ considered by the CPMI report:
    • Extend on current operating days;
    • Extend on current non-operating days; and
    • Extend to near 24x7.
  • Investigating what changes would be needed by participants and their customers (eg to policies, processes, technology, staffing) to implement a new end-state and defining a path and timeline to getting there.
  • Considering whether some elements of extended operating hours could be made optional for participants.
Synchronisation

As part of the RTGS Renewal Programme, we have engaged widely with stakeholders on synchronisation via a Call for Interest and industry workshops. Building on the work in the previous years, we have been working with BIS Innovation Hub London Centre and a consortium of private sector collaborators to explore synchronisation functionality since Spring 2022. Project Meridian will develop a technology prototype that can suitably co-ordinate transactions across multiple ledgers. It will give us practical insights on what information exchange would look like between settlement parties and earmarking and triggering of funds at RTGS. Project Meridian will complete in Spring 2023.

Taking into account the findings from Project Meridian, we will explore further policy and design questions relating to the practical implementation of synchronisation functionality in RTGS. This could take a form of a working level policy sandbox, consisting of different settlement parties including potential operators, RTGS account holders and asset ledgers.

Key areas for focus in co-creation

  • Defining in more detail the relationships and responsibilities between the operators, the settlement participants, the asset ledgers and the Bank. This includes the level of control that participants would have over the earmarking of their funds used for settlement in RTGS.
  • Identifying earmarking protocols, eg timing and length of earmarking and any potential limits to earmarks.
  • Exploring policy frameworks for synchronisation operators’ access to RTGS, eg what regulatory and supervisory requirements potential operators would need to meet.
  • Analysing the business case for potential operators to provide synchronisation services and for industry to use the services. This would include assessing the benefits and industry impact of the identified models.

Once we have answered the key questions and if we decide to deliver the synchronisation functionality, we will develop and publish eligibility criteria for becoming a synchronisation operator so that potential operators can prepare and apply to become one. This could be done in parallel with the technical development of the synchronisation interface into RTGS.

Box A: Wholesale central bank digital currency

In the consultation we outlined that the objective of modernising the RTGS service is to offer a more accessible, functional and resilient platform for digital settlement in central bank money.

The Bank has been actively exploring the case for issuing a new form of money in the form of a retail central bank digital currency (rCBDC) and has issued a consultation paper on the digital pound. Some market participants have called for a wholesale version (wCBDC), which would not be a new form of digital money (at present, the Bank enables digital wholesale settlement through CHAPS and its RTGS service) but instead would represent the application of new technologies to improve wholesale settlement in central bank money by making it faster, safer and more transparent.

There are a number of benefits that are commonly cited as motivations for a wCBDC.

  • Transparency: using modern data interfaces and automation to allow financial firms and end users to be informed in real time about the status of payments and reach consensus for transactions to proceed.
  • Availability: providing reliable settlement services on a 24x7 basis.
  • Efficiency: minimising frictions in delivery of wholesale settlement.
  • Atomicity: complex transactions can be made safer and more efficient by co-ordinating movements of assets and funds across different ledgers.
  • Access: expanding the use of central bank money for settlement, both by increasing uptake among already-eligible institutions and by extending eligibility to more types of institutions.

The Bank has already engaged in various Proofs of Concept and experiments exploring these ideas. Topics covered by these exercises have included:

  • Distributed Ledger Technology (DLT) Proof of Concept: a project to explore and demonstrate basic functions of wholesale settlement using DLT.footnote [1] We built on this work via a second exercise working with Baton Systems, Clearmatics Technologies Ltd, R3 and Token to ensure our renewed RTGS service could connect with systems based on DLT and other innovative technologies.footnote [2]
  • Cross-border synchronisation: a joint project with Ripple demonstrating that synchronised FX transactions in two different simulated RTGS systems can be achieved, leading to the incorporation of synchronisation functionality into the roadmap for RTGS renewal.footnote [3]

Building upon this collaboration with the industry, the Bank has developed new policies and structures to enable the benefits of innovative technologies to be delivered by new types of private sector firms.

Through the RTGS Renewal Programme, the Bank is in a position to realise a number of benefits commonly associated with wCBDC more quickly than it would be possible to launch an entirely new wholesale settlement platform and achieve scale in its usage. These include:

  • In 2021, the Bank launched the Omnibus Account model, which allows a greater range of innovative payment services to benefit from settling in central bank money.
  • The Bank will increase the transparency, efficiency and speed of information exchange through adopting the ISO 20022 standard and through the provision of APIs, and plans to expand the range of available APIs over time to meet user needs.
  • The Roadmap for RTGS beyond 2024 (this document) sets out proposals around:

We invited challenge on our view that we should focus on delivering these benefits through the enhancement of our existing infrastructure in the consultation. We did not receive substantive contest on this approach and received broadly positive responses to the innovative RTGS features outlined above.

We view the consultation feedback received as endorsing the Bank’s near-term focus on providing enhanced wCBDC functionality via RTGS. However, it does not preclude the Bank from continuing to track the findings of other central banks in exploring the merits of creating a separate wCBDC platform.

Box B: Supporting improved cross-border payments

The G20 has made enhancing cross-border payments a priority and agreed ambitious quantitative targets for the speed, cost, accessibility, and transparency of these payments. The targets mostly apply from 2027. To achieve them, central banks, other public authorities and the payments industry need to take decisive action to tackle the frictions in cross-border payments. Some of the features considered for RTGS beyond 2024, such as longer operating hours, could make an important contribution.

It is estimated that in 2022 the aggregate value of global cross-border payment market will have exceeded US$150 trillion, and the importance of cross-border payments is expected to grow further. Yet cross-border payments infrastructure and service levels have not kept pace with the changing world and domestic progress. Faster, cheaper, more transparent and more inclusive cross-border payment services would deliver widespread benefits for citizens and economies worldwide, supporting economic growth, international trade, global development and financial inclusion.

Since 2020, work on cross-border payments has been organised around an international roadmap comprised of 19 building blocks. The CPMI, FSB and other international bodies have largely completed the stocktaking and analysis stage of this roadmap, and published guidance and recommendations in several areas, including RTGS operating hours.

The next stage of the international roadmap will focus on implementation of the guidance and recommendations, through practical projects to enhance cross-border payments. This includes prioritising initiatives that will make the largest contribution to achieving the G20 targets by 2027 and will inform future work in three priority areas:

  • Payment system interoperability and extension including possible extensions to RTGS operating hours as well as expanded access and options for interlinking domestic payment systems;
  • Legal, regulatory and supervisory framework including options for improving alignment in national requirements for combatting financial crime; and
  • Cross-border data exchange and message standards including internationally harmonised adoption of ISO 20022 payment messages and regulatory restrictions on transferring personal payment data across borders.

Enhancing cross-border payments requires close public-private collaboration. To this end, the FSB and CPMI intend to establish in 2023 Q1 two new industry taskforces to facilitate regular engagement between public authorities and senior representatives from the payments industry.

In parallel, the FSB and CPMI are working with the International Monetary Fund and World Bank to strengthen the technical assistance available to non-G20 jurisdictions as they seek to implement the guidelines and recommendations emerging from the international roadmap.

The Bank strongly supports the G20 cross-border payments programme. The approach for the way forward outlined in this response document – in particular through the innovation and global initiatives category – reflects the important interlinkages between international work on cross-border payments and the Roadmap for RTGS beyond 2024. The Bank will continue to (i) feed into and drive international work, including by sharing ideas and lessons from our RTGS Renewal Programme, and (ii) consider and utilise the helpful outputs of the international work to shape domestic initiatives such as the potential transition to longer RTGS operating hours after 2024.

4: Next steps

We will work on the centralised RTGS identity service (PKI) as the first priority of the Roadmap, focusing on detailed design and procurement. We anticipate that the earliest we could implement PKI is around six months after the delivery of the core settlement engine in 2024.

As per the approach for further work outlined in Section 3.4, we will be setting out a plan for co-creation with the industry. We will look to identify diverse industry representation for co-creation forums reusing existing structures where possible. We intend to start working actively with those industry representatives on co-creation topics from 2023 Q2.

We expect this phase of co-creation to run from 2023 Q2 until early 2024. We will then take stock of the findings and, considering costs and benefits of various features, take a decision on moving propositions to delivery at an appropriate time. Depending on the impact and complexity of various features, we will consider delivering features in parallel.

After the initial co-creation work, we will be monitoring industry developments and reviewing priorities (as part of the cross-cutting strategic industry forum and a wider industry engagement) on an ongoing basis.

In parallel to co-creation, we will continue working on other priorities, such as ISO 20022 and API implementation and further development of our resilience framework.

Annex: detailed consultation feedback summary

The Annex summarises detailed industry feedback we received. Section A1 sets out organisation categories we used. Section A2 covers market trends and overview of cross-cutting priorities across all features. Section A3 provides a summary of responses on individual features.

A1: Respondents by organisation type

We received 34 official responses from a diverse range of organisations. To allow for comparison across different organisation types, we grouped respondents into the following categories:

  • Large user (13 respondents). Respondents are a CHAPS Direct Participant with either a heavy UK focus or an international bank. This category also includes financial market infrastructures.
  • Small user (8 respondents). Respondents are indirect participants with RTGS and include banks, building societies and non-bank payment service providers.
  • Service provider (8 respondents). Respondents provide services to RTGS and/or RTGS account holders. Four of these respondents wish to expand their service provision in capacities including as synchronisation operators and payment system operators.
  • Other industry actors (5 respondents). Respondents include consultants, trade associations, and Government banking.

Further sections of the Annex refer to these categories to flag any differences in views dependent on business models and organisation types.

A2: Our vision and roadmap for RTGS beyond 2024

A2.1: General trends

A2.1.1: Important trends driving the need for further enhancements to settlement in RTGS

We asked the industry about general trends in the payments landscape driving the need for enhancements in RTGS (see Table A2.1). The majority of respondents selected increased focus on operational resilience and innovation in payment technology as the main drivers of change.

Respondents commented that strong resilience was necessary for:

  • Consistent data exchange and real-time information access;
  • Delivery of market products that meet growing client expectations, for example network speeds, end-to-end transparency of transaction flows and ‘always-on’ capabilities; and
  • Rising need for early detection of problems as cyber-threats increase.

Many respondents highlighted the links between innovation and increasing international collaboration leading to more efficient cross-border payments and increased flexibility. Several respondents called attention to providing easier access to RTGS in the context of the increasing competition in the UK payments market.

Overall, respondents agreed that the trends identified by the Bank captured the key challenges and opportunities within the industry. They acknowledged the dynamic nature of the payments landscape and noted that the Roadmap would need to be adaptive to change.

Table A2.1: Responses to question: In your view, what are the most important trends driving the need for further enhancements to settlement in RTGS? (Percentage out of 34 respondents)

Key trends

Per cent

Increased focus on operational resilience

59

Innovation in payments technology and business models (eg increasing use of cloud technology, API usage)

59

Increasing international collaboration and growing cross-border business opportunities, including increasing global focus on enhancing cross-border payments

56

Growing demand for a digital economy (including increased global focus on exploring central bank digital currency, moving from cash to digital payments, emergence of stablecoins)

41

New solutions for settlement (including industry collaboration to solve inefficiencies in securities settlement, trade finance, cross-border settlement)

38

More competitive UK payments market

32

A2.1.2: Key opportunities to improve efficiency of settlement in central bank money

We asked respondents to identify key opportunities to improve the efficiency of settlement in central bank money in the UK.

  • A large proportion of respondents underlined extended RTGS operating hours as bringing the most benefit for cross-border payments.
  • Respondents mentioned the introduction of ISO 20022 messaging standard.
  • Several respondents also acknowledged the improvements to the efficiency of settlement that will be realised through change delivered in the RTGS Renewal Programme. These include enhanced Liquidity Saving Mechanism and the introduction of APIs in Transition State 3 with the new core settlement engine.

Feedback also noted that settlement efficiency can be achieved by the automation of processes and transactions to the greatest possible extent, and through the establishment of new infrastructures such as synchronised settlement.

A2.1.3: Payments with the highest potential for improvement

We asked which types of payments have the highest potential for improvement. Chart A2.1 shows the summary of responses categorised by organisation type. Across all respondents, cross-border payments were deemed to have the greatest potential for improvement. Smaller RTGS users also proportionately favoured property transactions. This was because such payments make up a large portion of business for many small users and have visible benefits for end customers.

Large users placed greater weighting on money market transactions out of all respondents. These organisations noted that improving money market transactions has increased in priority in current monetary policy environments globally. These respondents also noted potential future disparity between these environments, which could cause dislocation in cross-currency demand.

Chart A2.1: Views on general market trends

Payment types identified with the highest potential for future improvement

Respondents indicated that payment types with the highest potential for future improvements were (in descending order of potential): Cross-border payments, Property transactions and Money market transactions.

Footnotes

  • Consultation question: Which type of payments have the highest potential for improvement? (34 responses.)

A2.2: Views on relative priorities

A2.2.1: General views on Roadmap features

To help us prioritise, we asked respondents about which features would bring the most benefit beyond 2024.

While feedback was generally positive across all features, many respondents caveated their responses on priorities. They noted that detailed business case assessments would be required to obtain a clearer view on benefits to their organisation and the industry as a whole.

Some respondents expressed concern of the cost of Roadmap features and required further detail to feed into business cases and cost-benefit analyses. Many responses stressed the importance of ensuring alignment with other industry change beyond 2024.

A2.2.2: Features bringing the most benefit to organisations beyond 2024

When asking which features would bring the most benefit beyond 2024, respondents scored each feature from one to seven, with one being the lowest priority and seven being the highest priority. Chart A2.2 shows the average score for each feature, highlighting proposals with the greatest levels of support across all respondents.

Chart A2.2: Views on feature prioritisation

Features providing the most benefit beyond 2024 by average score

Respondents indicated that the features providing the most benefit beyond 2024 were Settlement contingency, Evolving APIs and Public Key Infrastructure. Retail contingency solution and extending CREST ACR were deemed as providing the least benefit.

Footnotes

  • Consultation question: 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? (34 responses scoring all features. Chart shows average score.)

Maintaining a suitable contingency for settlement, a new channel to send and receive payments, APIs and PKI received the highest average scores, suggesting these features would bring the greatest benefit to organisations beyond 2024. Respondents emphasised the operational resilience benefits of these features for a range of business models and stressed that ensuring secure connectivity across wider direct participation would support faster and more cost-effective payments. These features also showed the least dispersion across different organisation types.

Key differences among types of organisations

Chart A2.3 below shows how priorities differed across organisation types by providing a breakdown of average score for each feature based on respondent category. The most common reason provided as to why views on priorities differed was that certain features are likely to provide more benefit for certain business models or may not be applicable to others.

The key differences across organisation types included:

  • Generally, small users favoured extended RTGS operating hours to help increase the efficiency of cross-border payments. While these benefits were also supported by larger users, lowering the cost of cross-border payments was a greater driver for prioritisation for smaller firms.
  • Smaller users preferred a new channel to send and receive payments over a common contingency messaging channel. They noted the current cost burden of a single method of connection as a key driver for a new channel.
  • In comparison, large users gave higher priority to a common contingency messaging channel when compared to a new channel to send and receive payments. This was due to a focus on increasing resilience rather than a business need for an alternative method of connection.
  • Service providers and other industry actors acknowledged the importance of PKI in enabling the secure implementation and use of other Roadmap features. This benefit was also supported across other types of respondents.
  • Synchronisation was also given the highest average score by service providers, particularly due to expressions of interest in providing services related to synchronised settlement.
  • While large users placed lower benefit on enhanced reconciliations due to intraday reconciliations already being in place, this feature was supported more so by small users and service providers to provide efficiencies for internal processes.

Chart A2.3: Views on feature prioritisation

Features providing the most benefit beyond 2024, by respondent type

Respondents indicated that the features that would bring the most benefit to their organisations beyond 2024 were Settlement contingency, Evolving APIs and Public key Infrastructure.

Footnotes

  • Consultation question: 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? (34 responses scoring all features, split by respondent category (see Section A1). Chart shows average score.)

Overall respondents across different groups deemed a retail contingency solution (CARA) and generating liquidity using securities in CREST as collateral (CREST ACR) as the lowest priority. Respondents noted that CARA does not have a use case for organisations who do not have retail traffic. Two respondents also voiced a concern over the potential cost and risk of interoperability complexities weighted against limited apparent benefits at present.

A2.2.3: Features chosen to deprioritise for beyond 2024

We asked which features (selection of up to three) the respondents would deprioritise (see Chart A2.4). As in the previous question, a retail contingency solution and CREST ACR were mostly identified as features that could be deprioritised.

Some respondents also deprioritised a new channel to send and receive payments and a common contingency messaging channel, referring to the cost of maintaining multiple networks with different connectivity. However, some respondents noted that technologies, including APIs, could be leveraged to significantly reduce the cost of implementation and use of a new channel.

Overall, respondents deprioritised features which they thought provided little benefit or were not applicable to their business models. However, some respondents acknowledged that features could be delivered for the benefit of the industry as a whole even if they were not directly relevant for their organisations.

Chart A2.4: Views on feature prioritisation

Features chosen to deprioritise for beyond 2024

Most respondents chose retail contingency solution and extended CREST ACR as features that could be deprioritised.

Footnotes

  • Consultation question: If you had to choose to deprioritise up to three of the features outlined in this consultation, what would they be? (34 responses selecting up to three options.)
A2.2.4: Additional features to introduce as part of the Roadmap

We asked for views on any additional features that the Bank should introduce as part of the Roadmap for RTGS that are not outlined in the consultation.

The majority of respondents agreed that the list of features was comprehensive. A few respondents suggested considering adding fraud and economic crime prevention functionalities in collaboration with the industry. The Bank is already progressing work in these areas via other existing work streams.

A3: Feedback on individual features

This section summarises the feedback on individual features. For consistency and comparison with the consultation document, we have maintained the structure and grouping of features as in the consultation. Section 3.2.7 of this document explains how the three features of the vision in the consultation map with the new categories for further work set out in this document.

For several features, we asked about the industry’s assessment of cost and complexity to organisations for using and/or maintaining such a feature. These questions used the following parameters as indicators.

Unfeasible/too high: you do not expect the project to be feasible for your organisation

High: project requires at least one of: cost exceeding £10 million; more than 50 full-time employees (FTE) staff/contractors required at project peak; substantial changes required to many systems.

Medium: project requires at least one of: cost exceeding £1 million–£5 million; more than 10 FTE staff/contractors required at project peak; substantial changes required to at least one system or changes required to many systems.

Low: project would need to be stood up but does not meet any of the medium criteria.

Business as usual (BAU): project cost can be incorporated into BAU/cost and complexity is negligible for your organisation.

A3.1: New ways to connect to RTGS

A3.1.1: A new channel to send and receive payments

Currently, the only way to access RTGS is via the SWIFT network. The consultation proposed creating a new channel to connect to RTGS and to send and receive payment instructions. We asked the industry about their support for the introduction of such channels and about the benefits, cost and complexity of their implementation.

Support for a new channel to send and receive payments

  • The majority (56%) of respondents supported the introduction of alternative channels, with stronger support from large current users.
  • Respondents across different organisation types noted the benefits that this feature would have in:
    • Reducing single point of failure and
    • Increasing opportunities for innovation and competition.

Chart A3.1: New ways to connect to RTGS

Support for introducing a new channel to send and receive payments

Majority of respondents agreed or strongly agreed with introducing a new channel. 38% were neutral.

Footnotes

  • Consultation question: Do you agree that RTGS should introduce an alternative channel to send and receive payments? (34 responses.) Please note figures may not add to 100% due to rounding.

Cost and complexity of adopting and using a new channel

  • Cost perception varied across organisation types. Small users estimated the implementation cost to be higher than large users, with some expressing concern that maintaining dual connectivity would be too burdensome. Other users pointed to the resiliency benefits that could be realised with a sufficiently wide range of participants maintaining a new channel.
  • Many respondents caveated their responses, indicating the need for more details on what type of organisations will be mandated to maintain a new channel, as well as design and implementation plans.

Chart A3.2: New ways to connect to RTGS

Views on cost and complexity for adopting and using a new channel

Most respondents indicated that the level of cost and complexity of adopting and using a new channel was medium or high.

Footnotes

  • Consultation question: How would you assess the complexity and cost to your organisation from (a) adopting V-shaped networking and (b) using an alternative channel? (24 responses.)

Policy and design considerations for a new channel

  • A wide range of respondents emphasised that a new channel needs to be based on open standards and consistent with existent architectural principles and rulebooks. It should have the same level of service (eg resilience, security, and end-to-end) as SWIFT.
  • There was a strong desire for the layered approach to the optionality a new channel, ie respondents suggested that it could be made mandatory for large participants and optional for the smaller ones.

Implementation timing for introducing a new channel

  • Implementation after 2026 was strongly preferred due to expected budget constraints.
  • One respondent raised potential synergies that could materialise if an alternative channel was implemented in parallel with the delivery of NPA.

Consultation questions

Consultation question

Respondents

Answers

Do you agree that RTGS should introduce an alternative channel to send and receive payments?

34

Strongly agree: 26%

Agree: 29%

Neutral: 38%

Disagree: 3%

Strongly disagree: 3%

Do you expect your organisation to use an alternative channel?

34

Yes: 47%

No: 29%

Not applicable: 24%

How would you assess the complexity and cost to your organisation from:

a) adopting V-shaped networking?

24

Unfeasible/too high: 4%

High: 17%

Medium: 54%

Low: 17%

Business as usual: 8%

b) using an alternative channel?

22

Unfeasible/too high: 14%

High: 27%

Medium: 41%

Low: 14%

Business as usual: 5%

In your estimation how long might it take your organisation to implement an alternative channel?

24

>24 months: 17%

19–24 months: 38%

13–18 months: 17%

7–12 months: 8%

1–6 months: 21%

A3.1.2: Common contingency messaging channel

We asked the industry for views on whether we should provide a contingency network 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.

Support for a common contingency messaging channel

  • Over half of all respondents supported the introduction of this feature, acknowledging its benefits for enhanced resilience.
  • However, many respondents caveated their responses by noting the key trade-off between high levels of resilience and increasing costs. Therefore, respondents required further details for cost-benefit analyses for this feature (similarly across all features) in order to comment further on whether the investment is justified.

Chart A3.3: Common contingency messaging channel

Support for introducing a common contingency messaging channel

Majority of respondents strongly agreed or agreed with introducing a contingency messaging channel. 32% were neutral.

Footnotes

  • Consultation question: Do you agree that RTGS should implement a contingency messaging channel in the event of an outage of the primary network? (34 responses.)

Policy and design considerations for a common contingency messaging channel

  • Feedback highlighted that any contingency messaging channel should be trustworthy, functional as well as easy and quick to switch over. In addition, several respondents suggested that this should be consistent with the format and standards of primary channels to facilitate continued seamless integration into participants’ internal processing infrastructures.
  • A number of respondents noted the risk of creating this solution for it to subsequently be seldom used and costly to maintain.
  • A few respondents indicated that having dual primary connectivity for payments would also work as a contingency, instead of introducing a contingency solution per se.

Consultation questions

Consultation question

Respondents

Answers

Do you agree that RTGS should implement a contingency messaging channel in the event of an outage of the primary network?

34

Strongly agree: 24%

Agree: 32%

Neutral: 32%

Disagree: 6%

Strongly disagree: 6%

In your estimation how long might it take your organisation to implement a contingency messaging channel?

24

1–6 months: 25%

7–12 months: 13%

13–18 months: 17%

19–24 months: 29%

>24 months: 17%

A3.1.3: Centralised RTGS identity service

We will deliver a centralised RTGS identity service (PKI) to support the future security model. In the consultation, we asked the industry if they agree with the following design principles for the development of the Bank’s PKI.

  • 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.

We also consulted on the possibility of making the Bank’s PKI available to other payment systems.

Design principles for the development of the Bank of England’s PKI

  • Approximately two thirds of respondents agreed with each design principle for the development of PKI.
  • Respondents assigned upmost importance to security and expressed strong preference for being agnostic to cloud or on premise structures.
  • 65% of the respondents agreed that the Bank’s PKI should be available to other payment systems. A few respondents noted that greater benefits could be achieved in the case of sharing the PKI with Pay.UK.
  • Many respondents recommended that the Bank follow established and international standards in the development of PKI.

Chart A3.4: Centralised RTGS identity service

Support for design principles of the Bank of England’s PKI

Majority of respondents strongly agreed or agreed with all design principles for Public Key Infrastructure.

Footnotes

  • Consultation question: To what extent do you agree with the proposed design principles for the development of the Bank of England’s PKI? (34 responses.) Please note figures may not add to 100% due to rounding.

Consultation questions (34 responses)

Consultation question

Answers

To what extent do you agree with the proposed design principles for the development of the Bank’s PKI?

a) Security

Strongly agree: 50%

Agree: 29%

Neutral: 21%

Disagree: 0%

Strongly disagree: 0%

b) Cost effectiveness

Strongly agree: 44%

Agree: 32%

Neutral: 21%

Disagree: 0%

Strongly disagree: 3%

c) Flexibility

Strongly agree: 35%

Agree: 38%

Neutral: 24%

Disagree: 3%

Strongly disagree: 0%

d) Openness

Strongly agree: 35%

Agree: 38%

Neutral: 26%

Disagree: 0%

Strongly disagree: 0%

Do you agree that our PKI credentials should be available to other payment systems?

Strongly agree: 21%

Agree: 44%

Neutral: 32%

Disagree: 3%

Strongly disagree: 0%

A3.1.4: Automating data transfers with RTGS via APIs

In the consultation, we proposed to continue introducing new APIs based on industry demand and evolving our ecosystem. The consultation invited views on automating data transfers with RTGS via APIs and any use cases.

Development of RTGS API platform

  • Overall, respondents expressed support for the introduction of APIs. This feature was particularly supported by e-money institutions.
  • Respondents acknowledged the benefits that APIs could bring, namely unlocking innovation, cost and operational efficiencies, ease of customisation and adaptation.
  • Some respondents noted that in order to fully realise the benefits of APIs, users would need to be able to execute all core functions via APIs.
  • There was strong emphasis amongst respondents on ensuring high levels of security for RTGS APIs. Respondents recommended the use of standards and architectures that are already widely adopted in the industry.
  • Respondents supported a collaborative approach between a wide range of participants and vendors to co-develop the APIs functionalities.

Prioritised use cases for RTGS APIs beyond 2024

  • The most important use cases selected by respondents were reconciliation (65%), liquidity management (58%) and reporting analytics (58%).
  • Feedback also provided additional use cases including financial crime prevention (eg Anti-Money Laundering), data sharing in the payments journey, request and authorisation of settlement execution, and real-time monitoring.

Chart A3.5: Evolving API Platform

Prioritised use cases for RTGS APIs beyond 2024

Respondents indicated that the most important use cases for RTGS APIs beyond 2024 were Reconciliation, Reporting analytics and Additional liquidity management features.

Footnotes

  • Consultation question: How important are each of the additional use cases in terms of their prioritisation for addition beyond 2024? (30 responses.) Please note figures may not add to 100% due to rounding.

Consultation questions (30 responses)

Consultation question

Answers

How important are each of the additional use cases in terms of their prioritisation for addition beyond 2024?

a) Additional liquidity management features

Very important: 20%

Important: 40%

Neutral: 37%

Unimportant: 3%

Very unimportant: 0%

b) Reporting and analytics

Very important: 20%

Important: 40%

Neutral: 40%

Unimportant: 0%

Very unimportant: 0%

c) Management of network preference

Very important: 3%

Important: 27%

Neutral: 63%

Unimportant: 7%

Very unimportant: 0%

d) Submission of payment instructions

Very important: 27%

Important: 17%

Neutral: 57%

Unimportant: 0%

Very unimportant: 0%

e) Account management

Very important: 13%

Important: 27%

Neutral: 60%

Unimportant: 0%

Very unimportant: 0%

f) Reconciliation

Very important: 23%

Important: 43%

Neutral: 30%

Unimportant: 3%

Very unimportant: 0%

A3.2: Flexible and innovative services for our users

A3.2.1: Synchronisation: linking RTGS with other ledgers

In the consultation, we considered creating a generic interface into RTGS which would allow a wider range of ledgers to connect to RTGS to synchronise transactions. We asked respondents about their support for this feature as well as their interest in using or providing synchronisation services. We also asked about the use cases and costs/complexity of implementation.

Support for RTGS offering an interface for synchronisation

  • 62% respondents across different types of organisations supported the introduction of synchronisation.
  • Respondents noted that synchronisation would contribute to the reduction of transaction risk and cost, and help payment service providers to offer innovative services backed by the security of central bank money.
  • While 68% of respondents were interested in using synchronisation services directly, the greatest interest was for organisations providing such services to their customers (80%). Eight respondents were interested in becoming a synchronisation operator.

Chart A3.6: Synchronisation

Support for RTGS offering an interface for synchronisation

Majority of respondents (62%) strongly agreed or agreed with RTGS introducing an interface for synchronised settlement.

Footnotes

  • Consultation question: Do you agree that RTGS should offer an interface for synchronised settlement? (34 responses.)

Use cases for synchronisation

  • Cross-border transactions were supported as the most valuable use case for synchronised settlement, particularly by large RTGS users. However, some respondents caveated their responses noting that cross-border payments as a use case requires operating hours to be extended across the jurisdictions of the flow of the payment.
  • Further valuable use cases cited by respondents were securities transactions, corporate transactions and trade finance given the value of these payments and subsequent risk attached.
  • Some respondents noted the benefit of using synchronisation for housing transactions to customers in reducing the risk when purchasing property and reducing costs for all actors involved. However, several respondents said that housing transactions were unimportant for non-retail banks.

Chart A3.7: Synchronisation

Most valuable use cases for synchronisation

Respondents indicated that the most valuable use cases for synchronisation were Cross-border payments, Securities and housing transactions.

Footnotes

  • Consultation question: What are the most valuable use cases that would bring benefits for your organisation? Respondents scored each use case on a scale of 1–7, with 1 being of the lowest benefit, and 7 being of the highest benefit. (Between 19–23 responses across use cases.)

Policy and design considerations for synchronisation

  • A few respondents preferred the Bank to facilitate industry discussions on shaping the functionality, setting standards on messages, and arrangement between the synchronisation operators and their customers.
  • Many respondents expressed preference for being able to send payments through APIs, although this was not seen as a prerequisite.

Cost and complexity of providing and using synchronisation

  • Among those who were interested in becoming a synchronisation operator, half noted that the cost and complexity of providing synchronisation services would be low or business as usual.
  • For large users who expressed an interest in using synchronisation, the cost and complexity was low or business as usual provided the implementation and use leveraged APIs and cloud technology. A few of these respondents already had enabling technical capabilities in place, further reducing the costs.
  • Many respondents caveated their responses. Common reasons included (but were not limited to) dependencies on technology and infrastructure providers; the level of testing required; dependencies on specific use cases, since cost and complexity will differ across them; and, whether the organisation is an existing CHAPS participant or not.

Consultation questions

Consultation question

Respondents

Answers

Do you agree that RTGS should offer an interface for synchronised settlement?

34

Strongly agree: 21%

Agree: 41%

Neutral: 29%

Disagree: 9%

Strongly disagree: 0%

Would your organisation be interested in:

a) using synchronisation service directly?

34

Very interested: 15%

Interested: 35%

Neutral: 24%

Uninterested: 0%

Very uninterested: 0%

Not applicable: 26%

b) providing synchronised settlement to your customers?

34

Very interested: 18%

Interested: 41%

Neutral: 12%

Uninterested: 3%

Very uninterested: 0%

Not applicable: 26%

c) providing synchronised settlement as a synchronisation operator?

34

Very interested: 18%

Interested: 6%

Neutral: 24%

Uninterested: 12%

Very uninterested: 0%

Not applicable: 41%

d) connecting to RTGS as an asset ledger or trading platform?

34

Very interested: 21%

Interested: 15%

Neutral: 24%

Uninterested: 0%

Very uninterested: 0%

Not applicable: 41%

How would you assess the complexity and cost to your organisation from preparing to:

a) provide synchronised settlement?

21

Too high: 10%

High: 19%

Medium: 33%

Low: 19%

Business as usual: 19%

b) use synchronised settlement?

19

Too high: 5%

High: 21%

Medium: 37%

Low: 21%

Business as usual: 16%

In your estimation, how long might it take your organisation to implement the relevant changes to:

a) use synchronised settlement?

19

>24 months: 32%

19–24 months: 21%

13–18 months: 21%

7–12 months: 16%

1–6 months: 11%

b) provide synchronised settlement?

21

>24 months: 33%

19–24 months: 24%

13–18 months: 24%

7–12 months: 10%

1–6 months: 10%

What are the most valuable use cases that would bring benefits for your organisation? Please rate on a scale of 1–7, with 1 as the least valuable, and 7 as the most valuable.

Shown as the numbers in parenthesis to the right

Cross-border: 5.2 (23)

Securities: 4.5 (20)

Housing: 3.8 (19)

Trade finance: 3.8 (20)

Corporate actions: 3.6 (20)

Do you agree with the proposed implementation approach for synchronisation?

27

Strongly agree: 4%

Agree: 48%

Neutral: 44%

Disagree: 4%

Strongly disagree: 0%

A3.2.2: Extended operating hours in RTGS

The renewed RTGS will be capable of supporting 22x5 operating hours and will have no technical barriers to moving to near 24x7 operation in the future. In the consultation, we asked about respondents’ support for extending RTGS hours as well as about costs and complexities of such extension.

Support for extending RTGS operating hours

  • The majority (59%) of respondents agreed that the Bank should extend RTGS operating hours.
  • Respondents also acknowledged the global trend towards the extension of operating hours to near 24x7.
  • The benefits of extended hours were recognised across different types of organisations and included:
    • Aligning with CPMI/G20 initiatives on enhancing cross-border payments, expressed in majority by large users.
    • An extension of a few hours could lead to increased business and help smooth liquidity flows, in turn also improving customer experiences. This was mostly cited by small users.
  • Some respondents noted that they do not currently see a clear use case for their clients and highlighted the costs predominately related to the changes required to staff and technology. Some considered that extending RTGS operating hours was less time-critical due to the UK’s central time zone.

Chart A3.8: Extended operating hours in RTGS

Support for extending RTGS operating hours

Majority of respondents (59%) strongly agreed or agreed that the Bank should extend RTGS operating hours. 18% disagreed and 24% were neutral.

Footnotes

  • Consultation question: Do you think the Bank should extend RTGS operating hours? (34 responses.) Please note figures may not add to 100% due to rounding.

Extension length of RTGS operating hours delivering the most benefit

  • The most favoured extension length was a 1–3 hour extension on working days. This was mainly driven by small users who wished to further improve their customer experiences and to smooth liquidity flows throughout the day.
  • Respondents noted that CHAPS and RTGS operating hours would need separate reviews. Extending CHAPS operating hours was somewhat less favoured by industry as it was viewed by some as not being cost effective and lacking in current demand.

Chart A3.9: Extended operating hours in RTGS

Extension length of RTGS operating hours delivering the most benefit

Respondents indicated that the preferred extension length of RTGS operating hours delivering the most benefit was 1-3 hours on working days.

Footnotes

  • Consultation question: 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? (34 responses.)

Cost and complexity for adopting and maintaining extended RTGS operating hours

  • A small number of large RTGS users noted staff and resourcing costs as a key concern for any extension type. They noted that cost and complexity of CHAPS extended hours could be too high/unfeasible mainly due to legacy systems and potential high system change costs.
  • As the length of extension to RTGS operating hours increases, cost and complexity also increases. Generally, respondents noted they would need to review the potential demand and use cases for any extension type.
  • However, some respondents noted that their business models are already adapted for 24x7 operating hours so would be low impact and BAU.

Chart A3.10: Extended operating hours in RTGS

Cost and complexity for adopting and maintaining extended RTGS operating hours

Most respondents thought that the cost and complexity was largely either Business as usual or Medium for adopting and maintaining extended CHAPS operating hours.
Most thought that the cost and complexity for adopting and maintaining extended RTGS operating hours would be Low, Medium or BAU.

Footnotes

  • Consultation question: How would you assess the complexity and cost to your organisation from adopting and maintaining extended RTGS operating hours? (34 responses.) Please note figures may not add to 100% due to rounding.

Consultation questions (34 responses)

Consultation question

Answers

Do you think that the Bank should extend RTGS operating hours?

Strongly agree: 15%

Agree: 44%

Neutral: 24%

Disagree: 18%

Strongly disagree: 0%

If you agree, which RTGS services would benefit from extended operating hours?

CHAPS (including funding): 22%

Retail settlement: 14%

Participant User Interface (UI) access: 10%

API access: 12%

Transfers between accounts within RTGS: 17%

Transfers between RTGS accounts and commercially held accounts via CHAPS: 13%

Not answered: 12%

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?

CHAPS:

Small extent: 19%

Moderate extent: 29%

Large extent: 16%

Very large extent: 6%

Not applicable: 23%

Not at all: 6%

Wider RTGS:

Small extent: 13%

Moderate extent: 29%

Large extent: 13%

Very large extent: 6%

Not applicable: 29%

Not at all: 10%

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?

CHAPS:

1–3 hours on working day: 24%

A few hours on weekend: 3%

22x5: 6%

24x7: 12%

None: 18%

Other: 24%

Not answered: 15%

Wider RTGS:

1–3 hours on working day: 24%

A few hours on weekend: 3%

22x5: 6%

24x7: 12%

None: 18%

Other: 21%

Not answered: 18%

How would you assess the complexity and cost to your organisation from:

a) adopting extended CHAPS operating hours?

Unfeasible/too high: 6%

High: 9%

Medium: 24%

Low: 12%

Business as usual: 18%

Not answered: 32%

b) maintaining extended CHAPS operating hours?

Unfeasible/too high: 0%

High: 6%

Medium: 29%

Low: 9%

Business as usual: 21%

Not answered: 35%

c) adopting extended RTGS operating hours?

Unfeasible/too high: 3%

High: 12%

Medium: 18%

Low: 24%

Business as usual: 12%

Not answered: 32%

d) maintaining extended RTGS operating hours?

Unfeasible/too high: 0%

High: 6%

Medium: 21%

Low: 21%

Business as usual: 15%

Not answered: 38%

Please specify any practical constraints to implementing extended operating hours to your organisation.

Addressing incidents: 17%

Performing reconciliations: 17%

Introducing technical upgrades: 13%

Staff requirements: 25%

Conducting testing: 16%

None: 3%

Not answered: 10%

In your estimation, how long might it take your organisation to implement the changes required to extend operating hours?

CHAPS:

1–6 months: 16%

7–12 months: 3%

13–18 months: 13%

19–24 months: 23%

>24 months: 23%

Not answered: 32%

Wider RTGS:

1–6 months: 13%

7–12 months: 3%

13–18 months: 16%

19–24 months: 13%

>24 months: 23%

Not answered: 32%

A3.2.3: More ways to generate intraday liquidity

In the consultation, we considered two new ways to generate intraday liquidity in RTGS:

  • New liquidity bridges with RTGS systems in other currencies.
  • Generating liquidity in RTGS using securities in CREST as collateral.

We asked about the respondents’ demand for these features and how they could be designed.

Support for introducing new liquidity bridges

  • 62% of respondents agreed with the Bank introducing liquidity bridges. Respondents (in particular large users) welcomed opportunities to strengthen the efficiency of liquidity positions.
  • While organisations were generally interested in this feature, it was seen as a ‘nice to have’ rather than a requirement to improve liquidity management.
  • Service providers also noted that new liquidity bridges would assist with the provision of synchronised settlement.
  • The most favoured liquidity bridge to explore supported by the majority of respondents (55%) was between sterling and the US dollar. Some respondents highlighted the use of this liquidity bridge for contingency purposes. Support for liquidity bridges in G7 currencies and emerging markets was also noted across responses.

Chart A3.11: More ways to generate intraday liquidity

Support for introducing functionality to provide more ways to generate intraday liquidity

Majority of respondents (62%) agreed with new liquidity bridges. Fewer respondents (50%) supported extending CREST ACR. Around a third of respondents were neutral on liquidity management features.

Footnotes

  • Consultation question: Do you agree that RTGS should introduce these features? (31 responses.)

Support for generating liquidity in RTGS using securities in CREST as collateral (CREST ACR)

  • 50% of respondents (mainly large users) expressed interest in using the feature. They noted that this feature seemed a sensible extension of the intraday liquidity functionality currently available. However, the extension of CREST ACR was largely seen as ‘nice to have’.
  • Some respondents asked for more clarification about whether this feature would be optional or mandatory. They noted it was not as applicable to smaller players compared to larger organisations.
  • Non-bank payment service providers expressed interest in using this feature if they were made eligible to access it.

Costs and complexity of more ways to generate intraday liquidity

  • Responses on the cost and complexity of implementation of new liquidity bridges ranged from a very high to a very low impact.
  • The majority (55%) of respondents said it could take their organisations over 18 months to implement changes to support generating liquidity using securities in CREST as collateral (though a more detailed analysis would be required to assess impact more precisely).
  • Some respondents noted that they would need to review contractual arrangements in order to use securities as collateral (which could be undesirable).

Chart A3.12: More ways to generate intraday liquidity

Views on cost and complexity for more ways to generate intraday liquidity

Most respondents indicated that the cost and complexity for more ways to generate intraday liquidity was largely either Medium or Low.

Footnotes

  • Consultation question: How would you assess the complexity and cost to your organisation of adopting and using these features? (31 responses.) Please note figures may not add to 100% due to rounding.

Consultation questions (31 responses)

Consultation question

Answers

Do you agree that RTGS should introduce these features?

New liquidity bridges:

Strongly agree: 15%

Agree: 47%

Neutral: 32%

Disagree: 3%

Strongly disagree: 3%

CREST ACR:

Strongly agree: 18%

Agree: 32%

Neutral: 35%

Disagree: 6%

Strongly disagree: 9%

Would your organisation be interested in using either of these features?

New liquidity bridges:

Very interested: 10%

Interested: 32%

Neutral: 19%

Uninterested: 3%

Very uninterested: 6%

Not applicable: 29%

CREST ACR:

Very interested: 13%

Interested: 23%

Neutral: 23%

Uninterested: 0%

Very uninterested: 13%

Not applicable: 29%

Please specify which currencies you would like the Bank to explore for further liquidity bridges, beyond the current euro cash liquidity bridge.

US dollar: 38%

Yen: 16%

Swiss franc: 16%

None: 11%

Not answered: 20%

Is your organisation interested in using reciprocal liquidity bridges?

Very Interested: 10%

Interested: 16%

Neutral: 23%

Uninterested: 3%

Very uninterested: 13%

Not applicable: 35%

In which currencies is your organisation interested in using reciprocal liquidity bridges?

US dollar: 29%

Euro: 27%

Swiss franc: 14%

None: 10%

Not answered: 20%

How would you assess the complexity and cost to your organisation of:

a) adopting these features?

New liquidity bridges:

Unfeasible/too high: 3%

High: 9%

Medium: 18%

Low: 21%

Business as usual: 6%

Not answered: 44%

CREST ACR:

Unfeasible/too high: 9%

High: 12%

Medium: 15%

Low: 12%

Business as usual: 9%

Not answered: 44%

b) using these features?

New liquidity bridges:

Unfeasible/too high: 3%

High: 6%

Medium: 18%

Low: 18%

Business as usual: 12%

Not answered: 44%

CREST ACR:

Unfeasible/too high: 9%

High: 12%

Medium: 15%

Low: 12%

Business as usual: 9%

Not answered: 44%

In your estimation, how long would it take your organisation to implement the relevant changes?

New liquidity bridges:

1–6 months: 3%

7–12 months: 16%

13–18 months: 23%

19–24 months: 16%

>24 months: 39%

Not answered: 3%

CREST ACR:

1–6 months: 3%

7–12 months: 16%

13–18 months: 16%

19–24 months: 23%

>24 months: 32%

Not answered: 10%

A3.3: World-class resilience

A3.3.1: Maintaining suitable contingency for settlement

We are reviewing the third site contingency solution in light of the evolution of the RTGS (such as message network agnosticism and our resilience ambitions). In the consultation, we proposed a design principle framework underpinning how we will develop a new model and invited feedback on these principles. The consultation also asked respondents about the models for settlement contingency that we could consider and the considerations on how participants would be able to connect to the settlement contingency solution.

Support for alternative third site settlement contingency solutions

  • Respondents particularly strongly supported a settlement contingency solution that is channel agnostic and removes SWIFT as a single point of failure. This was supported by both large and small users.
  • The majority agreed that a fully independent third site (ie geographically, technically) is critical to ensure sufficient resiliency.
  • Respondents voiced a preference for a solution that can be regularly and easily tested, ideally running in parallel to the primary service. Reasons included improved familiarity of the third site to enhance the speed of failover/failback.
  • Large RTGS users favoured a settlement contingency solution offering seamless invocation, ie quick activation with minimal participant impact.
  • While feedback was conceptually supportive of the Bank’s approach and reasoning for alternative third site solutions, it was noted that several themes, including connection and delivering value for money, require further consideration.

Considerations for the Bank’s settlement contingency approach

  • Several respondents noted that any alternative settlement contingency approach should not be a step backwards from the current functionality of MIRS.
  • Generally, smaller users encouraged the use of cost-efficient technologies in order to improve value for money, should the Bank’s settlement contingency solution change.
  • A small number of respondents, particularly large users, noted that they would be willing to invest heavily upfront if a settlement contingency solution had an easy and efficient invocation process (ie where no manual configuration is needed).
  • Utilising other Roadmap features (eg APIs, new liquidity bridges, CREST ACR) and cloud technology could improve the efficiency and resiliency of a settlement contingency solution.
  • Respondents made several suggestions for the mode of connection to a third site contingency solution. Considerations could include potential re-use of infrastructures (such as gateway) and connection models (such as use of APIs), alignment of messaging protocol between primary and contingency solutions, simplified settlement model and automated and frequent testing.
  • Two respondents noted that the change risk in changing from the current settlement contingency solution would need to be sized and mitigated.

Design principles and methods of connection

  • 74% of respondents agreed that the design principles are a suitable framework for maintaining a suitable settlement contingency solution.
  • The overall prioritisation of design principles is shown in Chart A3.14. Larger users and service providers value resilient and ease of use as the most beneficial design principles. Smaller users prioritised value for money and suitability.
  • Respondents acknowledged the framework as comprehensive but suggested our ‘ease of use’ principle focus on seamless invocation and regular testing capability of the third site.

Chart A3.13: Maintaining suitable contingency for settlement

Support for proposed design principles to maintain suitable settlement contingency

Most respondents agreed or strongly agreed with proposed design principles to maintain suitable settlement contingency.

Footnotes

  • Consultation question: Do you agree with the proposed design principles are a suitable framework for maintaining a suitable contingency for settlement? (34 responses.) Please note figures may not add to 100% due to rounding.

Chart A3.14: Maintaining a suitable contingency for settlement

Views on prioritisation between proposed settlement contingency design principles

Respondents' views on prioritisation among proposed settlement contingency design principles were fairly evenly split between Simple, Suitable, Resilient, Flexible, Value for money and Easy to use, with Resilient gaining the highest score and Flexible the lowest.

Footnotes

  • Consultation question: How should we prioritise between these principles? (34 responses provided a score between 1 as lowest priority and 7 as highest priority.)

Consultation questions (34 responses)

Consultation question

Answers

Does the list of principles set out provide a suitable framework for selecting or designing a Settlement Contingency solution?

Strongly agree: 13%

Agree: 45%

Neutral: 26%

Disagree: 16%

Strongly disagree: 0%

How should we prioritise between these principles? Average score provided here between 1 (lowest priority) and 7 (highest priority).

Simple: 5.1

Suitable: 5.4

Resilient: 5.9

Flexible: 4.6

Value for money: 5.4

Easy to use: 5.7

A3.3.2: Reconciling data with participants

In the consultation, we proposed enhancing functionality and policies to enable improved reconciliation. We proposed to do this by:

  • requiring positive confirmation and more frequent reconciliations; and
  • utilising new functionality from ISO 20022 messages and the API channel.

We asked about the length of time to implement relevant changes as well as any technical barriers for implementation.

Reconciling balances intraday

  • The main barriers preventing respondents from reconciling intraday currently were the lack of automation and resource and technology constraints.
  • Two respondents argued that the use case for enhanced reconciliations was not yet clear. They noted that due to ‘in-flight’ payments it cannot be expected that intraday reconciliations would match at all times. Several respondents also thought that there was a risk of significant cost of such enhancements with only small visible benefits (eg during an RTGS disruption).
  • Several respondents asked for further clarity on the proposed technical specification and approach, including requirements for any concurrent reconciliation solutions (eg implication of enhanced reconciliations with regards to a settlement contingency solution and a new channel/common contingency messaging channel).

Chart A3.15: Reconciling data with participants

Respondents currently reconciling balances in RTGS intraday

34% of respondents indicated they currently reconcile balances with RTGS intraday, while 25% indicated they do not and 41% said this was not applicable to them.

Footnotes

  • Consultation question: Does your organisation currently reconcile your balance in RTGS in intraday? (34 responses.)

Length of time to implement enhanced reconciliations

  • Chart A3.16 shows the views on the length of time respondents thought they might require to implement relevant changes.
  • Responses varied significantly across organisations due to the differing levels of applicability and current automation. Organisations with automated reconciliation processes would require a shorter time period to make relevant changes.

Chart A3.16: Reconciling data with participants

Length of time to implement relevant changes for enhanced reconciliations

The views on the length of time to implement relevant changes for enhanced reconciliation were split, with 35% indication it would take 13-18 months; around 23% choosing 1-6 months and above 205 choosing over 24 months.

Footnotes

  • Consultation question: 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? (34 responses.)

Sending and receiving data for enhanced reconciliations

  • We asked respondents what the best medium would be to send and receive data for reconciliations. 28% of respondents for which this was applicable preferred APIs for sending and receiving data for reconciliations and 32% preferred ISO 20022 messages.
  • The majority (40%) of respondents supported both APIs and ISO 20022 messages and noted that flexibility to choose would be beneficial.
  • Views on the best medium to send and receive data for enhanced reconciliations did not differ significantly across organisation types.

Consultation questions (34 responses)

Consultation question

Answers

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?

1–6 months: 24%

7–12 months: 9%

13–18 months: 35%

19–24 months: 12%

>24 months: 21%

Does your organisation currently reconcile your balance in RTGS in intraday?

Yes: 34%

No: 25%

Not applicable: 41%

A3.3.3: A retail contingency solution

In the consultation, we noted that the Bank was considering how CHAPS could provide a contingency for critical retail payments (CARA). We asked if organisations were interested in potentially using CHAPS as a contingency route for critical retail payments.

Interest in using CHAPS as a contingency route for critical retail payments (CARA)

  • Chart A3.17 summarises views on potentially using CARA.
  • Large users noted the following benefits of CARA: greater resilience, drive towards greater interoperability and a need for effective contingency for the NPA.
  • Some respondents noted the emphasis on operational resilience at the moment and thought that CARA would be beneficial for retail payment contingency.

Chart A3.17: Retail contingency solution (CARA)

Interest in using a retail contingency solution

38% of respondents were interested or very interested in using a retail contingency solution. 21% were neutral and 32% noted this was not applicable to their organisations.

Footnotes

  • Consultation question: 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)? (34 responses.)

Considerations on using CARA

  • Smaller users questioned if using CHAPS was the correct approach for retail contingency, noting the costs of using CHAPS for this purpose.
  • Some respondents thought investment may be better placed in ensuring the resiliency of retail payment infrastructure and its fit for purpose.
  • Some respondents noted that there was insufficient information on the final specifications and scope of the NPA for them to be able to assess whether there is a business case for CARA. It was noted that, should NPA proposals offer an acceptable level of resilience, there would not be a valuable use case for CARA.
  • Respondents noted that any contingency solution would need to be proportional, simple, future-proofed and credible.

Consultation questions (34 responses)

Consultation question

Answers

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)?

Very interested: 6%

Interested: 35%

Neutral: 23%

Uninterested: 10%

Very uninterested: 0%

Not applicable: 35%