Model change control & re-approval workflow¶


ID	`MOD-175`
System	SD06
Repo	`bank-risk-platform`
Build status	Not started
Deployed	No

Workflow engine that wraps every platform model change in a structured change-control record and enforces the approval gates required before the changed model reaches production. For NZ capital models, the gate is extended to require RBNZ re-approval artefacts before the deployment lock is released. This module is the direct technical response to the regulatory risk illustrated by the Westpac NZ case (2016): operating an unapproved model change is a breach of the conditions of registration.

Why this is non-negotiable¶

The RBNZ framework is explicit: a change to an approved capital model without first obtaining RBNZ approval breaches the bank's conditions of registration. This is not a risk-management deficiency — it is a licence breach. The Westpac NZ case involved a risk-weighted-asset impact exceeding NZD 1 billion and triggered a mandatory section 95 independent review. The platform must never put a NZ customer in that position, regardless of how incremental a model change appears.

APRA's APS 113 similarly requires notification or approval for material model changes before they go live.

Change-control record¶

Every model change — whether a parameter recalibration, a methodology update, or a code fix — generates a change-control record containing:

Change description and classification (minor / material / major)
Model register reference (MOD-173 entry for the affected model)
Re-validation evidence: what testing was performed, what changed in performance
Impact assessment: expected change in model outputs across representative portfolios
Approval requirements: for NZ capital models, the RBNZ re-approval pathway is surfaced explicitly with the required artefacts pre-populated
Sign-off chain: model owner → validation function → (for Tier 1 models) independent reviewer → deployment gate

RBNZ re-approval pathway¶

For capital model changes affecting NZ deployments (primarily MOD-033):

Change-control record is created with classification = material or major
MOD-175 generates the RBNZ submission artefact package (change description, impact analysis, re-validation evidence) in the format the RBNZ expects
The deployment gate in the NZ customer's pipeline is locked
The customer submits to RBNZ and records the approval reference in MOD-175
Only after the approval reference is recorded does the gate open and the deployment proceed

This workflow is integrated with MOD-168 (maker-checker enforcement engine) which provides the multi-party sign-off mechanism. No single actor can release the gate unilaterally.

What triggers a material change classification¶

A change is classified as material if it results in a change of more than 2% in total model-estimated RWA, total ECL provision, aggregate PD, or model Gini coefficient — configurable per model. Minor changes (e.g. bug fixes with no measurable output impact) follow an expedited track with reduced sign-off requirements but still generate an audit record.

Audit trail¶

All change-control records are immutable once created. The audit trail of every model change — who proposed it, what was tested, who approved it, when it went live — is retained for the life of the model. This is the artefact internal audit needs for the annual independent review under APS 113.

Module dependencies¶

Depends on¶

Module	Title	Required?	Contract	Reason
MOD-173	Model risk register & inventory	Required	—	Change-control records reference the model register entry for the changed model; MOD-173 must exist before change records can be created or validated.
MOD-168	Maker-checker enforcement engine	Required	—	Maker-checker enforcement engine provides the approval-gate mechanism that MOD-175 uses to block deployment until change-control sign-off is complete.
MOD-104	AWS shared infrastructure bootstrap	Required	—	EventBridge bus and SSM parameter store used for change-event publishing and workflow configuration.

Required by¶

Module	Title	As	Contract
MOD-177	SD06 risk dashboard renderer	Optional enhancement	—

Policies satisfied¶

Policy	Title	Mode	How
DT-013	Model Validation & Audit Policy	`GATE`	No model change reaches production without a completed change-control record; for NZ capital models the gate requires RBNZ re-approval artefacts to be present before the deployment lock is released — directly preventing a conditions-of-registration breach of the Westpac NZ type.
DT-005	Model Risk Management Policy	`GATE`	Change-control enforcement before model update deployment satisfies the model-change management requirement of the Model Risk Management Policy.

Capabilities satisfied¶

(No capabilities mapped)

Part of SD06 — Snowflake Analytics & Risk Platform Compiled 2026-05-22 from source/entities/modules/MOD-175.yaml