Data Quality & Assurance Policy¶


Code	`REP-005`
Domain	Regulatory Reporting
Owner	Chief Technology Officer
Status	Draft
Applicability	Platform
Jurisdiction	NZ + AU
Business domain	BD09
Review date	2027-03-25

Regulations: CPS 234 Information Security · RBNZ Prudential Returns ¶

Purpose¶

Govern source data validation, reconciliation controls, and lineage documentation for all regulatory submissions. Ensures that data submitted to regulators is accurate, complete, traceable to source ledger events, and has passed defined quality gates before submission. No regulatory submission proceeds if reconciliation controls have not been satisfied.

Scope¶

All regulatory data submissions in NZ and AU including prudential returns, AML/CFT reports, IFTI/CMIR reports, credit reporting submissions, and any other data filed with a regulator or government authority.

Policy statements¶

Every regulatory submission SHALL be traceable to the source data it is derived from. Traceability SHALL extend from the submitted figure back to the originating ledger events or system records without unexplained gaps or transformations. Shadow datasets — copies of regulatory data maintained outside the governed pipeline — are prohibited. All analytical views used in regulatory submissions SHALL be derived from the governed CDC pipeline that replicates from the operational source of record.

Reconciliation controls SHALL be applied before every regulatory submission. A submission SHALL NOT proceed if the reconciliation gate has not been passed. Where reconciliation identifies a break, the break SHALL be investigated and resolved, or a documented exception approved by the Chief Risk Officer, before submission.

All data transformations applied to source records before regulatory submission SHALL be implemented in governed, version-controlled pipeline code. Ad-hoc transformations applied outside the governed pipeline — including spreadsheet calculations, manual adjustments, and undocumented scripted extracts — are prohibited.

Data quality rules SHALL be applied to regulatory submission datasets. Rule violations SHALL be treated as blocking issues unless individually reviewed and approved.

Submission systems SHALL maintain an audit trail of: the data extract used, the reconciliation outcome, any exceptions approved, the submission package, the submission timestamp, and the regulatory acknowledgement or receipt.

Corrections to previously submitted regulatory data SHALL follow the applicable regulator's resubmission procedure. Corrections SHALL be logged and SHALL be flagged to the Chief Compliance Officer.

The platform SHALL maintain a regulatory submission calendar. Submissions approaching their due date without a completed reconciliation sign-off SHALL trigger an escalation alert.

All submission packages, reconciliation records, and approval documentation SHALL be retained per the applicable regulatory retention schedule.

Satisfying modules¶

Module	Name	Mode	Description
MOD-002	Immutable transaction log	`LOG`	Data lineage from source transaction to regulatory submission is fully traceable
MOD-022	Payment audit trail	`LOG`	Payment data lineage from instruction to GL posting fully traceable
MOD-027	Affordability calculator	`LOG`	Credit decision data lineage from input to output fully traceable in Snowflake
MOD-036	Prudential return builder (RBNZ / APRA)	`GATE`	Submission is gated by two sequential checks — automated validation rules (data quality) AND an explicit Finance officer approval record in REGULATORY.RETURN_APPROVALS; the submission orchestrator refuses to post to RBNZ or APRA unless both gates are cleared.
MOD-037	AUSTRAC / RBNZ AML reporting pipeline	`GATE`	Submission is gated by Finance officer approval in REGULATORY.RETURN_APPROVALS (via MOD-170); the submission orchestrator aborts if no approval record exists for the current (run_id, return_code) before posting to AUSTRAC or RBNZ.
MOD-038	Data quality & reconciliation monitor	`GATE`	Source-to-report reconciliation automated — breaks cannot be hidden or ignored
MOD-042	CDC pipeline — Neon logical replication to S3 Iceberg	`AUTO`	Regulatory data sourced from the same Iceberg snapshots as all consumers — no divergent copies or selective replication
MOD-057	Statistical returns & survey engine	`GATE`	Submission is gated by Finance officer approval in REGULATORY.RETURN_APPROVALS (via MOD-170); the submission orchestrator aborts if no approval record exists for the current (run_id, return_code) before posting to RBNZ or APRA.
MOD-060	FATCA/CRS/AEOI reporting engine	`GATE`	Submission is gated by Finance officer approval in REGULATORY.RETURN_APPROVALS (via MOD-170); the submission orchestrator aborts if no approval record exists for the current (run_id, return_code) before transmitting to IRD or ATO.
MOD-081	Payment reconciliation engine	`LOG`	Reconciliation outcomes are retained with full data lineage — payment, settlement file, and matched/unmatched status are traceable for audit and dispute resolution.
MOD-085	Market rates ingestion & normalisation	`LOG`	All market data ingestion events are logged with provider, version, and timestamp — full audit trail for any rate used in regulatory calculations or product pricing.
MOD-119	BPAY payment integration	`LOG`	All BPAY transactions are logged with biller code, customer reference, and settlement batch reference for data quality and reconciliation purposes.
MOD-122	NZ faster payments and A2A integration	`LOG`	All interbank payment data is logged with Payments NZ clearing references for data quality and reconciliation purposes.
MOD-136	BPAY biller registration and inbound BPAY	`LOG`	All BPAY biller registrations, inbound payment receipts, and reconciliation outcomes are logged for payment data quality and regulatory reporting.
MOD-170	Regulatory Submissions Portal	`GATE`	No regulatory return may be submitted to RBNZ or APRA without passing validation (REP-005 data quality gate) AND receiving explicit written approval from an authorised Finance officer recorded in REGULATORY.RETURN_APPROVALS — the submission orchestrator enforces both gates unconditionally.

Part of Regulatory Reporting · Governance overview Compiled 2026-05-22 from source/entities/policies/REP-005.yaml