NZ: Deposit Takers (Operational Resilience) Standard
|
|
| Regulator |
RBNZ |
| Jurisdiction |
NZ |
| Status |
Draft — not yet in force |
| Applicability |
Platform |
DRAFT — exposure draft expected as part of Tranche 3. Standard takes effect 1 December 2028.
The Deposit Takers (Operational Resilience) Standard is a non-core standard under the Deposit Takers Act 2023. It applies to all locally-incorporated deposit takers (NZ-G1, NZ-G2, NZ-G3) on a principles-based, proportionate basis. G3 entities are not exempt — they face simplified but mandatory requirements aligned with their scale and risk profile.
The standard sets requirements to identify, prevent, adapt to, respond to, and recover from operational disruptions. It addresses critical operations identification, impact tolerances, scenario testing, third-party operational risk, and incident reporting to the RBNZ. Unlike the Outsourcing Standard (which focuses on resolution-readiness for G1/G2), the Operational Resilience Standard is a universal standard focused on continuity of service.
The standard builds on and partially replaces the former business continuity and IT risk guidance.
Compliance register
This register maps every material obligation under the draft standard to the platform control or
institutional process that is expected to satisfy it.
Scope legend
| Symbol |
Meaning |
| 🤖 Automated |
Platform enforces or performs the obligation. Primary control mode is GATE, AUTO, CALC, or ALERT. Human action is not required in the normal case. |
| 📊 Evidenced |
Platform captures the evidence trail automatically. Human compliance decision sits on top. Primary control mode is LOG. |
| 🏛 Institutional |
Obligation is met by a process entirely outside the platform — governance, operations, HR. Platform may generate evidence inputs but does not own the process. |
| N/A |
Obligation does not apply to this deployment configuration. |
Build legend
| Symbol |
Meaning |
| ✅ |
Module built and deployed |
| 🔨 |
Module planned — not yet built (build_status: Not started) |
| ❌ |
Uncontrolled gap — no module attributed |
Critical operations identification and impact tolerances
| Obligation |
Scope |
Policy |
Platform controls |
Build |
| Identify and map critical business services and the underlying systems, people, and third parties that support them |
📊 Evidenced |
OPS-007 |
MOD-150 (AUTO) — all designated critical third parties (Neon, Snowflake, AWS, BPAY, NPP, eIDV providers, card bureau) are continuously health-monitored; operational risk register maps service dependencies automatically; service mapping document is institutional |
🔨 |
| Set impact tolerances for each critical business service — maximum tolerable disruption in terms of duration and scope |
🏛 Institutional |
OPS-007 |
MOD-076 (ALERT) — availability monitoring measures service uptime continuously; tolerance breach alerts are raised automatically. Impact tolerance values are set by the board and configured in the monitoring platform; their approval is institutional. |
— |
| Monitor critical service availability against impact tolerances |
🤖 Automated |
OPS-007 |
MOD-076 (ALERT) — observability platform monitors all critical services against availability SLAs; tolerance breach triggers automated incident creation with P1/P2 classification and routing; MOD-150 (AUTO) — SLA breach for critical third parties auto-creates an incident |
🔨 |
| Maintain business continuity plans (BCPs) and disaster recovery plans (DRPs) for all critical services |
🏛 Institutional |
OPS-001 |
BCP and DRP documents are institutional. MOD-076 provides the availability monitoring and incident detection that feeds BCP/DRP activation decisions; MOD-150 provides the operational risk register that informs BCP scope. |
— |
Scenario testing and self-assessment
| Obligation |
Scope |
Policy |
Platform controls |
Build |
| Test resilience against impact tolerances at least annually through scenario exercises |
🏛 Institutional |
OPS-007 |
MOD-150 (LOG) — idempotency key collision rates, reprocessing events, and settlement reconciliation outcomes tracked and logged; scenario test outputs are documented in the risk case console (MOD-151). Exercise execution and design are institutional. |
— |
| Conduct post-incident reviews and remediate identified weaknesses |
📊 Evidenced |
OPS-007 |
MOD-150 (AUTO) — incidents auto-created with P1/P2/P3 classification and SLA timers; MOD-151 (GATE) — all P1 incidents require a documented root cause and resolution action before they can be closed; no bypass path exists |
🔨 |
Third-party operational risk
| Obligation |
Scope |
Policy |
Platform controls |
Build |
| Manage third-party operational risk: due diligence, ongoing monitoring, and exit planning |
📊 Evidenced |
OPS-005 |
MOD-150 (AUTO) — all designated critical third-party services are continuously monitored for health and SLA compliance; contract expiry dates trigger review reminders; due diligence records and exit plans are institutional |
🔨 |
| Report material operational incidents to RBNZ within prescribed timeframes |
🤖 Automated |
OPS-007 |
MOD-150 (AUTO) — material incidents auto-detected and routed through notification assembly workflow; regulator notification proceeds where an API is available; RBNZ notification for incidents without an API is institutional |
🔨 |
The following obligations under the standard are the responsibility of the institution, not the platform.
| Obligation |
Owner |
Platform evidence input |
| BCP and DRP document authorship and maintenance |
Chief Operating Officer |
MOD-076 and MOD-150 provide availability and incident data that inform BCP/DRP scope |
| Annual scenario testing exercise design and execution |
Chief Operating Officer / Chief Risk Officer |
MOD-151 provides case management for scenario exercise documentation; exercise execution is institutional |
| Board approval of impact tolerances |
Board / Chief Operating Officer |
MOD-076 monitors against configured tolerances; tolerance values and board approval are institutional |
| Due diligence assessments for critical service providers |
Chief Technology Officer / Chief Risk Officer |
MOD-150 provides ongoing health monitoring; due diligence execution is institutional |
Coverage summary
| Area |
Total obligations |
Platform automated 🤖 |
Platform evidenced 📊 |
Institutional 🏛 |
N/A |
| Critical operations identification and impact tolerances |
4 |
1 |
1 |
2 |
0 |
| Scenario testing and self-assessment |
2 |
0 |
1 |
1 |
0 |
| Third-party operational risk |
2 |
1 |
1 |
0 |
0 |
| Total |
8 |
2 (25%) |
3 (38%) |
3 (37%) |
0 |
Platform controls (MOD-076, MOD-150, MOD-151) provide the monitoring, incident, and risk case
infrastructure. BCP/DRP documents, scenario test execution, and impact tolerance approval are
institutional by their nature. Standard is draft — compliance position is contingent on finalisation.
| Policy |
Title |
| OPS-001 |
Business Continuity Policy |
| OPS-005 |
Third-Party & Critical Service Provider Policy |
| OPS-007 |
Financial Processing Resilience & Idempotency Policy |
Official documentation
Policies referencing this standard
- OPS-007 — Financial Processing Resilience & Idempotency Policy
Compiled 2026-05-22 from source/entities/regulations/nz-dta-operational-resilience.yaml