Model Risk Management Policy¶
| Code | DT-005 |
| Domain | Data & Technology |
| Owner | Chief Risk Officer |
| Status | Draft |
| Applicability | Platform |
| Jurisdiction | NZ + AU |
| Business domain | BD08 |
| Review date | 2027-03-25 |
Regulations: APS 113 IRB · APS 220 Credit Quality · CPS 220 Risk Management · CPS 230 Operational Risk Management · RBNZ BS2A/BS2B Capital · DTA Capital Standard · DTA Risk Management Standard · RBNZ Model Risk Guidance · IFRS 9 · SR 11-7 Model Risk · PRA SS1/23 Model Risk¶
Purpose¶
Govern the lifecycle of all quantitative models used in banking decisions, including credit scoring, fraud detection, AML behavioural analysis, and risk rating. Defines model inventory requirements, validation standards, champion/challenger governance, and AI/ML model oversight obligations. All machine learning models deployed in production systems are subject to this policy.
Scope¶
All models used to produce outputs that influence customer-facing decisions, regulatory capital calculations, risk appetite reporting, or operational controls. Includes statistical models, ML models, rules-based scoring engines, and algorithmic systems.
Model inventory¶
The platform SHALL maintain a model inventory covering every model in development, validation, production, and retirement. Each inventory entry SHALL record: model identifier, purpose, owner, current version, deployment status, last validation date, next scheduled review date, and performance thresholds.
Development and validation standards¶
Every new model and every material model change SHALL be subject to independent validation before deployment to production. Validation SHALL assess: conceptual soundness, data quality, discriminatory power, stability, and bias. Validation reports SHALL be retained as part of the model record.
Models used in credit decisions, fraud blocking, or AML alert generation SHALL be tested for demographic bias before each production deployment. Bias test results and any remediation actions SHALL be documented.
Model code, training data lineage, feature definitions, and hyperparameters SHALL be version-controlled. A model in production SHALL have a corresponding validation record linked to the deployed artefact.
Champion/challenger and change governance¶
Material changes to a model — including retraining on new data, feature set changes, and threshold adjustments — SHALL follow the model change process with documented approval before production deployment.
Champion/challenger frameworks SHALL be used where practicable for models with material customer or financial impact. Challenger performance SHALL be monitored against the champion on defined metrics before any promotion to champion.
Production monitoring¶
Every production model SHALL have defined performance thresholds — including accuracy, recall, precision, and population stability index (PSI) where applicable. Breach of a threshold SHALL trigger a review. A model with sustained performance degradation SHALL be retrained or decommissioned within the defined remediation SLA.
Model outputs SHALL be monitored for distribution drift relative to the training population. Where input feature drift is detected, the model SHALL be flagged for priority review.
Human oversight¶
No model output SHALL constitute a final, unoverridable decision without human review capability. For adverse credit decisions, fraud blocks, and AML account restrictions, a qualified human SHALL be able to review the model output and override within the timeframe defined per product.
Fully automated adverse decisions above defined materiality thresholds SHALL be reviewed by a human within the SLA defined in the relevant product or operational specification.
Satisfying modules¶
| Module | Name | Mode | Description |
|---|---|---|---|
| MOD-017 | ML behavioural scoring model | LOG |
Model version controlled, validated, and logged — champion/challenger governance applied |
| MOD-023 | Transaction fraud scorer | LOG |
Fraud model versioned, validated, and performance-monitored in Snowflake |
| MOD-028 | Credit score & risk rating | LOG |
Credit model in model inventory, validated quarterly, performance monitored in Snowflake |
| MOD-031 | ECL calculation & GL posting | LOG |
ECL model in model inventory — backtested and validated against actual losses |
| MOD-039 | Customer risk score model | LOG |
Risk score model in model inventory — validated against AML outcomes quarterly |
| MOD-041 | Categorisation & merchant enrichment model | LOG |
Categorisation model versioned, retrained on feedback, and performance-monitored |
| MOD-150 | Risk management platform | LOG |
Model inventory is auto-maintained from CI/CD deployment events; scheduled PSI and accuracy monitoring runs nightly; model validation gate is enforced before production promotion. |
| MOD-151 | Risk case console | GATE |
Model validation cases enforce an upload-report-then-approve gate; a model cannot be promoted in the MOD-150 inventory without a closed validation case with an approved validation report attached. |
| MOD-171 | Risk Intelligence Dashboard | LOG |
Model performance indicators (accuracy, PSI, drift alerts) for all deployed SD06 quantitative models are surfaced in the risk metrics overview, maintaining the model inventory and monitoring visibility required by DT-005. |
| MOD-172 | Operations & Model Intelligence Dashboard | LOG |
Model performance metrics (accuracy, PSI, drift alerts) for all deployed SD06 operational models are surfaced and logged per model inventory requirements — any model showing PSI above threshold or accuracy degradation is flagged for review. |
| MOD-173 | Model risk register & inventory | LOG |
Central model inventory maintains the register required by the Model Risk Management Policy, covering all platform model-bearing modules with APS 113 and RBNZ compendium fields. |
| MOD-174 | Model performance monitoring & drift detection | AUTO |
Continuous model performance monitoring satisfies the ongoing-monitoring pillar of the Model Risk Management Policy without requiring manual customer engagement. |
| MOD-175 | Model change control & re-approval workflow | GATE |
Change-control enforcement before model update deployment satisfies the model-change management requirement of the Model Risk Management Policy. |
Part of Data & Technology · Governance overview
Compiled 2026-05-22 from source/entities/policies/DT-005.yaml