1. The Bank’s RTGS infrastructure supports settlement of individual CHAPS payments as well as settlement from several other payment systems. CHAPS is the UK’s high‐value payment system and is also used for certain time‐critical lower value payments like house purchases. Our combined delivery of RTGS and CHAPS contributes to the Bank’s mission to promote the good of the people of the UK by maintaining monetary and financial stability.footnote [1]
2. RTGS is built to a very high level of resiliency. It operates on fault‐tolerant computers, replicated at a second site. We conduct business operations on a split‐site basis and continue to operate the Bank’s RTGS infrastructure if one site is lost. CHAPS normally closes at 5.40pm for customer payments and 6pm for financial institution payments but we can extend CHAPS operating hours until 8pm in extremis so that payment service providers can make maximum use of the operating day to provide same day value for end‐users.
3. This document sets out the factors that the Bank will consider when deciding whether to invoke MIRS (Market Infrastructure Resiliency Service) as a contingency solution for RTGS (including CHAPS settlement). It is intended to help external and internal stakeholders, including CHAPS Direct Participants (DPs) and the operators and participants of other payment systems that settle in RTGS, understand the issues that the Bank will consider when deciding whether to invoke MIRS.
4. In the event of an incident, we will communicate with CHAPS DPs and other RTGS users on: the nature of the incident; proposed remediation; and any decision we take in relation to invoking MIRS. Communication will be transparent to the extent it would not, amongst other things, risk prejudicing the security and integrity of RTGS, CHAPS, the Bank and/or financial stability or release commercially sensitive information.
Key facts about MIRS
5. MIRS is primarily intended to address a dual site failure of RTGS. It also provides an additional level of resilience to some types of incidents that would affect the main RTGS infrastructure. MIRS uses different software, programming and hardware to RTGS because it is remotely hosted by SWIFT, a provider of secure financial messaging.
6. MIRS was built and designed by SWIFT as a generic systemfootnote [2] to provide core RTGS functionality and is used by multiple central banks as a contingency solution. MIRS provides this core functionality as well as processing capacity to provide continuity of the Bank’s critical RTGS and CHAPS services.
7. As part of the invocation of SWIFT, CHAPS Direct Participant must reconcile their expected account balances as well as the status of any payments in‐flight. MIRS can settle peak CHAPS volumes and net retail settlements.footnote [3] The design of MIRS, however, deliberately does not replicate all of the functionality of the UK’s RTGS infrastructure, such as a Liquidity Saving Mechanism, because that would increase its complexity, and make maintenance harder.
Factors influencing the Bank’s decision to invoke MIRS
8. Risks to monetary and financial stability are paramount, consistent with the Bank’s mission.
9. The Bank prefers, if possible, to resolve an issue so we can resume settlement in the main RTGS infrastructure. Where that is not possible, or will delay resumption beyond the end of day (including an extension to 20:00), then we will consider the appropriateness of invoking MIRS. If we believe resumption is only likely late in the settlement day, we will consider the case for early invocation of MIRS to minimise the gap during which settlement is not available (see Scenarios requiring finely balanced judgement on the day).
10. Our decision to invoke MIRS will be judgement‐based and made in response to circumstances at the time. The outcome cannot be absolutely pre‐determined because of the complexity of the technical and external impacts that need to be considered. However, we can categorise scenarios into those where: we would be likely to invoke MIRS; we would be unlikely to invoke MIRS; and the decision is finely balanced because of the magnitude and type of payments activity expected for the remainder of the specific day of an incident relative to the expected recovery time.
11. Similarly, our decision to revert from MIRS to the main RTGS infrastructure will take account of circumstances at the time. We must consider when it is safe to revert, with confidence around the integrity and availability of RTGS being paramount. In terms of timing for reversion, our view is that the safest course of action in most circumstances is likely to be to return to settling in RTGS after the end of the business day following its restoration, or over a weekend if earlier. Therefore, we are likely to run MIRS for two or more days depending on the nature of the incident.
Scenarios where there is a strong likelihood we would invoke MIRS
12. Reasons might involve physical disaster (e.g. flood or fire), hardware or software incidents or cyber‐attacks. A rapid, or even same day, resolution of the main RTGS infrastructure may not be feasible.
Examples include:
a) Physical loss of the Bank’s data processing sites.
b) Loss of the Bank’s IT infrastructure needed by technology and/or operational staff to access and operate RTGS (e.g. desktop PCs, networks).
c) Inability of RTGS to connect to SWIFT.
d) Loss of availability of RTGS infrastructure.
e) Loss of integrity through the corruption of RTGS data, if we determine that we cannot restart RTGS because forensic analysis is required.
Scenarios where invoking MIRS are unlikely to be appropriate
13. Under the examples below the Bank would be likely to continue to operate the main RTGS system:
a) If only one of the Bank’s data processing centres was lost. Should the standby site be lost, moving to single site operation of RTGS will be straight‐forward and rapid; if the live site is lost, fallback to the second site will take less than 1 hour.
b) Issues elsewhere in the broader payments system, for example at SWIFT or individual CHAPS DPs.
14. MIRS will not be invoked at an early stage where alternative contingency arrangements already exist to ensure that financial obligations are met or mitigated:
a) Contingency arrangements to enable settlement of a small volume of financial market infrastructure activity. These include: CLS pay‐ins; provision of intra‐day liquidity; CREST DvP settlement; and deferred net settlement for retail systems.
b) In some cases, standard or contingency arrangements exist that ensure financial obligations can be met; for example CCP members may be able to meet margin calls through collateral or non‐sterling.
Scenarios requiring finely balanced judgement on the day
15. Sometimes it will be clear that we should invoke MIRS as soon as practical, for example major physical disaster (a) or data corruption (e). In less extreme scenarios than those above, we would assess the likely recovery time required and also how late it is in the settlement day. We will consider the impact of the lack of RTGS/CHAPS being available for critical market segments and assess whether it is appropriate to invoke MIRS to complete the settlement day, this could depend on:
a) Significant financial market activity due to settle, with potential impact on monetary and financial stability.
b) Support for payments which are time‐sensitive, such as housing completion payments. We will consider the case for early invocation of MIRS although, depending on the time of invocation, CHAPS settlement in MIRS might not be able to start until after 2pm, which is the convention for housing completion payments to have settled.
c) Expected CHAPS volumes and values for the remainder of the settlement day, reflecting that more time is required to process peak‐day volumes.
d) Time of day relative to the estimated time for recovery of the Bank’s RTGS infrastructure.
Net settlement systems operate in settlement cycles – at the end of each cycle, the payment system operator calculates the net amounts owed by each settlement participant. Instructions are then sent to the Bank’s RTGS system to credit or debit the amount owed to, or from, each settlement participant. The norm in the UK is that this settlement takes place after participants exchange information on individual payments, and after customers are debited or credited for individual payments.
Download pdf