ADR-013: External data sharing from Snowflake¶
| Status | Accepted |
| Date | 2026-04-10 |
| Deciders | CTO, CFO, CCO, CRO |
| Affects repos | bank-risk-platform |
Status¶
Accepted — 2026-04-10
Context¶
The bank has several categories of external parties who require access to data that lives in Snowflake:
- Regulators (RBNZ, APRA, AUSTRAC, FMA) — supervisory data requests, prudential returns, AML compliance data
- External auditors — financial statement audit, regulatory audit
- Board and board committees — risk, audit, and credit committee reporting
- Rating agencies / investors (future) — investor reporting
- Research partners — anonymised aggregate data for authorised research
The question is the mechanism by which data is shared — file extract and delivery, API access, direct Snowflake access, Snowflake Secure Data Sharing, or a purpose-built regulatory reporting portal.
This is a significant architectural decision because it affects data security, regulatory relationships, operational overhead, and audit trail.
Current approach (baseline)¶
Today, regulatory returns are produced as files (CSV, XML, XBRL) and submitted via regulator portals (APRA Connect, RBNZ Statistical Survey System). This works but is manual, error-prone at the margins, and creates a publish-and-hope dynamic — the regulator receives a file and cannot ask follow-up questions without a new submission cycle.
Options evaluated¶
Option A — File extract and submission (current baseline)¶
Snowflake produces regulatory returns as files on schedule. Files submitted via regulator portals. Evidence maintained in Snowflake (what was submitted, when, from which data).
Strengths: Familiar to regulators; works for all current submission channels; no new infrastructure.
Weaknesses: Manual steps in the submission process; no ability for regulator to query underlying data; reconciliation between submitted files and Snowflake data is manual; does not scale well as return volume increases.
Option B — Snowflake Secure Data Sharing¶
Snowflake's native data sharing mechanism. The bank creates a share — a read-only view of specific Snowflake objects — and grants access to the counterparty's Snowflake account. No data movement, no file creation. The counterparty queries the bank's data directly in their own Snowflake environment.
Strengths: Zero data movement — the share is a live view, not a copy; no file transfer risk; counterparty can query the data at the granularity they need; automatic freshness; full audit trail of what was queried and when; scales naturally; elegant solution for regulators with Snowflake accounts.
Weaknesses: Counterparty must have a Snowflake account — RBNZ and APRA may or may not have this capability today; governance of what is shared requires careful access design; schema changes in Snowflake can break shares if not managed carefully.
Option C — Regulatory data portal (read-only web app on Snowflake data)¶
A dedicated read-only web portal for regulators and auditors. Built on Streamlit in Snowflake or a custom Next.js app backed by Snowflake. Regulators log in with their own credentials and can view and export the data they are entitled to see.
Strengths: Works for regulators without Snowflake accounts; fine-grained access control per user; audit trail of access; can provide a curated, regulator-friendly interface rather than raw SQL access.
Weaknesses: Must be built and maintained; user management overhead; security review required for external access; another surface to operate.
Option D — Snowflake Secure Data Sharing (primary) + file submission (fallback)¶
Use Snowflake Secure Data Sharing for regulators with Snowflake capability. Maintain file submission as a fallback for regulators without it and for submissions to portals that require file upload.
Perspective evaluation¶
| Perspective | File extract | Secure Data Sharing | Data portal | Hybrid (D) |
|---|---|---|---|---|
| Integration | ~ Manual steps | ✓ Native Snowflake | ✓ Custom | ✓ |
| Security | ~ File transfer risk | ✓ No data movement | ✓ | ✓ |
| Regulatory | ✓ Familiar to regulators | ~ Requires Snowflake | ✓ | ✓ |
| Support & Maintenance | ~ Manual overhead | ✓ Low maintenance | ~ Must maintain portal | ✓ |
| Traceability | ~ Submit and hope | ✓ Query audit trail | ✓ | ✓ |
| Cost | ✓ | ✓ Included in Snowflake | ~ Build cost | ✓ |
| Evolution | ~ More returns = more work | ✓ Scales naturally | ✓ | ✓ |
See perspectives.md for how to use these evaluation lenses.
Data sharing governance¶
Regardless of mechanism, the following governance applies to all external data sharing:
| Control | Requirement |
|---|---|
| What is shared | Only explicitly approved objects — never raw customer PII tables |
| Approval | CCO + CTO sign-off for each new share or portal access grant |
| Access log | All external access logged — who queried what and when |
| Schema change management | External shares reviewed before any Snowflake schema change is deployed |
| Data classification | Only aggregated, anonymised, or specifically authorised data shared |
| Right to revoke | All access revocable immediately; automated access review quarterly |
| Data residency | Shares created from AU-region Snowflake account; data does not leave AU region |
External party access matrix¶
| Party | Mechanism | Data scope | Access type |
|---|---|---|---|
| RBNZ | File submission + Secure Share (pending RBNZ capability) | Prudential returns, AML supervisory data | Approved return sets only |
| APRA | File submission (APRA Connect) + Secure Share | APS/ARS return data | Approved return sets only |
| AUSTRAC | File submission | IFTI, SMR, annual compliance data | Automated submission |
| External auditors | Secure Share or portal | Ledger aggregates, capital/liquidity, IFRS 9 | Time-limited; read-only |
| Board / committees | Internal portal (back office app) | Risk dashboards, capital, credit portfolio | Role-scoped; not a share |
| Rating agencies | File extract (future) | Public financial data only | On request |
Principles alignment¶
| Principle | Assessment |
|---|---|
| AP-001 KISS | Secure Data Sharing is elegant — no ETL, no file management, no transfer infrastructure |
| AP-002 Data governance | Explicit share objects; access log; approval process; schema change management |
| AP-003 Compliance | Automated regulatory return submission satisfies BG-009 (automate everything) |
| AP-004 Security | No data movement; query-level audit trail; access revocable immediately |
| AP-006 Cost effective | Secure Data Sharing included in Snowflake; no additional platform cost |
| AP-008 Real time | Regulatory returns are scheduled; real-time not required — but shares are live views |
Recommendation (pending decision)¶
Option D — Snowflake Secure Data Sharing (primary) + file submission (fallback):
- Build automated file submission for all current regulatory portals (APRA Connect, RBNZ SSS, AUSTRAC) as the immediate priority
- Design Snowflake objects (views and aggregations) that would form the basis of a Secure Data Share when regulators are ready
- Engage RBNZ and APRA proactively on Snowflake data sharing capability — this is an opportunity to offer a more transparent regulatory relationship
- Build the external auditor access as a Secure Data Share — this is the lowest-risk first use case as auditors are likely to have Snowflake accounts
- Board/committee reporting is served from the internal back office app — not a Snowflake share
Relevant viewpoints¶
- System viewpoint — Snowflake as the data sharing hub; share objects; file submission pipeline
- Information viewpoint — What data is in each share; classification; aggregation rules
- Security viewpoint — External access control; network policy; query audit trail; PII exclusion
- Operational viewpoint — Share health monitoring; submission schedule; failure alerting; access review
See viewpoints.md for guidance on producing these viewpoints.
Signoff record¶
| Date | Name | Role | Status |
|---|---|---|---|
| 2026-04-10 | Ross Millen | CTO | Approved |
| 2026-04-10 | Ross Millen | Head of Architecture | Approved |
| 2026-04-10 | Ross Millen | Head of Data | Approved |
Capabilities¶
| Capability | Description | Relationship |
|---|---|---|
| CAP-025 | Automated regulatory reporting pipeline | enabled — automated file submission to APRA Connect, RBNZ SSS, AUSTRAC |
| CAP-030 | Regulator evidence portal | enabled — Snowflake Secure Data Sharing enables regulator direct access |
| CAP-035 | Per-jurisdiction regulatory report profiles | enabled — jurisdiction-specific report shapes built in Snowflake |
| CAP-072 | Regulatory threshold alerting | governed — threshold breaches surfaced before return submission |
Related decisions¶
| ADR | Title | Relationship |
|---|---|---|
| ADR-002 | Snowflake as the analytics and risk compute platform | all regulatory data lives and is shaped in Snowflake |
All ADRs
Compiled 2026-05-22 from source/entities/adrs/ADR-013.yaml