Risk case console¶


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

Purpose¶

The Risk Case Console is the human interface for exception-driven risk management. Cases arrive exclusively from the Risk Management Platform (MOD-150) when an event requires human judgement: a P1 incident requiring a post-mortem, a model failing its validation gate, a vendor SLA breach needing a remediation plan, a potential regulatory breach awaiting sign-off before notification is submitted, or a whistleblower report requiring investigation.

No risk event is manually entered here. Every case was generated by the automated pipeline. The console provides the workflow to assess, act on, close, and audit the exception — and nothing else.

Case types and routing¶

Seven case types are handled. All originate from MOD-150 triggers.

1. Incident Triggered by a P1 or P2 alert from MOD-076. P1 incidents are assigned to the on-call engineer and Head of Technology; P2 incidents are assigned to the on-call engineer. SLA timers run from case creation. Root cause documentation is mandatory before closure — the close action is not available until a root cause field has been completed and a resolution action recorded. This gate satisfies OPS-003.

2. Operational risk event Triggered when the risk register auto-classification produces an event that exceeds the configured severity threshold or falls into a category requiring human treatment assessment. Routed to a risk_officer. Requires a treatment decision: accept, mitigate, transfer, or escalate. Treatment documentation is recorded against the case and written to the risk register via MOD-048.

3. Vendor SLA breach Triggered when a critical third-party service breaches its configured SLA and the breach has not auto-resolved within the grace period. Routed to the risk_officer and the relevant business domain owner. Requires a remediation plan within the case SLA. Contractual review reminder cases (generated 90 days before contract expiry) follow the same routing.

4. Model validation request Triggered when a model reaches awaiting_validation status in the MOD-150 model inventory. Assigned to an independent validator — a role that cannot be the same individual as the model owner. The case requires: a validation report upload, a formal approve or reject decision, and a summary of findings. A model cannot be promoted to production in the MOD-150 inventory until this case is closed with an approved status. This gate is enforced at the inventory level by MOD-150, not in application logic here — the case closure is the unlock condition.

5. Regulatory breach review Triggered when MOD-150 assembles a draft regulatory notification. Routed to the compliance_officer. The notification draft — pre-populated with incident detail, affected service, estimated customer impact, and current resolution status — is presented in the case for review. The compliance officer can approve the draft for submission, amend it, or escalate to the CCO. Where MOD-150 has submitted via a regulator API, the case records the submission timestamp and confirmation reference.

6. Whistleblower intake Described in full below.

7. Change post-implementation review Triggered for any deployment that resulted in a rollback or that was followed by a P1 incident within 72 hours. Routed to the tech lead for the relevant module. Requires a documented review outcome covering: what was deployed, what failed, what the root cause was, and what change to process or testing is being made. The outcome is recorded against the change record in risk.change_records via MOD-048.

Whistleblower intake channel¶

The whistleblower channel is a distinct intake path, not a case type added to the standard queue.

Access: Available at a public URL (no authentication required) and within the authenticated app under a clearly labelled "Protected disclosure" link. Both paths accept anonymous submissions.

Routing: Submissions are routed exclusively to the board_audit_committee role. No management role — including CEO, COO, CFO, CRO, CCO, Head of Technology, or any team lead — can view a whistleblower case. This isolation is enforced at the database role level in Neon: whistleblower cases are stored in a separate schema (risk.whistleblower_cases) with column-level encryption on submitter identity fields. The application access control layer cannot override this — even if a bug existed in the application's role check, the query would return no data for a non-board_audit_committee role.

Notification: The Board Audit Committee chair receives a notification via a secure, out-of-band channel when a new case is submitted. This notification does not go through MOD-063 (which routes notifications through shared infrastructure visible to operations staff).

Submitter protections disclosed: Before a submission is completed, the submitter is shown a plain-language summary of: the NZ Protected Disclosures (Protection of Disclosers) Act 2022 protections, the AU Corporations Act Part 9.4AAA protections for eligible whistleblowers, and the platform's own identity protection commitment. The submitter must confirm they have read this before the submission is accepted.

Follow-up: The submitter receives a case reference number on submission. They can return to the public URL at any time, enter their reference number, and add further information — anonymously if they originally submitted anonymously. The Board Audit Committee can ask questions through this same channel without learning the submitter's identity unless the submitter chooses to disclose it.

Role-based access¶

Role	Case types visible	Actions permitted
`on_call_engineer`	Incident	Update status, add notes, close (with root cause)
`tech_lead`	Incident, Change PIR	Update status, add notes, close
`risk_officer`	Operational risk event, Vendor SLA breach, Incident (read)	Treatment decision, remediation plan, escalate
`compliance_officer`	Regulatory breach review, Incident (read)	Approve/amend notification, escalate to CCO
`model_validator`	Model validation request	Upload report, approve/reject
`board_risk`	All except Whistleblower	Read-only, plus RAF dashboard view
`board_audit_committee`	Whistleblower only	Full case management
`internal_audit`	All (read-only)	No write actions
`cro`	All except Whistleblower	Escalation target; read-only on cases; can reassign

