ADR-037: Open Banking participation strategy — CDR, NZ API standard, and API monetisation¶


Status	Accepted
Date	2026-04-10
Deciders	CEO, CTO, Chief Payments Officer, Chief Compliance Officer
Affects repos	`bank-payments`, `bank-platform`, `bank-kyc`

Context¶

The bank is approaching the threshold for mandatory CDR Data Holder participation under the Australian Consumer Data Right rules. In NZ, Payments NZ has published its Open Banking API standard and is moving toward mandatory participation for registered banks. Separately, the bank's SaaS platform strategy (BG-011, BG-012) creates commercial demand for API access from tenant institutions' fintech integrations.

Three strategic questions need to be resolved:

How broadly should the bank participate in Open Banking frameworks — minimum compliance or active engagement?
Should the bank use Open Banking infrastructure to support its own customer migration strategy (acquiring customers from other banks)?
Should the bank operate a commercial API programme?

Options considered¶

Option A — Compliance only¶

Implement the minimum required CDR Data Holder APIs for AU and participate in NZ Open Banking at the mandatory tier. No inbound Open Banking capability. No commercial API programme.

Pros: Minimum build scope. Lowest ongoing compliance overhead.

Cons: Misses migration opportunity (BG-014). No revenue from API infrastructure. Fintech ecosystem does not see the bank as an integration-friendly platform. Does not support SaaS tenant needs (tenants' customers may use third-party fintech tools that require CDR/Open Banking connectivity).

Option B — Compliance + inbound Open Banking for migration¶

Implement mandatory outbound CDR/NZ APIs plus an inbound CDR data retrieval capability to pre-fill account opening and migration workflows when a customer nominates their existing bank.

Pros: Supports BG-014 (frictionless migration). Positions bank as migration-friendly. Inbound capability reuses CDR infrastructure already being built.

Cons: Inbound CDR data retrieval requires the migrating customer's current bank to be a CDR Data Holder (NZ coverage is partial). Migration benefit is real but currently limited by ecosystem readiness.

Option C — Full participation + paid API programme (proposed)¶

Implement full CDR Data Holder compliance + NZ Open Banking at participation tier. Build inbound Open Banking migration capability. Operate a commercial API access programme for approved fintechs and enterprise customers. Phase the build:

Phase 1: CDR Data Holder compliance + NZ Open Banking outbound APIs + consent management UI (MOD-061, MOD-049)
Phase 2: Inbound CDR data retrieval for migration pre-fill (BG-014, pending market readiness assessment)
Phase 3: Commercial API programme launch with tiered pricing (BG-013)

Pros: Regulatory compliance achieved. Migration advantage activated when ecosystem matures. Revenue from API infrastructure. SaaS tenants can offer Open Banking connectivity to their customers. Positions bank as infrastructure layer for NZ/AU fintech ecosystem.

Cons: Largest build scope. Commercial API programme requires legal framework (API subscriber agreements, data use restrictions, revenue operations). Phase 3 timeline depends on market demand validation.

Proposed decision¶

Option C — phased full participation.

Phase 1 is non-discretionary: CDR Data Holder obligations apply regardless of strategic preference. Phase 1 also delivers the consent management infrastructure that Phase 2 and Phase 3 depend on, so the incremental cost of phases 2 and 3 is lower when built on the same foundation.

The commercial API programme (Phase 3) is subject to a market demand survey before launch. If demand does not justify the operational overhead, Phase 3 will be deferred without affecting Phase 1 or Phase 2.

The CTO is the decision owner for Phase 1 build prioritisation. Phase 2 and Phase 3 require Board visibility given commercial and regulatory implications.

Consequences¶

Accepted consequences:

MOD-061 (Open Banking API gateway & CDR adapter) is created in SD04 with build status Not started. Priority scheduling is at the CTO's discretion within the Phase 1 obligations timeline.
MOD-049 (consent management) scope is expanded to cover CDR consent lifecycle requirements. Existing consent management build should be assessed for CDR compliance gaps.
PAY-010 (Open Banking & API access policy) is created to codify Data Holder obligations and commercial API governance.
Phase 2 (inbound migration) is recorded as BG-014 (Proposed) pending market readiness assessment. No module is created for Phase 2 until the feasibility assessment is complete.
Phase 3 (commercial API programme) is recorded as BG-013 (Proposed) pending demand validation. Revenue model to be developed by the CFO and CTO before Phase 3 scoping.

Deferred decisions:

CDR accreditation registration timing (ACCC)
Payments NZ participation tier (Standard vs. Premium)
Commercial API pricing model and subscriber onboarding process
Inbound CDR provider coverage assessment (which NZ banks are CDR-accessible)

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-048	Automated direct debit migration	enabled — inbound Open Banking data retrieval enables account migration pre-fill
CAP-049	Salary redirect wizard	enabled — Open Banking inbound data supports salary redirect migration
CAP-060	CDR Data Holder compliance & consent management	enabled — Phase 1 CDR Data Holder compliance is the non-discretionary first phase
CAP-061	Commercial API programme & developer portal	enabled — Phase 3 commercial API programme defined here
CAP-131	Inbound CDR data retrieval for account migration	enabled — inbound CDR data retrieval for account migration pre-fill (Phase 2)

ADR	Title	Relationship
ADR-025	API layer — HTTP API Gateway and SST	Open Banking APIs are surfaced through HTTP API Gateway

All ADRs Compiled 2026-05-22 from source/entities/adrs/ADR-037.yaml