What the user provides
Typical inputs across programmatic and manual paths include:
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.”
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). 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:
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.
Exact fields depend on your credential schema and verification program configuration in the Developer Dashboard.