> ## Documentation Index
> Fetch the complete documentation index at: https://docs.moca.network/llms.txt
> Use this file to discover all available pages before exploring further.
# Data collection & sharing
> Data lifecycle for Moca's on-chain KYC — what users submit, what partners receive, what is anchored on-chain, and how disclosure modes work.
This page is for **legal, compliance, and security reviewers** evaluating **Veriff powered by zkMe** — Moca Network's **on-chain IDV/KYC solution** — alongside AIR Kit on Moca Network. It complements [How it works](/kyc/how-it-works) and [zkMe security architecture](/kyc/zkme-security-architecture).
The **disclosure spectrum** (pass/fail, selective attributes, full raw under consent) is summarized on the [KYC overview](/kyc/index) under **Disclosure flexibility**.
***
## What the user provides
Typical inputs across programmatic and manual paths include:
| Category | Examples | Purpose |
| ----------------- | --------------------------------------------------------- | ----------------------------------------------------------- |
| Identity document | Passport, national ID, driver's license, residence permit | Document authenticity, MRZ/OCR, chip read where NFC applies |
| Biometrics | Selfie images or video, liveness challenge | Match user to document portrait; fraud resistance |
| Device signals | IP address, coarse geo, device metadata | Risk scoring and sanctions workflows |
| NFC chip payload | ePassport / eID chip data | Cryptographic authenticity (zkPassport path) |
Exact fields depend on the verification program configured for your partnership. **Your application does not need to persist these artifacts** to participate in the **on-chain IDV/KYC model** unless your own compliance policy requires local copies.
***
## What the partner receives
What your platform and downstream verifiers see depends entirely on the **verification program** and whether **CAK** is in play — not on a single fixed "privacy mode."
| Data | When does the partner or verifier receive it? |
| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Passport / ID images | **Pass/fail or selective-only programs:** not delivered as raw media. **Full-raw program with CAK:** only after explicit user consent per verifier session. |
| MRZ text, structured chip fields | Same pattern: **only via CAK** when the program requests full raw disclosure and the user consents. |
| Selfie / liveness media | Same: **only via CAK** with user consent when the program requires raw biometric evidence at the verifier. |
| AML policy outputs | Usually reflected as **credential attributes** or pass/fail eligibility (for example sanctions-clear flag). Raw vendor hit detail follows the same program + CAK rules as other sensitive fields. |
| **AIR Credential** reference and attributes | **Yes** — whatever the Issuance program encodes (for example `kycLevel`, `isOver18`, compliance flags) for selective or pass/fail modes. |
| **Verifier outcome** | **Yes** — from a simple **COMPLIANT** / **NON\_COMPLIANT** signal through to **field-level payloads** when the program and CAK consent allow. |
Partners should treat the credential and verification program as the **integration contract**: define the minimum disclosure that meets each use case, and rely on revocation and re-issuance when users or regulators require updates.
***
## What Moca Chain stores
Moca Chain records **cryptographic commitments** for credentials — for example hashes, Merkle roots, and revocation state — not plaintext PII. That design lets verifiers trust a credential without every verifier inheriting a full document vault.
***
## What zkMe holds
**zkMe** operates the verification orchestration for **Veriff powered by zkMe** and **encrypts sensitive verification payloads** under the **zkVault** model (hardware-backed trusted execution, threshold encryption, and supporting cryptography — summarized on [zkMe security architecture](/kyc/zkme-security-architecture)).
zkMe stores the original verification material so it can be **re-issued**, **refreshed**, or **partially or fully disclosed** in line with each verifier's program configuration and the **user's consent** (including CAK where enabled). Retention follows regulated identity-provider practices: fraud investigation, regulatory inquiry support, and operational quality — not resale to unrelated third parties.
***
## How the verification stack fits together
End-user verification sessions for **Veriff powered by zkMe** may execute on infrastructure operated under **zkMe's** commercial and technical arrangements. Outputs are consumed by **zkMe** as the **legal and contracting party** for your Moca-facing KYC bundle. Partners contract for this path with **zkMe** only.
Always refer to the offering in public materials as **Veriff powered by zkMe** — use the full product name, not a shortened form.
***
## Disclosure spectrum (configured per verification program)
Three common patterns — all are **first-class** options, not a ladder you must climb:
1. **Pass/fail** — the verifier receives only an eligibility boolean (for example **COMPLIANT** / **NON\_COMPLIANT**).
2. **Selective disclosure** — the verifier receives an agreed subset of attributes from the credential (and any attached proofs your schema defines).
3. **Full raw data** — the verifier receives underlying KYC media and fields only when the program requires it **and** the user has granted access through **Compliance Access Key (CAK)**.
Consent-gated encryption and decryption across Issuer, Holder, and Verifier for full-raw workflows.
Early-access AIR Kit capability for attribute-level presentation controls.
How CAK fits the credential lifecycle on Moca Network.
***
## Pass/fail program (eligibility-only signal)
When the verification program is configured for **eligibility only**, a typical verifier sees:
| Verifier may receive | Not part of this program unless separately requested |
| ------------------------------------------------------------------------ | ---------------------------------------------------- |
| **COMPLIANT** / **NON\_COMPLIANT** | Full legal name, document number, DOB, address |
| Credential identifier, expiry, issuer DID | Passport / ID images, selfie video |
| (Optional) a small set of boolean flags encoded in the credential schema | MRZ or raw AML vendor payloads |
For **selective** programs, the left column expands to include whichever attributes the schema and verification program expose (for example `kycLevel`, `isOver18`). For **full raw** programs with CAK, the verifier may additionally receive decrypted media and structured fields after consent — the table above is no longer the right mental model; follow the [CAK verifier guide](/airkit/usage/credential/cak-verifier-guide).
Exact fields depend on your **credential schema** and **verification program** configuration in the Developer Dashboard.
***
## Related reading