AP-002 — Data governance by design

Data is the bank's most valuable asset and its most significant liability. Both at the same time.

Governance is not a compliance layer you apply after the fact. By the time you are retrofitting data classification onto a schema that was not designed for it, you have already created risk — and work. Build it in from the start.

Every data element has an owner, a classification, a retention period, and a traceable lineage from source to use. Data quality is enforced at ingestion — bad data is rejected, not corrected downstream where the cost is ten times higher. PII is handled correctly from the moment it enters the system, not from the moment a regulator asks about it.

Key rules, non-negotiable: - No PII in logs, URLs, or error messages — ever - No schema change without a migration plan and documented rollback - Snowflake access is role-scoped — analysts do not touch raw PII tables - Data retention enforced by automated jobs, not manual processes - All data movement across the NZ/AU jurisdictional boundary is explicit and consented

KISS check: Data governance can generate enormous complexity. Govern the data that matters at the level of detail that is useful. No more.

See also: Data architecture for how this principle is implemented in the platform.

Relationship to other principles

Principle	Relationship
AP-001 KISS	Govern the data that matters — no more. Governance complexity is waste.
AP-003 Compliance by design	Data lineage and retention are core compliance obligations — governance enables compliance.
AP-004 Security by design	PII handling rules (no PII in logs/URLs) overlap directly with security controls.
AP-010 Modular by design	Explicit domain ownership is the mechanism that makes data governance real at scale.

See the full architectural principles index.