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 and zkMe security architecture. The disclosure spectrum (pass/fail, selective attributes, full raw under consent) is summarized on the KYC overview under Disclosure flexibility.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.
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) |
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. |
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). 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:- Pass/fail — the verifier receives only an eligibility boolean (for example COMPLIANT / NON_COMPLIANT).
- Selective disclosure — the verifier receives an agreed subset of attributes from the credential (and any attached proofs your schema defines).
- 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).
CAK overview
Consent-gated encryption and decryption across Issuer, Holder, and Verifier for full-raw workflows.
Selective disclosure
Early-access AIR Kit capability for attribute-level presentation controls.
Privacy & compliance
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 |
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.
Exact fields depend on your credential schema and verification program configuration in the Developer Dashboard.