Skip to main content

​
KYC and attestation

Sumvin turns the raw outcome of a KYC run — an identity document, a liveness check, a sanctions screen — into a small set of attestation claims that a verifier can consume on a . The raw KYC data stays with the KYC provider and with Sumvin; the verifier only sees the attestation.

​
The pipeline

  1. The partner runs KYC in one of three modes: WebSDK, hybrid, or document-only. See the KYC guide for each mode’s shape.
  2. The KYC provider (SumSub) returns a verified identity outcome to Sumvin. Sumvin stores the user’s name and the link to the applicant record; the full PII remains with the provider.
  3. On token exchange, the user’s KYC outcome surfaces on the issued PINT JWT as the kyc_status claim, and — when the scope envelope requests them — as further attestations like age_over_18 or proof_of_personhood.

​
What a verifier trusts

The verifier trusts the SIS signature on the JWT. The chain of trust is: 
KYC provider (SumSub)
  → Sumvin (stores outcome, gates on scope)
  → SIS (signs the JWT)
  → Verifier (validates signature against JWKS)
A verifier accepting a kyc_status: verified claim is transitively trusting SumSub via Sumvin via SIS. A verifier that needs to inspect underlying KYC documents (not just the status) requests sr:us:pint:identity:kyc_read — the scoped SIS lookup endpoint then returns the document metadata to the verifier’s API key.

​
See also

​
Referenced from