Open Bank Resolution pre-positioning¶


ID	`MOD-143`
System	SD01
Repo	`bank-core`
Build status	Deployed
Deployed	Yes
Last commit	`2b41724`

Purpose¶

Pre-position the platform so that a deploying deposit taker can execute an Open Bank Resolution event in compliance with the RBNZ DTA OBR Pre-positioning Standard. OBR is an RBNZ resolution tool that allows a distressed deposit taker to be kept open overnight and re-opened the following business day with depositor accounts partially frozen and partially accessible. This module ensures the platform is technically capable of entering a resolution state, partitioning balances across all deposit accounts, and operating channels in a restricted mode — at any time and on short notice.

What it does¶

Balance fields¶

Every deposit account carries two new fields managed by this module in cooperation with MOD-001:

obr_frozen_amount — NUMERIC, default 0. Holds the portion of the account balance subject to the OBR haircut. Zero in normal operation; populated atomically on resolution-state activation.
obr_available_amount — NUMERIC, mirrors the full account balance in normal operation. On activation, reduced to balance × (1 - haircut_pct). This is the amount customers can access after resolution.

Both fields are stored on the MOD-001 account record and updated only through the OBR partition transaction.

Resolution state¶

A resolution_state flag on the platform instance governs module behaviour across three values:

normal — pre-positioning not yet completed (development and staging only).
pre_positioned — the default production state. The platform is ready to execute OBR at any time. Balance fields exist but contain their normal values. No customer-facing change.
activated — RBNZ has issued a haircut instruction and the module has partitioned all deposit account balances. Channel restrictions are in force.

Production deployments must run continuously at pre_positioned. Verification that resolution_state = pre_positioned is available to the RBNZ on demand via a signed status endpoint.

Partition calculation¶

On activation, the RBNZ supplies a haircut percentage via a signed instruction payload (rbnz_instruction_ref). The partition calculation runs as a single database transaction covering all deposit accounts:

obr_frozen_amount   = current_balance × haircut_pct
obr_available_amount = current_balance × (1 - haircut_pct)

For joint accounts, MOD-125 balance_share_pct is applied per holder before the haircut is calculated, ensuring each depositor's Statutory Deposit Value (SDV) obligation is met correctly. The full partition — across all accounts — is applied atomically. Partial completion is not permitted; the transaction rolls back if any account cannot be updated.

Channel behaviour under activation¶

When resolution_state = activated:

Digital channels (app and internet banking, governed by MOD-068 and MOD-069) switch to a restricted mode. Customers see their obr_available_amount as their accessible balance. Outbound payments and transfers that would draw on the frozen portion are blocked with an OBR notice presented to the customer.
Teller channel (MOD-129) enforces the same available/frozen split. Teller UI displays both amounts and the haircut percentage.
Inbound credits continue to be received and are not frozen.
Account information queries (balance, transaction history) remain fully available.

Audit and event table¶

All OBR activity is written to core.obr_partition_events:

Column	Description
`event_id`	UUID primary key
`activated_at`	Timestamp of partition execution
`haircut_pct`	Haircut percentage applied
`rbnz_instruction_ref`	Reference from RBNZ instruction payload
`accounts_partitioned`	Count of accounts updated
`total_frozen_amount`	Sum of all `obr_frozen_amount` values post-partition
`total_available_amount`	Sum of all `obr_available_amount` values post-partition
`activated_by`	Operator identity or automated trigger reference
`status`	`pre_positioned` / `activated` / `resolved`

Records in this table are immutable. No update or delete path exists. Every haircut instruction received, every partition execution, and every resolution exit is appended as a new row.

Resolution exit¶

When RBNZ issues a resolution end notice, the module unwinds the partition flags. obr_available_amount is restored to the full balance and obr_frozen_amount is set to zero for accounts where no write-off applies. Where the RBNZ confirms a permanent haircut, the frozen amount is posted as a credit loss entry in MOD-001 and the account balance is reduced accordingly. The status field in core.obr_partition_events is updated to resolved with a timestamp.

Customer notification¶

Activation of resolution state triggers customer notifications dispatched via MOD-063. Notification content is pre-approved as part of the deploying institution's OBR communication plan and stored as a template. Notifications are sent to all affected depositors within the activation transaction completion.

Compliance reason¶

The RBNZ DTA OBR Pre-positioning Standard, issued under the Deposit Takers Act 2023, requires every licensed deposit taker to maintain systems that are technically capable of executing OBR at any time without material system changes. The Standard requires the institution to demonstrate pre-positioning readiness to the RBNZ on request. A deploying institution using this platform as its core banking system cannot satisfy its OBR condition of registration without this module. The pre_positioned state must be active in production continuously, not only at examination time.

Commercial reason¶

Completing OBR pre-positioning removes a NZ licensing blocker. Institutions that cannot demonstrate OBR readiness will not receive or retain their deposit taker licence under the DTA 2023. Beyond the licensing requirement, demonstrating that OBR capability was built into the platform from first principles — rather than retrofitted under regulatory pressure — signals maturity to the RBNZ during the licence application process and reduces the risk of additional conditions being imposed. It also shortens the path to licence variation when adding new deposit product types, since the regulator has already examined and accepted the resolution architecture.

Module dependencies¶

Depends on¶

Module	Title	Required?	Contract	Reason
MOD-001	Double-entry posting engine	Required	—	OBR partition logic operates on the core double-entry ledger — frozen and available balance fields are extensions of the MOD-001 account record.
MOD-125	Joint account management	Required	—	Per-depositor SDV apportionment (balance_share_pct) feeds the OBR partition calculation for joint accounts.
MOD-063	Notification orchestration	Required	—	Customer notification of OBR resolution-state activation is dispatched via the notification engine.
MOD-103	Neon database platform bootstrap	Required	—	Neon database and schema provisioned by MOD-103 must exist before this module can read or write Postgres.
MOD-104	AWS shared infrastructure bootstrap	Required	—	AWS shared infrastructure provisioned by MOD-104 (EventBridge buses, S3, KMS, Kinesis, Cognito) is required before this module can be deployed.

Required by¶

(No modules in this wiki currently declare a dependency on this module.)

Policies satisfied¶

Policy	Title	Mode	How
REP-001	Regulatory Reporting Policy	`LOG`	OBR resolution-state activation and partition events are logged as regulatory records for RBNZ examination.
OPS-001	Business Continuity Policy	`AUTO`	Resolution-state activation triggers immediate operational controls — channel mode switches and account partition flags applied atomically.

Capabilities satisfied¶

(No capabilities mapped)

Part of SD01 — Core Banking Platform Compiled 2026-05-22 from source/entities/modules/MOD-143.yaml