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

# Introducing chmod

> Identity verification and KYC for mobile apps. Your backend sets the rules, your app runs the capture, and chmod delivers the decision.

<iframe className="w-full aspect-video rounded-xl" src="https://www.youtube.com/embed/D0UnqGm_miA" title="chmod identity verification" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowFullScreen />

*One complete verification: from your backend's request to the decision on your webhook.*

chmod verifies that the person using your app is who they say they are. The user photographs their identity document and takes a short liveness selfie; chmod checks that the document is genuine, that a real person is present, that the two faces match, that the device is trustworthy, and that what the document says agrees with what you already know. You get a decision, and every reason behind it.

It is built for products that onboard real people and cannot afford to get it wrong: fintech and payments, lending, marketplaces, gig platforms, telcos, anything regulated.

## How it works

The integration is two halves, owned by two teams, joined by one token.

<Steps>
  <Step title="Your backend opens a verification">
    It registers the person as a **customer**, then creates a **transaction** carrying the rules to enforce — which documents to accept, how strict the face match should be, what to do about a rooted phone. The response includes an `sdk_token`.
  </Step>

  <Step title="Your app runs the capture">
    It hands the token to the chmod SDK. The SDK renders document capture, the liveness check and a result screen, then returns `completed`, `cancelled` or `failed`.
  </Step>

  <Step title="chmod analyses">
    Document extraction and authenticity, liveness, face comparison, device integrity, data matching, and consistency with the customer's history — all of it, to completion, usually within seconds.
  </Step>

  <Step title="Your backend receives the decision">
    `APPROVED`, `REJECTED` or `UNDETERMINED`, delivered by webhook and readable at any time by id, with a stable code for every finding.
  </Step>
</Steps>

<Warning>
  The SDK returning `completed` means the user finished the flow, **not** that they were approved. The verdict arrives afterwards, on your backend. Show "we're reviewing your document" at `completed` and update the user when the decision lands.
</Warning>

## What chmod checks

<CardGroup cols={3}>
  <Card title="Document authenticity" icon="id-card">
    Reads the printed data, the MRZ and the barcode, cross-checks them against each other, and detects digital manipulation, physical tampering and photocopies.
  </Card>

  <Card title="Liveness" icon="face-viewfinder">
    Confirms a real, present person — not a photo, a video or a mask — and reports facial attributes with confidence for each.
  </Card>

  <Card title="Face comparison" icon="people-arrows">
    Matches the document face to the selfie, and both to the face enrolled on the customer's first verification.
  </Card>

  <Card title="Device integrity" icon="mobile-screen-button">
    Root and jailbreak, emulators, developer mode, VPN and proxy, spoofed GPS. You decide whether each one rejects, warns or is ignored.
  </Card>

  <Card title="Data matching" icon="equals">
    Compares the extracted name, date of birth, document number and more against values you already hold — fuzzy where it should be, exact where it must be.
  </Card>

  <Card title="Customer history" icon="clock-rotate-left">
    Flags a date of birth or document number that contradicts what the same customer presented before, and points at the transaction it conflicts with.
  </Card>
</CardGroup>

## Three verification types

Every transaction has a type, and the type decides what the user is asked to do and what the result proves.

| Type | User does | Proves | Typical use |
| - | - | - | - |
| `DOCUMENT_AND_BIOMETRIC` | Document + selfie | A real person holds a genuine document that is theirs | Onboarding |
| `BIOMETRIC_ONLY` | Selfie | A real person, and the same one you enrolled | Step-up before something sensitive |
| `DOCUMENT_ONLY` | Document | A genuine, readable document that belongs to the enrolled person | Refreshing an expired document |

See [Verification types](/concepts/verification-types) for how to choose.

## Rules you control

On top of the type, each transaction carries a configuration. Every field has a default, so you set only what matters to you:

* **Which documents** — by country and type, with per-document control over expiry.
* **How strict** — liveness and face-match thresholds, expected age range.
* **What must match** — names by similarity score, dates and numbers exactly.
* **How to treat the device** — reject, warn or ignore for each integrity signal.

See [What you can configure](/concepts/what-you-can-configure).

## Where to go next

<CardGroup cols={3}>
  <Card title="Your first verification" icon="rocket" href="/quickstart">
    One complete flow in five requests. Start here.
  </Card>

  <Card title="API Reference" icon="code" href="/api-reference/overview">
    Authentication, the three endpoints, errors.
  </Card>

  <Card title="Client SDK" icon="mobile-screen" href="/sdk/overview">
    iOS and Android integration, configuration and theming.
  </Card>
</CardGroup>

## Getting access

chmod is available to businesses through an account. Your chmod account manager provides the API host, the OAuth credentials for your backend and access to the SDK packages. Contact them to get started, or use the support link above.

See the [API Reference](/api-reference/overview) for what you receive and where to start.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.