Regulatory Submissions Portal¶


ID	`MOD-170`
System	SD06
Repo	`bank-risk-platform`
Build status	Deployed
Deployed	Yes
Last commit	`54197c02fff0ca78a988e6140d31778e59f05b46`

The Regulatory Submissions Portal is the human interface for all regulatory return activity across SD06. It aggregates submission calendars, assembled return data, approval workflows, and historical submission records from MOD-036 (prudential returns), MOD-037 (AUSTRAC/RBNZ AML reports), MOD-057 (statistical surveys), and MOD-060 (FATCA/CRS/AEOI) into a single Snowflake Streamlit application.

Why it exists¶

The downstream modules (MOD-036 etc.) are data pipelines — they assemble, validate, and submit regulatory returns automatically. But automated submission without human sign-off is unacceptable for returns filed with RBNZ and APRA. A defective prudential return filed incorrectly triggers regulatory sanctions and potentially public disclosure requirements. This portal provides the mandatory human review and approval layer: no return is submitted until a Finance officer has reviewed the assembled data, confirmed correctness, and recorded a signed approval.

Submission calendar¶

The landing page aggregates all regulatory returns across all submission modules. Each return shows its return code, jurisdiction, period end date, due date, current status (ASSEMBLING / VALIDATED / AWAITING_APPROVAL / APPROVED / SUBMITTED / ACKED / OVERDUE), and the name of the officer who last acted on it. The calendar refreshes within 1 hour of any status change. Overdue returns are highlighted in red; returns due within 7 days are amber.

Return viewer and approval workflow¶

Clicking any return in the calendar opens the cell-level return viewer. The viewer shows: - Every line item code, value, and the validation status (pass / fail / warning) - Source lineage for each cell: which upstream view and model_run_id produced it - Validation error details if any validation rules failed - Prior period values for comparison

At the bottom of the viewer, an authorised Finance officer sees an approval form. They can: - Approve — records a row in REGULATORY.RETURN_APPROVALS with their staff_id (from their Snowflake session), timestamp, run_id, return_code, jurisdiction, and a mandatory sign-off comment. This releases the submission orchestrator in MOD-036 to post to the regulator API. - Reject — records a rejection with reason; the assembly pipeline must re-run before approval can be granted again.

The approving officer must be a different Snowflake user from the system account that assembled the return (four-eyes principle, GOV-002). The approval is immutable once written — NFR-024 applies to RETURN_APPROVALS.

Historical submissions log¶

A separate page shows every submission ever made across all regulatory modules, with regulator acknowledgement status, content hash, submission reference, and 7-year retention indicator.

Snowflake objects¶

This module owns no computation tables — it is a pure read-and-write Streamlit layer. It writes only to REGULATORY.RETURN_APPROVALS (owned by MOD-036, cross-schema grant required: GRANT INSERT ON REGULATORY.RETURN_APPROVALS TO regulatory_submissions_portal_role).

The Streamlit app is deployed as REGULATORY.STREAMLIT_SUBMISSIONS_PORTAL in MOD-036's REGULATORY schema, using MOD-036's Snowflake role for read access to all REGULATORY objects.

Role-based access¶

Access to the portal is restricted to staff with the finance.regulatory_reporting or compliance.officer Cognito group (forwarded from the RBNZ/APRA staff identity pool). The approval action is additionally restricted to finance.senior_officer or compliance.head — junior reporting analysts can view but not approve.

Dependency on MOD-036¶

MOD-036 must be built and the REGULATORY schema must exist before this module can be deployed. MOD-037, MOD-057, and MOD-060 are optional — the portal degrades gracefully, showing only the return modules that have been deployed.

Module dependencies¶

Depends on¶

Module	Title	Required?	Contract	Reason
MOD-036	Prudential return builder (RBNZ / APRA)	Required	—	Primary source of prudential return assembly data (REGULATORY schema) and the submission orchestrator that this portal gates via the RETURN_APPROVALS check.
MOD-037	AUSTRAC / RBNZ AML reporting pipeline	Optional	—	AML reporting pipeline — portal aggregates its submission calendar and provides the approval gate when MOD-037 is deployed.
MOD-057	Statistical returns & survey engine	Optional	—	Statistical returns pipeline — portal aggregates its submission calendar and provides the approval gate when MOD-057 is deployed.
MOD-060	FATCA/CRS/AEOI reporting engine	Optional	—	FATCA/CRS/AEOI reporting pipeline — portal aggregates its submission calendar and provides the approval gate when MOD-060 is deployed.
MOD-102	Snowflake account configuration & governance	Required	—	Snowflake account, RISK database, and governance provisioned by MOD-102 must exist before this module can create its Streamlit app.
MOD-104	AWS shared infrastructure bootstrap	Required	—	AWS shared infrastructure (EventBridge bus, Lambda role, SNS alarm topic) required before this module can be deployed.

Required by¶

Module	Title	As	Contract
MOD-036	Prudential return builder (RBNZ / APRA)	Hard dependency	—
MOD-037	AUSTRAC / RBNZ AML reporting pipeline	Hard dependency	—
MOD-057	Statistical returns & survey engine	Hard dependency	—
MOD-060	FATCA/CRS/AEOI reporting engine	Hard dependency	—

Policies satisfied¶

Policy	Title	Mode	How
REP-005	Data Quality & Assurance Policy	`GATE`	No regulatory return may be submitted to RBNZ or APRA without passing validation (REP-005 data quality gate) AND receiving explicit written approval from an authorised Finance officer recorded in REGULATORY.RETURN_APPROVALS — the submission orchestrator enforces both gates unconditionally.
REP-001	Regulatory Reporting Policy	`AUTO`	The unified submission calendar aggregates all return statuses across MOD-036, MOD-037, MOD-057, and MOD-060, updated within 1 hour of any status change, satisfying the automated regulatory reporting visibility requirement.
REP-002	Prudential Reporting Policy	`LOG`	Every return approval records the approving officer identity, timestamp, run_id, return_code, and sign-off reason in REGULATORY.RETURN_APPROVALS — immutable per NFR-024, providing the prudential reporting audit trail required by REP-002.
GOV-002	Risk Appetite Statement Policy	`LOG`	All portal access events (view, approve, reject) are logged with staff_id, timestamp, return_code, and run_id, satisfying the Risk Appetite Statement governance audit requirement for regulatory submission actions.

Capabilities satisfied¶

(No capabilities mapped)

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