ADR-002: Snowflake as the analytics and risk compute platform¶
| Status | Accepted |
| Date | 2026-04-10 |
| Deciders | CTO, Head of Platform, CRO |
| Affects repos | bank-risk-platform, bank-aml, bank-credit, bank-core |
Status¶
Accepted — 2026-03-23
Context¶
The bank requires a platform for risk model execution, regulatory capital and liquidity calculations, AML transaction monitoring models, ML model training, fraud scoring, customer intelligence, and all regulatory reporting. This platform must handle large analytical workloads without impacting OLTP performance, support continuous refresh via streaming ingest, and provide a governed ML training environment.
Decision¶
All analytics, risk calculations, ML model training, and regulatory reporting pipelines run exclusively in Snowflake. Snowflake Cortex is the ML training environment. Snowflake dynamic tables provide the continuously refreshed analytical layer — no scheduled batch ETL jobs. Results that need to be read operationally are written back to Postgres via a write-back API within latency targets.
Consequences¶
Positive - Complete separation of analytical workloads from OLTP — no performance impact on transaction path - Snowflake Cortex provides ML training without additional MLOps infrastructure - Dynamic tables replace batch jobs — near-real-time analytics from CDC stream - CDC pipeline (ADR-003) provides near-real-time ingest via Kinesis Firehose and S3 Iceberg; Snowflake reads via External Iceberg Table - Single platform for risk models, regulatory reporting, customer analytics, and fraud models
Negative / trade-offs - Snowflake never called inline — write-back pattern adds latency for operational scores - Snowflake compute costs scale with query volume — warehouse sizing discipline required - Data latency from Postgres commit to Snowflake availability is seconds, not milliseconds
Constraints this creates for all repos¶
- All ML models must be trained and served from Snowflake Cortex
- Every model must be registered in the model inventory (DT-005)
- Write-back latency targets: operational scores (risk, fraud) ≤ 60s; batch (capital, liquidity) end of day
- No repo may use Snowflake as an OLTP store or call it on the payment path
- See NFR-014 (write-back ≤ 60s) and SG-002
Principles alignment¶
| Principle | Assessment | Notes |
|---|---|---|
| AP-001 KISS | ✓ | Single analytics platform; no separate BI, ML, or reporting tools |
| AP-002 Data governance | ✓ | Snowflake RBAC; column-level masking for PII; clear schema ownership |
| AP-006 Cost effective | ✓ | Compute on demand; warehouse auto-suspend; consumption-based pricing |
| AP-007 Evolution | ✓ | Cortex models can be retrained and promoted without platform changes |
| AP-008 Real time | ~ | Near-real-time via Snowpipe Streaming; not millisecond — appropriate for analytical use cases |
Perspectives¶
| Perspective | Assessment | Notes |
|---|---|---|
| Performance & Scalability | ✓ | Snowflake separates storage and compute; scales independently |
| Evolution | ✓ | Dynamic tables and Cortex can evolve without upstream changes |
| Strategy | ✓ | Snowflake is the market leader for cloud analytics; strong NZ/AU presence |
| Integration | ✓ | CDC pipeline (ADR-003) via S3 Iceberg; write-back API to Postgres; Secure Data Sharing |
| Cost | ~ | Cost discipline required — warehouse sizing and auto-suspend configuration critical |
| Regulatory | ✓ | Secure Data Sharing enables regulator access; data residency in AU region |
| Security | ✓ | Column-level masking; row access policies; network policy restricts access |
| Capability | ✓ | Capital, liquidity, IRRBB, AML typology, fraud scoring, categorisation, regulatory returns |
See perspectives.md for how to use these evaluation lenses.
Relevant viewpoints¶
- System viewpoint — Snowflake as the analytical layer; ingest via CDC pipeline (ADR-003); write-back API to Postgres
- Information viewpoint — Dynamic table lineage; data classification; PII masking policies
- Security viewpoint — Column-level masking; Snowflake network policy; secure data share configuration
- Operational viewpoint — Warehouse utilisation monitoring; query performance; credit consumption alerts
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-012 | Merchant name enrichment & logo | enabled — merchant lookup table and embedding model hosted in Snowflake |
| CAP-013 | Spend categorisation (auto + manual) | enabled — categorisation ML model trained in Snowflake Cortex |
| CAP-019 | Monthly spending summary & trends | enabled — spending analytics computed in Snowflake Dynamic Tables |
| CAP-022 | Unusual transaction alert | enabled — anomaly detection models run in Snowflake Cortex |
| CAP-025 | Automated regulatory reporting pipeline | enabled — all regulatory returns generated from Snowflake |
| CAP-027 | Automated AML submission pipeline | enabled — AML typology models and SAR inputs computed in Snowflake |
| CAP-038 | Real-time fraud scoring & block | enabled — fraud ML models trained and scored in Snowflake Cortex |
| CAP-062 | CDD automatic tier assignment | enabled — CDD tier decisions produced by Snowflake risk models |
| CAP-063 | Proactive financial insight engine | enabled — all intelligence signals computed in Snowflake Dynamic Tables |
| CAP-065 | Pre-approval engine (nightly eligibility scoring) | enabled — nightly affordability model runs in Snowflake Cortex |
| CAP-068 | Automated credit decisioning engine | enabled — credit scoring models execute in Snowflake Cortex |
| CAP-069 | Affordability calculator (CCCFA/NCCP compliant) | enabled — affordability calculation is a Snowflake model output |
| CAP-070 | Real-time capital ratio engine (CET1/RWA) | enabled — capital calculations run in Snowflake |
| CAP-071 | LCR/NSFR continuous calculation | enabled — liquidity calculations run in Snowflake |
| CAP-072 | Regulatory threshold alerting | enabled — threshold monitoring via Snowflake Dynamic Tables |
Related decisions¶
| ADR | Title | Relationship |
|---|---|---|
| ADR-001 | Postgres as the OLTP operational store | complementary — Snowflake consumes Postgres facts via CDC |
| ADR-003 | CDC pipeline — Neon Postgres to Snowflake via Firehose and Apache Iceberg | inbound data pipeline to this platform |
| ADR-009 | Insights and data visualisation approach | consumes Snowflake outputs via presentation layer and read API |
| ADR-035 | Snowflake account configuration and data residency | implements account configuration and data residency for this platform |
| ADR-036 | Decision result publication — governed Snowflake → Neon write-back contract | outbound path — decisions from Snowflake to Postgres |
| ADR-038 | Data access tier policy — Snowflake as the reporting and insight layer | governs what data lives in Snowflake (Tier 2 and Tier 3) |
All ADRs
Compiled 2026-05-22 from source/entities/adrs/ADR-002.yaml