ADR-012: External disclosures system¶
| Status | Accepted |
| Date | 2026-04-10 |
| Deciders | CTO, CCO, Head of Product, CFO |
| Affects repos | bank-app, bank-risk-platform |
Status¶
Accepted — 2026-04-10
Context¶
A bank has significant disclosure obligations to its customers — at product application, at account opening, at credit decision, at fee changes, at annual review, and at various other regulatory trigger points. These disclosures must be:
- Correct — the right disclosure for the right product, jurisdiction, and customer type
- Timely — delivered at the required trigger point, not before or after
- Evidenced — the bank must be able to prove that a specific customer received a specific disclosure at a specific time
- Versioned — when disclosure content changes, historical records must reflect what the customer actually received
- Auditable — regulators can ask to see the disclosure a customer received three years ago
The key regulatory obligations driving this are CCCFA (NZ responsible lending disclosure), NCCP/NCC (AU disclosure requirements), ASIC RG 274 (design and distribution obligations, TMD), CoFI Act 2022 (NZ fair conduct), and the broader product disclosure obligations in the FMC Act (NZ) and Corporations Act (AU).
The question is whether to build disclosure management into the bank's own platform or use a specialist external disclosures platform.
Scope of disclosures covered¶
| Disclosure type | Trigger | Jurisdiction |
|---|---|---|
| Pre-contractual disclosure (lending) | Credit application | NZ + AU |
| Key Facts Sheet / Loan summary | Credit decision | NZ + AU |
| Product terms and conditions | Account opening | NZ + AU |
| Electronic delivery consent | Account opening | NZ + AU |
| Target Market Determination | Product application (AU) | AU |
| Fee change notice | 30 days before change | NZ + AU |
| Monthly account statement | 1st of each month | NZ + AU |
| Annual account statement | End of financial year (31 Mar NZ / 30 Jun AU) | NZ + AU |
| Hardship notice | Hardship application | NZ + AU |
| Complaints disclosure | First contact | NZ + AU |
| Privacy notice | Account opening | NZ + AU |
| AML/CFT identity use notice | KYC initiation | NZ + AU |
| CDR data sharing consent | CDR request | AU |
Statement delivery: Monthly and annual statements are generated and delivered via the mechanism defined in ADR-016 — electronic only, stored in the in-app document centre, email notification with deep link (no PDF attachment). The regulatory classification and evidence requirement for statements is governed by this ADR; generation and delivery is governed by ADR-016.
Electronic delivery consent: Customers consent to electronic-only statement delivery as part of the account opening product terms. This consent is a gate at account activation — it is recorded in the disclosure event log alongside product T&C acknowledgement.
Options evaluated¶
Option A — Build in-house (templates in back end, delivery via app and email)¶
Disclosure templates managed as versioned content in the bank's system. Trigger logic in the application layer. Delivery via in-app notification, email (SendGrid), and PDF generation. Evidence stored in Postgres (disclosure event log) and Snowflake.
Strengths: Full control; templates versioned with the product; delivery evidence in the bank's own audit trail; no third-party platform; consistent with AP-001 KISS and AP-006 cost-effective.
Weaknesses: Content management for 10+ disclosure types across two jurisdictions requires discipline; PDF generation at scale needs library management (WeasyPrint, Puppeteer); regulatory content must be reviewed by legal before each template change; no pre-built compliance checking.
Option B — Specialist disclosures platform (Liqtech, Doxee, or similar)¶
Dedicated document management and delivery platforms for financial services.
Strengths: Pre-built compliance templates for NZ/AU; document versioning and evidence management built in; regulatory update management; strong audit trail.
Weaknesses: Another platform to integrate and operate; licensing cost; data leaves the bank for document generation; integration with the bank's trigger events requires API work; limited availability of NZ/AU-specific platforms.
Option C — Hybrid: in-house trigger logic + document generation service¶
In-house logic determines what disclosure is required and when. A document generation service (Docupilot, Formstack, or self-hosted Carbone.io) handles template rendering and PDF production. Evidence stored in bank's own systems.
Perspective evaluation¶
| Perspective | In-house | Specialist platform | Hybrid |
|---|---|---|---|
| Capability | ~ Must build | ✓ Pre-built | ✓ |
| Evolution | ✓ Full control | ~ Vendor-dependent | ✓ |
| Integration | ✓ Native triggers | ~ API integration | ✓ |
| Cost | ✓ | ~ Licensing | ✓ Lower cost |
| Regulatory | ✓ Evidence in-house | ✓ Built for compliance | ✓ |
| Security | ✓ PII stays in bank | ~ Document generation | ✓ |
| Support & Maintenance | ~ Template discipline | ~ Platform maintenance | ✓ |
See perspectives.md for how to use these evaluation lenses.
Principles alignment¶
| Principle | Assessment |
|---|---|
| AP-001 KISS | Hybrid is the simplest approach that meets requirements without overbuilding |
| AP-003 Compliance | Disclosure delivery is a GATE at product acceptance; evidence is LOG mode |
| AP-005 Customer driven | In-app delivery is the best customer experience; email as fallback |
| AP-006 Cost effective | Carbone.io or equivalent is open source; no specialist platform licensing |
Recommendation (pending decision)¶
Hybrid: in-house trigger logic + Carbone.io (self-hosted) for document generation:
- Disclosure content managed as versioned templates in the bank's content repository (Git-versioned Markdown or HTML templates)
- Trigger logic in the application layer — each product event triggers the required disclosure check
- Document rendering via Carbone.io (open source, self-hosted) or WeasyPrint — produces PDF from template + data
- Delivery: In-app disclosure gate (customer must view and acknowledge before proceeding); PDF copy delivered to the document centre (MOD-075); email notification with deep link for regulatory-required types
- Evidence: Disclosure event log in Postgres — customer ID, disclosure type, version, template hash, delivery timestamp, acknowledgement timestamp. Immutable. Written before the gate passes.
- Versioning: Template content versioned in Git; disclosure records reference the exact version delivered
- Legal sign-off required before any template change is deployed — PR review gate in CI
Relevant viewpoints¶
- Functional viewpoint — Disclosure trigger points across the customer journey; acknowledgement gate
- System viewpoint — Trigger logic in application; template store; Carbone.io rendering; delivery via app and email
- Information viewpoint — Disclosure event log schema; template versioning
- Security viewpoint — PII in disclosure documents; secure delivery; retention policy (7 years)
- Operational viewpoint — Template deployment process; legal review gate; disclosure failure alerting
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-029 | Immutable audit log | enabled — disclosure event log is an immutable record of what was delivered |
| CAP-046 | Real-time account opening (sub-10 minutes) | governed — disclosure delivery is a GATE at account activation |
| CAP-105 | Communication audit trail | enabled — every disclosure delivery creates a timestamped evidence record |
| CAP-118 | Statement generation & download | governed — statement regulatory classification defined here; generation in ADR-016 |
| CAP-128 | Regulated disclosure management | enabled — versioned templated disclosure delivery with evidence trail |
Related decisions¶
| ADR | Title | Relationship |
|---|---|---|
| ADR-016 | Transaction history design — data model, enrichment, and UX | statement generation and delivery mechanism is ADR-016; classification is this ADR |
| ADR-028 | Document storage — S3 and Postgres metadata | disclosure documents stored in S3 customer document tier |
All ADRs
Compiled 2026-05-22 from source/entities/adrs/ADR-012.yaml