Identity Verification

1. Why We Verify Identity

Identity verification may be required at governed transaction thresholds before a user can list, sell, or complete a protected purchase on the platform. Specifically:

• Seller verification is required to list or sell above Seller_Verification_Threshold from the Constants Registry.
• Buyer identity verification (KYC) is required for orders above Buyer_KYC_Threshold from the Constants Registry.
• Buyer Protection is default-on above Buyer_Protection_Default_On_Threshold from the Constants Registry. Protected orders are held at the payment gate until the buyer’s identity verification (GOV ID) is satisfied.

Each account has one of three governed verification statuses:

• unverified — account created; identity verification not yet started.
• pending — GOV ID verification submitted and in progress.
• verified — GOV ID verification confirmed.

Identity verification confirms identity only. It does not verify the authenticity of any card, the condition of any card, or the general trustworthiness of any seller. Card grading, condition disputes, and seller credibility are governed by separate platform mechanisms — see the Seller Policy and the Dispute & Returns Policy.

2. How Verification Works

Identity verification is performed by a contracted third-party identity verification provider, once selected. The platform does not handle the identity-document capture process directly.

Verification may fail or remain incomplete. Where verification fails or does not complete, the affected user is held at the governed verification gate for the relevant transaction.

For protected orders, the order is held at the created → paid transition until the buyer’s GOV ID verification is satisfied. If verification has not completed within GOV_ID_Stall_Timeout_Hours from the Constants Registry, the order is escalated for admin review.GOV_ID_Stall_Timeout_Hours is an admin-escalation trigger, not a guaranteed verification completion window.

At admin escalation, the admin’s options are governed: the buyer may opt down to an unprotected purchase where the order value does not exceed Buyer_Protection_Opt_Down_Max from the Constants Registry (the buyer must actively elect this), or the order is cancelled. Under no circumstances does a protected order proceed to payment without completed GOV ID verification.

[TODO: Step-by-step verification flow, accepted document types, and typical verification duration — pending KYC provider selection.]

3. Our KYC Provider

[TODO: Identity verification provider — pending selection and execution of a Data Processing Agreement (DPA). Once contracted, this section will identify the provider, link to the provider’s privacy policy, disclose the provider’s data-processing regions, and confirm that identity document data is processed by the provider rather than stored by Merchant Scroll NZ.]

4. What Data We Collect

The platform’s KYC storage posture is locked: “The platform may store verification status and KYC flag state only. No raw identity document data may be stored.”

On the platform, identity verification produces the following stored fields:

• users.verification_status — one of unverified, pending, or verified.
• KycFlag.flag_type — the governed flag category (such as a threshold-triggered KYC requirement, a chargeback escalation, or a GOV ID Buyer Protection gate).
• KycFlag.status — open or resolved.
• KycFlag.raised_by — the admin or system actor that raised the flag (nullable for system-triggered flags).
• KycFlag.resolved_by and KycFlag.resolved_at — admin resolution metadata.
• KYC-related entries in the platform audit log, recording admin actions on the flag and on the affected account.

Merchant Scroll NZ does not store any of the following:

• raw identity document images;
• document numbers;
• biometric data;
• identity document payloads of any kind.

Identity document data is processed by the contracted third-party identity verification provider under their own privacy obligations. “Raw uploaded identity document payloads must not become part of governed platform storage.” Admin tooling must not request or access raw identity document data — status only.

5. AML/CFT Obligations

[TODO: AML/CFT Act 2009 obligations — pending NZ legal counsel confirmation of whether Merchant Scroll NZ is a reporting entity under the AML/CFT Act 2009. If reporting-entity status applies, this section will describe the platform’s Customer Due Diligence (CDD) obligations, Suspicious Transaction Reporting (STR) obligations, and any statutory record-retention obligations. No specific retention period or statutory obligation is asserted here pending that confirmation.]

6. Your Rights

Under the New Zealand Privacy Act 2020, you have the following Information Privacy Principle (IPP) rights in relation to your verification record:

• IPP 6 (Access) — the right to access the personal information the platform holds about you, including your verification status and any KYC flag state.
• IPP 7 (Correction) — the right to request correction of inaccurate personal information, including incorrect verification status.

For broader information about how the platform handles your personal information, see the Privacy Policy.

You may also make a privacy complaint to the Office of the Privacy Commissioner at www.privacy.org.nz.

[TODO: Privacy Officer name, contact email, and internal response timeframe — pending operator input and legal review.]