> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sumvin.com/llms.txt
> Use this file to discover all available pages before exploring further.

# KYC and attestation

> How raw KYC outcomes become claims a verifier can consume.

# KYC and attestation

KYC and attestation are what feed <Tooltip headline="Sigil" tip="Sumvin's portable, KYC-verified identity — Proof of Personhood." cta="Glossary →" href="/glossary">Sigil</Tooltip>: the verified outcome of a KYC run becomes the portable, KYC-verified identity a user carries across products.

<Snippet file="product-term-disambiguation.mdx" />

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 <Tooltip headline="Stamped Mandate" tip="A signed authorisation a user grants for specific scoped actions — delivered on the wire as a PINT." cta="Glossary →" href="/glossary">Stamped Mandate</Tooltip> <Tooltip headline="JWT" tip="JSON Web Token — the SIS-issued credential a verifier receives." cta="Glossary →" href="/glossary">JWT</Tooltip>. The raw KYC data stays with the identity-verification 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](/guides/kyc) for each mode's shape.
2. The identity-verification provider 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 JWT as the `kyc_status` claim, and — when the scope envelope requests them — as further attestations like `age_over_18` or `proof_of_personhood`. Together these claims are what make Sigil a portable Proof of Personhood.

## What a verifier trusts

The verifier trusts the SIS signature on the JWT. The chain of trust is:

```text theme={null}
Identity-verification provider
  → 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 the identity-verification provider 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](/identity/getting-user-kyc-data) then returns the document metadata to the verifier's API key.

## See also

* [KYC guide](/guides/kyc) — the three modes, end to end
* [Attestation claims](/identity/attestation-claims) — the claim catalogue
* [Getting user KYC data](/identity/getting-user-kyc-data) — deeper lookups via SIS

## Referenced from

* [Sumvin Identity overview](/identity/overview)
* [Onboarding state machine](/concepts/onboarding-state-machine)
* [Verified checkout use case](/overview/use-cases/verified-checkout)