ADR-039: Market data sourcing — Snowflake Marketplace with provider abstraction¶
| Status | Accepted |
| Date | 2026-04-10 |
| Deciders | CTO, Head of Architecture, Head of Data, Head of Treasury |
| Affects repos | bank-risk-platform, bank-payments, bank-core |
Status: Accepted — 2026-04-10
Context¶
The bank requires market reference data across multiple systems and purposes:
- FX spot rates — SD04 Payments needs intraday spot mid-rates for customer cross-border transactions and rate locks (MOD-025)
- FX forward curves — SD06 Risk needs tenor-structured forward points for FX risk mark-to-market and hedge accounting
- Swap and OIS curves — SD06 needs AUD and NZD term structures (BBSW, BKBM, SOFR, SONIA) for IFRS 9 ECL discounting, ILAAP stress scenarios, and funds transfer pricing
- Benchmark rates — RBA OCR, RBNZ OCR, BBSW, and BKBM for floating-rate product repricing and regulatory reporting
- TP curves — internal funds transfer pricing requires a daily rate grid derived from swap curves plus a liquidity premium, used by SD01 and SD05 to price products and attribute NIM
Options considered:
- Direct vendor API ingestion — Lambda functions pull from Bloomberg, Refinitiv, or ICE APIs; data loaded to Postgres and Snowflake. Full control; requires ingestion pipeline, API key management, rate-limiting handling, and custom schema parsing per vendor.
- Snowflake Marketplace data sharing — subscribe to a provider's Marketplace share; data appears as a read-only Snowflake database in the same account. No ingestion pipeline; data co-located with analytical consumers; provider-portable.
- Central bank direct feeds only — RBA and RBNZ publish rates via HTTP; limited to benchmark rates, no curves or FX.
Decision¶
Source all market reference data via Snowflake Marketplace where available. A thin normalisation layer (Snowflake Dynamic Tables in the market.* schema) translates provider-specific field names and formats into a canonical schema. All analytical consumers (ECL, LCR/NSFR, stress testing, FTP engine) read from market.* — they are never aware of which provider supplies the data. Providers can be swapped or supplemented by updating the normalisation Dynamic Tables only.
Provider selection is intentionally deferred at this stage. The architecture supports a single bundle provider (e.g. Refinitiv/LSEG for full coverage) or a multi-provider mix (e.g. ICE for IBOR-successor benchmarks, Cybersyn for central bank rates, a separate FX-specialist provider). That decision is a procurement choice with no architectural consequence.
BKBM exception: BKBM (NZ Bank Bill Benchmark Rate, published by the NZFMA) is not currently available on Snowflake Marketplace. A daily scheduled Lambda fetches the rate from the NZFMA HTTPS endpoint and loads it into market.benchmark_rates. When BKBM becomes available via Marketplace, the Lambda is retired and the normalisation table updated — no consumer changes required.
Operational FX (SD04): Snowflake Marketplace FX spot data refreshes every 5–15 minutes — not true real-time. SD04's fx_rates Postgres table is maintained by a write-back Lambda (MOD-085) reading market.fx_spot_current on each Marketplace update. Customer rate locks (MOD-025) include a spread buffer to absorb intraday FX movement. No supplementary real-time FX feed is deployed at launch — the spread buffer is the risk mitigation. This decision is revisited when FX transaction volume justifies the operational complexity of a real-time feed.
Consequences¶
Positive: - No market data ingestion pipeline to build or maintain — the Marketplace provider handles data quality, delivery SLAs, and schema versioning - All analytical consumers are provider-agnostic — the normalisation layer is the only code that knows about the provider schema - Snowflake-native data sharing has zero egress cost and no API rate limits - Provider can be changed, supplemented, or extended by updating Dynamic Tables only
Negative / trade-offs: - Operational FX spot has up to 15-minute staleness; mitigated by spread buffer at launch - BKBM requires a separate direct feed until NZFMA data appears on Marketplace — one Lambda to maintain - Marketplace subscriptions are a recurring data cost; provider pricing must be included in the operating budget
Risk: Single-provider concentration if only one Marketplace share supplies multiple data types. Mitigate by selecting providers per data type where cost-effective, and reviewing annually.
Signoff¶
| Name | Role | Date |
|---|---|---|
| Ross Millen | Head of Architecture | 2026-04-10 |
| Ross Millen | Head of Data | 2026-04-10 |
| Ross Millen | CTO | 2026-04-10 |
Capabilities¶
| Capability | Satisfying module | Mode |
|---|---|---|
| CAP-132 Market reference rates | MOD-085 Market rates ingestion & normalisation | AUTO |
| CAP-133 Funds transfer pricing | MOD-086 Funds transfer pricing engine | AUTO |
All ADRs
Compiled 2026-05-22 from source/entities/adrs/ADR-039.yaml