New Zealand alignment

Note

This is a design statement written to make your compliance work easier — it is not legal advice and not a certification. If your product is an AML/CFT reporting entity, your compliance programme (and your auditor) remains the authority.

AML/CFT Act — Identity Verification Code of Practice (IVCOP)

IVCOP (as amended) describes how reporting entities verify name and date of birth using electronic means. The relevant mechanics here:

IVCOP expectation	System mechanism
Verify against a photographic identity document (passport, driver licence, etc.)	Document capture with type/country extraction; unsupported/unreadable documents never approve
Confirm the document is genuine	Two independent layers: deterministic ICAO 9303 check-digit validation + AI tamper inspection (photo substitution, font mismatch, MRZ↔visual disagreement)
Confirm the presenter is the holder (“linkage”)	Biometric face match to the document portrait plus active liveness (random pose challenge)
Records to evidence the verification	Hash-chained audit log of every step + encrypted artifact retention with integrity hashes
Electronic verification safeguards	Fail-safe decisioning: uncertainty → human review, never auto-approval

Gap you must close yourself: IVCOP electronic verification for reporting entities generally expects verification against an independent data source (e.g. confirming the licence number with the issuing agency) in addition to document authenticity. That’s an external integration (DIA/NZTA-accredited services) on the roadmap — factor it into your programme if you are a reporting entity. If you’re not (you just want real humans with real IDs), the current pipeline is the appropriate strength.

Biometric Processing Privacy Code 2025

The Code (in force since late 2025) regulates biometric processing under the Privacy Act. Design mapping:

Code theme	System answer
Necessity & proportionality	Biometrics are used for exactly one purpose — linking presenter to document — and nothing else. No identification against galleries, no profiling, no training on user data
Transparency	The capture UI states what is collected and why, at the moment of capture; this documentation is public
Processing limits	All biometric computation is local to the server; embeddings are transient (never persisted); frames are encrypted at rest
Retention	30 days hot → encrypted offline archive → cryptographic erasure on request; biometric artifacts die with the verification
Safeguards	Envelope encryption, access via audited API keys only, fail-safe decisioning, full audit chain

Your obligations as operator: run a privacy impact assessment before processing real users, publish a privacy notice covering biometrics, and honour access/ correction/deletion requests (deletion is one API call).

Privacy Act 2020 — the IPPs that bite

IPP	Obligation	Mechanism
1, 4	Collect only what’s necessary, fairly	Minimum artifact set; capture flow collects nothing beyond the documents + challenge frames
5	Reasonable security safeguards	See Security architecture
6, 7	Access & correction	GET /v1/verifications/{id} for the data held; manual review path for corrections
9	Keep no longer than necessary	30-day hot window + archival + erasure — retention is a configured number, not a habit
12	Cross-border disclosure	Biometrics never leave the server. Document images are processed by the AI provider under contract — disclose this in your privacy notice, or self-host the document model to eliminate it
13	Unique identifiers	ver_… IDs are internal; your products reference their own user IDs

Serving other jurisdictions

The NZ-aligned posture travels well: the EU GDPR, Australian Privacy Act, and Gulf data-protection laws (UAE PDPL, Saudi PDPL) share the same skeleton — minimality, security, retention limits, deletion rights. Jurisdiction-specific additions (data-residency pinning, local supervisory notification timelines) are deployment choices, not architecture changes: run an instance in-region and point your products at it.