Restricted activities enforcement¶


ID	`MOD-146`
System	SD08
Repo	`bank-app`
Build status	Not started
Deployed	No

Purpose¶

Prevent a deploying deposit taker from inadvertently enabling product features or activities that are classified as restricted under the NZ Deposit Takers Act 2023 Restricted Activities Standard. The DTA restricts certain non-deposit-taking and non-lending activities for licensed deposit takers unless RBNZ consent or a board resolution with RBNZ notification is in place. This module enforces those constraints at the platform's product configuration layer, ensuring that no restricted activity can be switched on through routine configuration without the required authorisation being on record.

What it does¶

Restricted activities register. The platform ships with a restricted_activities register — a curated list of product types and feature flags that are classified as restricted under the DTA Restricted Activities Standard. The register is maintained by the platform vendor and updated when the standard is amended by RBNZ. Examples of restricted-activity classifications include: operating a collective investment scheme, underwriting insurance, and acting as a derivatives market maker. Each entry in the register carries the DTA standard reference, a plain-language description of the restricted activity, and the date the classification was last confirmed.

Gate on product configuration. When MOD-127 (product configuration) receives a proposal to enable a product type or feature flag, this module checks the restricted activities register against the proposed item. If the item is classified as restricted, the proposal is automatically set to blocked_pending_authorisation status and cannot advance to the approved or live state until a valid authorisation is attached. The gate operates at both initial product creation and at subsequent feature-flag changes to an existing product.

Authorisation to unblock. To move a blocked proposal out of blocked_pending_authorisation status, the compliance team must attach one of three authorisation types:

An RBNZ consent reference number, confirming that RBNZ has provided formal consent for the restricted activity.
A board resolution reference, with confirmation that the board has resolved to undertake the activity and that RBNZ has been notified as required by the standard.
A platform vendor advisory confirming that the item in question has been reclassified as not restricted in the current version of the standard, applicable where the register update has not yet been deployed.

The authorisation is reviewed and recorded by a compliance team member, not self-certified by the product owner proposing the change.

Authorisations table. The app.restricted_activity_authorisations table records each authorisation with the following columns: authorisation_id, product_type_or_flag, authorisation_type (rbnz_consent / board_resolution / vendor_reclassification), reference_document, authorised_by, authorised_at, expires_at (nullable — used where an RBNZ consent is time-limited), and notes. Where an authorisation has an expires_at date, the product configuration is automatically re-flagged as blocked_pending_authorisation when the authorisation expires, unless a renewal authorisation has been attached.

Audit logging. Every restricted activity check generates a log entry recording: the product type or flag checked, the classification result (restricted / not restricted), the authorisation attached (if any), and the identity of the person who provided the authorisation. These records feed into the MOD-048 decision log and are available for RBNZ examination.

Jurisdiction scope. The restricted activities register and enforcement gate are NZ-only. The module is inactive for AU-only deployments. For NZ + AU deployments, the gate applies only to product types and feature flags that are within scope of the NZ DTA standard; AU-specific regulatory constraints are handled separately.

RBNZ examination export. The restricted activities authorisation log is included in the platform's RBNZ examination data export, ensuring that an examiner can verify that every restricted activity the institution operates has a corresponding authorisation on record.

Compliance reason¶

The DTA Restricted Activities Standard is a condition of registration for NZ deposit takers. A breach — enabling a restricted activity without the required RBNZ consent or board resolution — is a licensing violation that must be notified to RBNZ and remediated. If the platform has no enforcement mechanism, a misconfiguration by a bank employee could inadvertently create a licence breach with no internal visibility until an external audit or examination reveals it. System-level enforcement at the configuration gate is the strongest possible control because it makes violation structurally impossible without leaving a complete audit trail of who provided what authorisation and on what basis.

Commercial reason¶

Restricted activities enforcement reduces the deploying institution's compliance risk at the point where it is cheapest to prevent — configuration time, before any customers are affected and before RBNZ notification obligations are triggered. Discovering a restricted activity breach after launch requires regulatory notification, customer remediation, and potential enforcement action. Preventing the breach at the configuration gate has negligible operational cost and eliminates the downside entirely. The authorisation workflow also creates a clean paper trail that reduces the cost of future RBNZ examinations by making compliance evidence readily retrievable.

Module dependencies¶

Depends on¶

Module	Title	Required?	Contract	Reason
MOD-127	Product configuration panel	Required	—	Restricted activities enforcement operates as a gate within the product configuration workflow — MOD-127 product proposals are checked against the restricted activities register before approval is available.
MOD-048	System decision log	Required	—	All restricted activity checks, consent records, and override events are recorded as immutable decision log entries for RBNZ examination.
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
GOV-010	Restricted Activities Policy	`GATE`	Product types and features classified as restricted activities under the DTA cannot be enabled in the product catalogue without a documented RBNZ consent or board resolution — the system enforces this at the configuration layer.
REP-001	Regulatory Reporting Policy	`LOG`	All restricted activity classification decisions, consent records, and product enablement events are logged as regulatory records.

Capabilities satisfied¶

(No capabilities mapped)

Part of SD08 — Customer App & Back Office Platform Compiled 2026-05-22 from source/entities/modules/MOD-146.yaml