Role assignment is managed through MOD-068. The board_audit_committee role is issued only to board members holding that committee position and is reviewed at each board composition change.

RAF dashboard view¶

Users with the board_risk or risk_officer role see a dashboard panel at the top of the console showing:

All open risk cases by type and current SLA status (green / amber / red)
Current RAF indicator status pulled live from MOD-150 (green / amber / red per indicator)
Model inventory summary: count of production models, count with upcoming review dates, count flagged
Vendor health summary: count of critical providers, count currently in breach or incident

This gives the risk function a single place to see the platform's risk posture without navigating Snowflake directly. The underlying data is always MOD-150's live computation — the console displays it, it does not store it.

SLA enforcement¶

Follows the same pattern as MOD-053. Each case type has a configured resolution SLA. At 50% elapsed: amber warning visible on the case and on the assignee's dashboard. At 80% elapsed: red escalation notification sent to the assignee's manager. At 100% elapsed: auto-escalation to the next tier (CRO for risk cases, CCO for compliance cases, Head of Technology for incident and change cases). The escalation is recorded in the case audit trail.

Compliance rationale¶

GOV-008 (NZ Protected Disclosures (Protection of Disclosers) Act 2022) requires a formal protected disclosure procedure that ensures a discloser can make a protected disclosure without fear of retaliation. The Act imposes obligations on the organisation to have a procedure, to keep the discloser's identity confidential, and to not take adverse action against the discloser. AU equivalent protections exist under Corporations Act Part 9.4AAA for eligible whistleblowers. A policy document alone does not satisfy these obligations — the protection must be technically enforced. Database-level isolation of submitter identity fields means the protection cannot be accidentally or intentionally defeated by application-layer changes.

OPS-003 (RBNZ Operational Resilience Standard, APRA CPS 230) requires a documented incident management process with root cause analysis for material incidents. The mandatory root-cause-before-close gate creates a verifiable, auditable record that the requirement was met for every P1 incident — not just the ones that a risk manager chose to document.

DT-005 (APRA CPS 220 model risk) requires independent validation of models before production use. The validation case type operationalises this: the model owner cannot approve their own model, the CI/CD hook enforces the gate, and the audit trail shows precisely when validation was performed and by whom.

GOV-006 (Internal Audit Policy) requires that the internal audit function has access to records needed to assess control effectiveness. The internal_audit read-only role, combined with the no-deletion guarantee, satisfies this requirement structurally.

Commercial rationale¶

Whistleblower protections that exist only in a policy document are not protections at all. An employee who suspects a colleague of fraud — including a senior colleague — needs to be able to report it without their manager seeing the report. If the system routes the report through the same notification infrastructure that operations staff monitor, or if a determined administrator can query the database directly to identify the submitter, the protection is illusory. The technical isolation described above makes it real.

Risk cases that exist in email threads or shared spreadsheets lose their audit trail, cannot have SLA enforcement applied to them, and cannot be reviewed systematically by internal audit. The console creates a single governed record for every exception, with a complete history of every action taken and by whom. This is not a compliance formality — it is what allows the risk function to demonstrate, under regulatory examination, that identified risks were assessed and acted upon within the required timeframes.

Module dependencies¶

Depends on¶

Module	Title	Required?	Contract	Reason
MOD-150	Risk management platform	Required	—	All cases originate from the risk management platform — the case console is the human-facing exception layer of the risk platform.
MOD-053	Case & complaint management module	Required	—	MOD-151 extends the case management infrastructure with risk-specific case types, reusing the same SLA engine, assignment logic, and escalation patterns.
MOD-068	Authentication & session management	Required	—	Authentication and role-based access control for all case management actions.
MOD-047	Agent action logger	Required	—	All case decisions and actions are logged via the agent action logger for conduct risk monitoring.
MOD-048	System decision log	Required	—	Case closures and regulatory decisions are written as immutable system decision log entries.
MOD-103	Neon database platform bootstrap	Required	—	Neon database stores all case state, whistleblower submissions, and role-access-controlled case records.
MOD-104	AWS shared infrastructure bootstrap	Required	—	AWS shared infrastructure is required before this module can be deployed.

Required by¶

Module	Title	As	Contract
MOD-153	Customer acceptance engine	Optional enhancement	—

Policies satisfied¶

Policy	Title	Mode	How
OPS-003	Incident Management Policy	`GATE`	All P1 incidents require a documented root cause and resolution action before they can be closed — the case workflow enforces this gate and no bypass path exists.
GOV-008	Whistleblower Protection Policy	`GATE`	Whistleblower submissions are received through an isolated intake channel with no management routing; cases are delivered directly to the Board Audit Committee role and identity protection is enforced at the data layer.
GOV-006	Internal Audit Policy	`LOG`	All risk cases, decisions, and resolutions are available to the internal_audit role for examination — no case can be deleted.
DT-005	Model Risk Management Policy	`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.

Capabilities satisfied¶

(No capabilities mapped)

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