Compliance visibility engine¶
| ID | MOD-056 |
| System | SD06 |
| Repo | bank-risk-platform |
| Build status | Deployed |
| Deployed | Yes |
| Last commit | 54197c02fff0ca78a988e6140d31778e59f05b46 |
Purpose¶
Visualise how the bank's platform satisfies its regulatory obligations. The bank-wiki
is the authoritative obligation register — it contains every regulation the bank is
subject to, every compliance policy derived from those regulations, and (in each
module's policies_satisfied array) exactly how the platform satisfies each policy
in code. MOD-056 imports that obligation chain into Snowflake and surfaces it as a
live compliance dashboard, from regulation → policy → module → runtime evidence.
What it does¶
The module owns the REGULATORY Snowflake schema and operates in two layers:
Layer 1 — Design-time evidence. A wiki-import Lambda runs on a daily schedule
and fetches the bank-wiki's compiled AI context pages (policies, systems, index). It
parses and upserts the full set of regulations, policies, policy-regulation links,
modules, and policies_satisfied entries into the WIKI_* tables. These tables are
the structural proof that each policy is satisfied: they record which module satisfies
which policy, the satisfaction mode (AUTO / GATE / LOG / ALERT / CALC), and the
description of the mechanism. For every Built or Deployed module, this constitutes
complete architectural compliance evidence. No manual curation is needed — the wiki
IS the sign-off.
Layer 2 — Runtime evidence. A Snowflake Task (TASK_AUTO_EVIDENCE_LINKER) runs
hourly and reads sibling SD06 module views via source() declarations, inserting
rows into COMPLIANCE_EVIDENCE when a runtime artefact confirms an obligation was
fulfilled for a given period. v1 wires MOD-080's V_PERIOD_CLOSE_METRICS — every
period where succeeded_count > 0 produces one evidence row for the statutory
reporting obligation. v2 extends to MOD-058 (breach notifications), MOD-060
(FATCA/CRS), and MOD-036 (prudential returns) as those modules ship.
Streamlit dashboards are the primary output. The bank uses these to answer: which policies does this platform satisfy? Which modules satisfy them? Is each module built and deployed? How many runtime evidence records exist in the last 12 months? Which policies have no satisfying module (NFR-011 zero-tolerance check)? The dashboards are filterable by risk domain, jurisdiction, and policy domain.
A deadline-alerter Lambda runs at 09:00 daily, queries time-bound obligations in
WIKI_POLICIES (annual/periodic regulatory submissions, licensing renewals), and
publishes bank.regulatory.obligation_deadline_approaching events for obligations
within the configured alert window (default 90 days) with no recent evidence record.
Compliance reason¶
REP-006 requires the CCO to maintain a current regulatory obligation register and present compliance status to the Board Risk Committee quarterly. This module provides the governed Snowflake-native system of record and automates the alert and reporting cadence. The wiki-sourced seed means the obligation register is always consistent with the CCO-maintained policy wiki — no separate governance review cycle needed.
Commercial reason¶
Supervisory risk materialises when a bank cannot demonstrate, on demand, how its platform satisfies its regulatory obligations. Governance By Design — the platform's founding architectural principle — means compliance is built into every module's code. MOD-056 makes that built-in compliance visible and auditable. It is the answer to the regulator's question: "Show me your controls."
Design notes¶
Bank-wiki as seed: The wiki's AI context pages (https://bank-wiki.pages.dev/
ai-context/policies/ and /systems/) are structured Markdown published by the wiki
CI pipeline on every compile. The import Lambda fetches these pages, parses policy
entities and policies_satisfied arrays, and upserts into the WIKI_* tables. The
idempotency key is (policy_code, module_id) for satisfaction rows; policy_code
for policy rows; module_id for module rows.
No external regulator feeds: RBNZ/APRA/FMA/AUSTRAC RSS polling is explicitly out of scope. When regulations change, the CCO team updates the wiki. The wiki update propagates into MOD-056 on the next daily sync. The wiki is the single source of truth for regulatory obligation; maintaining a second register in parallel would create divergence risk.
No CSV exports for auditors: All output is Snowflake Streamlit. If the bank needs a point-in-time file for an audit, they export from Snowsight through their own governance process — that is the bank's responsibility, not this module's.
ADR-046 compliance: The auto-evidence linker is a Snowflake Task (not a Lambda
opening a Snowflake connection). Cross-module reads use source() declarations.
Single-schema ownership — no other module writes to the REGULATORY schema.
Build notes — 2026-05-14¶
Deploy fails with:
003001 (42501): SQL access control error:
Insufficient privileges to operate on schema 'REGULATORY'.
The REGULATORY schema was pre-created by BANK_NONPROD_RISK_ROLE before CI
took over ownership. The CI service account (SF_ROLE) cannot create views in it.
Under the HAS_DCM=false workaround, the DCM ownership-transfer step that would
grant SF_ROLE the necessary privileges is skipped.
Resolution: Grant BANK_NONPROD_RISK_ROLE to SF_USER in Snowflake so the
CI service account can take ownership of the DCM project and its schemas. This is
the long-term fix documented in the GitLab CI handover page. Once granted, flip
HAS_DCM=true + HAS_DBT_PROJECT=true in the pipeline and remove the workaround.
Stopgap alternative: one-off GRANT CREATE VIEW ON SCHEMA REGULATORY TO ROLE SF_ROLE.
Navigation from hub¶
MOD-056's Streamlit dashboards (compliance map, policy satisfaction matrix, obligation deadline tracker) are accessible via a navigation link from MOD-172 (Operations & Model Intelligence Dashboard) per FR-818. MOD-056 does not depend on MOD-172 — the link is one-directional. MOD-172 depends on MOD-056 being deployed for the link to resolve.
Module dependencies¶
Depends on¶
| Module | Title | Required? | Contract | Reason |
|---|---|---|---|---|
| MOD-104 | AWS shared infrastructure bootstrap | Required | — | MOD-104 provisions the KMS key and bank-risk-platform EventBridge bus ARN. Required before this module can be deployed. |
| MOD-102 | Snowflake account configuration & governance | Required | — | Snowflake account and governance provisioned by MOD-102 must exist before this module can read or write Snowflake. |
| MOD-080 | Statutory financial reporting & ERP integration | Optional | — | v1 auto-evidence linker reads MOD-080 STATUTORY.V_PERIOD_CLOSE_METRICS via Snowflake source() to insert COMPLIANCE_EVIDENCE rows for statutory reporting obligations. Optional because the WIKI_POLICY_SATISFACTION layer provides structural compliance evidence independently of runtime evidence. |
Required by¶
| Module | Title | As | Contract |
|---|---|---|---|
| MOD-172 | Operations & Model Intelligence Dashboard | Hard dependency | — |
| MOD-173 | Model risk register & inventory | Optional enhancement | — |
Policies satisfied¶
| Policy | Title | Mode | How |
|---|---|---|---|
| REP-006 | Regulatory Change Management Policy | ALERT |
Deadline-alerter emits bank.regulatory.obligation_deadline_approaching for time-bound obligations approaching their due date; ALERT_OBLIGATION_DEADLINE_APPROACHING DCM alert routes to MOD-076 SNS for CCO notification. |
| GOV-006 | Internal Audit Policy | LOG |
WIKI_IMPORT_LOG and OBLIGATION_EVENTS are append-only audit tables recording every wiki-sync run and every obligation state transition with timestamp and run_id — immutable per NFR-024. |
Capabilities satisfied¶
(No capabilities mapped)
Part of SD06 — Snowflake Analytics & Risk Platform
Compiled 2026-05-22 from source/entities/modules/MOD-056.yaml