What "Operational Risks and Resilience" actually means for your bank
If a critical function at your bank goes down, whether the failure is yours or a third party's, FINMA expects the board to have already approved how much disruption that specific function can tolerate, and expects you to have tested that you can hold that line under a severe but plausible scenario. Working it out during the incident is not an answer.
Whether it applies to you at all
The addressee table on page one is the fastest answer to that question, and it is the part almost everyone skips. Five boxes are ticked: banks, financial groups and conglomerates, persons under Art. 1b BankG, and investment firms in both proprietary and non-proprietary trading. Insurers, portfolio managers, trustees, fund management companies and custodian banks are not addressees of this circular.
The scope chapter then states it in law, and it runs wider than the grid. All of those institutions are simply called "institutions" for the rest of the text. The circular came into force on 1 January 2024 and replaced the 2008 circular it grew out of.
Rz 2. Banks under Art. 1a BankG · persons under Art. 1b BankG · securities firms under Art. 2 Abs. 1 Bst. e and Art. 41 FINIG · financial groups and conglomerates under Art. 3c BankG and Art. 49 FINIG. Replaced FINMA-RS 2008/21.
Proportionality comes with a list of numbers
The requirements are implemented case by case according to size, complexity, structure and risk profile. The half that never gets quoted sits in the same passage: FINMA can tighten the rules in individual cases as readily as relax them, and reserves the right to impose more stringent requirements on specific topics during ongoing supervision.
Rz 19 and 27.
The relief itself is a list. Banks and securities firms in FINMA categories 4 and 5 drop one named set of requirements. Institutions under Art. 47a–47e ERV, persons under Art. 1b BankG and investment firms in non-proprietary trading drop a further set on top. If you are relying on proportionality, you should be able to say which.
Rz 20 and 21. Categories 4 and 5 are exempt from Rz 33–38, 41–46, 48, 51, 57, 73, 74, 76–78, 80, 87, 92, 93, 96, 103, 104 and 110–112. The institutions named second are additionally exempt from Rz 72, 75, 79 and 105–109.
What Chapter IV covers
Chapter IV on operational risk management has six parts, not the three most summaries describe: overarching operational risk management, ICT risk, cyber risk, critical data risk, business continuity management, and the management of risks from cross-border service business. Chapter V covers operational resilience, and Chapter VI adds the continuation of critical services for systemically important banks.
Chapter IV runs Rz 22–112. Overarching 22–46 · ICT 47–60 · Cyber 61–70 · Critical data 71–82 · BCM 83–96 · Cross-border 97–100. Chapter V: Rz 101–111. Chapter VI: Rz 112.
The cross-border chapter is the one people are surprised to find here. Exposure to foreign tax, criminal and anti-money-laundering law, including through foreign-based subsidiaries and branches serving Swiss clients, is an operational risk under this circular.
Critical data is defined more broadly than most institutions assume. The definition covers data crucial for the successful and sustainable provision of the institution's services or for regulatory purposes, and it states that confidentiality, integrity and availability can each independently make data critical. That is a wider net than a confidentiality-driven classification scheme tends to catch.
Rz 7.
Availability alone is enough.
The part with real teeth
The circular defines a tolerance for disruption as the extent, for example the duration or the expected damage, of disruption to a critical function that the institution is willing to accept under severe but plausible scenarios. One has to be defined for each critical function. That is a different object from the risk tolerance for operational risk the board approves annually, and the two are routinely confused.
Tolerance for disruption: Rz 17. Risk tolerance for operational risk: Rz 23.
The board approves the critical functions and their tolerances, and that approval has to be renewed at least annually. It is not a one-time sign-off. The inventory of critical functions is reviewed at least annually as well, and it has to contain the tolerances and the dependencies between critical processes and the resources needed to deliver them. The underlying ICT asset inventory is stricter still: it is expected to be available in real time.
Rz 101, 103 and 107. Real-time ICT asset inventory: Rz 54.
The timing, which most summaries get wrong
Rz 113 sets out three different clocks, not one two-year runway. Identifying the critical functions, defining the tolerances, getting the board approvals and filing the initial reporting were expected from entry into force, with no transitional period granted at all. A one-year period applied to the inventory requirements and to the first round of tests. A two-year period applied to ensuring operational resilience and to two further requirements.
Rz 113. No transition: Rz 101, 103 and 105. One year: Rz 106–109 and 110. Two years: Rz 102, 104 and 111.
All three windows have now passed. An institution that treated this as a single two-year programme was on time for the last group and two years late on the first.
Tabletop exercises still count
There is a widespread claim that tabletop exercises no longer satisfy the circular. That is not what it says. Rz 91 lists them among the acceptable means of testing, and they are named again for the cyber exercises. The bar is not the format.
Rz 91 and 70.
The bar is the scenario. Tests have to encompass various severe but plausible scenarios and take account of recovery dependencies, including those involving third parties. The resilience testing requirement goes further and asks for scenarios that differ from short, limited interruptions: longer duration, in the order of several months, and a lack of basic resources. The examples are in a footnote and worth reading in full, because they include a pandemic, a power shortage, prolonged downtime from the insolvency of a key service provider, and a foreign government prohibiting its cloud providers from serving Swiss firms. The most important BCP and DRP measures and the crisis organisation are tested at least once a year.
Rz 94 and 110, with footnote 27. Annual testing: Rz 92.
So a tabletop run against a severe, long-duration, third-party scenario meets the requirement. A live failover test against a two-hour outage does not, however impressive it looks in the report.
-
Is there a documented identification of which services meet the circular's definition of a critical function, with a date on it?
Rz 14
-
For each critical function, has the board approved a tolerance for disruption expressed as an extent, such as a duration or an expected damage figure?
Rz 17 and 101
-
Was that approval renewed within the last twelve months?
Rz 103
-
Does your critical-function inventory actually contain the dependencies between critical processes and the resources delivering them? A list of function names is not an inventory.
Rz 107
-
Do your test scenarios include long duration and a lack of basic resources?
Rz 110
-
Does your critical-data classification treat availability and integrity as independent triggers, and does it include data held for regulatory purposes?
Rz 7
-
Is your outsourcing risk management under FINMA-RS 2018/3 coordinated with this framework, as the circular expressly requires?
Rz 104
-
If you are relying on proportionality relief, can you name the requirements you are exempt from?
Rz 20 and 21
Three separate duties to report
The circular contains three separate duties to report to FINMA, and institutions often build a process for only one. ICT incidents regarded as a significant disruption to critical processes and material for supervision have to be reported without delay. The same applies to incidents that substantially impair the confidentiality, integrity or availability of critical data. The cyber timetable is its own: an initial assessment and preliminary notification to the responsible body at FINMA within 24 hours, the full report through the EHP platform within 72 hours, and a conclusive root cause analysis once the case is closed.
ICT incidents: Rz 60. Critical data: Rz 81. Cyber: Rz 68.
Those are the duties inside this circular. They are not the only reporting clocks a Swiss institution runs, and the interaction between them is a subject of its own.
Where this trips people up
Common misreading
Treating this as an IT circular that the security or infrastructure team owns end to end. It deliberately is not. FINMA placed the tolerance decision at board level and requires annual re-approval, so accountability sits with governance. The second common mistake is assuming an existing risk appetite statement already satisfies this. It does not. The risk tolerance for operational risk is institution-wide and approved annually. The tolerance for disruption is a separate object, defined per critical function, expressed as an extent, and approved on its own.
Rz 17 and 23.
If you are not sure whether your current business continuity documentation would hold up to an examiner asking for this level of specificity, that gap is usually smaller to close than it looks. The hard part is almost always naming the critical functions honestly, not the testing itself.
Checked against the German text of FINMA-RS 2023/1 "Operationelle Risiken und Resilienz – Banken", in the version in force at the review date above. Randziffern refer to that text, which is the authoritative version.