# Zyphe Developer Documentation > Technical documentation for integrating Zyphe APIs, SDKs, and webhooks. This file contains all documentation content in a single document following the llmstxt.org standard. ## Quickstart This is the shortest path from zero to a **reviewed verification result**. Follow the seven steps in order. Each links to the relevant guide if you want more depth. You can complete the whole path in the **sandbox**, with no contract and no production data. :::tip[Where to go for detail] This page is deliberately linear and opinionated. Every capability it touches has a full guide; follow the links when you need options, edge cases, or reference material. ::: ## 1. Create an account and open the sandbox Sign up and open your organization in the [dashboard](/docs/guides/dashboard). Switch the dashboard to **sandbox** mode. Everything below runs against synthetic data, so you can build and test without any production entitlement or data-processing agreement. ## 2. Create your first flow A **flow** is the sequence of steps a user goes through to get verified (document check, liveness, proof of address, and so on). Open the flow builder and create one. Start from a template or add a couple of steps such as **Document Verification** and **Liveness**. → [Create a flow](/docs/guides/create-a-flow) ## 3. Run a test verification From the flow you just built, start a verification request in the sandbox and complete it yourself. This produces a **flow result**: the record you will review in step 6. Verifying yourself, or anyone on your team's email domain, costs **no credits** in sandbox — see [credits in sandbox](/docs/guides/sandbox-mode#credits-and-billing-in-sandbox) for when sandbox runs are billed. → [Create a flow → running a verification](/docs/guides/create-a-flow) ## 4. Choose how you integrate: public link or SDK You have two ways to put the flow in front of a real user (see [Choosing an integration method](/docs/choosing-an-integration-method) for a full comparison, including MCP agents): - **Public link**: Zyphe hosts the verification UI; you share a URL and receive the result. The fastest path to a working integration. → [Sharing a flow](/docs/guides/create-a-flow/sharing) - **SDK**: embed verification directly in your web or mobile app for a native experience and full control over the UX. → [SDKs](/docs/guides/sdk) Pick one for now; you can add the other later. ## 5. Receive a webhook Register a webhook endpoint for your organization, subscribe it to the events you care about, and scope it to your flows. Your backend is then notified when a verification completes, instead of polling. Zyphe signs every delivery so you can verify it came from us. Endpoints belong to the organization, not to a single flow: subscribe one to the events you handle and scope it to this flow or to all of them. → [Webhook endpoints](/docs/guides/webhook/endpoints) · [Webhook signature](/docs/guides/webhook/webhook-signature) ## 6. Review the result Open the flow result in the dashboard. You will see its status, the collected data (subject to your [role](/docs/guides/manage-users) and [PII access](/docs/pii-access-control)), and any computed [scores](/docs/guides/scoring). Approve or reject it, or configure [manual review](/docs/guides/manual-review) to route results to a reviewer automatically. → [Manual review](/docs/guides/manual-review) · [Reviewing scores](/docs/guides/scoring/reviewing-scores) ## 7. Prepare for production When your sandbox integration works end to end, use the full **[Sandbox and go-live](/docs/guides/sandbox-and-go-live)** checklist. In short: 1. Generate production [API keys](/docs/guides/api-keys). 2. Point your production webhook endpoint at your production infrastructure and confirm signature verification. 3. Review [billing](/docs/guides/billing) and enable the products you need. 4. Switch your integration from the sandbox to the production environment. 5. Map statuses and failure reasons with [Statuses and codes](/docs/reference/statuses-and-codes). ## Where to next - Finish QA with [Sandbox and go-live](/docs/guides/sandbox-and-go-live). - Compare integration options in [Choosing an integration method](/docs/choosing-an-integration-method). - Read short product explainers under [How it works](/docs/how-it-works). - Add continuous compliance with [AML monitoring](/docs/aml) and [Transaction Monitoring](/docs/transaction-monitoring). - Let partners reuse an existing verification with [reusable credentials / one-click KYC](/docs/reusable-credentials-one-click-kyc). - Automate flow setup with the [MCP server](/docs/guides/model-context-protocol-mcp). - Explore the full [API reference](/docs/openapi/zyphe-sdk). --- ## @zyphe-sdk/browser Install the package: ## Embedding the Zyphe Verification Iframe Use the `startVerificationSession` function to embed a Zyphe verification flow in your web app: ```ts const container = document.getElementById('your-container-id') const flowParams = { // Provide at least one identity field: email or a credential. email: 'user@example.com', credentials: [ { type: 'EXTERNAL_ID', externalId: 'user_123' }, { type: 'WALLET', address: '0x123...', chain: 'ETHEREUM' }, ], flowId: 'your-flow-id', isSandbox: true, // or false for production customData: {/* optional custom data */}, // Optional: pass any extra data needed for your flow } const opts = { apiKey: 'your-api-key', // ...other SDK options } const result = await startVerificationSession({ containerElement: container, flowParams, opts, eventHandlers: { onSuccess: (message) => { // Handle success console.log('Verification completed successfully') console.log('Completed step:', message.flowStep) console.log('Verification request session:', message.vrSession) }, onFailure: (message) => { // Handle failure console.log('Verification failed') console.log('Failure details:', message.error) }, }, }) if (result.error) { // Handle error (e.g., show a message to the user) console.error('Failed to start verification session:', result.error) } else { // Session created successfully, iframe embedded console.log('Verification session started successfully') } ``` ### Key Features - **Non-throwing API**: The function returns a **Result** object: `{ error, data }`. If session creation fails, `error` will be set and no iframe will be embedded. - **Automatic iframe management**: Creates and appends an iframe to the specified container with proper styling and permissions. - **Event handling**: Listen for success and failure events from the verification flow, including the completed flow, flow step, and verification request session context. - **Camera permissions**: The iframe is automatically configured with camera permissions for document and identity verification. - **Identity credentials**: Start a session with `email`, an `EXTERNAL_ID` credential, a `WALLET` credential, or any combination. At least one is required. :::warning[Email aliases not supported in production] The `email` field in `flowParams` does not accept email aliases (e.g. `user+tag@example.com`) in production environments. Use a plain email address without `+alias` suffixes when `isSandbox` is `false`. ::: --- ## API Reference ### `startVerificationSession({ containerElement, flowParams, opts, eventHandlers })` Creates a verification session and embeds the Zyphe iframe in the specified container. #### Parameters - **containerElement**: `HTMLElement` - The DOM element to append the iframe to - **flowParams**: `InitializeZypheFlowParams` - The parameters for the verification flow - `email?`: `string` - User's email address. Required only when `credentials` does not include an external ID or wallet. - `credentials?`: `VerificationIdentifierCredential[]` - User credentials. Include `{ type: 'EXTERNAL_ID', externalId: 'user_123' }` and/or `{ type: 'WALLET', address: '0x123...', chain: 'ETHEREUM' }`. - `flowId`: `string` - The ID of the verification flow - `flowStepId?`: `string` - Optional. If omitted, the next incomplete step is selected automatically. - `isSandbox`: `boolean` - Whether to use sandbox or production environment - `customData?`: `any` - Optional custom data to pass to the flow - **opts**: `SDKOptions` - SDK configuration options (e.g., `{ apiKey }`). Optional theming overrides are also accepted. See [Theming](../dashboard/theming.mdx) for the full list. - **eventHandlers?**: `{ onSuccess?, onFailure? }` - Optional event handlers - `onSuccess?`: `(message: ZypheVerificationSuccessMessage) => void` - Called when verification completes successfully - `onFailure?`: `(message: ZypheVerificationFailureMessage) => void` - Called when verification fails #### Verification event payloads The browser SDK listens to the iframe `postMessage` events emitted by the Zyphe verification flow. Both success and failure handlers receive the full event payload. ```ts type ZypheVerificationSuccessMessage = { type: 'zyphe-verification-success' flow: Flow flowStep: FlowStep vrSession: { customData?: VerificationRequest['customData'] email?: string verificationRequestId?: string } } type ZypheVerificationFailureMessage = { type: 'zyphe-verification-failure' flow: Flow flowStep: FlowStep vrSession: { customData?: VerificationRequest['customData'] email?: string verificationRequestId?: string } error?: string | { code?: string; message?: string } } ``` - `flow`: The flow where the verification event happened. - `flowStep`: The flow step that completed or failed. - `vrSession`: Verification request session context, including `verificationRequestId`, `email`, and `customData`. - `error`: Failure details. This field is only present on `zyphe-verification-failure` events. #### Returns `Promise<{ error?: any, data?: any }>` - A Result object - If `error` is present, session creation failed and no iframe is embedded - If `data` is present, session was created and iframe is embedded #### Example ```ts const result = await startVerificationSession({ containerElement: document.getElementById('verification-container'), flowParams: { email: 'user@example.com', credentials: [{ type: 'EXTERNAL_ID', externalId: 'user_789' }], flowId: 'flow_123', isSandbox: true, customData: { userId: 'user_789' }, }, opts: { apiKey: 'your-api-key' }, eventHandlers: { onSuccess: (message) => { console.log('Verification successful', message.flowStep.type) }, onFailure: (message) => { console.log('Verification failed', message.error) }, }, }) ``` --- ## Browser Compatibility This SDK requires a modern browser with support for: - ES6+ features - Web Crypto API (for future webhook signature verification) - Iframe elements --- ## Get Next Step The Get Next Step endpoint allows integrators to programmatically determine the current progress of a verification flow and identify the next action required from the user. This endpoint is part of the HTTP **SDK API** on `https://api.zyphe.com`. You do not need an npm package to call it. For the full backend recipe, see [Backend API integration](/docs/guides/backend-api-integration). For tradeoffs when driving steps yourself, see [Hosted UI vs direct API](/docs/guides/hosted-vs-direct-api). ## Endpoint Details - **Base URL:** `https://api.zyphe.com` ([Environment setup](/docs/guides/environment-setup)) - **Method:** `GET` - **Path:** `/sdk/flow/{flow_id}/vr/next-step` - **Authentication:** Secret API key in the `x-api-key` header (`zyphe_sk_…`) ### Query Parameters | Parameter | Type | Required | Description | | :--------------- | :------ | :------- | :---------------------------------------------------------------------------------------------- | | `sandbox` | boolean | Yes | Whether to query the sandbox environment. | | `email` | string | No | The email address of the user undergoing verification. | | `credentialType` | string | No | Use `EXTERNAL_ID` or `WALLET` when querying by credential. | | `externalId` | string | No | Required when `credentialType=EXTERNAL_ID`. | | `address` | string | No | Wallet address. Required when `credentialType=WALLET`. | | `chain` | string | No | Wallet chain. Required when `credentialType=WALLET` (for example `ETHEREUM`, `SOLANA_TESTNET`). | | `locale` | string | No | Optional response locale. | Provide at least one identity field: `email`, `credentialType=EXTERNAL_ID` with `externalId`, or `credentialType=WALLET` with `address` and `chain`. ## Response The endpoint returns a `GetNextStepResponse` object. ```json { "nextStep": { "id": "step_123", "name": "Document Verification", "type": "DV", "order": 1, "config": { ... } }, "isCompleted": false, "executedActions": ["action_abc"] } ``` ### Field Descriptions - **nextStep:** A `FlowStep` object containing the details of the next step. Returns `null` if all steps are completed. - **isCompleted:** A boolean indicating if the entire verification flow is finished. - **executedActions:** An array of workflow actions that have already been executed for this user. ## How It Works The system evaluates the current state of the verification flow for the provided email or credential: - If the user has not started, it returns the first step in the flow. - If the user has completed steps, it identifies the next incomplete step based on the flow configuration. - If all steps are finished, `isCompleted` is set to `true` and `nextStep` is `null`. ## Use Cases This endpoint is primarily used for custom UI implementations where the integrator wants to manage the user experience programmatically rather than using the Zyphe hosted UI. It provides the necessary metadata to render the appropriate component for each step (e.g., DV, Form, POA, SPID). ## Example ```bash curl -X GET "https://api.zyphe.com/sdk/flow/flow_123/vr/next-step?sandbox=true&email=user@example.com" \ -H "x-api-key: your_api_key_here" ``` Query by external ID: ```bash curl -X GET "https://api.zyphe.com/sdk/flow/flow_123/vr/next-step?sandbox=true&credentialType=EXTERNAL_ID&externalId=user_123" \ -H "x-api-key: your_api_key_here" ``` Query by wallet: ```bash curl -X GET "https://api.zyphe.com/sdk/flow/flow_123/vr/next-step?sandbox=true&credentialType=WALLET&address=0x123...&chain=ETHEREUM" \ -H "x-api-key: your_api_key_here" ``` --- ## SDK Integration Zyphe exposes an HTTP **SDK API** under `https://api.zyphe.com/sdk/...`. You can call it with any HTTP client ([Backend API integration](/docs/guides/backend-api-integration)) or with the npm packages below. **npm packages** help TypeScript/JavaScript apps create sessions, embed the hosted UI, and verify webhooks. They are optional if you speak HTTP. There is **no native iOS or Android SDK**. Mobile uses backend session creation + WebView: [Mobile integration](/docs/guides/mobile-integration). ## Before you install a package 1. [Environment setup](/docs/guides/environment-setup) — `api.zyphe.com` vs `verify.zyphe.com` vs docs 2. [API keys](/docs/guides/api-keys) — secret key for servers, publishable only for browser SDK 3. [Sandbox mode](/docs/guides/sandbox-mode) — `isSandbox` / `sandbox` query must match the session URL 4. [Hosted UI vs direct API](/docs/guides/hosted-vs-direct-api) — when not to reimplement capture ## @zyphe-sdk/browser https://www.npmjs.com/package/@zyphe-sdk/browser This package is designed for browser applications. It provides utilities to interact with the Zyphe platform, including verification session management and iframe embedding. ## @zyphe-sdk/node https://www.npmjs.com/package/@zyphe-sdk/node This package is designed for Node.js applications. It provides utilities to interact with the Zyphe platform, including webhook signature verification, verification session management, [Export API](/docs/guides/export-api) helpers for flow results and document-verification details, on-demand AML screening, KYB case management (officers, document requests, decisions), and [Transaction Monitoring](/docs/guides/transaction-monitoring) ingestion. See the [Node SDK guide](/docs/guides/sdk/node). ## React Native Integration For mobile applications, we provide a comprehensive integration guide using React Native with WebView. This approach works with both Expo and bare React Native projects. See the [React Native Integration](/docs/guides/sdk/react-native) guide for detailed setup instructions, or the language-agnostic [Mobile integration](/docs/guides/mobile-integration) page. ## @zyphe-sdk/core https://www.npmjs.com/package/@zyphe-sdk/core This environment-agnostic package is used internally by both the `sdk-node` and `sdk-browser` packages. The exports are passed through to those packages, so you typically won't need to use this package directly. It can also be used on React Native **backend** servers (not inside the app binary with a secret key). ## Direct HTTP (no package) Same create-session and step endpoints, documented as a single recipe: → [Backend API integration](/docs/guides/backend-api-integration) · [OpenAPI](/docs/openapi/zyphe-sdk) ## Upgrading Moving to the KYB case helpers, or reading types from `@zyphe-sdk/core/openapi`? See the [migration guide](/docs/guides/sdk/migration-guide). ## Theming You can match the verification flow to your brand using dashboard themes and per-session SDK overrides. See the [Theming](../dashboard/theming.mdx) guide for the full list of color, border-radius, font, and logo options. --- ## Migration Guide: KYB Cases This release of `@zyphe-sdk/core` and `@zyphe-sdk/node` moves KYB management from the KYB result to the **KYB case**, adds [Transaction Monitoring](/docs/guides/sdk/node#7-transaction-monitoring) helpers, and updates the bundled OpenAPI types. If you review KYB in the dashboard, see the [KYB dashboard migration guide](/docs/guides/kyb/dashboard-migration) for what changed there. Nothing stops working when you upgrade: the previous KYB helpers are **deprecated, not removed**, and their endpoints still answer. You only have to act if you use the KYB helpers or read the types listed under [Type changes](#type-changes). | Package | From | To | | -------------------- | ------- | -------------------- | | `@zyphe-sdk/core` | `0.5.x` | next minor (`0.6.0`) | | `@zyphe-sdk/node` | `0.4.x` | next minor (`0.5.0`) | | `@zyphe-sdk/browser` | `0.4.x` | patch, no action | ## Who needs to migrate - **You call `addKybUbos`, `removeKybUbo`, `addKybDirectors`, `removeKybDirector`, `requestKybOnDemandDocument`, or `sendKybUboReminder`**: move to the case helpers ([step 2](#2-move-to-the-case-helpers)). Your editor already flags them as deprecated after the upgrade. - **You approve or reject KYB results from your backend**: use `decideKybCase` ([step 4](#4-decide-cases-with-decidekybcase)). - **You import types from `@zyphe-sdk/core/openapi`**: check [Type changes](#type-changes). - **You only create verification sessions, verify webhooks, or use the Export API**: upgrade, no code change. ## 1. Upgrade the packages ```bash pnpm add @zyphe-sdk/node@latest # or, if you use it directly pnpm add @zyphe-sdk/core@latest ``` ## 2. Move to the case helpers The case helpers take a `caseId` instead of a `kybResultId`. **It is the same value**: the ID of a KYB result is the ID of its case. Rename the parameter and keep passing the ID you already store. | Deprecated | Replacement | | ---------------------------- | -------------------------------- | | `addKybUbos` | `addKybCaseUbos` | | `removeKybUbo` | `removeKybCaseUbo` | | `addKybDirectors` | `addKybCaseDirectors` | | `removeKybDirector` | `removeKybCaseDirector` | | `requestKybOnDemandDocument` | `requestKybCaseOnDemandDocument` | | `sendKybUboReminder` | `sendKybCaseUboReminder` | Before: ```ts const { data } = await addKybUbos({ organizationId, kybResultId, isSandbox: true, persons }, opts) const ubos = data?.uboDefinitions ?? [] ``` After: ```ts const { data } = await addKybCaseUbos({ organizationId, caseId: kybResultId, isSandbox: true, persons }, opts) const ubos = data?.ubos ?? [] ``` The `persons` payload is unchanged. ## 3. Read the new officer response The four officer helpers (`addKybCaseUbos`, `removeKybCaseUbo`, `addKybCaseDirectors`, `removeKybCaseDirector`) no longer answer with the whole KYB result. They answer with the case's officers as they stand after the change: ```ts { caseId: string, ubos: UboDefinition[], directors: DirectorDefinition[] } ``` | Before (KYB result) | After (officers) | | -------------------------- | ------------------------------- | | `data.uboDefinitions` | `data.ubos` | | `data.directorDefinitions` | `data.directors` | | any other KYB result field | `getKybCase` or `getFlowResult` | Each person keeps the same stable `id`, which `removeKybCaseUbo` / `removeKybCaseDirector` take as `personId`. To read the officers without changing them, call `getKybCaseOfficers`. The other two replacements behave as before, with two details worth checking: - `sendKybCaseUboReminder` still takes a `recipientIndex`: the position of the UBO in `ubos`. Only a UBO with an email can be invited; one declared without an email is rejected. - `requestKybCaseOnDemandDocument` also accepts optional `recipientEmail`, `subject`, `body`, and `description` next to `documentKey`. The `documentKey` must name a document the flow marks as on demand; a document the flow requires upfront is rejected. ## 4. Decide cases with `decideKybCase` Approving or rejecting a KYB result from your backend now goes through the case decision: ```ts const { data, response } = await decideKybCase( { organizationId, caseId, isSandbox: true, outcome: 'REJECTED', // or 'APPROVED' reason: 'Ownership could not be verified', // mandatory on a rejection reasonCode: 'CDD_INCOMPLETE', // optional classification }, opts, ) ``` - The `POST /sdk/organizations/{organization_id}/kyb/{kyb_result_id}/approve` and `/reject` endpoints are deprecated in favour of this one. Send `outcome: 'APPROVED'` or `outcome: 'REJECTED'`; `reason`, `reasonCode`, and `dueDiligenceLevel` carry over. - The answer is the decision (`outcome`, `statusBefore`, `statusAfter`, `decisionId`), not the KYB result. Read the case with `getKybCase` afterwards if you need it. - **Handle `202`**: when the organization's approval matrix requires two signatures, the call records a `decisionProposal` instead of closing the case. The second signature must come from a person in the dashboard: an API key can propose a decision but cannot confirm one. See [Decide a case](/docs/guides/sdk/node#decide-a-case). - A decision is final. A decided case cannot be decided again. ## 5. Handle the new error tags Refusals of a case decision now carry their own `errorTag`, so you can tell the user why instead of showing a generic bad request: | `errorTag` | Meaning | | ------------------------------------ | --------------------------------------------------------------------------------------------------- | | `kyb_case_not_decidable` | The case's status does not accept this decision (for example, it is already decided) | | `kyb_case_not_ready` | The case is not ready for review yet: an approval needs it in `READY_FOR_REVIEW` | | `kyb_case_exception_required` | The approval rests on something that needs a recorded exception first; the message lists what | | `kyb_case_rejecting_hit` | A confirmed screening match stands on the case and the organization's policy rejects it | | `kyb_case_reason_required` | The decision needs a `reason` (every rejection, and an approval resting on an exception or a match) | | `kyb_case_decision_not_authorized` | The organization's approval matrix does not let this caller take this decision | | `kyb_case_second_signature_required` | The confirmation of a proposal is not valid: it must come from a person other than the proposer | All of them are `400`. The message names the specific blocker, so log it. ## Type changes These only affect code that reads the generated types exported from `@zyphe-sdk/core/openapi` (`components['schemas'][...]`): - **`KybConfig`** no longer has `articlesOfAssociation`, `certificateOfIncorporation`, `customDocuments`, `organizationalStructureChart`, or `proofOfAttorney`. KYB documents are configured on the `KYB_DOCUMENTS` step (`KybDocumentsConfig`); see [KYB steps and configuration](/docs/guides/kyb/steps-and-configuration). - **`FlowStepType`** gains `KYB_DOCUMENTS`, `KYB_UBOS`, and `KYB_DIRECTORS`. Update exhaustive `switch` statements over step types. - **`Flow`** no longer has `webhookUrl`. Webhook destinations are configured as [webhook endpoints](/docs/guides/webhook/endpoints). - **`ErrorTags`** no longer contains `websocket`. - **Removed schemas** that were not used by any SDK helper: `CustomDocumentConfig`, `DocumentConfig`, `ModerateKybResultPayload`, `ModerateKybResultResponse`, `PagedCommunicationsResponse`, `PagedDocumentRequestsResponse`, `Uuid`, and the dashboard `List*Response` types. Additive changes need no action: new optional fields such as `SdkCreateVerificationRequestResponse.sessionId`, `KybMetadata.dueDiligenceLevel`, and `DvConfig.capture`, plus the new KYB case and Transaction Monitoring schemas. ## Checklist - [ ] Upgrade `@zyphe-sdk/node` (and `@zyphe-sdk/core` if you depend on it directly). - [ ] Replace the six deprecated KYB helpers and rename `kybResultId` to `caseId`. - [ ] Read `ubos` / `directors` instead of `uboDefinitions` / `directorDefinitions`. - [ ] Move backend approvals and rejections to `decideKybCase`, handling `202`. - [ ] Map the new `kyb_case_*` error tags to user-facing messages. - [ ] Fix compile errors from the [type changes](#type-changes), if any. - [ ] Run the flow end to end in the [sandbox](/docs/guides/sandbox-mode) before switching production keys. --- ## @zyphe-sdk/node Install the package: ## 1. Webhook Signature Verification This package provides the core webhook signature verification logic for Zyphe. It enables secure verification of incoming webhook requests in Node.js using HMAC-SHA256 signatures. ### Basic Usage ```ts const secretHex = '' const rawBodyString = '...' // The raw request body as a string const signatureHeader = 't=1234567890,v0=abcdef...' // The signature header from the webhook const isValid = verifyWebhookSignatureHeader(secretHex, rawBodyString, signatureHeader) if (isValid) { // Signature is valid } else { // Signature is invalid } ``` - `secretHex`: The hex-encoded secret key used to sign the webhook. - `rawBodyString`: The raw request body as a string (must match exactly what was sent). - `signatureHeader`: The signature header string, e.g. `t=1234567890,v0=abcdef...`. - Returns: `true` if the signature is valid, or `false` otherwise. ### Advanced Utilities - `parseSignatureHeader(signatureHeader)`, Parse the signature header into timestamp and signature. - `hexToBytes(hex)` / `bufferToHex(buffer)`, Convert between hex and bytes. - `timingSafeEqual(a, b)`, Constant-time string comparison. - Error codes/messages for robust error handling. --- ## 2. Verification Session Management You can programmatically create verification sessions and construct user-facing URLs for onboarding flows. ### Create a Verification Session ```ts const response = await createVerificationSession( { // Provide at least one identity field: email or a credential. email: 'user@example.com', // optional when credentials are provided credentials: [ { type: 'EXTERNAL_ID', externalId: 'user_123' }, { type: 'WALLET', address: '0x123...', chain: 'ETHEREUM' }, ], // optional when email is provided flowId: '', // required isSandbox: false, // required customData: { // optional plan: 'pro', // ...any extra data you want to pass }, }, { // Secret key (zyphe_sk_...) — required for server-side session creation apiKey: '', // production → https://api.zyphe.com + https://verify.zyphe.com // See Environment setup: /docs/guides/environment-setup environment: 'production', handoffBaseUrl: 'https://your-app.com', // optional // Theming, all optional. Light mode: backgroundColor: '#ffffff', // page background accentColor: '#155dfb', // buttons, icons, highlights cardColor: '#ffffff', // card surface // Dark mode: darkBackgroundColor: '#16181d', darkAccentColor: '#155dfb', darkCardColor: '#16181d', borderRadius: '12px', // shared radius for cards, buttons, inputs // Deprecated (still honored): primaryColor → background, secondaryColor → accent isFullscreen: true, // optional }, ) ``` - `email` and `credentials` identify the user. Provide at least one of `email`, an `EXTERNAL_ID` credential, or a `WALLET` credential. - `credentials` (optional): Pass an array of credentials, for example `{ type: 'EXTERNAL_ID', externalId: 'user_123' }` or `{ type: 'WALLET', address: '0x123...', chain: 'ETHEREUM' }`. - You can combine identity fields, such as `email` plus `externalId`, `email` plus `wallet`, or all three. - `customData` (optional): Pass any extra data you want to associate with the verification session. This will be available in the webhook payload and session data. - The function returns a Promise resolving to the API response. Handle errors as needed (e.g., try/catch or checking for error fields). ### Construct a Verification Session URL ```ts const url = constructVerificationSessionUrl({ flowParams: { flowId: '...', email: 'user@example.com', credentials: [{ type: 'EXTERNAL_ID', externalId: 'user_123' }], isSandbox: false, customData: { plan: 'pro' }, // optional }, verificationSession: response.data, // from createVerificationSession opts: { apiKey: '', environment: 'production', handoffBaseUrl: 'https://your-app.com', // optional // Theming, all optional. Light mode: backgroundColor: '#ffffff', // page background accentColor: '#155dfb', // buttons, icons, highlights cardColor: '#ffffff', // card surface // Dark mode: darkBackgroundColor: '#16181d', darkAccentColor: '#155dfb', darkCardColor: '#16181d', borderRadius: '12px', // shared radius for cards, buttons, inputs // Deprecated (still honored): primaryColor → background, secondaryColor → accent isFullscreen: true, // optional }, }) ``` - The constructed URL includes all relevant parameters and can be used to embed or redirect users to the verification flow. - Optional fields (like `handoffBaseUrl`, `accentColor`, `borderRadius`, etc.) will be appended as query parameters if provided. See [Theming](../dashboard/theming.mdx) for the full list of theme options and how they work. #### Types - `InitializeZypheFlowParams`: Parameters for initializing a verification flow. - `SDKOptions`: Configuration for the SDK. - `SdkCreateVerificationRequestResponse`: API response type for session creation. #### Error Handling - If session creation fails, the function may throw or return an error object depending on usage context. Always check for errors and handle them appropriately. - Example: ```ts try { const response = await createVerificationSession(...); if (response.error) { // Handle error console.error(response.error); } else { // Success } } catch (err) { // Handle thrown errors (e.g., network issues) console.error(err); } ``` :::warning[Email aliases not supported in production] The `email` field in `flowParams` does not accept email aliases (e.g. `user+tag@example.com`) in production environments. Use a plain email address without `+alias` suffixes when `isSandbox` is `false`. ::: --- ## 3. Complete Verification Steps The Node SDK also includes helpers for completing document selection, document verification, and liveness steps from your backend. Typical flow: 1. Create a verification session with `createVerificationSession`. 2. Check the current step with `getNextStepDetails` if you need to branch dynamically. 3. Complete document selection with `completeDocumentSelectionStep` when the next step is `document-selection`. 4. Upload document images with `completeDvStep` when the next step is a document verification step. 5. Complete liveness with `completeLivenessStep` when the flow requires liveness. ### Inspect the Next Step ```ts const opts: SDKOptions = { apiKey: '', environment: 'production', } const { error, data: nextStep } = await getNextStepDetails( { flowId: '', email: 'user@example.com', credential: { type: 'EXTERNAL_ID', externalId: 'user_123' }, isSandbox: true, }, opts, ) if (error) { console.error(error) } else { console.log('Next step:', nextStep) } ``` - Use `getNextStepDetails` to decide whether to ask for document selection, document images, liveness capture, or another step. - Provide at least one identity field: `email`, an `EXTERNAL_ID` credential, or a `WALLET` credential. - This helper calls the `sdk_get_next_step` endpoint documented in `docs/openapi/sdk-get-next-step.api.mdx`. ### Complete Document Selection and Document Verification ```ts async function readBase64File(filePath: string) { return (await readFile(filePath)).toString('base64') } const opts: SDKOptions = { apiKey: '', environment: 'production', } const verificationSessionResponse = await createVerificationSession( { email: 'user@example.com', flowId: '', isSandbox: true, }, opts, ) if (verificationSessionResponse.error || !verificationSessionResponse.data) { throw new Error('Failed to create verification session') } await completeDocumentSelectionStep( { verificationSession: verificationSessionResponse.data, payload: { country: 'IT', documentType: DocumentType.IDENTITY_CARD, }, }, opts, ) const dvResult = await completeDvStep( { verificationSession: verificationSessionResponse.data, countryCode: 'IT', images: { type: 'DOUBLE_SIDED_DOCUMENT', frontImage: await readBase64File('./front.jpg'), backImage: await readBase64File('./back.jpg'), }, }, opts, ) console.log('DV step completed') console.log(dvResult) ``` - This example follows `../zyphe-sdk/examples/node-complete-step-dv/src/index.ts`. - Use `DocumentType.IDENTITY_CARD`, `DocumentType.DRIVING_LICENSE`, or `DocumentType.PASSPORT` when selecting the document type. - `completeDvStep` accepts either: - `type: 'DOUBLE_SIDED_DOCUMENT'` with `frontImage` and `backImage` - `type: 'SINGLE_SIDED_DOCUMENT'` with a single `image` - Image values must be base64-encoded strings. - The SDK returns the API response for the submitted document job, including the verification request ID and job ID. ### Complete a Liveness Step ```ts async function readBinaryFile(filePath: string) { return new Uint8Array(await readFile(filePath)) } const opts: SDKOptions = { apiKey: '', environment: 'production', } const verificationSessionResponse = await createVerificationSession( { email: 'user@example.com', flowId: '', isSandbox: true, }, opts, ) if (verificationSessionResponse.error || !verificationSessionResponse.data) { throw new Error('Failed to create verification session') } const calibrationImage = await readBinaryFile('./calibration.jpg') const video = await readBinaryFile('./liveness.mp4') const movementImages = await Promise.all(['./movement-1.jpg', './movement-2.jpg'].map((filePath) => readBinaryFile(filePath))) const livenessResult = await completeLivenessStep( { verificationSession: verificationSessionResponse.data, frontImage: Buffer.from(calibrationImage), video: Buffer.from(video), movementImages: movementImages.map((image) => Buffer.from(image)), }, opts, ) console.log('Liveness step completed') console.log(livenessResult) ``` - This example follows `../zyphe-sdk/examples/node-complete-step-liveness/src/index.ts`. - `completeLivenessStep` first fetches the challenge configuration, uploads the required assets to the provided presigned URLs, and then calls the final liveness processing endpoint. - For active liveness challenges, you must provide a `video` and the same number of `movementImages` requested by the challenge. - `frontImage` is the calibration image uploaded before the final liveness submission. --- ## 4. Flow Results You can use the Node SDK to list flow results for a flow and fetch a single flow result by ID. ### List Flow Results ```ts const opts: SDKOptions = { apiKey: '', environment: 'production', } const { error, data } = await listFlowResults( { organizationId: '', flowSlug: '', isSandbox: true, pagination: { take: 10, skip: 0, }, }, opts, ) if (error) { console.error(error) } else { console.log('Total flow results:', data?.totalCount ?? 0) console.log('Current page:', data?.page ?? []) } ``` - `organizationId`: The organization that owns the flow results. - `flowSlug`: The flow slug used to scope the results. - `isSandbox`: Set to `true` for sandbox data and `false` for production data. - `pagination` (optional): Use `take`, `skip`, `sort`, and `filter` to control paging. - `locale` (optional): Localize fields that support translated values. - Returns: A Promise resolving to a paginated response with `totalCount` and a `page` array of flow results. ### Get a Flow Result ```ts const opts: SDKOptions = { apiKey: '', environment: 'production', } const { error, data: flowResult } = await getFlowResult( { organizationId: '', flowResultId: '', isSandbox: true, }, opts, ) if (error) { console.error(error) } else { console.log('Flow result:', flowResult) } ``` - `flowResultId`: The ID of the specific flow result you want to retrieve. - Returns: A Promise resolving to the full flow result payload, including result collections such as `dvResults`, `poaResults`, and `amlResults` when available. `getFlowResult` and `getDvResult` are Export API helpers. They require a secret key and an organization with the Export API product enabled. `getDvResult` returns decoded document fields and images from the protobuf stream. See [Export API](/docs/guides/export-api). --- ## 5. AML Screening `screenAml` runs a live AML screening for a person or a company, outside any verification flow. It queries the configured screening provider and returns its raw matches: nothing is scored or stored. ```ts const opts: SDKOptions = { apiKey: '', environment: 'production', } const { error, data } = await screenAml( { organizationId: '', isSandbox: true, subjectType: 'PERSON', // or 'COMPANY' query: { name: 'Jane Doe', birthDate: '1980-01-01', country: 'nl', }, }, opts, ) if (error) { console.error(error) } else { for (const entity of data.entities) { console.log(entity.name, entity.score) } } ``` - `query` accepts the person or company attributes you have, such as `name`, `firstName`, `lastName`, `birthDate`, `country`, `nationality`, `registrationNumber`, or `passportNumber`. The more you send, the fewer false positives. - The response lists the raw provider matches in `entities` (each with a match `score`), with the `provider` and entity `format` used. - AML screening is billed per call. For how screening works inside a flow, see [AML](/docs/aml). --- ## 6. KYB Cases Every KYB result is handled as a **case**: its status, due-diligence level, rating, officers, and decision. The case helpers address it by `caseId`, the ID of the KYB case (the same value as the KYB result ID). All KYB helpers require a secret key. ### Read a Case ```ts const opts: SDKOptions = { apiKey: '', environment: 'production', } const params = { organizationId: '', caseId: '', isSandbox: true } const { data: kybCase } = await getKybCase(params, opts) console.log(kybCase?.status, kybCase?.dueDiligenceLevel, kybCase?.rating) const { data: officers } = await getKybCaseOfficers(params, opts) console.log(officers?.ubos.length, 'UBOs,', officers?.directors.length, 'directors') ``` - `getKybCase` returns the case as the dashboard reads it: `status` (`OPEN`, `PROCESSING`, `WAITING_INPUT`, `ACTION_REQUIRED`, `READY_FOR_REVIEW`, `APPROVED`, `REJECTED`, `CANCELLED`), `dueDiligenceLevel`, `rating`, assignment, what the case is waiting on, and each attempt at deciding it. - `getKybCaseOfficers` returns the case's `ubos` and `directors`. Each person carries the stable `id` the officer helpers below use. ### Manage UBOs and Directors ```ts const { data: officers } = await addKybCaseUbos( { ...params, persons: [ { firstName: 'Jane', lastName: 'Doe', dateOfBirth: '1980-01-01', country: 'nl', gender: 'F', // With an email the person is invited to complete full KYC; // without one they are screened by name only (AML) email: 'jane.doe@example.com', }, ], }, opts, ) // Invite the UBO just added to complete their KYC await sendKybCaseUboReminder({ ...params, recipientIndex: officers!.ubos.length - 1 }, opts) await removeKybCaseDirector({ ...params, personId: '' }, opts) ``` - `addKybCaseUbos` / `addKybCaseDirectors` add one or more people; `removeKybCaseUbo` / `removeKybCaseDirector` remove one by `personId`. All four answer with the case's officers as they stand after the change (`{ caseId, ubos, directors }`). - `sendKybCaseUboReminder` sends (or re-sends) the KYC invitation to the UBO at `recipientIndex` in the `ubos` list. Only a UBO with an email can be invited. ### Request a Document ```ts const { data: documentRequest } = await requestKybCaseOnDemandDocument( { ...params, documentKey: '', recipientEmail: 'compliance@company.com', // optional subject: 'One more document', // optional body: 'Please upload the requested document.', // optional }, opts, ) ``` - `documentKey` must name a document the flow marks as **on demand**. A document the flow requires upfront is rejected. ### Decide a Case ```ts const { data: decision, response } = await decideKybCase( { ...params, outcome: 'APPROVED', // or 'REJECTED' reason: 'Checks complete', // mandatory on a rejection dueDiligenceLevel: 'standard', // optional, approvals only }, opts, ) if (response.status === 202) { // The organization's approval matrix asks for a second signature console.log('Awaiting:', decision?.decisionProposal) } else { console.log('Decided:', decision?.outcome, decision?.statusAfter) } ``` - A decision is **final**: a decided case cannot be decided again. - An approval needs the case in `READY_FOR_REVIEW`. A rejection is also accepted from `ACTION_REQUIRED`, and always needs a `reason`. Add a `reasonCode` (for example `SANCTIONS_CONFIRMED` or `OUTSIDE_RISK_APPETITE`) to classify it. - When the organization's approval matrix requires two signatures, the call answers `202` with a `decisionProposal` listing the roles it awaits. An API key can take the **first** signature only: the case closes when a person holding one of those roles confirms the proposal in the dashboard. Sending `confirmingProposalId` with an API key is refused with `kyb_case_second_signature_required`. ### Deprecated KYB Helpers The helpers below address the case by `kybResultId` and call endpoints that are deprecated. They keep working, but new integrations should use the case helpers: | Deprecated | Use instead | | ---------------------------- | -------------------------------- | | `addKybUbos` | `addKybCaseUbos` | | `removeKybUbo` | `removeKybCaseUbo` | | `addKybDirectors` | `addKybCaseDirectors` | | `removeKybDirector` | `removeKybCaseDirector` | | `requestKybOnDemandDocument` | `requestKybCaseOnDemandDocument` | | `sendKybUboReminder` | `sendKybCaseUboReminder` | When migrating, pass the same ID as `caseId`. The officer helpers now answer with `{ caseId, ubos, directors }` instead of the whole KYB result, so read `ubos` / `directors` instead of `uboDefinitions` / `directorDefinitions`. The [migration guide](/docs/guides/sdk/migration-guide) walks through every change. --- ## 7. Transaction Monitoring Stream payment events from your backend and get the synchronous Allow / Review / Block verdict. See [Transaction Monitoring](/docs/guides/transaction-monitoring) for how rules, lists, and thresholds produce it. ```ts const opts: SDKOptions = { apiKey: '', environment: 'production', } const { error, data: verdict } = await ingestTransaction( { organizationId: '', isSandbox: true, transaction: { externalId: 'txn_123', // your ID, also the idempotency key identityId: '', direction: 'WITHDRAWAL', // 'DEPOSIT' | 'WITHDRAWAL' | 'TRANSFER' amountMinor: 125000, // integer minor units: 1,250.00 EUR currency: 'EUR', occurredAt: new Date().toISOString(), channel: 'sepa', // optional description: 'Invoice 2026-042', // optional, screened for keywords counterparty: { kind: 'PERSON', name: 'John Smith', address: 'NL91ABNA0417164300' }, // optional }, }, opts, ) if (error) { console.error(error) } else { console.log(verdict.decision, verdict.riskProbability, verdict.firedRules, verdict.alerts) } // Read it back, then report the payment lifecycle const { data: transaction } = await getTransaction( { organizationId: '', transactionId: verdict!.transactionId, isSandbox: true }, opts, ) await updateTransactionStatus( { organizationId: '', transactionId: verdict!.transactionId, status: 'SETTLED', isSandbox: true }, opts, ) ``` - `ingestTransaction` is **idempotent on `externalId`**: sending the same event again returns the original verdict with `replay: true`, without re-evaluating or billing it twice. Retrying with the same `externalId` is the safe recovery after a timeout or a `5xx`. - `amountMinor` is an integer in minor units (cents); there is no float money. - `updateTransactionStatus` sets the payment status: `PENDING`, `SETTLED`, `FAILED`, `CANCELED`, or `REVERSED`. Moving a transaction to `FAILED`, `CANCELED`, or `REVERSED` removes it from the velocity counters once; retrying the same update is safe. - Transaction ingestion is billed per ingested transaction (replays are not billed). --- ## 8. Types and Configuration - `InitializeZypheFlowParams`, `SDKOptions`, `SdkCreateVerificationRequestResponse`, for type-safe integration. - `Environments`, `EnvironmentConfigs`, `API_KEY_HEADER`, for environment and API configuration. --- ## React Native This guide shows you how to integrate Zyphe verification into a React Native application using Expo or bare React Native. ## Overview The React Native integration uses a WebView to display the Zyphe verification flow. You'll need: - A backend server to create verification sessions securely - A React Native app with WebView to display the verification flow - Proper permissions configured for camera, microphone, and other required features ## Prerequisites - Node.js 18+ installed - React Native or Expo project set up - Zyphe account with API credentials ([Get started here](https://verify.zyphe.com)) --- ## Backend Setup :::warning[Security] **Never expose your API key in the mobile app.** Always create verification sessions on your backend server. ::: You need to create a backend endpoint that generates verification session URLs securely. You can use any backend framework (Express, Fastify, NestJS, Hono, etc.). Your backend service should: 1. **Authenticate the user** - Verify the user's identity using your authentication system (session, JWT, OAuth, etc.) 2. **Validate identity fields** - Ensure at least one of `email`, external ID, or wallet is provided 3. **Create the verification session** - Use the Zyphe SDK **or** raw HTTP with a **secret** API key 4. **Return the verification URL** - Send the URL back to the mobile app 5. **Handle errors appropriately** - Manage authentication failures and session creation errors Platform-agnostic architecture (including native iOS/Android WebView notes): [Mobile integration](/docs/guides/mobile-integration). Raw HTTP recipe without npm: [Backend API integration](/docs/guides/backend-api-integration). ### Install the SDK ### Create Verification Session Endpoint Create an API endpoint that receives the user's identity details and returns a verification URL. :::warning[Secret key on the server] Session creation is a **backend** operation. Use a **secret** API key (`zyphe_sk_…`), never a publishable key and never a key embedded in the mobile app. See [API keys](/docs/guides/api-keys). ::: ```ts createVerificationSession, constructVerificationSessionUrl, type SDKOptions, type InitializeZypheFlowParams, } from '@zyphe-sdk/core' // Secret key — server-side only (prefix zyphe_sk_) const SECRET_API_KEY = process.env.ZYPHE_SECRET_API_KEY! const FLOW_ID = process.env.ZYPHE_FLOW_ID! // The flow ID you want to use for creating the verification session type CreateVerificationSessionInput = { email?: string externalId?: string wallet?: { address: string chain: 'ETHEREUM' | 'ETHEREUM_TESTNET' | 'SOLANA' | 'SOLANA_TESTNET' } } // Your API endpoint handler (adapt to your framework) async function createVerificationSessionHandler(input: CreateVerificationSessionInput) { if (!input.email && !input.externalId && !input.wallet) { throw new Error('Provide at least one of email, externalId, or wallet') } const opts: SDKOptions = { apiKey: SECRET_API_KEY, environment: 'production', // maps to api.zyphe.com + verify.zyphe.com } const flowParams: InitializeZypheFlowParams = { email: input.email, credentials: [ ...(input.externalId ? [{ type: 'EXTERNAL_ID' as const, externalId: input.externalId }] : []), ...(input.wallet ? [{ type: 'WALLET' as const, address: input.wallet.address, chain: input.wallet.chain }] : []), ], flowId: FLOW_ID, isSandbox: true, } const { error, data: verificationSession } = await createVerificationSession(flowParams, opts) if (error) { throw new Error('Failed to create verification session') } const verificationSessionUrl = constructVerificationSessionUrl({ opts, verificationSession, flowParams, }) return { url: verificationSessionUrl, sessionId: verificationSession.id, } } ``` `email` is optional when `credentials` includes an external ID or wallet. You can send any combination, such as email only, external ID only, wallet only, email plus external ID, or all three. ### Fullscreen Mode By default, the verification UI displays as cards. To show the UI in fullscreen mode, add the `zypheFullscreen=true` query parameter to the verification URL: ```ts const verificationSessionUrl = constructVerificationSessionUrl({ opts, verificationSession, flowParams, }) // Add fullscreen mode const fullscreenUrl = `${verificationSessionUrl}&zypheFullscreen=true` ``` This is particularly recommended for mobile WebView implementations to provide a better user experience. --- ## React Native App Setup ### Install Required Packages ```bash npm install react-native-webview # For Expo: npx expo install react-native-webview expo-camera expo-constants ``` For bare React Native, follow the [react-native-webview installation guide](https://github.com/react-native-webview/react-native-webview/blob/master/docs/Getting-Started.md). --- ## Platform Configuration ### Android Permissions #### Expo (Managed Workflow) Add permissions to your `app.json` or `app.config.js`: ```json { "expo": { "android": { "permissions": [ "android.permission.INTERNET", "android.permission.CAMERA", "android.permission.RECORD_AUDIO", "android.permission.MODIFY_AUDIO_SETTINGS" ] }, "plugins": [ [ "expo-build-properties", { "android": { "usesCleartextTraffic": true } } ] ] } } ``` :::warning The `usesCleartextTraffic` setting is only needed for development to allow HTTP connections to localhost. **Remove this for production builds** and use HTTPS endpoints only. ::: #### Bare React Native Edit `android/app/src/main/AndroidManifest.xml`: ```xml ``` #### Android Permissions Explained - **INTERNET**: Required for all network communication - **CAMERA**: Required for document scanning and selfie verification - **RECORD_AUDIO**: Required for liveness detection and video recording - **MODIFY_AUDIO_SETTINGS**: Required for audio settings during verification --- ### iOS Permissions #### Expo (Managed Workflow) Add permissions to your `app.json` or `app.config.js`: ```json { "expo": { "ios": { "infoPlist": { "NSCameraUsageDescription": "Camera access is required for identity verification and document scanning.", "NSMicrophoneUsageDescription": "Microphone access is required for liveness detection during identity verification.", "NSPhotoLibraryUsageDescription": "Photo library access allows you to upload existing photos for verification.", "NSLocationWhenInUseUsageDescription": "Location access may be used for fraud prevention during verification." } } } } ``` #### Bare React Native Edit `ios/YourAppName/Info.plist`: ```xml NSCameraUsageDescription Camera access is required for identity verification and document scanning. NSMicrophoneUsageDescription Microphone access is required for liveness detection during identity verification. NSPhotoLibraryUsageDescription Photo library access allows you to upload existing photos for verification. NSLocationWhenInUseUsageDescription Location access may be used for fraud prevention during verification. ``` #### iOS Permissions Explained - **NSCameraUsageDescription**: Required for document capture and selfie verification - **NSMicrophoneUsageDescription**: Required for liveness detection and video recording - **NSPhotoLibraryUsageDescription**: Allows users to upload existing photos - **NSLocationWhenInUseUsageDescription**: Optional but recommended for fraud detection :::info The description strings will be shown to users when iOS requests permission. Make them clear and specific to pass App Store review. ::: --- ## Implementation ### Basic Example Here's a complete React Native component that implements Zyphe verification: ```tsx const BACKEND_URL = 'http://localhost:3000' // Your backend URL export default function App() { const [email, setEmail] = useState('') const [verificationUrl, setVerificationUrl] = useState('') const [loading, setLoading] = useState(false) const [showWebView, setShowWebView] = useState(false) const createVerificationSession = async () => { if (!email) { Alert.alert('Error', 'Please enter your email') return } setLoading(true) try { // Request camera permission before proceeding const { status } = await Camera.requestCameraPermissionsAsync() if (status !== 'granted') { Alert.alert( 'Camera Permission Required', 'Camera access is required for identity verification. Please enable camera permissions in your device settings.', ) setLoading(false) return } const response = await fetch(`${BACKEND_URL}/api/create-verification-session`, { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify({ email }), }) const data = await response.json() if (response.ok && data.url) { setVerificationUrl(data.url) setShowWebView(true) } else { Alert.alert('Error', data.error || 'Failed to create verification session') } } catch (error) { Alert.alert('Error', 'Failed to connect to the server. Make sure the backend is running.') } finally { setLoading(false) } } const handleWebViewMessage = (event: any) => { // Handle messages from the WebView if needed console.log('WebView message:', event.nativeEvent.data) } const resetSession = () => { setShowWebView(false) setVerificationUrl('') setEmail('') } if (showWebView && verificationUrl) { return ( ← Back Verification ( )} /> ) } return ( Zyphe Verification Enter your email to start the verification process {loading ? : Start Verification} Make sure your backend server is running ) } const styles = StyleSheet.create({ container: { flex: 1, backgroundColor: '#f5f5f5', }, content: { flex: 1, justifyContent: 'center', padding: 20, }, title: { fontSize: 32, fontWeight: 'bold', marginBottom: 10, textAlign: 'center', color: '#333', }, subtitle: { fontSize: 16, marginBottom: 30, textAlign: 'center', color: '#666', }, input: { backgroundColor: '#fff', borderWidth: 1, borderColor: '#ddd', borderRadius: 8, padding: 15, fontSize: 16, marginBottom: 20, }, button: { backgroundColor: '#007AFF', borderRadius: 8, padding: 15, alignItems: 'center', }, buttonDisabled: { backgroundColor: '#9cc9ff', }, buttonText: { color: '#fff', fontSize: 18, fontWeight: '600', }, infoContainer: { marginTop: 30, padding: 15, backgroundColor: '#e8f4ff', borderRadius: 8, }, infoText: { fontSize: 14, color: '#007AFF', textAlign: 'center', }, webViewHeader: { flexDirection: 'row', alignItems: 'center', padding: 15, backgroundColor: '#fff', borderBottomWidth: 1, borderBottomColor: '#ddd', }, backButton: { padding: 5, }, backButtonText: { fontSize: 18, color: '#007AFF', fontWeight: '600', }, headerTitle: { flex: 1, fontSize: 18, fontWeight: '600', textAlign: 'center', marginRight: 60, color: '#333', }, webView: { flex: 1, }, loadingContainer: { flex: 1, justifyContent: 'center', alignItems: 'center', }, }) ``` --- ## WebView Configuration The WebView must be configured with specific properties for the verification flow to work properly: ```tsx ``` ### Key Properties Explained - **allowsInlineMediaPlayback**: Allows the camera/media to play inline instead of fullscreen (iOS) - **mediaPlaybackRequiresUserAction**: Disables the requirement for user interaction before media plays - **javaScriptEnabled**: Required for the verification flow to function - **domStorageEnabled**: Required for storing session data and state --- ## Permission Handling ### Request Permissions at Runtime It's recommended to request camera permissions before starting the verification flow: #### Using Expo Camera ```tsx const requestPermissions = async () => { const { status } = await Camera.requestCameraPermissionsAsync() if (status !== 'granted') { Alert.alert('Permission Required', 'Camera access is required for verification.') return false } return true } ``` #### Using Bare React Native (Android) ```tsx const requestAndroidPermissions = async () => { if (Platform.OS !== 'android') return true try { const granted = await PermissionsAndroid.requestMultiple([ PermissionsAndroid.PERMISSIONS.CAMERA, PermissionsAndroid.PERMISSIONS.RECORD_AUDIO, ]) return ( granted['android.permission.CAMERA'] === PermissionsAndroid.RESULTS.GRANTED && granted['android.permission.RECORD_AUDIO'] === PermissionsAndroid.RESULTS.GRANTED ) } catch (err) { console.warn(err) return false } } ``` --- ## Testing ### iOS Simulator Use the default localhost URL: ```tsx const BACKEND_URL = 'http://localhost:3000' ``` ### Android Emulator Use the special Android emulator address: ```tsx const BACKEND_URL = 'http://10.0.2.2:3000' // Points to host machine's localhost ``` ### Physical Devices For testing on physical devices, you'll need to: 1. Use your computer's local network IP address 2. Ensure both devices are on the same WiFi network 3. Configure firewall to allow connections on port 3000 ```tsx const BACKEND_URL = 'http://192.168.1.100:3000' // Replace with your local IP ``` Or use automatic IP detection with the `ip` package. --- ## Production Checklist Before deploying to production: - ✅ Remove `usesCleartextTraffic` from Android config - ✅ Use HTTPS endpoints for all API calls - ✅ Never expose API keys in the mobile app - ✅ Test on real devices with production builds - ✅ Verify all permission descriptions are clear and accurate - ✅ Handle permission denials gracefully - ✅ Add error handling for network failures - ✅ Test the complete verification flow end-to-end --- ## Common Issues ### Camera Not Working in WebView Make sure: - All required permissions are granted - `allowsInlineMediaPlayback={true}` is set - `mediaPlaybackRequiresUserAction={false}` is set - Camera permissions are declared in AndroidManifest.xml/Info.plist ### Backend Connection Errors - iOS Simulator: Use `http://localhost:3000` - Android Emulator: Use `http://10.0.2.2:3000` - Physical Devices: Use your computer's local network IP - Ensure backend server is running ### Permissions Not Requested - Check that permission strings are in AndroidManifest.xml (Android) or Info.plist (iOS) - Verify you're calling the permission request methods - Check device settings to ensure permissions weren't permanently denied --- ## API Keys Management API keys authenticate requests to the Zyphe **API** (`https://api.zyphe.com`). They are not used against the documentation site. See [Environment setup](/docs/guides/environment-setup) for hosts. ## Key Types Zyphe provides two distinct types of API keys, each designed for specific use cases and security requirements: ### Publishable Keys - **Prefix:** `zyphe_pk_` - **Use Case:** Client-side code only—primarily the [Browser SDK](/docs/guides/sdk/browser) in a web app with restricted **Allowed Origins** (CORS). - **Security:** Limited permissions. Never sufficient as a substitute for a secret key on your backend. ### Secret Keys - **Prefix:** `zyphe_sk_` - **Use Case:** **All backend / server-side calls**, including: - `POST /sdk/flow/{flowId}/vr/create` (session creation) - Step completion, next-step, flow results, AML, KYB helpers - Direct HTTP integrations without the npm SDK ([Backend API integration](/docs/guides/backend-api-integration)) - [Node SDK](/docs/guides/sdk/node) / `@zyphe-sdk/core` on a server - The [Export API](/docs/guides/export-api) (secret keys only) - **Security:** Secret keys grant broad access to your organization's API resources. They must never be embedded in mobile apps, browser bundles, or public repositories. | Call site | Key type | | --------------------------- | ---------------------------------------------------- | | Your backend (any language) | **Secret** `zyphe_sk_…` | | Browser SDK in the page | **Publishable** `zyphe_pk_…` | | Mobile app binary | **Neither** — call your backend; backend uses secret | :::tip[Backend integrations] If you are not using the Browser SDK in a web page, generate a **secret** key. A very common `401 invalid_api_key` cause is sending a publishable key to `vr/create` from a server. ::: ## Managing API Keys You can manage your API keys through the Zyphe Dashboard. The following operations are available:
Open the API Keys page from the dashboard to create and manage API credentials.
- **Create:** Generate new keys for different environments or applications. You can specify a name, description, and key type. - **View:** Access your existing keys. Note that for security reasons, the full value of a Secret Key is only displayed once at the time of creation. - **Update:** Modify the metadata of a key, such as its name, description, or allowed origins. - **Delete:** Revoke a key to immediately disable its access to the API.
When generating a key, choose its type and configure allowed origins for publishable keys.
Generated keys appear in the API Keys list with their type, allowed origins, and actions.
## Where to generate keys 1. Open the [Zyphe Dashboard](https://verify.zyphe.com). 2. Navigate to **API Keys** (organization developer settings). 3. Click **Generate API Key**, choose **Secret** or **Publishable**, name the key, and (for publishable) set allowed origins. 4. Copy a **secret** key immediately—it is shown in full only once. ## Troubleshooting `invalid_api_key` HTTP `401` with body like: ```json { "code": 10201, "errorTag": "invalid_api_key" } ``` | Cause | What to check | | ---------------------------- | ------------------------------------------------------------------------------------------------- | | Wrong key type | Backend must use `zyphe_sk_…`, not `zyphe_pk_…` | | Wrong API host | Base URL must be `https://api.zyphe.com` (not `docs.zyphe.com`) | | Truncated / reformatted key | No spaces, quotes, or line breaks in the header value | | Key deleted or rotated | Generate a new secret key in the dashboard | | Sandbox vs production mix-up | `sandbox` / `isSandbox` must match the dashboard mode — [Sandbox mode](/docs/guides/sandbox-mode) | Full error catalog: [API errors](/docs/reference/statuses-and-codes#api-errors). ## Security Best Practices - **Protect Secret Keys:** Always store secret keys securely using environment variables or secret management services. - **Restrict Origins:** For publishable keys, always configure the "Allowed Origins" setting to ensure the key can only be used from your authorized domains. - **Rotate Keys:** Periodically rotate your API keys to minimize the impact of a potential credential leak. - **Principle of Least Privilege:** Use different keys for different applications or environments to isolate access. ## Related Documentation - [Environment setup](/docs/guides/environment-setup) - [Backend API integration](/docs/guides/backend-api-integration) - [SDK Integration](/docs/guides/sdk) - [Export API](/docs/guides/export-api) - [Webhook Signature](/docs/guides/webhook/webhook-signature) - [Statuses and codes](/docs/reference/statuses-and-codes) --- ## Backend API integration (without the npm SDK) This is the **end-to-end recipe** for integrating Zyphe from your backend using the HTTP **SDK API** (`https://api.zyphe.com/sdk/...`) directly—no Node, browser, or React Native package required. You will: 1. Create a verification request with a **secret** API key 2. Compose a hosted session URL from the response 3. Open that URL in a WebView, iframe, or browser redirect 4. Receive results via webhook (and optionally fetch images via the Export API) If you prefer packages, use the [Node SDK](/docs/guides/sdk/node) for the same API. For product tradeoffs, see [Hosted UI vs direct API](/docs/guides/hosted-vs-direct-api) and [Choosing an integration method](/docs/choosing-an-integration-method). :::tip[Naming] **SDK API** means the HTTP routes under `/sdk/...` on `api.zyphe.com`. **SDK packages** means `@zyphe-sdk/node`, `@zyphe-sdk/browser`, and related npm libraries. You can use the HTTP API without installing any package. ::: ## Prerequisites | Item | Where | | -------------------------------- | --------------------------------------------------- | | Secret API key (`zyphe_sk_…`) | [API keys](/docs/guides/api-keys) | | Flow ID (UUID) | Dashboard → flow settings | | Correct hosts | [Environment setup](/docs/guides/environment-setup) | | Sandbox flag aligned | [Sandbox mode](/docs/guides/sandbox-mode) | | A webhook endpoint (recommended) | [Webhook endpoints](/docs/guides/webhook/endpoints) | ## 1. Create a verification request ```bash curl -X POST "https://api.zyphe.com/sdk/flow/${ZYPHE_FLOW_ID}/vr/create?sandbox=true" \ -H "x-api-key: ${ZYPHE_SECRET_API_KEY}" \ -H "Content-Type: application/json" \ -d '{ "email": "applicant@example.com", "customData": { "externalUserId": "user_123", "plan": "pro" } }' ``` | Piece | Value | | ------------- | ------------------------------------------------------------------------- | | Method / path | `POST /sdk/flow/{flow_id}/vr/create` | | Query | `sandbox=true` for sandbox, `sandbox=false` for production (**required**) | | Header | `x-api-key: zyphe_sk_…` (secret key) | | Body | Identity + optional `customData` (see below) | Provide **at least one** identity: `email`, and/or credentials such as external ID or wallet (see [OpenAPI](/docs/openapi/zyphe-sdk) `SdkCreateVerificationRequestPayload`). ### Response fields you need A successful response includes (among other fields): | Field | Use | | ------------------------ | ----------------------------------------------------------- | | `verificationRequest.id` | Session id → query param `zypheVr` | | `zypheToken` | Session JWT → query param `zypheToken` | | `zypheAccessSig` | Short-lived access signature → query param `zypheAccessSig` | | `flowSlug` | Hosted UI path segment | | `flowStepSlug` | First incomplete step (informational; URL uses `flowSlug`) | | `isSandbox` | Must match the `sandbox` query you sent | | `email` | Echo of identity email when present → optional `zypheEmail` | Full schema: OpenAPI `SdkCreateVerificationRequestResponse`. ### `customData` - Optional JSON object of arbitrary key/value metadata attached to the verification request. - Round-trips into webhooks as `data..customData` and top-level `custom` (see [Custom fields](/docs/guides/webhook/custom-fields)). - Use opaque business identifiers (your user id, application id). Avoid putting secrets or unnecessary PII in query strings if you also pass metadata on public links. ## 2. Compose the session URL ```text https://verify.zyphe.com{/sandbox}/flow/?zypheVr=&zypheToken=&zypheAccessSig=&zypheEmail= ``` | Mode | Base path | | ---------------------------- | -------------------------------------------------- | | Sandbox (`sandbox=true`) | `https://verify.zyphe.com/sandbox/flow/` | | Production (`sandbox=false`) | `https://verify.zyphe.com/flow/` | **Example (sandbox):** ```text https://verify.zyphe.com/sandbox/flow/my-kyc-flow?zypheVr=cf52e18e-28d1-4a2f-8304-c04ef5a75d0f&zypheToken=eyJ...&zypheAccessSig=...&zypheEmail=applicant%40example.com ``` Optional query parameters supported by the hosted UI and npm helpers: | Param | Purpose | | ---------------------- | -------------------------------------------------- | | `zypheFullscreen=true` | Fullscreen layout (recommended in mobile WebViews) | | `zypheHandoffBaseUrl` | Return / handoff base URL for your app | | Theme params | See [Theming](/docs/guides/theming) | Always **URL-encode** query values. :::warning Do not open `https://api.zyphe.com/...` in a WebView. Users complete verification on **`verify.zyphe.com`**. The API host is only for your backend. ::: ## 3. Present the URL to the user | Platform | Pattern | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Web** | Redirect the browser, or embed in an iframe ([Browser SDK](/docs/guides/sdk/browser) automates this) | | **Mobile** | Load the URL in a WebView with camera permissions ([Mobile integration](/docs/guides/mobile-integration)) | | **Email / SMS** | Send the composed URL (or use a [public flow link](/docs/choosing-an-integration-method#public-link) when you do not need server-side session creation) | ## 4. Receive results 1. Create an organization [webhook endpoint](/docs/guides/webhook/endpoints) and subscribe it to the events you handle. Scope it to this flow, or to every flow you own. 2. Verify `X-Signature` ([Webhook signature](/docs/guides/webhook/webhook-signature)). 3. Branch on the canonical `type` (`V2`) or on `event` / `flowStatus` (`LEGACY_V1`) — see [Payload versions](/docs/guides/webhook/payload-versions) and [Statuses and codes](/docs/reference/statuses-and-codes). 4. Correlate with your system via `flow.customData` on `V2`, or top-level `custom` on `LEGACY_V1`. The verification request's own `customData` sits inside the result object in both. To attach a callback to a single verification run instead, pass `webhook` to the creation call above: [Session webhooks](/docs/guides/webhook/session-webhooks). **Document images are not included in webhook payloads by default.** Extended webhooks may include a limited selfie URL; full document media requires the [Export API](/docs/guides/export-api) (must be enabled by Zyphe). ## 5. Optional: complete steps without the hosted UI You can drive document selection, document upload, and liveness from your backend using the step endpoints documented in OpenAPI and the [Node complete-step helpers](/docs/guides/sdk/node#3-complete-verification-steps). That path has important tradeoffs (capture quality, device signals, liveness modes). Read [Hosted UI vs direct API](/docs/guides/hosted-vs-direct-api) before choosing it. ## Minimal Node example (raw `fetch`) ```ts const API = process.env.ZYPHE_API_BASE_URL ?? 'https://api.zyphe.com' const VERIFY = process.env.ZYPHE_VERIFY_BASE_URL ?? 'https://verify.zyphe.com' const apiKey = process.env.ZYPHE_SECRET_API_KEY! const flowId = process.env.ZYPHE_FLOW_ID! const sandbox = process.env.ZYPHE_SANDBOX !== 'false' async function createSessionUrl(email: string, customData?: Record) { const res = await fetch(`${API}/sdk/flow/${flowId}/vr/create?sandbox=${sandbox}`, { method: 'POST', headers: { 'x-api-key': apiKey, 'Content-Type': 'application/json', }, body: JSON.stringify({ email, customData }), }) if (!res.ok) { const err = await res.json().catch(() => ({})) throw new Error(`Create VR failed: ${res.status} ${JSON.stringify(err)}`) } const data = await res.json() const pathPrefix = data.isSandbox ? '/sandbox' : '' const params = new URLSearchParams({ zypheVr: data.verificationRequest.id, zypheToken: data.zypheToken, zypheAccessSig: data.zypheAccessSig, }) if (data.email || email) { params.set('zypheEmail', data.email ?? email) } params.set('zypheFullscreen', 'true') return `${VERIFY}${pathPrefix}/flow/${data.flowSlug}?${params.toString()}` } ``` ## Common failures | Symptom | Likely cause | Fix | | ---------------------------- | -------------------------------------------------------- | --------------------------------------------------------------------------------- | | Connection / HTML error page | API base URL is `docs.zyphe.com` or another non-API host | Use `https://api.zyphe.com` | | `401` · `invalid_api_key` | Publishable key, typo, or wrong environment | Use `zyphe_sk_…`; see [API errors](/docs/reference/statuses-and-codes#api-errors) | | Flow / VR not found | `sandbox` flag does not match the flow | Align flag, dashboard mode, and URL path | | User stuck / blank WebView | Missing camera permissions or wrong WebView flags | [Mobile integration](/docs/guides/mobile-integration) | | No images in webhook | Expected by design | [Export API](/docs/guides/export-api) | ## Related - [Environment setup](/docs/guides/environment-setup) - [Mobile integration](/docs/guides/mobile-integration) - [Hosted UI vs direct API](/docs/guides/hosted-vs-direct-api) - [Get next step](/docs/guides/sdk/get-next-step) - [Webhooks](/docs/guides/webhook) - [OpenAPI reference](/docs/openapi/zyphe-sdk) --- ## Environment setup Use this page as the **single source of truth** for hosts, environment variables, and which URL does what. Most failed first integrations come from pointing the API client at the wrong host (including the documentation site). ## Hosts | Purpose | Production URL | Notes | | ---------------------------- | -------------------------- | ------------------------------------------------------------------------------------------------------------- | | **API base URL** | `https://api.zyphe.com` | All backend HTTP calls (`/sdk/...`, session create, step completion, flow results, …). Send `x-api-key` here. | | **Dashboard** | `https://verify.zyphe.com` | Sign in to configure flows, API keys, webhooks, and review results. Not an API host. | | **Verification / hosted UI** | `https://verify.zyphe.com` | User-facing verification session pages. Open this in a browser, redirect, iframe, or mobile WebView. | | **Documentation** | `https://docs.zyphe.com` | Human- and LLM-readable docs only. **Never** send API traffic here. | The dashboard and hosted verification UI share `https://verify.zyphe.com`. Sandbox vs production is a **flag and URL path**, not a different host. See [Sandbox mode](/docs/guides/sandbox-mode). :::danger[Wrong host = guaranteed failure] `https://docs.zyphe.com` is **not** an API base URL. Requests to the docs site never authenticate, never create sessions, and will not return verification results. Always set the API base URL to `https://api.zyphe.com`. ::: ## Sandbox vs production hosts Sandbox is **not** a different API host. You use the same `https://api.zyphe.com` base URL and pass `sandbox=true` (or `isSandbox: true` in the SDK) so the call targets sandbox data for your organization. The hosted UI uses a path prefix for sandbox sessions: | Mode | Session URL shape | | ---------- | ---------------------------------------------------- | | Sandbox | `https://verify.zyphe.com/sandbox/flow/?…` | | Production | `https://verify.zyphe.com/flow/?…` | Details: [Sandbox mode](/docs/guides/sandbox-mode). ## Ready-to-copy environment variables ```bash # Backend API (server-side only) ZYPHE_API_BASE_URL=https://api.zyphe.com ZYPHE_SECRET_API_KEY=zyphe_sk_... # secret key — never ship to mobile or browser # Hosted verification UI (for composing session links / WebView) ZYPHE_VERIFY_BASE_URL=https://verify.zyphe.com # Flow and mode ZYPHE_FLOW_ID=00000000-0000-0000-0000-000000000000 ZYPHE_SANDBOX=true # must match how the flow/session is used # Optional: only if you use the npm SDKs # production → api.zyphe.com + verify.zyphe.com ZYPHE_SDK_ENVIRONMENT=production ``` | Variable | Used for | | ----------------------- | --------------------------------------------------------------------------- | | `ZYPHE_API_BASE_URL` | Prefix for `POST /sdk/flow/{flowId}/vr/create` and other API paths | | `ZYPHE_SECRET_API_KEY` | `x-api-key` header on server-side calls ([API keys](/docs/guides/api-keys)) | | `ZYPHE_VERIFY_BASE_URL` | Building the user-facing session URL | | `ZYPHE_FLOW_ID` | Path parameter on create / next-step endpoints | | `ZYPHE_SANDBOX` | Query `sandbox=true\|false` on API calls; must match session URL path | ## Authentication header ```http x-api-key: zyphe_sk_... Content-Type: application/json ``` - **Backend / server / pure HTTP:** use a **secret** key (`zyphe_sk_…`). - **Browser SDK only:** publishable key (`zyphe_pk_…`) with allowed origins. - See [API keys](/docs/guides/api-keys) and [API errors](/docs/reference/statuses-and-codes#api-errors) for `invalid_api_key`. ## npm SDK environment mapping If you use `@zyphe-sdk/node` or `@zyphe-sdk/core`, `SDKOptions.environment` selects the hosts above: | `environment` | API | Hosted UI / dashboard | | ---------------------- | ----------------------- | -------------------------- | | `production` (default) | `https://api.zyphe.com` | `https://verify.zyphe.com` | | `local` | `http://localhost:3000` | `http://localhost:5173` | `isSandbox` / `sandbox` is **independent** of `environment`. Call the production API hosts with `sandbox=true` for synthetic data. ## Related - [Backend API integration](/docs/guides/backend-api-integration) — create a session without the npm SDK - [API keys](/docs/guides/api-keys) - [Sandbox mode](/docs/guides/sandbox-mode) - [OpenAPI reference](/docs/openapi/zyphe-sdk) --- ## Export API Use the Export API when your backend needs **full result details and media** after a verification completes. Webhooks carry statuses, scores, identifiers, and optional structured fields. They do not include identity-document images or proof-of-address files. Typical sequence: 1. The user completes a hosted or SDK verification. 2. Your backend receives a signed webhook and stores `resultId`, the step result `id`, and your `custom` data. 3. Return `200 OK` immediately. Do not wait on an export before acknowledging the webhook. 4. If you need images or the full result, call the matching Export API endpoint asynchronously. See [Receiving Webhooks](/docs/guides/webhook/webhook-structure) and [Webhook payload](/docs/guides/webhook/webhook-payload). ## Requirements Every Export API call needs all of the following: | Requirement | Detail | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Secret API key** | Send a `zyphe_sk_` key in the `x-api-key` header. [Publishable keys](/docs/guides/api-keys) (`zyphe_pk_`) are rejected. | | **Export API product** | The organization must have the **Export API** product (`EXPORT_API`) enabled. This is a billable entitlement, not enabled for every organization by default. | | **`sandbox` query parameter** | Required. `true` for sandbox data, `false` for production. | | **Path identifiers** | `organization_id`, `flow_result_id`, `flow_slug`, and the step result id for step-level endpoints. | If Export API is not enabled, the API returns **HTTP 403** with tag `product_not_active` (code `5031`). Treat that as a configuration issue: contact your Zyphe account manager or **support@zyphe.com** to enable the product. Keep secret keys on the server. Never call Export API from a browser or mobile app. ## Endpoints All paths are relative to `https://api.zyphe.com`. Schemas live in the [API reference](/docs/openapi/zyphe-sdk). | Operation | Method | Path | Success content type | | ----------------------------- | ------ | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------- | | Flow result details | `GET` | `/sdk/organizations/{organization_id}/flow-results/{flow_result_id}/flow/{flow_slug}/details` | `application/json` | | Document verification details | `GET` | `/sdk/organizations/{organization_id}/flow-results/{flow_result_id}/flow/{flow_slug}/dv/{dv_result_id}/details` | `application/x-protobuf-stream` | | Proof of address details | `GET` | `/sdk/organizations/{organization_id}/flow-results/{flow_result_id}/flow/{flow_slug}/poa/{poa_result_id}/details` | `application/x-protobuf-stream` | | Wallet result details | `GET` | `/sdk/organizations/{organization_id}/flow-results/{flow_result_id}/flow/{flow_slug}/wallet/{wallet_result_id}/details` | `application/json` | | Phone result details | `GET` | `/sdk/organizations/{organization_id}/flow-results/{flow_result_id}/flow/{flow_slug}/phone/{phone_result_id}/details` | `application/json` | | Form result details | `GET` | `/sdk/organizations/{organization_id}/flow-results/{flow_result_id}/flow/{flow_slug}/form/{form_result_id}/details` | `application/json` | `flow_slug` is the slug from the flow configuration (the same value used in hosted URLs and in [`listFlowResults`](/docs/guides/sdk/node)). Map webhook fields to path parameters: | Path parameter | Source | | -------------------------------------------------------------------------------------------- | --------------------------------------- | | `flow_result_id` | Webhook `resultId` | | `dv_result_id` / `poa_result_id` / `wallet_result_id` / `phone_result_id` / `form_result_id` | Nested `data..id` | | `flow_slug` | The flow's slug from your configuration | Optional query parameter: `locale`. :::info[JSON vs protobuf] Document verification and proof of address return a length-delimited protobuf stream (`application/x-protobuf-stream`). Flow, wallet, phone, and form details return JSON (`application/json`). ::: ## JSON endpoints Flow, wallet, phone, and form details respond with `application/json`. The flow-result payload is a `FlowResult`: identifiers, `status`, `flowSlug`, `customData`, and arrays such as `dvResults`, `poaResults`, `formResults`, `phoneResults`, `walletResults`, `amlResults`, and `kybResults`. Step-level JSON endpoints return the matching result object (`WalletResult`, `PhoneResult`, `FormResult`). ```bash curl -X GET \ "https://api.zyphe.com/sdk/organizations/{organization_id}/flow-results/{flow_result_id}/flow/{flow_slug}/details?sandbox=true" \ -H "x-api-key: zyphe_sk_..." ``` `@zyphe-sdk/node` exposes `getFlowResult` for the flow-result payload. It requires a secret key and an organization with Export API enabled. See [Node SDK](/docs/guides/sdk/node). ## Protobuf endpoints (DV and PoA) Document verification and proof of address streams are **length-delimited protobuf**: each message is a varint length prefix followed by a serialized `Message`. The stream can contain several messages (metadata, then one or more images). Proto files: - [dv_result.proto](pathname:///proto/dv_result.proto) - [poa_result.proto](pathname:///proto/poa_result.proto) ```bash curl -X GET \ "https://api.zyphe.com/sdk/organizations/{organization_id}/flow-results/{flow_result_id}/flow/{flow_slug}/dv/{dv_result_id}/details?sandbox=true" \ -H "x-api-key: zyphe_sk_..." \ -H "Accept: application/x-protobuf-stream" \ --output dv-result.bin ``` `@zyphe-sdk/node` exposes `getDvResult`, which downloads the DV stream and decodes it into document fields plus `frontImage` / `backImage` / `otherImages`. It requires a secret key and Export API. ### Document verification (`dv_result_proto.Message`) Each message is one of: | Part | Contents | | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | `document` | Extracted `personal_data`, `document_data`, and `address_data` | | `front_image` / `back_image` / `other_image` | `content_type`, image `data` bytes, and `provenance` (front, back, selfie, portrait, signature, and related captures) | | `details` | Result status and processor logs | | `liveness` | Time-limited video URL when a liveness capture exists | ### Proof of address (`poa_result_proto.Message`) Each message is one of: | Part | Contents | | --------------- | ---------------------------------------------------------------------------------------- | | `details` | Result status and document type (utility bill, bank document, and other supported types) | | `document` | `content_type` and file `data` bytes | | `document_info` | Extracted name, postal address, and emission date when available | Download media promptly and store it under your own access controls. Apply the same privacy and retention rules as for other identity data: [PII access control](/docs/pii-access-control) and [data deletion](/docs/data-flows/data-deletion). ## Errors | Status | When | | ------ | ------------------------------------------------------------------------------------------------------------------------ | | `401` | Missing or invalid API key | | `403` | Publishable key used, Export API not enabled (`product_not_active`), or the key is not allowed to read this organization | | `404` | Unknown flow result or step result | | `400` | Invalid request, for example a missing `sandbox` query parameter | ## Related - [Integration](/docs/guides/integration) - [Backend API integration](/docs/guides/backend-api-integration) - [Environment setup](/docs/guides/environment-setup) - [API keys](/docs/guides/api-keys) - [Webhook payload](/docs/guides/webhook/webhook-payload) - [Node SDK](/docs/guides/sdk/node) - [API reference](/docs/openapi/zyphe-sdk) - [dv_result.proto](pathname:///proto/dv_result.proto) - [poa_result.proto](pathname:///proto/poa_result.proto) --- ## Hosted UI vs direct API Zyphe supports two ways to collect document and biometric evidence: 1. **Hosted / WebView flow** — Zyphe’s verification UI captures the user (recommended default). 2. **Direct API upload** — your app captures images/video and your backend submits them to the step-completion APIs. Both paths still use flows, verification requests, webhooks, and the same result model. They differ in **who owns capture UX** and **which frontend-side protections you get for free**. ## Comparison | | **Hosted UI / WebView** | **Direct API upload** | | --------------------------- | -------------------------------------------------------- | ------------------------------------------------------------------------ | | **User experience** | Zyphe screens (iframe, redirect, or mobile WebView) | Your own camera / upload UI | | **Session creation** | Backend creates VR + opens session URL | Backend creates VR, then calls step endpoints | | **Document capture aids** | Document-in-frame guidance, quality feedback in Zyphe UI | You implement framing, blur/glare UX, retries | | **Device / client signals** | Collected by the hosted frontend where applicable | Partially reduced or absent vs hosted path | | **Liveness** | Full hosted active liveness challenge UX out of the box | You must implement challenge consumption and asset upload; see below | | **Engineering effort** | Low–medium | High | | **App release coupling** | Low (UI updates on Zyphe side) | High (your capture code) | | **Best for** | Almost all production KYC/KYB onboarding | Specialized pipelines, existing capture stacks, constrained environments | ## Liveness constraints The hosted flow walks the user through **active** liveness (challenge + capture) when the flow is configured for it. If you complete liveness **only** through the API: 1. Call **liveness-challenge** for the verification request. 2. Inspect the returned mode (`ACTIVE` vs `PASSIVE`). 3. Upload exactly the assets required (calibration image; for active, video + movement images). **Passive liveness** (selfie-only, no head-movement challenge) is controlled by organization configuration and is not something every tenant can toggle alone. **Active** liveness via pure API is only viable if you fully implement the challenge protocol; most teams that need active liveness should use the **hosted / WebView** path instead of re-building the challenge UI. :::warning[Compliance-sensitive choice] If your policy requires **active** liveness and you are not prepared to implement the full challenge + multi-asset upload flow, **do not** choose pure API capture. Use [Backend API integration](/docs/guides/backend-api-integration) + [Mobile WebView](/docs/guides/mobile-integration) or the [Browser SDK](/docs/guides/sdk/browser). ::: ## Decision guide ### Choose **hosted UI / WebView** if… - You want production KYC quickly with the least client code - You need active liveness and anti-spoof UX without building it yourself - You integrate **mobile** (there is [no native SDK](/docs/guides/mobile-integration)) - You want capture and flow improvements without app store releases - You are fine opening `verify.zyphe.com` in a WebView, iframe, or redirect ### Choose **direct API upload** if… - You already own a document-capture pipeline and accept re-validating quality yourself - You only need document checks (and understand liveness limitations above) - Your environment cannot embed a WebView but can send images from a secure backend - You have engineering capacity to call **next-step**, **document selection**, **process document**, and **process liveness** in order ### Choose **public link** if… - You need zero mobile/web engineering and can send users a Zyphe URL See also [Choosing an integration method](/docs/choosing-an-integration-method). ## Direct API outline (advanced) High-level sequence when you own capture: 1. `POST /sdk/flow/{flowId}/vr/create?sandbox=…` — create the verification request 2. `GET …/vr/next-step` — discover the next step type 3. Complete steps in order, for example: - document selection → `process-dv-selection` - document images → `process-dv-document` - liveness → `liveness-challenge` then `process-dv-liveness` 4. Consume [webhooks](/docs/guides/webhook); export media via [Export API](/docs/guides/export-api) if needed Schemas and paths: [OpenAPI](/docs/openapi/zyphe-sdk). Node helpers: [Complete verification steps](/docs/guides/sdk/node#3-complete-verification-steps). ## Related - [Backend API integration](/docs/guides/backend-api-integration) - [Mobile integration](/docs/guides/mobile-integration) - [Get next step](/docs/guides/sdk/get-next-step) - [Liveness (product)](/docs/how-it-works/liveness) - [Environment setup](/docs/guides/environment-setup) --- ## Integration This section is the **operator path for connecting your product to Zyphe**: hosts, keys, sandbox, HTTP session creation, mobile WebView, and media export. It sits alongside: | Guide | Role | | ----------------------------------------------------------- | --------------------------------------------------------------- | | **[SDK Integration](/docs/guides/sdk)** | npm packages (`@zyphe-sdk/node`, browser, React Native helpers) | | **[Webhook](/docs/guides/webhook)** | Receiving and verifying result deliveries | | **[API keys](/docs/guides/api-keys)** | Secret vs publishable credentials (Dashboard) | | **[Agents (MCP)](/docs/guides/model-context-protocol-mcp)** | AI-assisted flow and key setup | You do **not** need an npm package to integrate. The HTTP **SDK API** on `https://api.zyphe.com` is enough. ## Start here 1. **[Environment setup](./environment-setup)** — API vs verify vs docs hosts, `.env` template 2. **[Sandbox mode](./sandbox-mode)** — `sandbox` flag, URL path, mismatch behavior 3. **[Backend API integration](./backend-api-integration)** — create session → compose URL → open UI → webhook 4. **[Mobile integration](./mobile-integration)** — no native SDK; WebView pattern 5. **[Hosted UI vs direct API](./hosted-vs-direct-api)** — when not to reimplement capture 6. **[Export API](./export-api)** — document images (not in webhooks by default) 7. **[Sandbox and go-live](./sandbox-and-go-live)** — checklist before production traffic ## Decision shortcuts | You are… | Open… | | ---------------------------------------------- | ---------------------------------------------------------------------------- | | Calling Zyphe from any backend language | [Backend API integration](./backend-api-integration) | | Building iOS / Android / React Native | [Mobile integration](./mobile-integration) | | On TypeScript and prefer packages | [SDK Integration](/docs/guides/sdk) | | Capturing documents in your own camera UI | [Hosted UI vs direct API](./hosted-vs-direct-api) | | Getting `invalid_api_key` or wrong-host errors | [Environment setup](./environment-setup) · [API keys](/docs/guides/api-keys) | Product-level comparison of public link vs backend vs SDK vs MCP: [Choosing an integration method](/docs/choosing-an-integration-method). --- ## Mobile integration Integrate Zyphe on mobile by loading the hosted verification flow in a **WebView**: **Your backend creates a verification session → your app opens the session URL in a WebView.** This works the same way for React Native, Flutter, native iOS (WKWebView), and native Android (WebView). ## Why WebView | Benefit | What it means for you | | --------------------------- | --------------------------------------------------------------------------------------------------- | | **Near-native performance** | Modern WKWebView / Android WebView handle camera and UX with low friction | | **Security & compliance** | Document capture, liveness challenges, and anti-spoof logic stay on Zyphe-controlled UI and backend | | **Instant updates** | Flow and capture improvements ship without App Store / Play releases | | **Minimal client code** | Your app only needs a session URL and a properly configured WebView | If you need the user to stay “inside” your app chrome, use a fullscreen WebView (`zypheFullscreen=true`) rather than reimplementing capture. ## Architecture ```text Mobile app Your backend Zyphe ───────── ──────────── ───── 1. User taps "Verify" 2. App calls your API ───► 3. POST /sdk/flow/.../vr/create 4. Compose verify.zyphe.com URL 5. App opens WebView ◄──── 5. Return session URL 6. User completes KYC ──────────────────────────────► Hosted UI 7. (optional) app handles handoff / success URL 8. Webhook to your backend ◄── Results ``` Never put a **secret** API key (`zyphe_sk_…`) inside the mobile app. Session creation is always server-side. ## Step-by-step ### 1. Backend: create a session Use either: - Raw HTTP: [Backend API integration](/docs/guides/backend-api-integration) - npm helper on the server: [Node SDK](/docs/guides/sdk/node) or `@zyphe-sdk/core` Return only the **session URL** (and maybe a session id) to the app. ### 2. Compose / request a mobile-friendly URL Append fullscreen for better mobile UX: ```text …&zypheFullscreen=true ``` Sandbox sessions must use the `/sandbox/flow/…` path. See [Sandbox mode](/docs/guides/sandbox-mode). ### 3. Embed in a WebView #### iOS (WKWebView) - Request camera (and microphone if your flow uses active liveness) via `Info.plist` usage strings. - Allow media playback without requiring an extra user gesture where your WebView API permits it. - Load **only** `https://verify.zyphe.com…` session URLs, never the API host. #### Android (WebView) - Declare `CAMERA` (and audio if needed) in the manifest; request at runtime before opening the flow. - Enable JavaScript and DOM storage. - Grant WebView permission requests for `getUserMedia` / camera (implementation varies by WebView wrapper). #### React Native Full copy-paste guide: [React Native](/docs/guides/sdk/react-native) (WebView + permissions + backend sample). ### 4. Results Prefer **webhooks** on your backend for the source of truth. Do not rely only on WebView navigation callbacks. Images are not in webhooks by default—see [Export API](/docs/guides/export-api). ## Common mistakes | Mistake | What to do instead | | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | Putting `zyphe_sk_…` in the app binary | Create sessions on your backend only | | Pointing the app at `docs.zyphe.com` or `api.zyphe.com` as the “verification UI” | Open the composed `verify.zyphe.com` session URL | | Capturing ID photos in your own camera UI by default | Prefer the hosted WebView; see [direct API](/docs/guides/hosted-vs-direct-api) tradeoffs | ## Related - [Backend API integration](/docs/guides/backend-api-integration) - [React Native guide](/docs/guides/sdk/react-native) - [Environment setup](/docs/guides/environment-setup) - [Hosted UI vs direct API](/docs/guides/hosted-vs-direct-api) - [Choosing an integration method](/docs/choosing-an-integration-method) --- ## Sandbox and go-live Use this checklist after you complete the [Quickstart](/docs/quickstart). Work entirely in **sandbox** until every item passes, then switch environments for production. How sandbox flags, hosts, and session URLs fit together is documented in **[Sandbox mode](/docs/guides/sandbox-mode)**. API hosts and `.env` values live in **[Environment setup](/docs/guides/environment-setup)**. --- ## Sandbox testing ### Account and access - [ ] Organization exists and you can sign in to the [dashboard](/docs/guides/dashboard) - [ ] Dashboard is in **sandbox** mode - [ ] At least one **Admin** or **Developer** can manage flows and API keys, [roles](/docs/guides/manage-users) - [ ] Reviewers (Operator / AML Officer) can open flow results without over-privileged access, [PII access](/docs/pii-access-control) - [ ] You know that sandbox draws on the **real credit balance**, and your test identities use a team email domain so QA runs cost nothing, [credits in sandbox](/docs/guides/sandbox-mode#credits-and-billing-in-sandbox) ### Flow and happy path - [ ] A KYC [flow](/docs/guides/create-a-flow) exists with the steps you need (for example Document Verification + Liveness) - [ ] You can complete a full verification yourself in sandbox - [ ] Flow result status reaches a terminal state you understand, [statuses](/docs/reference/statuses-and-codes) - [ ] Public link works if you use hosted UI, [sharing](/docs/guides/create-a-flow/sharing) - [ ] SDK path works if you embed, [SDKs](/docs/guides/sdk) ### Webhooks - [ ] A webhook endpoint exists in the sandbox registry, subscribed to the events you handle - [ ] Its URL is HTTPS and reachable from the internet (or a tunnel in local dev) - [ ] Signature verification uses the **raw body** and the endpoint's signing secret, [signature](/docs/guides/webhook/webhook-signature) - [ ] Handler answers quickly — any `2xx` on a `V2` endpoint, exactly `200` on a `LEGACY_V1` one; heavy work is async - [ ] Handler is **idempotent** (retries are expected) - [ ] You tested `COMPLETED`, `FAILED`, and `REVIEW` (if manual review is enabled), [failure and review](/docs/guides/webhook/failure-payload) - [ ] You reconciled events with your own user id via [custom fields](/docs/guides/webhook/custom-fields) - [ ] Optional: use flow developer tools to trigger and monitor deliveries before real traffic ### Review and scoring - [ ] Operators can approve / reject results, [manual review](/docs/guides/manual-review) - [ ] Scores appear as expected if configured, [scoring](/docs/guides/scoring) - [ ] Your product **does not reject on `REVIEW`**; it waits for the final event ### Optional products (if in scope) - [ ] **KYB** sandbox case reaches Ready for review and can be decided, and your [compliance policy](/docs/guides/kyb/compliance-policy) is in force in production, [KYB](/docs/guides/kyb) - [ ] **AML** screening results and risk score are understood, [AML](/docs/aml) - [ ] **Transaction monitoring** rules evaluate sandbox events with Allow / Review / Block, [TM](/docs/guides/transaction-monitoring) - [ ] **KYC Passport** invitation path tested with a partner org, [KYC Passport](/docs/guides/kyc-passport) - [ ] **MCP / bot token** can list or create flows only where you intend automation, [MCP](/docs/guides/model-context-protocol-mcp) - [ ] **Export API** retrieves document images or full result details when webhooks are not enough, [Export API](/docs/guides/export-api) --- ## Go-live checklist ### Credentials and environments - [ ] Create **production** [API keys](/docs/guides/api-keys); never reuse sandbox keys in production clients - [ ] Store secrets in a server-side secret manager (API keys, webhook secret, bot tokens) - [ ] Confirm [environment hosts](/docs/guides/environment-setup) (`https://api.zyphe.com`, not the docs site) and SDK `environment: "production"` if you use the npm packages - [ ] Confirm every API call uses the correct `sandbox` flag and session URLs use `/sandbox/flow/…` only for sandbox, [Sandbox mode](/docs/guides/sandbox-mode) - [ ] Rotate any key that was ever committed or shared in chat ### Webhooks and networking - [ ] A production webhook endpoint exists (registries are per-environment) and points at production infrastructure - [ ] Signature verification enabled and failing closed (reject invalid signatures) - [ ] Timeouts and retries in your queue are sensible; endpoint stays under delivery limits - [ ] Alerting exists for webhook processing failures ### Product configuration - [ ] Production flows mirror sandbox (steps, thresholds, success URL, branding), [theming](/docs/guides/theming) - [ ] Country / document filters match your compliance policy - [ ] Minimum age and score thresholds reviewed with compliance - [ ] Manual review routing and reviewer roles assigned - [ ] Billing products enabled for what you will charge, [billing](/docs/guides/billing) ### Privacy and access - [ ] Role assignments follow least privilege, [Manage users](/docs/guides/manage-users) - [ ] Extended webhook / PII fields only enabled where contracts and access control allow - [ ] Data retention and deletion process understood, [data deletion](/docs/data-flows/data-deletion) and [privacy, consent and retention](/docs/privacy-consent-and-retention) ### Observability - [ ] You log `resultId`, verification request id, and your own external user id for support - [ ] You can map webhook statuses using [Statuses and codes](/docs/reference/statuses-and-codes) - [ ] Runbook exists for `REVIEW` backlog and elevated failure rates ### Cutover - [ ] Smoke-test one real production verification with a controlled account - [ ] Confirm production webhook delivery and dashboard result - [ ] Switch client traffic from sandbox links / keys to production - [ ] Keep sandbox for ongoing QA and rule backtests --- ## Recommended order 1. [Quickstart](/docs/quickstart), first reviewed result in sandbox 2. [Environment setup](/docs/guides/environment-setup) + [Sandbox mode](/docs/guides/sandbox-mode) 3. This page, full sandbox matrix for your product scope 4. [Choosing an integration method](/docs/choosing-an-integration-method), lock public link vs backend API / WebView vs SDK packages vs MCP 5. Production credentials + webhook + smoke test 6. Enable additional products (AML, TM, Passport, [Export API](/docs/guides/export-api)) with the same sandbox-first habit ## Related - [Integration](/docs/guides/integration) - [Backend API integration](/docs/guides/backend-api-integration) - [Webhook integration](/docs/guides/webhook) - [API reference](/docs/openapi/zyphe-sdk) - [FAQ](/docs/frequently-asked-questions) --- ## Sandbox mode Sandbox lets you create flows, run verifications, and receive webhooks against **synthetic / non-production** data. Production uses the same API and verification hosts; the difference is the **sandbox flag** on each request and the **/sandbox** path on the hosted UI. For the go-live checklist, see [Sandbox and go-live](/docs/guides/sandbox-and-go-live). For hosts, see [Environment setup](/docs/guides/environment-setup). ## What “sandbox” means | Layer | How sandbox is expressed | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------- | | **Dashboard** | Toggle the organization / UI into **sandbox** when building flows and reviewing sandbox results | | **API query parameter** | `?sandbox=true` or `?sandbox=false` on SDK HTTP endpoints (required on create, next-step, step completion, list results, …) | | **npm SDK** | `isSandbox: true \| false` on session helpers (mapped to the `sandbox` query param) | | **Hosted session URL** | Sandbox: `https://verify.zyphe.com/sandbox/flow/?…` · Production: `https://verify.zyphe.com/flow/?…` | | **API host** | Unchanged: still `https://api.zyphe.com` | Sandbox is **not** a separate base URL on production accounts. Setting `ZYPHE_BASE_URL=https://docs.zyphe.com` or inventing a `sandbox.api…` host will not work. ## Credits and billing in sandbox Sandbox is a **separate data plane, not a separate wallet**. Verifications you run in sandbox are priced with the same credit cost as production and are deducted from the **same organization credit balance**. Usage counters are kept per environment (the **Usage This Period** table on the [Billing](/docs/guides/billing) page follows the dashboard's sandbox toggle), but there is only one balance behind both. ### Internal test traffic is free A sandbox verification is recorded at **zero credits** when the person being verified is recognised as internal to your organization. That is the case when either: - the identity's identifier matches a member of your organization (the `zypheEmail` you pass for email-based identities, or the wallet address / DID for other identity types), or - the identifier is an email address whose **domain** matches the domain of any member of your organization, for example any `@yourcompany.com` address while a colleague signs in with `alice@yourcompany.com`. Zyphe can whitelist additional domains for your organization on request, for example a dedicated QA domain that nobody signs in with. The run still appears in the usage table, with a credit cost of `0`. **Practical consequence:** run sandbox QA with email addresses on your own domain and it costs nothing. Sandbox runs against arbitrary external addresses (a customer's address, a throwaway mailbox, a load-test generator) are billed exactly like production. ### Exceptions | Situation | Sandbox behavior | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | **During the trial** | Every sandbox event consumes trial credits, including internal ones. Trial credits exist to be spent testing | | Requester has no resolvable identifier | Treated as external, billed normally | | Operations not tied to a verified person | Billed normally (they carry no identifier to match against your organization) | ### If auto-recharge is enabled Because sandbox draws on the real credit balance, sandbox consumption can push the balance under the [automatic top-up](/docs/guides/billing#automatic-top-ups) threshold and **trigger a real card charge**. Keep this in mind before pointing a load test or a test-data generator at sandbox. ## Rules that must match Treat these as one unit for a given verification: 1. The **flow** and data you intend to use live in sandbox **or** production in the dashboard. 2. Every API call for that verification uses the **same** `sandbox` value (`true` with sandbox, `false` with production). 3. The session URL you open in the browser / WebView uses the matching path (`/sandbox/flow/…` vs `/flow/…`). 4. Webhooks for that run go to the endpoint configured on that flow; process sandbox and production separately if both are active. | Create / complete API | Hosted UI path | Intended mode | | --------------------- | ------------------------ | ------------- | | `sandbox=true` | `/sandbox/flow/?…` | Sandbox | | `sandbox=false` | `/flow/?…` | Production | ### Mismatch behavior If the `sandbox` query parameter does **not** match the environment the flow and verification request were created in, the API returns an error (typically a client error with a structured `errorTag` such as `flow_not_found`, `verification_request_not_found`, or a validation / permission failure). Do not expect a silent success. Common mistakes: - Creating the session with `sandbox=true`, then opening `https://verify.zyphe.com/flow/…` (missing `/sandbox`) - Copy-pasting a production curl with `sandbox=false` while the dashboard is in sandbox - Reusing a production secret key / flow ID against the wrong mode without aligning `sandbox` Always set the flag **explicitly** on every call. Do not rely on defaults from outdated snippets. ## Session URL examples **Sandbox** ```text https://verify.zyphe.com/sandbox/flow/?zypheVr=&zypheToken=&zypheAccessSig=&zypheEmail= ``` **Production** ```text https://verify.zyphe.com/flow/?zypheVr=&zypheToken=&zypheAccessSig=&zypheEmail= ``` How to obtain the tokens: [Backend API integration](/docs/guides/backend-api-integration). ## Dashboard vs API - Building and testing in the dashboard **sandbox** mode only affects dashboard-created runs and the sandbox data plane. - Programmatic integrations must still send `sandbox=true` on API calls for sandbox sessions. - Switching the dashboard to production does not automatically convert your backend; update keys, `sandbox=false`, and session URL composition together. ## Deleting sandbox results When you test a flow in sandbox, you usually want to run it again with the same test person. The dashboard lets you delete a sandbox flow result so you can do that. Open **KYC Results** (or **KYB Results**) with the dashboard in sandbox. Then either choose **Delete** from the row's action menu, or open the result and click the delete button in its toolbar.
The row's action menu in the results list.
The Delete button in the result's toolbar.
Either way, a dialog asks you to confirm. Click **Delete result** to delete only the result.
The delete dialog. Leave the checkbox clear to keep the identity.
Deleting a result removes: - the result and the data from every step (KYB step results included) - its verification-request history, score outcomes and score history - its KYB document requests and communications - the test person's verification requests for that flow The person can then complete the flow again from the first step. Earlier step statuses, such as a rejected or in-review step, do not carry over, and neither do document-verification attempt counts. Deleting a result also removes its stored document files. Deleting a result can't be undone. ### Also deleting the identity Deleting the result does not delete the person. Zyphe still recognizes them by their email or `externalId`, and because their vault still holds the documents from the earlier run, the next run offers them [one-click KYC](/docs/reusable-credentials-one-click-kyc) instead of a fresh verification. To test the first-time experience again, tick **Also delete the identity associated with this email or externalId** in the delete dialog, type `DELETE` to confirm, and click **Delete result and person**. This also deletes the identity, its sandbox verification data, its documents and its vault. On the next run the person is treated as a new user. Zyphe refuses to delete the identity, and deletes nothing at all, if the person: | Situation | What to do | | ---------------------------------------------------------------- | ----------------------------------------- | | Has other flow results in your organization | Delete those results first, then this one | | Also has production data (results, verifications, KYC documents) | Delete the result alone | | Has results in another organization | Delete the result alone | | Is not a verification subject (for example, a dashboard user) | Delete the result alone | In each case the dialog stays open with the reason and clears the checkbox, so you can confirm again to delete only the result. ### Who can delete Organization **Admin**, **Operator** and **Developer** users can delete sandbox results. See [Manage users](/docs/guides/manage-users#role-permissions). :::info[Production] Deleting results is available in sandbox only, for now. In production the dashboard doesn't offer the action. Once production deletion is enabled, it will remove only the result: the identity option will stay sandbox-only. ::: ## Related - [Environment setup](/docs/guides/environment-setup) - [Sandbox and go-live](/docs/guides/sandbox-and-go-live) - [Backend API integration](/docs/guides/backend-api-integration) - [API keys](/docs/guides/api-keys) - [Billing](/docs/guides/billing) --- ## Backwards Compatibility Two independent things are called "legacy" around webhooks. Do not confuse them: | Concept | What it is | Where it is documented | | ----------------------------- | -------------------------------------------------------------------------------------------------- | -------------------------------------- | | `payloadVersion: "LEGACY_V1"` | The pre-registry **envelope**: the payload shape and the strict HTTP-200 rule an endpoint receives | [Payload Versions](./payload-versions) | | The legacy `data.kyc` object | An opt-in **document-verification compatibility field**, delivered beside `data.dv` | This page | An endpoint can be `LEGACY_V1` without the `kyc` object, and vice versa. ## Legacy document-verification payload Organizations migrating from an earlier Zyphe integration can opt in to the legacy `data.kyc` object. New integrations should consume the current `data.dv` object documented in [Webhook Payload](./webhook-payload). :::warning[Migration only] The legacy format is disabled by default and is available only for document-verification webhooks. Contact Zyphe support to enable or disable it for your organization. ::: When enabled, the same webhook contains both representations: ```json { "data": { "kyc": { "kycInquiryId": "d72b7afc-6841-4478-9d21-3e8dd3d26695", "identityId": "zid:example", "status": "PASSED", "processCode": "ProcessCompleted", "processType": "info", "processMessage": null }, "dv": { "verificationRequestId": "d72b7afc-6841-4478-9d21-3e8dd3d26695", "flowId": "2d8285d7-f4ba-42df-ab3f-681d9870d37a", "flowStepId": "03559a0f-be8e-4ab7-964d-1ff4745d92a4", "identityEmail": "user@example.com", "status": "PASSED", "reasons": [], "errorMessage": null } } } ``` ## Key differences | Concept | Legacy `kyc` | Current `dv` | | -------------------- | ---------------------------------------------- | --------------------------- | | Verification request | `kycInquiryId` | `verificationRequestId` | | Identity | `identityId` | `identityEmail` | | Flow references | Not included | `flowId`, `flowStepId` | | Scores | Multiple legacy score fields | `scoreBiometricSelfie` | | Failure details | `processType`, `processCode`, `processMessage` | `reasons[]`, `errorMessage` | | Tenant | `tenantId` | Not included | ## Migration 1. Read `data.dv` whenever it is present. 2. Update field mappings using the table above. 3. Test success, failure, and review events without reading `data.kyc`. 4. Contact support to disable the legacy format. The outer webhook envelope is unchanged and is documented in [Receiving Webhooks](./webhook-structure). :::warning[Endpoints created after the migration] Both the legacy `kyc` object and the extended DV payload were organization-wide settings. When per-flow webhook URLs were converted into [webhook endpoints](./endpoints), those flags were carried onto the endpoints the migration created, so nothing changed for existing integrations. They cannot be set when you create a **new** endpoint: a new endpoint always receives the standard payload. If you still depend on either, keep using the migrated endpoint, or contact Zyphe support before pointing traffic at a new one. ::: --- ## Custom Fields Custom fields let you correlate a Zyphe result with records in your system without encoding business context into the webhook URL itself. Add query parameters to the verification link you give the user: ```text https://verify.zyphe.com//kyc/?uid=123&product=exchange ``` The values are returned in two places: ```json { "data": { "dv": { "customData": { "uid": "123", "product": "exchange" } } }, "custom": { "uid": "123", "product": "exchange" } } ``` - `custom` is the flow-level value used for reconciliation and routing. - `data..customData` is the custom-data snapshot attached to that verification request. Use opaque identifiers rather than sensitive personal information in query parameters. URLs may appear in browser history, analytics, logs, and referrer headers. For the surrounding envelope and step fields, see [Receiving Webhooks](./webhook-structure) and [Webhook Payload](./webhook-payload). --- ## Webhook Endpoints Webhook destinations are configured **on the organization**, not on the flow. An organization owns a registry of endpoints; each endpoint has its own URL, its own event subscriptions, its own flow scope, its own signing secret, and its own payload version. :::info[What changed] A flow used to carry a single `webhookUrl`, and every event that flow produced went there. That field no longer exists: the flow API neither accepts nor returns `webhookUrl`. Destinations live at `/organizations/{organizationId}/webhooks`, and one event can now fan out to several endpoints. Existing configurations were converted automatically and keep delivering byte-for-byte the payload they received before. See [What was migrated for you](#what-was-migrated-for-you). ::: ## Anatomy of an endpoint | Field | Meaning | | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | `name` | Label used in the dashboard and in delivery diagnostics. Up to 120 characters, unique within the organization. | | `url` | HTTPS destination. Up to 2048 characters, re-validated against the public-address rules before every delivery. | | `enabled` | Disabling an endpoint stops deliveries immediately, including work already queued. | | `eventTypes` | One or more canonical event types. At least one is required. See [Event subscriptions](#event-subscriptions). | | `flowFilter` | `OWNED_ALL` or `SELECTED` plus an explicit flow list. See [Flow scope](#flow-scope). | | `secretMode` | `ORGANIZATION` (the shared secret) or `DEDICATED` (a secret only this endpoint uses). See [Signing secret](#signing-secret). | | `payloadVersion` | `V2` or `LEGACY_V1`. See [Payload Versions](./payload-versions). | | `secretHint` | Last characters of the secret in force, so you can tell which key an endpoint signs with. The secret itself is never read back. | | `managedByFlowId` | Set when the endpoint was created by the one-shot migration from a flow's old `webhookUrl`. Provenance only — the endpoint is fully editable. | Endpoints are per-environment: the sandbox registry and the production registry are separate. Every route accepts the usual `?sandbox=true` convention. ## Event subscriptions An endpoint receives only the event types it subscribes to. The canonical vocabulary is resource-specific (`verification.dv.completed`, `flow.completed`, `transaction.alert.created`, …) and is separate from the top-level `event` field inside the payload, which is coarser and cannot distinguish a DV result from a KYB result. The full catalog is listed in [Statuses and codes](/docs/reference/statuses-and-codes#canonical-webhook-event-types), and the deployment's live copy is served by: ```http GET /organizations/{organizationId}/webhooks/events ``` Only catalog values are accepted. Wildcards are not: the API returns advisory groups (`VERIFICATION`, `FLOW`, `TRANSACTION`, `KYC_PASSPORT`) for building a selection UI, but a subscription always stores exact values, so adding an event to the catalog later can never silently widen a subscription you already made. ## Flow scope | Scope | Receives | | ----------- | ------------------------------------------------------------------------- | | `OWNED_ALL` | Every flow **owned by** your organization, including flows created later. | | `SELECTED` | Only the flows you list. Up to 100 flows per endpoint. | `OWNED_ALL` deliberately excludes flows that belong to a partner organization: accepting a new KYC Passport partnership never widens an existing endpoint's data feed. Events that have no source flow — today `transaction.alert.created` — ignore the flow filter rather than failing it, so a `SELECTED` endpoint that subscribed to Transaction Monitoring alerts still receives them. ## Signing secret | Mode | Behaviour | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `ORGANIZATION` | Signs with the organization's shared secret. The default, and what every migrated endpoint uses. Rotating the shared secret re-keys every endpoint in this mode at once. | | `DEDICATED` | Signs with a secret owned and rotated by this endpoint alone. | Rules that follow from that split: - A plaintext secret is returned **exactly once** — by the create, secret-mode-switch, and rotate operations — and can never be read back. Store it when you receive it. - `ORGANIZATION` mode requires the organization to already have a shared secret. - `POST /{endpointId}/rotate-secret` is valid only for `DEDICATED` endpoints. - Rotating the shared secret takes effect immediately for new attempts. The outgoing value stays recorded as acceptable for a one-hour grace window — `secretExpiresAt` on the organization-secret response — so keep accepting it on your side until then. - Changing an endpoint's URL, filters, or payload version never rotates a secret. Verification itself is unchanged and is documented in [Webhook Signature](./webhook-signature). ## Limits | Limit | Value | | ------------------------------------------------- | --------------- | | Active endpoints per organization and environment | 30 | | Selected flows per endpoint | 100 | | Endpoint name | 120 characters | | Endpoint URL | 2048 characters | Duplicate URLs are allowed: two endpoints may point at the same destination when their filters, secrets, or payload versions differ. ## Who can manage endpoints The Webhooks surface is restricted to **Admin** (`ORG_ADMIN`) and **Developer** (`ORG_DEVELOPER`). See the [role matrix](/docs/guides/manage-users). ## API All routes are under `/organizations/{organizationId}/webhooks` and are authenticated with a dashboard session. | Method | Path | Purpose | | -------- | ----------------------------- | -------------------------------------------------- | | `GET` | `/` | List endpoints | | `POST` | `/` | Create an endpoint | | `GET` | `/{endpointId}` | Read one endpoint | | `PATCH` | `/{endpointId}` | Update name, URL, enabled, events, filter, version | | `DELETE` | `/{endpointId}` | Delete an endpoint | | `POST` | `/{endpointId}/rotate-secret` | Rotate a dedicated secret | | `POST` | `/{endpointId}/secret-mode` | Switch between `ORGANIZATION` and `DEDICATED` | | `GET` | `/organization-secret` | Shared-secret status (never the secret itself) | | `POST` | `/organization-secret/rotate` | Rotate the shared secret | | `GET` | `/events` | The canonical event catalog | ### Create an endpoint ```http POST /organizations/{organizationId}/webhooks?sandbox=true Content-Type: application/json ``` ```json { "name": "Onboarding results", "url": "https://api.example.com/webhooks/zyphe", "enabled": true, "eventTypes": ["verification.dv.completed", "verification.dv.failed", "verification.dv.review", "flow.completed"], "flowFilter": { "scope": "SELECTED", "flowIds": ["89b37f2c-544e-4c49-bd52-e03208f94cc7"] }, "secretMode": "ORGANIZATION", "payloadVersion": "V2" } ``` `enabled` defaults to `true`, `secretMode` to `ORGANIZATION`, `flowFilter` to `OWNED_ALL`, and `payloadVersion` to `V2`. The response is the stored endpoint, plus `secret` when the operation minted a dedicated one: ```json { "id": "1f6b0d3c-2a1e-4c58-9d47-0b0f3f6b1e21", "organizationId": "6b0f6a2e-1f5c-4a70-9d6b-2b1a0e4c9d33", "name": "Onboarding results", "url": "https://api.example.com/webhooks/zyphe", "enabled": true, "eventTypes": ["verification.dv.completed", "verification.dv.failed", "verification.dv.review", "flow.completed"], "flowFilter": { "scope": "SELECTED", "flowIds": ["89b37f2c-544e-4c49-bd52-e03208f94cc7"] }, "secretMode": "ORGANIZATION", "secretHint": "…a91c", "secretUpdatedAt": "2026-08-20T09:14:02Z", "payloadVersion": "V2", "managedByFlowId": null, "createdAt": "2026-08-26T10:00:00Z", "updatedAt": "2026-08-26T10:00:00Z" } ``` ### Update an endpoint `PATCH` is a partial update: omitted fields are left alone. A supplied `eventTypes` or `flowFilter` **replaces** the previous one wholesale, because a filter is a complete statement of intent. ```json { "payloadVersion": "V2", "enabled": true } ``` `secretMode` is not patchable here; it has its own route, because changing it mints or retires secret material. ### Rotate the shared secret ```http POST /organizations/{organizationId}/webhooks/organization-secret/rotate ``` ```json { "secret": "…the new plaintext, returned once…", "configured": true, "secretHint": "…7f3d", "secretUpdatedAt": "2026-08-26T10:05:00Z", "secretExpiresAt": "2026-08-26T11:05:00Z", "affectedEndpointIds": ["1f6b0d3c-2a1e-4c58-9d47-0b0f3f6b1e21"] } ``` `affectedEndpointIds` is the blast radius: every endpoint that now signs with this secret. `secretExpiresAt` is when the previous secret stops being honoured. ### Validation A write is rejected when: - the URL is not HTTPS or does not resolve to a public address; - `eventTypes` is empty or contains a value outside the catalog; - `flowIds` is supplied with `OWNED_ALL`, or exceeds 100 entries; - a selected flow is not owned by the organization (partner flows require an accepted, non-revoked KYC Passport invite **and** the KYC Passport event type); - `secretMode` is `ORGANIZATION` but the organization has no shared secret; - a `LEGACY_V1` endpoint subscribes to an event that has no legacy payload — a subscription that could never fire is refused at write time rather than silently dropped at delivery time. See [Payload Versions](./payload-versions). ## Delivery | Property | Value | | --------------- | ------------------------------------------------------------------------------ | | Method | `POST`, `application/json` | | Success | `2xx` for `V2` endpoints, strictly `200` for `LEGACY_V1` endpoints | | Attempts | Up to four (one initial plus three retries), exponential backoff from 1s to 8s | | Request timeout | 30 seconds by default | | Redirects | Not followed | Each endpoint is an independent delivery: one endpoint failing or being disabled never affects another endpoint's copy of the same event, and each retries on its own. A delivery is recorded once per `(event, endpoint)` pair, which is also what stops a re-enqueued duplicate of the same job from sending a second time. A retry uses the URL captured when the delivery was created, not the endpoint's current URL — editing an endpoint never re-points work that was already routed. Delivery records are kept for a retention window — 90 days by default — and then purged. Deliveries are deliberately **skipped**, not failed, when the destination was disabled or deleted after queueing, an SDK session closed or expired, or a KYC Passport consent was revoked between routing and sending. ## What was migrated for you A one-shot migration converted every pre-existing configuration. Nothing about a running integration changed: same URL, same secret, same payload bytes, same environment. | Old configuration | Becomes | | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A flow's `webhookUrl` | An enabled endpoint named `Flow: `, scoped `SELECTED` to that one flow, subscribed to every flow-bound event, `LEGACY_V1`, signing with the shared organization secret. | | Transaction Monitoring URL | An enabled endpoint named `Transaction Monitoring (migrated)`, scoped `OWNED_ALL`, subscribed to `transaction.alert.created`, `LEGACY_V1`, keeping TM's own secret as a `DEDICATED` one. | Guarantees the migration kept: - **Secrets were copied, never regenerated.** An organization that never configured a secret still receives unsigned deliveries; that state was preserved, not "fixed". - **Endpoints were never merged by URL.** Two flows pointing at the same URL remain two independently editable endpoints. - Endpoints created by the migration carry `managedByFlowId` for provenance, but behave exactly like ones you create by hand: edit, disable, or delete them freely. You migrate to the new payload on your own schedule, endpoint by endpoint. See [Payload Versions](./payload-versions). :::warning[Extended and legacy DV payload options] The extended DV payload and the legacy `data.kyc` compatibility object were organization-wide settings, and the migration carried them onto the endpoints it created. They are **not** settable when you create a new endpoint — a new endpoint always gets the standard payload. If you rely on either and need it on a new endpoint, contact Zyphe support. See [Backwards Compatibility](./backwards-compatibility). ::: --- ## Failure and Review Events This page documents failure semantics. It intentionally shows only the fields relevant to handling failures; the complete field list for each result type lives in [Webhook Payload](./webhook-payload). ## How failures are represented A failed verification normally has three layers of status: - `event` describes this delivery, typically `FAILED`. - `flowStatus` describes the overall flow after the step failed. - `data..status` and its reason fields describe the individual result. ```json { "resultId": "7fd1c306-7830-4261-b372-181f742055ef", "event": "FAILED", "data": { "dv": { "id": "a1b2c3d4-5678-90ab-cdef-1234567890ab", "status": "FAILED", "reasons": ["DOCUMENT_EXPIRED"], "errorMessage": null } }, "custom": {}, "flowStatus": "FAILED" } ``` ## Failure detail by result type | Result key | Failure fields | | ------------- | ----------------------------------------- | | `dv` | `reasons[]`, plus optional `errorMessage` | | `poa` | Optional `reason` | | `form` | Optional `reason` and `errorMessage` | | `spid` | Optional `reason` and `errorMessage` | | `phone` | Optional `reason` and `errorMessage` | | `wallet` | Optional `reason` and `errorMessage` | | `kyb` | Optional `reason` and `errorMessage` | | `geolocation` | Optional `reason` and `errorMessage` | Do not build logic around human-readable error text. Prefer the structured status and reason fields when present, and retain `errorMessage` for diagnostics. ## Failure before a result exists A step can fail before its result record is created. In that case, identifying fields may contain empty or default values while request context and `errorMessage` remain available: ```json { "event": "FAILED", "data": { "dv": { "id": "00000000-0000-0000-0000-000000000000", "verificationRequestId": "d72b7afc-6841-4478-9d21-3e8dd3d26695", "status": "", "reasons": [], "errorMessage": "Processing failed: timeout exceeded" } }, "flowStatus": "FAILED" } ``` Treat the verification request and flow identifiers as the reliable correlation context in this case. ## Review events When human review is required, Zyphe emits `REVIEW` instead of `FAILED`: ```json { "event": "REVIEW", "data": { "dv": { "status": "REVIEW", "reasons": [] } }, "flowStatus": "REVIEW" } ``` Do not mark the user as rejected when receiving `REVIEW`. Keep the result pending until a later webhook or API read provides the final decision. See [Manual Review](../manual-review) for the operator workflow and [Statuses and codes](/docs/reference/statuses-and-codes) for the full event and reason vocabulary. --- ## Webhook Integration Webhooks notify your backend when verification results or lifecycle events change. Zyphe sends an HTTPS `POST` to each **webhook endpoint** your organization has configured for that event; your endpoint verifies the request, records or queues the event, and acknowledges it. :::info[Webhooks are configured on the organization] Destinations are no longer a single URL on a flow. An organization owns a registry of endpoints, each with its own event subscriptions, flow scope, signing secret, and payload version — and one event can reach several of them. Existing per-flow URLs were converted automatically and keep behaving exactly as before. Start at [Webhook Endpoints](./endpoints). ::: ## Integration checklist 1. **Create an endpoint.** Add your public HTTPS URL under Webhooks in the Zyphe Dashboard, or through the endpoints API. 2. **Subscribe to the events you handle.** Endpoints receive only what they ask for. See the [event catalog](/docs/reference/statuses-and-codes#canonical-webhook-event-types). 3. **Choose the signing secret.** The shared organization secret, or one dedicated to this endpoint. Store it server-side; never expose it in browser or mobile code. 4. **Read the raw request body.** Signature verification must use the exact bytes received, before JSON parsing or re-serialization. 5. **Verify `X-Signature`.** Reject requests with an invalid signature or an unacceptable timestamp. See [Webhook Signature](./webhook-signature). 6. **Dispatch the event.** On `V2` branch on the envelope's `type`; on `LEGACY_V1` use `data` for results and `eventData` for notifications. See [Receiving Webhooks](./webhook-structure). 7. **Acknowledge delivery.** Return `2xx` promptly — `200` if the endpoint is `LEGACY_V1` — then do slower work asynchronously. 8. **Make processing idempotent.** Failed deliveries are retried, so receiving the same logical event more than once must be safe. :::tip[Test before going live] Configure endpoints in sandbox first: the sandbox and production registries are separate. Use the webhook trigger and monitor tools in the flow's developer controls to inspect the payload, delivery attempts, response status, and errors before sending production traffic. ::: ## Choose the right reference | You need to… | Read… | | ----------------------------------------------------------------------------------- | -------------------------------------------------------- | | Configure destinations, filters, secrets, and limits | [Webhook Endpoints](./endpoints) | | Understand `LEGACY_V1` vs `V2`, and migrate between them | [Payload Versions](./payload-versions) | | Implement the HTTP endpoint and route events | [Receiving Webhooks](./webhook-structure) | | Inspect fields for DV, PoA, Form, Phone, Wallet, SPID/CIE, KYB, AML, or Geolocation | [Webhook Payload](./webhook-payload) | | Look up event, status, and reason enums | [Statuses and codes](/docs/reference/statuses-and-codes) | | Handle failed or review-required results | [Failure and Review Events](./failure-payload) | | Verify that a request came from Zyphe | [Webhook Signature](./webhook-signature) | | Reconcile events with records in your system | [Custom Fields](./custom-fields) | | Attach a callback to one verification run | [Session Webhooks](./session-webhooks) | | Retrieve document images or full result details | [Export API](/docs/guides/export-api) | | Migrate from the legacy `data.kyc` format | [Backwards Compatibility](./backwards-compatibility) | The pages above each own one part of the contract. Payload examples are kept in the payload reference rather than repeated throughout the integration guide. --- ## Payload Versions Every endpoint declares which payload shape it receives. There are two, and they are stable contracts, not a rolling format: | Version | What you receive | Success rule | Default for | | ----------- | ---------------------------------------------------------------------------------- | -------------- | ---------------------------------- | | `LEGACY_V1` | Byte-for-byte the payload Zyphe sent before organization-level endpoints existed | Strictly `200` | Endpoints created by the migration | | `V2` | A common envelope naming the event, the API version, and both ends of the delivery | Any `2xx` | Every endpoint you create | The success rule differs on purpose: migrating an endpoint to `V2` must never silently change which of your responses count as delivered, so the strict rule stays attached to the legacy shape. ## `LEGACY_V1` Exactly the payload documented in [Receiving Webhooks](./webhook-structure) — the result envelope with `resultId`, `event`, `data`, `custom`, and `flowStatus`, or the notification envelope with `eventData`. Nothing was added to it and nothing was removed from it, including the fields a `V2` endpoint receives that this one does not. Two consequences: - A `LEGACY_V1` endpoint never receives `nextStep`, even where the platform now computes it. - A `LEGACY_V1` endpoint **cannot subscribe** to events that have no legacy shape, because there are no legacy bytes to reproduce. Today those are `flow.completed` and `kyc_passport.verification.updated`. The API refuses the subscription when you write it rather than dropping the delivery later. If you have an integration that works today, doing nothing is a supported choice. ## `V2` `V2` is not the legacy body with an envelope on top: it states each fact once, at one address. ```json { "id": "0f0dcb6c-6b6a-4f4a-a4a6-2b4a19e2e9c1", "type": "verification.dv.completed", "apiVersion": "2026-08-26", "createdAt": "2026-08-26T10:12:44.192Z", "recipientOrganizationId": "6b0f6a2e-1f5c-4a70-9d6b-2b1a0e4c9d33", "source": { "organizationId": "6b0f6a2e-1f5c-4a70-9d6b-2b1a0e4c9d33", "flowId": "2d8285d7-f4ba-42df-ab3f-681d9870d37a", "flowResultId": "936f35a8-4921-430e-b016-15be48968886" }, "flow": { "status": "PROCESSING", "slug": "onboarding", "customData": { "uid": "123" }, "nextStep": { "id": "03559a0f-be8e-4ab7-964d-1ff4745d92a4", "slug": "liveness", "name": "Liveness", "type": "LIVENESS" } }, "data": { "dv": { "id": "d65fa9a0-596e-4d7e-afd1-59a23bfb5a74", "verificationRequestId": "cf52e18e-28d1-4a2f-8304-c04ef5a75d0f", "flowId": "2d8285d7-f4ba-42df-ab3f-681d9870d37a", "flowStepId": "03559a0f-be8e-4ab7-964d-1ff4745d92a4", "createdAt": "2026-08-26T10:12:40.100Z", "customData": {}, "status": "PASSED", "reasons": [], "identityEmail": "applicant01@example.com" } } } ``` The envelope has three parts, and they answer three different questions: | Part | Question it answers | Notes | | ------ | ------------------------------ | ------------------------------------------------------------------------------------------------------------ | | root | What delivery is this? | `id`, `type`, `apiVersion`, `createdAt`, `recipientOrganizationId`, `source` | | `flow` | Which run, and where it stands | Present for every event that has a flow. Absent for Transaction Monitoring alerts. | | `data` | What happened | The product result under its own name (`dv`, `poa`, `kyb`, `aml`, …), or the notification under its own name | | Field | Meaning | | --------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | `id` | Identifier of the **event**. The same event delivered to three endpoints carries the same `id`. Use it for idempotency. | | `type` | The canonical event type — the single place the event is named. | | `apiVersion` | The envelope contract, dated. It changes only on a breaking envelope change. Current value: `2026-08-26`. | | `createdAt` | When the event occurred, not when this attempt was sent. | | `recipientOrganizationId` | Who this delivery is for. Differs from `source.organizationId` for KYC Passport deliveries. | | `source` | `organizationId`, plus `flowId` / `flowResultId` when the event is flow-bound. | | `flow.status` | The run's status, in the same vocabulary as the legacy `flowStatus`. Omitted when the producer did not observe the run. | | `flow.slug` | The flow's slug, so acting on an event does not require resolving `source.flowId` through the API first. | | `flow.customData` | The **flow result's** custom data — the legacy top-level `custom`. | | `flow.nextStep` | The step the run is waiting on (`id`, `slug`, `name`, `type`), or absent when it is waiting on nothing. | | `data.` | The result object. Only products that are actually present are sent. | | `data..customData` | The **verification request's** custom data. A different scope from `flow.customData`, and now visibly so. | ### What moved, compared with `LEGACY_V1` | `LEGACY_V1` | `V2` | Why | | ----------------------------------------- | ---------------------------- | --------------------------------------------- | | `event` (`COMPLETED`, `NOTIFICATION`, …) | _(gone)_ — use `type` | `type` already names the event, canonically | | `resultId` | `source.flowResultId` | Identical value on every standard payload | | `data.data.{dv,poa,…}` | `data.{dv,poa,…}` | The extra nesting carried no information | | Ten `null` product keys on every delivery | _(gone)_ | Absence says what `null` said | | `custom` | `flow.customData` | The name now says whose custom data it is | | `flowStatus` | `flow.status` | Read together with the run, so stored with it | | `nextStep` | `flow.nextStep` | `LEGACY_V1` never carries it at all | | `version: 0` inside each payload object | `apiVersion` on the envelope | One version, in one place | Nothing was summarised or dropped: every value the legacy body carried is still on the wire, at a stated address. Migrating is a mechanical re-pathing. ### Notifications A notification's data goes under its own name, and the legacy `eventData.type` discriminant is gone — the envelope's `type` already names it: ```json { "type": "flow.risk.reevaluated", "apiVersion": "2026-08-26", "source": { "organizationId": "…", "flowId": "…", "flowResultId": "…" }, "flow": { "slug": "onboarding", "customData": { "uid": "123" } }, "data": { "flowRiskReevaluated": { "flowResultId": "936f35a8-4921-430e-b016-15be48968886", "scoreBefore": 10, "scoreAfter": 70, "statusBefore": "COMPLETED", "statusAfter": "REQUIRES_MANUAL_REVIEW" } } } ``` | Canonical event | `data` key | `flow` block | | ------------------------------- | --------------------- | ---------------------------------------------------------------- | | `verification.document.expired` | `documentExpired` | Present, including `status` — its producer holds the flow result | | `verification.kyc.expired` | `kycResultExpired` | Present, without `status` | | `flow.risk.reevaluated` | `flowRiskReevaluated` | Present, without `status` | | `transaction.alert.created` | `transactionAlert` | **Absent** — a TM alert is about a transaction, not about a run | A producer that did not observe the run's state omits `flow.status` rather than guessing it. ### What only `V2` carries - **`flow.nextStep`**, the step the user is expected to reach next. - **`flow.slug`**, on every event that has a run. - **`flow.completed`**, a registry-native event fired when every step the flow asks for has a passing result. Before it existed, completion had to be inferred from `flowStatus` on the last step's payload, which is a snapshot taken before completion was evaluated. Its whole subject is the run, so the run is where it reports: ```json { "type": "flow.completed", "apiVersion": "2026-08-26", "source": { "organizationId": "…", "flowId": "…", "flowResultId": "…" }, "flow": { "status": "COMPLETED", "slug": "onboarding", "customData": { "uid": "123" }, "nextStep": null }, "data": { "identityId": "3f7a1c62-9f0d-4b58-b1d2-6b8a9c0e5d41" } } ``` - **Distinct notification events.** `verification.document.expired`, `verification.kyc.expired`, `flow.risk.reevaluated`, and `transaction.alert.created` are separate `type` values you subscribe to individually, instead of one `NOTIFICATION` event routed on a buried discriminant. `flow.completed` fires whenever the flow result reaches `COMPLETED`, so a run that is reopened and completes again emits it a second time. Key on the envelope's `id` and keep the handler idempotent. ### A change both versions see Step webhooks now evaluate the flow before sending, so the run's status describes the state _after_ the result being reported, not a snapshot taken before it was applied. That applies to `LEGACY_V1` deliveries too — the field is the same `flowStatus`, its value is simply more current. `nextStep` and `flowSlug` are stripped from `LEGACY_V1` bodies, which stay byte-identical to the pre-registry format. ### Body encoding The request body is canonical JSON, so object keys arrive in a deterministic order. Do not depend on that order when parsing, and always verify the signature against the raw bytes you received, before parsing. See [Webhook Signature](./webhook-signature). ## Migrating an endpoint to `V2` Switching is a single field, and it is reversible. 1. **Make your handler accept both.** A `V2` body has a top-level `type` and `apiVersion`; a `LEGACY_V1` body does not. ```ts function normalize(body: any) { if ('apiVersion' in body) { return { eventId: body.id, eventType: body.type, flowResultId: body.source.flowResultId, flowStatus: body.flow?.status, custom: body.flow?.customData ?? {}, results: body.data, // { dv } | { kyb } | { documentExpired } | … } } return { eventId: null, eventType: null, flowResultId: body.resultId, flowStatus: body.flowStatus, custom: body.custom ?? {}, results: body.event === 'NOTIFICATION' ? { [body.eventData.type]: body.eventData } : body.data, } } ``` Use the [field mapping table](#what-moved-compared-with-legacy_v1) to re-path the rest. 2. **Accept any `2xx` on your side** — or keep returning `200`, which satisfies both rules. 3. **Switch the endpoint**, in sandbox first: ```json PATCH /organizations/{organizationId}/webhooks/{endpointId} { "payloadVersion": "V2" } ``` 4. **Subscribe to the new events** you now have access to, such as `flow.completed`. 5. Once you trust the new handler, drop the legacy branch. If you would rather not touch a working endpoint at all, create a second endpoint pointing at a new URL with `payloadVersion: "V2"`, run both in parallel, and delete the old one when you are done. Both receive the same events; each is signed and retried independently. :::tip[Idempotency] On `V2`, `id` is the event identifier and is stable across retries and across endpoints — the natural idempotency key. On `LEGACY_V1` there is no such field: build a key from the result type and its identifier, as described in [Receiving Webhooks](./webhook-structure). ::: --- ## Session Webhooks When you create a verification request from your backend, you can attach a callback that belongs to **that verification run only**. It is delivered _in addition to_ every configured organization endpoint, and it is never added to the [endpoint registry](./endpoints). Use it when a single run needs its own destination — a per-tenant callback, a short-lived worker, a test harness — without permanently changing your organization's webhook configuration. ## Installing one Pass a `webhook` object to the SDK verification-request creation call: ```bash curl -X POST "https://api.zyphe.com/sdk/flow/${ZYPHE_FLOW_ID}/vr/create?sandbox=true" \ -H "x-api-key: ${ZYPHE_SECRET_API_KEY}" \ -H "Content-Type: application/json" \ -d '{ "email": "applicant01@example.com", "customData": { "customerReference": "C-123" }, "webhook": { "url": "https://api.example.com/verifications/session-42", "secret": "9f2b7c1d4e6a8035b1c9d2e4f6a80351d7e9b2c4f6a803517d9e2b4c6f8a0351", "eventTypes": ["verification.dv.completed", "verification.dv.failed", "flow.completed"], "payloadVersion": "V2" } }' ``` | Field | Required | Notes | | ---------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `url` | yes | HTTPS, up to 2048 characters. Re-validated against the public-address rules before every delivery. | | `secret` | yes | **You** generate it, 32–512 characters, and it must be **hexadecimal** — it is hex-decoded before signing, exactly like a Zyphe-generated secret. 32 random bytes hex-encoded (64 characters) is the right shape. Zyphe signs with it and never returns it. | | `eventTypes` | no | Omit to receive every verification and flow event this run produces. | | `payloadVersion` | no | Defaults to `V2`. See [Payload Versions](./payload-versions). | The response confirms what was installed: ```json { "sessionId": "cbe0f5cd-6f38-4a2e-9c3f-0a2f9e2b7c14", "sessionWebhook": { "id": "8a1c0d33-59a2-4f6c-9c30-64e1c1a4f0f2", "secretHint": "…cret", "expiresAt": "2026-09-25T10:00:00Z" } } ``` ## Rules - **A Secret API key is required.** A Publishable key may be embedded in a browser page, so it is not allowed to install a callback URL. Requests that carry `webhook` with a Publishable key are rejected. - **The secret is yours.** It is never minted or returned by Zyphe, which is what makes resuming a run idempotent: the same call with the same secret is safe to retry, and nothing has to be re-disclosed. - **Resuming replaces.** Supplying `webhook` again while resuming the same run replaces the previous callback; omitting it leaves the existing one in place. - **Lifetime is 30 days**, fixed by the server. After `expiresAt`, deliveries to it are skipped. - **Scope is enforced at send time**, not just when routing: a callback can only ever observe its own organization, flow, identity, and run. - **Not everything is subscribable.** `transaction.alert.created` and `kyc_passport.verification.updated` are rejected here — they belong to audiences a verification session does not define. ## Verifying Signature verification is identical to any other webhook, using the secret you supplied — hex-decoded into bytes, the same way Zyphe does when it signs. See [Webhook Signature](./webhook-signature). --- ## Webhook Payload This page documents the objects carried by standard result webhooks and lifecycle notifications. The outer HTTP and envelope contract is defined once in [Receiving Webhooks](./webhook-structure). :::note[The paths on this page are `LEGACY_V1` paths] The **contents** of each result object are the same in both payload versions, so every field table below applies to `V2` as well. Only the path differs: `V2` lifts the result object one nesting level up and drops its `version` field in favour of the envelope's `apiVersion`. See the [field mapping table](./payload-versions#what-moved-compared-with-legacy_v1). ::: ## Standard result fields Most result objects under `data` share these fields: | Field | Meaning | | ----------------------- | ----------------------------------------------------------------------------------------------------------------- | | `version` | Payload schema version. | | `id` | Identifier of the step result. It may contain a default value when processing failed before a result was created. | | `verificationRequestId` | Verification request that produced the result. | | `flowId` | Flow identifier. | | `flowStepId` | Flow-step identifier. | | `createdAt` | ISO 8601 timestamp associated with the request or result. | | `customData` | Custom values attached to the verification request. See [Custom Fields](./custom-fields). | | `status` | Status of the individual result. Do not confuse it with top-level `flowStatus`. | | `identityEmail` | Email of the verified identity, when available. | | `reason` / `reasons` | Structured failure or review context, depending on result type. | | `errorMessage` | Optional processing diagnostic, when supported by the result type. | The primary result key is the non-null value among `dv`, `poa`, `form`, `spid`, `phone`, `wallet`, `kyb`, `aml`, and `geolocation`. Other keys may be absent or `null`, depending on the serializer. Extended and legacy DV configurations can add companion values beside `dv`. ## Document Verification (`data.dv`) ```json { "version": 0, "id": "d65fa9a0-596e-4d7e-afd1-59a23bfb5a74", "verificationRequestId": "cf52e18e-28d1-4a2f-8304-c04ef5a75d0f", "flowId": "2d8285d7-f4ba-42df-ab3f-681d9870d37a", "flowStepId": "03559a0f-be8e-4ab7-964d-1ff4745d92a4", "createdAt": "2025-04-25T19:32:14.558006634Z", "customData": {}, "status": "PASSED", "reasons": [], "documentId": "d41bc0ea-3b5c-4342-a1ae-a46dd0a770f8", "documentType": "Driving License", "class": "web-mobile", "platform": "iOS", "browser": "Mozilla/5.0 ...", "scoreBiometricSelfie": 99, "errorMessage": null, "processAdditionalData": {}, "identityEmail": "applicant01@example.com" } ``` | DV-specific field | Meaning | | ------------------------------ | -------------------------------------------------------------------------------------------------------------- | | `reasons` | Structured reasons such as `DOCUMENT_EXPIRED`, `LOW_QUALITY`, or `UNDERAGE`. Empty when no reason is reported. | | `documentId` | Identifier of the document stored for this result. | | `documentType` | Human-readable document type. | | `class`, `platform`, `browser` | Optional client context captured during verification. | | `scoreBiometricSelfie` | Optional portrait-match percentage. | | `processAdditionalData` | Additional processor output, when available. | Standard DV webhooks do not include identity-document images. To retrieve front/back captures and related media, use the [Export API](/docs/guides/export-api). ### Extended document verification (`data.additionalData`) When Extended Webhook is enabled, `additionalData` is a sibling of `dv` inside `data`: ```json { "data": { "dv": { "id": "d65fa9a0-596e-4d7e-afd1-59a23bfb5a74", "status": "PASSED" }, "additionalData": { "firstName": "John", "lastName": "Doe", "dateOfBirth": "1990-01-15", "documentNumber": "AB1234567", "issuingState": "GBR", "expiryDate": "2030-12-31", "issuingDate": "2020-01-01", "issuingAuthority": "DVLA", "personalNumber": "", "documentClassCode": "DL", "selfie": { "contentType": "image/jpeg", "presignedUrl": "https://..." } } } } ``` `selfie.presignedUrl` is time-limited. Download it only when needed and apply the same access controls used for other identity data. A selfie URL is not a full document-image export; use the [Export API](/docs/guides/export-api) for identity-document images. The legacy `data.kyc` companion is documented in [Backwards Compatibility](./backwards-compatibility). ## Proof of Address (`data.poa`) In addition to the common result fields, proof-of-address results contain: | Field | Meaning | | -------------- | ----------------------------------------------------------------------- | | `reason` | Optional failure reason. | | `documentId` | Identifier of the uploaded address document. | | `documentType` | Document type, such as `PAY_SLIP`, `UTILITY_BILL`, or `BANK_STATEMENT`. | ```json { "status": "PASSED", "reason": null, "documentId": "e04a00e6-ccf9-4593-ab86-4b2c01f3bb95", "documentType": "UTILITY_BILL" } ``` The webhook does not include the address-document file. Retrieve it with the [Export API](/docs/guides/export-api). ## Form (`data.form`) | Field | Meaning | | ---------- | -------------------------------------------------- | | `reason` | Optional failure reason. | | `sections` | Submitted answers grouped by form section. | | `formId` | Identifier of the form definition, when available. | | `formName` | Name of the form. | ```json { "status": "PASSED", "reason": null, "sections": [ { "name": "Personal Information", "items": [{ "name": "fullName", "value": "John Doe" }] } ], "formId": "a1b2c3d4-5678-90ab-cdef-1234567890ab", "formName": "Customer Onboarding Form", "errorMessage": null } ``` ## Phone Verification (`data.phone`) Phone results include `reason`, `errorMessage`, and `phoneNumberLast4` in addition to the common fields. ```json { "status": "PASSED", "reason": null, "errorMessage": null, "phoneNumberLast4": "1234" } ``` :::info[Phone-number privacy] The full phone number is not included in the webhook. Zyphe stores a SHA-256 hash and exposes only the final four digits in this result. ::: ## Wallet Verification (`data.wallet`) | Field | Meaning | | ------------------------ | ---------------------------------------------------------------------- | | `message` | SIWX message signed by the user. | | `signature` | Signature produced by the wallet. | | `walletAddress` | Verified wallet address. | | `walletChain` | Network used, such as `ETHEREUM`, `SOLANA`, or their testnet variants. | | `reason`, `errorMessage` | Optional failure context. | ```json { "status": "PASSED", "message": "example.com wants you to sign in with your Ethereum account...", "signature": "0x1234567890abcdef...", "walletAddress": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb", "walletChain": "ETHEREUM", "reason": null, "errorMessage": null } ``` ## SPID / CIE (`data.spid`) SPID/CIE results include optional `reason`, `errorMessage`, and `userInfo`. The `userInfo` object can contain: - Name and identity attributes: `firstName`, `lastName`, `fullName`, `fiscalNumber`, `dateOfBirth`, `gender` - Birth and address attributes: `placeOfBirth`, `countryOfBirth`, `address` - Contact attributes: `email`, `mobilePhone`, `digitalAddress` - Provider attributes: `id`, `username`, `spidCode` - Business-account attributes: `companyName`, `registeredOffice`, `companyVatNumber` Fields depend on the identity provider and may be `null`. ## Geolocation (`data.geolocation`) ```json { "status": "PASSED", "reason": null, "errorMessage": null, "country": "IT", "ipAddress": "203.0.113.10", "deviceFingerprint": "device-fingerprint", "vpn": false, "blacklistedIp": false } ``` | Field | Meaning | | ------------------- | --------------------------------------------- | | `country` | Resolved country, when available. | | `ipAddress` | IP address evaluated for the result. | | `deviceFingerprint` | Device fingerprint associated with the proof. | | `vpn` | Whether VPN usage was detected. | | `blacklistedIp` | Whether the IP matched a blacklist. | ## KYB (`data.kyb`) KYB outcomes are delivered using the standard envelope. ### The case (`data.kybCase`) On `V2` payloads, `data.kybCase` carries the KYB case. Read the outcome from here: | Field | Meaning | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `caseId` | The case ID (the same value as the KYB result ID). | | `status` | The [case status](/docs/reference/statuses-and-codes#kyb-case-status). | | `dueDiligenceLevel` | `SIMPLIFIED`, `STANDARD`, or `ENHANCED`. | | `decision` | The decision that stands on the case: `outcome` (`APPROVED` or `REJECTED`), `decidedAt`, and, when given, `reasonCode` and `reason`. Absent while the case is undecided or reopened. | ```json { "kybCase": { "caseId": "8f0c9b49-a562-41bf-ab8b-5fd0bfee2d68", "status": "APPROVED", "dueDiligenceLevel": "STANDARD", "decision": { "outcome": "APPROVED", "decidedAt": "2026-09-28T10:15:00Z" } } } ``` ### The KYB result (deprecated) `data.kyb` still carries the full KYB result for existing integrations, and is deprecated: new integrations should read `data.kybCase`. Its `status` keeps the previous [moderation vocabulary](/docs/reference/statuses-and-codes#kyb-moderation-moderationresultstatus). It includes the common result fields plus: | Field | Meaning | | ----------------------- | ------------------------------------------------------------- | | `businessInformation` | Submitted and verified business information. | | `documentUploads` | KYB document-upload state and metadata. | | `uboDefinitions` | Ultimate Beneficial Owner definitions and verification state. | | `directorDefinitions` | Director definitions and verification state. | | `pepAndSanctionsStatus` | Consolidated PEP and sanctions state. | | `nextAction` | Next action required by the KYB workflow, when any. | | `assignedToIdentityId` | Reviewer assigned to the case, when any. | | `fundedAt` | Funding timestamp, when applicable. | | `report` | Generated report or report reference, when available. | ```json { "status": "REVIEW_REQUIRED", "reason": null, "errorMessage": null, "businessInformation": {}, "documentUploads": [], "uboDefinitions": [], "directorDefinitions": [], "pepAndSanctionsStatus": null, "nextAction": null } ``` ## AML (`data.aml`) AML deliveries represent produced results, scheduled refreshes, and moderation changes. Top-level `event` and inner `updateKind` use `PRODUCED`, `REFRESHED`, or `MODERATED`. ```json { "event": "PRODUCED", "data": { "aml": { "version": 0, "id": "e5f6a7b8-9012-3456-7890-abcdef123456", "verificationRequestId": "cf52e18e-28d1-4a2f-8304-c04ef5a75d0f", "flowId": "2d8285d7-f4ba-42df-ab3f-681d9870d37a", "flowStepId": "03559a0f-be8e-4ab7-964d-1ff4745d92a4", "createdAt": "2026-07-14T10:15:30Z", "updateKind": "PRODUCED", "status": "PENDING", "subjectType": "PERSON", "hasPep": false, "hasSanctions": false, "riskScorePercent": 12 } } } ``` | Field | Meaning | | ------------------ | ---------------------------------------------------------------------- | | `updateKind` | Why this webhook was emitted: `PRODUCED`, `REFRESHED`, or `MODERATED`. | | `status` | Moderation state: `PENDING`, `APPROVED`, `REJECTED`, or `ESCALATED`. | | `subjectType` | Screened subject type, such as `PERSON` or `COMPANY`. | | `hasPep` | Whether PEP matches are present. | | `hasSanctions` | Whether sanctions matches are present. | | `riskScorePercent` | Optional risk score from 0 to 100. | The same four AML moderation values are listed in [Statuses and codes](/docs/reference/statuses-and-codes#aml-result-moderation-dataamlstatus). Do not confuse them with the KYB PEP and sanctions screening states. ## Notification events Notification webhooks use top-level `eventData`, not `data`, and omit `flowStatus`. See the full envelope in [Receiving Webhooks](./webhook-structure#notification-envelope). ### `DOCUMENT_EXPIRED` ```json { "version": 0, "type": "DOCUMENT_EXPIRED", "flowResultId": "936f35a8-4921-430e-b016-15be48968886", "verificationRequestId": "cf52e18e-28d1-4a2f-8304-c04ef5a75d0f", "flowId": "2d8285d7-f4ba-42df-ab3f-681d9870d37a", "flowStepId": "03559a0f-be8e-4ab7-964d-1ff4745d92a4", "expiryDate": "2025-04-25", "customData": {}, "documentId": "d41bc0ea-3b5c-4342-a1ae-a46dd0a770f8", "documentType": "Driving License", "identityEmail": "applicant01@example.com" } ``` ### `KYC_RESULT_EXPIRED` | Field | Meaning | | --------------- | ------------------------------------------------ | | `flowResultId` | Expired flow-result identifier. | | `flowId` | Associated flow. | | `identityId` | Identity associated with the expired KYC result. | | `dvResultId` | Document-verification result that expired. | | `identityEmail` | Identity email, when available. | ### `FLOW_RISK_REEVALUATED` | Field | Meaning | | ----------------------------- | ----------------------------------------------------------- | | `flowResultId` | Re-evaluated flow result. | | `scoreBefore`, `scoreAfter` | Previous and current composed scores. Either may be `null`. | | `statusBefore`, `statusAfter` | Previous and current flow statuses. | Use this event to refresh downstream decisions when AML moderation, scheduled AML refreshes, manual review, or administrative scoring changes the composed risk result. --- ## Webhook Signature Zyphe signs webhook requests with HMAC-SHA256 when a signing secret is in force for the destination. Verify the signature before parsing or processing the payload. ## Which secret signs a delivery | Destination | Signed with | | ------------------------------------------ | -------------------------------------------------------------- | | Endpoint with `secretMode: "ORGANIZATION"` | The organization's shared webhook secret | | Endpoint with `secretMode: "DEDICATED"` | That endpoint's own secret | | [Session webhook](./session-webhooks) | The secret you supplied when creating the verification request | An organization that never configured a webhook secret keeps receiving unsigned deliveries — that state was preserved rather than "fixed" when endpoints were introduced. Configure a secret to start receiving `X-Signature`. Each endpoint's `secretHint` (the last characters of the key in force) tells you which secret to verify against without ever disclosing it. A plaintext secret is returned exactly once, when it is created or rotated. See [Webhook Endpoints](./endpoints#signing-secret). ## Signature format The `X-Signature` header contains a Unix timestamp and a hexadecimal signature: ```text t=,v0= ``` Zyphe constructs the signed value from the timestamp, a dot, and the exact JSON request body: ```text signed_payload = "{timestamp}.{raw_json_payload}" ``` The webhook secret is a hexadecimal string. Decode it into bytes, then calculate the hexadecimal HMAC-SHA256 digest of `signed_payload`. :::warning[A secret you supply yourself must also be hexadecimal] Every secret is hex-decoded into bytes before signing, including one you generate for a [session webhook](./session-webhooks). A non-hexadecimal secret fails at signing time and the delivery never leaves Zyphe. Generate 32 random bytes and hex-encode them: the resulting 64 characters clear the 32-character minimum and match what Zyphe's own generator produces. ::: The request body is **canonical JSON** — object keys in a deterministic order, no insignificant whitespace — because the signature covers exactly those bytes. Parsing and re-serializing the body yields different bytes and the signature will not verify. See [Body encoding](./payload-versions#body-encoding). ## Verification steps 1. Read `X-Signature` and extract `t` and `v0`. 2. Reject an invalid timestamp or one outside your accepted tolerance. A five-minute tolerance is a common starting point for replay protection. 3. Read the raw, unmodified request body. Do not parse and re-serialize it before verification. 4. Construct `{t}.{raw_request_body}`. 5. Decode your hexadecimal webhook secret and calculate the HMAC-SHA256 digest. 6. Compare the computed hexadecimal digest with `v0` using a constant-time comparison. 7. Parse and process the request only after all checks pass. If the signature is missing, malformed, expired, or does not match, return an error and do not process the event. Keep the secret server-side and rotate it immediately if it is exposed. ## Rotating Rotating the **shared** organization secret re-keys every endpoint in `ORGANIZATION` mode at once; the response lists exactly which ones. New attempts are signed with the new secret immediately. The previous secret is recorded as still acceptable until `secretExpiresAt`, one hour later — comfortably longer than the maximum retry window. **Keep accepting it on your side until then**, so a delivery signed just before the rotation still verifies when it arrives or is retried. Rotating a **dedicated** secret affects only its own endpoint. To roll over without a gap, accept both the old and the new secret during the grace window: compute both digests and accept a constant-time match against either. --- ## Receiving Webhooks This page defines the HTTP delivery contract and the payload shapes your handler will see. Where deliveries come from is covered in [Webhook Endpoints](./endpoints); step-specific fields are documented separately in [Webhook Payload](./webhook-payload). ## Delivery contract | Property | Value | | -------------------------- | --------------------------------------------------------------------------- | | Method | `POST` | | Content type | `application/json` | | Signature header | `X-Signature` when a webhook secret is configured | | Successful acknowledgement | Any `2xx` for a `V2` endpoint; strictly `200 OK` for a `LEGACY_V1` endpoint | | Delivery attempts | Up to four total attempts, with exponential backoff from 1s to 8s | | Request timeout | 30 seconds by default | | Redirects | Not followed | Each endpoint subscribed to an event gets its own delivery: they are signed, retried, and disabled independently, and one endpoint failing never affects another. Your endpoint should: 1. Capture the unmodified request body. 2. Verify `X-Signature` before trusting the body. 3. Parse the JSON only after verification. 4. Store or enqueue the event using idempotent application logic. 5. Return `200 OK` promptly. See [Webhook Signature](./webhook-signature) for the exact HMAC input and header format. ## Which shape you receive The endpoint's `payloadVersion` decides: - **`LEGACY_V1`** delivers the two envelopes described below, exactly as Zyphe sent them before organization-level endpoints existed. - **`V2`** carries the same facts in a different, versioned envelope: a canonical `type`, an event `id`, the source and recipient of the delivery, a `flow` block for the run, and the result under its own name in `data`. **This page describes `LEGACY_V1`.** The `V2` envelope, and a field-by-field mapping between the two, are in [Payload Versions](./payload-versions). The step-specific objects in [Webhook Payload](./webhook-payload) are the same in both. ## Standard result envelope Verification-result webhooks use this envelope: ```json { "resultId": "936f35a8-4921-430e-b016-15be48968886", "event": "COMPLETED", "data": { "dv": { "id": "d65fa9a0-596e-4d7e-afd1-59a23bfb5a74", "status": "PASSED" } }, "custom": {}, "flowStatus": "COMPLETED" } ``` | Field | Meaning | | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `resultId` | Identifier of the overall flow result. | | `event` | The event for this delivery. Common verification values include `COMPLETED`, `FAILED`, `REVIEW`, and `REJECTED`; a KYB submission uses `SUBMITTED`. AML updates use `PRODUCED`, `REFRESHED`, or `MODERATED`. | | `data` | The typed result object. The primary key identifies the result type. | | `custom` | Flow-level custom data used to reconcile the result with your system. | | `flowStatus` | Current status of the overall flow, which may differ from the individual step status. | The primary `data` keys are `dv`, `poa`, `form`, `spid`, `phone`, `wallet`, `kyb`, `aml`, and `geolocation`. Extended DV webhooks also include `additionalData`; organizations using legacy compatibility may also receive `kyc` beside `dv`. ## Notification envelope Lifecycle notifications have a different shape. They use top-level `eventData` and intentionally omit `data` and `flowStatus`: ```json { "resultId": "936f35a8-4921-430e-b016-15be48968886", "event": "NOTIFICATION", "eventData": { "version": 0, "type": "DOCUMENT_EXPIRED", "flowResultId": "936f35a8-4921-430e-b016-15be48968886" }, "custom": {} } ``` Route notifications by `eventData.type`. Current notification types are: - `DOCUMENT_EXPIRED` - `KYC_RESULT_EXPIRED` - `FLOW_RISK_REEVALUATED` - `TRANSACTION_ALERT` (Transaction Monitoring) On a `V2` endpoint you do not need to route on `eventData.type`: each of these is a distinct canonical event you subscribe to individually (`verification.document.expired`, `verification.kyc.expired`, `flow.risk.reevaluated`, `transaction.alert.created`). Their fields are listed under [Notification Events](./webhook-payload#notification-events). ## Dispatching events On a `V2` endpoint, branch on the envelope's canonical `type` — no envelope sniffing required: ```ts if ('apiVersion' in body) { // body.type is e.g. 'verification.dv.completed', 'flow.completed', 'transaction.alert.created' // body.flow holds the run; body.data holds the result under its own name handleCanonicalEvent(body.type, body.id, body.flow, body.data) } ``` On a `LEGACY_V1` endpoint, use the envelope before inspecting step-specific fields: ```ts if (payload.event === 'NOTIFICATION') { handleNotification(payload.eventData.type, payload.eventData) } else if (payload.data.aml) { handleAmlUpdate(payload.event, payload.data.aml) } else { const resultTypes = ['dv', 'poa', 'form', 'spid', 'phone', 'wallet', 'kyb', 'geolocation'] const resultType = resultTypes.find((key) => payload.data[key] != null) handleVerificationResult(resultType, payload) } ``` Do not assume that `resultId` uniquely identifies one delivery: a flow can produce multiple step results and later updates. Choose an idempotency key that includes the result type and its result identifier or update kind. On `V2` this is simpler: the envelope's `id` identifies the event and is stable across retries and across endpoints, so it is the natural idempotency key. --- ## Document Selection The Document Selection step allows users to choose the specific type of identity document they wish to use for verification. This step acts as a routing mechanism, ensuring that the subsequent verification steps are configured to handle the selected document type and issuing country. ## How It Works This step is typically placed at the beginning of a verification flow. It presents the user with a filtered list of supported countries and document types based on the organization's configuration. Once a user makes a selection, the flow stores this preference and uses it to initialize subsequent steps such as Document Verification (DV), SPID (Italian Digital Identity), or Proof of Address (PoA). This ensures a tailored experience where the user is only asked for information relevant to their specific document. ## Customize Settings ### General Details - **Name:** The name of the flow step for identification within the dashboard. - **Countries Filter:** Define a whitelist or blacklist of countries. Users will only be able to select documents from allowed countries. - **Document Type Whitelist:** Specify which categories of documents are acceptable (e.g., Passport, National ID, Driver's License). - **Allowed Documents Per Country:** A granular configuration that maps specific country codes to their respective allowed document types. - **Government Providers:** Configuration for digital identity providers, such as SPID, mapping them to specific document types. - **Success Button Label:** The text displayed on the button after the user has confirmed their selection. ## Related Documentation - [Document Verification](./document-verification.md) - [Proof of Address](./proof-of-address.md) - [SPID / CIE](./spid-cie.md) --- ## Document Verification Short product explainer: [How document verification works](/docs/how-it-works/document-verification). ## Customize Settings ### General Details - **Name:** The name of the flow step. It will be used to identify the step in the flow. - **Minimum Age:** Age threshold that will be considered valid for the verification flow. - **Minimum Acceptable Document Score:** The system analyzes submitted documents and computes a score based on authenticity checks. This parameter sets the minimum score threshold required for document validation. - **AML Agent Mode:** when person screening produces PEP, sanctions, or adverse-media hits, chooses how the AML AI agent moderates them (`Disabled`, `Suggest`, or `Auto-pilot`). See [AML Agent Mode](/docs/aml#aml-agent-mode) and the [AML Agentic Review Engine](/docs/aml/agentic-review-engine). - **Success Button Label:** A custom label for the Continue button that is shown once the step is completed. :::info The Document Verification step extracts and validates information from identity documents. To add liveness verification (ensuring the person is real and matches the document), add a separate [Liveness Verification](./liveness.md) step after this one. ::: ### Country Filters If not specified, by default all the countries are whitelisted. - **Countries Whitelist:** Documents from countries **in** the list will be accepted. - **Countries Blacklist:** Documents from countries **not in** the list will be accepted. If both are configured, the whitelist will override the blacklist. ### Document Filters - **Document Type Whitelist:** Only document types that are in the list will be accepted (eg. ID Card, Driving License, Passport). If not specified, all the document types are accepted.
Review the configured Document Verification step in the flow.
--- ## Form ## Create a New Form In order to create a "Form" Flow Step, you first need to create a Form. In the Zyphe Dashboard, navigate to the **Forms** section and click on the **Create** button. :::info A Form can be reused in multiple different Flow Steps. :::
Create forms from the dashboard and preview the end-user experience as you edit.
You can also generate a first draft from a prompt, then customize the generated sections and fields in the form editor.
Use prompt generation to create a reusable form draft from a natural-language description.
### Section A form is composed of one or more sections. Each section will be displayed to the user as a separate page. Each section is composed of one or more items. ### Item An item is one of the following types: - **Input Field:** A form input field. - **Name:** The "machine-friendly" name of the field. This will be used for the JSON entry key. - **Label:** The user-facing label of the field. - **Type:** Text, Textarea, Checkbox, Date, Select, File, Place - **Required:** Whether the field is required or not. - **Options (Select):** A list of predefined values for the user to choose from, with an optional "Other" free-text entry. - **Options (File):** Accepted MIME types (e.g., `application/pdf`, `image/jpeg`) and the expected document type. - **Separator:** A line that visually separates items within a section. - **Plaintext:** Plain text displayed to the user in the form of one or more paragraphs.
Edit sections and form items directly in the form builder.
### Visibility Conditions You can use visibility conditions to show or hide fields based on previous answers. This lets you keep forms shorter for users while collecting additional information only when it is relevant.
Configure conditions to control when specific fields are visible.
Conditions can combine field values and operators to support dynamic form behavior.
### Scoring Every input field has an optional **Score** panel in its settings, where you can assign score tags and factors based on the field's answer. The weights you configure here feed your organization's scores, by default the **Risk score**: which are computed on each flow result once the user completes the flow.
Expand the Score panel in a field's settings to score its answers.
The panel offers three mechanisms: - **Option weights (Select fields):** Assign an optional score weight to each option; the weight is applied when that option is selected. Options with no weight simply don't contribute. - **Score tags:** Attach one or more tags to the field, each with a **Weight**. A tag can be emitted unconditionally or **only when** the answer matches a condition, for example, emit a tag with weight `40` only when a checkbox is checked. - **Contextual factors (optional):** Attach multipliers that amplify the score instead of adding to it. A factor uses either a **fixed key** or, on Select fields, the **answer value**, and carries a **Multiplier**. Factors also support "only when" conditions. You can score a form with tags only; factors are not required. A typical use is a province or jurisdiction select: each option is a factor key (for example an Italian province) whose multiplier scales the tags already emitted by the form. See [tag vs factor](/docs/guides/scoring/how-scores-are-computed#tag-weight-vs-contextual-factor).
Assign a score weight to each option of a Select field.
Configure conditional score tags and contextual factors for a field.
If your organization has defined custom scores, each tag or factor also has a **Score** selector that chooses which score it feeds; otherwise everything feeds the default Risk score. :::tip[Scoring documentation] Score definitions, tag weights, and the math that turns them into a 0–100 score are covered in the dedicated [Scoring](/docs/guides/scoring) section, see in particular [Score Definitions](/docs/guides/scoring/score-definitions) and [How Scores Are Computed](/docs/guides/scoring/how-scores-are-computed). ::: ### Multilanguage Support Forms support multiple editing languages, so you can localize section labels, field labels, and option labels for users in different locales.
Switch the editing language to localize form content.
## Customize Settings - **Name:** The name of the flow step. It will be used to identify the step in the flow. - **Form:** The form to be embedded in the flow step. - **Success Button Label:** A custom label for the Continue button that is shown once the step is completed. --- ## Geolocation Verification The Geolocation Verification step allows organizations to verify the physical location of a user during the verification flow. This process cross-references the device's reported coordinates with network-level data to ensure the user is present in an authorized region and is not attempting to mask their location. ## How It Works The verification process follows a two-step sequence to ensure the integrity of the location data: 1. **Initialization:** The client requests a geolocation verification start. The system generates and returns a unique, time-limited nonce. 2. **Proof Submission:** The client submits the geolocation proof, which includes GPS coordinates, device fingerprint, the provided nonce, permission status, and network metadata such as RTC candidates. 3. **Validation:** The system performs reverse geocoding on the coordinates to determine the country. This is then compared against the IP-based country data derived from request headers or Cloudflare trace data. 4. **Result:** If the coordinates and IP country do not match, the verification fails with a "location_ip_mismatch" reason. ## Where the result is stored The geolocation result is stored with the verification, on the same record and audit trail as the identity evidence, so an examiner reads location and identity together rather than joining two systems. The result carries the status, the failure reason where there is one, the detected country, the IP address, the device fingerprint, the VPN status and whether the IP was blacklisted. Operators in markets whose licence names a specific geolocation vendor can keep running that vendor alongside this step. Zyphe does not ingest a third-party geolocation payload, and the two results stay independent: Zyphe stores its own. ## Customize Settings ### General Details - **Name:** The name of the flow step used for internal identification. - **VPN Detection:** When enabled, the system checks if the user is connecting through a known VPN or proxy service. - **IP Validation:** Enables strict validation of the user's IP address against known blacklists and reputation databases. - **Location Cross-Check:** Performs a mandatory comparison between the device's GPS coordinates and the network's reported location. - **Success Button Label:** The text displayed on the button after a successful location verification. ## Technical Details - **Rate Limiting:** The initialization endpoint is limited to 10 requests per 60 seconds. The verification submission endpoint is limited to 10 requests per 120 seconds. - **Nonce Expiry:** The verification nonce is valid for 300 seconds (5 minutes). Proofs must be submitted within this window. - **Result Fields:** The verification result includes the status, failure reason (if applicable), detected country, IP address, device fingerprint, VPN status, and whether the IP is blacklisted. ## Related Documentation - [Creating a Flow](./index.mdx) - [Document Verification](./document-verification.md) - [Liveness Verification](./liveness.md) --- ## KYC Overview KYC verifies the identity of an **individual**. A KYC flow can combine identity-document checks, liveness detection, proof of address, phone verification, forms, and other steps to collect the evidence your organization needs for onboarding and compliance. This guide explains how to create and configure a KYC flow in Zyphe, from selecting the flow type to testing SDK and webhook integrations. ## Create a KYC Flow ### 1. Log in to the admin panel Login to the Zyphe Dashboard and navigate to the **Flows** section. ### 2. Click the "Create Flow" button Click on the **Create Flow** button on the top right.
Open the Flows page and click Create Flow to start a new flow.
Zyphe supports two types of flows: - **KYC:** Use this flow type to verify individuals. - **KYB:** Use this flow type to verify businesses. For this tutorial, we will create a KYC flow.
Choose whether to create a KYC flow for individuals or a KYB flow for businesses.
### 3. Configure the flow Customize the flow settings: - **Name:** the name of the flow. - **Slug:** a short identifier for the flow. It will be used to identify the flow within the link that is going to be shared with the end users that goes through the verification process. - **Success URL:** the link where we redirect the users once the verification process is completed. :::note[Webhooks are not configured here] Webhook destinations belong to the organization, not to the flow. Create an endpoint under Webhooks and scope it to this flow (or to every flow you own). See [Webhook Endpoints](/docs/guides/webhook/endpoints). :::
Enter the flow name, slug, and success URL.
### 4. Optional: Invite partner organizations If you want to share verification results with partner organizations, you can enable **KYC Passport** for this flow. This allows you to create a trusted ecosystem where verified identity data is securely shared with authorized partners. KYC Passport enables you to invite partner organizations to access KYC verification results from your flow. When users complete verification, they provide consent for their data to be shared with all approved partners, eliminating the need for repeated verification across your ecosystem. :::tip[Step-by-step guide] For a detailed walkthrough with screenshots on how to invite partner organizations, see the [KYC Passport: Inviting Partner Organizations](/docs/guides/kyc-passport) guide. ::: For technical details about how KYC Passport works, including security considerations and use cases, see the [KYC Passport technical documentation](/docs/data-flows/kyc-passport). ### 5. Configure the flow settings Use the flow configuration panel to update the flow endpoints and advanced settings after the flow has been created. - **Success URL:** the page where users are redirected after they complete all flow steps. Webhook destinations and signing secrets are managed at the organization level under Webhooks, not in this panel. See [Webhook Endpoints](/docs/guides/webhook/endpoints).
Use the flow settings action to review or update endpoint settings after creation.
Review or update the flow's redirect settings after creation.
### 6. Create a flow step Click **Add Step** to start creating the verification steps for the current flow. A common KYC setup starts with **Document Selection** and then adds **Document Verification**. - **Document Verification:** Scans and validates identity documents using the phone camera. Extracts information from documents and performs authenticity checks. Supports documents from 190+ countries including ID cards, passports, and driver's licenses. - **Liveness Verification:** Performs active liveness detection to ensure the person is real and matches the portrait in their identity document. Must be linked to a Document Verification step. - In order to add a Liveness Verification step, you need to first add a Document Verification step. - **Proof of Address:** Allows the users to submit documents that attest their residency such as utility bills, pay slip, financial documents and others. - In order to add a Proof of Address step, you need to first add a Document Verification step or a SPID step. - **Phone Verification:** Allows users to verify their phone number through an SMS-based OTP (One-Time Password) authentication flow. - Please contact support to enable this step type. - **Form:** Allows to collect additional information. The form step allows to embed any form that has been created with the Form builder. - In order to add a form step, you first need to create a Form with the Form builder. - **Wallet Verification:** Allows users to prove ownership of their cryptocurrency wallet by connecting their wallet and signing a cryptographic message. Supports Ethereum and Solana networks. - **SPID:** Allows the users to submit their SPID (Italian digital identity card) to verify their identity. - Please contact support to enable this step type. - **Document Selection:** Allows users to choose which type of identity document they want to use for verification. Acts as a routing step before Document Verification, SPID, or Proof of Address steps. - **Geolocation Verification:** Verifies the physical location of a user by cross-referencing device GPS coordinates with network-level IP data. - **Sharing:** Enables the secure transfer of previously verified identity data to partner organizations, supporting reusable credentials and one-click KYC flows. Let's start by creating a new Document Verification step
Click Add Step from the new flow page to begin adding verification steps.
Select the type of flow step you want to add.
Start with Document Selection so users can choose their document type.
The Document Selection step appears in the flow after it is added.
After that we can proceed with adding the Document Verification step
Open the Add Flow Step dialog again to add Document Verification.
Select Document Verification and link it to the Document Selection step.
The flow now contains both Document Selection and Document Verification steps.
### 7. SDK snippets Use the SDK snippets panel to generate implementation examples for the selected flow and step. These snippets help you start an SDK integration with the correct identifiers and environment values.
Open SDK snippets from the step devtools panel.
Copy a generated SDK snippet with the flow and step identifiers already filled in.
### 8. Webhook trigger Use the webhook trigger tool to manually send a webhook event for a flow step. This is useful when testing your webhook endpoint before sending users through the flow.
Open the webhook trigger tool from the step devtools panel.
Trigger a test webhook event for a selected flow step and status.
### 9. Webhook monitor Use the webhook monitor to inspect webhook delivery attempts, payloads, responses, and errors while testing your integration.
Open the webhook monitor from the step devtools panel.
Inspect captured webhook events, delivery attempts, payloads, and errors.
### 10. Flow Builder Flow Builder is an alternative way to build flows. Use it when you need advanced patterns such as if conditions, custom logic, branching paths, and more complex step orchestration.
Open Flow Builder from the flow page when you need advanced orchestration.
Use the Flow Builder canvas to arrange steps and connect branching paths.
Add new nodes to define additional actions, checks, or branches.
Configure switch conditions to route users through different flow paths.
#### Assign Risk Tags The **Assign Risk Tags** action attaches custom score tags to the flow result. Use it when the tag should fire only if a condition in the graph is true (for example document verification failed, or a form answer matched), rather than on every run. 1. Create the tag on **Score Definitions → Manage tags** (or **Risk Scoring Tags** for AML-side custom tags). The action can only pick tags that already exist. 2. In Flow Builder, add an **Assign Risk Tags** node and select one or more of those tags. 3. Connect it after a **switch** (or after the step whose outcome you care about) so assignment is conditional. Form fields can emit tags without this node; use the form **Score** panel for questionnaire weights. Full walkthrough: [Tags](/docs/guides/scoring/tags). #### Conditions with custom data and vault fields Flow Builder conditions can use custom data passed into the verification flow. This is useful when you want to route users based on information from your own system, such as customer segment, onboarding type, product plan, or other context attached to the verification session. Conditions can also use selected fields extracted from vault documents, such as age, nationality, document metadata, or address-related values. These fields are handled with privacy in mind: Zyphe does not store the document details unencrypted just to make workflow decisions. Instead, the relevant condition is evaluated securely when the verified document data is available, and the workflow keeps only the outcome needed to continue routing the flow. --- ## Liveness Verification The Liveness Verification step ensures that the person completing the verification is a real human and matches the portrait in their identity document. This step must be linked to a Document Verification step. Short product explainer: [How liveness works](/docs/how-it-works/liveness). ## Overview The liveness check performs active liveness detection using facial recognition technology to: 1. Verify that a live person is present (not a photo, video, or mask) 2. Match the live portrait against the portrait extracted from the identity document 3. Optionally perform biometric uniqueness checks to prevent duplicate identities (ask the support to enable the functionality in case of need) ## How It Works 1. **Prerequisites**: A Document Verification step must be completed first to extract the portrait image from the identity document 2. **User Flow**: The user is prompted to position their face in the camera frame and follow on-screen instructions 3. **Active Liveness**: The system performs active liveness detection to ensure a real person is present 4. **Face Matching**: The live portrait is compared against the portrait from the document 5. **Validation**: The system validates that the match score meets the configured threshold ## Customize Settings ### General Details - **Name:** The name of the flow step. It will be used to identify the step in the flow. - **Document Step:** The Document Verification step that this liveness check is linked to. The liveness check will use the portrait extracted from the document in this step for comparison. - **Success Button Label:** A custom label for the Continue button that is shown once the step is completed. ### Thresholds - **Minimum Portrait Match Percent:** The minimum similarity score (0-100%) required between the live portrait and the document portrait. Default: 75% - Higher values increase security but may result in more false rejections - Lower values are more permissive but may reduce security - **Biometric Match Percent:** The minimum similarity score required for biometric uniqueness checks when biometric checking is enabled. Default: 75% (ask the support if you need to change the value) ## Best Practices ### For End Users The liveness check works best when users: - **Use good lighting**: Ensure the face is well-lit without harsh shadows - **Find a neutral environment**: Use a plain background without distractions - **Position properly**: Keep the face centered in the frame - **Remove accessories**: Take off glasses, hats, or masks that might obscure the face ## Common Issues ### Low Match Score If users frequently fail the liveness check: - Check if the portrait in the document is clear and recent - Verify that lighting conditions are adequate - Ensure users are following the on-screen instructions ## Technical Details The liveness verification step: - Uses active liveness detection (user interaction required) - Performs face matching using advanced biometric algorithms - Stores the live portrait securely in the user's vault - Can trigger biometric uniqueness checks across on a per-flow basis ## Related Documentation - [Document Verification](./document-verification.md) - Must be configured before adding a liveness step - [Webhook Payload](/docs/guides/webhook/webhook-payload) - Learn about the webhook events for liveness verification --- ## Phone Verification The Phone Verification step allows you to verify users' phone numbers through an SMS-based OTP (One-Time Password) authentication flow. ## How It Works 1. **Phone Number Entry:** The user enters their phone number in international format (E.164). 2. **OTP Delivery:** The system sends a 6-digit verification code via SMS to the provided phone number. 3. **Code Verification:** The user enters the received code to complete the verification. 4. **Completion:** Once verified, the phone number is securely stored (hashed) and the verification step is marked as complete. ## Customize Settings ### General Details - **Name:** The name of the flow step. It will be used to identify the step in the flow. - **Success Button Label:** A custom label for the Continue button that is shown once the step is completed. ## Technical Details ### Phone Number Format Phone numbers must be provided in **E.164 format**, which includes: - A leading `+` sign - Country code (1-3 digits) - Phone number (up to 15 digits total) **Examples:** - `+1234567890` (Valid) - `+19876543210` (Valid) - `1234567890` (Invalid - missing `+`) ### Security Features - **OTP Expiration:** Verification codes expire after 3 minutes (180 seconds). - **Rate Limiting:** - Starting verification: Maximum 3 requests per 5 minutes per verification request. - Code verification: Maximum 5 attempts per 3 minutes per verification request. - **Data Privacy:** Phone numbers are stored as SHA-256 hashes. Only the last 4 digits are stored in plain text for reference. ### SMS Delivery SMS messages are sent via AWS SNS with the sender ID "Zyphe" and include the verification code in the user's locale. ## Requirements :::info The Phone Verification product must be enabled for your organization. Please contact support if you need access to this feature. :::
Configure the Phone Verification step and its success button label.
--- ## Proof of Address Short product explainer: [How proof of address works](/docs/how-it-works/proof-of-address). ## Customize Settings - **Name:** The name of the flow step. It will be used to identify the step in the flow. - **Document Types:** The types of documents to be accepted as valid proof of residency. - **Maximum Document Age (in days):** If the submitted document is older than the specified threshold, it will be rejected. - **Success Button Label:** A custom label for the Continue button that is shown once the step is completed.
Configure accepted proof-of-address document types and the maximum document age.
--- ## Sharing The Sharing step enables the secure transfer of verified identity data between different organizations or flows. This feature supports the concept of reusable credentials, allowing users who have already completed a verification process to share their existing data with partners without undergoing the full verification process again. ## How It Works When a user reaches a Sharing step in a flow, the system checks for existing verified data associated with that user's identity (often referred to as a KYC Passport). If valid data is found, the Sharing step facilitates the automatic population of the target flow with the verified attributes. The organization defines which partner flows are authorized to receive this data and which specific verification components (such as Document Verification or Liveness) should be shared. This significantly reduces friction for the user while maintaining high security standards. ## Customize Settings ### General Details - **Name:** The internal identifier for this flow step. - **Partner Configurations:** A list of authorized partner flows. Each configuration specifies the unique ID of the partner flow and the types of verification data (e.g., Document Verification, Form data, Liveness) that are permitted to be shared. - **Success Button Label:** The text displayed on the button after the user consents to share their data. ## Related Documentation - [Reusable Credentials](/docs/reusable-credentials-one-click-kyc) - [KYC Passport](/docs/data-flows/kyc-passport) - [Creating a Flow](./index.mdx) --- ## SPID / CIE The Zyphe platform supports the Italian Identity providers SPID and CIE (Electronic ID Card) as an identity verification method. The SPID/CIE verification can be added as a dedicated step in verification flow.
Add a Digital Identity step for SPID and CIE verification.
## How it works For more details, see the [SPID/CIE integration overview](/docs/integrations/italian-digital-identity-ecosystem-spid-and-cie). --- ## Wallet Verification The Wallet Verification step allows users to prove ownership of their cryptocurrency wallet addresses by connecting their wallet and signing a cryptographic message. This provides a secure and decentralized way to verify wallet ownership without exposing private keys. ## Supported Blockchains The wallet verification step supports the following blockchain networks: - **Ethereum** (Mainnet) - **Solana** (Mainnet) - **Ethereum Testnet** (Sepolia) - **Solana Testnet** (Devnet) ## How It Works The wallet verification process follows these steps: 1. **Wallet Connection**: The user connects their crypto wallet using a compatible wallet provider (e.g., MetaMask, Phantom, WalletConnect). 2. **Message Generation**: The system generates a unique cryptographic message that includes: - Domain information - Verification request details - Timestamp and expiration time (5 minutes) - Unique nonce for security 3. **Message Signing**: The user signs the generated message with their wallet's private key. 4. **Signature Verification**: The system verifies the signature cryptographically to confirm wallet ownership. 5. **Result Storage**: Upon successful verification, the wallet address, chain, signed message, and signature are securely stored. ## Customize Settings ### General Details - **Name:** The name of the flow step. It will be used to identify the step in the flow. - **Chains:** Select one or more blockchain networks that users can use for wallet verification. You can allow multiple chains to give users flexibility in choosing their preferred network. - **Success Button Label:** A custom label for the Continue button that is shown once the step is completed. ### Security Features The wallet verification implements several security measures: - **Message Expiration:** Generated messages expire after 5 minutes to prevent replay attacks. - **Rate Limiting:** Signature verification is rate-limited to 5 attempts per minute per verification request. - **Domain Verification:** The system validates that the message domain matches the expected domain. - **URI Validation:** The verification ensures the message URI corresponds to the correct verification request. - **Nonce Generation:** Each message includes a unique nonce to prevent message reuse. ## Technical Details The wallet verification step uses the **SIWX (Sign-In With X)** standard, which provides a blockchain-agnostic approach to wallet-based authentication. The implementation supports: - **Ethereum chains:** Uses SECP256K1 signature verification - **Solana chains:** Uses ED25519 signature verification ## Use Cases Wallet verification is particularly useful for: - **DeFi Platforms:** Verify user wallet ownership for decentralized finance applications - **NFT Marketplaces:** Confirm wallet ownership before allowing trading or minting - **Token Gating:** Verify wallet addresses to gate access to exclusive content or services - **Compliance:** Add wallet verification as part of a comprehensive KYC flow - **Airdrop Eligibility:** Verify wallet ownership for token distribution ## Configuration Example
Configure the Wallet Verification step and choose the supported chains.
## Webhook Payload When a wallet verification is completed, a webhook is triggered (if configured in the flow settings) with the following information: - Verification request details - Wallet address - Blockchain network used - Signed message - Signature - Verification timestamp ## Best Practices 1. **Multiple Chain Support:** Enable multiple blockchain networks to accommodate users with different wallet preferences. 2. **Clear Instructions:** Provide clear guidance to users about which wallets are supported for each chain. 3. **Error Handling:** Inform users if their signature verification fails and allow them to retry. 4. **Combine with Other Steps:** Consider combining wallet verification with document verification for enhanced KYC/KYB processes. ## Notes - The verification message must be signed within 5 minutes of generation. - Each wallet address can be verified once per verification request. - The signed message and signature are stored for audit purposes. - Testnet chains should only be used for development and testing purposes. --- ## Billing Use the Billing page to activate a plan, buy credit top-ups, choose how the organization is funded, manage billing details, set trial reminders, and monitor credit usage. ## Open Billing You can open billing in two ways: - Click **Open billing** from the trial banner on the dashboard. - Open **Settings** and switch to the **Billing** tab.
Open billing from the trial banner or from Settings.
## Update Your Plan In the **Billing** tab, the **Current Plan** card shows your active plan or trial state. Click **Update** or **Manage Billing** to change your subscription. The plan dialog shows the plans currently available for your organization.
Use the Billing tab to update your plan and review current plan status.
## Complete Checkout After choosing a plan, complete checkout through the Stripe-hosted checkout page. Select the currency, enter the billing email, and start the trial or subscription.
Complete checkout in Stripe to activate the selected plan.
## Billing Actions The Billing page also includes actions for managing billing information and reminders. - **Manage Billing:** opens the billing portal for subscription and payment management. - **Billing Contact:** lets you customize the billing contact information shown for your organization. - **Trial reminder:** sends a reminder before the trial expires.
Use billing actions to manage billing details, update the billing contact, and send trial reminders.
## Usage and Credits The **Usage This Period** section shows how credits are consumed during the current billing period. It breaks usage down by product, event count, credit cost, credits consumed, and overage. The top bar also shows the remaining credit balance, so you can monitor available credits while navigating the dashboard.
Track product usage, consumed credits, overage, and remaining credits from the Billing page.
## Credit Top-Ups The **Credit Top-Ups** card sells one-time credit packs. Pick a pack, complete the Stripe checkout, and the credits land on your balance as soon as the payment completes — no subscription change and no proration. Each pack shows how many credits it grants, its price, and its validity: - **Valid for N months** — unused credits from that pack expire at the end of the window. - **Never expires** — the credits stay on the balance until you spend them. Top-ups are additive: buying a pack never replaces the credits you already have, and it works alongside a subscription plan as well as on its own. Zyphe can also provision a bespoke pack visible only to your organization; ask support if the public packs do not fit your volume. A pack must be denominated in your organization's billing currency; one in another currency is refused at checkout, because the credits it granted would not be visible to the balance reconciliation. Top-ups are a production-only operation, so switch the dashboard out of sandbox to see the card. ## Funding Mode The **Funding Mode** card states how the organization pays for what it consumes, and holds the switch between the two self-serve modes. | Mode | How it funds usage | Where it comes from | | --------------------- | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | | **Plan** | A subscription plan grants credits at the start of every billing period | Reached by paying for a plan through checkout, not selectable here | | **Pay as you go** | Usage continues past zero credits and the overage is invoiced in arrears | Configured by the Zyphe team, contact support | | **Manual top-ups** | Funded by credit packs you buy yourself; usage **stops at zero** | The default, and one end of the switch on this card | | **Automatic top-ups** | Funded by credit packs that refill themselves from a card on file before the balance runs out | The other end of the switch, then configured on its own card | Two constraints apply to the switch: - **A subscription plan blocks it.** Automatic top-ups are only available without a plan: cancel the current one from the billing portal, or through support, first. A plan attached and awaiting payment blocks the change too, until that checkout is completed or cancelled. - **Pay as you go and automatic top-ups are mutually exclusive.** Turning automatic top-ups on clears any pay-as-you-go configuration and cancels the metered subscription behind it, for which Stripe issues a final invoice covering the usage recorded so far. ## Automatic Top-Ups Automatic top-ups (auto-recharge) charge a card on file for a fixed credit pack before your balance reaches zero, so verifications keep running without anyone watching the balance. ### Set it up 1. Switch the funding mode to **Automatic top-ups**. The **Automatic Top-Ups** card appears once the organization is in that mode. 2. **Add card.** This authorizes a payment method only — nothing is charged when you add it. 3. Configure the three settings and save: | Setting | What it does | | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Threshold** | A top-up starts once the balance drops to this many credits | | **Credit pack** | Which pack to charge. It must grant **more** credits than the threshold, otherwise the balance would sit at the threshold after every top-up and trigger the next one immediately | | **Daily limit** | Most top-ups allowed in any rolling 24 hours (1–50, 5 by default). A backstop against a runaway integration draining the card | Set the threshold high enough to cover what you consume while a card payment settles: the credits above the threshold are what keep serving traffic in the meantime. ### What it does not do **Zyphe never extends credit.** The balance never goes negative and there is no reserve: an organization that reaches zero stops there, exactly as it would without automatic top-ups. Continuity is bought with a generous threshold, not with an overdraft. If you want usage to continue past zero and be invoiced afterwards, that is pay-as-you-go instead. ### Monitoring it The card reports **Last top-up**, **Top-ups in the last 24h**, and **Next attempt**, plus an **Active** / **Paused** badge. Reaching the daily limit is not a failure: top-ups resume on their own as soon as the 24-hour window frees a slot. ### When a charge fails A failed charge is retried after **1 hour**, then **6 hours**, then **24 hours**. After **three consecutive failures** automatic top-ups are paused and the organization is emailed. Paused means paused — credits already on the balance are still spendable, and manual top-ups still work. | Pause reason | What happened | How to resume | | ------------------------------------------- | ------------------------------------------------------------ | ---------------------------------------------------------- | | **Automatic top-ups are paused** | The card was declined several times in a row | Add a working card, or buy a top-up by hand | | **Your bank needs to confirm this payment** | The card needs confirmation that cannot be given off-session | Pay the invoice linked on the card to complete that top-up | | **No usable card on file** | The card was expired or unusable and has been removed | Add a card | | **A top-up charge was disputed** | A charge was disputed; the card has been removed | Contact support | Turning automatic top-ups off returns the organization to manual top-ups and clears the threshold, pack, and daily limit. Credits already purchased are unaffected. ## Sandbox Usage Sandbox and production share **one credit balance**. A sandbox verification costs the same credits as the equivalent production verification, with one exception: runs whose identity belongs to your own organization (a team member, or any address on a member's email domain) are recorded at zero credits. The usage table follows the dashboard's sandbox toggle, so switch environments to see the other side's counters. The remaining balance in the top bar is the same number in both. Because the balance is shared, sandbox consumption counts towards the [automatic top-up](#automatic-top-ups) threshold and can trigger a real card charge. Full rules, including how the trial period differs: [Sandbox mode → Credits and billing in sandbox](/docs/guides/sandbox-mode#credits-and-billing-in-sandbox). --- ## Dashboard ### Overview The Zyphe Dashboard is a business-to-business (B2B) plug-and-play solution that facilitates the verification of customer identity efficiently and accurately. Designed to offer a comprehensive suite of tools for conducting and managing KYC and KYB processes. ### Features - **Verification Flows Overview**: Provides a quick glance at all verification requests that have been performed along with the status for each step of the verification flow. - **Verification filters**: It is possible to filter verification attempts by email and/or any custom parameters that has been passed during the verification session. - **Document Verification**: The system supports verification of official documents, including ID cards, driver's licenses and passports with details such as document type and creation dates. - **Biometric Analysis**: Incorporates biometric verification scores, including facial recognition and life proof scores, to ensure the authenticity of the individual. - **Result Management**: Presents the verification status (e.g., "success") and allows for viewing detailed results, enhancing decision-making processes. ### Security & Compliance Our KYC Dashboard adheres to stringent security protocols, ensuring that all data is encrypted and handled in full compliance with GDPR and other relevant privacy laws. Regular audits and updates ensure that the dashboard remains compliant with the latest regulatory requirements. ### Access the Dashboard Sign up for an account on the Zyphe Dashboard. -- OR -- Reach out to our support team to obtain your credentials. With your credentials in hand, you can log in to the dashboard. --- ## Manage Users Use the Users and Invites pages to add teammates to your organization, assign roles, and manage flow access for partner users. ## Invite a New User Open the **Invites** page from the sidebar to invite users to your organization.
Use the Invites page to send new organization invitations.
Click **Invite Users** to open the invitation dialog.
The Invites page lists pending invitations and provides the Invite Users action.
Add one or more email addresses, then assign a role to each invitee.
Add email addresses before selecting roles and sending invitations.
Review the permission summary before sending the invitations. The summary shows the effective permissions for each selected role.
Use the role permission summary to confirm what each invited user can access.
Pending invitations can be resent or deleted from the action menu.
Use invite actions to resend a pending invite or delete it.
## Role Permissions Zyphe roles are permission bundles. The main organization roles are: | Role | Description | Main permissions | | --------------- | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Admin** | Full access to all organization features | Manage flows, flow results, flow access, users, API keys, bots, risk tags, partner invites, forms, organization settings, billing, webhooks, AML cases, KYB cases, and the KYB compliance policy. | | **Operator** | Operational access to results and cases | Manual review, flow result management, advanced logs, AML case management, and KYB case review. | | **AML Officer** | Access to AML monitoring and case management | Flow results, AML case management, escalated AML cases, KYB case review, and the KYB compliance policy. | | **Developer** | Access to organization development features | Manage flows, API keys, bots, webhook endpoints, and webhook secrets. | | **Partner** | Access to shared flows only | View results for explicitly shared flows and manage them when write access is enabled. | :::info[Sandbox permissions] In sandbox, Admin and Operator users can also delete flow steps. Admin, Operator and Developer users can delete flow results and, optionally, the test identity behind them; see [Deleting sandbox results](/docs/guides/sandbox-mode#deleting-sandbox-results). This is intentionally limited to sandbox workflows. ::: ## Manage Partner Flow Access Open the **Users** page to review organization users. If a user has the **Partner** role, you can manage which flows they can access.
Partner users expose a Manage Flow Access action from the Users table.
Flow access is granted per flow. You can grant access to specific flows and manage whether the partner has read-only or write access.
Grant partner users access to specific flows and enable write access when needed.
Partner flow permissions work as follows: - **View access:** lets the partner user view results for the shared flow. - **Write access:** lets the partner user manage results for the shared flow when write access is enabled and has not been revoked. - **Revoked write access:** removes write permissions while preserving the existing shared-flow relationship. --- ## Passkey Authentication Zyphe provides full FIDO2/WebAuthn support for passwordless authentication, allowing users to register and authenticate using biometric sensors, security keys, or mobile devices. ## How It Works ### Registration Flow 1. **Initiation:** The client calls the registration start endpoint to receive a cryptographic challenge. This requires an active JWT session. 2. **Credential Creation:** The user's device generates a new passkey and signs the challenge. 3. **Completion:** The client submits the signed credential to the registration endpoint. The system verifies the signature and stores the public key. ### Authentication Flow 1. **Initiation:** The client requests an authentication challenge by providing either a specific credential ID or the user's email. 2. **Assertion:** The user's device signs the challenge using the previously registered passkey. 3. **Completion:** The client submits the authentication response. Upon successful verification, the system returns a session token or verification request ID. ## API Endpoints | Method | Path | Description | | :----- | :--------------------------------- | :---------------------------------------------------------------------------------------------------------- | | GET | `/auth/register-passkey/start` | Initiates passkey registration. Returns a challenge. Requires JWT authentication. | | POST | `/auth/register-passkey` | Completes registration with the signed credential. Accepts `registrationResponse` and optional `prfSalt`. | | POST | `/auth/authenticate-passkey/start` | Initiates authentication. Accepts optional `credentialId` or `email`. Returns challenge and options. | | POST | `/auth/authenticate-passkey` | Completes authentication. Accepts `authenticationResponse` and `tokenType` (Bearer or VerificationRequest). | ## Security Features - **Challenge Expiry:** Registration and authentication states are cached for 300 seconds (5 minutes). Challenges must be completed within this window. - **PRF Support:** Supports the Pseudo Random Function (PRF) extension for WebAuthn, enabling client-side vault encryption. - **Vault Integration:** Upon registration, the system automatically creates or unlocks the user's secure vault using a passkey-derived key. - **Token Types:** Supports `Bearer` tokens for dashboard access (invalidates cache) and `VerificationRequest` tokens for identity verification flows (retains cache for vault access). ## Related Documentation - [Dashboard](/docs/guides/dashboard) - [SDK Integration](/docs/guides/sdk) --- ## Theming You can match the verification flow to your brand. There are two layers, and they compose: 1. **Dashboard themes**: configured per organization in the Zyphe dashboard and saved. A theme defines light and dark color sets, a shared border radius, an optional custom font, and a logo. Each flow either selects a theme or uses the organization default. 2. **SDK overrides**: colors and border radius passed when you build a verification session URL. These override the configured theme **for that session only**, without changing anything saved in the dashboard. Use the dashboard for your standing brand, and SDK overrides when a single integration needs different colors (for example, embedding the flow inside a host app that already has its own palette). ## Managing themes in the dashboard Themes live in the dashboard under **Settings → Themes**. From the organization sidebar, open **Settings**, then select the **Themes** tab (you need the _Manage organization_ permission to see it). This page lists your themes and lets you create, edit, delete, and set a default. ### Sandbox and production are separate Themes are scoped to the environment you are in: your **sandbox** themes and your **production** themes are two independent lists. Switching the dashboard between sandbox and production shows a different set of themes, and editing a theme in one environment never affects the other. To avoid rebuilding a theme twice, design it in one environment and then copy it across. On any theme row, use the copy action, labelled **Copy to production** when you are in sandbox (and **Copy to sandbox** when you are in production). This duplicates the theme into the other environment as a new theme (`{name} (copy)`), which you can then rename or set as the default there. ### Default theme and per-flow overrides Every organization has one **default** theme, marked _Default_ in the list. Any flow that hasn't been given a specific theme renders with the default. To change which theme is the default, open the theme's actions menu and choose **Set as default**. To override the theme for a single flow: 1. Go to the **Flows** page and open the flow's **Flow configuration** dialog. 2. In the **Theme** dropdown, pick the theme this flow should use. 3. **Save**. A flow keeps inheriting the organization default until you explicitly pick a theme here; once set, that flow always renders with the chosen theme (in the matching environment). Because theme selection is per environment, a flow resolves its theme from the sandbox or production theme list depending on where the session runs. ## Theme tokens A theme is built from a small set of tokens, each available for **light** and **dark** mode: | Token | What it controls | | ------------ | --------------------------------------------------------------- | | `background` | The page background behind the flow card | | `accent` | The primary action color, buttons, icons, links, and highlights | | `card` | The surface the flow card is drawn on | Plus mode-agnostic tokens: | Token | What it controls | | -------------- | ------------------------------------------------------------ | | `borderRadius` | Shared corner radius applied to cards, buttons, and inputs | | `font` | A self-hosted custom font (`.woff2`), **dashboard only** | | `logo` | A per-mode logo shown in the flow header, **dashboard only** | Text colors are derived automatically for readability: the label color on an `accent` button and the text on a `card` are computed to contrast with their background, so you only set the surface colors. > The custom **font** and **logo** can only be set in the dashboard, they are not overridable through the SDK. ## SDK overrides Pass any of these on the `opts` object of `constructVerificationSessionUrl` (and `initializeZypheFlow` in the browser SDK). All are optional; anything you omit falls back to the flow's configured theme. | Option | Maps to | Description | | --------------------- | ------------------ | --------------------------------------- | | `backgroundColor` | light `background` | Page background (light mode) | | `accentColor` | light `accent` | Buttons, icons, highlights (light mode) | | `cardColor` | light `card` | Card surface (light mode) | | `darkBackgroundColor` | dark `background` | Page background (dark mode) | | `darkAccentColor` | dark `accent` | Buttons, icons, highlights (dark mode) | | `darkCardColor` | dark `card` | Card surface (dark mode) | | `borderRadius` | `borderRadius` | Shared radius, e.g. `"12px"` | Colors accept any CSS color value; we recommend hex codes. The dark-mode values apply when the flow renders in dark mode. ### Example ```ts const url = constructVerificationSessionUrl({ flowParams: { flowId: '...', email: 'user@example.com', isSandbox: false, }, verificationSession: response.data, // from createVerificationSession opts: { apiKey: '', environment: 'production', // Light mode backgroundColor: '#ffffff', accentColor: '#155dfb', cardColor: '#ffffff', // Dark mode darkBackgroundColor: '#16181d', darkAccentColor: '#4f8bff', darkCardColor: '#1f2229', // Shared borderRadius: '12px', }, }) ``` ## Deprecated options Earlier SDK versions exposed `primaryColor` and `secondaryColor`. They still work for backwards compatibility but are deprecated, prefer the named options above: | Deprecated | Use instead | Notes | | ---------------- | ----------------- | -------------------------------------- | | `primaryColor` | `backgroundColor` | Historically controlled the background | | `secondaryColor` | `accentColor` | Historically controlled the accent | If both a deprecated option and its replacement are provided, the named option wins. ## Building the URL manually If you are not using the SDK, append the equivalent query parameters to the flow URL yourself. Each SDK option maps to a `zyphe`-prefixed parameter: | SDK option | URL parameter | | ------------------------------- | -------------------------- | | `backgroundColor` | `zypheBackgroundColor` | | `accentColor` | `zypheAccentColor` | | `cardColor` | `zypheCardColor` | | `darkBackgroundColor` | `zypheDarkBackgroundColor` | | `darkAccentColor` | `zypheDarkAccentColor` | | `darkCardColor` | `zypheDarkCardColor` | | `borderRadius` | `zypheBorderRadius` | | `primaryColor` _(deprecated)_ | `zyphePrimaryColor` | | `secondaryColor` _(deprecated)_ | `zypheSecondaryColor` | Color values must be URL-encoded (a `#` becomes `%23`). ## Forcing light or dark mode The color overrides above define _what_ the light and dark palettes look like. A separate parameter controls _which_ mode the flow renders in. Append `zypheTheme` to the flow URL to force the color mode for that session: | Value | Effect | | -------- | ----------------------------------------------------------- | | `light` | Always render the flow in light mode | | `dark` | Always render the flow in dark mode | | `system` | Follow the end user's operating-system / browser preference | For example, `…&zypheTheme=dark` pins the session to dark mode regardless of the user's system setting. When `zypheTheme` is omitted, the flow follows the system preference. This parameter is independent of the color overrides, you can combine it with them (for instance, force `dark` and supply your `darkAccentColor`). ## Accessibility The `accent` color is rendered as a solid element (button fills) on top of `card`, so it should stay visually distinct from the card surface, the dashboard theme editor warns when the contrast falls below the WCAG 1.4.11 non-text threshold (3:1). When supplying colors through the SDK, pick an `accent` that stands out against your `card`, and a `card`/`background` that the auto-derived text color can sit on comfortably. --- ## KYB Agentic Review Engine The KYB agent that reviews KYB cases runs on a **multi-role agentic review engine**. Rather than a single AI loop that both reasons and acts, the engine separates the work into distinct phases: three analytic roles assess the case, a deterministic (non-AI) guard decides whether the case may be approved, and a tool-constrained actuator carries out exactly one outcome. Every decision is recorded against a versioned policy and written to the audit trail. This page describes how the engine works and how the [KYB Agent Mode](./index.mdx#kyb-agent-mode) you pick on the flow step controls it. :::info You do not configure the review engine directly. It is driven by the **KYB Agent Mode** on the KYB step (`Disabled`, `Suggest`, or `Auto-pilot`). This page describes what happens behind that setting. ::: ## How a review runs When a KYB case is ready for review, the engine builds a **case file** from the case and any open clarifications, then runs it through the pipeline below. Each phase has a single responsibility, and the analytic phase cannot mutate any record. ```mermaid flowchart TD A["KYB caseCase file: case + open clarifications"] --> B["Prosecutorrisk findings: LLM, structured output"] B --> C["Defendermitigations: LLM, skipped when zero findings"] C --> D["Judgeverdict + rationale: LLM"] D --> E["Deterministic guardhard veto: Approve + Deny ⇒ Escalate(Rust, no LLM)"] E --> F["ActuatorONE permitted action: allowlist narrowed toJudge's decision ∩ Agent Mode gate"] F --> G["KYB_AGENT_REVIEWED auditfindings count · verdict · guard outcome ·enacted decision · policy version · actuator status"] ``` ### The three analytic roles The analytic phase runs three roles in sequence: one raises concerns, one answers them, and a third weighs the two. None of them can change the stored record. | Role | Responsibility | Notes | | -------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------- | | **Prosecutor** | Produces structured **risk findings** across the case file. | LLM with structured (schema-constrained) output. | | **Defender** | Produces **mitigations** that answer the findings. | LLM. **Skipped** when the Prosecutor returns zero findings. | | **Judge** | Weighs findings against mitigations and issues a **verdict with a rationale**. | LLM. Its decision is one of `Approve`, `Escalate`, or `Deny`. | Each role uses a provider-agnostic, strict-mode structured-output schema and is driven by a versioned prompt (currently `kyb-policy-2026.06.0`). ### The deterministic guard The Judge's verdict does not decide approval on its own. It is checked by a deterministic guard, written in Rust and running no LLM, that has the final say on whether the case may be approved. Approval requires all of: - **PEP screening succeeded.** - **Every document-backed field cross-check matched.** - **No unresolved clarifications remain.** If any condition fails, the guard vetoes the approval. An `Approve` verdict that coincides with a `Deny` signal is forced to **Escalate**. An LLM verdict cannot override the guard. ### The actuator The actuator runs only after the guard, and it can take **only one action**. Its tool allowlist is the **intersection of the Judge's decision and the Agent Mode gate**: - For an `Escalate` verdict, the `approve_kyb_result` tool is not in the allowlist and cannot be called. - An `Approve` verdict under **Suggest** mode is recorded but not enacted. - The mutating tools are idempotent, so a retry re-runs the same stateless evaluation instead of producing a second, independent action. ## How Agent Mode controls the engine The [KYB Agent Mode](./index.mdx#kyb-agent-mode) on the flow step determines how far the actuator is allowed to go: | Mode | Engine behavior | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Disabled** | The pipeline does not run. Fields still receive a match type, but there is no AI reasoning, verdict, or suggested value, reviewers decide everything by hand. | | **Suggest** | The full pipeline runs. Clarification requests and escalations are enacted; an `Approve` verdict is recorded as a suggestion only, for a reviewer to follow or not. | | **Auto-pilot** | The actuator may also approve. An `Approve` verdict is enacted only when the deterministic guard passes and the case's decision rules allow it (readiness, exceptions, and the approval matrix); anything else is escalated to a reviewer. | ## Guarantees The engine enforces the following, independent of the LLM's output: - **The guard is final.** Approval requires PEP success, every document-backed field cross-check matched, and no unresolved clarifications. An LLM verdict cannot override it. - **The allowlist is `decision ∩ mode`.** The actuator for an `Escalate` verdict cannot call `approve_kyb_result`, and `Approve` under `Suggest` does not run the actuator at all. - **The agent is never the second signature.** Where the approval matrix requires two signatures, the agent's approval is only a proposal; a person confirms it. - **The guard runs again server-side.** `approve_kyb_result` re-runs the strict guard when it is called; the engine-side guard passing is not sufficient on its own. - **Retries are safe.** All mutating actions are idempotent. A retryable actuator failure re-runs the stateless evaluation, and the audit entry flags it (`actuator_will_retry`) so a retry reads as another attempt rather than an independent review. - **The engine can be switched off.** A hot-reloadable flag, changed from the admin runtime-config endpoint without a redeploy, stops dispatch from claiming candidates and releases in-flight jobs, so cases stay with your reviewers. - **Clarifications round-trip.** The guard distinguishes "awaiting the client" (a veto) from "submitted and cross-check matched." Once a clarification is submitted and matches, the actuator reviews the fields, closes the request, and may then approve. ## Audit trail Every run writes a **`KYB_AGENT_REVIEWED`** entry to the case's [audit trace](./reviewing-cases.mdx#audit-trace). The entry records both the model's verdict and the action the system took: | Field | Meaning | | -------------------- | ------------------------------------------------------------------------------- | | **Findings count** | How many risk findings the Prosecutor raised. | | **Judge verdict** | `Approve`, `Escalate`, or `Deny` with the Judge's rationale. | | **Guard outcome** | Whether the deterministic guard passed or vetoed, and why. | | **Enacted decision** | The action the actuator took (or none, under Suggest). | | **Policy version** | The versioned policy the decision was made under (e.g. `kyb-policy-2026.06.0`). | | **Actuator status** | Success, or a retryable failure flagged with `actuator_will_retry`. | ## Related - [AML Agentic Review Engine](/docs/aml/agentic-review-engine), the parallel multi-role engine for sanctions, PEP, and adverse-media moderation --- ## Compliance policy The **compliance policy** holds the rules every KYB decision in your organization follows: how screening matches are treated, which fallbacks you accept, who may approve at each risk rating, whether a second signature is needed, and how decisions are reviewed afterwards. The dashboard, the [Node SDK](/docs/guides/sdk/node#decide-a-case), and the KYB agent all decide under the same policy. The policy lives under **Settings → Compliance policy** and can be edited by users with the `ORG_ADMIN` or `AML_OFFICER` role.
From your written procedure to a policy in force: procedure, review, draft, in force.
## Versions The policy is a series of **numbered versions**. You edit a **draft**; **publishing** it gives it a version number and freezes it. A published version is then put **in force**: first in the sandbox, then in production. Production only accepts a version that has been in force in the sandbox, so every rule change can be tried before it applies to real companies. Every decision records the policy version it was taken under, and a case's coverage is read against the version in force. ## Written procedure You can start the draft from your own written procedure (your KYB SOP) instead of from scratch: 1. **Upload** the procedure as a PDF, plain text, or Markdown file, up to 20 MiB. Scanned PDFs are read with text recognition (up to 30 pages). 2. **Review** what was read. Each clause comes with the verbatim quote it was read from, and is classified as: - **Enforced:** tied to a setting of the policy, for example a screening rule or an approval-matrix row; - **Guidance:** kept as instructions for the reviewers and the KYB agent; - **Out of reach:** something the platform cannot enforce. For each clause, **accept** it, **edit** it, or **drop** it. A clause whose quote could not be found in the document raises an **open question** on that clause. 3. The accepted clauses become the **draft**. A draft that still has open questions cannot be published. The uploaded file is not kept: only its fingerprint, the clauses, and their quotes are stored, and the quotes are shown only to `ORG_ADMIN` and `AML_OFFICER` users. Clauses reach the KYB agent and the case planner as data: they can make a case stricter, never relax a platform rule. ## What the draft contains ### Screening For **PEP matches** and **Adverse media matches**, choose: - **Review** (the default): a match holds the subject until a reviewer rules it a false positive. A confirmed match can still be approved, by the roles your approval matrix names for approvals "with a confirmed screening match". - **Reject:** a match a reviewer rules a **true positive** leaves rejection as the only decision open; no exception can clear it. A false positive releases the subject exactly as under Review, and a match nobody has ruled on still holds. - **Ignore:** matches are listed and marked as ignored, need no verdict, and never hold the case. Sanctions matches are always reviewed. For PEPs, keep in mind that some regulators (for example in the UK) tell firms not to decline a customer merely for being a PEP; Review is the setting that fits that guidance. ### Admitted fallbacks A fallback is a weaker way of covering a requirement, for example screening an owner **by name only** because no email was collected, so they could not complete KYC. A fallback your policy admits counts as covered; any other fallback blocks approval until a reviewer records an [exception](./reviewing-cases.mdx#exceptions) for it. Organizations that existed before the compliance policy started with name-only screening admitted. New organizations admit no fallback until they choose to. ### Approval matrix The approval matrix says, for each **rating** (Low, Medium, High, Critical) and each kind of approval, **who may decide** and whether a **second signature** is required. The kinds of approval are: - **Clean:** nothing is excepted and no confirmed match stands; - **Resting on an exception:** the approval relies on a recorded exception; - **With a confirmed screening match:** a true positive stands in a category your policy reviews.
The approval matrix: who may decide each rating, and when a second signature is needed.
- A row with no role selected lets any role that works cases decide. - With no rows at all, anyone who may work cases decides alone. - A company without a rating uses the strictest row. A rejection uses the **Clean** row of the company's rating. - With **Second signature** on, the first decision becomes a proposal that a different person confirms. See [Two signatures](./reviewing-cases.mdx#two-signatures). - Decisions taken with an API key act with the `ORG_ADMIN` role: they are refused where the row does not name Admin, and they can be the first signature, never the second. The policy also says whether a rating can be **lowered** by hand. Raising it is always allowed. ### Quality-review sampling The share of decisions drawn for a [quality review](./reviewing-cases.mdx#quality-reviews). A drawn decision is reviewed by someone who did not sign it; a disagreement reopens the case. ### Approval validity How long an approval stays valid before the company is [reviewed again](./reviewing-cases.mdx#periodic-re-review), and how many re-reviews can open per day. ## KYB orchestration rules **KYB orchestration rules** (on the same page) let your organization add checks to the cases that match a condition, for example requiring an extra document for a given country or legal form. A flow uses them when its **Case planner** is set to **Organization's rules**. Each rule's suggestions appear on the case as [proposed changes](./reviewing-cases.mdx#proposed-changes) for a reviewer to accept. Rules can be created, edited, enabled, and disabled at any time. ## Related - [Reviewing KYB cases](./reviewing-cases.mdx): exceptions, decisions, and quality reviews in practice. - [KYB Overview](./index.mdx): the case statuses and flow setup. - [Manage Users](/docs/guides/manage-users): the roles and their permissions. --- ## Country coverage Zyphe verifies businesses against official company registers in **49 countries and territories** and **all 50 US states plus Washington DC**. This page lists every covered jurisdiction and what the register returns for it. Register coverage drives three KYB capabilities: - **Register cross-check:** the KYB AI agent compares the submitted business information and documents against the register record. Every jurisdiction listed below supports it. - **Prefill from official registers:** the widget's company search, which prefills the business-information form. See [Prefilling from official registers](./steps-and-configuration.md#prefilling-from-official-registers). - **[Ownership discovery](./ownership-discovery.md):** directors, shareholders, and UBOs read from the register instead of being declared by the applicant. For a jurisdiction that is not listed, the KYB flow still runs: the applicant declares the company details, UBOs, and directors, and the uploaded documents are verified, but there is no register record to cross-check against. ## Reading the tables Every listed jurisdiction returns the core **company record** used by the register cross-check. The columns show what else the register provides: - **Directors and officers:** legal representatives and other key persons, used for director suggestions and director discovery. - **Shareholders:** the direct ownership of the company, the input to multi-tier ownership traversal. - **UBOs:** ultimate beneficial owners as published in the jurisdiction's beneficial-ownership register. A dash means the register does not provide that data for the jurisdiction. The KYB flow then falls back to the applicant's declaration for it. ¹ Retrieved from the official register on request rather than in real time: typically **1–3 business days**, and **a few business days** for China. Ownership discovery reports these nodes with `expectedLatency: manual`. ## Europe | Jurisdiction | Code | Directors and officers | Shareholders | UBOs | | ---------------------- | ---- | ---------------------- | ------------ | ---- | | Austria | `AT` | ✓ | ✓ | — | | Belgium | `BE` | ✓ | ✓ | ✓ | | Bosnia and Herzegovina | `BA` | ✓ | ✓ | ✓ | | Bulgaria | `BG` | ✓ | ✓ | ✓ | | Croatia | `HR` | ✓ | ✓ | ✓ ¹ | | Cyprus | `CY` | ✓ | ✓ | ✓ ¹ | | Czech Republic | `CZ` | ✓ | ✓ | — | | Denmark | `DK` | ✓ | ✓ | ✓ | | Estonia | `EE` | ✓ | ✓ | ✓ | | Finland | `FI` | ✓ | — | ✓ | | France | `FR` | ✓ | ✓ | ✓ | | Germany | `DE` | ✓ | ✓ | ✓ ¹ | | Greece | `GR` | ✓ | ✓ | — | | Hungary | `HU` | ✓ | ✓ | — | | Iceland | `IS` | ✓ | ✓ | ✓ | | Ireland | `IE` | ✓ | ✓ | — | | Italy | `IT` | ✓ | ✓ | — | | Latvia | `LV` | ✓ | ✓ | ✓ | | Liechtenstein | `LI` | ✓ | ✓ | — | | Lithuania | `LT` | — | — | — | | Luxembourg | `LU` | ✓ | ✓ | — | | Malta | `MT` | ✓ | ✓ | — | | Moldova | `MD` | ✓ | ✓ | — | | Monaco | `MC` | ✓ | — | — | | Netherlands | `NL` | ✓ | ✓ | — | | Norway | `NO` | ✓ | — | — | | Poland | `PL` | ✓ | ✓ | ✓ | | Portugal | `PT` | ✓ | ✓ | ✓ ¹ | | Romania | `RO` | ✓ | ✓ | — | | Russia | `RU` | ✓ | ✓ | — | | Serbia | `RS` | ✓ | ✓ | ✓ ¹ | | Slovakia | `SK` | ✓ | ✓ | ✓ ¹ | | Slovenia | `SI` | ✓ | ✓ | ✓ ¹ | | Spain | `ES` | ✓ | ✓ | — | | Sweden | `SE` | ✓ | ✓ | ✓ | | Switzerland | `CH` | ✓ | — | — | | Ukraine | `UA` | ✓ | ✓ | ✓ | | United Kingdom | `GB` | ✓ | ✓ | ✓ | ## Offshore financial centres and Crown Dependencies | Jurisdiction | Code | Directors and officers | Shareholders | UBOs | | ---------------------- | ---- | ---------------------- | ------------ | ---- | | Antigua and Barbuda | `AG` | — | — | — | | British Virgin Islands | `VG` | — | — | — | | Cayman Islands | `KY` | ✓ | — | — | | Guernsey | `GG` | ✓ | — | — | | Isle of Man | `IM` | — | — | — | | Jersey | `JE` | ✓ | ✓ | — | | Marshall Islands | `MH` | ✓ | — | — | | Mauritius | `MU` | ✓ | ✓ | — | ## Asia | Jurisdiction | Code | Directors and officers | Shareholders | UBOs | | ------------ | ---- | ---------------------- | ------------ | ---- | | China | `CN` | ✓ | ✓ ¹ | ✓ ¹ | | Hong Kong | `HK` | ✓ | ✓ | — | | Singapore | `SG` | ✓ | ✓ | — | ## United States Coverage is per state: every state's own business register is covered. | Jurisdiction | Code | Directors and officers | Shareholders | UBOs | | -------------- | ------- | ---------------------- | ------------ | ---- | | Alabama | `US-AL` | ✓ | — | — | | Alaska | `US-AK` | ✓ | ✓ | — | | Arizona | `US-AZ` | ✓ | — | — | | Arkansas | `US-AR` | ✓ | — | — | | California | `US-CA` | ✓ | — | — | | Colorado | `US-CO` | ✓ | — | — | | Connecticut | `US-CT` | ✓ | — | — | | Delaware | `US-DE` | ✓ | — | — | | Florida | `US-FL` | ✓ | — | — | | Georgia | `US-GA` | ✓ | — | — | | Hawaii | `US-HI` | ✓ | ✓ | — | | Idaho | `US-ID` | ✓ | — | — | | Illinois | `US-IL` | ✓ | — | — | | Indiana | `US-IN` | ✓ | — | — | | Iowa | `US-IA` | ✓ | — | — | | Kansas | `US-KS` | ✓ | — | — | | Kentucky | `US-KY` | ✓ | — | — | | Louisiana | `US-LA` | ✓ | ✓ | — | | Maine | `US-ME` | ✓ | — | — | | Maryland | `US-MD` | — | — | — | | Massachusetts | `US-MA` | ✓ | — | — | | Michigan | `US-MI` | ✓ | — | — | | Minnesota | `US-MN` | ✓ | — | — | | Mississippi | `US-MS` | ✓ | — | — | | Missouri | `US-MO` | ✓ | — | — | | Montana | `US-MT` | ✓ | — | — | | Nebraska | `US-NE` | ✓ | — | — | | Nevada | `US-NV` | ✓ | — | — | | New Hampshire | `US-NH` | ✓ | — | — | | New Jersey | `US-NJ` | ✓ | — | — | | New Mexico | `US-NM` | ✓ | — | — | | New York | `US-NY` | ✓ | — | — | | North Carolina | `US-NC` | ✓ | — | — | | North Dakota | `US-ND` | ✓ | — | — | | Ohio | `US-OH` | ✓ | — | — | | Oklahoma | `US-OK` | ✓ | — | — | | Oregon | `US-OR` | ✓ | — | — | | Pennsylvania | `US-PA` | ✓ | — | — | | Rhode Island | `US-RI` | ✓ | — | — | | South Carolina | `US-SC` | ✓ | — | — | | South Dakota | `US-SD` | ✓ | — | — | | Tennessee | `US-TN` | ✓ | — | — | | Texas | `US-TX` | ✓ | — | — | | Utah | `US-UT` | ✓ | — | — | | Vermont | `US-VT` | ✓ | ✓ | — | | Virginia | `US-VA` | ✓ | — | — | | Washington | `US-WA` | ✓ | — | — | | Washington DC | `US-DC` | ✓ | — | — | | West Virginia | `US-WV` | ✓ | — | — | | Wisconsin | `US-WI` | ✓ | — | — | | Wyoming | `US-WY` | ✓ | — | — | :::info[Coverage evolves] Coverage is extended over time, and ownership discovery also has to be enabled for your deployment. Ask Zyphe support to confirm coverage for a jurisdiction before you rely on it in production. ::: --- ## KYB dashboard migration guide KYB results are now worked as **KYB cases**. This page is for the people who review KYB in the dashboard: what moved, what behaves differently, and what to set up before relying on the new pages. Existing results were migrated: each one is now a case with the same ID, and its history is kept. If you integrate through the API or the SDK, see the [SDK migration guide](/docs/guides/sdk/migration-guide) as well. ## What changed at a glance | Before | Now | | ----------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **KYB Results** was a table of every result | **Cases to work on** groups open cases by what they need: ready for review, action required, waiting for input, processing. **Show all results** keeps the full table. | | Statuses `ACQUIRING`, `ENRICHING`, `PENDING_MODERATION`, `REVIEW_REQUIRED`, `SUCCESS`, `FAILED` | Case statuses `OPEN`, `PROCESSING`, `WAITING_INPUT`, `ACTION_REQUIRED`, `READY_FOR_REVIEW`, `APPROVED`, `REJECTED`, `CANCELLED`. See [How a KYB case works](./index.mdx#how-a-kyb-case-works). | | Clean companies could be approved automatically | Nobody approves automatically. A clean company reaches **Ready for review** and a reviewer (or the KYB agent in Auto-pilot) decides it. | | Approving could acknowledge open barriers | Each blocker is covered by an **exception** with a reason and an expiry. See [Exceptions](./reviewing-cases.mdx#exceptions). | | A rejection could be recorded without a reason | Every rejection needs a reason, and can carry a **reason code**. | | Anyone who could moderate decided alone | Your **approval matrix** says who may decide at each rating, and when a second signature is needed. See [Approval matrix](./compliance-policy.md#approval-matrix). | | A decision was the end of the result | A decision is never rewritten, but the case can be **reopened** by a resubmission, a quality review, or a periodic re-review. | | Assignment was per result | Assignment is per **company**, and applies to every case of that company. | | The activity log and the agent activity were separate lists | **Case activity** shows what the case is waiting for, the steps and runs, coverage, exceptions, decisions, and agent reviews; **Audit trace** keeps the full event log. | | Screening matches | A **false positive** needs a discriminator (date of birth, nationality, ID number, address, gender, or another reason). See [Company screening](./reviewing-cases.mdx#company-screening). | | Documents were configured with fixed built-in slots | Each country has a **document catalog**; you mark documents required, optional, on demand, or off, and add your own. See [Required documents](./index.mdx#4-required-documents). | ## New pages - **[Compliance policy](./compliance-policy.md)** (Settings → Compliance policy): screening rules, admitted fallbacks, the approval matrix, quality-review sampling, and approval validity. Versioned: publish a draft, put it in force in the sandbox, then in production. - **[Quality reviews](./reviewing-cases.mdx#quality-reviews)**: decisions drawn for a second look. - **[Metrics](./reviewing-cases.mdx#metrics)**: how your KYB decisions were taken over a period. ## Who can do what KYB cases can now be worked by `ORG_OPERATOR` and `AML_OFFICER` users as well as `ORG_ADMIN`. The compliance policy and the KYB orchestration rules are edited by `ORG_ADMIN` and `AML_OFFICER`. What each person may **decide** is set by your approval matrix. ## Before you go live 1. **Review your compliance policy.** Organizations that existed before this release start with a first version in force, which admits name-only screening as a fallback. Check it against your procedure (or upload the procedure and let Zyphe read it), then publish your changes and put them in force in the sandbox before production. 2. **Decide who signs.** Add approval-matrix rows for the ratings where you want specific roles or a second signature. 3. **Check your webhooks.** `verification.kyb.review` is now also sent when an **approved** company is reopened, and every decision sends exactly one webhook, including decisions taken from the dashboard. See [Webhook lifecycle](./index.mdx#webhook-lifecycle). 4. **Check the case planner of each KYB flow.** Flows keep the fixed order of checks unless you choose your organization's rules or AI proposals on the Know Your Business step. ## Related - [KYB Overview](./index.mdx) - [Reviewing KYB cases](./reviewing-cases.mdx) - [Compliance policy](./compliance-policy.md) --- ## KYB Overview KYB verifies **businesses**, where KYC verifies individuals. A KYB flow collects a company's business information and documents, captures its **Ultimate Beneficial Owners (UBOs)** and, optionally, its **directors**, and cross-checks what the applicant declared against the documents and the official company register. Owners and directors are verified through a linked KYC flow or screened by name, the company and its people are screened for PEP, sanctions, and adverse media, and a reviewer takes the final decision. Every KYB submission is handled as a **KYB case**: one record that tracks what has been checked, what is still owed and by whom, the risk rating, and the decision. The case keeps the same ID as the KYB result, for its whole life. Short product explainer: [How KYB works](/docs/how-it-works/kyb). Register cross-check, UBO unwrapping, and agent modes in the wider control map: [Antifraud controls](/docs/how-it-works/antifraud-controls). :::info[KYB result delivery] KYB outcomes are delivered to your organization's [webhook endpoints](/docs/guides/webhook/endpoints). On current payloads the case is under `data.kybCase` (status, due-diligence level, and decision); the full KYB result is still under `data.kyb`, which is deprecated. See [Webhook Payload](/docs/guides/webhook/webhook-payload#kyb-datakyb). ::: :::tip[Moving from the previous KYB results page?] The dashboard, the decision rules, and the statuses changed. [KYB dashboard migration guide](./dashboard-migration.md) lists what moved where. For API integrations, see the [SDK migration guide](/docs/guides/sdk/migration-guide). ::: ## How a KYB case works A case moves through these statuses: | Status | What it means | | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `OPEN` | The applicant is still filling in the flow. Nothing billable runs yet. A draft left idle for 30 days is cancelled; the applicant's next save resumes it. | | `PROCESSING` | The applicant submitted. Zyphe runs the checks in the background: register lookup, ownership discovery, cross-checks, document checks, screening, and KYC invitations to the officers. | | `WAITING_INPUT` | A document request or clarification is open with the applicant. The case returns to `PROCESSING` once every request is answered, withdrawn, or expired. | | `ACTION_REQUIRED` | A person has to act, for example on a screening match that holds or on an escalation. | | `READY_FOR_REVIEW` | Every check has finished. A reviewer decides the case. | | `APPROVED` | Approved by a decision. | | `REJECTED` | Rejected by a decision. | | `CANCELLED` | Abandoned, or the company's country changed before submission. | Three rules shape how cases behave: - **No automatic approval.** A clean company is not approved on its own: it reaches `READY_FOR_REVIEW` and a reviewer (or the KYB agent in Auto-pilot) decides it. - **Decisions are final, cases are not.** A decision is never rewritten. A case can still be reopened, under the same ID, when the applicant resubmits after a rejection, when a quality review disagrees with the decision, or when a periodic re-review is due. Each opening is an **episode** of the case. - **One decision path.** The dashboard, the [Node SDK](/docs/guides/sdk/node#6-kyb-cases), and the KYB agent all decide through the same rules: the case must be ready, blockers must be covered by an exception, and your organization's approval matrix says who may decide and whether a second signature is needed. How to work a case, from the worklist to the decision: **[Reviewing KYB cases](./reviewing-cases.mdx)**. How your organization sets the rules those decisions follow: **[Compliance policy](./compliance-policy.md)**. ## Create a KYB Flow ### 1. Start a KYB flow Log in to the Zyphe Dashboard, open the **Flows** section, and click **Create Flow** in the top right.
Open the Flows page and click Create Flow to start a new flow.
In the dialog, choose **Create KYB**.
Select Create KYB to build a flow that verifies businesses.
### 2. Configure the flow Enter the flow's basic settings: - **Name:** the name of the flow. - **Slug:** a short identifier used in the verification link shared with end users. This cannot be changed after the flow is created. - **Success URL:** where users are redirected after they complete all flow steps. To receive KYB outcomes, create an organization [webhook endpoint](/docs/guides/webhook/endpoints) subscribed to `verification.kyb.submitted`, `verification.kyb.review`, `verification.kyb.completed`, and `verification.kyb.failed`, scoped to this flow or to every flow you own. When each one is sent is described under [Webhook lifecycle](#webhook-lifecycle).
Enter the flow name, slug, and success URL.
### 3. The KYB steps A KYB flow is built from a **Know Your Business** step, which collects the business information, plus optional steps linked to it: **Business Document Collection**, **UBO Collection**, and **Director Collection**. All of them write into the same case. A part is collected only if its step is in the flow: to collect directors, add a Director Collection step.
The Know Your Business step and the steps linked to it, with the Devtools panel.
Open the **Know Your Business** step to configure how cases of this flow are worked: - **KYB Agent Mode:** how far the KYB agent acts on the case. See [KYB Agent Mode](#kyb-agent-mode) below. - **AML Agent Mode:** how the AML agent handles screening matches (disabled, suggest-only, or auto-pilot). See [AML Agent Mode](/docs/aml#aml-agent-mode). - **Case planner:** which checks a case runs, and in what order. - **Fixed order:** every case runs the standard set of checks. - **Organization's rules:** your [KYB orchestration rules](./compliance-policy.md#kyb-orchestration-rules) propose extra steps for the cases they match. - **AI proposals:** an AI planner reads each case against your written procedure and proposes stricter changes. **AI planner mode** decides whether a reviewer accepts them (Suggest, the default) or they apply on their own (Auto-pilot). See [Proposed changes](./reviewing-cases.mdx#proposed-changes). - **Ask whether the applicant is a business or an individual:** shows the applicant a first question to choose between the business path and the individual (sole proprietor) path. - **Enable UBO discovery:** Zyphe finds the beneficial owners from official registers instead of asking the applicant, within a per-verification **Discovery budget**. See [Ownership discovery](./ownership-discovery.md) and the covered jurisdictions in [Country coverage](./country-coverage.md). - **Check the EIN of US businesses:** asks a business registered in the US for its EIN and matches it with the company name on IRS records before the business information is accepted. Offered to organizations with the [TIN Check](/docs/guides/tin-check) product. See [Checking a US business's EIN](./steps-and-configuration.md#checking-a-us-businesss-ein). - **Let the agent research on its own:** lets the KYB agent consult extra sources during its review, within a **research spend** and a number of **web searches** per review. Off by default. - **Success Button Label:** the label of the button shown to the user on completion.
The Know Your Business step: agent modes, case planner, and ownership discovery.
The linked steps carry their own settings: - **Business Document Collection:** which documents are requested per country, and how many extra files the applicant may attach. See [Required documents](#4-required-documents). - **UBO Collection** and **Director Collection:** the **KYC Flow** each person completes, the maximum number of people, and **Require KYC**. With Require KYC off, people are collected by name and screened for PEP and sanctions only. See [Collecting people without KYC](./steps-and-configuration.md#collecting-people-without-kyc). On the UBO step, **Auto-send UBO KYC invitations** emails each owner their KYC link on submission. The field-by-field reference, including the API names, is in [KYB steps and configuration](./steps-and-configuration.md#configuration). #### KYB Agent Mode The KYB agent reviews the case: it cross-checks every business-information field against the documents and the official register, grades each one **Exact Match**, **Partial Match**, **Mismatch**, or **Not Found** with a one-sentence explanation and a suggested value, and reaches a recommendation for the case. Behind it runs a multi-role **[agentic review engine](./agentic-review-engine.mdx)**: analytic roles argue the case, a deterministic guard arbitrates, and a tool-constrained actuator enacts one audited outcome. The mode controls how far that goes: - **Disabled:** the agent is not invoked. Fields still receive a match type, and reviewers do everything by hand. - **Suggest:** the agent runs and records its reasoning and recommendation. It may ask the applicant for a clarification or escalate the case, but an **approval stays a suggestion** for a reviewer to follow or not. - **Auto-pilot:** the agent may also approve, through the same decision rules as a person: the case must be ready, blockers must be covered, and the approval matrix must allow it. A case whose screening coverage is incomplete is escalated, not approved. :::info For how the engine reaches and enacts each outcome (the analytic roles, the deterministic guard, the audited action, and the safety guarantees), see [KYB Agentic Review Engine](./agentic-review-engine.mdx). ::: ### 4. Required documents Zyphe keeps a catalog of company documents per country (for example, the chamber-of-commerce extract and the articles of association for an Italian company), plus a general list for countries without a dedicated entry. On the **Business Document Collection** step you can adjust it: - mark a document **required** or optional, or turn it off; - mark a document **on demand**: it is not asked upfront, and a reviewer (or your backend) can request it later from the case; - add your own documents, globally or for a given country. A country with its own list uses only that list. Documents grouped as alternatives are satisfied by any one of them. The applicant can attach up to the configured number of extra files on top of the required ones. :::info For general flow settings, advanced flow building, and SDK snippets, see [Create a Flow](../create-a-flow/index.mdx). For webhook destinations, see [Webhook endpoints](../webhook/endpoints.md). ::: ## Ownership structure and recursive UBO discovery Zyphe can discover Ultimate Beneficial Owners automatically by building and traversing the company's ownership structure. Starting with the company being verified, the system follows corporate shareholders through every available ownership tier until it reaches natural persons and calculates each person's **effective ownership** across the full chain. A person with **at least 25% direct or indirect ownership** is identified as a UBO candidate and can then complete the KYC and AML checks configured in the linked KYC flow. For indirect ownership, each stake along a path is multiplied. For example, a person who owns 50% of a holding company that owns 60% of the subject company has 30% effective ownership (`50% × 60%`) and meets the 25% threshold. The traversal records the source of every relationship and makes unresolved branches visible when registry coverage or available evidence does not permit the chain to be completed. This gives reviewers both the result and the evidence path used to reach it. In this anonymized example, the traversal covers six ownership tiers. The highest identified natural person has **23.2% effective ownership**, so no individual meets the 25% ownership test. A separate branch represents **30.2% effective ownership**, but ends at a corporate entity where registry coverage is unavailable; it is retained as a UBO proxy rather than incorrectly reported as a natural-person UBO. ### When the ownership test does not identify a UBO When no natural person reaches the threshold, Zyphe can apply the alternative determination methodology required by the applicable regulatory framework. Depending on the configured policy and available evidence, this can include assessing **control through other means** and, when appropriate, using the company's **senior managing officials or directors** as the fallback subjects. Under the director fallback, the selected directors are run through the configured AML checks, including PEP and sanctions screening. The system preserves the determination basis, unresolved ownership branches, and screening results so the reviewer can see and audit why the fallback was used. :::info The 25% ownership test and the available fallback methodology must be applied in line with the regulations and internal policy relevant to your organization and the company being verified. ::: ### Turning it on, and what it costs Discovery is off by default and is enabled per flow, on the Know Your Business step, together with a per-verification credit budget. With it on, the applicant **never walks the UBO and director steps**: discovered people are added to the case and screened automatically. If discovery cannot finish, Zyphe reopens those steps with a declaration request instead. Once the automatic traversal has spent its budget, a reviewer can continue individual branches of the graph from the case page, previewing what each node would cost before paying for it. → **[Ownership discovery](./ownership-discovery.md)** covers the configuration, the declaration fallback, per-node expansion, and how discovery is charged in credits. ## The end-user KYB experience The following steps are what an applicant goes through after opening the KYB flow link. ### 5. Business registration status When the flow asks it, the applicant first says whether the business is registered. - **Yes**: the applicant continues to the business information and document steps (the registered-business path). - **No**: the flow skips the company details and collects a single owner directly (the unregistered / sole-proprietor path).
The applicant indicates whether their business is registered.
### 6. Business information The applicant provides the company details: **Address**, **City**, **Postal Code**, **Country**, **Company Name**, **Email**, **Company Type**, **Business Activity**, **Registration Number**, and **Incorporation Date**.
The applicant enters the registered business information.
### 7. Business documents The applicant uploads the documents required for the company's country, plus any **Other Documents**, and confirms the authenticity attestation before continuing. Each upload is classified and checked automatically (see [Document checks](./reviewing-cases.mdx#documents-and-declared-information)).
The applicant uploads company documents and confirms they are authentic.
### 8. Ultimate Beneficial Owners The applicant enters each Ultimate Beneficial Owner's details: **First Name**, **Last Name**, **Date of Birth**, **Gender**, **Email**, and **Country**.
The applicant provides the details of a beneficial owner.
### 9. Confirm owners The applicant reviews the owners they have added. They can choose **Enter another UBO** (up to the configured maximum) or **Submit** to continue.
The applicant confirms the beneficial owners, adding more if needed.
### 10. Directors (when collected) If the flow has a **Director Collection** step, an equivalent director sub-flow runs after the owners are confirmed: - A **director form** with the same fields as the UBO form (First Name, Last Name, Date of Birth, Gender, Email, Country). - A **Confirm directors** screen, where the applicant can choose **Enter another director** (up to the configured maximum) before submitting. When directors are not collected, the flow submits right after the UBOs are confirmed. :::info After submission, each owner **and director** with an email receives the linked KYC flow. People without an email are screened by name only. Reminders can be sent from the case page (see [People](./reviewing-cases.mdx#people)) or from your backend with the [Node SDK KYB case helpers](/docs/guides/sdk/node#6-kyb-cases). ::: ## Reviewing KYB cases Cases are worked under **KYB Results** in the Zyphe Dashboard, grouped by what they need from you: ready for review, action required, waiting for input, and processing. The case page shows what was declared and how it matched, what the case is waiting for, how each requirement was covered, the screening matches, the people, and the full audit trace, and it is where the case is decided.
Cases to work on, grouped by what they need from you.
→ **[Reviewing KYB cases](./reviewing-cases.mdx)** walks through the worklist, the case page, screening matches, exceptions, decisions, and quality reviews. ## Statuses A KYB case reports the [case statuses](#how-a-kyb-case-works) above, plus: | Field | Values | | ------------------- | ------------------------------------------------------------------------------------- | | **Rating** | `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`: the worst of the company's and its people's risk | | **Due diligence** | `SIMPLIFIED`, `STANDARD` (default), `ENHANCED` | | **Waiting on** | The applicant, a reviewer, the agent, a provider, or the platform | | **PEP & sanctions** | `PENDING`, `IN_PROGRESS`, `REVIEW`, `SUCCESS`, `FAILED` | The full vocabulary, including decision reason codes, is in [Statuses and codes](/docs/reference/statuses-and-codes#kyb-and-aml-statuses). ### Webhook lifecycle A KYB case sends these webhooks: | When | Event | | ---------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- | | The applicant submits the last outstanding part | `verification.kyb.submitted` | | The case needs a person (`ACTION_REQUIRED`), is reopened, or is put back in `READY_FOR_REVIEW` by anything other than its own checks finishing | `verification.kyb.review` | | The case is approved | `verification.kyb.completed` | | The case is rejected | `verification.kyb.failed` | - `submitted` means nothing has been checked or decided yet: do not provision on it. - `completed` is the event to onboard the business on. There is exactly one webhook per decision, whoever takes it (dashboard, SDK, or agent). - `review` can arrive more than once, or not at all. It is also sent when an **already approved** company is reopened by a quality review or a periodic re-review, so do not treat it as a new company. - A case that reaches `READY_FOR_REVIEW` on its own, or is cancelled, sends no webhook. The legacy event names (`SUBMITTED`, `REVIEW`, `COMPLETED`, `FAILED`) map one to one. The exact transition behind each event is in [Statuses and codes](/docs/reference/statuses-and-codes#kyb-event-lifecycle). --- ## Ownership discovery A KYB step can discover a company's beneficial owners **automatically**, instead of asking the applicant to declare them. When it does, Zyphe buys the ownership graph from official business registers as soon as the applicant submits their business information, traverses it to natural persons, and materializes the discovered owners and directors onto the case, where they are screened like any declared person. The conceptual model: how the graph is traversed, how effective ownership is multiplied along a chain, and what happens when no natural person crosses the 25% threshold: is described in [Ownership structure and recursive UBO discovery](./index.mdx#ownership-structure-and-recursive-ubo-discovery). This page is how you turn it on and operate it. ## Turning it on Discovery is configured on the **anchor `KYB` step**: | Field | Type | Default | Meaning | | ------------------------ | ------- | ------- | ----------------------------------------------------------------------------------- | | `discoveryEnabled` | boolean | `false` | Dispatch ownership discovery when business information is submitted. | | `discoveryBudgetCredits` | integer | none | Per-verification cap on discovery spend, in credits. Omit for the platform default. | :::warning[Breaking change: these fields moved] `discoveryEnabled` and `discoveryBudgetCredits` used to live on the `KYB_UBOS` satellite's configuration. They now live on the anchor, because discovery is dispatched by the anchor's business-information submission and the opt-in has to sit on the step that triggers it. Existing flows were migrated in place: there is nothing to do unless you assemble flow configuration yourself, in which case move the two keys. ::: The default is `false`. A traversal spends your credits, so a flow that never opted in never dispatches one. :::info[Discovery also has to be available] Beyond the step flag, ownership discovery has to be switched on for your deployment and for the country being verified. [Country coverage](./country-coverage.md) lists every jurisdiction and whether its register provides directors, shareholders, and UBOs. Ask Zyphe support to confirm coverage before you rely on it in production, and keep the declaration fallback in mind for the countries it does not reach. ::: ## What the applicant sees Enabling discovery **is** the decision to let it stand in for the declaration steps. It is a single flag, not a pair of independent switches. With `discoveryEnabled` on, the applicant submits business information and then **never walks the `KYB_UBOS` or `KYB_DIRECTORS` steps at all**. Those satellites stay hidden. Discovered people are written onto the result and their KYC invitations and screenings proceed exactly as they would for declared people. The applicant's session can read the discovery's progress and result: ```text GET /flow/{flow_id}/vr/{verification_request_id}/kyb/discovery ``` It returns `status`: `NONE` when no traversal has been dispatched, otherwise `PENDING`, `COMPLETED`, or `FAILED` for the base run: plus `ownershipStructure`, `uboSuggestions`, and optional `stoppedReason` and `errorMessage`. It deliberately does **not** return the expansion history: per-node spend is your organization's business, not the applicant's. Read that from the organization-scoped endpoint [below](#reading-the-full-picture). Discovered owners arrive **without an email address**, so they are screened for PEP and sanctions by name. They are not invited into a KYC flow. ### When discovery cannot finish Registers do not cover every jurisdiction, and a chain can dead-end at an entity nothing authoritative reports. When discovery fails or produces nothing usable, Zyphe falls back to asking the applicant: it raises a **declaration document request** that reopens the hidden satellite for a fresh declaration: | Request type | Reopens | | ---------------------- | --------------- | | `UBO_DECLARATION` | `KYB_UBOS` | | `DIRECTOR_DECLARATION` | `KYB_DIRECTORS` | A declaration request is raised automatically when the traversal fails, stops early, produces no natural-person owner (or, for directors, no director), or is still unfinished after the fallback window. The applicant receives an email with a deep link back into the reopened step, and answers it by submitting that part normally: the request flips to `UPLOADED` on submission. **While one is outstanding, the case cannot be approved**, by an agent or by a reviewer. Each part is asked **at most once, ever**. If the applicant's declaration is unsatisfactory, take it forward as an ordinary clarification or document request rather than expecting a second automatic reopen. A reviewer can also raise one manually: ```http POST /organizations/{organization_id}/kyb-cases/{case_id}/document-requests ``` ```json { "requests": [{ "requestType": "UBO_DECLARATION", "description": "Please declare the beneficial owners." }] } ``` Raising a declaration request on a step that does **not** have `discoveryEnabled` returns a `400` that flow already collects declarations directly, so there is nothing to reopen. :::note[`requestType` on document requests] Every item in a document-request creation payload carries a `requestType`. It now has four values: `STANDARD`, `CLARIFICATION`, and the two new `UBO_DECLARATION` and `DIRECTOR_DECLARATION`. ::: ## Enrichment: the `ENRICHING` status `ENRICHING` no longer exists. The registry lookup the business-information cross-check is graded against now runs while the case is `PROCESSING`, as one of its checks, and appears under **Steps and runs** on the case page. A case whose checks are not finished is simply not ready for review yet. The case statuses are described in the [KYB overview](./index.mdx#how-a-kyb-case-works) and in [Statuses and codes](/docs/reference/statuses-and-codes#kyb-case-status). ## Expanding the graph node by node The automatic traversal runs against a budget. Once it is spent, the graph can be **truncated**: branches that were not followed to their end are recorded as such rather than silently dropped. A reviewer can then pay to continue specific branches, one node at a time, from the case page page. These endpoints are organization-scoped and available to your **organization administrators**. ### Preview what an expansion would cost ```text GET /organizations/{organization_id}/kyb-cases/{case_id}/expansion-preview ``` A pure read: no register is queried and nothing is charged. It answers "which nodes can I expand, and what would each cost?" ```json { "candidates": [ { "nodeId": "n_7", "legalName": "Beta Holdings S.à r.l.", "countryCode": "LU", "nodeStatus": "budget_truncated", "expandable": true, "alreadyExpanded": false, "estimatedCredits": 42, "estimateBasis": "variableCap", "expectedLatency": "slow" }, { "nodeId": "n_9", "legalName": "Gamma Ltd", "countryCode": "KY", "nodeStatus": "coverage_unavailable", "expandable": false, "reason": "countryUnsupported" } ], "inFlight": [{ "nodeId": "n_4", "discoveryId": "…", "startedAt": "2026-08-30T02:00:00Z" }], "concurrencySlotsFree": 3, "pricingFetchedAt": "2026-08-30T02:00:00Z" } ``` | Field | Meaning | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `countryCode` | The **node's own** country. Pricing and coverage are decided by it, not by the subject company's country: expanding a Cayman parent of an Italian subject prices against Cayman. | | `expandable` | Whether the node can be sent to `extend-discovery` right now. | | `alreadyExpanded` | Reported, not a rejection. Re-pulling a node is legitimate and is usually near-free thanks to source-side deduplication. | | `estimatedCredits` | Estimated cost in credits. Absent when `expandable` is `false`. | | `estimateBasis` | `fixedPrice` (a firm per-country price), `variableCap` (a ceiling the request is capped at, never a firm price), or `unknown` (a guess against the same conservative ceiling). | | `expectedLatency` | `fast` (seconds), `slow` (minutes), or `manual` (days, for jurisdictions where the record is retrieved by hand). | | `reason` | Why a node is not expandable: see the table below. | | `concurrencySlotsFree` | How many more expansions this case can have in flight at once. | Optional fields are **omitted** rather than serialized as `null`. Treat "key absent" and "key null" identically. The preview is only meaningful once the base traversal has **completed**: before that there is nothing to expand, and a dispatch attempt rejects every node with `baseRunInFlight`. ### Dispatch the expansion ```text POST /organizations/{organization_id}/kyb-cases/{case_id}/extend-discovery ``` ```json { "nodeIds": ["n_7", "n_9", "n_4"], "maxCreditsPerNode": 60 } ``` | Field | Required | Meaning | | ------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `nodeIds` | yes | 1–25 company node ids from the stored ownership graph. | | `maxCreditsPerNode` | no | Per-node ceiling, **in the credits you are actually charged**. It only ever binds downward: on a variable-priced country it replaces the platform ceiling; on a fixed-price country it cannot raise the price, but a cap below that price makes the node come back rejected with the real cost rather than overspending it. | :::warning[Breaking change: the response shape] The response is now a **per-node dispatch report** (`202`), not a single `{discoveryId, status}` job handle. One register request, one row, and one verdict per requested node, with **partial acceptance**. The old top-level `discoveryId` and `status` fields are gone: with N rows they were never meaningful. ::: ```json { "verificationRequestId": "…", "estimatedCreditsTotal": 84, "expansions": [ { "nodeId": "n_7", "accepted": true, "discoveryId": "…", "status": "PENDING", "estimatedCredits": 42, "estimateBasis": "variableCap" }, { "nodeId": "n_4", "accepted": true, "discoveryId": "…", "status": "COMPLETED", "estimatedCredits": 42, "estimateBasis": "variableCap", "chargedCredits": 17 }, { "nodeId": "n_9", "accepted": false, "reason": "countryUnsupported" } ] } ``` A node can finalize inline when the source responds synchronously, in which case it comes back `COMPLETED` with `chargedCredits`. Otherwise the charge arrives later. `verificationRequestId` in the response is the anchor's verification request: join its websocket room to receive `discovery-update` events carrying `discoveryId`, `rootNodeId`, `status`, and `chargedCredits` as each node settles, or poll the [discovery read](#reading-the-full-picture). The endpoint is rate limited to 10 calls per minute per case, and a single case can have a limited number of expansions in flight at once: `concurrencySlotsFree` on the preview tells you how many are left. **Partial acceptance replaces all-or-nothing.** An unknown or non-expandable id is reported in place in `expansions[]`. Only a request where **every** node is rejected returns `400`, carrying each node's reason. **Rejection reasons.** `expansion-preview` can return the first seven; `extend-discovery` can return all ten. | Reason | Meaning | | --------------------------- | --------------------------------------------------------------------------------------------------------------------- | | `notACompanyNode` | The node is a natural person, not a company. | | `countryUnsupported` | No source covers that node's country. | | `graphDatapointUnavailable` | Ownership data is not available for that country. | | `expansionInFlight` | Another request is already expanding this node. | | `baseRunInFlight` | The base traversal has not finished yet. Every node is rejected with this. | | `concurrencyCap` | This case already has the maximum number of expansions in flight. | | `unknownNodeId` | No such node in the stored graph. | | `providerError` | Dispatch-time only. The lookup or row creation failed. | | `budgetExceeded` | Dispatch-time only. The continuation was refused as over budget. Free, and may carry a re-quote. | | `insufficientCredits` | Dispatch-time only. Your balance no longer covers this node once other in-flight traversals' commitments are counted. | Clients that match exhaustively on `reason` must handle all ten. **`402 Payment Required`** means the summed estimate of every accepted node, plus what this KYB's in-flight traversals have already committed, exceeded your credit headroom. It is deliberately all-or-nothing: **zero rows were created and zero lookups were made**, so there is nothing to reconcile and nothing to cancel. Top up, lower `maxCreditsPerNode`, or ask for fewer nodes, and retry. ### Cancel an expansion ```text DELETE /organizations/{organization_id}/kyb-cases/{case_id}/extend-discovery/{discovery_id} ``` Returns `204 No Content`, or `409` if the expansion has already finished or failed. Cancelling means **"stop waiting for this and let me move on"**, not "stop spending". The traversal continues at the source, which exposes no abort, and you are billed for the work it does. When it eventually settles, the result is **kept rather than discarded**: the graph is merged into the case, discovered people are materialized, and the real final cost is billed once. Paying for a traversal and throwing its result away would be the worse outcome. Your cancellation note is preserved in the audit trail either way. Cancelling releases the node's lock immediately, so a fresh expansion of the same node can be dispatched right away rather than waiting out a timeout. ### Reading the full picture ```text GET /organizations/{organization_id}/kyb-cases/{case_id}/discovery ``` The reviewer's full read: the base traversal's status, the discovered graph, the derived UBO suggestions, and the **per-node expansion history with its per-node spend**. A pure read: no lookup, no charge. ```json { "status": "COMPLETED", "ownershipStructure": {}, "uboSuggestions": [], "expansions": [ { "discoveryId": "…", "rootNodeId": "n_4", "status": "COMPLETED", "chargedCredits": 17, "stoppedReason": null, "createdAt": "2026-08-30T02:00:00Z", "completedAt": "2026-08-30T02:01:00Z" } ] } ``` `chargedCredits` is always present and is `0` before the charge is claimed. **`0` is not the same as "free"**: read `status` to tell a not-yet-charged row from a genuinely zero-cost one (a deduplicated lookup). `stoppedReason`, when present, is one of `completed`, `budget_exhausted`, `max_depth_reached`, `max_nodes_reached`, or `timeout`. ## What a KYB costs Everything below is denominated in **credits**, deducted from your organization's balance. See [Billing](/docs/guides/billing) for how credits are funded. **Every KYB carries a base charge**, resolved for the **jurisdiction of the business being verified**, falling back to your plan's KYB credit cost when no jurisdiction price applies. Zyphe can set a **per-organization override** of a jurisdiction's price for you. What that base charge covers depends on whether discovery is on: | `discoveryEnabled` | Charging model | What you pay | | ------------------ | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `false` (default) | **Flat** | The jurisdiction base charge, and nothing else. The registry lookup behind the business-information cross-check is **included**: it is performed and costs you no extra credits. | | `true` | **Metered** | The jurisdiction base charge, **plus** the ownership-graph traversal and any operator-initiated node expansions, each charged in credits. | Flat versus metered is a **per-KYB** property derived from the anchor step's `discoveryEnabled`, not an organization-level setting. Two flows in the same organization can charge differently. Within a metered KYB: - The automatic traversal is bounded by `discoveryBudgetCredits` on the step. - Each node expansion is priced and charged **individually**, against the node's own country, and optionally capped by `maxCreditsPerNode` on the request. - Sandbox draws the same credit balance as production. There is no separate sandbox balance. ## Approval preconditions Every decision goes through the same rules, whoever takes it (a reviewer in the dashboard, your backend through the SDK, or the KYB agent). For discovery, that means a case is not ready for review while: - ownership discovery is still running; - a UBO or director declaration request is unanswered; - required documents are missing, business information is incomplete, or a person's KYC or screening is unfinished. **Waiting for** on the case page names each gap and who owes it. The full decision rules (readiness, exceptions, the approval matrix, and second signatures) are in [Reviewing KYB cases](./reviewing-cases.mdx#deciding-a-case). ## Related - [KYB overview](./index.mdx) - [Reviewing KYB cases](./reviewing-cases.mdx) - [KYB steps and configuration](./steps-and-configuration.md) - [KYB Agentic Review Engine](./agentic-review-engine.mdx) --- ## Reviewing KYB cases Every KYB submission is a **case**. This page walks through how a reviewer works one in the Zyphe Dashboard: finding it, reading what was checked, clearing what blocks it, and deciding it. The rules a decision follows (who may decide, when a second signature is needed, how screening matches are treated) come from your [compliance policy](./compliance-policy.md). Cases can be worked by users with the `ORG_ADMIN`, `ORG_OPERATOR`, or `AML_OFFICER` role. See [Manage Users](/docs/guides/manage-users) for the full permission matrix. ## Cases to work on Open **KYB Results** in the sidebar. **Cases to work on** groups the open cases by what they need from you: - **Ready for review:** every check has finished; the case is waiting for a decision. - **Action required:** a person has to act, for example on a screening match or an escalation. - **Waiting for input:** a request is open with the applicant. - **Processing:** checks are still running. Each row shows the company, its **due-diligence** level, the **stage**, who the case is **waiting on**, how many **checks** are done, the **risk** rating, and who it is **assigned to**. Turn on **Only assigned to me** to see your own cases.
Pick a group, then open a case.
From a row's **⋯** menu you can: - **Assign** the company to a reviewer. An assignment belongs to the company, so it applies to every case of that company. - **Override risk:** set the rating by hand, with a reason and an expiry. Raising it is always allowed; lowering it is allowed only if your policy permits downward overrides and you have the authority for the level being left. The buttons at the top open **Metrics**, **Quality reviews**, and **Show all results** (every case, including decided ones, with search and filters). ## The case page Open a case to see everything about it on one page. The header stays visible as you scroll.
The case header: status, screening, stage, due diligence, risk, and the decision buttons.
The header shows: - **Status:** the [case status](./index.mdx#how-a-kyb-case-works). - **Screening:** whether the company's and its people's screening is complete. - **Stage** and **Assigned to**. - **Due diligence:** `Simplified`, `Standard` (the default), or `Enhanced`. `Enhanced` adds a financial-documents requirement; otherwise the checks are the same at every level. Changing it makes the case plan its checks again. - **Risk:** `Low`, `Medium`, `High`, or `Critical`, the worst of the company's risk score, its screening, and each person's screening and KYC. A confirmed match keeps the rating high even after approval. **How it is computed** shows the breakdown. - **Report:** generate, upload, or download the case report. - **Approve** and **Reject** when the case can be decided (see [Deciding a case](#deciding-a-case)). ### Documents and declared information **Business Information Clarifications** compares each field the applicant declared with what the documents and the official register say, graded **Exact Match**, **Partial Match**, **Mismatch**, or **Not Found**. Select a field to see the agent's reasoning and every source. To resolve a discrepancy, use **Ask for a clarification**: the applicant is asked to confirm or correct the selected fields, and you review each answer (old value next to new value) before accepting it. **Send Email** requests a named document instead.
What the applicant sees: they confirm or update the requested fields and explain the change.
The **Document Checklist** lists every document the company's country requires. Each upload is classified and checked automatically: - **Document check:** whether the file is the document it claims to be (for example, **Correct document** or **Wrong document**). - **Checks:** each field read from it (issuer, issue date, shareholders, directors, and so on) marked **Match**, **Mismatch**, **Not found**, or **Not checkable**. A reviewer can override any check; the override is recorded next to the automatic verdict.
Every upload is classified and its content checked against the case.
**Register documents** lists the official documents the company's register holds. Listing them is free; buying one spends credits. This is not available in the sandbox. To ask for a document your flow marks as **on demand**, request it from the document list (or from your backend with the [Node SDK](/docs/guides/sdk/node#request-a-document)). ### Case activity **Case activity** is the workbench: what the case is waiting for and everything that happened to it.
What the case needs before it can move on, and who owes it.
- **Waiting for:** every outstanding item, with who owes it and since when: a blocker, an open screening match, an exception needed before approval, a proposal to answer, a second signature awaited, a quality review due. **Show** jumps to where you act on it. - **Clarification proposals:** when the cross-check finds fields that do not match, it proposes asking the company about them. **Accept** opens the clarification request; **Decline** drops it. - **Steps and runs:** each check of the case and its latest run. A failed check can be **confirmed** by a reviewer with a reason and evidence (for the register, ownership, director, and cross-checks; not for screening or KYC), or run again. - **Verification coverage:** each requirement of each subject, and how it was covered (for example, verified by the register or by an interactive check, screened by name, or **Nothing provided** when the flow did not collect that part). Coverage shows what was actually checked, which a rating cannot: an unscreened company can still rate Low. - **Exceptions**, **Decisions**, and **Agent reviews:** the history of each, with who acted and why. - **The case's account:** a timeline of the case, its episodes, and each person's progress.
Verification coverage, read against the policy version in force.
#### Proposed changes When the flow's case planner is **AI proposals** or **Organization's rules**, **Proposed changes** lists the changes suggested for this case, such as requiring a step, raising the due-diligence level, widening screening, or asking the owners or directors to complete KYC. The planner can only propose changes that make the case **stricter**. A reviewer accepts or refuses each one; a refused change is not proposed again. In Auto-pilot, changes apply on their own, except ones that need a choice (such as which KYC flow to use). ### Company screening The screening card lists every match found for the company and its people, by category (sanctions, PEP, adverse media, other), with the match score and the details the list holds.
A sanctions match cleared as a false positive, following the agent's proposal.
Each match gets a verdict: - **False positive:** the match is not the subject. It needs at least one discriminator: date of birth, nationality, tax or ID number, address, gender, or another reason with a note. Only a false positive releases the match. - **True positive:** the match is the subject. - **Undetermined** or **Customer contacted:** the match holds while you find out more. The AML agent can propose a verdict with its discriminators; you can follow it or record your own. A verdict is not edited afterwards, and it carries over to the same match when the company is screened again. Where your policy **rejects** a category (for example PEP or adverse media), a true positive in it blocks approval outright: no exception can clear it. Sanctions matches are always reviewed, whatever the policy says. ### People **People** lists the owners and directors of the company with their roles, KYC status, and screening.
Owners and directors, with their KYC and screening status.
- **Add person** adds an owner or director to the case; removing someone's role cannot be undone. - **Request UBO declaration** and **Request director declaration** ask the applicant to declare that part again (available when ownership discovery is enabled). - From a person's menu, **Send reminder** re-sends the KYC invitation, and **Open KYC result** opens their KYC. A person without an email is screened by name only (**Name-only (AML screen)**) and cannot be invited to KYC. ### Ownership structure When [ownership discovery](./ownership-discovery.md) ran, **Ownership structure** draws who owns the company, with unresolved branches marked. You can extend individual branches, or add the structure by hand when discovery is off. **State or public ownership** records whether the owners include a state or public body. ### Audit trace **Audit trace** records every event on the case (submissions, checks, requests, verdicts, exceptions, decisions, agent reviews) with the actor, the action, and the details. ## Deciding a case **Approve** is available when the case is **Ready for review**; **Reject** also from **Action required**. Every decision is final: it is never rewritten, and remediation happens by reopening the case.
Approving: a reason is optional on a clean approval.
Rejecting: a reason is required, and a reason code classifies it.
- A **reason** is required on every rejection, and on an approval that rests on an exception or on a confirmed match. It is optional on a clean approval. - A **reason code** classifies the decision so regulators, metrics, and quality reviews can count it: `CDD_INCOMPLETE`, `SANCTIONS_CONFIRMED`, `PEP_CONFIRMED`, `ADVERSE_MEDIA`, `OUTSIDE_RISK_APPETITE`, `SUSPECTED_FRAUD`, `APPLICANT_UNRESPONSIVE`, or `OTHER`. Without one, a decision that owes a reason is recorded as `OTHER`. - Your **approval matrix** decides who may approve at each rating, and whether a second signature is needed. See [Approval matrix](./compliance-policy.md#approval-matrix). The decision sends one webhook (`verification.kyb.completed` or `verification.kyb.failed`), and a sealed decision package records the coverage, exceptions, signatures, and policy version behind it. ### Exceptions Some things block an approval until a reviewer takes responsibility for them, for example **provider results still pending**, **open clarifications**, or a fallback your policy does not accept (such as screening a person by name only). **Record an exception** covers exactly one of them, with a **reason** and an **expiry date**. Recording one needs the authority to approve that rating "with an exception" in your approval matrix, and it can be withdrawn. An exception never clears a true positive in a category your policy rejects. Separately, a step can be **waived** (proposed, then approved), but sanctions and PEP screening and the platform's mandatory steps can never be waived. ### Two signatures When your approval matrix asks for a second signature, the first **Approve** or **Reject** records a **proposed decision** instead of closing the case. The case header then shows who proposed it, with **Confirm** and **Withdraw proposal**.
A proposed approval waiting for a second signature.
- The confirmation must come from a **different person** holding one of the awaited roles. The proposer cannot confirm their own proposal. - An API key or the KYB agent can take the first signature, never the second. - A proposal lapses if the case, its screening matches, or the policy in force change before it is confirmed. ## After the decision ### Quality reviews Your policy can draw a share of decisions for a second look. **Quality reviews** lists the decisions waiting for one, oldest first. Nobody reviews a decision they signed.
Decisions drawn for a second look.
A reviewer **agrees** or **disagrees**, with a reason. A disagreement reopens the case, even an approved one, and sends a `verification.kyb.review` webhook. ### Periodic re-review Your policy sets how long an approval stays valid. When it expires, the case is reopened for a new review, and a `verification.kyb.review` webhook is sent. ### Metrics **Metrics** shows how your KYB decisions were taken over a period, by flow: how many approvals were fully covered, how many decisions were later superseded, rating overrides, time to decision by rating, the agent's reviews and agreement, quality-review outcomes, who decided, and how quickly applicants answered requests.
Compliance metrics for your KYB decisions.
## Related - [KYB Overview](./index.mdx): flow setup and the case statuses. - [Compliance policy](./compliance-policy.md): the approval matrix, screening rules, exceptions, and review cycles. - [KYB Agentic Review Engine](./agentic-review-engine.mdx): how the KYB agent reviews a case. - [Node SDK: KYB cases](/docs/guides/sdk/node#6-kyb-cases): reading and deciding cases from your backend. --- ## KYB steps and configuration A KYB flow is an **anchor** step that collects business information, plus optional **satellite** steps that collect documents, beneficial owners, and directors. All of them write into **one KYB case**, so the reviewer sees a single case. This page is the reference for the step types, what each one configures, and the endpoints the applicant's session posts to. For the dashboard walkthrough, see the [KYB overview](./index.mdx); for the review workflow, see [Reviewing KYB cases](./reviewing-cases.mdx). :::warning[Changes in this release] - **Per-document flags are gone from the step configuration.** `certificateOfIncorporation`, `articlesOfAssociation`, `organizationalStructureChart`, `proofOfAttorney`, and `customDocuments` are still accepted when you save a flow, and are folded into `customCountryDocuments["**"]`, but they are never returned. Configure documents through `customCountryDocuments`, described [below](#kyb_documents). - The anchor gains `orchestrator`, `plannerMode`, and `agentResearch`. - The **flow no longer has a `webhookUrl`**. Destinations are organization-level [webhook endpoints](/docs/guides/webhook/endpoints). - `discoveryEnabled` and `discoveryBudgetCredits` live on the anchor `KYB` step, not on `KYB_UBOS`. ::: ## The anchor and its satellites | Step type | Dashboard name | Role | Requires | | --------------- | ---------------------------- | ----------------------------------------------------------------------------------------------------------- | -------------------------------- | | `KYB` | Know Your Business | **Anchor.** Collects the business information and owns the case. Also where ownership discovery is enabled. | Nothing | | `KYB_DOCUMENTS` | Business Document Collection | Company document uploads. | A `KYB` step earlier in the flow | | `KYB_UBOS` | UBO Collection | Beneficial-owner declaration. | A `KYB` step earlier in the flow | | `KYB_DIRECTORS` | Director Collection | Director declaration. | A `KYB` step earlier in the flow | Each satellite carries a `kybStepId` pointing back at its anchor, the same way a Liveness step points at its Document Verification step. Two rules are enforced when you save a flow: - A flow has **at most one `KYB` anchor**. - A satellite's `kybStepId` must resolve to a `KYB` step **ordered before it**. A satellite without a resolvable anchor is not a valid flow. Splitting the step buys three things: - **The applicant can be routed part by part.** Documents can be collected before owners, or a part can be skipped entirely for a particular flow. - **UBOs and directors can use different KYC flows.** Each satellite carries its own `kycFlowId`, so directors can be invited into a lighter flow than beneficial owners. - **Owners or directors can be collected without KYC at all.** See [`requireKyc`](#collecting-people-without-kyc) below. ### A KYB step with no satellites An anchor with **no satellite steps** collects the business information only: the applicant supplies it and the case goes on to its checks. A part is collected only when its satellite is in the flow, so to collect documents, owners, or directors, add the matching step. Flows created before the split, whose single KYB step still declares documents or directors, are **legacy monolithic steps**. They keep working through the legacy submission endpoint, and the per-part endpoints reject them with a message naming the endpoint to use instead. ## Configuration ### `KYB` (anchor) | Field | Type | Default | Meaning | | ------------------------ | ------- | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `agenticMode` | enum | `DISABLED` | KYB agent mode: `DISABLED`, `SUGGEST`, `AUTO_PILOT`. See [KYB Agent Mode](./index.mdx#kyb-agent-mode). | | `amlAgenticMode` | enum | `DISABLED` | AML agent mode for the screening matches this case raises. | | `orchestrator` | enum | `LINEAR` | The **Case planner**: `LINEAR` (Fixed order), `JDM` (Organization's rules, see [KYB orchestration rules](./compliance-policy.md#kyb-orchestration-rules)), or `LLM` (AI proposals). Fixed for each case when it opens. | | `plannerMode` | enum | `SUGGEST` | For `LLM`: `DISABLED`, `SUGGEST` (a reviewer accepts each proposal), or `AUTO_PILOT` (proposals apply on their own, except ones that need a choice). See [Proposed changes](./reviewing-cases.mdx#proposed-changes). | | `agentResearch` | object | off | `{ enabled, spendLimit, maxSearches }`: lets the KYB agent consult extra sources during its review, within a credit limit and a number of web searches per review. Values above the platform ceiling are refused when you save the flow. | | `discoveryEnabled` | boolean | `false` | Start [ownership discovery](./ownership-discovery.md) when business information is submitted. | | `discoveryBudgetCredits` | integer | none | Per-verification cap on discovery spend, in credits. Omit for the platform default. Only read when `discoveryEnabled` is on. | | `allowIndividualSubject` | boolean | `false` | Offer the applicant a business-or-individual choice at the start of the step. | | `tinCheckEnabled` | boolean | `false` | Ask a business registered in the US for its EIN and match it with the company name on IRS records on submission. See [Checking a US business's EIN](#checking-a-us-businesss-ein). | | `labels` | object | `{}` | Per-locale button labels. | An anchor on a legacy monolithic flow also carries `kycFlowId`, `maxUbos`, `maxDirectors`, `maxFileUploads`, `collectDirectors`, `autoSendUboKycEmail`, and the document configuration described below. On a split flow those live on the satellites instead. ### `KYB_DOCUMENTS` | Field | Type | Default | Meaning | | ------------------------ | ------- | ------- | ------------------------------------------------------------------------------------------------------------ | | `kybStepId` | UUID | none | The anchor this satellite belongs to. Required. | | `maxFileUploads` | integer | `10` | How many additional documents the applicant may attach, on top of the upfront ones. | | `customCountryDocuments` | object | `{}` | Your changes to the document catalog, keyed by ISO 3166-1 alpha-2 country code, or `"**"` for every country. | | `labels` | object | `{}` | Per-locale button labels. | Zyphe keeps a **document catalog** per country, plus a general list used for countries without their own entry. Each entry in `customCountryDocuments` overrides or adds a document: | Field | Meaning | | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | `key` | The document's catalog key, or your own key for a custom document. | | `label` | The name shown to the applicant and the reviewer. | | `required` | Whether the applicant must upload it before submitting. | | `onDemand` | Not asked upfront. A reviewer, or your backend through the [SDK](/docs/guides/sdk/node#request-a-document), requests it later from the case. | | `enabled` | Turn a catalog document off for your flows. | A country with its own list uses only that list. Catalog documents that share a group are **alternatives**: any one of them satisfies the group. The effective list served to the client, `documentsPerCountry`, is computed from the catalog and your changes, which win per country; it is read-only. ### `KYB_UBOS` | Field | Type | Default | Meaning | | --------------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------------ | | `kybStepId` | UUID | none | The anchor this satellite belongs to. Required. | | `maxUbos` | integer | `10` | Maximum number of beneficial owners the applicant may declare. | | `requireKyc` | boolean | `true` | Whether each declared owner must complete a KYC flow. See below. | | `kycFlowId` | UUID | none | The flow owners are invited into. Only meaningful when `requireKyc` is on; may be omitted otherwise. | | `autoSendUboKycEmail` | boolean | `true` | Send the KYC invitation automatically on submission. When off, a reviewer sends the first invitation from the case page. | | `labels` | object | `{}` | Per-locale button labels. | ### `KYB_DIRECTORS` | Field | Type | Default | Meaning | | -------------- | ------- | ------- | ------------------------------------------------------------------------------------------------------------------- | | `kybStepId` | UUID | none | The anchor this satellite belongs to. Required. | | `maxDirectors` | integer | `10` | Maximum number of directors the applicant may declare. | | `requireKyc` | boolean | `true` | Whether each declared director must complete a KYC flow. | | `kycFlowId` | UUID | none | The flow directors are invited into. Independent of the UBO satellite's, so directors can use a different KYC flow. | | `labels` | object | `{}` | Per-locale button labels. | The **existence of the `KYB_DIRECTORS` step** is what makes a flow collect directors. The anchor's `collectDirectors` boolean is the legacy monolithic equivalent. ## Collecting people without KYC `requireKyc` is on the UBO and director satellites, and defaults to `true`, which is what every flow built before it existed does. **`requireKyc: true`.** The widget demands an email address for each person, because an email is what a KYC invitation is addressed to. Zyphe sends and schedules those invitations against `kycFlowId`, and the person must complete that flow before the case is ready for review. **`requireKyc: false`.** The widget collects the person by name alone and asks for no email. `kycFlowId` becomes meaningless and can be omitted. The person is still screened for PEP and sanctions by name; there is simply no identity verification behind the name. The two satellites are independent: you can require KYC of beneficial owners while screening directors by name only, or the reverse. Two rules follow from it: - Saving a step with `requireKyc: true` and no `kycFlowId` is rejected at validation time. Set one, or turn `requireKyc` off. - With `requireKyc: true`, a **final** submission whose declared people carry no email is rejected. This also applies to the legacy monolithic endpoint, so a widget that used to send name-only owners against a KYC-requiring step must now send emails, or the step must set `requireKyc: false`. :::info[Readiness keys off the person, not the config] Whether a person is covered is decided per person, from whether that person has an email on file: a person with an email needs a completed KYC, a name-only person needs a clean name screening. Changing `requireKyc` therefore does not retroactively re-gate people already declared, and owners found by [ownership discovery](./ownership-discovery.md), who arrive without an email, are always screened by name. Name-only screening is a **fallback**: unless your [compliance policy](./compliance-policy.md#admitted-fallbacks) admits it, approving such a case needs a recorded exception. ::: ## Which population must be screened A KYB case records a **screening strategy**: which population of natural persons must be identified and screened before it can be approved. | Value | Meaning | | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `ubo` | Beneficial owners. **The default**, and correct for the overwhelming majority of private companies. | | `directors` | Directors instead of owners. For a business where no natural person crosses the ownership threshold (a listed or widely-held company, a state-owned body), control rather than ownership is the screenable population. | | `uboAndDirectors` | Both. | The strategy selects _which_ population is required, never _whether_ one is: every value demands at least one screened natural person, so no sequence of changes produces a case that is approvable with nobody identified. A person who holds both roles is screened once. Screening is complete when every required subject has a current screening and every match is resolved. Until then the case is not ready for review, whoever wants to decide it, and the KYB agent escalates rather than approves a case whose screening coverage is incomplete. Agents change the strategy through the `set_kyb_screening_strategy` [MCP tool](/docs/guides/model-context-protocol-mcp), which accepts only a strategy the people already on file satisfy, requires a reason, and writes a `KYB_SCREENING_STRATEGY_CHANGED` entry to the audit trail carrying the previous and new strategy, the reason, and the UBO and director counts at that moment. Ask Zyphe support to set it for a flow if you are not driving KYB through an agent. Alongside it, the case records a **due-diligence level**: `simplified`, `standard` (the default), or `enhanced`. `enhanced` adds a financial-documents requirement; otherwise the checks are the same at every level. The level can be changed on the case page, and an approver can record it on the decision (`dueDiligenceLevel`, also available through [`decideKybCase`](/docs/guides/sdk/node#decide-a-case)). `simplified` is never a fallback: it is a positive finding about the subject, so an unclassified case is `standard`, not reduced-checks. ## Submitting each part The applicant's session posts one part at a time. All four endpoints are **verification-request scoped** and authenticated with the session token the hosted widget already holds; they are not part of the API-key `/sdk` surface. Add `?sandbox=true` to target the sandbox. | Method | Path | Body | Step the VR must be on | | ------ | ----------------------------------------------------------------------- | ------------------------------- | ---------------------- | | `POST` | `/flow/{flow_id}/vr/{verification_request_id}/kyb/submit-business-info` | `businessInformation`, `submit` | `KYB` | | `POST` | `/flow/{flow_id}/vr/{verification_request_id}/kyb/submit-documents` | `documentUploads`, `submit` | `KYB_DOCUMENTS` | | `POST` | `/flow/{flow_id}/vr/{verification_request_id}/kyb/submit-ubos` | `uboDefinitions`, `submit` | `KYB_UBOS` | | `POST` | `/flow/{flow_id}/vr/{verification_request_id}/kyb/submit-directors` | `directorDefinitions`, `submit` | `KYB_DIRECTORS` | Each returns `202` with `verificationRequestId` and `kybResultId` (the case ID). `submit-documents` additionally returns `documentUploads` carrying **presigned PUT URLs**: upload the files to those URLs immediately after the response returns. The case stays `OPEN` until **every part present in the flow** has been submitted; only then does it move to `PROCESSING`. Reading any satellite's verification request returns the shared result, so a client does not have to hold the anchor's ID to show progress. ### The two-phase `submit` flag Each payload carries a `submit` boolean, defaulting to `true`: - **`submit: false`** saves progress. The part stays open and the applicant can come back to it. - **`submit: true`** marks the part submitted. Once every part of the flow is submitted, the case moves to `PROCESSING` and its checks start. Use `submit: false` for autosave and multi-screen parts; send `submit: true` on the last screen of the part. A final submit runs the part's real validation, which a draft save skips: | Part | What a final submit enforces | | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Business info | Company screening is queued; the document part is reopened if resolving the company's country made more documents required; ownership discovery is started when enabled. | | Documents | Every required document for the resolved country must be present. `documentUploads: null` on a final submit means "finalize what was already saved"; it never clears them. | | UBOs, directors | Caps from `maxUbos` / `maxDirectors`. When `requireKyc` is on, **every declared person must carry an email address**, otherwise the call is rejected. Any outstanding declaration request for that part is fulfilled. | :::note[Non-registered businesses] `businessInformation` on `submit-business-info` is nullable. Send `null` for a business that is not registered: the sole-proprietor path that collects a single owner directly. ::: ### The legacy monolithic endpoint `POST /flow/{flow_id}/vr/{verification_request_id}/kyb/process-kyb-document` is unchanged and remains the submission path for a monolithic KYB step. It enforces the same validation and upload caps as the split endpoints. Posting a per-part submission to a monolithic flow returns a `400` naming this endpoint. ## Checking a US business's EIN With `tinCheckEnabled` on the anchor, a business registered in the US is asked for its **EIN** (Employer Identification Number), and its business information is accepted only once the EIN and the company name match IRS records. The match is a [TIN check](/docs/guides/tin-check), and needs the TIN Check product. Businesses outside the US, and non-registered businesses, are not asked. The widget sends the EIN as `ein`, next to `businessInformation`, on `submit-business-info` (and on the legacy `process-kyb-document`). It is not part of the business information and is never stored: the check keeps its last four digits only. The hyphen applicants type (`12-3456789`) is accepted. A final submission (`submit: true`) is refused with `422` when the EIN does not let it through. The answers are kept as a draft, so the applicant corrects the EIN or the company name and submits again: | Error tag | Code | When | | ------------------------------ | ------- | ------------------------------------------------------------------------------------ | | `tin_check_ein_required` | `12809` | No EIN was sent. | | `tin_check_mismatch` | `12810` | The EIN and the company name do not match IRS records, or the IRS has not issued it. | | `tin_check_attempts_exhausted` | `12811` | Three checks of this submission did not match. No further check is run. | An unavailable lookup answers `503` with `tin_check_unavailable`. Once a check has matched, a retried submission with the same company name reuses it and needs no EIN. Each check that returns an answer is charged to your organization as a TIN check, match or not. In sandbox, checks are free and answered from sample data: `12-3456789` (any EIN outside the `000000` prefix) matches, and `00-0000000` does not. The checks appear on the KYB result page in the dashboard, and with your organization's other checks under **Compliance → TIN Check**. Over the API, list a KYB result's checks with `GET /sdk/organizations/{organization_id}/tin-checks?flowResultId=…`. ## Prefilling from official registers Two applicant-facing endpoints let the widget prefill the business-information form from official business registers before the applicant confirms it: | Method | Path | Purpose | | ------ | ---------------------------------------- | ------------------------------------------------------------------ | | `GET` | `.../kyb/company-search?country=&query=` | Search by company name or registration number. Returns candidates. | | `POST` | `.../kyb/company-prefill` | Fetch a chosen candidate's details as prefill values. | | `GET` | `.../kyb/director-candidates` | Re-read any director suggestions from the persisted snapshot. | `company-search` returns `available: false` with an empty candidate list when no source serves that country. That is **not an error**: the widget hides the search box. The covered jurisdictions are listed in [Country coverage](./country-coverage.md). `company-prefill` returns `authoritative: false` when the values came from a non-authoritative search hit; the authoritative record is fetched after submission and the cross-check compares the applicant's submission against it. Director candidates are commonly empty, since officer data is not always available for a country. Treat an empty list as normal and collect directors from the applicant. These endpoints are rate limited per verification request: 30 searches and 10 prefills per minute. ## Step outputs in Flow Builder Each satellite writes its own step output, which [Flow Builder](../create-a-flow/index.mdx#10-flow-builder) conditions can branch on: | Step | Output fields | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | `KYB` | `status`, `moderationStatus`, `pepAndSanctionsStatus`, `businessName`, `registrationNumber`, `country`, `amlPep`, `amlSanctions`, `amlRiskScorePercent` | | `KYB_DOCUMENTS` | `uploadedCount`, `requiredSatisfied` | | `KYB_UBOS` | `uboCount`, `allUbosVerified` | | `KYB_DIRECTORS` | `directorCount`, `allDirectorsVerified` | ## Related - [KYB overview](./index.mdx): creating a flow, the applicant experience, the case statuses - [Reviewing KYB cases](./reviewing-cases.mdx): working and deciding a case - [Compliance policy](./compliance-policy.md): the rules decisions follow - [Ownership discovery](./ownership-discovery.md): automatic UBO discovery and graph expansion - [KYB Agentic Review Engine](./agentic-review-engine.mdx) - [Webhook endpoints](/docs/guides/webhook/endpoints): where KYB outcomes are delivered --- ## Accepting Partner Invitations ## Overview If your organization has been invited to access KYC verification results from a partner organization through KYC Passport, this guide will help you accept the invitation and start accessing shared flow results. ## Prerequisites Before accepting a partner invitation, you need: - An invitation email from the partner organization - The invitation code (OTP) included in the email - Admin access to your organization (for existing users) - Or, ability to register a new organization (for new users) ## For Existing Organizations If you already have an organization on the Zyphe platform, follow these steps: ### Step 1: Check Your Invitations When you receive a partner invitation, you'll be notified through: - Email notification with invitation details - In-app notification in your dashboard ### Step 2: Review the Invitation Log in to your dashboard and navigate to **KYC Passport → Incoming Invites** to view pending invites (the sidebar entry shows a badge with the number of pending invitations). Each invitation shows: - The inviting organization's name - The flow name and type - What data will be shared - When the invitation was sent - Expiration date of the invitation ### Step 3: Accept or Reject After reviewing the invitation details: 1. Find the invitation in the **Pending Invites** list 2. Choose to **Accept Invite** or **Reject Invite** 3. Alternatively, follow the secure link in the invitation email, which uses the verification code to accept the invitation :::info[Access to Data] Once you accept an invitation, you immediately gain access to all flow results created from the moment the invite was sent, provided users have given consent to share data with your organization. ::: ### Step 4: Access Shared Flow Results After accepting the invitation: 1. Navigate to **KYC Passport → Flow Results** in your dashboard 2. You'll see all flow results shared from partner organizations 3. Filter by partner organization or flow name 4. Click on a result to view the full verification data ## For New Organizations If you don't have an account on the Zyphe platform yet: ### Step 1: Receive the Invitation You'll receive an email with: - A secure invitation link - A verification code (OTP) - The inviting organization's name - Flow details that will be shared ### Step 2: Click the Invitation Link The link in the email will direct you to the organization registration page with the invitation pre-filled. ### Step 3: Complete Organization Registration Fill out the organization registration form with: - Organization name - Your admin email (pre-filled from invite) - Password for your account - Organization details - Verification code from the email ### Step 4: Automatic Acceptance Once you complete the registration: - The invitation is automatically accepted - Your new organization is linked to the invitation - You immediately gain access to shared flow results - You can start accessing verification data from the partner ### Step 5: Set Up Your Organization After registration, you can: - Add team members to your organization - Configure notification preferences - Review shared flow results - Set up your own flows if needed ## Understanding Shared Data Access When you accept a partner invitation, you gain access to: ### Available Data - Verified identity documents - Personal information (name, date of birth, address, etc.) - Verification results and status - Any additional data collected in the flow (forms, wallet verification, etc.) ### Data Limitations - **Time-based access**: You can only access data from users who completed verification **after** the invite was created - **Consent-based**: You can only view data from users who explicitly consented to share with your organization - **Flow-specific**: Access is limited to the specific flow mentioned in the invitation ### No Access To - Historical data from before the invitation was sent - Data from users who declined consent - Data from other flows not included in the invitation ## Invitation Lifecycle ### Invitation Validity Partner invitations have an expiration period: - Invitations are valid for a limited time (check the email for specific expiration) - Expired invitations cannot be accepted - Partners can resend expired invitations with a new code ### Resent Invitations If your invitation expires or you didn't receive it: - Contact the partner organization to resend the invitation - You'll receive a new email with a fresh verification code - The previous invitation code will no longer work ### Rejected Invitations If you reject an invitation: - The invitation is permanently closed - No data is shared with your organization - The partner can send a new invitation if needed in the future ## Compliance Ensure your organization: - Has a legal basis for processing shared data - Provides privacy notices to end users if needed - Respects user rights (access, deletion, etc.) - Maintains proper data processing agreements with partners ## Need Help? If you have questions or need assistance: - Review the [FAQ](./faq) for common questions and troubleshooting - Contact the inviting organization directly - Reach out to Zyphe support --- ## Frequently Asked Questions Common questions about KYC Passport, partner invitations, user consent, and data access. ## General Questions ### What is KYC Passport? KYC Passport is a feature that enables organizations to securely share verified KYC data with partner organizations. It creates a trusted ecosystem where users verify once and partners can securely access the verification results with proper consent. ### How does KYC Passport benefit my organization? KYC Passport enables you to: - Share verification results with trusted partners - Reduce verification friction for users in your ecosystem - Build partner networks without compromising user privacy - Maintain compliance while enabling data sharing ## Inviting Partners ### Can I invite multiple partners to the same flow? Yes, you can invite as many partners as needed to a single flow. There is no technical limit on the number of partners. However, for user experience and compliance reasons, it's recommended to limit the list to partners that are essential for the user's journey. ### What happens if a user completes verification before a partner accepts the invite? The access grant is created when the user completes verification (with consent). When the partner later accepts the invite, they gain immediate access to that data. The grant is created in an inactive state and becomes active once the partner accepts. ### Can partners access historical data? No. Partners can only access data from users who completed verification **after** the invite was created. This ensures users have visibility into which partners their data will be shared with at the time of verification. ### What data do partners receive? Partners receive the same KYC data that your organization has access to for the specific flow, including: - Verified identity documents - Personal information (name, date of birth, address, etc.) - Verification results and status - Any additional data collected in the flow The exact data depends on the flow configuration and document types verified. ## Managing Invitations ### Can I see which users' data a partner has accessed? Currently, you can see that a partner has accepted an invitation and has general access to the flow. Detailed per-user access logs are available through your organization's audit logs. ### What happens to data a partner already accessed if I revoke their access? Revoked access prevents the partner from accessing new flow results. However, data they've already accessed and stored remains available until their retention obligations are met. Partners should follow their data retention policies for already accessed information. ### Can I temporarily suspend a partner's access? Access revocation is permanent. If you need temporary suspension, consider creating time-limited flows or coordinating directly with the partner organization. ### Will users be notified when I revoke a partner's access? Users are not automatically notified when partner access is revoked. If you want to inform users, you should communicate this through your own channels. ### Can I change a partner's email address after sending an invitation? Yes, as long as the invitation hasn't been accepted or revoked. Find the invitation in the **KYC Passport → Outgoing Invites** list, click the action menu (three dots), and select **Edit** to update the organization name or email address. ### How do I resend an invitation? Find the pending invitation in the **KYC Passport → Outgoing Invites** list, click the action menu (three dots), and select **Resend Invite**. A new email with a fresh verification code will be sent. The previous code will no longer work. ## Accepting Invitations ### What if I didn't receive the invitation email? - Check your spam/junk folder - Verify the email address with the inviting organization - Ask them to resend the invitation - Check with other admins in your organization in case they received it ### Can I accept an invitation if my organization doesn't exist yet? Yes! If you don't have an account on the Zyphe platform, the invitation will guide you through the organization registration process. Once you complete registration, the invitation is automatically accepted. ### What happens if I reject an invitation? If you reject an invitation: - The invitation is permanently closed - No data is shared with your organization - The partner can send a new invitation if needed in the future ### How long are invitations valid? Invitations have a built-in validity period for security purposes. The exact duration is specified in the invitation email. If an invitation expires, the partner can resend it with a new verification code. ### Can multiple people in my organization accept the same invitation? No. Each invitation can only be accepted once. The first admin to accept it will link the invitation to your organization. Other admins will have access to the shared data once the invitation is accepted. ## User Consent ### Can users revoke consent after verification? Users cannot directly revoke consent, but they can request data deletion through your organization's data protection procedures. When a deletion request is received, you should revoke partner access as appropriate. ### What if a user wants to share data with some partners but not others? Currently, consent is all-or-nothing for the partners listed at verification time. Consider creating multiple flows with different partner combinations if you need granular control. ### How long does user consent last? Consent lasts for the duration specified in your privacy policy and data retention policy. Ensure these align with regulatory requirements in your jurisdiction. ### Can I add partners to a flow without getting new consent from users? No. Partners invited after a user completes verification do not receive access to that user's data, specifically to maintain the integrity of the original consent. This ensures users always know which organizations will receive their data at the time of verification. ### How does this work with multi-step flows? Consent is typically shown at the beginning of the flow or before the first step that collects personal information. Once provided, it applies to all data collected in that flow session. ### What happens if a user declines consent? If a user declines consent, they cannot proceed with verification for that flow. Consider creating alternative flows without partner sharing for users who prefer not to share their data. ## Troubleshooting ### "Invalid Verification Code" - Double-check the code from your email - Codes are case-sensitive - Request a new invitation if the code has expired ### "Invitation Already Used" - This invitation has already been accepted - Check if someone else in your organization already accepted it - Contact the partner if you need clarification ### "Invitation Expired" - The invitation validity period has passed - Contact the partner organization to resend the invitation - You'll receive a new code with extended validity ### "Email Mismatch" - Make sure you're using the email address the invitation was sent to - Contact the partner if the wrong email was used - They can send a new invitation to the correct email ### "Invite has been revoked" - The inviting organization has cancelled this invitation - Contact them to understand why it was revoked - They can send a new invitation if appropriate ### "Invite not for this organization" - The invitation is linked to a different organization - Ensure you're logged into the correct organization - Contact the inviting organization if there's a mismatch ## Data Access & Security ### How is shared data secured? All data is secured using: - Cryptographic access grants - End-to-end encryption - Decentralized storage Partners never receive raw access to storage, only through properly authorized access grants. ### Can partners share the data with others? Partners should only use the data for the purposes agreed upon in your data sharing agreement. Technical limitations prevent them from creating additional partner invites for your flow data. ### What happens to my data if a partner has a security breach? Partners are responsible for securing any data they access and store. Ensure your data sharing agreements include security requirements and breach notification procedures. ## Technical Questions ### Does KYC Passport work in sandbox mode? Yes. All KYC Passport features are available in sandbox mode for testing. We strongly recommend testing the complete flow in sandbox before inviting production partners. ## Best Practices ### How should I choose which partners to invite? Consider: - Business need: Does the partner genuinely need the data? - Trust level: Do you have a strong relationship with the partner? - Compliance: Does the partner meet your security and privacy standards? - User benefit: Does sharing improve the user experience? ### How many partners should I invite per flow? Limit partners to those essential for the user's journey. Too many partners can: - Overwhelm users during consent - Increase compliance complexity - Raise privacy concerns Generally, 1-5 partners is reasonable for most use cases. ### Should I invite partners before or after creating a flow? Ideally, invite partners after creating the flow but before users start verifying. This ensures: - Partners appear in user consent - Users know all recipients at verification time - Proper access grants are created ### How often should I review partner access? Conduct regular audits: - Monthly reviews of active partnerships - Quarterly compliance reviews - Immediate review if partnerships end - Annual comprehensive security assessments ## Still Have Questions? If your question isn't answered here: - Check the [technical documentation](/docs/data-flows/kyc-passport) for detailed information - Review the individual guides: - [Inviting Partners](./inviting-partners) - [Managing Invitations](./managing-invitations) - [Accepting Invitations](./accepting-invitations) - [User Consent](./user-consent) - Contact our support team --- ## KYC Passport ## Overview The KYC Passport feature enables you to share verified KYC data with partner organizations, creating a trusted ecosystem where users verify once and partners can securely access the verification results with proper consent. This section provides comprehensive guides for organizations looking to implement KYC Passport, including: - **Inviting partner organizations** to share flow results - **Managing partner invitations** (resend, revoke, track status) - **Accepting partner invitations** from other organizations - **Understanding user consent** and privacy requirements ## Prerequisites Before using KYC Passport, ensure you have: - An active flow created on the Zyphe platform - Admin access to your organization - Understanding of data sharing agreements and compliance requirements ## Quick Start ### For Organizations Inviting Partners If you want to share your flow results with partner organizations: 1. Start with [Inviting Partner Organizations](./inviting-partners) to learn how to send invitations 2. Review [Managing Partner Invitations](./managing-invitations) to track and control partner access 3. Understand [User Consent and Privacy](./user-consent) to ensure compliance ### For Organizations Receiving Invitations If you've been invited by a partner to access their flow results: 1. See [Accepting Partner Invitations](./accepting-invitations) for step-by-step guidance 2. Review [User Consent and Privacy](./user-consent) to understand data access rules ## Key Features ### Partner Ecosystem Create a trusted network of partner organizations that can securely access verified user data without requiring repeated verification. ### User-Centric Consent Users maintain full control by providing explicit consent during verification, with clear visibility into which organizations will receive their data. ### Cryptographic Security Access grants use advanced cryptography to ensure only authorized partners can access data, with full audit trails. ### ⏱️ Time-Based Access Partners can only access data from users who completed verification after the invitation was created, ensuring proper consent transparency. ### Access Management Track invitation status, resend invitations, and revoke access at any time through an intuitive dashboard interface. ## How It Works 1. **Organization A** creates a KYC flow and invites **Organization B** as a partner 2. **Organization B** receives an email invitation and accepts it (or creates an account if new) 3. A **User** goes through verification on Organization A's flow 4. During the process, the **User** sees and consents to sharing data with both organizations 5. Both **Organization A** and **Organization B** can now access the user's verification results 6. Access is secured through cryptographic access grants and can be revoked at any time ## Related Documentation - [KYC Passport Technical Documentation](/docs/data-flows/kyc-passport) - Detailed technical architecture and data flows - [Reusable Credentials / One-Click KYC](/docs/reusable-credentials-one-click-kyc) - Enable users to reuse credentials across services ## Need Help? If you have questions or need assistance with KYC Passport: - Contact our support team - Check out the dedicated [FAQ](./faq) section - Review the [technical documentation](/docs/data-flows/kyc-passport) --- ## Inviting Partner Organizations This guide walks you through the process of inviting partner organizations to access KYC verification results from your flow. ## Prerequisites Before inviting partners, ensure you have: - An active flow created on the Zyphe platform - Admin access to your organization - Partner organization's admin email address - Partner organization's name ## Step 1: Navigate to Your Flow Log in to the Zyphe Dashboard and navigate to the **Flows** section. Select the flow you want to share results from. ## Step 2: Open the Flow Partners Page In the flow details header, click the **Flow Partners** badge (it also shows the current number of partners). This takes you to the **Outgoing Invites** page, pre-filtered for the selected flow.
Click the Flow Partners badge in the flow header to manage partner invitations for that flow
:::tip You can also reach the same page from the sidebar via **KYC Passport → Outgoing Invites**, where you can see invitations across all your flows and filter by flow. ::: ## Step 3: Invite a New Partner On the **Outgoing Invites** page, click the **Invite Partner** button to open the partner invitation dialog.
The Outgoing Invites page lists all partner invitations and lets you invite new partners
## Step 4: Fill in Partner Details In the invitation dialog, provide the following information: - **Flow**: The flow whose results will be shared (pre-selected if you arrived via the Flow Partners badge) - **Organization Name**: The name of the partner organization (this will be displayed to users during consent if the organization has not yet completed registration) - **Organization Email**: The email address of the partner organization's administrator who will receive the invitation
Enter the partner organization's name and admin email
## Step 5: Send the Invitation Click **Submit** to send the invite. The partner will receive an email with: - A secure invitation link - A verification code (OTP) - Instructions on how to accept the invitation ## What Happens Next? ### For New Organizations If the invited partner doesn't have an account on the Zyphe platform: 1. They receive an email invitation with a secure link and verification code 2. Clicking the link directs them to the organization registration process 3. During registration, they'll use the verification code to confirm the invitation 4. Once registered, the invitation is automatically accepted 5. The new organization immediately gains access to shared flow results (from the invite creation date forward) ### For Existing Organizations If the partner already has an account: 1. The admin receives the invitation via email and in-app notifications 2. They can review the invitation details in their dashboard under **KYC Passport → Incoming Invites** 3. They can choose to **Accept** or **Reject** the invitation 4. If accepted, they gain access to all flow results from the moment the invite was created 5. If rejected, no data is shared and the invitation is closed ## Data Access for Partners Once a partner accepts the invitation and users provide consent: - Partners can view shared flow results through their dashboard - They access data through the **KYC Passport → Flow Results** section - Partners can only access data from users who: - Completed verification **after** the invite was created - Explicitly consented to share data with the partner ## Need Help? If you encounter any issues or have questions about inviting partners: - Check the [FAQ](./faq) for common questions - Contact our support team - Review the detailed [KYC Passport technical documentation](/docs/data-flows/kyc-passport) --- ## Managing Partner Invitations After sending invitations to partner organizations, you can track their status, resend invitations, and revoke access when needed. ## Viewing Partner Invitations All partner invitations are visible on the **Outgoing Invites** page, under **KYC Passport → Outgoing Invites** in the sidebar. You can also open it by clicking the **Flow Partners** badge in a flow's details header, which pre-filters the list for that flow.
The Outgoing Invites page displays all invited partner organizations and their invitation status
### Invitation Statuses The invitations list shows the status of each invitation: - **Pending**: Invitation sent but not yet accepted by the partner organization - **Accepted**: Partner has accepted the invitation and has access to flow results - **Rejected**: Partner has declined the invitation (no data is shared) Each invitation entry displays: - Partner organization name - The flow the invitation applies to - Partner admin email - Invitation status - Whether the invitation is still valid (revoked or expired invitations are marked as not valid) - Creation date and expiration date (**Valid until**) ## Editing an Invitation As long as an invitation hasn't been accepted or revoked, you can edit its details (e.g. fix the organization name or email): 1. Find the invitation in the **Outgoing Invites** list 2. Click the action menu (three dots) next to the invitation 3. Select **Edit** and update the details ## Resending Invitations If a partner hasn't responded to an invitation, you can resend it with a new verification code. ### When to Resend - The partner hasn't received or can't find the original invitation - The verification code has expired - You want to send a reminder to the partner ### How to Resend 1. Find the pending invitation in the **Outgoing Invites** list 2. Click the action menu (three dots) next to the invitation 3. Select **Resend Invite** 4. A new email with a fresh verification code is sent to the partner :::info Resending an invitation generates a new verification code. The previous code will no longer work. ::: ## Revoking Partner Access You can revoke a partner's access at any time, immediately ending their ability to view shared flow results. ### When to Revoke Access - The partnership has ended - The partner no longer needs access to the data - Security or compliance concerns arise - You want to limit the number of partners with access ### How to Revoke 1. Find the partner in the **Outgoing Invites** list (any status except rejected) 2. Click the action menu (three dots) next to the partner 3. Select **Revoke Access** 4. Confirm the revocation in the dialog ### What Happens After Revocation - The partner immediately loses access to all shared data for that flow - They will no longer see the flow in their **Flow Results** section - The invitation is marked as no longer valid in the Outgoing Invites list, along with the revocation date - Access to historical data they've already accessed remains until retention obligations are met :::warning[Important] Revoking access is permanent. The partner organization will need to be invited again if access should be restored in the future. Note that if access is revoked, it remains available until the partner's data retention obligations are met. ::: ## Need Help? If you have questions about managing partner invitations: - Check the [FAQ](./faq) for common questions - Contact our support team - Review the [KYC Passport technical documentation](/docs/data-flows/kyc-passport) --- ## User Consent and Privacy User consent is central to the KYC Passport functionality. This guide explains how user consent works, what users see, and important compliance considerations. ## Overview When users go through verification on a flow with partner sharing enabled, they must provide explicit consent before their data can be shared with partner organizations. ## The Consent Process ### When Consent is Requested During the verification flow, users encounter a privacy consent step that clearly discloses: 1. **The main organization** they're verifying with 2. **All partner organizations** that will receive their data 3. **The types of data** that will be shared 4. **Why the data is being shared** (optional, based on your configuration) ### What Users See Users see a clear consent screen listing all organizations that will have access to their verification data:
Users see a clear list of all organizations that will receive their data during the consent step
The consent screen includes: - **Organization names**: Your organization and all invited partner organizations - **Data types**: What information will be shared (identity documents, personal information, verification results) - **Consent checkbox**: Users must explicitly check this to proceed - **Clear language**: Easy-to-understand explanation of data sharing ### User Decision Users have two options: 1. **Provide consent**: Check the consent box and proceed with verification - Their data will be shared with your organization and all accepted partner organizations - Access grants are created for authorized partners - Verification continues normally 2. **Decline consent**: Not check the consent box - They cannot proceed with verification - No data is shared with any organization - No access grants are created :::warning[Important] If a user declines consent, they cannot complete the verification process. Consider creating separate flows without partner sharing for users who prefer not to share their data. ::: ## Consent Rules and Timing ### No Consent = No Access If a user does not consent to data sharing: - No access grants are created for any partner organizations - Only metadata (non-PII) may be stored for analytics - Partners cannot access any verification data - The user must start over if they later decide to consent ### Invite Timing Matters The consent shown to users is based on the partners invited **at the time of verification**: - Partners invited **before** user verification are included in the consent - Partners invited **after** user verification do NOT receive access to that user's data - This ensures users always know which organizations will receive their data **Example Timeline:** ``` Day 1: Organization invites Partner A and Partner B Day 2: User completes verification (sees A and B in consent) Day 3: Organization invites Partner C Result: Partners A and B can access the user's data Partner C CANNOT access this user's data ``` ### Consent is Flow-Specific Each flow has its own partner list and consent: - Users consent to share data for a **specific flow** - They consent to share with the **partners listed at that time** - Consent for one flow does not apply to other flows - Users must consent separately for each flow they complete ## Access Grant Creation When a user consents and completes verification, the system creates cryptographic access grants: ### Grant Creation Rules 1. **Main Organization**: Always receives an access grant when the user completes verification with consent 2. **Accepted Partner Invites**: If the partner has already accepted the invite before the user verified, they receive an access grant immediately 3. **Pending Partner Invites**: An access grant is created but remains inactive until the partner accepts the invite 4. **Rejected Partner Invites**: No access grant is created for partners who rejected invitations 5. **No Consent**: If the user doesn't consent, no partner grants are created (only the main organization receives a grant if verification proceeds through alternative means) ### Grant Lifecycle ```mermaid sequenceDiagram actor User participant BE as Backend participant MO as Main Org participant PA as Partner A(Accepted) participant PB as Partner B(Pending) User->>+BE: Complete verificationwith consent BE->>MO: Create access grant BE->>PA: Create active grant BE->>PB: Create inactive grant Note over PB: Later accepts invite PB->>+BE: Accept invitation BE->>PB: Activate grant ``` ## Need Help? If you have questions about user consent and KYC Passport: - Check the [FAQ](./faq) for common questions - Contact our support team - Consult with your legal/compliance team - Review the [KYC Passport technical documentation](/docs/data-flows/kyc-passport) --- ## Manual Review Manual review lets authorized organization users resolve a document verification (DV) result that automated checks could not finalize. Keep the verification pending until the reviewer decision has been processed and a final webhook arrives. ## How It Works 1. **Flagging:** A DV result that needs a person to decide is exposed by the API as `REQUIRES_MANUAL_REVIEW`. 2. **Notification:** Zyphe sends a webhook with `event: REVIEW`, `flowStatus: REVIEW`, and `data.dv.status: REVIEW`. 3. **Review:** An **Admin** or **Operator** opens Manual Review in the dashboard and inspects the submitted document, reasons, and available checks. 4. **Decision:** The reviewer submits the API decision `approved`, `rejected`, or `failed`. 5. **Final event:** After processing, Zyphe sends `COMPLETED`, `REJECTED`, or `FAILED`. Use that event, not the earlier `REVIEW`, as the final outcome in your product. :::info[DV and KYB use different review vocabularies] `REQUIRES_MANUAL_REVIEW` and the `REVIEW` step status apply to document verification. KYB is reviewed as a case, with its own statuses (`READY_FOR_REVIEW`, `ACTION_REQUIRED`, `APPROVED`, `REJECTED`, and so on) and its own decision rules. See [Reviewing KYB cases](/docs/guides/kyb/reviewing-cases) and [Statuses and codes](/docs/reference/statuses-and-codes#kyb-and-aml-statuses). ::: ## Review Statuses | Reviewer decision | Final webhook | Meaning | | ----------------- | ------------- | ----------------------------------------------------------------- | | `approved` | `COMPLETED` | The reviewer accepts the document verification result. | | `rejected` | `REJECTED` | The reviewer explicitly declines the result. | | `failed` | `FAILED` | The verification cannot be completed, for example due to quality. | ## Permissions The customer organization roles that can perform DV manual review are: - **Admin** (`ORG_ADMIN`): full organization access, including manual review. - **Operator** (`ORG_OPERATOR`): can inspect and decide results waiting for manual review. Platform administrators are internal Zyphe personnel, not a customer organization role. The full customer role matrix is maintained in [Manage Users](/docs/guides/manage-users). ## Webhook Events - `REVIEW`: sent when a DV result is flagged; keep the user pending. - `COMPLETED`, `FAILED`, or `REJECTED`: sent after the reviewer decision is processed and represents the final outcome. ## Related Documentation - [Webhook Integration](/docs/guides/webhook) - [Webhook Payload](/docs/guides/webhook/webhook-payload) - [Statuses and Codes](/docs/reference/statuses-and-codes#manual-review) --- ## Model Context Protocol (MCP) Zyphe ships a built-in [Model Context Protocol](https://modelcontextprotocol.io) server that lets AI agents and MCP-compatible clients (Claude Desktop, Claude Code, Cursor, and any other MCP host) both **configure** your organization — flows, forms, API keys — and **operate on compliance cases** — KYB files, AML screenings, KYC results, and the audit trail. Instead of writing REST clients or learning the dashboard UI, you can ask your AI assistant _"create a new KYC flow with a document verification step and a form"_, or _"show me what happened to this KYB case and who did it"_. The agent calls the right MCP tools on your behalf. :::info The MCP server is exposed by the same Zyphe API server that handles REST traffic. There is no separate process or port to run. ::: ## Capabilities at a glance The MCP server exposes **39 tools** in eight groups. Fourteen of them work KYB cases, three dispose of AML screening hits, and two read a KYC case and the audit trail, so an agent can carry a review from open case to approval or escalation — and evidence what it did — not only configure the flows that produce them. - **KYB**: read a KYB result, request and review business-information clarifications, correct field values, add or remove UBOs and directors, request per-country documents, send UBO KYC invitations, set the screening strategy, approve, or escalate to admin review. - **AML**: read a screening result, clear a false positive, or escalate to a human reviewer. - **KYC**: read a verification case as a decision summary. - **Audit trail**: read the organization's tamper-evident audit log. - **Flows**: list, create, read, update, delete flows; manage flow-level settings (branding, webhooks). - **Flow steps**: add, update, and delete steps inside a flow (DV, FORM, POA, KYB, KYB_DOCUMENTS, KYB_UBOS, KYB_DIRECTORS, SPID, PHONE, WALLET, LIVENESS, AUTO_ONE_CLICK_KYC, DOCUMENT_SELECTION, GEOLOCATION). - **Forms**: list, create, read, update, delete forms with their sections. - **API keys**: list, create, read, update, delete API keys (SECRET and PUBLISHABLE). The KYB and AML write tools are **guarded server-side**. `approve_kyb_result` refuses while any clarification is open or any document-backed field is not a match, and `clear_aml_result` refuses on a high-confidence sanctions match, Critical overall risk, a result already under a human verdict, or a screening with no identity discriminators. The guard is deterministic and lives on the server, so it holds whatever the calling model decides. Every `tools/call` is recorded as a readable audit row carrying the tool name, redacted arguments, the mapped action, and the target resource id. Protocol traffic (`initialize`, `tools/list`, `ping`) is not logged, and neither are the unauthenticated probes MCP clients make before completing authentication. See [Auditing](#auditing). Every tool accepts an optional `sandbox: boolean` flag so you can target the sandbox environment from the same connection. :::tip[New in this release] `get_kyc_result` and `get_audit_trail` let an agent read a KYC case and evidence its own work against the audit log. See [Reading cases and evidence](#reading-cases-and-evidence). ::: ## Authentication The MCP server is authenticated with **bot tokens**. Bots are organization-scoped service identities; their permissions are evaluated by the same role-based access control policies that govern the REST API, so a bot can only do what its assigned role is allowed to do. ### 1. Create a bot and obtain a token Bot management lives under `/organizations/{organization_id}/bots/...` in the REST API:
Create and manage bot identities from the Bots page in the dashboard.
| Method | Path | Purpose | | -------- | -------------------------------------------------------- | ---------------------------------------- | | `GET` | `/organizations/{org_id}/bots/list` | List bots in the organization | | `POST` | `/organizations/{org_id}/bots/create` | Create a new bot (returns plain token) | | `GET` | `/organizations/{org_id}/bots/{bot_id}/get` | Fetch bot metadata | | `POST` | `/organizations/{org_id}/bots/{bot_id}/regenerate-token` | Issue a new token; the previous one dies | | `DELETE` | `/organizations/{org_id}/bots/{bot_id}/delete` | Soft-delete the bot | The plain-text token is returned **only once** at creation (or regeneration). It looks like:
Create a bot to obtain a token that MCP-compatible clients can use.
``` zyphe_bot_<48 random alphanumeric characters> ``` :::warning[Store the token securely] Tokens are SHA-256 hashed on the server, so Zyphe cannot retrieve a lost token. If you misplace one, regenerate it. Treat bot tokens like passwords: never commit them to source control, never paste them into chat logs. ::: ### 2. Use the token Send it as a `Bearer` token on the `Authorization` header: ```http Authorization: Bearer zyphe_bot_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ``` Authentication failures are answered with `401 Unauthorized` and a JSON body that distinguishes the two cases: | Situation | Body | | -------------------------------------------------------- | ------------------------------------------ | | No `Authorization` header at all | `{"error":"Missing Authorization header"}` | | A header that is not a well-formed `Bearer` credential | `{"error":"Invalid bot token"}` | | A well-formed `Bearer` credential whose token is unknown | `{"error":"Invalid bot token"}` | A malformed header used to be reported as a missing one, which sent client authors looking for a header they were in fact sending. It is now answered as the bad credential it is. If the bot's role does not allow the requested operation, the tool call returns an MCP error with code `INVALID_REQUEST` and message `"Permission denied"`. :::note[Unauthenticated probes are not audited] MCP clients routinely request `/mcp` without credentials while probing the endpoint before completing authentication. Those rejected probes no longer write anything to your audit trail, and neither does protocol chatter such as `initialize`, `tools/list`, or `ping`. **Real tool invocations are still audited**, as readable per-call events — see [Auditing](#auditing). ::: ## Endpoint The MCP server is mounted on the same host and port as the Zyphe API: ``` POST {ZYPHE_API_BASE_URL}/mcp ``` It uses the **Streamable HTTP** transport from the MCP specification. Any MCP-compliant client that supports HTTP transport can connect to it. ## Connecting a client ### Claude Desktop / Claude Code Add an entry to your `mcp.json` (or the equivalent config UI): ```json { "mcpServers": { "zyphe": { "transport": { "type": "http", "url": "https://api.zyphe.com/mcp", "headers": { "Authorization": "Bearer zyphe_bot_YOUR_TOKEN_HERE" } } } } } ``` Replace `https://api.zyphe.com` with the URL of your Zyphe deployment, and substitute your bot token. ### Cursor Cursor supports MCP via the same JSON config format. Add the snippet above to your Cursor MCP settings. ### Generic / programmatic Any MCP client SDK (TypeScript, Python, etc.) that supports the streamable-HTTP transport can talk to `/mcp`. Point the transport at the URL and inject the `Authorization` header. ## Tool reference All parameters use **camelCase** keys. Every tool also accepts an optional `sandbox` boolean (default `false`) to target the sandbox environment instead of production. ### KYB Tools that work an existing KYB result. All of them take `kybResultId`, the UUID of the KYB result. #### `get_kyb_result` Read-only. Get a KYB result by its ID, scoped to the bot's organization. | Field | Type | Required | Description | | ------------- | ------- | -------- | --------------------------------- | | `kybResultId` | string | yes | UUID of the KYB result | | `sandbox` | boolean | no | Read from the sandbox environment | #### `get_pending_kyb_clarifications` Read-only. List pending clarification requests for a KYB result. Required: `kybResultId`. #### `send_kyb_clarification_request` Write. Request business-information clarification from the client. Moves the KYB next action to Client. | Field | Type | Required | Description | | -------------- | -------- | -------- | ----------------------------------------------- | | `kybResultId` | string | yes | UUID of the KYB result | | `documentName` | string | yes | Clarification request title shown to the client | | `fields` | string[] | yes | Business information field keys to clarify | | `description` | string | no | Clarification instructions for the client | #### `review_kyb_clarification_field` Write. Approve one submitted clarification field, but **only** when the cross-check classified it as an exact, auto-correct, or fuzzy match against the document-collected value. Does not approve the KYB. Required: `kybResultId`, `documentRequestId`, `fieldKey`. #### `approve_kyb_result` Write. Guarded final KYB approval. Approves only when no clarifications remain open and every document-backed business-information verification field is an exact, auto-correct, or fuzzy match. | Field | Type | Required | Description | | ------------- | ------ | -------- | ----------------------------------- | | `kybResultId` | string | yes | UUID of the KYB result | | `reason` | string | no | Audit reason for the agent approval | #### `mark_kyb_for_admin_review` Write. Safely escalate a KYB result to human review. Does not approve the KYB. Required: `kybResultId`, `reason`. #### `send_ubo_kyc_reminder` Write. Send the KYC invitation or reminder email to a single UBO, identified by its zero-based index in `uboDefinitions`. For an un-onboarded UBO this sends the initial invitation. Required: `kybResultId`, `recipientIndex` (integer, minimum 0). #### `edit_kyb_business_information` Write. Directly correct one or more business-information field values as a reviewer edit. Each edited field is marked as a verification match and any pending clarification on it is auto-resolved. Allowed only while the KYB result is under review. | Field | Type | Required | Description | | ------------- | -------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `kybResultId` | string | yes | UUID of the KYB result | | `updates` | object[] | yes | Each `{ fieldKey, value }`. Keys include `companyName`, `registrationNumber`, `country`, `address`, `city`, `postZipCode`, `businessActivity`, `incorporationDate`, `companyType`, `contactEmail` | | `reason` | string | yes | Reason for the correction, recorded in the activity log | #### `add_kyb_ubos` Write. Add one or more UBOs to an existing KYB result. A UBO **with** an email is sent a KYC invitation and must complete full KYC; a UBO **without** an email is screened by name only (AML) and is not notified. Allowed only while the KYB is under review. | Field | Type | Required | Description | | ------------- | -------- | -------- | ------------------------------------------------------------------------------------------- | | `kybResultId` | string | yes | UUID of the KYB result | | `persons` | object[] | yes | Each requires `firstName`, `lastName`, `dateOfBirth`, `country`, `gender`; `email` optional | #### `remove_kyb_ubo` Write. Remove a UBO by its stable `personId`. Any name-only AML screening for that UBO is removed too. Allowed only while the KYB is under review. #### `add_kyb_directors` Write. Add one or more directors. Same email and name-only semantics as `add_kyb_ubos`. Allowed only while the KYB is under review. #### `remove_kyb_director` Write. Remove a director by its stable `personId`. Any name-only AML screening for that director is removed too. #### `request_kyb_document` Write. Request a specific on-demand per-country document by its catalog key, validated against the KYB's country, and notify the client. Creates a Standard document request for the client to upload. | Field | Type | Required | Description | | ---------------- | ------ | -------- | ---------------------------------------------------------- | | `kybResultId` | string | yes | UUID of the KYB result | | `documentKey` | string | yes | Catalog key of the on-demand document | | `description` | string | no | Instructions shown to the client | | `recipientEmail` | string | no | Recipient override; defaults to the business contact email | | `subject` | string | no | Notification email subject | | `body` | string | no | Notification email body | #### `set_kyb_screening_strategy` Write. Change which population of natural persons this KYB must identify and screen before it can be approved. Does not approve the KYB. | Field | Type | Required | Description | | ------------- | ------ | -------- | ------------------------------------------------------- | | `kybResultId` | string | yes | UUID of the KYB result | | `strategy` | string | yes | `ubo` (the default), `directors`, or `uboAndDirectors` | | `reason` | string | yes | Why the default test is the wrong one for this business | Use it when beneficial ownership is the wrong test — a listed company with no natural person above the ownership threshold, where directors are the screenable population. It is guarded: it accepts only a strategy the people **already on file** satisfy. Every strategy requires at least one screened person, so no sequence of calls can make an unidentified business approvable by an agent or by automatic completion. A human reviewer keeps their override either way. It emits its own `KYB_SCREENING_STRATEGY_CHANGED` audit entry carrying the previous and new strategy, the reason, and the UBO and director counts at that moment. See [Which population must be screened](./kyb/steps-and-configuration.md#which-population-must-be-screened). ### AML #### `get_aml_result` Read-only. Get an AML screening result by its ID: the scored entity hits, submitted identity, adverse media, moderation state, and flags. Required: `amlResultId`. #### `clear_aml_result` Write. Guarded false-positive clear, moderating the screening to Approved. A deterministic server-side guard refuses to clear a high-confidence sanctions match, a Critical overall risk, a result already under a human verdict, or a screening lacking identity discriminators. | Field | Type | Required | Description | | ------------- | ------ | -------- | -------------------------- | | `amlResultId` | string | yes | UUID of the AML result | | `reason` | string | no | Audit reason for the clear | #### `escalate_aml_result` Write. Escalate a screening to a human reviewer, moderating it to Escalated. Use it for genuine or ambiguous hits, and state in the reason if enhanced due diligence is recommended. Required: `amlResultId`, `reason`. ### Reading cases and evidence Two read-only tools let an agent understand a case before acting on it, and evidence what it did afterwards. #### `get_kyc_result` Read-only. Get a KYC verification case (a flow result) as a **decision summary**: per-step statuses and failure reasons, document-verification scores, the manual-review outcome, AML screening flags, the risk score, assigned risk tags, and the review suggestion. | Field | Type | Required | Description | | -------------- | ------- | -------- | ---------------------------------- | | `flowResultId` | string | yes | UUID of the flow result (the case) | | `sandbox` | boolean | no | Read from the sandbox environment | The case's personal data is withheld by design, and for most of it there is no way to ask again: identity-document contents, submitted form answers, the IP address, and the wallet address are returned by **no tool on this surface at all**. Screened names are the one exception — read them with `get_aml_result` or `get_kyb_result`. #### `get_audit_trail` Read-only. Read the organization's tamper-evident audit log, newest first. Every field is optional. | Field | Type | Description | | --------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `resourceType` | string | PascalCase resource type, e.g. `FlowResult`, `KybResult`, `AmlResult`, `Flow`, `ApiKey`. An unrecognised value is rejected rather than silently matching nothing. | | `resourceId` | string | UUID of the resource whose history you want | | `action` | string | SCREAMING_SNAKE_CASE action, e.g. `VIEWED`, `KYB_APPROVED`, `AML_RESULT_MODERATED`. Rejected the same way an unrecognised `resourceType` is. | | `actorZid` | string | Restrict to one actor (a user email or a bot zid) | | `createdAtFrom` | string | Only entries at or after this RFC 3339 timestamp | | `createdAtTo` | string | Only entries at or before this RFC 3339 timestamp | | `skip` | integer | Entries to skip (default 0) | | `take` | integer | Entries to return (default 25, maximum 100) | Each entry carries its id, its position and hash in the chain, and the action's outcome. An agent sees **its own earlier tool calls** here, with their arguments, so a disposition can be evidenced rather than asserted. The payload of an action taken **outside** the MCP surface is withheld — its top-level keys are named instead — because it can carry the case's personal data. Actor IP addresses and session ids are never returned, and end-user actor identifiers are masked. :::warning[A bot has the authority of its role, not of its agent mode] The **Agent Mode** on a flow step configures which tools Zyphe's own autonomous reviewer is handed for that flow. It is not an authorization control and no tool checks it. A bot with an admin role calling `approve_kyb_result` does exactly what an admin person calling the REST approve endpoint does, on a flow at any agent mode. Scope your bots' roles accordingly. ::: ### Flows #### `list_flows` List flows for the bot's organization, with optional pagination, sorting, and filtering. | Field | Type | Required | Description | | --------- | ------- | -------- | -------------------------------------------------------------------------------- | | `skip` | integer | no | Records to skip (default 0) | | `take` | integer | no | Records to return (default 100) | | `sort` | string | no | Sort field and direction, e.g. `"createdAt:desc"` | | `filter` | string | no | Semicolon-separated triples `"field:operator:value"` (e.g. `"flow_type:eq:KYC"`) | | `sandbox` | boolean | no | Use sandbox environment | #### `create_flow` Create a new flow. **Required:** `name`, `slug`, `successUrl`. | Field | Type | Description | | ------------ | ------- | --------------------------------------- | | `name` | string | Display name of the flow | | `slug` | string | URL-safe identifier (e.g. `"kyc-flow"`) | | `successUrl` | string | Redirect URL on successful completion | | `failureUrl` | string | Redirect URL on failure (optional) | | `sandbox` | boolean | Create in sandbox environment | :::warning[`webhookUrl` is vestigial here] The published tool schema still advertises a `webhookUrl` parameter and lists it as required, but a flow no longer has one: the value is **accepted and ignored**. Configure destinations as [organization webhook endpoints](./webhook/endpoints.md) instead. If your MCP client validates against the advertised schema, pass any placeholder string — it has no effect. ::: #### `update_flow` Update an existing flow's metadata. **Required:** `flowId`, `name`, `slug`, `successUrl`. The same `webhookUrl` caveat applies. #### `get_flow` Get a flow by its ID. **Required:** `flowId`. #### `delete_flow` Soft-delete a flow by its ID. **Required:** `flowId`. #### `get_flow_settings` Get the settings (branding, webhook options, notifications) for a flow. **Required:** `flowId`. #### `update_flow_settings` Update the settings for a flow. **Required:** `flowId`. All other fields are optional and patch-style; only provided fields are changed. | Field | Type | Description | | ----------------- | ------- | ----------------------------------------- | | `webhookSecret` | string | Legacy HMAC secret. See the note below. | | `extendedWebhook` | boolean | Include extended data in webhook payloads | | `published` | boolean | Whether the flow is publicly accessible | :::note[Webhook settings live on the endpoint now] Signing secrets and the extended-payload switch are properties of an [organization webhook endpoint](./webhook/endpoints.md). `webhookSecret` here writes the legacy organization settings field, which the endpoint registry no longer signs with — rotate the organization secret through the webhooks API instead. ::: ### Flow steps #### `create_flow_step` Add a new step to a flow. **Required:** `flowId`, `name`, `stepType`, `config`, `order`. | Field | Type | Description | | ------------ | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `flowId` | string | UUID of the parent flow | | `name` | string | Display name of the step | | `stepType` | string | One of: `DV`, `FORM`, `POA`, `KYB`, `KYB_DOCUMENTS`, `KYB_UBOS`, `KYB_DIRECTORS`, `SPID`, `PHONE`, `WALLET`, `LIVENESS`, `AUTO_ONE_CLICK_KYC`, `DOCUMENT_SELECTION`, `GEOLOCATION` | | `config` | object | Step configuration object (must contain a matching `stepType` discriminator) | | `order` | integer | Position of the step in the flow (0-based) | | `successUrl` | string | Override success redirect URL for this step (optional) | | `failureUrl` | string | Override failure redirect URL for this step (optional) | :::tip Each step type has its own `config` schema. See the [flow-step guides](/docs/guides/create-a-flow/) for the shape of each step's configuration, and [KYB steps and configuration](./kyb/steps-and-configuration.md) for the four KYB step types. ::: :::note The tool's own description string still lists the pre-split step types. The three KYB satellite types are accepted — the description lags the enum. ::: #### `update_flow_step` Update a step's name, config, or redirect URLs. **Required:** `flowId`, `stepId`, `config`. #### `delete_flow_step` Soft-delete a step from a flow. **Required:** `flowId`, `stepId`. ### Forms #### `list_forms` List forms for the bot's organization, with optional pagination and sorting. Same pagination fields as `list_flows` (without `filter`). #### `create_form` Create a new form. **Required:** `name`, `sections`. | Field | Type | Description | | ---------- | ------ | ------------------------------ | | `name` | string | Display name of the form | | `sections` | array | Array of `FormSection` objects | #### `update_form` Update a form's name and/or sections. **Required:** `formId`. #### `get_form` Get a form by its ID. **Required:** `formId`. #### `delete_form` Hard-delete a form by its ID. **Required:** `formId`. ### API keys #### `list_api_keys` List API keys for the bot's organization. #### `create_api_key` Create a new API key. **Required:** `keyType`. The plain-text key is returned **once** in the `key` field of the response, so store it immediately. | Field | Type | Description | | ---------------- | ---------------- | ----------------------------------- | | `keyType` | string | `SECRET` or `PUBLISHABLE` | | `name` | string | Human-readable name (optional) | | `description` | string | Description (optional) | | `allowedOrigins` | array of strings | Allowed CORS origins (optional) | | `options` | object | Additional options as a JSON object | #### `get_api_key` Get an API key by its ID. **Required:** `apiKeyId`. #### `update_api_key` Update an API key's name, description, allowed origins, or options. **Required:** `apiKeyId`. #### `delete_api_key` Soft-delete an API key by its ID. **Required:** `apiKeyId`. ## Sandbox vs production Every tool takes an optional `sandbox` boolean. When `true`, the tool reads and writes against the sandbox dataset; when `false` or omitted, it operates on production data. This means a single bot token can drive both environments, which is useful for agents that build a flow in sandbox, validate it, and then promote it to production in one session. ## Error handling MCP errors follow the standard MCP error model: | Condition | Error code | Notes | | ------------------------------------ | ------------------ | ------------------------------------------------ | | Missing or malformed parameters | `INVALID_PARAMS` | Returned when JSON parsing or schema check fails | | Unknown tool name | `METHOD_NOT_FOUND` | Tool not registered on this server | | RBAC policy denial | `INVALID_REQUEST` | Message: `"Permission denied"` | | Unexpected backend / DB / RBAC error | `INTERNAL_ERROR` | Server-side failure; check Zyphe logs | HTTP-level failures (`401`, `403`) are returned **before** the MCP envelope and indicate problems with the bot token or middleware, not with a specific tool call. ## Auditing Every **tool invocation** writes a readable event to your organization's audit trail, naming the tool, its arguments, and its outcome. That is what makes an agent's work reviewable and lets `get_audit_trail` evidence a disposition rather than assert it. Two things are deliberately **not** audited, because they are noise rather than activity: - MCP protocol chatter — `initialize`, `tools/list`, `ping`. - Unauthenticated requests to `/mcp`. MCP clients probe the endpoint before completing authentication, and every such probe used to leave an actor-less failure row in the trail. Some tools write their own domain events on top of the per-call event — `approve_kyb_result` writes a KYB approval, `set_kyb_screening_strategy` writes `KYB_SCREENING_STRATEGY_CHANGED` — so a reviewer sees the decision, not just the call. ## Example session A typical agent conversation with the Zyphe MCP server might look like this (paraphrased; the agent translates intent into tool calls): > **You:** Create a sandbox flow called "Onboarding Test" with a document verification step. > > **Agent:** > > 1. calls `create_flow` with `{ name: "Onboarding Test", slug: "onboarding-test", successUrl: "...", sandbox: true }` > 2. takes the returned `flowId` and calls `create_flow_step` with `{ flowId, name: "DV", stepType: "DV", config: { stepType: "DV", ... }, order: 0, sandbox: true }` > 3. returns: _"Created sandbox flow `onboarding-test` (id `…`) with one DV step at position 0."_ A case-work session looks different, because the agent is disposing of real compliance work rather than configuring it: > **You:** Take a look at AML result `…` and clear it if it is obviously a false positive. > > **Agent:** > > 1. calls `get_aml_result` with `{ amlResultId: "…" }` and reads the scored hits, submitted identity, and adverse media > 2. decides the hit is a common-name collision with no matching date of birth or nationality > 3. calls `clear_aml_result` with `{ amlResultId: "…", reason: "Name-only collision; DOB and nationality both mismatch the listed entity." }` > 4. returns: _"Cleared. Had the guard refused — high-confidence sanctions match, Critical risk, existing human verdict, or no identity discriminators — I would have escalated instead."_ The agent's judgement is not what makes this safe. The server-side guard is: if the screening had been a high-confidence sanctions match, `clear_aml_result` would have refused the call regardless of what the model concluded, and the correct next step would have been `escalate_aml_result`. ## Security notes - The KYB and AML write tools carry **deterministic server-side guards**. `approve_kyb_result` and `clear_aml_result` refuse unsafe calls on the server, so the guarantee does not depend on the calling model's reasoning or on prompt wording. - Bot tokens authenticate at the request level; the MCP transport does **not** add a separate session layer. - All tool calls are subject to the **same role-based access control policies** that govern the REST API. A bot scoped to a specific role cannot escalate privileges through MCP. - Token hashes are stored with SHA-256; plain-text tokens are never persisted. - Regenerating a bot's token instantly invalidates the previous one. Use this if you suspect leakage. - **A bot has the authority of its role.** A flow step's Agent Mode configures Zyphe's own autonomous reviewer; it is not an authorization boundary and no tool checks it. Give a bot the narrowest role that lets it do its job. - **Personal data is withheld by design.** Identity-document contents, submitted form answers, IP addresses, and wallet addresses are returned by no tool on this surface. Screened names come back only from `get_aml_result` and `get_kyb_result`, and the audit trail masks end-user actor identifiers and never returns actor IPs or session ids. - Every tool call is recorded in the audit trail. See [Auditing](#auditing). --- ## How Scores Are Computed Every enabled score definition produces one outcome per flow result. The computation runs when the flow completes and again on every re‑evaluation, and each outcome is frozen with the tags and factors that contributed to it, so a score can always be re‑explained and audited. For each score definition, the engine runs a three-step pipeline: ```mermaid flowchart LR A["Matched tags+ contextual factors"] --> B["1 · Self score(normalization strategy)"] B --> C["2 · Combine with sources(combination strategy)"] C --> D["3 · Clamp & roundinteger 0–100"] D --> E["LevelLow · Medium · High · Critical"] ``` Scores are evaluated in dependency order, so by the time a score is computed, all of its sources already have a value. ## Tag weight vs contextual factor Keep these two ideas separate: | | **Tag** | **Contextual factor** | | --------- | ----------------------------------------------- | ------------------------------------------------------------------------------- | | Role | The signal itself | The context around that signal | | Effect | A **weight** added into the score | A **multiplier** applied after tags are combined | | Required? | You need at least some tags for a score to move | **No.** Factors are optional. Leave them empty and the tag weights stand as-is. | | Example | `role.pep` (this person is a PEP) | Jurisdiction `IT` vs `KP` (the same PEP is riskier in a high-risk country) | A tag answers “what did we find?”. A contextual factor answers “does the setting make that finding count for more (or less)?”. Worked picture, PEP in two countries (same tag, different factor): - The screening match emits the tag `role.pep`. That weight is the same in both cases. - A **jurisdiction** factor then multiplies the result: Italy (`IT`, a low default multiplier) barely moves the score; a high-risk jurisdiction (for example `KP`) raises it substantially. - Formula after tags are combined: `amplified = base × (1 + Σ multipliers)`. A multiplier of `0.05` is +5%; `0.4` is +40%. Italian **province** of registered office or of the UBO is the same idea at sub-national level. AML jurisdiction factors today are **country** (ISO 3166). To weight Italian provinces now, attach a factor to a form select of provinces (each option a key with its own multiplier). A first-class province factor set can be added as an organization configuration. Factors you do not need can be left unused or deactivated. They never have to be part of a score. ## Inputs - **Score tags**: weighted labels matched on the flow result. Tags come from form answers, workflow actions, and manual assignment. A tag's **weight** expresses how strongly it pushes the score up. See [Tags](/docs/guides/scoring/tags). - **Contextual factors**: optional multipliers that amplify the tag-based result when a contextual signal is present (for example a specific answer value or jurisdiction). - **Sources**: the already-computed results of other scores folded into this one. | Value | Range | Notes | | ----------------- | ----------------------------- | --------------------------------------------------------------------------- | | Tag weight | `-1000` to `100` | Positive contributes; `0` matches but adds nothing; negative acts as a veto | | Factor multiplier | greater than `-1`, up to `10` | `0.5` amplifies the base result by 50% | | Score output | integer `0` to `100` | Always clamped and rounded | ## Step 1: Self score (normalization strategies) The normalization strategy defines how the weights of the matched tags are turned into a percentage. ### Additive share (scorecard): default Classic scorecard math. Tags are organized in **groups**: all the options of one form question form a group (they are mutually exclusive), while a standalone tag is its own group. The score is the share of points obtained out of the points obtainable: ```text base = ( Σ matched weights / Σ per-group maximum active weight ) × 100 ``` Selecting the highest-weighted option of every scored question yields 100%; maxing out one question of two equally weighted ones yields 50%. **Veto tags:** a tag with a _negative_ weight never raises the obtainable maximum, but when matched it subtracts its full magnitude from the obtained points. A strong veto (e.g. `-1000`) forces the score to `0` regardless of the other answers. Vetoed results are not amplified by contextual factors. ### Relative share Scale-invariant: each matched tag contributes its weight as a share of the highest active weight in the definition (`s = w / w_max`), and shares are combined with a probabilistic union: ```text base = ( 1 − ∏ (1 − sᵢ) ) × 100 ``` A single tag at the maximum weight saturates the score to 100%; additional matches push the score asymptotically toward 100% without ever exceeding it. ### Single tag ceiling The legacy strategy used by AML screening. Each matched weight contributes `w · ln(1 + w)`, the sum is amplified by contextual factors, and the result is normalized against a worst-case ceiling: the largest single scaled weight amplified by the maximum configured multiplier of each factor type. ## Contextual factor amplification After the base result is computed, the multipliers of all matched contextual factors are summed and applied: ```text amplified = base × ( 1 + Σ multipliers ) ``` Amplification never lowers a _Relative share_ result, and it is skipped entirely for vetoed _Additive share_ results, so a negative factor can never flip a veto. ## Step 2: Combine with sources If the definition lists **Sources**, its own tag-based result is folded together with the source scores using the combination strategy: Probabilistic union (default) 100 × ( 1 − ∏ (1 − sᵢ / 100) ), each contribution increases the score, with diminishing returns as it approaches 100 Maximum The highest of the contributing scores Weighted The equal-weight mean of the contributing scores ## Step 3: Clamp and level The combined result is clamped to `[0, 100]`, rounded to an integer, and mapped to a level: `0–25` Low, `26–50` Medium, `51–75` High, `76–100` Critical. The default score's percentage is also surfaced as the flow result's headline **Risk score**. ## Worked example A form has two scored select questions feeding a custom `supplier_risk` score with _Additive share_ normalization: - **Company age**: "Less than 1 year" (weight `30`), "1–5 years" (weight `10`), "Over 5 years" (weight `0`) - **Prior incidents**: "Yes" (weight `50`), "No" (weight `0`) The obtainable maximum is `30 + 50 = 80`. A supplier answering "Less than 1 year" and "No" obtains `30`, so the base score is `30 / 80 × 100 = 37.5`. A contextual factor for a high-risk jurisdiction with multiplier `0.2` amplifies it to `37.5 × 1.2 = 45`, which rounds to **45 (Medium)**. :::tip[Configure it] Tags and their weights are managed on the [Score Definitions](/docs/guides/scoring/score-definitions) page, assigned as in [Tags](/docs/guides/scoring/tags), and attached to questions in the [form builder](/docs/guides/create-a-flow/form#scoring). ::: --- ## Scoring Zyphe includes a generalized scoring engine that turns the signals collected during a verification flow into one or more normalized **scores**. Every score is an integer percentage from `0` to `100`, paired with a categorical **level** (_Low_, _Medium_, _High_, or _Critical_), and is computed per flow result. Out of the box, every organization has a default **Risk score** that consolidates AML screening results, form answers, workflow actions, and manually assigned tags, and a system **AML score** driven by screening topics. You do not need to create a definition to use those. Create a **new definition** only when you want a separate, named score with its own tags — for example `supplier_risk` or `onboarding_quality`. Changing how risky a PEP is is a **tag-weight** change on the existing AML/Risk scores, not a new definition. See [Score Definitions](/docs/guides/scoring/score-definitions). A common use of custom scores is grading form answers: in the form builder you can assign weights to a question's options and answers, and those weights feed the scores computed for the flow result. See [Form scoring](/docs/guides/create-a-flow/form#scoring) for how to set it up. ## Where score signals come from Form answers Weighted score tags and contextual factors attached to form fields in the form builder, see{' '} Form scoring Workflow actions Tags assigned by the Assign Risk Tags action node in the flow builder AML screening The AML risk score computed from sanctions, PEP, and adverse media matches Manual review Score tags assigned or retracted by reviewers directly on a flow result ## Score levels Each score percentage maps to a level using fixed thresholds: | Score range | Level | | ----------- | -------- | | `0–25` | Low | | `26–50` | Medium | | `51–75` | High | | `76–100` | Critical | In the dashboard, the default Risk score is rendered as a color‑coded badge with its level; custom scores are displayed neutrally as a percentage. ## How scoring fits together ```mermaid flowchart LR A["Configurescore definitions · tags · form scoring"] --> B["Collectuser completes the flow"] B --> C["Computeone outcome per enabled score"] C --> D["ReviewScores tab · re-evaluate · manual tags"] ``` 1. **Configure**: define custom scores and their tags on the [Score Definitions](/docs/guides/scoring/score-definitions) page, create or assign tags as in [Tags](/docs/guides/scoring/tags), and attach score weights to form questions in the [form builder](/docs/guides/create-a-flow/form#scoring). 2. **Collect**: as the end user completes the verification flow, their answers and the flow's actions emit tags and contextual factors onto the flow result. 3. **Compute**: when the flow completes (or is re‑evaluated), each enabled score is calculated from its matched tags, factors, and source scores. See [How Scores Are Computed](/docs/guides/scoring/how-scores-are-computed). 4. **Review**: reviewers see every computed score on the flow result detail page, can assign or retract tags manually, and can trigger a re‑evaluation. See [Reviewing Scores](/docs/guides/scoring/reviewing-scores). --- ## Reviewing Scores Computed scores are surfaced on the flow result detail page in the Zyphe Dashboard, in a dedicated **Scores** tab that appears once a result carries score tags.
The Scores tab shows every computed score for the flow result, along with the score tags that produced them.
## Score badges Each enabled score is displayed with its current value: - The default **Risk score** is shown as a color‑coded badge with both percentage and level (e.g. `62% · High`). - **Custom scores** are shown neutrally as a percentage, since their meaning is organization-specific. - Scores fed by a specific form indicate the form they were computed from. ## Assigned score tags Below the badges, the **Assigned score tags** section lists every tag currently attached to the result together with its weight, whether it was emitted by a form answer, a workflow action, or a reviewer. Reviewers with the appropriate permissions can: - **Assign a tag manually**: click **Add tag**, pick the score it feeds, then pick the tag. This is useful to encode findings from a manual check into the score. - **Retract a tag**: remove a previously assigned tag from the result.
Manually assign a score tag to fold a reviewer's finding into the score.
## Re-evaluation Scores are computed automatically when the flow completes, and recomputed when their inputs change, for example after an AML moderation decision or a manual tag assignment. Reviewers can also trigger a recomputation explicitly with the **Re-evaluate** button on the Scores tab. When a re‑evaluation changes the overall score or the result's status, Zyphe can notify your registered webhook endpoint with the before/after values, so downstream systems stay in sync. See [Webhook](/docs/guides/webhook) for the general webhook setup. :::info[Permissions] Viewing scores requires access to flow results; assigning or retracting tags manually is reserved to **Admin** users, and re-evaluation is available to **Admin**, **Operator**, and **AML Officer** users. See [Manage Users](/docs/guides/manage-users). ::: :::tip[Where scores come from] Score tags are authored on the [Score Definitions](/docs/guides/scoring/score-definitions) page and attached to questions in the [form builder](/docs/guides/create-a-flow/form#scoring). The math behind the percentages is described in [How Scores Are Computed](/docs/guides/scoring/how-scores-are-computed). ::: --- ## Score Definitions A **score definition** describes one score your organization computes for each flow result: its name, the strategy used to calculate it, and the set of weighted tags that feed it. You do **not** need a new definition to use Zyphe for AML or onboarding risk. Every organization already has system scores for that. Create a definition only when you want a **separate number** with its own tags — typically something that is not AML. | You want to… | Do this | | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | Make PEP, sanctions, or fraud count more or less | Keep the system **AML** / **Risk** scores. Change **tag weights** (or add custom tags that feed them). | | Score a supplier questionnaire, an onboarding-quality checklist, or any non-AML rubric | Click **New definition** and point that score’s tags at the form (or at flow actions). | | Roll several scores into one headline | Create a definition and list the others as **Sources**. | In the Zyphe Dashboard, navigate to the **Score Definitions** page in the **Compliance** section to define custom scores for your organization and manage the tags that feed them. :::info[Permissions] Score definitions are managed by **Admin** users. See [Manage Users](/docs/guides/manage-users) for the full role reference. :::
The Score Definitions page lists the system Risk score alongside your organization's custom scores.
## System scores Every organization starts with system‑provided definitions. The keys `risk` and `aml` are reserved. - **AML** (`aml`): the screening score from sanctions, PEP, and adverse-media matches. Tune it by overriding tag weights and contextual factors, not by creating a second AML definition. See [Risk scoring](/docs/aml/risk-scoring). - **Risk** (`risk`): the headline score on flow results. It can fold in AML plus form answers, workflow tags, and manual tags. System definitions cannot be edited or removed. You can still **manage the custom tags** that feed them, and you can override global AML tag weights. That is “defining the score” for AML: changing how existing signals combine, not creating a new score. ## Create a custom score Click **New definition** when the number you need is **not** AML or the headline Risk score: a `supplier_risk` score on a vendor questionnaire, an `onboarding_quality` score, a product-specific rubric. The scoring engine is general-purpose; AML is one input, not the only one. Fill in: - **Name:** The user-facing name of the score. - **Key:** A unique, immutable identifier (lowercase letters, digits, and underscores, e.g. `supplier_risk`). The key cannot be changed after creation. - **Description:** An optional description of what the score measures. - **Combination strategy:** How the score's own tag-based result is combined with its sources, **Probabilistic union** (default), **Maximum**, or **Weighted**. - **Normalization:** How matched tag weights are turned into a percentage, **Additive share (scorecard)** (default), **Relative share**, or **Single tag ceiling**. - **Sources:** Other scores folded into this one. A score can build on the result of other scores; circular references are rejected. The strategies are explained in detail in [How Scores Are Computed](/docs/guides/scoring/how-scores-are-computed).
Create a custom score definition with its key, combination strategy, normalization, and sources.
Existing definitions can be renamed, re-described, re-configured, or disabled with the **Enabled** checkbox, a disabled score is skipped at computation time without deleting its configuration. ## Manage tags Each definition has a **Manage tags** action that opens the list of tags feeding that score, with their weight and status. - **Add a tag:** Provide the **Tag** name and its **Weight**. The tag can then be assigned by forms and workflow actions. - **Edit a tag:** Adjust the **Weight** or toggle the tag **Active**/inactive without deleting it.
Manage the weighted tags that feed a score definition.
:::tip[Scoring form answers] The most common way to feed a custom score is directly from a form: assign weights to answers and options in the form builder, and they are recorded as score tags on the flow result. See [Form scoring](/docs/guides/create-a-flow/form#scoring). Step-by-step tag assignment (form, Flow Builder, review) is in [Tags](/docs/guides/scoring/tags). ::: --- ## Tags A **tag** is a weighted label. When it is present on a flow result, its weight pushes the score it feeds. Tags are the “what” of scoring; [contextual factors](/docs/guides/scoring/how-scores-are-computed#tag-weight-vs-contextual-factor) are optional multipliers on top. This page covers where tags come from, which ones ship by default, and how to create and assign a custom tag. ## Where tags come from AML screening Global AML tags are attached automatically when a sanctions, PEP, or adverse-media match carries that topic. You do not assign{' '} role.pep or sanction by hand; the screening result emits them. See{' '} Default AML tags. Form answers A field in the form builder can emit a tag when the user answers a certain way.{' '} Form scoring. Flow Builder action The Assign Risk Tags node attaches tags you already created, typically behind a condition (for example “document review failed”). Manual review A reviewer can assign or retract a tag on the flow result. Reviewing Scores. Default AML tags live on the **Risk** / **AML** score definitions. Custom tags you create belong to the definition you attach them to (Risk, or a score you added). ## Create and assign a custom tag Use a custom tag when the signal is **yours**: an internal classification, a questionnaire answer, a failed manual check. Do not recreate AML topics; those already arrive from screening. ### 1. Create the tag 1. In the Zyphe Dashboard, open **Compliance → Score Definitions**. 2. On the score that should receive the tag (usually **Risk**, or a custom score such as `supplier_risk`), click **Manage tags**. 3. Click **Add a tag**. Give it a **name** and a **weight**. Leave it **Active**. The tag now exists but does not fire until something assigns it. AML-only overrides (changing the weight of `role.pep` without creating a new tag) are done on **Risk Scoring Tags**, not here. See [Configurable tag weights](/docs/aml/risk-scoring#configurable-tag-weights). ### 2. Assign it, pick one path **From a form (most common for questionnaires):** in the form builder, open the field, expand **Score**, add a score tag, pick the score and the tag, set the weight, and optionally an **Only when** condition. See [Form scoring](/docs/guides/create-a-flow/form#scoring). **From Flow Builder (conditional, cross-step):** 1. Open the flow in **Flow Builder**. 2. Add an **Assign Risk Tags** action node. 3. Select one or more custom tags created in step 1. 4. Wire the node behind a **switch** (or after the step whose outcome you care about), so the tag is assigned only when the condition matches: for example document verification failed, nationality in a set, or a form field equals a value. The action only lists tags you have already created. Create the tag first, then associate it. **From review:** on the flow result **Scores** tab, **Add tag**. Useful for a finding that is not in the flow. ### 3. Confirm it landed Complete a test run (or re-evaluate an existing result). The **Scores** tab lists assigned tags with source (form, workflow action, or reviewer) and weight. If the tag is missing, the condition did not match, or the tag is inactive on the definition. ## Related - [Score Definitions](/docs/guides/scoring/score-definitions) — when to add a score vs a tag - [How Scores Are Computed](/docs/guides/scoring/how-scores-are-computed) — weights and multipliers - [AML risk scoring](/docs/aml/risk-scoring) — default AML tags and contextual factors - [Create a flow: Flow Builder](/docs/guides/create-a-flow#10-flow-builder) --- ## TIN Check **TIN Check** matches a US Taxpayer Identification Number (TIN) and a name against IRS records. The same check screens the name against watchlists and can also validate a US mailing address and look up a FATCA GIIN. It is a standalone product: a check is run by a member of your organization from the dashboard, or by your backend [with an API key](#run-a-check-from-your-backend), not by an end user inside a verification flow. Use it when you need to confirm the tax identity of a US person or company, for example before filing a 1099 or onboarding a US vendor. ## Before you start - **The product must be enabled** for your organization. If **TIN Check** does not appear under **Compliance** in the sidebar, contact the Zyphe team. - **Your role must allow it.** Admins, Operators, and AML Officers can run and read checks in both environments. Developers can do so in sandbox only. The full role matrix is maintained in [Manage Users](/docs/guides/manage-users). - **You need credits in production.** Each production check that returns an answer is charged. See [Cost](#cost). ## Run a check 1. Open **Compliance → TIN Check**. 2. Select **New check**. 3. Enter the **Name**: a person's full name or a company's legal name, as it appears on IRS records. 4. Enter the **TIN**: the nine digits of a Social Security Number (SSN) or an Employer Identification Number (EIN). Spaces and hyphens are accepted. 5. Optionally, open **Address and FATCA details** to add a US mailing address, a GIIN, or both. They are verified as part of the same check, at no extra cost. 6. Select **Run check**. In production the button shows the price of the check. The answer is returned immediately and the check opens on its own page. :::info[What is stored of the TIN] Only the last four digits are stored, in the form `XXXXX6789`. The full TIN is used for the lookup and then discarded, so a check cannot be run again from the list: enter the TIN again to repeat it. ::: ### Optional details | Field | What the check does with it | | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Address** | Validates the address against the USPS database. This confirms that the address exists, not that it belongs to the subject. | | **GIIN** | Looks the Global Intermediary Identification Number up on the FATCA list of registered foreign financial institutions. The format is `XXXXXX.XXXXX.XX.XXX`. | When you fill in any part of an address, the street address is required. The state is the two-letter code, and the ZIP code is five digits, or nine with the +4 extension. ## The IRS answer Every stored check carries one of three answers: | Answer | Meaning | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | **Matches IRS records** | The TIN and name combination matches IRS records. When the IRS reports it, the check also says whether an SSN record, an EIN record, or both matched. | | **Does not match** | The combination does not match IRS records. Check the spelling of the name against the subject's tax documents. | | **TIN not issued** | The IRS has not currently issued this TIN. | Two situations are errors rather than answers. Nothing is stored and nothing is charged: - **The TIN is refused as invalid.** The number is not a valid TIN. Check it and try again. - **The check is unavailable.** The check could not be completed. Try again in a few minutes. ## The other lookups The check page lists every lookup the check ran, one row each. Select a row to expand it. | Row | What it tells you | | --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **IRS TIN and name check** | The IRS answer described above. | | **EIN name lookup** | Whether the EIN is on record under another name. This is for reference only: the record comes from earlier matches and may be out of date. | | **Death Master File check** | Whether the TIN appears on the Social Security Death Master File. A match does not by itself mean the person is deceased, because a number can be reissued. | | **Address check** | The USPS answer for the address you entered. Skipped when no address was provided. | | **GIIN check** | The FATCA list answer for the GIIN you entered. Skipped when no GIIN was provided. | | **Lists** | One row per watchlist the name was screened against, such as the OFAC sanctions list. A flagged list shows how many entries resemble the name, and expands to show those entries. | :::warning[A possible match is not a confirmed hit] A **Possible match** means that an entry resembles the name you checked. Watchlist screening is done by name, so common names produce matches that refer to someone else. Review the entries before you act on them. ::: Turn on **Only show validations with a result** to hide the lookups that found nothing and the ones that were skipped. ## The list of checks **Compliance → TIN Check** lists the checks your organization has run in the current environment, newest first. Each row shows: - **Name** and **TIN**, with the TIN masked. - **IRS match**: the IRS answer. - **Lists**: how many watchlists have entries to review. - **EIN name** and **DMF**: the result of the EIN name lookup and of the Death Master File check. - **Address** and **GIIN**: whether each was checked or not provided. - **Date**: when the check was run. Select a row to open the check. The check page also shows who ran it and what it cost. Sandbox and production checks are kept apart. Use the dashboard's sandbox toggle to switch between them. ## Cost A production check is charged in credits, at the price shown on the **Run check** button. - The charge is made only when the IRS returns an answer: a match, a mismatch, or a TIN that is not issued. - A TIN refused as invalid and an unavailable check cost nothing. - The address and GIIN lookups are included in the price of the check. - If the check cannot be charged, for example because the balance ran out, no result is returned and nothing is stored. Usage appears with the other products in the **Usage This Period** table on the [Billing](/docs/guides/billing) page. ## Sandbox Sandbox checks are **free** and do not run a real lookup. They are answered from sample data, so you can build and demonstrate a process without spending credits or using a real TIN. :::info[An exception to sandbox billing] Other sandbox usage draws on your credit balance, as described in [Sandbox mode](/docs/guides/sandbox-mode#credits-and-billing-in-sandbox). TIN Check does not: a sandbox check always costs nothing. ::: There are two ways to choose the answer of a sandbox check. ### Mock check **New mock check** appears next to **New check** in sandbox. It runs a check whose answer you state in the form: - **IRS answer**: a match, a mismatch, a TIN that is not issued, or one of the two errors. - **Matching record**: for a match, which kind of record matched. - **EIN on record under another name** and **Possible Death Master File match**. - **Lists to flag** and the number of entries on each flagged list. Every other list answers with no match. - **Address found by USPS** and **GIIN found on the FATCA list**, which apply when you enter an address or a GIIN. The check is stored like any other sandbox check. ### Reserved TINs A sandbox check run with **New check** matches IRS records, unless the TIN is one of these reserved values. No real TIN starts with `000000`. | TIN | Answer | | ----------- | ---------------------------------------------------- | | `000000000` | Does not match | | `000000005` | TIN not issued | | `000000006` | Matches, SSN record | | `000000007` | Matches, EIN record | | `000000008` | Matches, SSN and EIN records | | `000000013` | Error: the TIN is refused as invalid | | `000000017` | Error: the check is unavailable | | `000000101` | Matches, with a possible Death Master File match | | `000000201` | Matches, and the EIN is on record under another name | | `000000301` | Matches, with possible matches on two watchlists | An address is found unless its ZIP code is `00000`. A GIIN is found unless it is `000000.00000.XX.000`. ## Run a check from your backend The same check is available over the API with a **Secret API key** (`zyphe_sk_`) in the `x-api-key` header. [Publishable keys](/docs/guides/api-keys) are rejected. The `sandbox` query parameter is required on every request. | Operation | Request | | --------------- | ---------------------------------------------------------------- | | Run a check | `POST /sdk/organizations/{organization_id}/tin-checks` | | List the checks | `GET /sdk/organizations/{organization_id}/tin-checks` | | Get one check | `GET /sdk/organizations/{organization_id}/tin-checks/{check_id}` | | Get the price | `GET /sdk/organizations/{organization_id}/tin-checks/quote` | ```bash curl -X POST \ "https://api.zyphe.com/sdk/organizations/{organization_id}/tin-checks?sandbox=true" \ -H "x-api-key: zyphe_sk_..." \ -H "Content-Type: application/json" \ -d '{ "name": "Acme Inc", "tin": "12-3456789", "address": { "street": "123 Main Street", "city": "Hartford", "state": "CT", "zip": "06103" }, "giin": "98Q96B.00000.LE.250" }' ``` Only `name` and `tin` are required. The response is the stored check: the IRS answer in `outcome` (`MATCH`, `MISMATCH`, or `NOT_ISSUED`), the masked TIN in `tinMasked`, the other lookups, and one entry per watchlist in `watchlists`, each with `flagged` and `possibleMatches`. `@zyphe-sdk/node` exposes `runTinCheck`, `listTinChecks`, `getTinCheck`, and `getTinCheckQuote` for these requests: ```ts const { data: check, error } = await runTinCheck( { organizationId, isSandbox: true, name: 'Acme Inc', tin: '12-3456789' }, { apiKey: process.env.ZYPHE_SECRET_API_KEY, environment: 'production' }, ) ``` What applies to a dashboard check applies here too: - A check is charged in the same way, and `GET .../tin-checks/quote` returns its price in credits. - A TIN refused as invalid answers `422`, and an unavailable check answers `503`. Neither is stored or charged. - A balance that cannot cover the check answers `402`. - Running checks is limited to 30 requests per minute. Past that, requests answer `429`. - A check run with an API key has no author, so `createdByEmail` is absent. - The list takes `take` and `skip` for paging, and narrows to a KYB submission's checks with `flowResultId` (the KYB result's flow result) or `verificationRequestId`. - In sandbox, the [reserved TINs](#reserved-tins) work as they do in the dashboard. To state the answer instead, send a `mock` object, which a production request refuses. The request and response schemas are in the [API reference](/docs/openapi/zyphe-sdk). ## On a KYB submission A KYB flow can run the check for you: with **Check the EIN of US businesses** on its Know Your Business step, a business registered in the US gives its EIN, and its business information is accepted only once the EIN matches the company name. These checks are charged like any other, carry the KYB submission they were run on, and are listed both here and on the KYB result page. See [Checking a US business's EIN](/docs/guides/kyb/steps-and-configuration#checking-a-us-businesss-ein). ## Related documentation - [Manage Users](/docs/guides/manage-users) - [Billing](/docs/guides/billing) - [Sandbox mode](/docs/guides/sandbox-mode) - [API Keys](/docs/guides/api-keys) - [API reference](/docs/openapi/zyphe-sdk) --- ## Condition fields Every Transaction Monitoring rule is a condition over a **namespaced field**. The builder groups fields into **Transaction**, **Lists**, **Identity**, and **Velocity**. This page is the glossary: what each field means, the unit it uses, and a short example. Amounts are stored in **minor units** of the currency (the smallest unit: cents for EUR and USD, pence for GBP). The dashboard label is **Amount (minor units)** (`transaction.amountMinor`). It is not a banknote denomination. €10.00 is `1000`; €1,000.00 is `100000`. Pair amount cutoffs with `transaction.currency` so a EUR threshold is not applied to a USD payment. Time fields (`hourOfDay`, `dayOfWeek`, `isOutsideBusinessHours`) are computed in the **organization timezone** from [Settings](/docs/guides/transaction-monitoring/settings-and-alerts), not in UTC and not per rule. ## Transaction | Field | Meaning | Example | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ | | **Amount (minor units)** (`amountMinor`) | Payment amount in the currency’s smallest unit. Integer, never a decimal euro/dollar amount. | `amountMinor >= 100000` on EUR is “€1,000 or more”. | | **Currency** | ISO 4217 code of the payment. | `currency Equals EUR` | | **Direction** | `Deposit`, `Withdrawal`, or `Transfer`. | `direction Equals WITHDRAWAL` | | **Payment status** | Lifecycle status: `Pending`, `Settled`, `Failed`, `Canceled`, `Reversed`. | Fire only on `Settled`. | | **Hour of day (0–23)** | Hour in the organization timezone. | Night-time: `hourOfDay >= 0` AND `hourOfDay <= 5` | | **Day of week (1 = Monday)** | ISO day number in the organization timezone. | Weekend: `dayOfWeek >= 6` | | **Outside business hours** | True when the event falls outside weekday business hours in the organization timezone. | `isOutsideBusinessHours Equals true` | | **Counterparty country** | ISO 3166-1 alpha-2 of the other leg. Derived from IBAN when you omit it. | `counterpartyCountry Equals IR` | | **Origin country** | Country on the monitored identity’s side. | `originCountry Equals IT` | | **Counterparty name** | Name of the other party. | `counterpartyName Contains exchange` | | **Counterparty account / IBAN** | Account identifier of the other party. | Used with list hits more often than compared directly. | | **Channel** | How the payment was initiated (free string, e.g. mobile, branch). | `channel Equals mobile` | | **Rail** | Payment network or provider (free string, e.g. `sepa`, `open_banking`). | `rail Equals sepa` | | **Payment description** | Free-text reference / SEPA _causale_. Keyword lists match against this. | `description Contains prestito` | | **External ID** | Your transaction identifier (also the idempotency key). | Rarely used in rules. | | **External user ID** | Your identifier for the verified identity. | Rarely used in rules. | | **Amount vs average (%)** (`amountVsAvgPercent`) | This amount as an integer percentage of the identity's 90-day mean transaction amount. `100` is exactly average, `250` is 2.5×. | `amountVsAvgPercent >= 500` is "five times the usual". | :::info[`amountVsAvgPercent` is absent, not zero, on a first transaction] The field is only present when the identity has prior history in the last 90 days and that history has a positive mean. On the very first transaction it is **omitted from the condition context entirely**, so a rule that references it does not fire rather than firing against a fabricated baseline. The mean it compares against is [`identity.historicalAvgAmount`](#identity). ::: ## Lists List matches are boolean flags computed at ingest against your [managed lists](/docs/guides/transaction-monitoring/lists). Updating a list updates every rule that references it. | Field | Meaning | Example | | ------------------------------- | ----------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | **Counterparty blocklist hit** | The counterparty account is on a block list. | Hard-block template: `blocklistHit Equals true` | | **Counterparty allowlist hit** | The counterparty account is on an allow list. Use to suppress noise on known-good flows. | `allowlistHit Equals true` | | **Any country-risk list hit** | Origin or counterparty country is on any enabled country-risk list. | `countryRiskHit Equals true` | | **Country-risk hit (per list)** | Same, but for one list key (for example the Italian MEF/BdI set). | `countryRisk_it_high_risk Equals true` | | **Keyword list hit** | The payment description contains a term from a keyword list. | `keywordHits Equals true` | | **Matched keywords** | The list entries that actually matched the description. A list of strings, not a boolean. | Read it on the fired-rule provenance; `keywordHits` is what you compare in a condition. | ## Identity These fields come from the **verified identity** the transaction is tied to, not from the payment payload. | Field | Meaning | Example | | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | **KYC risk score (%)** | The identity’s latest Risk score, 0–100. | `riskScorePercent >= 51` (High or Critical) | | **Account age (minutes)** | Minutes since the identity was verified. | New account: `ageMinutes Less Than 1440` (24 hours) | | **Historical average amount** (`historicalAvgAmount`) | The identity’s mean transaction amount over the last 90 days, in **minor units**. Excludes the transaction being evaluated and any failed, canceled, or reversed payment. | `amountMinor > historicalAvgAmount` — but prefer [`transaction.amountVsAvgPercent`](#transaction) for ratios. | Like `transaction.amountVsAvgPercent`, `historicalAvgAmount` is **omitted** when the identity has no prior history in the window. It is read directly from the transaction book, not from the velocity counters below, so it is exact rather than bucketed. ## Velocity Velocity fields answer "how much, and how often, has this subject moved money recently". They are maintained as rolling counters per identity (and, for the counterparty metrics, per counterparty) and are available in the condition builder and as the **metric** of a banded rule. Every field below is an **integer**, and every one is **always present** — a subject with no history reads `0` rather than being absent, so a velocity rule never silently goes dormant. Amount fields are in **minor units**, on the same scale as `transaction.amountMinor`. ### Identity flow Each of these six metrics exists over four windows: `1h`, `24h`, `7d`, `30d`. The window is a suffix on the field name, so the deposit count over 24 hours is `velocity.depositCount24h`. | Metric | Meaning | Unit | | ------------------------------------------ | ------------------------------------------ | ----------- | | `depositSum1h` … `depositSum30d` | Total value of the identity's deposits. | minor units | | `depositCount1h` … `depositCount30d` | Number of deposits. | count | | `withdrawalSum1h` … `withdrawalSum30d` | Total value of the identity's withdrawals. | minor units | | `withdrawalCount1h` … `withdrawalCount30d` | Number of withdrawals. | count | | `transferSum1h` … `transferSum30d` | Total value of the identity's transfers. | minor units | | `transferCount1h` … `transferCount30d` | Number of transfers. | count | ### Net flow | Field | Meaning | Unit | | --------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------- | | `velocity.netFlow24h` | Deposits minus withdrawals over 24 hours. Transfers are treated as flow-neutral and contribute nothing. Can be negative. | minor units, signed | Net flow exists only at `24h`. ### Counterparty These are keyed on the **other** party, not on the identity, so they see activity across every identity in your organization that touched the same counterparty. | Field | Meaning | Unit | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------- | ----------- | | `velocity.counterpartyInboundSum24h` | Value moving **toward this counterparty** in 24 hours — the withdrawal and transfer legs pointed at it. | minor units | | `velocity.counterpartyInboundCount24h` | Number of such payments. | count | | `velocity.counterpartyDistinctIdentities24h` | How many distinct verified identities of yours transacted with this counterparty in 24 hours. | count | | `velocity.counterpartyDistinctIdentities30d` | The same over 30 days. A classic shared-beneficiary / money-mule signal. | count | "Inbound" is relative to the counterparty: value leaving your identity and arriving at the other side. Deposits do not contribute to it. `counterpartyInbound*` and `counterpartyDistinctIdentities*` exist only at the windows listed — there is no `1h` or `7d` variant. ### Semantics you should know before writing a threshold **The current transaction counts.** A payment is folded into the counters at ingest, before the rules are evaluated. `depositCount24h >= 3` therefore fires on the third deposit, not the fourth. **Reversals decrement.** When you move a payment to `Failed`, `Canceled`, or `Reversed`, a compensating decrement removes exactly what the original ingest added. Moving a payment to `Settled` changes nothing — it was already counted. **Windows are rolling, approximated by sub-buckets.** Counters are kept in fixed time buckets and a window is the sum of the buckets it covers, including the current partial one: | Window | Bucket size | Buckets summed | Real history covered | | ------ | ----------- | -------------- | -------------------- | | `1h` | 5 minutes | 12 | 55–60 minutes | | `24h` | 1 hour | 24 | 23–24 hours | | `7d` | 6 hours | 28 | 6.75–7 days | | `30d` | 1 day | 30 | 29–30 days | So a `24h` window covers between 23 and 24 hours of real history depending on where in the current hour the payment lands — worst-case truncation is under ~8% of the window. Buckets are aligned to UTC and keyed on the **event time you reported** (`occurredAt`), not on when Zyphe processed it, so a late or replayed report lands in the correct historical bucket. **Counters are currency-blind.** A counter key does not include the currency, so a mixed-currency book sums minor units across currencies. On a book that is not single-currency, pair a velocity sum cutoff with a `transaction.currency` condition, or prefer the count metrics. **`counterpartyDistinctIdentities*` is exact.** Unlike every other velocity field, it is counted directly over the transaction book rather than from buckets, so it is not subject to the truncation above. **Concurrent bursts can under-count.** A payment whose contribution has been recorded but not yet folded into the stored counters is invisible to a rule evaluating a _different_ payment in the same instant. Two simultaneous deposits for the same identity can each miss the other. Counters converge within about a minute. Size structuring thresholds with that tolerance in mind rather than expecting exact burst detection. **A counter failure fails the ingest.** If Zyphe cannot record a transaction's velocity contribution, the ingest request returns a `5xx` rather than silently dropping it — a lost contribution would permanently under-count the windows and let later payments miss blocks they should have hit. The transaction and its verdict are already stored, so **retry the same request with the same `externalId`**: the retry is idempotent and completes the missing bookkeeping. ## Fields that are not in the builder yet Counterparty screening fields (`counterparty.*`) are **reserved** for a later phase. A rule authored against them is rejected at save time with a clear error rather than being stored as a silently dormant rule. Every `velocity.*` field listed above is live. Additional payload fields (for example ATECO / nature of business) cannot be added from the dashboard today. Send the list of fields you need and they can be wired into the condition palette. ## Related - [Rules and Templates](/docs/guides/transaction-monitoring/rules-and-templates) - [Settings and Alerts](/docs/guides/transaction-monitoring/settings-and-alerts) — timezone and verdict thresholds - [Lists](/docs/guides/transaction-monitoring/lists) --- ## Transaction Monitoring Zyphe's Transaction Monitoring watches payment activity in real time. Your integration reports each payment event (deposit, withdrawal, or transfer) to Zyphe, the event is evaluated synchronously against your organization's enabled monitoring rules, and the response carries an **Allow**, **Review**, or **Block** decision, before your platform moves any funds. This page covers how to **operate** Transaction Monitoring from the dashboard. For the conceptual overview (where it sits in full-cycle compliance and how the decision model relates to Zyphe's scoring engine), see [Transaction Monitoring](/docs/transaction-monitoring) in the Overview. ## How it works ```mermaid sequenceDiagram autonumber participant APP as Your application participant ZB as Zyphe Backend participant RE as Rule engine APP->>+ZB: Report transaction event ZB-->>ZB: Resolve verified identity and counterparty ZB-->>ZB: Enrich with derived fields and list matches ZB->>+RE: Evaluate enabled rules RE-->>-ZB: Fired rules + combined P(risk) ZB-->>ZB: Apply thresholds, persist, raise alerts ZB->>-APP: Allow / Review / Block + fired-rule provenance ZB--)APP: Transaction alert webhook (if alerts raised) ``` 1. Your application reports the transaction event, referencing the verified identity it belongs to. 2. Zyphe resolves the identity and counterparty, and enriches the event with derived fields (hour of day, business hours, country of the counterparty's IBAN, the amount against the identity's own 90-day average, …), rolling [velocity counters](/docs/guides/transaction-monitoring/condition-fields#velocity) for the identity and the counterparty, and matches against your [managed lists](/docs/guides/transaction-monitoring/lists). The event being evaluated is itself counted, so a "third deposit in 24 hours" rule fires on the third one. 3. Every enabled [rule](/docs/guides/transaction-monitoring/rules-and-templates) is evaluated. Each rule that fires contributes a probability, its confidence that the transaction is risky. 4. The contributions are combined into a single `P(risk)` with a probabilistic union (noisy-OR): ```text P(risk) = 1 − ∏ (1 − pᵢ) ``` 5. `P(risk)` is compared against your organization's thresholds to produce the decision, which is returned synchronously so your platform can hold or reject the payment inline. 6. Rules flagged with **Raise alert** additionally create a review-queue alert and notify your webhook. | Condition | Decision | | ------------------------------------ | -------- | | `P(risk)` below the review threshold | Allow | | `P(risk)` ≥ review threshold | Review | | `P(risk)` ≥ block threshold | Block | Both thresholds are configurable per organization. See [Settings and Alerts](/docs/guides/transaction-monitoring/settings-and-alerts). ## What you can do - **Screen every payment in real time**: get a synchronous Allow / Review / Block verdict with full fired-rule provenance, and decide inline whether to execute, hold, or reject. - **Author your own rules**: build boolean or banded-metric rules over transaction, list, identity, and velocity fields with a visual condition builder; every rule change is versioned and auditable. - **Catch patterns, not just single payments**: rolling velocity counters expose deposit, withdrawal, and transfer sums and counts over 1h / 24h / 7d / 30d, 24-hour net flow, and how many of your identities share a counterparty, so structuring and mule typologies can be expressed as ordinary rules. See [Velocity](/docs/guides/transaction-monitoring/condition-fields#velocity). - **Start from a regulator-informed catalog**: instantiate jurisdiction-tagged rule templates (with regulator citations such as UIF _indicatori di anomalia_ and FCA/JMLSG) instead of starting from scratch. The catalog is a set of starters, not an exhaustive list of indicatori; you can always author a rule from blank. See [Templates vs rules](/docs/guides/transaction-monitoring/rules-and-templates#templates-vs-rules). - **Curate lists once, apply everywhere**: country-risk sets, keyword packs, and counterparty block/allow lists referenced by key from any rule. - **Backtest before going live**: dry-run a rule against your stored transactions and compare simulated decisions with the stored baseline; nothing is persisted or billed. - **Route alerts to your review workflow**: rules can raise alerts that appear in the transaction detail and fire a signed webhook to your systems. - **Rehearse in the sandbox**: seed a deterministic synthetic transaction book, with a controllable share of suspicious patterns, through the real ingest path. ## Key concepts Transaction A payment event (deposit, withdrawal, or transfer) reported by your integration, idempotent on your external ID Rule A versioned condition over transaction, list, and identity fields that contributes a probability when it fires, see{' '} Rules and Templates Rule template A catalog entry, jurisdiction-tagged, with regulator citations, you can instantiate into your own rule set with one click List A managed set of countries, keywords, or counterparties referenced by rules, see{' '} Lists Decision The synchronous verdict, ALLOW, REVIEW, or BLOCK, derived from the combined{' '} P(risk) and your thresholds Alert A review-queue entry raised by a rule with Raise alert, also delivered via webhook, see{' '} Settings and Alerts ## Dashboard sections The **Transaction Monitoring** area of the dashboard is organized in five sections: Transactions Every monitored payment event with its status, decision, P(risk), and fired rules, see{' '} Transactions Rules The enabled rule set, the rule builder, per-rule version history, and backtesting Rule Templates The jurisdiction-tagged catalog to bootstrap your rule set from Lists Country-risk sets, keyword packs, and counterparty block/allow lists referenced by your rules Settings Organization-wide decision thresholds, the timezone that interprets time-of-day rule fields in local operativity, and the alert webhook ## AI agents on alerts The Transaction Monitoring agent is the same kind of **first-line compliance analyst** as the KYC and KYB agents: it would triage **raised alerts** (not every Allow) under Disabled / Suggest / Auto-pilot. See [Antifraud controls](/docs/how-it-works/antifraud-controls#ai-agents-as-first-line-analysts). Until the alert-queue ships, TM agent mode is fixed to **Disabled** and is not shown on Settings. Rules still evaluate synchronously, and rules with **Raise alert** still notify your webhook for your own case management. ## Next steps 1. Explore ingested events on the [Transactions](/docs/guides/transaction-monitoring/transactions) page, or seed sample data in the sandbox. 2. Configure [rules or instantiate templates](/docs/guides/transaction-monitoring/rules-and-templates). Use the [condition field glossary](/docs/guides/transaction-monitoring/condition-fields) when a field name is unclear (including **Amount (minor units)**). 3. Curate the [lists](/docs/guides/transaction-monitoring/lists) your rules reference. 4. Tune thresholds and wire up the alert webhook in [Settings and Alerts](/docs/guides/transaction-monitoring/settings-and-alerts). :::info[Integrating ingestion] Your backend streams transactions with a secret API key through the SDK API: `POST /sdk/organizations/{organization_id}/transactions` to ingest one and get its verdict, `GET …/transactions/{transaction_id}` to read it, and `PATCH …/transactions/{transaction_id}` to update its payment status. The [Node SDK](/docs/guides/sdk/node#7-transaction-monitoring) wraps all three, and the [API reference](/docs/openapi/zyphe-sdk) documents their request and response schemas. ::: --- ## Lists **Transaction Monitoring → Lists** holds the managed lists your rules reference: country-risk sets, keyword packs, and counterparty block/allow lists. Rules reference a list by its **key**, so updating a list immediately updates every rule that uses it, no rule edits required.
The Lists page, grouped by kind, system-curated lists ship out of the box and can be overridden.
## List kinds Counterparty Blocklist Account identifiers (IBANs, wallet addresses) you never want to transact with Counterparty Allowlist Trusted counterparties, usable in rules to suppress noise on known-good flows Country Risk Sets of two-letter country codes grouped by risk (matched against origin and counterparty countries) Keywords Terms screened against the payment description (for example the SEPA causale) Each entry can carry an optional **note** with context for reviewers. ## System lists and overrides Zyphe ships **system-curated lists** (marked with a _System_ badge) that you can reference from rules out of the box. Your organization's own lists extend them, and an org list created with the **same key** as a system list **overrides** it wherever rules reference that key. The system list is marked _Overridden_ and its content stops matching until your override is deleted. Deleting an org list means rules referencing its key stop matching its entries on the next evaluation. ## How rules use lists The [rule builder](/docs/guides/transaction-monitoring/rules-and-templates) exposes list matches as condition fields: - **Counterparty blocklist / allowlist hit**: the transaction's counterparty account appears on a block or allow list. - **Country-risk hit**: the origin or counterparty country appears in a country-risk list (any list, or a specific one by key). - **Keyword list hit**: the payment description contains a term from a keyword list. Rule templates often reference system lists by key, so instantiating a template works immediately, and you can sharpen it later by overriding the list with your own entries. --- ## Rules and Templates **Transaction Monitoring → Rules** holds the rules evaluated on every ingested transaction. Each fired rule contributes a probability, and the noisy-OR combination of all contributions decides Allow / Review / Block.
The Rules page lists the enabled rule set with each rule's key, version, type, and probabilities.
## Anatomy of a rule A rule is made of: - **Rule key**: a stable lowercase slug (`a–z`, `0–9`, `-` and `_`) that identifies the rule across versions. - **Name and description**: for your reviewers. - **Condition**: when it matches, the rule fires and contributes its probability to the combined `P(risk)`. - **Probabilities**: how much a firing contributes, between `0` and `1`. - **Raise alert**: whether a firing also creates a review-queue alert and notifies your webhook. ### The condition builder Conditions are built visually as nested **AND / OR groups** of field comparisons (equals, not equals, greater/less than, in a set, contains, is empty / not empty).
The rule builder: name, stable rule key, and the visual condition editor with nested groups.
Fields come from four sources. Each field is defined, with units and examples, in [Condition fields](/docs/guides/transaction-monitoring/condition-fields). Amounts use **minor units** (cents, not euros): see that glossary before setting cutoffs. Transaction Amount (minor units), currency, direction, payment status, counterparty name / account / country, origin country, channel, rail, payment description, and derived time fields, hour of day, day of week, outside business hours (driven by the timezone in Settings) Lists Matches against your managed lists, counterparty blocklist / allowlist hits, country-risk list hits, keyword list hits Identity Signals from the verified identity behind the transaction, KYC risk score, account age, and the 90-day historical average transaction amount Velocity Rolling counters over recent activity, deposit / withdrawal / transfer sums and counts over 1h, 24h, 7d and 30d, 24h net flow, and per-counterparty inbound value and distinct-identity counts. See{' '} Velocity ### Boolean vs banded rules There are two rule types: - **Boolean signal**: the rule fires at a single probability whenever its condition matches. Example: _counterparty is on the blocklist → contribute `0.9`_. - **Banded metric**: on top of the condition, a numeric field (the **metric**) is banded against **low / medium / high cutoffs**, and each band contributes its own probability. Example: _withdrawal `amountMinor` banded at `100000` / `1000000` / `10000000` (that is €1,000 / €10,000 / €100,000 when the currency is EUR) → contribute `0.1` / `0.4` / `0.7` depending on where the amount lands_. Cutoffs must be ordered (low ≤ med ≤ high), and any subset of them can be provided. Always pair amount cutoffs with a currency condition. Any integer field can be the metric, which is what makes the [velocity counters](/docs/guides/transaction-monitoring/condition-fields#velocity) useful: banding `velocity.depositCount24h` at `5` / `10` / `20` turns "unusual frequency" into three graded contributions instead of one cliff edge. ## Versioning Rules are **append-only**: saving an edit creates a new version and enables it atomically, so the change is live on the very next ingested transaction. The rule page shows the full **version history**: enabling a previous version disables every other version of that key, and disabling a rule stops it from firing on the next ingest while keeping all versions reconstructable. Because ingested transactions record the exact rule versions that fired, historical decisions remain explainable regardless of how the rule set evolves. ## Backtesting Before enabling a rule (or a new version of one), you can **backtest** it: a dry-run of the rule, as currently edited, against your stored transactions over a chosen scan window. The backtest reports: - how the **simulated decisions** compare with the stored baseline (Allow / Review / Block distribution); - how often the candidate rule **would fire**, per band for banded rules; - a **sample of fired transactions** with their simulated decision and `P(risk)`. You can run the candidate rule alone or combined with the currently enabled rules; a candidate sharing an enabled rule's key replaces it for the run. Nothing is persisted or billed, the backtest uses the same validation and evaluation core as live ingestion.
The rule page: Raise alert toggle, the Backtest panel, and the append-only version history below.
## Templates vs rules A **rule** is what the engine evaluates: a condition you own, versioned, with probabilities you set. You can create a rule from a blank builder at any time. A **template** (the dashboard also calls these models) is a **starter**: a pre-filled copy of a known pattern, tagged with a jurisdiction and often a regulator citation. Instantiating a template **pastes it into your rule set** as an ordinary rule. After that it is yours — edit, retune, disable, or ignore the rest of the catalog. The cards you see (“Causale anomala”, “Controparte in paese ad alto rischio”, large deposit, night-time activity, …) are **examples, not the full universe** of rules you can run. Banca d’Italia / UIF _indicatori di anomalia_ cover far more typologies than the seeded cards. If a pattern is missing, create a rule from scratch over the [condition fields](/docs/guides/transaction-monitoring/condition-fields), or instantiate the closest template and change the condition. ## Rule templates **Transaction Monitoring → Rule Templates** is a jurisdiction-tagged catalog of ready-made rules, with regulator citations (for example UIF _indicatori di anomalia_, FCA/JMLSG) plus universal primitives that apply anywhere.
The template catalog, filterable by jurisdiction, each card shows the condition, type, probabilities, and alert flag.
### What instantiating does Instantiating turns a **parametric template** into a **concrete, enabled rule** (version 1) in your organization. On the Instantiate dialog you set, for _this_ copy: - **Rule key, name, description** — how it will show up in your rule list and in fired-rule provenance. - **Low / medium / high cutoffs** — only for banded templates. These are the numeric thresholds of the metric (for amount templates, in **minor units**). - **Probabilities** per band (or the single probability of a boolean template). - **Raise alert** — whether a firing also opens a review alert and hits your webhook. The **condition** (when the rule fires) comes from the template and is not edited in that dialog. Change it afterwards on the rule, like any other rule. Template provenance is stored so you can see which catalog entry it came from. Think of it as: pick a starter → name it and set your policy thresholds → it is live on the next ingested transaction. Cutoffs you do not yet know can be agreed at onboarding and filled in then; you can also retune them later and backtest first. ### Catalog Filter the page by **Universal**, **IT**, or **UK**. Filtering by a jurisdiction also keeps the universal entries, since those apply to every book. The in-product catalog is always the live list; the tables below are the current curated set. **Universal** (any book) | Template | What it catches | | --------------------------------- | ------------------------------------------------------------------------------------------- | | Blocklisted counterparty | Counterparty account is on a block list (hard block through the combined score). | | High-risk country (either leg) | Origin or counterparty country is on an enabled country-risk list. | | Suspicious keyword in description | Payment description matches a keyword list (SEPA _causale_). | | Large deposit / large withdrawal | Amount banded in minor units; adjust cutoffs to your currency. | | Night-time activity | Hour of day 00:00–05:59 in the organization timezone. Weak signal; accumulates with others. | | New account, high value | Identity verified less than 24 hours ago, amount banded. | **Italy (UIF _indicatori di anomalia_, Provvedimento 12/05/2023, applicable from 1 January 2024)** | Template | Indicator (indicative) | | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | Controparte in paese ad alto rischio (lista configurata) | Either country leg on your configured Italian risk list. _Indicatore 6._ | | Causale anomala | Payment description matches the Italian keyword pack. _Art. 5(1), parametri qualitativi di selezione._ | | Operatività frazionata (structuring) | Repeated EUR cash deposits just under the €10,000 threshold within 24h, banded on `velocity.depositCount24h`. _Indicatore 13, sub-indice 15.11._ | | Movimento rilevante in contanti | EUR movement on the cash channel, banded by amount. _Indicatore 13; art. 4(5)(d)._ | | Carta utilizzata fuori orario | Card activity outside 08:00–19:59 in the organization timezone. Weak proxy; does not raise an alert on its own. _Sub-indice 15.10._ | | Operatività crypto di importo rilevante | EUR movement on a crypto channel or rail, banded by amount. _Indicatore 26 and sub-indici 26.1–26.5._ | **United Kingdom (JMLSG / FCA)** | Template | Indicator (indicative) | | ----------------------------- | ---------------------------------------------------------------------------- | | High-risk jurisdiction | FATF/HMT-style country-risk list hit. | | Unusual transaction frequency | Deposit count over 24h, banded on `velocity.depositCount24h` at 5 / 10 / 20. | :::warning[The Italian templates are selection signals, not determinations] Article 4(5) of the Provvedimento is explicit that the mere occurrence of an indicator or sub-index — or the use of cash — is not by itself sufficient grounds for a report. The suggested cutoffs and probabilities shipped with these templates are **product starter values for you to calibrate**; they are not prescribed or endorsed by the UIF. ::: The velocity-based templates (**Operatività frazionata**, **Unusual transaction frequency**) are live and firing: they band on the rolling counters documented under [Velocity](/docs/guides/transaction-monitoring/condition-fields#velocity). You can also encode, as ordinary rules, patterns the seeded cards do not name: round amounts, just-under-threshold single payments, weekend activity, new-account plus high-risk country, allowlisted counterparties as suppressors, KYC risk score on the identity, spend against the identity's own 90-day average, velocity over any of the four windows, and any AND/OR combination of the glossary fields. That list is still not exhaustive; the builder is. :::info[Who curates the catalog] The template catalog itself is platform-curated: your organization can list templates and instantiate them, but not add, edit, or remove catalog entries. If a typology you need is missing, either build it as an ordinary rule or ask Zyphe to add it to the catalog. A template Zyphe retires disappears from the catalog and can no longer be instantiated; rules you already created from it keep working and keep their provenance. ::: --- ## Settings and Alerts **Transaction Monitoring → Settings** holds the organization-wide values every rule uses: how the combined `P(risk)` turns into a decision, which timezone interprets time-of-day fields, and where alerts are delivered. These are **not per-rule**. Each rule’s condition can _read_ hour of day or compare `P(risk)` bands; the clock and the Allow / Review / Block cutoffs themselves live here. Change them once, and every enabled rule sees the new values on the next ingest.
The Settings page: review and block thresholds over P(risk), the timezone, and the alert webhook.
## Decision thresholds Two percentage thresholds over the combined `P(risk)` split the decision space: | Range | Decision | | ------------------------------------ | -------- | | `P(risk)` below the review threshold | Allow | | `P(risk)` ≥ review threshold | Review | | `P(risk)` ≥ block threshold | Block | Tightening or loosening the thresholds takes effect on the next ingested transaction; already-decided transactions keep their original verdict. Set the thresholds to match the policy you agreed at onboarding (when a payment is held for review vs blocked). They apply to the **combined** `P(risk)` after all fired rules have been merged, not to a single rule’s probability. ## Timezone An IANA timezone (for example `Europe/Rome`) is the clock for **local operativity**. It drives the derived time fields in the rule builder: hour of day, day of week, and outside business hours. Set it to the timezone your transaction book actually operates in, so a “night-time” or “weekend” rule fires in Italian (or UK) local time rather than in UTC. A payment at 01:00 in Rome is hour `1` when this is `Europe/Rome`, even if the ingest server is elsewhere. Time-of-day **conditions** still live on the rule; this setting is how those conditions are interpreted. ## Alerts A rule saved with **Raise alert** does more than contribute probability when it fires: - an **alert** is recorded against the transaction, visible in the transaction detail's fired-rules breakdown; - the alert is delivered to your **webhook**, so you can route it into your own review or case-management workflow. Alerts carry full provenance, the rule key, the exact rule version, and the probability it contributed, and every raised alert is also written to the immutable audit trail. ## Alert webhook Alerts are delivered to any organization [webhook endpoint](/docs/guides/webhook/endpoints) subscribed to `transaction.alert.created`. The payload identifies the transaction (including your external ID), the verified identity, the decision, the combined risk probability, and the raised alerts with their rule provenance. `transaction.alert.created` is not flow-bound, so an endpoint's flow filter does not apply to it: an endpoint scoped to selected flows still receives TM alerts if it subscribes to them. Deliveries are signed the same way as every other webhook — see [Webhook signature](/docs/guides/webhook/webhook-signature). :::note[Existing Transaction Monitoring webhook settings] The webhook URL and signing secret previously configured in Transaction Monitoring settings were converted into a dedicated endpoint named **Transaction Monitoring (migrated)**, keeping the same URL and the same secret. Manage it under Webhooks from now on. ::: --- ## Transactions **Transaction Monitoring → Transactions** lists every payment event streamed by your integration, each with the synchronous Allow / Review / Block verdict it received at ingest time. ## Ingesting transactions Your backend sends each payment event with a secret API key, either through the [Node SDK](/docs/guides/sdk/node#7-transaction-monitoring) (`ingestTransaction`, `getTransaction`, `updateTransactionStatus`) or the SDK API directly. The ingest call answers synchronously with the decision, the risk probability, the fired rules, and any alerts raised. - `externalId` is the idempotency key: sending the same event again returns the original verdict without re-evaluating or billing it twice. - Amounts are integers in minor units (`amountMinor`, e.g. cents). - Report the payment lifecycle as it progresses by updating the status (`Pending`, `Settled`, `Failed`, `Canceled`, `Reversed`). ## The transaction list Each row shows: - **External ID**: your transaction identifier (also the idempotency key). - **Occurred At**: the client event time you reported. - **Direction**: `Deposit`, `Withdrawal`, or `Transfer`. - **Amount** and currency. - **Counterparty**: the other leg of the payment. - **Status**: the payment lifecycle status (`Pending`, `Settled`, `Failed`, `Canceled`, `Reversed`), updatable by your integration as the payment progresses. - **Decision**: the monitoring verdict (`Allow`, `Review`, `Block`), or _Not evaluated_ for transactions ingested before any rules were configured. - **P(risk)**: the combined risk probability behind the decision. - **Fired Rules**: the rules that contributed to the decision. The list can be filtered by status and decision, and clicking a row opens the transaction detail.
The Transactions page lists every ingested payment event with its synchronous verdict.
## Transaction detail The detail page breaks a single transaction down into: - **Payment**: external ID, direction, channel, rail, description, and the timeline: when it occurred, when it was ingested, and when it was decided. - **Parties**: the verified identity (and your own user reference), origin country, and the counterparty's name, country, and account identifier. - **Fired rules**: the heart of the page: each rule that fired, its version, the band it landed in (for banded rules), the probability it contributed, and whether it raised an alert. The header shows the combined risk probability and explains the combination: `P(risk) = 1 − ∏ (1 − pᵢ)`, compared against your review and block thresholds.
The transaction detail shows the payment, the parties, and how each fired rule contributed to the decision.
Because every fired rule is recorded with its exact version, a decision can always be re-explained later, even after the rule has been edited or disabled. ## Seeding sample data (sandbox) In the sandbox, the **Seed sample data** action generates a deterministic synthetic transaction book through the real ingest path, so it arrives already evaluated against your configured rules. You control: - the **seed**: same seed, same book, which keeps demos reproducible; - the number of **transactions** and **identities**; - the **time window** in days; - the **suspicious share**: the percentage of transactions drawn as suspicious patterns: structuring bursts, high-risk countries, flagged keywords, night-time movements. Re-running the same seed replays idempotently, and the outcome reports how many transactions were created, how many replayed, and how many alerts were raised. Seeding is available in the sandbox only, production books are real data. --- ## Antifraud controls Zyphe runs a set of complementary fraud and financial-crime checks across onboarding (KYC, KYB) and ongoing activity (AML screening, Transaction Monitoring). This page is the map of **what exists**; each row links to the page that explains how the check works and where you configure it. Nothing here is a single “fraud score.” Each control produces its own evidence, and you combine them in a flow, a score, or a monitoring rule. ## Onboarding: who the user is | Control | What it catches | Where it lives | | ------------------------------------ | -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | **Document authenticity** | Tampered IDs, screen or paper copies, fake layouts, MRZ/OCR mismatches, voided documents | [Document verification](/docs/how-it-works/document-verification#document-capture-checks) | | **Liveness** | Photos, videos, masks, and other presentation attacks | [Liveness](/docs/how-it-works/liveness) | | **Face match (liveness × document)** | A live person who is not the portrait on the ID | [Liveness](/docs/how-it-works/liveness) — compared against the document portrait | | **Proof of address** | Wrong document type, stale evidence, name mismatch | [Proof of address](/docs/how-it-works/proof-of-address) | | **Device and location signals** | GPS/IP country mismatch, VPN or proxy, blacklisted IP, device fingerprint | [Geolocation](/docs/guides/create-a-flow/geolocation) | | **Self-exclusion registers** | Players who have barred themselves from gambling, checked at signup, deposit and on triggers | [Self-exclusion checks](/docs/how-it-works/self-exclusion) | Identity-document checks run on the capture or upload of a government ID. Corporate and supporting files collected in KYB are cross-checked against the official register and the uploaded evidence (see below), not through the same ID-capture pipeline. ## Business verification: who the company is | Control | What it catches | Where it lives | | --------------------------------------------- | ------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------- | | **Register cross-check** | Business information that does not match the official company register or the uploaded documents | [KYB](/docs/how-it-works/kyb) · [KYB guide](/docs/guides/kyb) | | **UBO discovery** | Hidden beneficial owners; incomplete or circular ownership chains | [Ownership structure](/docs/guides/kyb#ownership-structure-and-recursive-ubo-discovery) | | **UBO and director KYC** | Unverified people behind the company | Each UBO or director runs a linked KYC flow | | **PEP and sanctions on the company and UBOs** | Listed entities and politically exposed persons in the ownership chain | [AML](/docs/aml) | ## Ongoing risk: screening and payments | Control | What it catches | Where it lives | | ------------------------------------ | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | **AML screening** | Sanctions, PEP, watchlists, adverse media, on onboarding and on a cadence | [AML](/docs/aml) · [Monitoring](/docs/aml/monitoring) | | **Risk scoring** | Weighted topics from screening, amplified by jurisdiction, position, and relationship | [Risk scoring](/docs/aml/risk-scoring) · [Scoring](/docs/guides/scoring) | | **Transaction Monitoring** | Payments that break your rules (amount, counterparty, country, keywords, timing) | [Transaction Monitoring](/docs/transaction-monitoring) | | **Inconsistency review (AI agents)** | Hits or fields that look like false positives, and alerts that need a first-line analyst | See [AI agents](#ai-agents-as-first-line-analysts) | Agents can also flag activity that does not fit the subject’s profile (for example a payment pattern that is inconsistent with declared or registered business activity). On Transaction Monitoring that review sits on **raised alerts**, not on every Allow. ## AI agents as first-line analysts Across KYC, KYB, and Transaction Monitoring, the optional AI agent is a **first-line compliance analyst**: it reads the case, proposes a verdict, and — depending on the mode — either waits for a human or acts under a deterministic guard. The same three modes apply on every module: | Mode | What the agent does | | -------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | **Disabled** | The agent does not run. Operators review every hit or alert. | | **Suggest** | The agent runs and surfaces a verdict and rationale. Clears stay suggestions; high-risk paths still reach the human queue. | | **Auto-pilot** | The agent may enact the decision. A clear is enacted only when a non-AI guard also passes; anything the guard vetoes is escalated. | Where you set the mode: | Module | What the agent reviews | Where the mode is set | | -------------------------- | ----------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **KYC (person AML)** | PEP, sanctions, and adverse-media hits on a person | **AML Agent Mode** on the document-verification step. See [AML Agent Mode](/docs/aml#aml-agent-mode). | | **KYB** | Business-information fields vs documents vs the official register | **KYB Agent Mode** on the KYB step. See [KYB Agent Mode](/docs/guides/kyb#kyb-agent-mode). Company and UBO screenings use **AML Agent Mode** on the same step. | | **Transaction Monitoring** | Raised rule alerts (first-line triage so analysts see exceptions) | Planned on **Transaction Monitoring → Settings**, using the same Disabled / Suggest / Auto-pilot values. Until the alert-queue ships, the mode is fixed to **Disabled** and is not shown in the dashboard. Rules still fire, and alerts still go to your webhook. | Missing or unparseable configuration fails closed: the agent does not run. ## How the pieces combine A typical full-cycle setup: ```text Document verification (+ authenticity checks) → Liveness (+ face match) → optional Geolocation / Proof of address / Form → AML screening → Risk score → (businesses) KYB register cross-check + UBO unwrapping → ongoing: rescreening + Transaction Monitoring on each payment ``` Scores and monitoring rules are how you turn those signals into a policy (review, block, escalate). See [Scoring](/docs/guides/scoring) and [Transaction Monitoring](/docs/guides/transaction-monitoring). ## Related - [How it works](/docs/how-it-works) - [AML overview](/docs/aml) - [AML Agentic Review Engine](/docs/aml/agentic-review-engine) - [KYB Agentic Review Engine](/docs/guides/kyb/agentic-review-engine) - [Manual review](/docs/guides/manual-review) --- ## Document verification(How-it-works) Document verification confirms that a government-issued identity document is authentic, readable, and acceptable for your flow, and extracts the fields you need for onboarding and compliance. ## What it does 1. Guides the user to capture or upload the document 2. Reads the contactless chip where the document carries one; see [Chip reading](#chip-reading) 3. Runs authenticity and quality checks (security features, tampering, copy / screen attacks, score thresholds); see [Document capture checks](#document-capture-checks) 4. Applies your **country** and **document-type** filters 5. Enforces **minimum age** when configured 6. Produces a step result (`PASSED`, `FAILED`, or review statuses) with optional structured `reasons` ## Chip reading Many modern identity documents carry a contactless chip: most current passports, and biometric national identity cards and driving licences in a growing number of countries. Where the presented document has one and the capture device can reach it, Zyphe reads the chip in addition to the printed document. The chip matters because its contents are signed by the issuing authority. Fields read from it are not a transcription of what a camera saw, so a forged or altered printed surface does not survive comparison with them, and the portrait can be taken from the chip rather than from the photograph on the card. Chip reading supplements the image pipeline, it does not replace it. A document is still checked for tampering, screen and paper capture, template match and MRZ consistency, because not every document carries a chip and not every capture context can reach one. Where no chip is present or it cannot be read, verification proceeds on the printed document and the checks below. ## Document capture checks When a document is captured or uploaded, the platform runs automated authenticity, quality, and data-consistency checks before accepting it. Failures surface as structured codes on the step result (`data.dv.reasons[]`); see [Statuses and codes](/docs/reference/statuses-and-codes#document-verification-reasons-datadvreasons). | Check | Description | | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Tamper check | Detects if the ID's main portrait was physically tampered. | | ID alteration check | Validates whether there are any foreign objects on the document. | | Alignment | Flags when the picture is badly aligned and the alignment/cropping correction could not produce a usable crop, and when the cropped capture is too close to the image edges. | | Screen ID liveness | Confirms whether the document was captured from a screen rather than the physical plastic document. | | Paper ID liveness | Confirms whether the document was captured from a printed paper rather than the physical plastic document. | | Voided ID check | Flags IDs that have been intentionally voided, such as those with cut corners, punched holes, or visible void marks. These alterations indicate the ID is no longer valid for use. | | Fake ID check | Searches for discrepancies in the document layout and other signs of fraud. | | Template check | Checks whether the document layout matches a supported document template (text positions and presence of security features). | | MRZ cross-check | Checks whether data extracted from the MRZ matches data extracted by OCR. | | Expiration date validity | Confirms that the expiration date is valid. | | Document type side cross-check | Checks front/back consistency of the document (for example, if both images are the front of the ID). | | Issue date validity | Confirms that the document issue date is valid. | | Barcode presence and format | When a barcode is expected on the document template, checks that it is present and matches the expected format. | | Image quality check | Flags glares above a threshold and low-resolution images. | These checks contribute to the document authenticity score and step outcome. You can tune the **minimum acceptable document score** and related filters in the flow builder. ## Where it sits in a flow Document verification is usually the first identity step. Pair it with [liveness](/docs/how-it-works/liveness) so you know a live person matches the document portrait. Other steps (PoA, phone, forms) can follow depending on risk appetite. ```text Document verification → Liveness → (optional PoA / form / phone) → Result + webhook ``` ## Outcomes you should handle | Outcome | What to do | | ---------------------- | -------------------------------------------------------------------------------------------------------------- | | `PASSED` | Continue the flow or accept the identity evidence | | `FAILED` + `reasons[]` | Map codes to UX (retry, different document, support), [statuses and codes](/docs/reference/statuses-and-codes) | | Manual review | Keep the user pending until review completes, [manual review](/docs/guides/manual-review) | ## Configure it Operational settings (thresholds, filters, labels) live in the flow builder: → **[Document verification guide](/docs/guides/create-a-flow/document-verification)** · **[Create a flow](/docs/guides/create-a-flow)** ## Related - [Antifraud controls](/docs/how-it-works/antifraud-controls), where document checks sit next to liveness, KYB, AML, and TM - [Verification process](/docs/verification-process), public link vs SDK - [Webhook payload: DV](/docs/guides/webhook/webhook-payload#document-verification-datadv) - [Reusable credentials](/docs/reusable-credentials-one-click-kyc), reuse a prior verification when eligible --- ## How it works Short product explainers: what each capability does, where it sits in a flow, and where to configure it. For architecture and data movement, use [Verification process](/docs/verification-process) and [Data flows](/docs/data-flows). For click-by-click setup, use [Guides](/docs/guides/dashboard). | Capability | Outcome | Guide | | --------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------------------- | | [Document verification](./document-verification.md) | Authenticate and extract identity documents | [Configure](/docs/guides/create-a-flow/document-verification) | | [Liveness](./liveness.md) | Confirm a live person matches the ID portrait | [Configure](/docs/guides/create-a-flow/liveness) | | [Proof of address](./proof-of-address.md) | Verify residency evidence | [Configure](/docs/guides/create-a-flow/proof-of-address) | | [Business verification (KYB)](./kyb.md) | Verify companies, UBOs, and directors | [Configure](/docs/guides/kyb) | | [Self-exclusion checks](./self-exclusion.md) | Check gambling self-exclusion registers at signup and deposit | [How it works](/docs/how-it-works/self-exclusion) | | [Antifraud controls](./antifraud-controls.md) | Map of document, liveness, KYB, AML, TM, and agent checks | [The map](/docs/how-it-works/antifraud-controls) | Every check on one page, including the ones without an explainer here (geolocation, phone, wallet, SPID/CIE, TIN Check), with what each returns: [Verification types](/docs/verification-types). Also in Overview (deeper concepts): - [AML](/docs/aml) - [Transaction monitoring](/docs/transaction-monitoring) - [Reusable credentials](/docs/reusable-credentials-one-click-kyc) - [Scoring](/docs/guides/scoring) (operational home of the shared scoring engine) --- ## Business verification (KYB) KYB verifies a **company** rather than an individual: registry data, ownership (UBOs), directors, documents, and screening, with an optional agentic review path for scale. ## What it does 1. Collects business identity and structure (legal entity, addresses, key people) 2. Cross-checks sources and uploaded evidence against official company registers in 49 countries and territories and every US state 3. Can **discover the ownership structure automatically** from official business registers, instead of asking the applicant to declare it 4. Handles every submission as a **KYB case** that tracks what was checked, what is still owed and by whom, the risk rating, and the decision 5. Decides cases under your organization's **compliance policy**: who may approve at each risk rating, when a second signature is needed, and how screening matches are treated 6. Records an audit trail of submissions, requests, verdicts, exceptions, and decisions 7. Can run the [agentic review engine](/docs/guides/kyb/agentic-review-engine) to review cases under policy guards ## How a KYB flow is built A KYB flow is an **anchor** step that collects business information, plus optional **satellite** steps for company documents, beneficial owners, and directors. They all write into one KYB case, so a reviewer sees a single case however many parts the applicant walked through. A flow can also be a single anchor that collects business information and nothing else. Which parts the applicant actually walks depends on configuration: with ownership discovery on, the owner and director parts are skipped entirely and Zyphe resolves those people from the registers, falling back to asking the applicant only when it cannot. → [KYB steps and configuration](/docs/guides/kyb/steps-and-configuration) · [Ownership discovery](/docs/guides/kyb/ownership-discovery) · [Country coverage](/docs/guides/kyb/country-coverage) ## How it differs from KYC | | KYC | KYB | | ---------------- | ----------------------------- | ----------------------------------------------------------- | | Subject | Natural person | Legal entity + related people | | Primary evidence | ID document, liveness, PoA | Registry, ownership, corporate docs | | Typical outcome | Flow result for an individual | A KYB case, decided by a reviewer | | Integration | Flow steps + webhooks | Dashboard, API, and `data.kybCase` webhooks (see KYB guide) | ## Statuses to know A case moves through `OPEN` (the applicant is filling in the flow) → `PROCESSING` (checks running) → `WAITING_INPUT` or `ACTION_REQUIRED` when the applicant or a person owes something → `READY_FOR_REVIEW` → `APPROVED` or `REJECTED`, or `CANCELLED`. Clean companies are not approved automatically: a reviewer, or the KYB agent in Auto-pilot, decides. A decided case can be reopened by a resubmission, a quality review, or a periodic re-review. Details: [Statuses and codes](/docs/reference/statuses-and-codes#kyb-and-aml-statuses). ## Configure and operate → **[KYB guide](/docs/guides/kyb)** · **[Reviewing KYB cases](/docs/guides/kyb/reviewing-cases)** · **[Compliance policy](/docs/guides/kyb/compliance-policy)** · **[Agentic review engine](/docs/guides/kyb/agentic-review-engine)** ## Related - [AML overview](/docs/aml), person and entity screening concepts - [Scoring](/docs/guides/scoring), organization-defined risk scores - [Sandbox and go-live](/docs/guides/sandbox-and-go-live) --- ## Liveness Liveness confirms that a **real person** is present and that their face matches the portrait from [document verification](/docs/how-it-works/document-verification). It reduces spoofing (photos, screens, masks) and is the usual companion step for full identity verification. ## What it does 1. Requires a completed document step that produced a portrait 2. Prompts the user through an active liveness capture 3. Runs anti-spoof and quality checks (brightness, sharpness, occlusion, eyes, …) 4. Compares the live face to the document portrait against your match threshold 5. Optionally supports biometric uniqueness checks (contact support to enable) ## Where it sits in a flow Always **after** document verification (or another step that supplies a reference portrait). Without that link, face match has nothing trusted to compare against. ## Outcomes you should handle Failures often surface as DV/liveness-related reason codes such as `LIVENESS_CHECK_FAILED`, `LIVENESS_ANTISPOOF_FAILED`, or `FACE_MATCH_CHECK`. See [Statuses and codes](/docs/reference/statuses-and-codes). Tune the **minimum portrait match percent** if you see too many false rejects vs fraud risk. ## Configure it → **[Liveness guide](/docs/guides/create-a-flow/liveness)** · **[Create a flow](/docs/guides/create-a-flow)** ## Related - [Document verification](/docs/how-it-works/document-verification) - [Antifraud controls](/docs/how-it-works/antifraud-controls) - [Verification process](/docs/verification-process) - [Scoring](/docs/guides/scoring), combine biometric and other signals into review policy --- ## Proof of address(How-it-works) Proof of address (PoA) verifies that a user can present acceptable evidence of residency (utility bills, bank statements, and similar documents), with checks on type, recency, name match, and address extraction. ## What it does 1. Collects an allowed address document 2. Validates document type against your configuration 3. Checks name consistency with the verified identity where applicable 4. Enforces recency (documents that are too old fail with `DATE_TOO_OLD`) 5. Returns a step result with optional structured `reason` ## Where it sits in a flow Usually **after** core identity (document ± liveness), when regulation or risk policy requires residency evidence. It can also run in flows that already know the user from reusable credentials. ## Outcomes you should handle | Reason (examples) | Meaning | | --------------------------- | --------------------------------------- | | `DOCUMENT_TYPE_NOT_ALLOWED` | User must upload a different type | | `NAME_MISMATCH` | Name does not match identity | | `DATE_TOO_OLD` | Document outside allowed age | | `UNRECOGNIZED_ADDRESS` | Address could not be parsed confidently | Full list: [Statuses and codes: PoA](/docs/reference/statuses-and-codes#proof-of-address-reasons-datapoareason). ## Configure it → **[Proof of address guide](/docs/guides/create-a-flow/proof-of-address)** · **[Create a flow](/docs/guides/create-a-flow)** ## Related - [Geolocation step](/docs/guides/create-a-flow/geolocation), location-based signals when configured - [Webhook payload: PoA](/docs/guides/webhook/webhook-payload) --- ## Self-exclusion checks A self-exclusion register lists people who have asked to be barred from gambling. Serving one is a licence breach in every regulated market that operates a register, and the obligation sits on the operator, not on the player. Zyphe calls the register as part of the verification flow, so the answer arrives with the identity evidence rather than from a separate system the operator has to reconcile afterwards. ## What it does The check runs against the register for the market the player is in, using the identity Zyphe has just verified. Because the person has been verified from a government document rather than from a typed name, the lookup is made on confirmed identity data, which is what makes a register answer dependable: a register match is only as good as the name and date of birth it was given. Zyphe integrates the national registers by default where one exists: | Register | Market | Notes | | ----------------------------------------- | ----------------------------------- | ------------------------------------------------------------------------------ | | **GAMSTOP** | United Kingdom | Participation is a condition of a remote operating licence | | **Spelpaus** | Sweden | Checked at registration and again at every login, as Spelinspektionen requires | | **Coalition for Fantasy Sports / idPair** | United States, daily fantasy sports | Cross-operator self-exclusion for fantasy contests | Where a market's register is less mature, or where an operator participates in a scheme not listed above, the check is added through the same policy layer rather than requiring an integration release. ## When it runs The register is not consulted once. A player can self-exclude at any time, including after they have onboarded, so the check runs: 1. **At signup**, before the account is usable. 2. **At first deposit**, because that is the point where money first moves. 3. **On configurable triggers thereafter**, so a player who excludes mid-relationship is caught before the next deposit rather than at a periodic review. A positive result rejects the action and is recorded with the rest of the verification evidence, which is the record a regulator asks for when it examines how an excluded player reached the product. ## Where it sits Self-exclusion is a licence control, not an identity control, and it depends on identity being settled first. In a typical flow it follows document verification and liveness, alongside the age check, and it runs again on the deposit path. ```text Document verification → Liveness → Age → Self-exclusion → (deposit path: self-exclusion again) ``` ## Related - [Antifraud controls](/docs/how-it-works/antifraud-controls), the map of every check - [Document verification](/docs/how-it-works/document-verification), the identity the register is queried with - [AML](/docs/aml), sanctions, PEP and adverse media screening, which is a separate obligation --- ## Statuses and codes This page is the **authoritative vocabulary** for statuses, webhook events, and structured reasons you will see in the dashboard, webhooks, and API. Prefer these enums over free-text `errorMessage` when branching application logic. Payload field layout lives in [Webhook Payload](/docs/guides/webhook/webhook-payload). Failure handling is in [Failure and Review Events](/docs/guides/webhook/failure-payload). --- ## Three layers of status A single webhook can carry different statuses at different layers. Do not treat them as synonyms. | Layer | Field | Scope | | ------------------ | ------------------------------------------------------------------------------- | --------------------------------------- | | **Delivery event** | top-level `event` | Why this webhook was sent | | **Flow / request** | `flowStatus` (webhook) · `status` on a flow result / verification request (API) | Overall outcome of the verification run | | **Step result** | `data..status` | Outcome of one step (DV, PoA, form, …) | Example: a DV step can be `FAILED` with `reasons: ["DOCUMENT_EXPIRED"]` while you still handle a later step, or the whole flow can move into review — delivered as a `REVIEW` event with `flowStatus: "REVIEW"`, while reading the same flow result via the API returns `REQUIRES_MANUAL_REVIEW`. --- ## Webhook `event` values (`LEGACY_V1`) ### Verification results | Value | Meaning | Typical next action | | -------------- | ---------------------------------------------- | --------------------------------------------------- | | `COMPLETED` | The step or flow completed successfully | Trust `data` / `flowStatus`; provision the user | | `FAILED` | The step or flow failed automatically | Read structured reasons; allow retry or reject | | `REVIEW` | Human review is required | **Do not reject yet**. Wait for a later final event | | `REJECTED` | Explicit rejection (often after manual review) | Treat as declined | | `SUBMITTED` | A KYB application was submitted (KYB only) | **Do not provision yet**. Wait for a final event | | `NOTIFICATION` | Lifecycle notification (not a step result) | Route on `eventData.type` | ### AML updates | Value | Meaning | | ----------- | ------------------------------------------------------------------- | | `PRODUCED` | Initial AML screening result produced | | `REFRESHED` | Ongoing monitoring refreshed matches | | `MODERATED` | An AML match was moderated (`APPROVED`, `REJECTED`, or `ESCALATED`) | ### Notification `eventData.type` Used only when `event` is `NOTIFICATION`: | Type | Meaning | | ----------------------- | --------------------------------------------------------------- | | `DOCUMENT_EXPIRED` | A verified identity document has expired | | `KYC_RESULT_EXPIRED` | A KYC / flow result has passed its retention or validity window | | `FLOW_RISK_REEVALUATED` | Risk scores were recomputed (for example after tag changes) | | `TRANSACTION_ALERT` | A Transaction Monitoring rule raised an alert | --- ## Canonical webhook event types These are the values a [webhook endpoint](/docs/guides/webhook/endpoints) subscribes to, and the value carried in `type` on a `V2` payload. They are **not** the same vocabulary as the `event` field above: `event` is derived from a verification's status and collapses every notification to `NOTIFICATION`, so it cannot distinguish a DV result from a KYB result, or one notification kind from another. Only these values are accepted. Wildcards are not: a selection is always stored as exact values, so a later addition to this catalog cannot widen a subscription you already made. The live catalog for a deployment is served by `GET /organizations/{organizationId}/webhooks/events`. ### Verification | Event type | Fired when | | ------------------------------------------------------------ | ---------------------------------------------------------------------------------- | | `verification.dv.completed` · `.failed` · `.review` | A document-verification result reaches that state | | `verification.poa.completed` · `.failed` · `.review` | A proof-of-address result reaches that state | | `verification.form.completed` · `.failed` · `.review` | A form result reaches that state | | `verification.spid.completed` · `.failed` · `.review` | A SPID / CIE result reaches that state | | `verification.phone.completed` · `.failed` · `.review` | A phone-verification result reaches that state | | `verification.wallet.completed` · `.failed` · `.review` | A wallet result reaches that state | | `verification.kyb.submitted` | A KYB application was submitted and its checks started. Not an outcome | | `verification.kyb.completed` · `.failed` · `.review` | A KYB case reaches that state. See [KYB event lifecycle](#kyb-event-lifecycle) | | `verification.geolocation.completed` · `.failed` · `.review` | A geolocation result reaches that state | | `verification.aml.produced` · `.refreshed` · `.moderated` | An AML screening result is produced, refreshed by ongoing monitoring, or moderated | | `verification.document.expired` | A verified identity document has expired | | `verification.kyc.expired` | A KYC / flow result passed its validity window | ### Flow | Event type | Fired when | | ----------------------- | ----------------------------------------------------------------- | | `flow.risk.reevaluated` | Risk scores were recomputed for a flow result | | `flow.completed` | Every step the flow asks for has a passing result. **`V2` only.** | ### Transaction | Event type | Fired when | | --------------------------- | ----------------------------------------------------------------------------------------------------------- | | `transaction.alert.created` | A Transaction Monitoring rule raised an alert. Not flow-bound, so an endpoint's flow filter does not apply. | ### KYC Passport | Event type | Status | | ----------------------------------- | -------------------------------------------------------------------------------------- | | `kyc_passport.verification.updated` | **Reserved.** Present in the catalog and subscribable, but not yet emitted. `V2` only. | ### Availability notes - Events marked **`V2` only** have no pre-registry payload, so a `LEGACY_V1` endpoint cannot subscribe to them; the API rejects the combination when you save it. See [Payload Versions](/docs/guides/webhook/payload-versions). - [Session webhooks](/docs/guides/webhook/session-webhooks) cannot subscribe to `transaction.alert.created` or `kyc_passport.verification.updated`. - The catalog API also returns an advisory `group` (`VERIFICATION`, `FLOW`, `TRANSACTION`, `KYC_PASSPORT`) and `flowScoped` flag for building a selection UI. Groups are never stored. --- ## Flow and verification-request status `flowStatus` on result webhooks and `status` on verification requests / flow results describe the same verification run, but use **different vocabularies**. Webhooks speak the event vocabulary; the API exposes the full lifecycle. ### Webhook `flowStatus` | Status | Meaning | | ------------ | ---------------------------------- | | `PROCESSING` | Automated checks in progress | | `COMPLETED` | Finished successfully | | `FAILED` | Finished with an automatic failure | | `CANCELLED` | Cancelled before completion | | `REVIEW` | Waiting on a human review decision | | `REJECTED` | Explicitly rejected | `flowStatus` never carries `PENDING`, `QUEUED`, or `REQUIRES_MANUAL_REVIEW`: webhooks are not sent for runs the user has not finished, and review states are always delivered as `REVIEW`. ### API `status` (flow results / verification requests) | Status | Meaning | | ------------------------ | ---------------------------------- | | `PENDING` | Created; user has not finished | | `QUEUED` | Waiting to be processed | | `PROCESSING` | Automated checks in progress | | `COMPLETED` | Finished successfully | | `FAILED` | Finished with an automatic failure | | `CANCELLED` | Cancelled before completion | | `REQUIRES_MANUAL_REVIEW` | Waiting on a human review decision | | `REJECTED` | Explicitly rejected | When a webhook reports `flowStatus: "REVIEW"`, reading the same flow result or verification request via the API returns `REQUIRES_MANUAL_REVIEW`. --- ## Step result status (`data..status`) Individual step results (document verification, PoA, form, and related types) use: | Status | Meaning | | --------- | ----------------------------------------- | | `PASSED` | Step checks passed | | `FAILED` | Step checks failed | | `PARTIAL` | Incomplete or partially successful result | | `REVIEW` | Human review in progress (DV only) | Document verification is the only step type that can enter review; in webhooks its result status is delivered as `REVIEW`, and reading the same DV result via the API returns `REQUIRES_MANUAL_REVIEW`. KYB cases use their own vocabulary ([KYB case status](#kyb-case-status), below). :::warning `REVIEW` — at the event, flow, or step layer — means “keep pending.” Use the final `COMPLETED` / `FAILED` / `REJECTED` event as the decision to act on in your product. ::: --- ## Document verification reasons (`data.dv.reasons[]`) Empty when no reason is reported. Values come from the API `DvReason` enum. ### Document quality and authenticity | Code | Typical meaning | | -------------------------------- | ----------------------------------------------------- | | `WRONG_DOCUMENT_TYPE` | Submitted type does not match what the step allows | | `DOCUMENT_TYPE_NOT_DEFINED` | Type could not be determined | | `DOCUMENT_TYPE_CHECK` | Type validation failed | | `DOCUMENT_NOT_FOUND` | No usable document in the capture | | `DOCUMENT_SCORE_BELOW_THRESHOLD` | Authenticity / quality score below configured minimum | | `SECURITY_CHECK_FAILED` | Built-in security features failed checks | | `DOCUMENT_ALTERATION_DETECTED` | Signs of alteration | | `DOCUMENT_TAMPERING_DETECTED` | Signs of tampering | | `FAKE_DOCUMENT_DETECTED` | Classified as fake | | `SCREEN_REPLAY_ATTACK_DETECTED` | Screen / replay presentation attack | | `PAPER_COPY_DETECTED` | Paper copy rather than original | | `BLACK_AND_WHITE_COPY` | B/W copy of a color document | | `ELECTRONIC_DEVICE` | Capture from another screen/device | | `SECURITY_TEXT` | Security text check failed | | `IMAGE_PATTERNS` | Image-pattern check failed | | `PHOTO_EMBEDDINGS` | Portrait embedding consistency failed | ### Country, age, and field rules | Code | Typical meaning | | --------------------------------- | ------------------------------------------ | | `COUNTRY_FILTER` | Country not allowed by whitelist/blacklist | | `DOCUMENT_COUNTRY_MISMATCH` | Country does not match expected value | | `DOCUMENT_COUNTRY_MISSING` | Country could not be read | | `DATE_OF_EXPIRY_NOT_VALID` | Expiry invalid or document expired | | `DATE_OF_EXPIRY_NOT_READABLE` | Expiry unreadable | | `DATE_OF_EXPIRY_FIELD_MISSING` | Expiry field missing | | `DATE_OF_BIRTH_BELOW_MINIMUM_AGE` | Below the flow’s minimum age | | `REQUIRED_FIELDS_MISMATCH` | Required extracted fields inconsistent | ### Face, liveness, and uniqueness | Code | Typical meaning | | --------------------------------------- | ------------------------------------------------------ | | `FACE_MATCH_CHECK` | Face match against the document failed | | `FACE_MATCH_CHECK_ONE_CLICK` | Face match failed in a one-click / reuse path | | `LIVENESS_CHECK_FAILED` | Liveness overall failed | | `LIVENESS_ANTISPOOF_FAILED` | Anti-spoofing failed | | `LIVENESS_BRIGHTNESS_FAILED` | Lighting / brightness out of range | | `LIVENESS_EYES_CLOSED_FAILED` | Eyes closed | | `LIVENESS_WEARING_SUNGLASSES_FAILED` | Sunglasses detected | | `LIVENESS_FACE_OCCLUDED_FAILED` | Face occluded | | `LIVENESS_SHARPNESS_FAILED` | Image not sharp enough | | `LIVENESS_FACE_CONSISTENCY_FAILED` | Face consistency across frames failed | | `UNIQUENESS_CHECK` | Biometric uniqueness / duplicate identity check failed | | `DOCUMENT_ALREADY_USED_BY_ANOTHER_USER` | Document already bound to another identity | | `DOCUMENT_FINGERPRINT_COMPUTATION` | Document fingerprinting failed | ### Other | Code | Typical meaning | | ---------------- | --------------------------------------------------------- | | `OVERALL_STATUS` | Aggregate step status failed without a more specific code | | `UNKNOWN` | Unclassified reason | --- ## Proof of address reasons (`data.poa.reason`) | Code | Typical meaning | | --------------------------- | ----------------------------------------- | | `DOCUMENT_TYPE_NOT_ALLOWED` | Type not accepted for PoA | | `NAME_MISMATCH` | Name does not match the verified identity | | `DATE_TOO_OLD` | Document older than allowed window | | `INVALID_DOCUMENT` | Document not valid for PoA | | `UNRECOGNIZED_ADDRESS` | Address could not be recognized | | `UNKNOWN` | Unclassified reason | Other step types (`form`, `phone`, `wallet`, `kyb`, `geolocation`, `spid`) may expose optional `reason` / `errorMessage` strings. Prefer structured fields when present; use `errorMessage` for diagnostics only. --- ## KYB and AML statuses ### KYB case status | Status | Meaning | | ------------------ | ----------------------------------------------------------------------------------------------------------- | | `OPEN` | The applicant is filling in the flow. An idle draft is cancelled after 30 days and resumed on the next save | | `PROCESSING` | Submitted; the case's checks are running | | `WAITING_INPUT` | A document request or clarification is open with the applicant | | `ACTION_REQUIRED` | A person has to act (a screening match that holds, an escalation) | | `READY_FOR_REVIEW` | Every check finished; waiting for a decision | | `APPROVED` | Approved by a decision | | `REJECTED` | Rejected by a decision | | `CANCELLED` | Abandoned, or the country changed before submission | `APPROVED` and `REJECTED` are not final: a case can be reopened by a resubmission, a quality review, or a periodic re-review. Each opening is an **episode** (`CREATED`, `RESUBMITTED`, `QA_REOPENED`, `PERIODIC_REVIEW`). How to work each status: [Reviewing KYB cases](/docs/guides/kyb/reviewing-cases). ### KYB moderation (`ModerationResultStatus`) The deprecated `data.kyb` object still carries the previous `ModerationResultStatus` vocabulary (`ACQUIRING`, `PENDING_MODERATION`, `REVIEW_REQUIRED`, `SUCCESS`, `FAILED`) for existing integrations. `ENRICHING` no longer exists. New integrations should read the case status from `data.kybCase.status`. ### KYB event lifecycle Each case transition that reaches a webhook, with the canonical event and the legacy `event` value: | Transition | Canonical event | Legacy `event` | | ----------------------------------------------------------- | ---------------------------- | -------------- | | Submission (`OPEN` → `PROCESSING`) | `verification.kyb.submitted` | `SUBMITTED` | | → `ACTION_REQUIRED` | `verification.kyb.review` | `REVIEW` | | → `READY_FOR_REVIEW` because the case's own checks finished | _none_ | _none_ | | → `READY_FOR_REVIEW` for any other cause | `verification.kyb.review` | `REVIEW` | | Reopened (→ `PROCESSING` after a decision) | `verification.kyb.review` | `REVIEW` | | → `APPROVED` | `verification.kyb.completed` | `COMPLETED` | | → `REJECTED` | `verification.kyb.failed` | `FAILED` | | → `CANCELLED` | _none_ | _none_ | Only `completed` means the business was approved. `review` is also sent when an already approved company is reopened, so do not treat it as a new company. How to act on each event is in the [KYB guide](/docs/guides/kyb#webhook-lifecycle). ### KYB decision reason codes A decision's `reasonCode` classifies why it was taken: | Code | Meaning | | ------------------------ | ------------------------------------------------------------------------------ | | `CDD_INCOMPLETE` | Customer due diligence could not be completed | | `SANCTIONS_CONFIRMED` | A sanctions match was confirmed | | `PEP_CONFIRMED` | A PEP match was confirmed | | `ADVERSE_MEDIA` | Adverse media about the company or its people | | `OUTSIDE_RISK_APPETITE` | The company is outside the organization's risk appetite | | `SUSPECTED_FRAUD` | Fraud is suspected | | `APPLICANT_UNRESPONSIVE` | The applicant did not answer requests | | `OTHER` | Anything else. The default for a decision that owes a reason and sends no code | ### KYB decision refusals When a decision is refused, the error carries its own `errorTag` (all `400`): | `errorTag` | Meaning | | ------------------------------------ | ------------------------------------------------------------------------------ | | `kyb_case_not_decidable` | The case's status does not accept this decision | | `kyb_case_not_ready` | An approval needs the case in `READY_FOR_REVIEW` | | `kyb_case_exception_required` | The approval rests on something that needs a recorded exception first | | `kyb_case_rejecting_hit` | A confirmed match in a category the policy rejects stands on the case | | `kyb_case_reason_required` | The decision needs a `reason` | | `kyb_case_decision_not_authorized` | The approval matrix does not let this caller take this decision | | `kyb_case_second_signature_required` | The confirmation of a proposal must come from a person other than the proposer | Publishing a compliance policy draft that still has open questions returns `409` with `compliance_policy_open_questions`. ### KYB screening match resolution | Outcome | Meaning | | -------------------- | ------------------------------------------------------------------------------------------------------ | | `FALSE_POSITIVE` | The match is not the subject. Needs at least one discriminator. The only outcome that releases a match | | `TRUE_POSITIVE` | The match is the subject | | `UNDETERMINED` | Not decided yet; the match holds | | `CUSTOMER_CONTACTED` | Waiting on the customer; the match holds | Discriminators: `DATE_OF_BIRTH`, `NATIONALITY`, `TAX_OR_ID_NUMBER`, `ADDRESS`, `GENDER`, `OTHER` (with a note). ### KYB document-request types Every item in a KYB document-request payload carries a `requestType`: | Type | Meaning | | ------------------------ | -------------------------------------------------------------------------------------------------------- | | `STANDARD` | Asks the applicant to upload a named document | | `CLARIFICATION` | Asks the applicant to re-confirm or update specific business-information fields | | `UBO_DECLARATION` | Reopens the beneficial-owner step for a fresh declaration when ownership discovery could not resolve one | | `DIRECTOR_DECLARATION` | The same for the director step | | `OWNERSHIP_CONFIRMATION` | Asks the applicant to confirm or correct the owners and directors on file, when a case is reopened | The two declaration types require ownership discovery to be enabled on the step, and block approval while outstanding. ### KYB document-request status | Status | Meaning | | ---------- | --------------------------------------- | | `PENDING` | Awaiting the applicant | | `UPLOADED` | Submitted, under review | | `APPROVED` | Accepted (terminal) | | `REJECTED` | Rejected (terminal, cannot be reopened) | ### KYB screening strategy Which population of natural persons a KYB case must identify and screen before approval: `ubo` (the default), `directors`, or `uboAndDirectors`. See [KYB steps and configuration](/docs/guides/kyb/steps-and-configuration#which-population-must-be-screened). ### KYB due-diligence level Recorded on the case as `SIMPLIFIED`, `STANDARD` (the default), or `ENHANCED`. `ENHANCED` adds a financial-documents requirement. An approver can also record it on the decision, where the `dueDiligenceLevel` field takes `simplified`, `standard`, or `enhanced`. ### PEP & sanctions screening (KYB) | Status | Meaning | | ------------- | --------------------- | | `PENDING` | Not started | | `IN_PROGRESS` | Screening in progress | | `REVIEW` | Match requires review | | `SUCCESS` | Cleared | | `FAILED` | Failed | ### AML result moderation (`data.aml.status`) These values describe the moderation state carried by AML webhook payloads. They are separate from the KYB PEP and sanctions screening states above. | Status | Meaning | | ----------- | --------------------------------- | | `PENDING` | Waiting for a moderation decision | | `APPROVED` | The AML result was approved | | `REJECTED` | The AML result was rejected | | `ESCALATED` | The AML result was escalated | See [AML](/docs/aml) and [KYB](/docs/guides/kyb) for operational workflows. --- ## Transaction monitoring decisions Transaction monitoring returns a synchronous verdict derived from combined rule risk: | Decision | Meaning | | -------- | ---------------------------------------------------- | | `ALLOW` | Below review threshold, proceed | | `REVIEW` | At or above review threshold, hold for investigation | | `BLOCK` | At or above block threshold, do not proceed | See [Transaction Monitoring](/docs/transaction-monitoring) for the Allow / Review / Block model and [TM guides](/docs/guides/transaction-monitoring) for rules and thresholds. --- ## Manual review | Concept | Value / event | | ------------------ | -------------------------------------------------------------------- | | Flagged for review | Webhook `event: REVIEW` · API result status `REQUIRES_MANUAL_REVIEW` | | Operator decision | Manual review result: `approved`, `rejected`, or `failed` | | After decision | Follow-up webhook with `COMPLETED`, `FAILED`, or `REJECTED` | Do not mark the end user as rejected on `REVIEW` alone. See [Manual review](/docs/guides/manual-review). --- ## API errors HTTP API failures use a structured body (`BaxeError`): ```json { "code": 10201, "errorTag": "invalid_api_key", "message": "optional human-readable detail" } ``` | Field | Meaning | | ---------- | ------------------------------------------------------------------------------------------- | | `code` | Numeric error code (stable enough for support; prefer `errorTag` in app logic when present) | | `errorTag` | Machine-readable tag from the API `ErrorTags` enum | | `message` | Optional detail; do not rely on exact wording for branching | ### Authentication and configuration | HTTP | `errorTag` | Typical causes | | ------------- | -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `401` | `invalid_api_key` | Publishable key used on a server endpoint; typo/truncated key; request sent to the wrong host (for example `docs.zyphe.com` instead of `api.zyphe.com`); key revoked | | `401` | `missing_api_key` | No `x-api-key` header | | `401` / `403` | `origin_not_allowed` | Publishable key used from a browser origin not in Allowed Origins | | `403` / other | `permission_denied`, `forbidden` | Key or role cannot perform the operation | | `4xx` | `product_not_active` | Product entitlement missing (for example [Export API](/docs/guides/export-api) not enabled) | Numeric code **`10201`** is commonly returned with `errorTag: "invalid_api_key"`. Fix checklist: 1. Use a **secret** key (`zyphe_sk_…`) for backend calls — [API keys](/docs/guides/api-keys) 2. Call `https://api.zyphe.com` — [Environment setup](/docs/guides/environment-setup) 3. Confirm the key still exists in the dashboard and was copied completely 4. Align sandbox/production usage — [Sandbox mode](/docs/guides/sandbox-mode) ### Other tags you may see while integrating | `errorTag` | Meaning (integration context) | | ------------------------------------------------- | ---------------------------------------------------- | | `flow_not_found` | Wrong flow id or sandbox/production mismatch | | `verification_request_not_found` | Bad VR id or sandbox mismatch | | `step_order_violation` / `step_already_completed` | Completing steps out of order on the direct-API path | | `bad_request` / `request_deserialization` | Invalid JSON or schema | | `rate_limit_exceeded` | Too many requests; back off and retry | The full `ErrorTags` enum is listed in the [OpenAPI](/docs/openapi/zyphe-sdk) schema. Webhook **events** and result **statuses** above are separate from these API tags. --- ## Related - [Webhook endpoints](/docs/guides/webhook/endpoints), configuring destinations and subscriptions - [Payload versions](/docs/guides/webhook/payload-versions), `LEGACY_V1` and `V2` - [Webhook structure](/docs/guides/webhook/webhook-structure), envelopes and delivery - [Webhook payload](/docs/guides/webhook/webhook-payload), field-level examples - [API keys](/docs/guides/api-keys), secret vs publishable - [Environment setup](/docs/guides/environment-setup), base URLs - [OpenAPI reference](/docs/openapi/zyphe-sdk), generated schemas (`DvReason`, `ResultStatus`, `VerificationRequestStatus`, `ErrorTags`, …) --- ## Advanced topics --- ## Proof of KYC ### Introduction #### Purpose This document is a technical guide for implementing **verifiable Proof of KYC** (Know Your Customer), usable both **on-chain** by smart contracts and **off-chain** by APIs, relayers, and traditional services. It outlines several methods for proving that a wallet, identifier, or credential holder has successfully completed a KYC process. Smart contract developers can consume the on-chain variants directly; backend developers, identity wallets, and compliance services can verify the same artifacts off-chain. Both consumers can build custom business logic on top of the verified identity data while preserving compliance and user privacy. #### Overview The **Proof of KYC** solution provides a privacy-preserving way to verify a user's KYC status without exposing the underlying identity attributes, neither on a public ledger nor to off-chain verifiers that don't need them. Zyphe offers five distinct methods, each with different privacy properties, integration complexity, and verification surface: | Method | Verifiable on-chain | Verifiable off-chain | | ---------------------------------------------------------- | :-----------------: | :------------------: | | KYC Soulbound Token issuance | ✓ | - | | Signed KYC Mint Voucher | ✓ | ✓ | | Ethereum Attestation Issuance | ✓ | ✓ | | W3C Verifiable Credentials | ✓\* | ✓ | | Zero-Knowledge Proofs derived from a Verifiable Credential | ✓ | ✓ | \* W3C VCs are typically verified off-chain, but signed presentations can also be checked on-chain via verifier contracts. #### Key Components **Verifiable Credentials (VCs)** Verifiable Credentials represent identity information issued by Zyphe after the KYC verification process. These credentials are cryptographically signed and attest that the user has undergone a KYC process. Each VC is associated with metadata, such as the issuer, date of issuance, and the type of verification performed (e.g., identity verification, proof of address, etc.). **Attestations** An attestation is a cryptographic statement that Zyphe has validated a user's identity. It can be persisted **on-chain** (as a smart-contract event or attestation registry entry) or held **off-chain** as a signed message, JWT, or JSON-LD document. In both cases, the verification surface is public while the underlying KYC data remains off-chain and minimized. **Cryptographic Signatures** Cryptographic signatures verify the integrity and authenticity of verifiable credentials and attestations. When Zyphe issues a credential, it signs it with its private key. **Smart contracts** can verify these signatures on-chain using the corresponding Zyphe public key (registered in an issuer registry), and **off-chain verifiers** (backends, wallets, relayers) can do the same with standard cryptographic libraries. Only artifacts from trusted issuers are accepted. **KYC Tokens** To ensure easy interaction with decentralized applications (dApps) and marketplaces, users who pass the KYC process can be issued a **non-transferable token** (e.g., a soulbound token). This token acts as a proof-of-KYC that is stored on the blockchain. While the token itself does not reveal any sensitive details, dApps can verify its existence to ensure the user has been KYC-verified by Zyphe. **Smart Contracts** For on-chain consumption, the Proof of KYC solution is backed by smart contracts that validate signatures, attestations, and zk-proofs. These contracts define the logic for: - Issuing attestations or soulbound tokens upon verification. - Validating cryptographic proofs when requested by another contract or a dApp. - Managing the lifecycle of issued credentials, including issuance and revocation. Off-chain integrations replace these contracts with equivalent verifier libraries running inside backends, wallets, or compliance services, using the same issuer keys and revocation state. **Signed KYC Mint Voucher** It’s a cryptographically signed message that a protocol can utilize within its smart contract. It provides smart contract developers with full flexibility to implement custom business logic on their side, such as issuing tokens, adding wallet addresses to a whitelist, or other actions based on the KYC verification. ### KYC Soulbound Token issuance In the **KYC Soulbound Token Issuance** solution, the user first connects and authenticates their wallet. Upon successful completion of the KYC process, our backend service issues a **non-transferable Soulbound Token** directly to the authenticated wallet. This token acts as an immutable on-chain representation that the KYC process has been completed, allowing decentralized applications (dApps) to verify the user’s KYC status without exposing any sensitive information. ### Flow ```mermaid sequenceDiagram participant Dapp box Zyphe participant FE as Frontend participant BE as Backend participant KYC as KYC Module end participant BC as Blockchain Dapp->>FE: redirect Note over FE: connect wallet FE->>BE: initiate SIWE login BE->>FE: send challenge Note over FE: sign message FE->>BE: send signed message BE->>FE: start user session BE->>KYC: initiate kyc session KYC->>BE: send challenge BE->>FE: send kyc session Note over FE: initiate kyc provider iframe FE->>KYC: perform kyc required actions KYC->>BE: kyc result webhook BE->>BC: mint token BC->>FE: send soulbound token BE->>FE: send kyc result FE->>Dapp: confirmation ``` #### KYC Soulbound Token issuanceSigned KYC Mint Voucher In the **Signed KYC Mint Voucher** solution, the user first connects and authenticates their wallet. After successfully completing the KYC process, our backend service generates and signs a message that attests to the completion of the KYC. This signed message, similar to a JWT but using EVM-compatible data types, can be consumed by a smart contract on-chain. This approach provides developers with the flexibility to implement their own business logic, such as issuing tokens, whitelisting addresses, or other custom workflows. ### Zero-Knowledge Proofs from a Verifiable Credential In the **zk-Proof from VC** solution, Zyphe issues a W3C Verifiable Credential signed under a ZKP-friendly scheme (BBS+ over BLS12-381, or CL signatures for AnonCreds-style flows). The holder then derives a **zero-knowledge proof** that attests to specific predicates over the credential, without revealing the underlying attributes, the credential identifier, or the issuer signature itself. The same proof artifact is **verifiable both on-chain and off-chain** under identical cryptographic guarantees. This makes it the most flexible primitive in the Zyphe stack: a single VC can serve a Solidity verifier contract on an EVM L1, an aggregator inside an ERC-4337 paymaster, and an off-chain compliance API, with no re-issuance and no PII leakage. #### Flow The lifecycle splits into two phases: **issuance** of the VC after KYC (one-time, off-chain), and **presentation** of a derived zk-proof against a verifier (per-request, on- or off-chain). ```mermaid sequenceDiagram participant Dapp box Zyphe participant FE as Holder(Frontend / Wallet) participant BE as Backend(Issuer) participant KYC as KYC Module end participant BC as Verifier Contract Note over Dapp,BC: Phase 1: Credential issuance (one-time) Dapp->>FE: redirect with required predicates + contextId Note over FE: connect wallet,generate link_secret FE->>BE: SIWE login + commit(link_secret) BE->>FE: challenge Note over FE: sign challenge FE->>BE: signed message BE->>FE: start session BE->>KYC: initiate kyc session KYC->>BE: session challenge BE->>FE: kyc session FE->>KYC: perform kyc actions KYC->>BE: kyc result webhook Note over BE: issue VC (BBS+ over attributes,bound to link_secret) BE->>FE: deliver VC + revocation handle Note over Dapp,BC: Phase 2: Proof presentation (per request) Dapp->>FE: request proof(predicates, contextId) Note over FE: derive zk-proof locally:verify BBS+, prove predicates,bind wallet, compute nullifier alt On-chain verification FE->>BC: submit proof + public inputs Note over BC: verify proof, check IssuerRegistry,expiry, nullifier, revocation BC-->>Dapp: emit event / state update else Off-chain verification FE->>Dapp: proof + public inputs Note over Dapp: verify proof, check issuer pubkey,track nullifier end ``` #### Cryptographic primitives - **Issuer signature**: BBS+ over BLS12-381. Multi-message signatures allow the holder to selectively disclose or blind individual credential attributes. - **Proof system**: Groth16, PLONK, or STARK circuits encode (a) the BBS verification relation, (b) the requested predicates (range proofs, set membership / non-membership, hash equality), and (c) holder binding. - **Holder binding**: a `link_secret` bound at issuance is committed inside every proof and signed against the wallet challenge, preventing credential pooling, rental, or transfer. - **Nullifiers**: a deterministic `nullifier = H(link_secret, contextId)` is published with each proof. Verifiers track nullifiers per-context to prevent replay while preserving cross-context unlinkability. - **Revocation**: handled out-of-band via `BitstringStatusList` (W3C) or a Merkle / RSA accumulator, with the current root mirrored on-chain for trustless checks. #### What can be proved The same VC satisfies many predicates without re-issuance: - `kyc_level >= L2`: KYC tier threshold - `age >= 18` (or any threshold): range proof over date-of-birth - `country ∈ allowlist` / `country ∉ sanctioned_set`: set membership / non-membership - `risk_score < threshold`: numeric bound when AML scoring is bound into the credential - `wallet == msg.sender`: binding the proof to the calling EOA / smart account - `issuer == zyphe_did ∧ not_expired(now)`: issuance authority and validity window #### On-chain verification A verifier contract is generated from the circuit and consumes a calldata-friendly proof. A typical EVM entrypoint: ```solidity function verifyKyc( uint256[8] calldata proof, uint256[] calldata publicInputs, // [issuerKeyId, predicateHash, nullifier, contextId, expiry] bytes32 nullifier ) external returns (bool); ``` The contract enforces: 1. `Verifier.verify(proof, publicInputs) == true` 2. `publicInputs.issuerKeyId` is registered in the on-chain `IssuerRegistry` 3. `publicInputs.expiry > block.timestamp` 4. `usedNullifiers[contextId][nullifier] == false`, then marks it used 5. (Optional) credential is unrevoked against the mirrored revocation root Gas cost is dominated by the pairing check: roughly 230k gas for a Groth16 verifier on BN254 via the `ecPairing` precompile (EIP-197), and single-digit-millisecond verification off-chain. #### Off-chain verification The same proof verifies under `snarkjs`, `arkworks`, `rapidsnark`, or `risc0`, enabling hybrid flows: - **Rollups / L2**: cheap on-chain verification, or batched verification at the sequencer. - **Account abstraction (ERC-4337)**: validate the proof inside `validateUserOp` (paymaster or signature aggregator) to gate UserOps without leaking PII. - **Off-chain APIs**: a backend issues a session token after verifying the proof, with no need to ever hold the underlying VC. #### Privacy and threat model - **Zero-knowledge**: only the predicate result and the declared public inputs are revealed; no attribute, signature, or credential identifier leaks. - **Unlinkability**: across distinct `contextId` values, two presentations of the same VC cannot be correlated by the verifier(s). - **Per-context Sybil resistance**: nullifiers prevent reuse within a context while preserving anonymity across contexts. - **Issuer compromise**: a leaked issuer key enables forgery of new credentials going forward, but does not retroactively deanonymize existing presentations. Keys are rotated via the `IssuerRegistry`. - **Trusted setup**: Groth16 requires a per-circuit ceremony; PLONK requires a universal setup; STARKs are transparent. Zyphe favors universal or transparent setups to avoid per-circuit ceremonies. ### AML compliance proof AML (Anti-Money Laundering) frameworks function fundamentally as a blacklist: they identify and restrict users or entities associated with high-risk activities. This contrasts with KYC, which confirms an individual's identity but does not assess their transactional history or risk indicators. A user who has successfully completed KYC verification may still be flagged on AML lists if linked to suspicious activities. KYC proves that an individual is known and verified; AML provides a separate compliance layer focused on monitoring and preventing illicit activity, even for KYC-verified users. - **AML Screening (off-chain)**\ The compliance process begins off-chain, where a user's wallet address (and, where applicable, identity attributes) is checked against up-to-date AML lists maintained by trusted providers. These lists flag addresses associated with money laundering, fraud, or sanctions. If the address is clear, a cryptographic attestation is created to certify that the wallet has passed AML checks. - **Issuing an AML compliance proof**\ Once the wallet passes screening, Zyphe issues a **cryptographic attestation** stating that the address is not blacklisted. This attestation can take the form of a signed message, a JWT, a W3C VC, or a token with an AML status attribute, any of which can be consumed by on-chain or off-chain verifiers. - **On-chain verification**\ The attestation can be persisted on-chain as a smart-contract event or registry entry. Other contracts check its validity without needing access to the full AML database. It acts as a public "AML passport" while the underlying screening data stays private. - **Off-chain verification**\ The same attestation is verifiable off-chain by APIs, custodians, exchanges, or compliance backends using standard signature-verification libraries against Zyphe's published issuer keys. - **Access control**\ When a user interacts with a dApp or service, the verifier checks the attestation's signature against the trusted AML issuer registry. Based on this proof, the verifier can permit or deny access, apply transaction limits, or trigger additional compliance measures. _More coming soon…_ --- ## AML Agentic Review Engine The AML agent that moderates sanctions, PEP, and adverse-media screenings runs on a **multi-role agentic review engine**. Rather than a single AI loop that both reasons and acts, the engine separates the work into distinct phases: three analytic roles assess the case, a deterministic (non-AI) guard decides whether the result may be cleared, and a tool-constrained actuator carries out exactly one outcome. Every decision is recorded against a versioned policy and written to the audit trail. This page describes how the engine works and how the [AML Agent Mode](./index.md#aml-agent-mode) you pick on the flow step controls it. :::info You do not configure the review engine directly. It is driven by the **AML Agent Mode** on the step that produced the screening (`Disabled`, `Suggest`, or `Auto-pilot`). This page describes what happens behind that setting. ::: ## When a review runs A scheduled dispatcher looks for AML results that are ready for agent review. Candidates are non-deleted screenings that produced at least one hit (PEP, sanctions, or adverse media), have passed a short grace period after the check, are not yet moderated by a human, and do not already carry an agent-review marker for the **current** screening revision. The agentic mode is resolved from the flow step that produced the screening (document verification for person checks; KYB for company and UBO checks). Missing or unparseable configuration is treated as **Disabled**, fail closed, with no deployment-wide default. The mode is captured when the job is enqueued so a mid-flight config change cannot alter what dispatch decided. Only results whose mode is `Suggest` or `Auto-pilot` are enqueued. At most one review runs per result at a time. After a completed evaluation, an `agentReview` marker is stored on the result so the dispatcher will not re-review an unchanged screening. A re-screen that bumps `checkedAt` past the marker makes the result eligible again. ## How a review runs When a candidate is claimed, the engine builds a **case file** from the full AML risk result and runs it through the pipeline below. Each phase has a single responsibility, and the analytic phase cannot mutate any record. ```mermaid flowchart TD A["AML screeningCase file: hits, identity query,adverse media, moderation history"] --> B["Prosecutorrisk findings: LLM, structured output"] B --> C["Defendermitigations: LLM, skipped when zero findings"] C --> D["Judgeverdict + rationale + residual risk: LLM"] D --> E["Deterministic guardhard veto on Approve only(Rust, no LLM)"] E --> F["ActuatorONE permitted action: allowlist narrowed toJudge's decision ∩ Agent Mode gate"] F --> G["AML_AGENT_REVIEWED auditfindings count · verdict · guard outcome ·enacted decision · policy version · actuator status"] ``` ### The case file The case file is the full parsed screening result, including: - Entity hits with match scores, sanctions and topics, date of birth, countries, and sources - The submitted identity query that was screened - Adverse-media articles, when present - Prior moderation history - Subject type (person or company) ### The three analytic roles The analytic phase runs three roles in sequence: one raises concerns, one answers them, and a third weighs the two. None of them can change the stored record. | Role | Responsibility | Notes | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | **Prosecutor** | Argues each hit is genuine and emits structured **risk findings**. | LLM with structured (schema-constrained) output. | | **Defender** | Runs false-positive analysis per finding (name-only match, DOB / nationality / jurisdiction mismatch, stale source, homonym) and emits **mitigations**. | LLM. **Skipped** when the Prosecutor returns zero findings. | | **Judge** | Weighs findings against mitigations and issues a **verdict with a rationale** and a residual risk score. | LLM. Its decision is one of `Approve` (clear), `Escalate`, or `RequestClarification`. | Each role uses a provider-agnostic, strict-mode structured-output schema and is driven by a versioned prompt policy for the AML domain. ### The deterministic guard The Judge's verdict does not decide a clear on its own. On an **Approve** verdict, a deterministic guard, written in Rust and running no LLM, has the final say on whether the screening may be cleared. The guard is a hard floor that vetoes auto-clear when any of the following is true: - **A human verdict is already in force** (`Escalated` or `Rejected`). The agent may never overturn a human decision. - **The screening produced hits but lacks minimum identity discriminators.** For a person: first name, last name, and date of birth. For a company: name plus country or registration number. A name alone is not enough to clear a hit. - **Any hit is a high-confidence sanctions match** (exact match, or match score at or above the high-confidence threshold). - **Overall risk level is Critical.** A guard Deny downgrades the **enacted** decision to **Escalate** while preserving the Judge's original verdict for the audit trail. An LLM verdict cannot override the guard. ### Request clarification becomes escalation AML subjects have no applicant clarification channel the way a KYB case does (for example, a UBO pulled from a register has no contact path in this pipeline). A `RequestClarification` verdict is therefore **normalized into an escalation** that carries the missing-data request for a human reviewer. The agent does not open a clarification loop with the end user. ### The actuator The actuator runs only after the guard, and it can take **only one action**. The enacted decision maps to a constrained tool allowlist over read and mutate operations (`get_aml_result`, `clear_aml_result`, `escalate_aml_result`). That allowlist is the **intersection of the Judge's decision and the Agent Mode gate**: - For an escalate path, clear is not in the allowlist and cannot be called. - Under **Suggest**, a clear is recorded as a suggestion and the clearing actuator does not run; an **escalation still enacts** so high-risk cases reach the human queue without waiting. - Under **Auto-pilot**, a clear may also enact when the guard allows it. - The mutating tools are idempotent (already cleared or already escalated is a no-op), so a retry re-runs the same evaluation instead of producing a second, independent action. - `clear_aml_result` re-runs the same deterministic guard server-side as a backstop, so even a misbehaving actuator cannot clear what the guard denies. When an action tool is allowed, a second, minimal LLM agent is started with the tool allowlist restricted to exactly the plan's tools and is prompted to enact the panel's already-made decision. It fills tool arguments; it does not re-decide the case. ## How Agent Mode controls the engine The [AML Agent Mode](./index.md#aml-agent-mode) on the flow step determines how far the actuator is allowed to go: | Mode | Engine behavior | | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Disabled** | The pipeline does not run for that step. Operators moderate every hit manually. | | **Suggest** | The full pipeline runs. Escalations are enacted so cases reach the human queue. Clears are recorded as **suggestions** only; a human confirms or rejects. | | **Auto-pilot** | The actuator may enact the decision automatically. An `Approve` (clear) is enacted only when the deterministic guard also passes; anything the guard vetoes is escalated to the human review queue. | ## Guarantees The engine enforces the following, independent of the LLM's output: - **The guard is final on clear.** Auto-clear is blocked when a human verdict is in force, identity discriminators are insufficient, any hit is high-confidence sanctions, or overall risk is Critical. An LLM verdict cannot override the guard. - **The allowlist is `decision ∩ mode`.** The actuator cannot clear on an escalate path, and under **Suggest** a clear does not run the clearing actuator at all. - **The guard runs again server-side.** `clear_aml_result` re-runs the strict guard when it is called; the engine-side guard passing is not sufficient on its own. - **Human decisions are sticky.** The agent never overturns an in-force human `Escalated` or `Rejected` verdict. - **Retries are safe.** All mutating actions are idempotent. A retryable actuator failure re-runs the evaluation; terminal failures are recorded and not retried. - **The engine can be switched off.** A hot-reloadable kill switch stops dispatch of new candidates so results fall back to the human review queue without a redeploy. - **Missing mode fails closed.** An absent or unparseable mode on the flow step is treated as **Disabled**. - **Re-screens reset agent review.** An `agentReview` marker is scoped to the current screening revision; a new check that advances `checkedAt` makes the result eligible for review again. ## Audit trail Every completed run writes an **`AML_AGENT_REVIEWED`** entry attributed to the agent bot identity. The entry records both the model's verdict and the action the system took: | Field | Meaning | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------- | | **Findings count** | How many risk findings the Prosecutor raised. | | **Judge verdict** | `Approve`, `Escalate`, or `RequestClarification` (the latter is enacted as escalate). | | **Guard outcome** | Whether the deterministic guard was not consulted, allowed, or vetoed, and why. | | **Enacted decision** | The action the actuator took (or a recorded suggestion under Suggest for clear). | | **Policy version** | The versioned AML policy the decision was made under. | | **Actuator status** | Success, or a retryable failure that will re-run the evaluation. | | **Decision narrative** | Structured decision context for the audit trail (operational logs omit free-text model rationale to avoid PII leakage). | ## Related - [AML overview](./index.md) and [AML Agent Mode](./index.md#aml-agent-mode) - [Risk scoring](./risk-scoring.md), how hits become a score and level - [Monitoring](./monitoring.md), when screening runs again - [KYB Agentic Review Engine](/docs/guides/kyb/agentic-review-engine), the parallel multi-role engine for business-information moderation - [Manual review](/docs/guides/manual-review) - [Statuses and codes](/docs/reference/statuses-and-codes#kyb-and-aml-statuses) --- ## Overview Anti-Money Laundering (AML) screening verifies people and organizations against sanctions, PEP, watchlists, and adverse media to prevent the use of financial services for illicit purposes. Zyphe integrates AML screening with its decentralized **Know Your Customer (KYC)** solution to deliver end‑to‑end compliance from onboarding through ongoing monitoring. We screen identities across multiple lists and compute a risk score to help you make fast, defensible decisions. Zyphe’s approach enables **privacy‑preserving compliance**. Instead of centrally storing sensitive personal data, Zyphe keeps user data decentralized and under the user’s control. Only the minimum necessary attributes or cryptographic credentials are shared with the screening engine and third‑party data sources (e.g., sanctions, PEP, adverse media providers). This achieves **data minimization** while maintaining high screening quality. Screening events and outcomes can be logged with strong cryptography and, where applicable, blockchain technology to provide an immutable audit trail for regulators and partners. ## Coverage Screening runs against sanctions regimes, politically exposed person data, law-enforcement and regulatory watchlists, and adverse media, drawn from more than 100,000 lists and sources worldwide. A match returns a banded risk score from 0 to 100 together with the number of contributing sources behind it, so an operator can tell a single weak reference from a corroborated one before deciding. Screening output is evidence for the reports a regulated firm has to file. Where a case results in a suspicious activity or suspicious transaction report, the screening record, the score and the sources that produced it form the case file the report is written from. The report itself is filed by the obliged entity, through its own regulator's channel; Zyphe does not file on a customer's behalf. ## AML Agent Mode When a screening produces PEP, sanctions, or adverse-media hits, results can be moderated manually or with help from the **AML AI agent**. Behind that agent, moderation is driven by a multi-role **[agentic review engine](./agentic-review-engine.md)**: analytic roles argue the case, a deterministic guard arbitrates auto-clear, and a tool-constrained actuator enacts one audited outcome. **AML Agent Mode** on the flow step that produced the screening controls how far that automation goes: - **Disabled:** the agent is not invoked. Operators review every hit manually. - **Suggest:** the agent runs and surfaces its verdict and rationale. **Escalations are enacted** so cases reach the human review queue; **clears are suggestions only**, a human confirms or rejects before the result is cleared. - **Auto-pilot:** the agent may **clear or escalate automatically**. A clear is enacted only when the deterministic guard also passes; anything the guard vetoes is escalated for human review. The mode is configured per step: on document verification for person screenings, and on the KYB step for company and UBO screenings. Missing or unparseable configuration is treated as **Disabled** (fail closed). :::tip Auto-pilot reduces manual review effort by clearing low-risk false positives that pass the guard, while keeping high-confidence sanctions hits, Critical risk, thin identity data, and human verdicts under operator control. ::: :::info For how the engine reaches and enacts each decision (the analytic roles, the deterministic guard, the audited action, and the safety guarantees), see [AML Agentic Review Engine](./agentic-review-engine.md). ::: AML screening is one control in the wider [antifraud map](/docs/how-it-works/antifraud-controls): document authenticity, liveness, KYB register checks, UBO unwrapping, device signals, and Transaction Monitoring sit alongside it. The same Disabled / Suggest / Auto-pilot modes are used on KYB and are intended for TM alert triage. --- ## When screening runs - Onboarding (KYC/KYB) - Periodic re‑screening and list refreshes - Event‑driven triggers (profile updates, behavior changes) Purpose Screens identities for sanctions, PEP, watchlists, and adverse media Timing During onboarding and on a recurring basis; event‑driven re‑screening Scope Individuals and organizations Process Multi‑list queries, fuzzy matching, disambiguation; consolidated risk scoring with configurable rules Key Benefits Reduces regulatory risk; blocks high‑risk users; improves review efficiency --- ## Risk Scoring For each subject screened against sanctions, PEP, and adverse media lists, Zyphe consolidates the matched signals into a single, normalized **risk score** and a categorical **risk level**. The scoring engine is fully configurable per organization, so each tenant can align the assessment to its own risk appetite, regulatory perimeter, and internal policies. :::tip[Beyond AML] The AML risk score is one input to Zyphe's generalized scoring engine: organizations can define additional custom scores fed by form answers, workflow actions, and manual review. See the [Scoring](/docs/guides/scoring) section. ::: ## Output Every AML check produces, for each matched entity, a structured result that includes: Risk Score Normalized integer percentage from 0 to 100 Risk Level Categorical band derived from the score: Low, Medium, High, or Critical Sources Count Number of independent data sources that contributed to the match ### Risk levels The AML risk score uses the platform-wide score levels defined in [Scoring](/docs/guides/scoring#score-levels), the same `Low / Medium / High / Critical` bands and thresholds apply here. The level is what most reviewers act on; the percentage is what flow builder conditions and audit trails reference. The **typical handling** column below is AML-specific guidance. | Score range | Risk level | Typical handling | | ----------- | ---------- | --------------------------------------------- | | `0–25` | Low | Auto‑approve, log for audit | | `26–50` | Medium | Auto‑approve with monitoring, or light review | | `51–75` | High | Manual review by a compliance analyst | | `76–100` | Critical | Block or escalate; requires senior review | In the dashboard, risk levels are rendered as color‑coded badges so reviewers can triage cases at a glance. ## How the score is computed The score combines two families of signals. Keep the split in mind: - A **tag** is the finding itself (`role.pep`, `sanction`, `crime.fraud`). It has a **weight**. - A **contextual factor** is optional context around that finding (country, position, relationship). It has a **multiplier**. You can run AML scoring with tags only. Factors are not required. The same combinator is documented in [How Scores Are Computed](/docs/guides/scoring/how-scores-are-computed#tag-weight-vs-contextual-factor). ```mermaid flowchart LR A["Matched entity(topics, country, position, relationships)"] --> B["Tag weightsseverity per topic"] A --> C["Contextual factorsjurisdiction · position · relationship"] B --> D["Base score"] C --> E["Adjustment"] D --> F["Adjusted score"] E --> F F --> G["Normalize to 0–100"] G --> H["Risk levelLow · Medium · High · Critical"] ``` In short: 1. Each topic the entity matches (e.g., `sanction`, `role.pep`, `crime.fraud`) contributes a weighted severity to a base score. These topics arrive **automatically from screening**; you do not assign default AML tags by hand. 2. The base score is optionally adjusted by contextual signals attached to the match. A high‑risk jurisdiction or a senior government position increases the score multiplicatively; with no factors configured, the tag weights stand alone. 3. The result is normalized against the worst‑case configuration to produce a stable percentage in `[0, 100]`. The full mathematical specification is part of Zyphe's internal algorithm documentation and is available on request for compliance review. ## Configurable tag weights A **tag weight** assigns a severity (a positive number) to a specific risk topic. The higher the weight, the more strongly a match on that topic pushes the score upward. Zyphe ships with a curated set of global default weights covering the standard AML taxonomy. The defaults are designed to produce sensible scores out of the box for most organizations. The dashboard **Risk Tags** page is the live list; the table below is the seeded catalog. Each organization can: - **Override** any default weight to make a topic count more or less heavily. - **Add custom tags** that are unique to the organization (for internal classifications that aren't part of the global AML taxonomy). - **Activate or deactivate** any tag without deleting it, which is useful when temporarily excluding a signal from scoring. Tag weights are managed from the **Risk Tags** page in the dashboard, under your organization's settings. The page lists every effective tag for the organization and indicates, for each row, whether it is a global default, a local override, or a custom entry. ### Default AML tags Default tags are **emitted by the screening provider** when a match carries that topic. Origin is the AML result, not the flow builder. Grouped by theme (key, dashboard label, default weight). Override any weight per organization; deactivate a tag to exclude it without deleting it. **Sanctions, watchlists, and regulatory** | Key | Label | Default weight | | ------------------ | ------------------------- | -------------- | | `sanction` | Sanctioned entity | 10 | | `wanted` | Wanted | 10 | | `sanction.linked` | Sanction-linked entity | 8 | | `sanction.counter` | Counter-sanctioned entity | 8 | | `debarment` | Debarred entity | 6 | | `export.control` | Export controlled | 7 | | `export.risk` | Trade risk | 6 | | `reg.action` | Regulator action | 6 | | `reg.warn` | Regulator warning | 3 | | `poi` | Person of interest | 4 | | `asset.frozen` | Frozen assets | 7 | **Crime** | Key | Label | Default weight | | ---------------------- | ------------------------ | -------------- | | `crime.terror` | Terrorism | 10 | | `crime.war` | War crimes | 10 | | `crime.boss` | Criminal leadership | 9 | | `crime.traffick.drug` | Drug trafficking | 9 | | `crime.traffick.human` | Human trafficking | 9 | | `crime.traffick` | Trafficking | 8 | | `forced.labor` | Forced labor | 8 | | `crime.fraud` | Fraud | 7 | | `crime.fin` | Financial crime | 7 | | `crime.cyber` | Cybercrime | 5 | | `crime.theft` | Theft | 5 | | `crime.env` | Environmental violations | 4 | **PEP, government, and roles** | Key | Label | Default weight | | ----------------- | ------------------------------------- | -------------- | | `role.pep` | Politician (PEP) | 5 | | `role.rca` | Close associate | 3 | | `role.oligarch` | Oligarch | 6 | | `role.spy` | Spy | 8 | | `gov.head` | Head of government or state | 7 | | `gov.security` | Security services | 7 | | `gov.executive` | Executive branch | 6 | | `gov.national` | National government | 6 | | `gov.financial` | Central banking / financial integrity | 6 | | `gov.state` | State government | 5 | | `gov.soe` | State-owned enterprise | 5 | | `gov.legislative` | Legislative branch | 5 | | `mil` | Military | 5 | | `gov` | Government | 4 | | `gov.muni` | Municipal government | 4 | | `gov.igo` | Intergovernmental organization | 4 | | `gov.admin` | Civil service | 4 | | `gov.judicial` | Judicial branch | 4 | | `role.judge` | Judge | 4 | | `role.pol` | Non-PEP politician | 3 | | `role.civil` | Civil servant | 3 | | `role.diplo` | Diplomat | 3 | | `role.lawyer` | Lawyer | 3 | | `role.acct` | Accountant | 3 | | `role.act` | Activist | 3 | | `role.lobby` | Lobbyist | 3 | | `role.journo` | Journalist | 2 | | `pol.party` | Political party | 4 | | `pol.union` | Union | 3 | | `rel` | Religion | 2 | **Corporate and financial** | Key | Label | Default weight | | --------------- | --------------------- | -------------- | | `corp.disqual` | Disqualified | 8 | | `corp.offshore` | Offshore | 6 | | `corp.shell` | Shell company | 6 | | `corp.public` | Public listed company | 3 | | `fin.bank` | Bank | 4 | | `fin.fund` | Fund | 4 | | `fin` | Financial services | 3 | | `fin.advisor` | Financial advisor | 3 | Custom tags (your own names) are added on the same page with **Add Custom Tag**, then assigned from a form, from Flow Builder, or from review. See [Tags](/docs/guides/scoring/tags).
Review global AML tags, custom tags, weights, and active status from the Risk Tags page.
Create an organization-specific override to adjust the weight of a global AML tag.
## Configurable contextual factors A **contextual factor** is an optional multiplier applied on top of the base score when a specific contextual signal is present in the match. **Tag = weight; factor = multiplier.** Factors are not required: if none match (or all are deactivated), the score is just the tag weights. There are three types: Jurisdiction Country‑level multipliers based on ISO‑3166 codes, applied when the entity's country, nationality, or country of birth matches a configured factor Position Multipliers tied to roles or occupancies, such as senior government officials, security agency leadership, or judicial figures Relationship Multipliers tied to relationship topics, such as a person being linked to a sanctioned entity or sitting on the board of a shell corporation As with tag weights, Zyphe provides global defaults covering the most common jurisdictions, positions, and relationship classes. Organizations can override any default factor or disable factors that don't apply to their use case. Contextual factors are managed from the **Risk Contextual Factors** page. ### Examples **Same PEP tag, different country.** Screening emits `role.pep` (weight 5) in both cases. A jurisdiction factor then multiplies the result: - PEP whose country is Italy (`IT`): default jurisdiction multiplier is low (`0.05` → +5%). The PEP tag still counts; Italy does not inflate it much. - PEP whose country is a high-risk jurisdiction (for example `KP`, default `0.4` → +40%): the same tag is amplified. The finding did not change; the context did. **Position.** A match tagged as head of government (`gov.head`) carries both a tag weight and, when configured, a position multiplier (default `0.6`). A journalist (`role.journo`) has a small tag weight and a near-zero position multiplier. **Italian provinces.** AML jurisdiction factors are **country-level** (ISO 3166) today. Banca d’Italia territorial risk (sede operativa, titolare effettivo) is the same multiplier idea at province level. Until a first-class province set is configured for your organization, model it as a **form** contextual factor: a select of provinces, each option a factor key with its own multiplier. See [Form scoring](/docs/guides/create-a-flow/form#scoring).
Review contextual factor multipliers and their global defaults from the dashboard.
Create an organization-specific override to tune contextual factor multipliers.
:::info[Defaults vs. overrides] Both tag weights and contextual factors follow the same precedence model: organization‑level configuration takes priority over global defaults. When you create an override, the global default is preserved and shown alongside the override so you always have a reference point. ::: ## Assigning custom risk tags from a flow Beyond the screening provider's output, your verification flows can attach **custom risk tags** to a specific result, for example to mark a subject who failed a manual document check as carrying additional internal risk. Custom tags assigned this way are folded into the next risk score computation for that flow result, using the weights configured for the organization. Create the tag first (Risk Tags or Score Definitions → Manage tags), then associate it. The usual paths are a scored form field, the **Assign Risk Tags** action node in Flow Builder (behind a condition), or a manual assignment on the result. Step-by-step: [Tags](/docs/guides/scoring/tags). ## Using risk scores in flow builder conditions The flow builder exposes the AML risk score as a condition input. You can branch a flow based on the percentage value with operators such as greater‑than, less‑than, or equals, which lets you encode policies like "send to manual review if score ≥ 60" or "auto‑reject if score ≥ 85" directly in the flow definition, without writing custom code. ## Where risk scores appear in the dashboard Risk scores are surfaced wherever AML results are reviewed: - **Flow result detail**: the AML section lists every matched entity with its risk level, match score, and topic tags, plus a moderation status (Under Review, Approved, Rejected, Escalated). - **Entity detail view**: clicking through an entity shows the risk score percentage, risk level badge, the originating sources, the field‑level controls, and the audit trail of moderation actions. - **Case management**: risk levels drive sorting and filtering of flow results so reviewers can prioritize the highest‑risk cases first. When hits need moderation, the optional [AML agentic review engine](./agentic-review-engine.md) can propose or enact clear or escalate decisions under [AML Agent Mode](./index.md#aml-agent-mode). The risk level and match signals described here are inputs to that engine's deterministic guard. ## Programmatic access Risk scores, levels, and the underlying matched signals are available through the Zyphe REST API as part of the AML result payload. They are intended for integration with internal compliance systems, BI tooling, and case management workflows. :::info[Webhook scope] AML webhooks include an update summary under `data.aml`: the update kind, moderation status, subject type, PEP and sanctions flags, and optional risk-score percentage. Use the Dashboard or AML result API when you need the full screening result and provider matches. See [Webhook Payload](/docs/guides/webhook/webhook-payload#aml-dataaml). ::: All inputs to the score (matched topics, jurisdictions, positions, relationships, and any custom tags assigned via the flow builder) are persisted alongside the result so the score can be re‑explained and audited at any time. --- ## Choosing an integration method Zyphe supports three main ways to put verification in front of a user. All of them share the same **flows**, **results**, and **webhooks**: you choose based on engineering effort, UX control, and how you want to operate the product. ## At a glance | | **Public link** | **SDK** | **Agent / MCP** | | -------------------------- | ----------------------------------------- | ----------------------------------- | ------------------------- | | **Setup time** | Minutes | Hours | Minutes with an agent | | **Engineering** | None–low | Low–medium | Low (AI-assisted) | | **User stays in your app** | No (hosted UI) | Yes (embed or redirect you control) | Depends on what you build | | **Best for** | Pilots, email/SMS invites, no-code launch | Production web or mobile UX | Automating setup and ops | ``` Do you need a working verification today with almost no code? ├─ YES → Public link └─ NO → Do you need a native experience in your app? ├─ YES → SDK (browser, Node session creation, React Native) └─ NO → Are you configuring the platform with an AI assistant? ├─ YES → MCP / agent tools └─ Prefer API-driven ops → Node SDK + webhooks + dashboard ``` --- ## Public link Each flow has a shareable URL. The user completes verification on Zyphe's hosted UI; your backend is notified via webhook and results appear in the dashboard. **Choose public link when:** - You need to start verifying users immediately - Engineering capacity is limited - You are running a pilot or proof of concept - You distribute invites by email, SMS, or partner portals **How it works (high level):** 1. Create a [flow](/docs/guides/create-a-flow) in the dashboard 2. Share the public link (or generate a session link from the server when you need per-user context) 3. Receive a [signed webhook](/docs/guides/webhook) when the result is ready 4. Review the [flow result](/docs/guides/manual-review) (or automate with scoring) → [Verification process: public web link](/docs/verification-process) · [Sharing a flow](/docs/guides/create-a-flow/sharing) --- ## SDK Use the SDK when you want control over session creation, branding in-context, or a native mobile experience. | SDK | Role | | ---------------- | --------------------------------------------------------------------------- | | **Node** | Create verification sessions server-side; generate links or tokens securely | | **Browser** | Embed the verification UI in your web app (iframe) | | **React Native** | Present verification in a mobile WebView | **Choose SDK when:** - Users should stay in your product experience - You need server-side session creation with your own user IDs and metadata - You are building production web or mobile onboarding Typical production pattern: 1. Backend creates a session with the [Node SDK](/docs/guides/sdk/node) and an [API key](/docs/guides/api-keys) 2. Frontend opens the session with the [browser](/docs/guides/sdk/browser) or [React Native](/docs/guides/sdk/react-native) SDK 3. Backend consumes [webhooks](/docs/guides/webhook) and optionally polls or fetches result details via API → [SDK overview](/docs/guides/sdk) · [Verification process: SDK](/docs/verification-process) --- ## Agent / MCP Zyphe ships a [Model Context Protocol (MCP)](/docs/guides/model-context-protocol-mcp) server so compatible assistants (Claude Desktop, Claude Code, Cursor, and others) can create and manage flows, forms, and API keys through natural language, authenticated with a bot token. **Choose MCP when:** - You want to scaffold or iterate on flows quickly - Operators or developers already work with AI coding agents - You are automating repetitive dashboard setup MCP complements public link and SDK; it does not replace user-facing verification. Ship the integration with a link or SDK, and use the agent for configuration and maintenance. → [MCP guide](/docs/guides/model-context-protocol-mcp) · [LLM-friendly docs](pathname:///llms.txt) --- ## What every path still needs Regardless of integration method: 1. A **sandbox** organization to test without production data. See [Quickstart](/docs/quickstart) 2. A **flow** that defines the steps the user completes 3. A way to **receive results**: webhooks are recommended for production 4. Clear **roles** so reviewers and developers only see the PII they need, [Manage users](/docs/guides/manage-users) · [PII access control](/docs/pii-access-control) --- ## Recommended next step - New to Zyphe → **[Quickstart](/docs/quickstart)** (public link or SDK, end to end) - Already know you need embed → **[Browser SDK](/docs/guides/sdk/browser)** or **[React Native](/docs/guides/sdk/react-native)** - Automating setup → **[MCP](/docs/guides/model-context-protocol-mcp)** - Shipping to production → **[Integration](/docs/guides/integration)** (hosts, HTTP API, WebView, export, go-live) --- ## Authority Check ```mermaid sequenceDiagram autonumber participant AUT as Authority participant ZB as Zyphe Backend participant COMP as Company participant DCS as Decentralized Storage AUT->>+COMP: Legal request to access Data COMP->>+AUT: Provide references to data AUT->>+DCS: legal request to access data by reference DCS-->>+DCS: check if authority has a legitimate access DCS-->>+AUT: provide data ``` Zyphe's commitment to balancing user privacy with legal compliance. The steps ensure that when authorities legally request access to data, the process is stringent, verifying the legitimacy of the request and providing data only when necessary and appropriate. This demonstrates Zyphe's robust approach to handling sensitive user data within the decentralized storage model. 1. **Legal Request to Access Data**: An authority initiates the process by issuing a legal request to a company to access specific data. This is the formal beginning of a procedure that is likely regulated by laws and policies to protect user privacy. 2. **Giving the list of Hashes**: The company responds to the authority by providing a list of hashes. Hashes are typically unique alphanumeric strings that correspond to specific pieces of data, used to maintain the privacy and security of the data being referred to. 3. **Legal request to check data of those hashes**: The authority, with the list of hashes, makes a legal request to check the actual data corresponding to those hashes. This step ensures that the authority is targeting specific data points for its inquiry. 4. **Check if the Authority has a legitimate request**: Before any data is provided, the decentralized storage system checks if the authority's request is legitimate. This might involve verifying the legal basis of the request, such as a court order or a subpoena. 5. **Provide Data**: If the request is verified as legitimate, the corresponding data is retrieved from the decentralized storage and provided to the authority. --- ## Creation of the User Vault ```mermaid sequenceDiagram actor User autonumber User->>Zyphe Backend: Authenticate Zyphe Backend->>Zyphe Backend: Create User Vault Zyphe Backend-->>User: User is asked to grant permission to store personal data User->>Zyphe Backend: Grant permission Zyphe Backend->>Decentralized Storage: Shard encrypted data among different nodes with TH + P encryption Zyphe Backend->>Zyphe Backend: Create UUID ``` 1. **Authenticate**: This is the initial step where the user signs up for services with Zyphe, initiating their journey into a decentralized identity ecosystem. 2. **Create User Vault**: Once registered, Zyphe's backend system creates a Personal Online Datastore (Vault) for the user. A Vault is a secure storage space where personal data is kept. 3. **Permission Request**: In alignment with privacy-by-design principles, the user is then prompted to grant Zyphe permission to store personal data. This is a crucial step emphasizing user control and consent in the data management process. 4. **Grant Permission**: After the user grants permission, the process of safeguarding their data can proceed. This permission ensures that Zyphe acts within the legal and ethical boundaries set by data protection regulations. 5. **Data Sharding**: Zyphe then takes the user's WebID, a unique identifier for the user in the decentralized web, and shards it using Threshold + Polynomial Encryption (TH + P Encryption). Sharding is the process of breaking the data into pieces and distributing it across multiple nodes (servers), and this specific encryption method adds layers of security and redundancy. 6. **Store User WebID and Create UUID**: The final step is storing the encrypted and sharded WebID in the decentralized storage. Alongside this, a Universal Unique Identifier (UUID) is created for the user, likely to further ensure the uniqueness of the user's identity within the system. This dataflow represents a user-centric model of identity management where privacy and security are paramount. By decentralizing storage and employing advanced encryption methods, Zyphe ensures that the user's identity and data are protected against centralized points of failure and unauthorized access. ```mermaid sequenceDiagram autonumber Zyphe Backend->>Encryption System: Send data for encryption Encryption System->>Encryption System: Perform TH + P encryption Encryption System->>User Vault: Send encrypted data User Vault->> User Vault: Fragmentation User Vault->> Decentralized Storage: Upload into the distributed decentralized storage ``` 7. **Send Data for Encryption**: Our story begins with data embarking from the Zyphe backend. This is where the raw user data, perhaps provided during registration or subsequent activities, is prepared to be sent for encryption. 8. **Perform TH + P Encryption**: The next chapter sees the data undergoing our robust Threshold Homomorphic + Polynomial encryption. This sophisticated encryption technique ensures that data, while still usable for computations, is securely encrypted and can be split into multiple pieces. 9. **Send Encrypted Data**: Once encrypted, the data is then dispatched to the user's User Vault. This secure transmission ensures that the encryption integrity remains intact. 10. **Fragmentation**: Within the safe confines of the User Vault, the data undergoes fragmentation. This step is akin to dividing a secret into several parts, with each part being meaningless on its own. It’s a measure that significantly enhances data security. 11. **Upload and Distributed into the Decentralized Storage**: In the final leg of its journey, the data fragments are uploaded and distributed across the decentralized storage infrastructure. This not only adds another layer of security but also ensures that data retrieval requires assembling the distributed fragments, making unauthorized access practically impossible. By now, the data has transformed from its original state into a secure, encrypted, and fragmented form, residing within a decentralized framework. This guarantees the highest level of privacy and security, allowing users to engage with digital services with peace of mind, knowing their data is secure within Zyphe's system. --- ## Data Deletion ```mermaid sequenceDiagram autonumber actor User participant ZB as Zyphe Backend participant COMP as Company participant DCS as Decentralized Storage User->>+ZB: Request to delete data ZB-->>+ZB: check data retention requirements for all connected companies ZB-->>+ZB: revoke access to companies if the retention period has passed ZB-->>+ZB: mark data for deletion ZB-->>+User: confirmation loop check if there is data to delete alt There is data to delete ZB->>+DCS: delete data ZB-->>+User: notification else ZB-->>+ZB: check again end end ``` It's important to note that this process indicates Zyphe's adherence to legal compliance by creating temporary storage for data if needed for legal reasons before fully deleting it from the system. 1. **User submits deletion request**: Via their account settings or UI. 2. **Evaluate retention obligations**: The backend checks all third-party recipients and internal policies to determine which copies must be retained and for how long. 3. **Revoke unnecessary access**: The backend immediately disable access for any party that no longer has a legal or contractual need to hold the data. 4. **Flag data for deletion**: The backend marks the user’s data “pending deletion” once every remaining retention obligation has expired. 5. **Acknowledge receipt**: The backend sends the user an immediate confirmation that their request is in progress. **Daily compliance check**: - Every 24 hours, re-evaluate retention obligations. - Revoke any newly ineligible access. - Delete all data whose retention period has lapsed. **Finalize and notify**: - After data is irreversibly deleted, send the user a “deletion complete” notification (e.g. by email). --- ## Data Flows This section explains how Zyphe creates, verifies, shares, accesses, and deletes identity data. Each page documents one flow, including the actors involved and the controls applied to the data. ## Overview Zyphe's data flows are designed around **decentralized identity**, **user sovereignty**, and **privacy by design**. Users control when their data is shared, while organizations receive only the access required for a specific purpose. ## How the flows fit together ```mermaid flowchart LR start([User starts]) --> vault[Create encrypted user vault] vault --> verify[Verify identity] verify --> credential[Issue verified credential] credential --> reuse[Reuse credential with another organization] credential --> passport[Share through KYC Passport] passport --> access[Authorized organization accesses data] authority[Authority submits legal request] --> check[Validate authority and scope] check --> access deletion[User requests deletion] --> retention{Retention required?} retention -->|Yes| restrict[Restrict access until retention expires] retention -->|No| remove[Revoke access and delete eligible data] restrict --> remove ``` The main lifecycle runs from vault creation to verification and controlled reuse. Authority access and deletion are separate, policy-driven paths that apply only when their legal conditions are met. ## Core Data Flows ### [User Vault Creation](./creation-of-the-user-vault.md) The foundational flow that establishes a user's secure digital identity. This process creates a personal online datastore (vault) where user data is encrypted, sharded, and distributed across decentralized storage using advanced cryptographic techniques. **Key Features:** - Threshold + Polynomial (TH + P) encryption - Data sharding across multiple nodes - User consent and permission management - UUID generation for unique identification ### [User Verification Flow](./user-verification-flow.md) The standard KYC (Know Your Customer) verification process that validates user identity and issues verifiable credentials. This flow supports documents from 190+ countries and can include separate document verification and liveness detection steps. **Key Features:** - Multi-country document verification (190+ countries) - Active liveness detection (separate step) - Portrait matching between document and live selfie - Verifiable Credential (VC) issuance - Secure data encryption and storage ### [Reusable Credentials / One-Click KYC](../reusable-credentials-one-click-kyc/index.md) A flow that enables users to reuse previously verified credentials across different companies, eliminating the need for repeated verification processes. **Key Features:** - Credential reuse across companies - Access grant system - Metadata-based eligibility checking - Passwordless authentication support ### [KYC Passport](./kyc-passport.md) A flow that allows organizations to securely share verified KYC data with partner organizations without requiring users to repeat verification. **Key Features:** - Partner organization invitations - User consent management for data sharing - Cryptographic access grants for partners - Flow-specific data sharing - Invite lifecycle management (accept/reject/revoke) ### [Organization Data Access Flow](./organization-data-access.md) The flow that enables an organization to access user data it has been granted, ensuring proper authorization and user consent. For the operational dashboard product, see the [Dashboard](/docs/guides/dashboard) guide. **Key Features:** - Company authentication - User permission verification - Secure data retrieval - Access control management ### [Authority Check](./authority-check.md) A compliance-focused flow that handles legal requests for data access from authorities while maintaining user privacy and ensuring legitimate access. **Key Features:** - Legal request verification - Hash-based data referencing - Authority legitimacy checking - Regulatory compliance ### [Data Deletion](./data-deletion.md) The "right to be forgotten" flow that ensures users can request complete deletion of their data while respecting legal retention requirements. **Key Features:** - User-initiated deletion requests - Retention obligation evaluation - Access revocation - Automated compliance checking ## Data Flow Principles All Zyphe data flows adhere to these core principles: 1. **User Sovereignty**: Users maintain full control over their data and identity 2. **Privacy by Design**: Data protection is built into every flow from the ground up 3. **Decentralized Storage**: Data is distributed across multiple nodes for enhanced security 4. **Cryptographic Security**: Advanced encryption ensures data remains secure 5. **Regulatory Compliance**: All flows comply with relevant data protection regulations 6. **Transparency**: Clear visibility into how data is processed and shared ## Technical Architecture The same security layers support every data flow: ```mermaid flowchart TB actors[Users, organizations, and authorities] policy[Consent, permissions, and legal scope] grants[Recipient-specific access grants] crypto[Encryption and proxy re-encryption] data[Vault data, credentials, and metadata] storage[Distributed storage nodes] actors --> policy policy --> grants grants --> crypto crypto --> data data --> storage ``` The architecture includes: - **Decentralized Storage**: Distributed data storage across multiple nodes - **Threshold + Polynomial Encryption**: Advanced cryptographic techniques - **Proxy Re-Encryption (PRE)**: User-to-organization sharing without ever exposing plaintext to Zyphe (see [Data Sharing and Encryption](../decentralized-identity/data-sharing-and-encryption.md)) - **Verifiable Credentials**: Standards-compliant digital credentials - **Access Grants**: Re-encryption keys that authorize a specific recipient to decrypt a specific document - **Metadata Management**: Efficient data discovery without compromising privacy ## Getting Started Read the flows in this order for a complete introduction: 1. [User Vault Creation](./creation-of-the-user-vault.md) establishes the storage and consent foundation. 2. [User Verification Flow](./user-verification-flow.md) verifies identity and issues a credential. 3. [Reusable Credentials / One-Click KYC](../reusable-credentials-one-click-kyc/index.md) shows how a verified credential can be reused. 4. [KYC Passport](./kyc-passport.md) explains controlled sharing with partner organizations. --- ## KYC Passport(Data-flows) The KYC Passport lets an organization securely share verified KYC data with partner organizations, so users don't repeat verification across an ecosystem, while keeping the sharing under the user's consent and control. This page covers the **conceptual architecture**: how access grants are generated, the rules that govern them, and the sequence flows behind partner data access. For the operational side, inviting partners, accepting invitations, managing consent, screenshots, and FAQs, see the [KYC Passport guide](/docs/guides/kyc-passport). ## Overview A main organization invites partner organizations to access KYC results from specific flows. The user consents once, during verification, to sharing with the named partners. This creates a trusted ecosystem where verified identity data is shared efficiently without re-verification. ## Key benefits - **Seamless partner integration**: share KYC results with multiple partners without repeat verification. - **User-centric consent**: users explicitly consent to the exact list of partners. - **Efficiency**: removes redundant verification across partner organizations. - **Secure access control**: cryptographic access grants ensure only authorized partners can decrypt data. ## Consent rules (architectural invariants) Consent is the precondition for every partner access grant: - **No consent = no access.** If the user does not consent, no partner grants are created, only the main organization receives a grant. - **Invite timing matters.** Partners invited _after_ a user completes verification do not retroactively receive access to that user's data. - **Consent is flow-specific.** It binds to a specific flow and the list of partners invited at verification time. ## Access grant generation ```mermaid sequenceDiagram actor User participant BE as Backend participant MO as Main Org participant IA as Invite A(Accepted) participant IB as Invite B(Pending) participant IC as Invite C(Rejected) User->>+BE: Start verification BE->>+User: Show privacy consentPartners: A, B, C User->>+BE: Accept and continue Note over BE,MO: User completes verification BE-->>+MO: Create grant for Main Org BE-->>+IA: Create grant for Invite A(if already accepted) BE-->>+IB: Create grant for Invite B(will activate when accepted) Note over IC: No grant for Invite C(rejected) BE->>+User: Verification complete ``` ### Access grant rules 1. **Main organization**: always receives a grant when the user completes verification with consent. 2. **Accepted partner invites**: receive a grant immediately. 3. **Pending partner invites**: a grant is created and becomes active when the partner accepts. 4. **Rejected partner invites**: no grant is created. 5. **No consent**: no partner grants are created (only the main organization). ## Partner invitation lifecycle ### Accepting an invite (existing organization) ```mermaid sequenceDiagram autonumber participant ORGA as Partner Org participant BE as Backend participant DB as Database ORGA->>+BE: GET /invites BE->>+ORGA: Return pending invites ORGA->>+BE: POST /accept-invite(inviteId, code) BE-->>+BE: Verify invite code BE-->>+DB: Update invite status to ACCEPTED BE-->>+DB: Link invite to organization BE->>+ORGA: Invite accepted successfully Note over ORGA: Organization can now accessshared flow results ``` ### Accepting an invite (new organization) ```mermaid sequenceDiagram autonumber participant ORGB as New Partner Org participant BE as Backend participant DB as Database ORGB->>+BE: POST /register(with invite details) BE-->>+DB: Create new organization BE-->>+DB: Update invite status to ACCEPTED BE-->>+DB: Link invite to new organization BE->>+ORGB: Registration and invite accepted Note over ORGB: New organization can nowaccess shared flow results ``` ## Partner data access ### Main organization data access ```mermaid sequenceDiagram autonumber participant MO as Main Org participant BE as Backend participant ACL as Access Control participant DB as Database participant DCS as Decentralized Storage MO->>+BE: GET /{orgId}/flow-results BE->>+ACL: Check organization permissions ACL->>+BE: Permissions granted BE->>+DB: Get flow results DB->>+BE: Return flow result metadata BE-->>+BE: Retrieve access grant(orgId, identityId, documentType) BE->>+DCS: Fetch encrypted data DCS->>+BE: Return user data BE->>+MO: Return complete data ``` ### Partner organization data access ```mermaid sequenceDiagram autonumber participant SUB as Partner Org participant BE as Backend participant ACL as Access Control participant DB as Database participant DCS as Decentralized Storage SUB->>+BE: GET /{orgId}/shared-flow-results BE->>+ACL: Check invite-based permissions ACL->>+BE: Invite has valid permissions BE->>+DB: Get flow results for this invite DB->>+BE: Return accessible flow results BE-->>+BE: Retrieve access grant(inviteId, flowId, identityId, documentType) BE->>+DCS: Fetch encrypted data DCS->>+BE: Return user data BE->>+SUB: Return complete data ``` :::info[Access grant differences] - **Main organization**: grants establish a connection between the organization and the verified document. - **Partner organizations**: grants associate the invite with the verified document, linking it to the invitee organization on acceptance. This ensures partners can only access data from the specific flow they were invited to, and only for users who completed verification after the invite was created (with proper consent). ::: ## Security considerations - **Access grants are proxy re-encryption keys** that transform ciphertext from the user's key to the partner's key (see [Data Sharing and Encryption](../decentralized-identity/data-sharing-and-encryption.md)). Zyphe acts as the proxy: it performs the transformation but never sees plaintext or holds either private key. - **Data stays encrypted** in decentralized storage under the user's key. Partners receive re-encrypted ciphertext that only their private key can decrypt; a full breach of Zyphe yields only encrypted data and re-encryption keys. - **Grants are auditable and revocable.** Revoking deletes the re-encryption key, ending future transformations for that pair. Where data-retention obligations apply, access remains until those obligations are met. - **Invites are authenticated** with a unique `inviteId` and a one-time password (OTP) sent by email, over encrypted HTTPS. - **Consent is verified** before any grant is created or activated, and is linked to the grant via flow consents. ## Related - **[KYC Passport guide](/docs/guides/kyc-passport)**: inviting and managing partners, accepting invitations, consent operations, and FAQs. - **[Reusable Credentials / One-Click KYC](/docs/reusable-credentials-one-click-kyc)**: the related pattern for reusing a credential with a single company. --- ## Organization Data Access Flow This is the architectural sequence by which an organization reads user data it has been granted access to. For the operational dashboard product (navigation, reviewing results, and day-to-day use), see the [Dashboard](/docs/guides/dashboard) guide. ```mermaid sequenceDiagram autonumber participant CD as Company Dashboard participant ZB as Zyphe Backend participant DCS as Decentralized Storage CD->>+ZB: Authenticate ZB->>+DCS: request user data DCS-->>+DCS: check if company have access DCS->>+CD: return data ``` 1. **Authenticate**: A company representative logs into the company dashboard. This is the entry point to access user data and likely involves authentication measures to ensure security. 2. **Request user data**: Once logged in, the company's dashboard makes a request to Zyphe's backend system to retrieve specific user data. This request is generated after the user engages with the company and implies that there is some need for the company to access user information stored by Zyphe. 3. **Check if the user has been granted access to the company**: Before data is retrieved, Zyphe's backend system checks whether the user has granted the company permission to access their data. This step is crucial for complying with privacy regulations and ensuring that user data is not accessed without consent. 4. **Return data**: If the user has been granted access, the requested data is retrieved from decentralized storage and returned to the company dashboard. The company can then use this data for the purpose it was requested, such as account management, customer service, or other business functions. --- ## User Verification Flow ```mermaid sequenceDiagram autonumber actor User participant ZF as Zyphe frontend participant ZB as Zyphe backend participant DCS as Decentralized Storage User->>+ZF: submit data for KYC ZF->>+ZB: send data for verification ZB-->>+ZB: perform KYC verification ZB-->>+ZB: create User Vault ZB->>+DCS: Encrypt and upload data ZB-->>+ZB: Issue VC ZB->>+DCS: Ecrypt and upload VC ``` 1. **Perform KYC**: The user begins by submitting their personal data required for KYC. This typically involves two steps: first, taking a picture of their identity document for document verification, and then performing a liveness check to prove they are a real person who matches the document. This is a standard compliance process to verify the identity of the users (documents from 190+ countries are supported). 2. **Perform KYC**: Zyphe takes the submitted data and performs the necessary checks to verify the user’s identity. 3. **Create User Vault**: Once the verification is complete, a user Vault is generated 4. **Encrypt and upload user data**: Zyphe's backend then encrypts the user's data for security. 5. **Issue an interoperable VC**: After the data is securely encrypted, a Verifiable Credential (VC) is issued. VCs are digital certificates that use cryptography to provide a secure and tamper-evident way for a claim to be represented and verified. In our case, the VC is a hash that can be minted in every chain if needed. 6. **Encrypt and upload VC**: The verifiable credential is then encrypted and stored securely in the user vault, along with the personal information that has been used to generate it. --- ## Data Sharing and Encryption Zyphe shares data between users and organizations using **Proxy Re-Encryption (PRE)**. The user always encrypts data with their own key. When they choose to share with an organization, a **re-encryption key** lets a proxy (Zyphe) transform the user's ciphertext into ciphertext that the organization can decrypt, without the proxy ever seeing the plaintext or learning either party's private key. This page explains how the scheme works in Zyphe, the two key-management models we offer, and what an attacker would actually obtain in the worst-case breach scenario. ## How Proxy Re-Encryption Works in Zyphe ```mermaid sequenceDiagram autonumber actor User participant Z as Zyphe (Proxy) participant DCS as Decentralized Storage participant Org as Organization User->>User: Encrypt data withuser public key User->>DCS: Store ciphertext (encrypted under user key) User->>User: Generate re-encryption keyuserKey → orgKey User->>Z: Upload re-encryption key Org->>Z: Request shared data Z->>DCS: Fetch user-encrypted ciphertext Z->>Z: Apply re-encryption key(transform ciphertext) Z->>Org: Deliver org-encrypted ciphertext Org->>Org: Decrypt withorg private key ``` Three properties make this safe: 1. **Plaintext never reaches Zyphe.** The proxy only ever handles ciphertext and a transformation key. 2. **The re-encryption key is one-way and pair-specific.** It only converts ciphertext from `userKey → orgKey`. It cannot decrypt anything on its own and cannot be inverted to recover either private key. 3. **Sharing is consent-driven.** A re-encryption key only exists for an `(identity, document, organization)` pair after the user has explicitly granted access. Revoking access removes the key, ending the proxy's ability to transform new requests. This is the cryptographic mechanism behind every "access grant" referenced in the [Reusable Credentials / One-Click KYC](../reusable-credentials-one-click-kyc/index.md) and [KYC Passport](../data-flows/kyc-passport.md) flows. ## Key Management: Two Models The user's private key is the only key that can encrypt data into the vault and produce re-encryption keys. Zyphe supports two ways to manage it, with different trade-offs between user control and convenience. ### BYOK with Passkey (Advanced Users) Bring-your-own-key mode binds the user's private key material to a **FIDO2/WebAuthn passkey** on the user's device. The key is derived client-side using the WebAuthn PRF extension and never leaves the user's authenticator. - **Custody:** the user's device (Secure Enclave, TPM, hardware key) holds the secret. Zyphe has no copy at any point. - **Re-encryption keys:** generated locally on the user's device when sharing is granted, then uploaded to Zyphe. - **Recovery:** governed entirely by the passkey backup story (platform sync, hardware-key replication, etc.). Losing all passkey copies means losing access; Zyphe cannot recover the vault. - **Best for:** users and organizations that require provable cryptographic isolation from Zyphe. See [Passkey Authentication](../guides/dashboard/passkey-authentication.md) for the registration and authentication flow. ### Managed Key with No-Log Paradigm (Default) For users who prefer a traditional flow, Zyphe generates and operates the key on the user's behalf under a strict no-log paradigm. - **Generation:** the key is generated inside an isolated execution context, used to perform the requested operation (encrypting a vault entry, producing a re-encryption key), and discarded. - **No-log guarantee:** the key is never persisted to disk, never written to logs, never included in telemetry, and never exposed to other internal services. Only ephemeral, in-memory use is permitted. - **User unlock:** the user authenticates with their account credentials (passphrase, Vault Access Key, or other supported method) before any key operation runs. - **Best for:** users who want decentralized, end-to-end encrypted storage without managing cryptographic material themselves. Both models produce the same on-the-wire artefact stored at Zyphe: a re-encryption key. The difference is **where the user's private key lives**. ## What an Attacker Would Get From a Breach The threat model is explicit: assume Zyphe's infrastructure is fully compromised. What can the attacker actually do with what they find? | Asset stored at Zyphe | What it is | What an attacker can do with it | | --------------------------- | -------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | Encrypted vault data | Ciphertext encrypted under the user's public key, sharded across decentralized storage | Nothing. Without the user's private key, the ciphertext is opaque. | | Re-encryption keys | One-way transformation keys for specific `(user → organization)` pairs | Nothing on their own. They transform ciphertext between two public keys but cannot decrypt anything and cannot be inverted to recover either private key. | | User private keys (BYOK) | Not present | N/A (never uploaded). | | User private keys (Managed) | Not persisted | N/A (generated ephemerally and discarded after use under the no-log paradigm). | To actually decrypt a user's data, an attacker would need the **organization's private key** (held by the organization) **and** the corresponding ciphertext **and** the re-encryption key. Even then they would only obtain data the user had already explicitly consented to share with that organization. A breach of Zyphe alone yields encrypted data and re-encryption keys. Neither, separately or together, is sufficient to decrypt anything. ## Why This Matters - **No central honeypot.** Zyphe physically cannot decrypt user data: there is no master key, no "break-glass" decryption path, and no plaintext cache. - **Granular, revocable sharing.** Each shared document corresponds to a distinct re-encryption key. Revocation simply deletes that key; no further requests can be transformed. - **Compliance posture.** Because the proxy never sees plaintext, the system aligns with data-minimization principles in GDPR and similar frameworks by construction, not by policy. - **Operational simplicity for organizations.** Recipients use standard public-key decryption against ciphertext they receive: no need to integrate with a key escrow or run a decryption service against Zyphe's storage. --- ## Definitions ## User Vault (User Vault) A User Vault is where personal information is securely stored. It contains the user’s verified and encrypted data, such as documents collected during the document verification or generated verifiable credentials. The User Vault is distributed as the data it contains is fragmented and uploaded across several storage nodes within the network. ## Threshold Encryption (TH Encryption) Threshold encryption is a cryptographic technique that allows a group of participants to jointly decrypt a message, without revealing the message to any individual participant. The decryption requires cooperation and agreement from a specified minimum number of participants, known as the threshold. ## Proxy ReEncryption or Transform encryption (PRE) Proxy re-encryption (PRE) is a cryptographic technique that allows a third party (the proxy) to transform ciphertext encrypted under one public key into ciphertext encrypted under another public key, without learning the underlying plaintext. This enables secure data sharing where the original data owner doesn't need to be online or share their private key with recipients. In Zyphe, PRE is the mechanism behind every access grant: the user encrypts vault data under their own key, generates a re-encryption key for the recipient organization, and uploads only that re-encryption key to Zyphe. See [Data Sharing and Encryption](./data-sharing-and-encryption.md) for the full flow and key-management options. ## Re-encryption Key A re-encryption key is a one-way, pair-specific cryptographic key that lets the proxy transform ciphertext encrypted under the user's public key into ciphertext encrypted under a recipient's public key. It cannot decrypt data on its own and cannot be inverted to recover either party's private key. Revoking access in Zyphe deletes the re-encryption key, preventing any future transformation for that pair. ## Web Identifier (WebID) WebID (Web Identifier) is a standard way of representing a person or organization on the web, using a unique URI (Uniform Resource Identifier) that serves as a persistent identifier for the entity. The WebID specification defines a decentralized and distributed identity system that allows users to create, manage, and share their own identity online, while also being able to control the use of their personal data. ## Decentralized Identifiers (DID) DIDs (Decentralized Identifiers) are a new type of globally unique identifier that enables verifiable digital identity without reliance on a centralized authority. They are self-owned, persistent, and cryptographically verifiable, linking subjects (people, organizations, things) to their decentralized key management systems and other identity-related data. ## Universally Unique Identifier (UUID) A UUID is a 128-bit identifier that is designed to be globally unique, meaning that no two UUIDs are expected to be the same. It is used in computer systems and software applications as a way to uniquely identify entities such as files, devices, users, and transactions. ## Decentralised Storage Secret Management (DSSM) Secret management systems typically provide a centralized way to securely store, manage, and distribute secrets. They may include features such as encryption, access control, auditing, and automatic rotation of secrets to enhance security. These systems are often integrated with other security tools and processes to provide a comprehensive security solution. ## Know Your Customer (KYC) KYC stands for "Know Your Customer," which refers to the process of verifying the identity of a customer or client as a part of due diligence and anti-money laundering procedures. KYC is a regulatory requirement in many industries, particularly in banking, finance, and e-commerce, where there is a risk of fraud, money laundering, or terrorist financing. ## Verifiable credentials (VC) A veriviable credential is a digital record that contains information about a person's identity, qualifications, certifications, or other relevant attributes. It is designed to be a secure, tamper-evident way to share personal information with others, it is based on decentralized identity principles and is designed to be shared directly between individuals, organizations, and other entities. ## Selective disclosure (SD) Selective disclosure allows you to reveal only specific parts of a verifiable credential while maintaining its verifiability without relying on a trusted third party. ## Verifiable presentation (VP) In SSI, a Verifiable Presentation is a collection of one or more Verifiable Credentials presented by a holder to a verifier, proving certain claims. ## Zero Knowlege Proofs (ZKP) Zero-Knowledge Proofs (ZKPs) are a cryptographic method where one party (the prover) can convince another party (the verifier) that a statement is true, without revealing any information beyond the truth of the statement itself. --- ## What is Decentralization for Zyphe Zyphe applies decentralization as a core business principle, it’s not just a technical feature. By removing single points of failure and control, we ensure that compliance-driven verification processes remain secure, scalable, and future-proof. Our architecture distributes both infrastructure and data ownership across independent nodes and end-users, creating a network that operates autonomously while meeting the highest standards of privacy, reliability, and regulatory resilience. This approach allows enterprises to onboard customers globally without the operational and legal risks associated with centralized data models. ## Two Key Points of Decentralization Zyphe is decentralized in two ways: ### Geographical Decentralization Through **geographical decentralization**, Zyphe achieves global infrastructure redundancy and continuity. Each storage node functions independently and is hosted across multiple providers and jurisdictions, ensuring that no single organization, including Zyphe, has control over the network. User data is encrypted, sharded, and distributed across nodes, so even if 80% of the network goes offline, the system remains operational and compliant. This distributed setup protects against downtime, data breaches, and vendor lock-in, providing enterprises with unmatched reliability and cross-border data resilience. ### Ownership Decentralization The **ownership** of personal information is decentralized. Zyphe returns control of personal information to users while maintaining enterprise-grade compliance. Once verified, user data moves into a personal decentralized vault, removing Zyphe entirely from data custody. Users can reuse verified credentials across multiple platforms instantly, reducing friction, verification costs, and regulatory exposure for businesses. This structure transforms KYC into a reusable, consent-based process, enabling companies to meet compliance obligations efficiently, decease frauds while aligning with global privacy regulations like GDPR and future-ready standards for digital identity. --- ## Decentralized Identity Zyphe's is dedicated to revolutionizing how personal identity is handled in the digital space, ensuring that control, privacy, and autonomy remain in the hands of our users. **In this documentation, we provide a comprehensive overview of Zyphe's systems and protocols designed to empower you:** - **The Evolution of Identity Management**: Understand the progression from traditional Siloed Identities to the innovative Decentralized Identities we champion today. - **Decentralized Storage Creation**: Discover the intricacies of how we generate and protect your Personal Online Datastore (POD) for ultimate data sovereignty. - **Dataflow Processes**: Dive into our various dataflow diagrams which detail how your data is managed, from creation, through KYC procedures, to eventual deletion if desired. - **Legal and Compliance Adherence**: Learn about our commitment to legal compliance and the mechanisms in place for authority checks and data retention. This guide aims to demystify the complexities of data management, providing you with clarity and confidence in how your digital identity is curated and conserved. Zyphe isn't just a service; it's a declaration of your right to privacy and self-determination in an increasingly connected world. Thank you for entrusting Zyphe with your digital identity. Together, we're setting the new standard for privacy and user empowerment. --- ## Types of Storages **Siloed Identities**\ This is a legacy system where identities are scattered across various companies. The drawbacks are clear: users juggle multiple credentials, and companies bear the high cost of managing data infrastructures. Plus, the centralized approach to data management leads to significant security vulnerabilities. **Siloed Identities**. In this archaic model, each company holds a separate fragment of the user's identity. This fragmentation leads to a cumbersome experience for users, who must remember a plethora of usernames and passwords, a true hassle in our digital world. Companies aren't spared either; they face the daunting task of maintaining secure, yet costly data infrastructures. Centralized data storage compounds the problem, posing a high risk of catastrophic data breaches. \ **Federated Identities**\ This was an improvement, offering a more connected experience. However, user control remained limited, and companies often exploited user data without clear incentives to protect it. The reliance on central databases continued to be a security concern, and the scope for users to selectively disclose their information was minimal.\ As we evolved into **Federated Identities**, we began to see identities linked across services, offering a glimmer of integration. But this system is far from perfect. Users still lack substantial control, and the user experience is dictated by corporate strategies focused on maximizing data extraction rather than protecting user privacy. Moreover, these federated systems create large honey pots of data, enticing targets for malicious actors, which further amplifies security concerns. **Decentralized Identities** Here at Zyphe, we're enabling a paradigm where users exercise full control over their identity. The need for corporate access to user data now requires explicit user authorization. Our decentralized approach to data storage minimizes security risks and corporate liabilities. Moreover, it supports full selective disclosure, empowering users like never before. **Decentralized identities** shift the paradigm from large, vulnerable data caches to distributed data nodes, each securely encrypted and autonomously controlled. This reduces the risk of mass data breaches and places the power of selective disclosure firmly in your hands. With Zyphe, you’re not just a user; you’re an individual with a fortified, self-sovereign identity. --- ## Why Decentralized PII Storage ## Why a Distributed Approach is Safer Than Centralized Solutions In handling sensitive personal identifiable information (PII), **decentralization** offers a fundamentally safer and more privacy-preserving approach than traditional centralized storage. Unlike a centralized system (where one database or authority holds all data and control), a decentralized system distributes control, decision-making, and data storage across many independent nodes. This means no single entity has complete control and no single point of failure, vastly improving resilience, security, and user privacy Below, we explain how **Zyphe’s decentralized architecture** works and why it is _better and safer_ for storing PII. ### Understanding Decentralization and Its Security Benefits In a decentralized data model, information is **encrypted and fragmented across multiple nodes** rather than kept in one central repository. Each node in the network holds only a piece of the data, and **no single node can access the entire dataset in usable form**. This structure provides several key security advantages: - **No Single Point of Failure:** A breach of one node does not compromise all data. By distributing encrypted data pieces across many servers, the system _eliminates_ the catastrophic risk of a central database breach. (In contrast, a centralized database is an obvious target: if attackers penetrate it, they can steal _everything_ at once.) - **Reduced Attack Surface:** Decentralization dramatically shrinks the attack surface available to hackers. Because data shards are spread out, an attacker would have to breach _dozens_ of nodes (and break strong encryption) to gather meaningful information. This makes successful hacks exponentially [more difficult](https://www.zyphe.com/faqs). In fact, analyses show decentralized storage can be \~**96% more resistant to data breaches** compared to traditional centralized data storage. - **Resilience and Uptime:** With no central server dependency, the system is inherently more fault-tolerant. Even if some nodes go offline or are attacked, the overall network continues to function, preventing downtime and data loss. This resilience ensures continuous availability of identity verification services globally. In short, decentralization means there is _no single vault to crack_: an attacker cannot simply “hit the jackpot” by hacking one server or database. Any malicious attempt faces a fragmented, encrypted wall of data distributed across the network, a far safer design for PII storage. ### Geographical Decentralization with Zyphe: Near-Impenetrable Data Security **Zyphe’s platform implements geographical decentralization** as a core strategy to secure PII. Once a user’s identity data is collected and verified, it is immediately encrypted with strong cryptography (AES-256-GCM and other methods). After encryption, Zyphe **splits the data into many small shards** and distributes these shards across a network of nodes in the user’s region. For example, a user's encrypted data is divided among storage nodes located near that user, drawn from a network of _thousands_ of nodes (to optimize performance and comply with local data residency laws). To reconstruct the original data, a minimum threshold of shards (for instance, 29 out of 100) must be reassembled, providing redundancy while ensuring that no single shard is useful on its own. **Why is this decentralized sharding approach so secure?** Consider the following scenarios and how Zyphe’s design addresses them: - **Breach of Zyphe’s Infrastructure:** Even if attackers breached Zyphe’s own systems, they would gain **no usable data**. Zyphe has _no access_ to plaintext PII after it’s encrypted and shard-distributed. The company doesn’t store complete datasets or any “master key,” meaning there’s no central trove of data to steal. This virtually **eliminates the risk of a platform-wide breach** exposing user information, a stark contrast to traditional providers whose databases can be raided in one go. - **Compromise of a Storage Node:** If one of the decentralized storage nodes is hacked or fails, the attacker obtains only an **encrypted fragment** of a user’s data (for example, just 1% of a document, which is meaningless on its own). **At least 29** independent shards would be required to reconstruct anything intelligible, and each shard is indecipherable without the decryption keys. Thus, a single server breach is effectively useless to an attacker. This _fragmentation and distribution strategy significantly reduces the risk of unauthorized access or data breaches_ - **Company-Wide or Server Cluster Breach:** In a worst-case event where multiple nodes or even a large portion of the network is compromised, the **threshold encryption** ensures that unless the attackers control a large majority of nodes (far beyond a feasible scope) _and_ break the encryption, the data remains safe. There is no central database to dump; any partial data from servers is still encrypted and incomplete. According to Zyphe’s metrics, decentralized storage **reduces the overall breach risk by orders of magnitude**, roughly a 96% improvement in breach resistance over centralized storage methods. - **Individual User Account Breach:** In the unfortunate case that a single user’s credentials or device are compromised, **only that user’s encrypted data** could potentially be accessed. No attacker can use one user’s credentials to leapfrog into a vast database of others’ information, because such a central database doesn’t exist. This containment contrasts with centralized systems where a single leaked administrator account or vulnerability could expose _millions_ of user records at once. Zyphe’s design inherently limits the blast radius of any single-user breach to that one user alone. Overall, by geographically distributing encrypted data shards and requiring a distributed consensus to reassemble them, Zyphe creates a **near-impenetrable security mesh** around PII. Even a breach at one point yields nothing of value, and **systemic breaches become exceedingly unlikely**. This approach **virtually nullifies the mass data-theft scenarios** that plague centralized databases. It’s a level of security and risk reduction that centralized storage simply cannot match. _(Notably, this decentralized model also simplifies compliance with data protection laws: user data shards stay within the user’s region or jurisdiction, satisfying stringent data residency requirements like GDPR by design. In other words, your European customers’ data stays in Europe, your Canadian data stays in Canada, etc., adding another layer of security and regulatory peace of mind.)_ ### User Ownership and Enhanced Privacy Control A decentralized data ecosystem also transforms the concept of data **ownership**, **putting users firmly in control of their own PII**. With Zyphe, once your data is verified and fragmented into the network, **you as the user retain the keys and rights to that information**, rather than a company holding it in a silo. Zyphe acts as a secure facilitator, but **does not have unilateral access to your personal data** after onboarding. This user-centric ownership model has several powerful implications: - **Personal Data Autonomy:** You decide **who** can access your identity information and **when**. Sharing your data becomes a conscious, user-driven action (for example, consenting to share your verified credentials with a new service), rather than something that happens behind the scenes in a provider’s database. This **enhanced privacy control** means your sensitive documents aren’t floating around on various third-party servers without necessity. Zyphe’s system is built on privacy-by-design principles to ensure users have direct control over their data at all times. - **No Unwanted Access or Backdoors:** Because of the encryption and distributed keys, **even Zyphe cannot access or read your PII** once it’s decentralized. There is no “backdoor” where a staff member or an internal breach could pull up your raw documents. This provides peace of mind that _only_ you (and those you authorize) ever see your personal data in readable form. It also prevents any single entity from monetizing or misusing your data, you truly **own your identity data** in the system. - **Privacy and Compliance by Design:** The decentralization inherently enforces data minimization, only the necessary information is stored, and it’s stored in a dispersed way. This minimizes the privacy risks and lowers compliance burdens on businesses using Zyphe. Companies don’t have to hold caches of PII they might otherwise be liable for securing; instead, users hold their data and just grant permission as needed. This **privacy-first architecture** builds trust: end-users know their information isn’t being stockpiled and exploited, and businesses can demonstrate respect for user privacy from the ground up. In summary, decentralization shifts the power over personal data back to its rightful owner, the individual. When clients use Zyphe’s decentralized KYC platform, they are empowering their users with transparency and control, which strengthens the business-user relationship. Users gain confidence knowing _their_ data is safe, not only from hackers but also from unnecessary access or misuse. ### One-Click KYC with Reusable Credentials: Security Meets Convenience A major advantage of Zyphe’s decentralized approach is the introduction of **One-Click KYC** via **reusable credentials**. This feature is not just a usability improvement, it also enhances security by reducing how often sensitive data needs to be shared. Here’s how it works and why it’s better than traditional repeated KYC checks: - **Verify Once, Reuse Securely:** With Zyphe, a user goes through the identity verification process **only once** to create a trusted digital credential. This might involve verifying a passport, driver’s license, selfie liveness check, etc., just like a normal KYC, but after this is completed, the verified identity data is encrypted and stored _decentrally_ as described above. The user is then issued a reusable KYC credential (essentially a cryptographic proof of their verified identity). When the user needs to verify their identity with another service or platform, they can simply **share this credential with one click**, no need to re-upload documents or re-enter personal details for each new account. The receiving service gets confirmation that the user’s identity is verified (via Zyphe’s attestation), **without the user’s raw PII ever changing hands again**. This dramatically cuts down on unnecessary data exposure. - **Minimized Data Exposure:** In traditional KYC processes, a user might send copies of their passport, ID, proof of address, etc., to every company they do business with, leading to _multiple copies_ of their PII stored across the internet. Each additional copy and storage location is another potential breach point. One-Click KYC **solves this by minimizing data duplication**: the user’s sensitive documents are not repeatedly transmitted and stored in new databases. Instead, a secure reference or token is shared. This **reduces the amount of personal data shared by orders of magnitude**, thereby _greatly lowering the risk of data being exposed or stolen during KYC processes_. Essentially, your passport scan isn’t sitting in five different company databases, it stays encrypted in your control, and only a verifiable proof is shared. - **Faster, Frictionless User Experience:** From a business perspective, one-click reusable KYC significantly **streamlines onboarding**. Users don’t drop out of signup flows due to KYC fatigue, since they can instantly satisfy KYC requirements with a click. This leads to higher completion rates, Zyphe reports up to **70% more users complete onboarding** when using reusable identity credentials versus traditional KYC methods. More completed onboardings mean more customers and revenue for businesses, achieved **without compromising security**. In fact, security is improved, as noted above, because less raw data is in transit or being repeatedly handled. - **Cost and Efficiency Gains:** For businesses, the reusable KYC model cuts down on redundant verification checks and storage. They don’t need to store as much PII (which reduces compliance scope and costs), and they avoid the expense of performing KYC from scratch for returning users or across multiple services. This not only saves money but also means fewer opportunities for a mistake or leak. Overall, it’s a win-win: **better security and privacy** for users, along with **faster onboarding and lower overhead** for companies. In summary, One-Click KYC powered by decentralized credentials combines **security with convenience**. It leverages the strength of Zyphe’s distributed network to **protect user data**, while simultaneously removing friction from the user journey. The result is a seamless yet secure verification process that stands in stark contrast to the cumbersome and risk-prone centralized KYC procedures of the past. ### Transparency, Trust, and Compliance in a Decentralized Ecosystem Decentralization doesn’t just improve security and convenience, it also fosters **greater transparency and trust** between all parties involved. Because of its inherent design, Zyphe’s decentralized storage and verification system offers clarity into how data is handled, and robust safeguards that inspire confidence: - **Auditability and Tamper-Proof Records:** Every action in a decentralized network can be logged in an immutable manner (often using blockchain-like ledgers or cryptographic audit trails). Zyphe employs **immutable logs and threshold encryption** so that any access to data requires consensus from multiple authorized parties. This creates a **tamper-proof record** of who accessed what and when, making the system highly transparent and audit-friendly. Neither data nor logs can be altered or deleted without detection. For regulated businesses, this means **simpler compliance audits**, you have a built-in, verifiable trail proving that sensitive data was handled properly and only accessed with proper authorization. - **User Visibility and Consent:** Zyphe’s approach is _privacy-first and transparent by design_. Users can **see how their personal data is being used** and are given meaningful control over that usage. For instance, when a user shares their KYC credential with a new service, that consent and transaction can be made transparent to the user. There are no dark corners or hidden data flows as often seen in big centralized systems. This openness reassures users that their information isn’t being misused or accessed without their knowledge, further building trust in the platform. - **No Central Honeypot for Misuse:** With no central database, there is no opportunity for internal bad actors or external spies to quietly collect large datasets of personal information. In a centralized model, whoever runs the database has enormous power (and could potentially be compelled or tempted to misuse data). In Zyphe’s decentralized model, **such risks are mitigated**, even the service provider _cannot_ unilaterally exploit user data. This strong stance on privacy and security **demonstrates to clients and end-users that the company values their data protection**, not just in words but through concrete architecture choices. - **Improved Customer Trust and Brand Reputation:** Ultimately, using a decentralized, secure solution helps a business **build trust with its customers**. Users are increasingly concerned about how companies handle their PII, and rightfully so, data breaches and privacy scandals have eroded public confidence in many industries. Adopting Zyphe’s decentralized storage for PII sends a message that your organization is _proactively safeguarding user privacy_. Knowing that a service “doesn’t even have access to my data unless I allow it” is a powerful trust signal to customers. Moreover, by **eliminating single points of failure**, Zyphe’s system greatly reduces the chance of a devastating breach that could destroy customer trust overnight. In fact, Zyphe’s decentralized identity management is explicitly designed to **improve user trust by removing those single points of vulnerability**. Businesses that prioritize such privacy and security not only avoid costly breaches and compliance fines, but also **differentiate themselves in the market as trustworthy custodians of user data**. In a decentralized ecosystem, **transparency is not an afterthought, it’s baked into the way data is stored and accessed.** This assures all stakeholders (users, businesses, regulators) that PII is handled with the utmost integrity. Companies leveraging Zyphe can confidently show that they _never_ put customer data at unnecessary risk, thereby meeting regulatory requirements and exceeding user expectations for privacy. The result is a stronger foundation of trust, which is invaluable in any client relationship. ### **Conclusion:** Decentralization = Better Security, Privacy, and Peace of Mind Shifting from a centralized to a decentralized model for storing PII is a **paradigm shift in security and data ownership**. By decentralizing data storage and control, Zyphe achieves a level of security and privacy that traditional systems cannot match. Data breaches are no longer existential threats but contained incidents; users are no longer passive data subjects but active data owners. The **technical benefits** (encryption, sharding, redundancy, no single point of failure) translate directly into **business benefits**, drastically lower breach risk, easier compliance, reduced liability, and higher user trust and satisfaction. In practical terms, **decentralized storage is simply safer for PII**. It means that even if one door is pried open, the vault as a whole remains secure. It means only those with permission can ever assemble the pieces of personal data, and even then under strict controls. It means an organization doesn’t have to wake up to a nightmare headline about millions of identities leaked, because such a leak is nearly impossible by design. And it means users can confidently share their information, knowing it isn’t being hoarded in yet another vulnerable silo. By embracing this decentralized approach, **Zyphe and its clients stand at the forefront of data security and privacy**. They offer customers a solution that is _not only more secure_, but also _more respectful_ of individual privacy. In an era of daily data breaches and increasing privacy regulations, this approach isn’t just better, it’s the future of how sensitive information should be handled. **Decentralization makes PII storage better, safer, and smarter**, creating a win-win for businesses and the people they serve. --- ## Frequently Asked Questions(Frequently-asked-questions) ## What is a Decentralized Storage Vault? A **User Vault** is a secure, personal space for verified and encrypted information, such as identity documents and biometrics collected during verification. It allows users to safely store and manage their data while giving companies a compliant way to access it when authorized. Access is always controlled by the user. Data can only be shared with parties explicitly granted permission or those who hold the unique Vault Access Key. Unlike centralized storage, a User Vault is **distributed and decentralized**: information is broken into fragments (shards) and stored across multiple nodes in Zyphe’s network. Each shard is encrypted using an **n-out-of-m threshold scheme**, so no single node can ever view or reconstruct the underlying data. Only authorized users can reassemble and decrypt the information, ensuring there is no single point of failure and dramatically reducing the risk of breaches or unauthorized access. For onboarding, users benefit from faster verification: if an identity document in the vault is still valid and accepted by a platform, they can reuse it without repeating KYC. All data is geo-located to meet residency requirements and protected with industry-grade security, including **AES‑256** encryption. By design, Zyphe’s decentralized infrastructure removes central points of vulnerability, lowering both compliance overhead and data breach risks while keeping privacy fully in the user’s control. ## How should I store my Vault Access Key? You are welcome to store the Vault Access Key to your own decentralized storage vault in whichever format you prefer, though we recommend using a secure password manager that also includes biometric validation or a passkey. In the event of a future onboarding using Zyphe, using this passcode, you will be able to save time and avoid redoing KYC if the IDs in your vault are still valid and include an acceptable form of ID for the platform that you’re onboarding with. If you lose your Vault Access Key, then you may be required to redo your KYC the next time you onboard with a platform that uses Zyphe. ## Is it safe to send users a Vault Access Key via email? Yes, sending your Vault Access Key by email is considered safe enough to balance ease of use with strong security. We chose this method so that you can receive the key quickly and conveniently, without complicated steps, while still ensuring your information remains protected. The Vault Access Key on its own does not provide access to your data or account. It can only be used in combination with your existing platform credentials, which stay private and secure. This means that even in the unlikely event the email were intercepted or the key leaked, it cannot be used directly to access your storage or personal information. In addition, our emails are transmitted over encrypted connections (TLS) whenever supported by mail providers, helping to protect them during delivery. To keep your account as safe as possible, we recommend that you: Do not forward or share your Vault Access Key Store it securely (for example, in a password manager) Delete the email once you’ve saved the key safely This approach ensures that the Vault Access Key is both **convenient to use** and **secure against misuse**. ## Does my Zyphe Vault Access Key grant access to the platform that I'm onboarding with? The Vault Access Key you received is only for your identity information stored in Zyphe, which can be conveniently reused for future onboarding onto other platforms that also use Zyphe for identity verification. It does not grant access to the platform that you’re onboarding with. You will separately need the login information for that specific platform. --- ## Introduction Zyphe is identity infrastructure built so organizations can **verify, reuse, and monitor** trust, without treating personal data as a free-for-all. One platform covers: - **Identity verification (KYC)**: document, liveness, address, phone, forms, and more, composed into flows - **Business verification (KYB)**: companies, directors, and beneficial owners - **Reusable credentials**: one-click KYC and KYC Passport so partners reuse an existing verification with user consent - **AML screening & monitoring**: sanctions, PEP, adverse media, and ongoing risk - **Transaction monitoring**: rules, lists, and Allow / Review / Block decisions Privacy is not a slogan here: PII is stored with user-centric controls, access is role-based, and sharing is grant-driven. For the architecture behind that, see [Decentralized Identity](/docs/decentralized-identity); for what you decide as controller and what Zyphe retains, see [Privacy, consent and retention](/docs/privacy-consent-and-retention). --- ## Start here | Path | Who it's for | Time | | -------------------------------------------------------------------------- | ----------------------------------------------------- | --------------------------- | | **[Quickstart](/docs/quickstart)** | Anyone shipping a first verification | Shortest linear path | | **[Verification types](/docs/verification-types)** | Anyone comparing what each check verifies and returns | One-page map of every check | | **[Choosing an integration method](/docs/choosing-an-integration-method)** | Engineers deciding hosted link vs SDK vs agent | Decision page | | **[Integration](/docs/guides/integration)** | Hosts, HTTP API, mobile WebView, export, go-live | Backend recipe hub | | **[Environment setup](/docs/guides/environment-setup)** | Anyone calling the API (hosts, keys, `.env`) | Read once | | **[Sandbox and go-live](/docs/guides/sandbox-and-go-live)** | Teams ready for production | QA + cutover checklist | | **[Privacy, consent and retention](/docs/privacy-consent-and-retention)** | DPOs, legal and integrators acting as controller | Roles, retention, deletion | | **[Guides](/docs/guides/dashboard)** | Configuring and operating each capability | Task-oriented how-tos | | **[Statuses and codes](/docs/reference/statuses-and-codes)** | Interpreting webhooks and API outcomes | Reference | | **[API reference](/docs/openapi/zyphe-sdk)** | Coding against the exact contract | OpenAPI + schemas | --- ## Core objects These are the concepts you will see across the product and API: | Object | What it is | | ------------------------ | --------------------------------------------------------------------------------- | | **Flow** | The sequence of verification steps a user completes (document, liveness, PoA, …) | | **Verification request** | One run of a flow for a specific user | | **Flow result** | The reviewed outcome, scores, and collected data (subject to role and PII access) | | **Webhook** | Signed real-time notification when a result or status changes | | **Score** | Explainable risk or quality signal derived from tags, factors, and checks | | **Transaction** | An activity event evaluated by transaction-monitoring rules | Deeper model: [Verification process](/docs/verification-process) · [Data flows](/docs/data-flows) --- ## Products Every check on one page, with what it verifies and what it returns: **[Verification types](/docs/verification-types)**. | Product | Outcome | How it works | Guide | | -------------------------- | ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **Flows / KYC** | Onboard users with composable checks | [Verification process](/docs/verification-process) · [Document](/docs/how-it-works/document-verification) · [Liveness](/docs/how-it-works/liveness) | [Create a flow](/docs/guides/create-a-flow) | | **Proof of address** | Verify residency evidence | [PoA](/docs/how-it-works/proof-of-address) | [Configure PoA](/docs/guides/create-a-flow/proof-of-address) | | **KYB** | Verify businesses and ownership | [KYB](/docs/how-it-works/kyb) | [Business verification](/docs/guides/kyb) | | **Reusable credentials** | Reuse trust across partners | [One-click KYC](/docs/reusable-credentials-one-click-kyc) | [KYC Passport](/docs/guides/kyc-passport) | | **AML** | Screen and monitor financial crime risk | [AML](/docs/aml) | [Risk scoring](/docs/aml/risk-scoring) · [Agentic review](/docs/aml/agentic-review-engine) · [Monitoring](/docs/aml/monitoring) | | **Transaction monitoring** | Continuous Allow / Review / Block | [TM concepts](/docs/transaction-monitoring) | [TM operation](/docs/guides/transaction-monitoring) | | **Scoring & review** | Turn signals into decisions | - | [Scoring](/docs/guides/scoring) · [Manual review](/docs/guides/manual-review) | | **Antifraud controls** | Document, liveness, KYB, AML, TM, agents | [Antifraud controls](/docs/how-it-works/antifraud-controls) | Linked from that map | --- ## Who this documentation is for **Engineers**: integrate with a [public link](/docs/choosing-an-integration-method#public-link), [SDK](/docs/guides/sdk), [webhooks](/docs/guides/webhook), or an [MCP-compatible AI agent](/docs/guides/model-context-protocol-mcp). Start with the [Quickstart](/docs/quickstart). **Compliance & operations**: review results, configure scores, manage AML and transaction-monitoring cases, and enforce [role-based PII access](/docs/pii-access-control). See [Manage users](/docs/guides/manage-users), [Scoring](/docs/guides/scoring), and [Privacy, consent and retention](/docs/privacy-consent-and-retention). **Partners & networks**: invite organizations and reuse verifications with user consent via [KYC Passport](/docs/guides/kyc-passport) and [reusable credentials](/docs/reusable-credentials-one-click-kyc). --- ## How the docs are organized | Section | Intent | | -------------- | ---------------------------------------------------------------------- | | **Quickstart** | One opinionated path from zero to a reviewed result | | **Overview** | What the product is, why it works this way, conceptual data flows | | **Guides** | How to configure and operate each capability | | **Reference** | Statuses and codes, OpenAPI, [LLM-friendly docs](pathname:///llms.txt) | Rule of thumb: deciding _whether_ → Overview · fastest _try_ → Quickstart · _configure_ → Guides · _code the contract_ → Reference. --- ## Integrations This section covers third-party systems and protocols that Zyphe interoperates with. - **[Italian Digital Identity Ecosystem (SPID and CIE)](./italian-digital-identity-ecosystem-spid-and-cie.md)**: verify Italian users via the official SPID and CIE identity providers. --- ## Italian Digital Identity Ecosystem: SPID and CIE SPID (Sistema Pubblico di Identità Digitale) and CIE (Carta d'Identità Elettronica) are two key components of the Italian digital identity ecosystem, designed to simplify access to online services for citizens and businesses. ## SPID (Sistema Pubblico di Identità Digitale - Public Digital Identity System) - **What it is:** SPID is a set of credentials (username, password, and often a second factor like an OTP) that allows citizens and businesses to access online services of the Italian public administration and private entities that have joined the system. It's not a physical card but a digital identity. - **How it works:** Users obtain their SPID identity from accredited "Identity Providers" (e.g., Poste Italiane, Aruba, Infocert). Once registered, they use these credentials to log in to various online services without needing separate accounts for each. - **Purpose:** To provide a single, secure, and unified digital identity for accessing a wide range of public and private online services, streamlining bureaucracy and enhancing digital interaction. ## CIE (Carta d'Identità Elettronica - Electronic Identity Card) - **What it is:** The CIE is the Italian electronic identity card, a physical smart card that serves as a personal identification document. Beyond its physical use for identification, it incorporates a microchip that can be used for digital authentication. - **How it works:** The CIE can be used in two main ways for digital services: - **Level 1 (Desktop):** By physically inserting the card into an NFC-enabled card reader connected to a computer and entering a PIN. - **Level 2 (Mobile):** Using an NFC-enabled smartphone with the "CIE ID" app to read the card and authenticate, often with fingerprint or facial recognition as a second factor. - **Purpose:** To serve as a secure physical and digital identification document. It provides a robust authentication method for online services, similar to SPID but based on a physical token (the card). ## Key Differences and Relationship: - **Nature:** SPID is purely a digital identity (credentials), while CIE is a physical document with digital capabilities. - **Issuance:** SPID is issued by private Identity Providers; CIE is issued by the Ministry of Interior through municipalities. - **Authentication:** Both offer secure authentication to online services. SPID is generally more widespread for quick access, while CIE offers a higher level of assurance due to its physical token component. - **Interoperability:** Both are part of the broader Italian digital identity strategy and can often be used interchangeably to access the same online services. The trend is towards deeper integration, with the CIE becoming a potential "SPID provider" in itself. In essence, SPID provides a flexible and widely adopted digital login, while the CIE offers a highly secure, hardware-based authentication method, both working together to underpin Italy's digital public services. ## Verification process When a user starts a SPID/CIE verification step on the Zyphe platform is prompted to log in with their SPID or CIE accounts. Once the authentication happens, the user is asked to confirm that he is going to share data with the Zyphe platform. After the confirmation, the platform collect the information from the identity provider and store the underlying information in the User Vault the same way we do for Document Verification.
Users choose CIE or select their SPID identity provider before sharing verified identity data.
--- ## PII Access Control ## Overview Zyphe applies role-based access control (RBAC) to Personally Identifiable Information (PII) so that sensitive customer data is only visible to the people who need it. This page explains the **principles** behind that model. For the concrete roles and the exact permission matrix (who can do what in the dashboard and API), see [Manage Users](/docs/guides/manage-users). ## Problem statement In many KYC/KYB systems, everyone with dashboard access can see every customer's PII. That creates avoidable risk: - **Insider threat**: internal actors with legitimate access can exfiltrate large volumes of sensitive data. - **Over-privileged access**: people with no need to view PII can see it anyway. - **Compliance risk**: broad access makes data-minimization obligations under GDPR, CCPA, and similar regimes hard to meet. - **Weak audit trail**: without granular controls it is difficult to reconstruct who accessed what, and when. ## How Zyphe reduces PII exposure Zyphe addresses this on two fronts: 1. **Decentralized storage.** PII lives in the user's own vault, not in a central Zyphe database. Only the minimum attributes required for a given operation are read, and every access is recorded in a hash-chained audit trail. See [Decentralized Identity](/docs/decentralized-identity) and [Why decentralized PII storage](/docs/decentralized-identity/why-decentralized-pii-storage). 2. **Role-based access.** Within your organization, what each member can see and do is governed by their **role**. Roles are least-privilege by default: a member is granted the narrowest set of permissions that lets them do their job, and elevated access is the exception rather than the rule. ## Roles Access is governed by the organization roles Zyphe enforces today: | Role | Typical use | | --------------- | --------------------------------------------------------------------- | | **Admin** | Organizational management and oversight; full access. | | **Operator** | Reviewing and operating on verification results and AML cases. | | **AML Officer** | AML monitoring and case management. | | **Developer** | Integration work, flows, API keys, webhooks. | | **Partner** | External collaborators, limited to flows explicitly shared with them. | The authoritative, per-permission breakdown of these roles, including what each can access and how partner flow access is granted, is maintained in **[Manage Users](/docs/guides/manage-users)**. Treat that page as the single source of truth; this page covers only the principles. :::info[Least privilege in practice] Default new members to the lowest role that lets them work, review elevated roles periodically, and keep the number of full-access accounts small. Grant broader access deliberately, not by default. ::: ## Webhooks and PII Webhook payloads respect your organization's PII configuration. You can choose how much a webhook carries: - **No PII (recommended)**: the webhook signals that a result is ready; PII is fetched separately with the [Export API](/docs/guides/export-api), subject to role permissions. - **Identifier only**: the webhook includes a session/result identifier and nothing sensitive. - **PII included**: only for organizations that explicitly opt in and accept the added handling responsibility. See [Webhooks](/docs/guides/webhook) for delivery and payload details. ## Best practices **For organizations** 1. Assign full-access (Admin) roles sparingly and secure those credentials with strong authentication. 2. Review who holds elevated roles on a regular cadence. 3. Monitor for unusual access patterns. 4. Default to the least-privileged role and grant more only when there is a demonstrated need. **For developers** 1. Never cache PII in client-side storage or logs. 2. Check access on every request rather than assuming it from a previous one. 3. Handle missing PII gracefully, your UI should work when PII fields are absent for the current role. 4. Test your integration against every role your users may have. ## Related - [Privacy, consent and retention](/docs/privacy-consent-and-retention): controller and processor roles, what Zyphe retains, and how deletion works ## Support For questions about PII access control, contact **support@zyphe.com**. --- ## Privacy, consent and retention When your organization runs KYC, KYB or AML checks through Zyphe, you are the **controller** of the verification data and Zyphe is your **processor**, acting on your documented instructions under a data processing agreement (DPA). You choose the lawful basis for the check, tell your end users about it and keep your own compliance record. Zyphe retains verification results, audit logs and cryptographic proofs; identity documents and biometrics are processed transiently, then encrypted and stored in the end user's own vault rather than in a central Zyphe database. :::info[Sources and scope] This page gathers, for integrators, what these docs and Zyphe's public [GDPR statement](https://www.zyphe.com/gdpr) say about roles, consent, retention and deletion. The GDPR statement restates the DPA, which you can request from **privacy@zyphe.com**. This page is not legal advice. ::: ## Your side and Zyphe's side | Topic | You, as controller | Zyphe, as processor | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | Role | Controller of the verification data your checks produce | Processor, acting on your documented instructions under the DPA | | Lawful basis | You decide the legal basis on which your customers are verified | Processes on your instructions; does not supply the basis | | Notice to end users | Your privacy notice says that a verification provider processes their document and face on your behalf | Processes the document and face on your behalf, on your instructions | | Biometric data | Cover facial processing in your notice and, where required, in your impact assessment | Processes facial images as special category data, on the person's explicit consent collected at the point of verification | | Retention | Your own anti-money-laundering record of the check, typically kept for five years, plus any copies you export | Verification results, audit logs and cryptographic proofs, for the term of the agreement or as required by law | | Erasure | Receive and route requests under your own data protection procedures | Executes erasure by revoking access to the encrypted shards, then deletes data as retention obligations lapse | | Decisions | The customer risk profile, the decision to enter or end a relationship, reports to the financial intelligence unit, and the agent mode on each step | Runs the automated checks and, depending on the agent mode you set, prepares or enacts reviews | | Impact assessment | Yours, if your processing requires one | Supplies the DPA, its annexes and answers on request | | Data residency | Nothing to configure | Stores data regionally, following the end user's location | ## Roles Zyphe touches two kinds of personal data, and the roles differ: - **Verification data.** When you run a KYC, KYB or AML check, the identity data belongs to your relationship with your customer. You are controller; Zyphe processes it under the DPA to return a verification result to you. - **Zyphe's own website, lead and hiring data.** Zyphe is controller of that data, as set out in its [privacy policy](https://www.zyphe.com/privacy-policy). Inside your organization, who can see verification data is governed by roles. See [PII Access Control](/docs/pii-access-control) for the principles and [Manage Users](/docs/guides/manage-users) for the permission matrix. ## Biometric data and consent A facial image used to identify a person uniquely is special category data under Article 9 of the GDPR. According to the [GDPR statement](https://www.zyphe.com/gdpr), Zyphe processes it: - on the person's **explicit consent**, collected at the point of verification; - only to match the face to the document, and not for any other check; - without using it to train models; - without disclosing it to anyone other than the company that asked for the verification; - with destruction within the limits set by BIPA and CUBI, as recorded in section 10.3 of the DPA. Liveness, face matching and injection-attack detection run in-house rather than through a third-party biometric vendor. The live portrait captured by the [liveness step](/docs/guides/create-a-flow/liveness) is stored in the user's vault. :::warning[Optional biometric uniqueness checks] The liveness step can also run a biometric uniqueness check that detects one person verifying under several identities. It runs in a privacy-preserving way and is off unless Zyphe support enables it for your flows. If you enable it, describe it in your notice and impact assessment; the [GDPR statement](https://www.zyphe.com/gdpr) covers it. ::: When a user's vault is created, the user is asked to grant permission to store their personal data. See [Creation of the User Vault](/docs/data-flows/creation-of-the-user-vault). ## What Zyphe retains ### Kept by Zyphe | Data | How long, or in what form | | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Verification results, audit logs and cryptographic proofs | For the term of the agreement or as required by law | | Screening identifiers | Only while ongoing monitoring is switched on for that customer | | Phone numbers from [phone verification](/docs/guides/create-a-flow/phone-verification) | As a SHA-256 hash, with only the last four digits in plain text | | TINs from [TIN Check](/docs/guides/tin-check) and EINs checked on KYB | The last four digits only; the full number is used for the lookup and discarded | | AML scoring inputs | Matched topics, jurisdictions, positions, relationships and assigned tags, kept with the result so the score can be re-explained ([Risk scoring](/docs/aml/risk-scoring)) | | Webhook delivery records | 90 days by default, then purged ([Webhook Endpoints](/docs/guides/webhook/endpoints#delivery)) | ### Not held in a central Zyphe database Identity documents and biometrics are processed transiently, then encrypted with AES-256, split into shards and stored in the end user's own vault. When the user shares that data with an organization, Zyphe re-encrypts the ciphertext for the recipient through proxy re-encryption, without access to the plaintext, and revoking the access deletes the re-encryption key. See [Data Sharing and Encryption](/docs/decentralized-identity/data-sharing-and-encryption) and [Why decentralized PII storage](/docs/decentralized-identity/why-decentralized-pii-storage). When Flow Builder routes on fields from vault documents (such as age or nationality), the workflow keeps only the outcome needed to continue the flow. See [Conditions with custom data and vault fields](/docs/guides/create-a-flow#conditions-with-custom-data-and-vault-fields). ### Copies that reach you Data you receive is held under your controls and your retention rules: | Channel | What it can carry | | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Webhooks | The PII level you configure: no PII (recommended), an identifier only, or PII when you opt in. The Extended Webhook adds extracted document fields and a time-limited selfie URL. See [PII Access Control](/docs/pii-access-control#webhooks-and-pii) | | [Export API](/docs/guides/export-api) | Full result details and media: document images, portrait and selfie captures, a liveness video URL and proof-of-address files. Download them promptly and store them under your own access controls | | Dashboard | Results and cases, visible according to each member's role | | KYC Passport partners | Data a partner has already accessed stays with that partner until its own retention obligations are met | ## Deletion and erasure Erasure is executed by revoking access to the shards, because the record is held in the data subject's vault rather than copied onto Zyphe servers. The [Data Deletion](/docs/data-flows/data-deletion) flow: 1. The user submits a deletion request. 2. Zyphe checks the retention obligations of every recipient. 3. Access that is no longer needed is revoked at once. 4. Data is marked for deletion once every remaining obligation has expired. 5. The user receives an immediate confirmation that the request is in progress. 6. Every 24 hours, Zyphe re-evaluates the obligations, revokes newly ineligible access and deletes data whose retention period has lapsed. 7. The user is notified when deletion is complete. What stays on your side: - **Your own record.** Anti-money-laundering law can require you to keep your record of the check, typically for five years. Zyphe erasing the identity data does not shorten that obligation. - **KYC Passport.** Users cannot revoke their sharing consent directly; they request deletion through your data protection procedures, and you revoke partner access as appropriate. Users are not notified automatically when you revoke a partner. See the [KYC Passport FAQ](/docs/guides/kyc-passport/faq). - **Expiry notices.** A `KYC_RESULT_EXPIRED` notification (`verification.kyc.expired`) tells you when a KYC result has passed its retention or validity window. See [Statuses and codes](/docs/reference/statuses-and-codes#notification-eventdatatype). Deleting a result from the dashboard is a sandbox testing aid for re-running a flow, not the erasure path; it is not offered in production. See [Deleting sandbox results](/docs/guides/sandbox-mode#deleting-sandbox-results). Data subject rights requests go to **privacy@zyphe.com**. The GDPR statement says they are answered within one month, extendable by two further months for complex requests. ## Where data is processed and stored Storage is regional and follows the end user's location: | End user | Processed and stored in | | ------------- | ---------------------------------- | | EEA and UK | EEA and UK nodes and cloud regions | | United States | US regions | Residency is enforced by the storage layer, as a property of where the encrypted shards live, rather than a per-market setting you configure. The shards are geo-locked, so, as the GDPR statement puts it, a Swiss customer's data stays in Switzerland. Identity verification data does not normally leave the region it was collected in. Where a transfer mechanism is needed, the DPA includes the Standard Contractual Clauses and the UK Addendum. ## Sub-processors and the DPA The DPA includes Annexes I to III (subject matter and duration, technical and organisational measures, and the sub-processor list), the Standard Contractual Clauses and the UK Addendum. The sub-processor list is Annex III, including the register-data supplier used for business verification, and is available on request at privacy@zyphe.com. The agreement and its annexes are part of the customer contract, so they are provided on request rather than published. Points for your data map that the docs state: - AML screening shares only the minimum necessary attributes with the screening engine and with third-party sanctions, PEP and adverse-media data sources ([AML overview](/docs/aml)). - Phone verification sends the one-time code by SMS through AWS SNS ([Phone verification](/docs/guides/create-a-flow/phone-verification)). - SPID / CIE attributes come from the user's identity provider ([SPID / CIE](/docs/integrations/italian-digital-identity-ecosystem-spid-and-cie)). For what each check is checked against, see [Verification types: Data sources](/docs/verification-types#data-sources). Zyphe is not yet SOC 2 or ISO/IEC 27001 certified; both audits are in progress. The current status is on [zyphe.com/security](https://www.zyphe.com/security). ## Automated decisions and human review Article 22 of the GDPR constrains decisions based solely on automated processing that produce legal or similarly significant effects on a person, and the EU anti-money-laundering regulation, Article 18(3), reserves the customer risk profile, the decision to enter a business relationship and reporting to the FIU to the obliged entity. How much a person decides in your setup depends on the configuration you choose: | Check | What is automated | Where a person decides | | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Document, liveness, proof of address and the other flow steps | Each step's checks return `PASSED` or `FAILED` automatically | A document verification result that automated checks cannot finalize goes to [manual review](/docs/guides/manual-review) by an Admin or Operator | | AML screening | With **AML Agent Mode** on Auto-pilot, the agent may clear a hit when a deterministic guard also passes | Disabled: operators review every hit. Suggest: clears are suggestions a person confirms. The agent never overturns a human verdict, and never auto-clears a high-confidence sanctions match or a Critical risk ([AML Agent Mode](/docs/aml#aml-agent-mode)) | | KYB | With **KYB Agent Mode** on Auto-pilot, the agent may approve under the same rules as a person | A clean company is not approved on its own: it waits in `READY_FOR_REVIEW` for a reviewer, or for the KYB agent in Auto-pilot. Your [approval matrix](/docs/guides/kyb/compliance-policy#approval-matrix) sets who may decide; an agent or API key can take a first signature, never the second | | Transaction Monitoring | Each payment gets a synchronous Allow, Review or Block from your rules | Your platform acts on the verdict, and raised alerts go to your webhook for your own case management. The TM agent is fixed to Disabled | The agent mode on each step, and what your product does with an automated `FAILED` or `BLOCK`, are your decisions as controller. Auto-pilot is switched on per category by your organisation, after you have validated the agent's results on that category. Every agent action is logged with its rationale, and your MLRO keeps final sign-off and responsibility. ## KYC Passport and reusable credentials Sharing a verification with another organization always runs on the user's consent: - **Reusable credentials.** The user unlocks their vault and agrees to share an eligible credential; the company receives an access grant. See [Reusable Credentials](/docs/reusable-credentials-one-click-kyc). - **KYC Passport.** During verification, the consent screen lists your organization, every partner invited at that moment, and the types of data shared. Consent is specific to the flow; partners invited later get no access to that user's data; without consent no partner grant is created. See [User Consent and Privacy](/docs/guides/kyc-passport/user-consent) and [KYC Passport](/docs/data-flows/kyc-passport). A partner organization that accepts an invitation needs a legal basis for processing the shared data, privacy notices for end users where needed, a way to honour user rights, and proper data processing agreements with its partners ([Accepting Partner Invitations](/docs/guides/kyc-passport/accepting-invitations#compliance)). How long sharing consent lasts follows your privacy policy and data retention policy ([KYC Passport FAQ](/docs/guides/kyc-passport/faq)). ## Example end-user notice :::caution[Example only] Adapt this with your legal counsel; it is not legal advice. Fill in the bracketed parts. The rest restates Zyphe's GDPR statement, so remove anything that does not match your setup, and add optional features you enable, such as biometric uniqueness checks or KYC Passport sharing. ::: > To verify your identity, [Company] uses Zyphe as a verification provider. Zyphe processes your identity document and an image of your face on our behalf and on our instructions. The legal basis for this check is [lawful basis]. Your facial image is processed only with your explicit consent and only to match your face to your document; it is not used to train models or for any other check. Your document and images are processed transiently, then encrypted and stored in your own Zyphe vault rather than in a central database. Zyphe keeps the verification result, an audit log and a cryptographic proof for the term of our agreement with Zyphe or as required by law. [Company] keeps its own record of the check for [period] as required by [law]. Your verification data is processed and stored in [the EEA and the UK / Switzerland / the United States], following your location. [Describe who reviews the outcome of your application.] To exercise your rights, contact [contact]. ## Documents you can request Ask **privacy@zyphe.com** for any of these: | Document | Contents | | ------------------------------------------- | -------------------------------------------------------------------------------------------------- | | Data processing agreement | Annexes I to III, the Standard Contractual Clauses and the UK Addendum | | Sub-processor list | Annex III of the agreement, including the register-data supplier used for business verification | | Penetration test schedule and latest report | Available to customers under NDA | | Certification status | The current status of the SOC 2 and ISO/IEC 27001 audits and the control documentation behind them | ## Related - [GDPR statement](https://www.zyphe.com/gdpr) and [Security and trust](https://www.zyphe.com/security) on zyphe.com - [Data Deletion](/docs/data-flows/data-deletion): the deletion sequence - [PII Access Control](/docs/pii-access-control): roles and webhook PII levels - [Data Sharing and Encryption](/docs/decentralized-identity/data-sharing-and-encryption): how access grants work - [Verification types](/docs/verification-types): every check, what it returns and what it is checked against - [Sandbox and go-live](/docs/guides/sandbox-and-go-live): the privacy items on the go-live checklist --- ## Reusable Credentials ## One click KYC Zyphe's decentralized KYC (Know Your Customer) is an innovative approach to the traditional KYC process, which involves collecting and verifying customer information to comply with legal and regulatory requirements. Here's a simplified explanation of how reusable credentials in a decentralized KYC system works: 1. **Initial Verification**: - When a user first interacts with a company that requires KYC verification, they undergo a standard verification process. This could involve submitting identification documents, proof of address, and other required information. 2. **Credential Issuance**: Once the user's information is verified, is encrypted, sharded and stored in a secure, decentralized manner, often on a blockchain or a distributed ledger, ensuring they are tamper-proof and owned by the user. 3. **Data Ownership and Control**: The user has control over their digital credentials. They can choose who to share their credentials with and can manage permissions through a simple interface. 4. **Reuse of Credentials**: - When the user interacts with a new company requiring KYC verification, they can share their previously verified credentials instead of going through the verification process all over again. 5. **Benefits**: - **Time-Saving**: Reusing credentials can significantly speed up the KYC process for users and companies. - **Cost Efficiency**: Companies save resources as they don't have to repeatedly conduct the same verification processes. - **Privacy Enhancement**: Users share only the necessary information, and the decentralized nature of the system can provide better data privacy and security. 6. **Interoperability**: - The decentralized KYC systems are often designed to be interoperable, allowing various companies and platforms to utilize the same set of reusable credentials, fostering a seamless user experience across different services. This setup creates an ecosystem where KYC processes become more user-centric, efficient, and privacy-preserving, with the ability to reuse verified credentials across multiple platforms and services. ## How it works When a user arrives at a company that requires KYC, Zyphe checks whether they already hold an eligible credential and, with the user's consent, shares it through an **access grant** instead of re-running verification. ```mermaid sequenceDiagram autonumber actor User participant CW as Company Website participant C as Company participant ZF as Zyphe frontend participant ZB as Zyphe backend participant DCS as Decentralized Storage CW-->>+User: share a link User->>+ZF: starts a Flow ZF->>+ZB: check for eligible documents ZB-->>+ZF: send list of eligible documents ZF-->>+User: ask the user User->>+ZF: unlock vault ZF->>+ZB: grant access to the company ZB-->>+C: send access grant C->>+ZB: request data using access grant ZB->>+DCS: request data DCS-->>+ZB: return data ZB-->>+C: return data ``` 1. **Redirect through company website**: The user starts on the dashboard of a company that needs to perform KYC, and is redirected to Zyphe to begin. 2. **Starts the onboarding flow**: The user lands on the platform and starts the onboarding flow. 3. **Check eligible documents**: The frontend asks the backend whether there are eligible documents for that flow. 4. **Return list of eligible documents**: The backend checks the user vault for eligible documents. :::info The check runs against a metadata table that holds only references and the minimum information needed for this check. The backend does not have access to any personal information. ::: 5. **Ask the user**: If eligible documents exist, the platform asks whether the user wants to reuse a previously generated credential or verify again. In sandbox, to test the first-time path again with the same email or `externalId`, delete the result together with its identity. See [Deleting sandbox results](/docs/guides/sandbox-mode#deleting-sandbox-results). 6. **Unlock vault**: To reuse a credential, the user unlocks the vault. This can use different authentication mechanisms, a passphrase, a Vault Access Key, or a passkey. Advanced users can run in BYOK mode where the private key is bound to a passkey on their device; traditional users rely on a managed key handled under a strict no-log paradigm. See [Data Sharing and Encryption](../decentralized-identity/data-sharing-and-encryption.md). 7. **Grant access**: An **access grant** is created. Under the hood it is a **proxy re-encryption key** that lets Zyphe (the proxy) transform ciphertext encrypted under the user's key into ciphertext that only the requesting company can decrypt. Zyphe never sees the plaintext. 8. **Send grant to the company**: The access grant is connected to the company dashboard. 9. **Request user data**: The company requests the user data through its dashboard on the Zyphe platform. 10. **Request data to DCS**: The system pulls the relevant data from decentralized storage, where it is securely stored. 11. **Return data from DCS**: The requested data is retrieved from the decentralized storage network. 12. **Display data in the company dashboard**: The retrieved data is returned to the company dashboard. --- ## Africa The following table lists supported identification documents for Africa, organized by country. ## Algeria (DZA) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :--------------------- | :------ | :------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2018 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Identification Card | | ALL | MedicalCard | SOCIAL\_SECURITY\_CARD | 2024 | Social Security Card | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Passport | ## Angola (AGO) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :---------------------------------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2011 | Carta de Condução (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Bilhete de Identidade de Cidadão Nacional (Identity Card of National Citizen) | | ALL | Passport | NATIONAL\_PASSPORT | 2000 | Passaporte / Passport | | ALL | Visa | VISA | 2024 | Visa | | ALL | TravelDocument | CONSULAR\_CARD | 2023 | Consular Card | ## Benin (BEN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :---------------------------------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2022 | Permis de Conduire (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Carte Nationale D'Identite (National I.D. Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Carte D'Identité Cedeao / ECOWAS Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Certificat D'Identification Personnelle (Personal Identification Certificate) | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passeport (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2021 | Passeport (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2024 | Passeport (Passport) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2023 | Carte de Resident (Residence Permit) | | ALL | TravelDocument | CONSULAR\_CARD | 2019 | Carte D'Identite Consulaire (Consular Card) | | ALL | TravelDocument | CONSULAR\_CARD | 2020 | Carte D'Identite Consulaire (Consular Card) | | ALL | TravelDocument | CONSULAR\_CARD | 2021 | Carte D'Identite Consulaire (Consular Card) | | ALL | TravelDocument | CONSULAR\_CARD | 2022 | Carte Consulaire / Consular Card | | ALL | TravelDocument | CONSULAR\_CARD | 2023 | Carte D'Identite Consulaire (Consular Card) | | ALL | TravelDocument | CONSULAR\_CARD | 2024 | Carte D'Identite Consulaire / Consular Card | ## Botswana (BWA) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :----------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2020 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | National Identity Card | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2023 | Permanent Residence Card | | ALL | Passport | NATIONAL\_PASSPORT | 2009 | National Passport | | ALL | Visa | VISA | 2022 | Visa | ## Burkina Faso (BFA) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :------------------------------------------------------------ | | ALL | DriversLicense | DRIVERS\_LICENSE | 2017 | Permis de Conduire (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2012 | Carte Nationale D'Identite Burkinabe (National Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2026 | Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Passeport (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Passeport (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2024 | Passport | | ALL | TravelDocument | CONSULAR\_CARD | 2020 | Carte Consulaire (Consular Card) | | ALL | TravelDocument | CONSULAR\_CARD | 2025 | Carte Consulaire / Consular Card | ## Burundi (BDI) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :---------------------------- | :------ | :---------------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2016 | Permis de Conduire (Driving License) | | ALL | IdentificationCard | REFUGEE\_IDENTIFICATION\_CARD | 2020 | Carte d'Identité Pour Réfugié (Refugee Identification Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2014 | Passeport (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Passeport (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2022 | Passeport (Passport) | ## Cameroon (CMR) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :---------------------------- | :------ | :-------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2009 | Permis de Conduire (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2020 | Permis de Conduire (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2008 | Carte Nationale D'Identite (National Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Carte Nationale D'Identite (National Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2025 | Carte Nationale D'Identite (Identity Card) | | ALL | IdentificationCard | REFUGEE\_IDENTIFICATION\_CARD | 2022 | Refugee Identification Card | | ALL | TravelDocument | CONSULAR\_CARD | 2021 | Consular Card | | ALL | TravelDocument | CONSULAR\_CARD | 2022 | Consulate Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Passeport (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2021 | Passeport (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Passeport (Passport) | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2020 | Carte D'Electeur (Voter's Card) | | ALL | TravelDocument | CONSULAR\_CARD | 2023 | Carte D'identite Consulaire (Consular Card) | | ALL | TravelDocument | CONSULAR\_CARD | 2024 | Consular Identity Card | | ALL | TravelDocument | CONSULAR\_CARD | 2025 | Consular Card | ## Cape Verde (CPV) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :---------------------------------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Permis de Conduire (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2012 | Bilhete de Identidade de Cidadão Nacional (Identity Card of National Citizen) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Cartão Nacional de Identificação (National Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2005 | Passaporte / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passaporte / Passport | | ALL | TravelDocument | CONSULAR\_CARD | 2020 | Cartão de Identificação (Consular Card) | ## Central African Republic (CAF) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :----------------- | :------ | :--------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2010 | Permis de Conduire (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2020 | Permis de Conduire (Driver's License) | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Passeport (Passport) | | ALL | TravelDocument | CONSULAR\_CARD | 2024 | Carte D'Identite Consulaire / Consular Identity Card | ## Comoros (COM) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :-------------------------------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Carte Nationale D'Identite (National Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Carte Nationale D'Identite (National Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Passeport (Passport) | | ALL | TravelDocument | CONSULAR\_CARD | 2021 | Carte Consulaire / Consular Card | | ALL | Visa | VISA | 2023 | Visa | ## Congo (COG) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :-------------------------- | :------ | :-------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2016 | Permis de Conduire (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2023 | Permis de Conduire / Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Carte Nationale D'Identite (National Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2024 | Identity Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2024 | Carte D'Electeur (Voter Identification Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Passeport Ordinaire / Ordinary Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2019 | Passeport (Passport) | | ALL | TravelDocument | CONSULAR\_CARD | 2024 | Carte Consulaire / Consular Card | ## Democratic Republic of the Congo (COD) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :--------------------------- | :------ | :--------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2017 | Permis de Conduire National (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2018 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2020 | Permis de Conduire / Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2021 | Permis de Conduire (Driving Licence) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2022 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2023 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2024 | Driving License | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2022 | Carte de Residence Pour Etrangers (Residence Permit) | | ALL | IdentificationCard | POLICE\_IDENTIFICATION\_CARD | 2019 | Police Identification Card | | ALL | Military | MILITARY\_CARD | 2020 | Carte d'Identite Militaire (Military Card) | | ALL | Permit | WORK\_PERMIT | 2023 | Carte de Travail Pour Etranger (Work Permit) | | ALL | Passport | NATIONAL\_PASSPORT | 2009 | Passeport (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Passeport (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2025 | Passeport / Passport | | ALL | TravelDocument | CONSULAR\_IDENTITY\_CARD | 2020 | Consular Identity Card | | ALL | TravelDocument | CONSULAR\_IDENTITY\_CARD | 2022 | Carte Consulaire / Consular Identity Card | | ALL | TravelDocument | CONSULAR\_IDENTITY\_CARD | 2023 | Carte Consulaire / Consular Card | | ALL | TravelDocument | CONSULAR\_IDENTITY\_CARD | 2024 | Carte Consulaire / Consular Card | | ALL | TravelDocument | CONSULAR\_IDENTITY\_CARD | 2025 | Carte Consulaire / Consular Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2010 | Carte D'Electeur (Voter's Card) | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2022 | Carte D'Electeur (Voter's Card) | ## Djibouti (DJI) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :--------- | :----------------- | :------ | :------------------- | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passeport (Passport) | ## Egypt (EGY) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :----------------------------- | :------ | :---------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2012 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2022 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2023 | Driving License | | ALL | DriversLicense | INTERNATIONAL\_DRIVING\_PERMIT | 2021 | International Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2000 | Identity Card | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2021 | Foreign Residence Card | | ALL | Passport | NATIONAL\_PASSPORT | 2008 | Passport | | ALL | Visa | VISA | 2017 | Visa | ## Equatorial Guinea (GNQ) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :---------------------------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Documento de Identidad Personal (Identity Card) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2017 | Permiso de Conducción / Driving License | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Pasaporte (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2020 | Pasaporte (Passport) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2024 | Permiso de Residencia (Residence Permit) | ## Eritrea (ERI) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :------------ | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Passport | ## Eswatini (SWZ) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2007 | Driver's License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2011 | National Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passport | ## Ethiopia (ETH) | State | Type of ID | Subtype of ID | Version | Description | | :----------- | :----------------- | :---------------------------- | :------ | :-------------------------------- | | ADDIS\_ABABA | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Addis Ababa City Resident ID Card | | ALL | DriversLicense | DRIVERS\_LICENSE | 2004 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2010 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2011 | Driving License | | ALL | IdentificationCard | DIGITAL\_IDENTIFICATION\_CARD | 2023 | Ethiopian Digital ID Card | | ALL | IdentificationCard | DIGITAL\_IDENTIFICATION\_CARD | 2024 | Ethiopian Digital ID Card | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2025 | Passport | | ALL | TravelDocument | CONSULAR\_CARD | 2020 | Consular Card | | ALL | Visa | VISA | 2024 | Visa | | ALL | Other | REFUGEE\_IDENTIFICATION\_CARD | 2022 | Refugee Identity Card | ## Gabon (GAB) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------------------------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2011 | Carte Nationale D'Identite (National Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Carte nationale d'identité (identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Carte D'Identite Consulaire (Consular Identity Card) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Residence Permit | | ALL | TravelDocument | CONSULAR\_CARD | 2024 | Carte D'Identite Consulaire / Consular Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2009 | Passeport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Passeport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2022 | Passeport / Passport | | ALL | Visa | VISA | 2014 | Visa | ## Ghana (GHA) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :------------------------------- | :------ | :------------------------------------------------ | | ALL | DriversLicense | DRIVERS\_LICENSE | 2008 | Driver License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2018 | Driver License | | ALL | DriversLicense | LEARNERS\_PERMIT | 2018 | Learner's Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2010 | National Identity Card | | ALL | IdentificationCard | ECOWAS | 2019 | ECOWAS Identity Card | | ALL | IdentificationCard | REFUGEE\_IDENTIFICATION\_CARD | 2024 | Refugee ID Card | | ALL | IdentificationCard | DIPLOMATIC\_IDENTIFICATION\_CARD | 2024 | Diplomatic Identification Card | | ALL | MedicalCard | MEDICAL\_CARD | 2015 | Medical Card | | ALL | MedicalCard | MEDICAL\_CARD | 2020 | Medical Card | | ALL | MedicalCard | VOTER\_MEDICAL\_CARD | 2016 | NHIS Membership Identification Card | | ALL | MedicalCard | SSNIT\_CARD | 2020 | Social Security and National Insurance Trust Card | | ALL | Passport | NATIONAL\_PASSPORT | 2007 | Passeport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Passeport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2025 | Passeport / Passport | | ALL | Visa | VISA | 2024 | Visa | | ALL | TravelDocument | CONSULAR\_CARD | 2022 | Carte Consulaire (Consular Card) | | ALL | TravelDocument | CONSULAR\_CARD | 2023 | Carte Consulaire (Consular Card) | | ALL | TravelDocument | CONSULAR\_CARD | 2024 | Carte D'Identite Consulaire (Consular Card) | | ALL | TravelDocument | CONSULAR\_CARD | 2025 | Carte Consulaire / Consular Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2010 | Voter Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2020 | Voter Card | ## Guinea (GIN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :-------------------------- | :------ | :--------------------------------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Carte Nationale d'Identite (National Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | ECOWAS Identity Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2020 | Voter Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2007 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2014 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Passport | | ALL | TravelDocument | CONSULAR\_CARD | 2022 | Carte D'identite Consulaire (Consular Identity Card) | | ALL | TravelDocument | CONSULAR\_CARD | 2023 | Carte D'Identite Consulaire (Consular Card) | | ALL | TravelDocument | CONSULAR\_CARD | 2024 | Carte D'Identite Consulaire (Consular Card) | | ALL | Visa | VISA | 2021 | Visa | ## Guinea-Bissau (GNB) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :-------------------------- | :------ | :-------------------------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Ecowas Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2021 | Passport | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2020 | Cartão de Eleitor (Voter Identification Card) | ## Ivory Coast (CIV) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2000 | Permis de Conduire (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2014 | Permis de Conduire (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2009 | Carte Nationale D'Identite (National Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Carte Nationale D'Identite (National Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Attestation D'Identite (Identity Card) | | ALL | TravelDocument | CONSULAR\_CARD | 2018 | Carte D'Identite Consulaire (Consular Identity Card) | | ALL | TravelDocument | CONSULAR\_CARD | 2020 | Carte Consulaire / Consular Card | | ALL | TravelDocument | CONSULAR\_CARD | 2021 | Carte D'Identite Consulaire (Consular Card) | | ALL | TravelDocument | CONSULAR\_CARD | 2022 | Carte D'Identite Consulaire / Consular Card | | ALL | TravelDocument | CONSULAR\_CARD | 2023 | Carte D'Identite Consulaire (Consular Card) | | ALL | TravelDocument | CONSULAR\_CARD | 2024 | Carte D'Identite Consulaire / Consular Card | | ALL | TravelDocument | CONSULAR\_CARD | 2025 | Carte Consulaire / Consular Card | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2018 | Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2024 | Resident Permit | | ALL | MedicalCard | MEDICAL\_CARD | 2023 | Carte D'Assure (Medical Card) | | ALL | MedicalCard | MEDICAL\_CARD | 2024 | Medical Card | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passeport / Passport | | ALL | Permit | WORK\_PERMIT | 2025 | Work Permit | ## Kenya (KEN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :------------------------------- | :------ | :-------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2019 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2020 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2024 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2011 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | National Identity Card | | ALL | IdentificationCard | REFUGEE\_IDENTIFICATION\_CARD | 2016 | Refugee ID Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2023 | National Identity Card | | ALL | IdentificationCard | DIPLOMATIC\_IDENTIFICATION\_CARD | 2023 | Diplomatic Identity Card | | ALL | IdentificationCard | POLICE\_IDENTIFICATION\_CARD | 2018 | Police Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2023 | Disability Identification Card | | ALL | MedicalCard | MEDICAL\_CARD | 2018 | Medical Card | | ALL | Passport | NATIONAL\_PASSPORT | 1997 | Passeport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2007 | Passeport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2008 | Passeport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Passeport / Passport | | ALL | Passport | TRAVEL\_DOCUMENT | 2024 | Titre de Voyage / Travel Document | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2021 | Foreigner Certificate | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2010 | Electors Card | | ALL | Military | MILITARY\_CARD | 2023 | Defence Forces Identity Card | | ALL | Military | MILITARY\_CARD | 2024 | National Youth Service ID Card | | ALL | Military | MILITARY\_CARD | 2025 | Veteran Identity Card | ## Lesotho (LSO) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2012 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2018 | National Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passeport / Passport | ## Liberia (LBR) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :------------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2010 | National Identification Card | | ALL | DriversLicense | DRIVERS\_LICENSE | 2022 | Driver’s License | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2020 | Passeport / Passport | | ALL | Permit | WORK\_PERMIT | 2024 | Work Permit | | ALL | TravelDocument | CONSULAR\_CARD | 2023 | Carte Consulaire / Consular Card | ## Libya (LBY) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :--------- | :------------------- | :------ | :------------------ | | ALL | Passport | NATIONAL\_PASSPORT | 2014 | Passport | | ALL | Passport | DIPLOMATIC\_PASSPORT | 2023 | Diplomatic Passport | ## Madagascar (MDG) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :----------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2018 | Permis de Conduire (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2021 | Permis de Conduire (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Kara Panondrom Pirenena (National Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Pasipaoro (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Pasipaoro (Passport) | ## Malawi (MWI) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :-------------------------- | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Passeport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2021 | Passeport / Passport | | ALL | DriversLicense | DRIVERS\_LICENSE | 2015 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2022 | Traffic Register Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Citizen Identification Card | ## Mali (MLI) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------------------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Carte D'Identite Cedeao (ECOWAS Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passeport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2025 | Passport | ## Mauritania (MRT) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :------------------------------------- | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Passeport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2021 | Passeport / Passport | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Carte D'Identification (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Carte D'Identification (Identity Card) | | ALL | ResidenceDocument | RESIDENCE\_CARD | 2023 | Residence Card | ## Mauritius (MUS) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------------ | :------ | :--------------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2013 | National Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2025 | National Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD\_FOR\_FOREIGNERS | 2022 | Identification Card for Foreigners | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Passeport / Passport | ## Morocco (MAR) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :-------------------------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2000 | Permis de Conduire (Driving License) | | ALL | DriversLicense | DRIVER\_LICENSE | 2001 | Permis de Conduire (Driving License) | | ALL | DriversLicense | DRIVER\_LICENSE | 2020 | Permis de Conduire (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2008 | Carte Nationale D'Identite (National Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Carte Nationale D'Identite (National Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2009 | Passeport / Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2023 | Residence Permit | ## Mozambique (MOZ) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :-------------------------- | :------ | :------------------------------------ | | ALL | DriversLicense | DRIVERS\_LICENSE | 2015 | Carta de Condução (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2021 | Carta de Condução (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Bilhete de Identidade (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Bilhete de Identidade (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Bilhete de Identidade (Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passaporte / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2020 | Passaporte / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2022 | Passport | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2010 | Cartão de Eleitor (Voter Card) | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2023 | Cartão de Eleitor (Voter Card) | | ALL | ResidenceDocument | ASYLUM\_SEEKER\_CARD | 2021 | Asylum Seeker Card | | ALL | TravelDocument | CONSULAR\_CARD | 2025 | Consular Card | | ALL | Visa | VISA | 2010 | Visto / Visa | ## Namibia (NAM) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :-------------------------- | :------ | :----------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2017 | Carta de Condução (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2022 | Permis de Conduire (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2006 | National Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2014 | Ordinary Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Ordinary Passport | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2014 | Voter Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2020 | Voter Card | ## Niger (NER) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :----------------- | :------ | :----------------------------------- | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passeport / Passport | | ALL | DriversLicense | DRIVER\_LICENSE | 2020 | Permis de Conduire (Driving License) | | ALL | TravelDocument | CONSULAR\_CARD | 2020 | Consular Card | | ALL | TravelDocument | CONSULAR\_CARD | 2024 | Carte Consulaire / Consular Card | ## Nigeria (NGA) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :------------------------------ | :------ | :-------------------------------------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2019 | National Driver's License | | ALL | DriversLicense | INTERNATIONAL\_DRIVERS\_LICENSE | 2022 | International Driving Permit | | ALL | DriversLicense | INTERNATIONAL\_DRIVERS\_LICENSE | 2024 | International Driver's License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 1995 | National Identification Number Slip (NINS) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 1996 | National Identification Number (NIN) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2003 | National Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2005 | National Identification Number Slip | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2008 | Identification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2010 | National Identification Number Slip (NINS) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2011 | National Identification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2013 | National Identification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | National Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2016 | National Identification Number (NIN) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2019 | National Identification Number Slip | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2022 | National Identification Number (NIN) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2023 | National Identification Number Slip | | ALL | IdentificationCard | REFUGEE\_IDENTIFICATION\_CARD | 2019 | Refugee Identity Card | | ALL | Military | MILITARY\_IDENTIFICATION\_CARD | 2023 | Military Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2019 | Passeport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2020 | Passeport / Passport | | ALL | VoterIdentification | VOTER\_IDENTIFICATION | 2014 | Voter's Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION | 2018 | Voter's Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION | 2020 | Cartão de Eleitor (Voter Identification Card) | | ALL | VoterIdentification | VOTER\_IDENTIFICATION | 2024 | Nigerian Voter's Card | | ALL | TaxIdentification | TAX\_IDENTIFICATION | 2015 | TIN (Taxpayer Identification Number) ID | | LAGOS | ResidenceDocument | RESIDENCE\_CARD | 2015 | Lagos State Resident Card | | LAGOS | ResidenceDocument | RESIDENCE\_CARD | 2020 | Lagos Residence Card | | ALL | TravelDocument | CONSULAR\_CARD | 2017 | Carte D'Identite Consulaire / Consular Identity Card | | ALL | TravelDocument | CONSULAR\_CARD | 2018 | Catre Consulaire Nigeria Au Togo / Consular Identification Card | | ALL | TravelDocument | CONSULAR\_CARD | 2020 | Consular Identity Card | | ALL | TravelDocument | CONSULAR\_CARD | 2019 | Consular Identity Card | | ALL | TravelDocument | CONSULAR\_CARD | 2021 | Consular Identity Card | | ALL | TravelDocument | CONSULAR\_CARD | 2023 | Consular Card | | ALL | TravelDocument | CONSULAR\_CARD | 2024 | Carte Consulaire Du Nigeria Au Mali / Consular Card | | ALL | TravelDocument | CONSULAR\_CARD | 2025 | Consular Identity Card | | ALL | Visa | VISA | 2024 | Visa | ## Republic of Chad (TCD) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :-------------------------- | :------ | :------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2017 | Permis de Conduire (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Carte Nationale D'Identite (Identity Card) | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2024 | Carte d'Electeur / Voter Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Passeport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2020 | Passeport / Passport | ## Rwanda (RWA) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :---------------------------- | :------ | :--------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2008 | Uruhushya Rwo Gutwara Ibinyabiziga (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Indangamuntu (National Identity Card) | | ALL | ResidenceDocument | RESIDENCE\_CARD | 2024 | Resident Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2019 | Pasiporo (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2020 | Passeport / Passport | | ALL | TravelDocument | LAISSEZ\_PASSER | 2023 | Laissez - Passer | | ALL | TravelDocument | REFUGEE\_TRAVEL\_DOCUMENT | 2024 | Refugee Travel Document | | ALL | IdentificationCard | REFUGEE\_IDENTIFICATION\_CARD | 2022 | Refugee Identity Card | | ALL | Visa | VISA | 2024 | Visa | ## Sao Tome and Principe (STP) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :--------- | :----------------- | :------ | :-------------------------------- | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passeport / Passport / Passaporte | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Passeport / Passport | ## Senegal (SEN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :-------------------------- | :------ | :-------------------------------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Carte Nationale D'Identite (National Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Carte D'Identite Cedeao (ECOWAS Identity Card) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2018 | Permis de Conduire (Driving License) | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2024 | Carte d'Electeur / Voter Identification Card | | ALL | TravelDocument | CONSULAR\_CARD | 2024 | Carte D'Identite Consulaire / Consular Card | | ALL | Passport | NATIONAL\_PASSPORT | 2014 | Passeport / Passport | ## Seychelles (SYC) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :----------------------------- | :------ | :--------------------- | | ALL | IdentificationCard | NATIONAL\_IDENTIFICATION\_CARD | 2010 | National Identity Card | | ALL | DriversLicense | DRIVERS\_LICENSE | 2016 | Driving Licence | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passeport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Passeport / Passport | ## Sierra Leone (SLE) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :--------------------- | :------ | :---------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2018 | Motor Driver's License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2023 | Motor Driver's License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | National Identity Card | | ALL | MedicalCard | SOCIAL\_SECURITY\_CARD | 2022 | Social Security Card | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passeport / Passport | | ALL | VoterIdentification | VOTER\_IDENTIFICATION | 2010 | Voter ID Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION | 2020 | Voter Registration Card | ## Somalia (SOM) | State | Type of ID | Subtype of ID | Version | Description | | :--------- | :------------------ | :------------------------------ | :------ | :-------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2015 | Driver License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2019 | Driver License | | ALL | DriversLicense | INTERNATIONAL\_DRIVERS\_LICENSE | 2023 | International Driver's License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Identity Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2023 | Voter Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2007 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Passport | | SOMALILAND | IdentificationCard | IDENTIFICATION\_CARD | 2024 | Somaliland National Identity Card | ## South Africa (ZAF) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :----------------------------- | :------ | :---------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2005 | Carta de Conducao (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 1996 | National Identity Card | | ALL | IdentificationCard | NATIONAL\_IDENTIFICATION\_CARD | 2015 | National Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2007 | Passeport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2009 | Passeport / Passport | | ALL | Passport | TRAVEL\_DOCUMENT | 2018 | Travel Document | | ALL | Visa | WORK\_VISA | 2010 | Zimbabwean Exemption Permit (ZEP) | ## South Sudan (SSD) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :---------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2023 | Driving Licence | | ALL | DriversLicense | DRIVERS\_LICENSE | 2024 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2014 | Nationality Certificate | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2024 | National ID Card | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Passport | | ALL | Visa | VISA | 2013 | Visa | ## Sudan (SDN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :------------------ | | ALL | DriversLicense | DRIVERS\_LICENSE | 2017 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Identification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2025 | Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Passport | ## Tanzania (TZA) | State | Type of ID | Subtype of ID | Version | Description | | :------- | :------------------ | :------------------------------- | :------ | :-------------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2017 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2014 | Citizen Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Citizen Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Citizen Identity Card | | ALL | IdentificationCard | POLICE\_IDENTIFICATION\_CARD | 2024 | Police Identity Card | | ALL | IdentificationCard | DIPLOMATIC\_IDENTIFICATION\_CARD | 2024 | Diplomatic Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2005 | Pasipoti (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Pasipoti (Passport) | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2015 | Kadi Ya Mpiga Kura (Voter's Card) | | ALL | MedicalCard | MEDICAL\_CARD | 2011 | Medical Card | | ALL | MedicalCard | MEDICAL\_CARD | 2013 | Membership Identity Card (National Health Insurance Fund) | | ALL | MedicalCard | MEDICAL\_CARD | 2019 | Medical Card | | ALL | Other | CABIN\_CREW\_CERTIFICATE | 2024 | Cabin Crew Certificate | | ZANZIBAR | DriversLicense | DRIVERS\_LICENSE | 2021 | Zanzibar Driver's License | | ZANZIBAR | IdentificationCard | IDENTIFICATION\_CARD | 2013 | Identification Card | ## The Gambia (GMB) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :-------------------- | :------ | :--------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2022 | Driver License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Carte D'Identite Cedeao (ECOWAS Identity Card) | | ALL | VoterIdentification | VOTER\_IDENTIFICATION | 2020 | Voter ID Card | | ALL | MedicalCard | HEALTH\_CARD | 2023 | Health Card | | ALL | Passport | NATIONAL\_PASSPORT | 2002 | Passeport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Passeport / Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2023 | Resident Permit - ''B'' Ecowas | ## Togo (TGO) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :-------------------------- | :------ | :-------------------------------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Carte Nationale D'Identite (National Identity Card) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2020 | Permis de Conduire (Driving License) | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2024 | Carte d'Electeur / Voter Identification Card | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2023 | Residence Permit | | ALL | TravelDocument | CONSULAR\_CARD | 2021 | Carte D'Identite Consulaire / Consular Card | | ALL | TravelDocument | CONSULAR\_CARD | 2022 | Carte D'Identite Consulaire (Consular Card) | | ALL | TravelDocument | CONSULAR\_CARD | 2023 | Carte D'Identite Consulaire (Consular Card) | | ALL | TravelDocument | CONSULAR\_CARD | 2025 | Carte Consulaire (Consular Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passeport / Passport | ## Trinidad and Tobago (TTO) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :--------------- | :------ | :-------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 1998 | Driver's Permit | ## Tunisia (TUN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :----------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2002 | Permis de Conduire (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2012 | Permis de Conduire (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2008 | Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2003 | Passport | ## Uganda (UGA) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :---------------------------- | :------ | :----------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2015 | Permis de Conduire / Driving Permit | | ALL | DriversLicense | DRIVERS\_LICENSE | 2018 | Permis de Conduire / Driving Permit | | ALL | DriversLicense | DRIVERS\_LICENSE | 2021 | Permis de Conduire / Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2014 | National ID Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2025 | National ID Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2020 | Voter Identification Card | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2024 | Residential Card | | ALL | Military | MILITARY\_CARD | 2022 | Uganda People's Defence Forces Card | | ALL | Other | REFUGEE\_IDENTIFICATION\_CARD | 2018 | Refugee Identity Card | | ALL | Other | REFUGEE\_IDENTIFICATION\_CARD | 2022 | Refugee Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2003 | Passeport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Passeport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Passeport / Passport | | ALL | Visa | VISA | 2024 | Visa | ## Zambia (ZMB) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :--------------------------------- | :------ | :-------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2020 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2024 | Driving License | | ALL | IdentificationCard | COMMON\_WEALTH\_REGISTRATION\_CARD | 2019 | Commonwealth Registration Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2019 | National Registration Card | | ALL | IdentificationCard | REFUGEE\_IDENTIFICATION\_CARD | 2024 | Refugee Identity Card | | ALL | MedicalCard | MEDICAL\_CARD | 2023 | The National Health Insurance Membership Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2020 | Voter's Card | | ALL | TravelDocument | CONSULAR\_CARD | 2024 | Diplomatic Permit | | ALL | Passport | NATIONAL\_PASSPORT | 2008 | Passeport / Passport | ## Zimbabwe (ZWE) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------ | :------ | :----------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2000 | Driver's License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2024 | Driving License | | ALL | DriversLicense | INTERNATIONAL\_DRIVERS\_LICENSE | 2022 | International Driver's License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2010 | National Registration Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2011 | National Registration Card | | ALL | Passport | NATIONAL\_PASSPORT | 2011 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2022 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2025 | Residence Permit | --- ## Asia The following tables list supported identification documents for Asia, organized by country. The tables for India and the Philippines are further divided by ID type or state. ## Afghanistan (AFG) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | National Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Diplomatic Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passport | ## Armenia (ARM) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------- | :------ | :----------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Permis de Conduire (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2014 | ID Card | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2021 | Travel Document / Passport | | ALL | ResidenceDocument | RESIDENCE\_CARD | 2010 | Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 2023 | Residence Card | | ALL | ResidenceDocument | TEMPORARY\_RESIDENCE\_CARD | 2024 | Temporary Residence Card | ## Azerbaijan (AZE) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :----------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Permis de Conduire (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2021 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2005 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2025 | Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 1998 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2023 | Permit for Temporary Residence | ## Bahrain (BHR) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2018 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2025 | Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2024 | Passport | | ALL | Passport | RESIDENCE\_DOCUMENT | 2010 | Residence Permit | | ALL | Passport | RESIDENCE\_DOCUMENT | 2021 | Residence Permit | ## Bangladesh (BGD) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :---------------------------- | :------ | :--------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2012 | Motor Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2017 | Professional Motor Driving License | | ALL | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE | 2024 | Non Professional E-Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2006 | National ID Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2016 | National ID Card | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2019 | Official Passport | | ALL | Visa | VISA | 2017 | Visa | ## Bhutan (BTN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Citizenship Card | | ALL | DriversLicense | DRIVERS\_LICENSE | 2022 | Driving License | | ALL | Passport | NATIONAL\_PASSPORT | 2006 | Passport | ## Brunei (BRN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :------------------------------ | | ALL | DriversLicense | DRIVERS\_LICENSE | 2015 | Lesen Memandu / Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2017 | Lesen Memandu / Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Identity Card | | ALL | Military | MILITARY\_CARD | 2020 | Armed Forces Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2008 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2019 | Certificate of Identity | ## Cambodia (KHM) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2010 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2019 | Driver's License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2022 | Driver's License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2021 | Passport | | ALL | Passport | TRAVEL\_DOCUMENT | 2023 | Travel Document | ## China (CHN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :---------------------------- | :------ | :---------------------------------------------------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2001 | Driving License of the People's Republic of China | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2004 | Domestic Identity Card | | ALL | Other | HUKOU\_CARD | 2010 | Hukou Card | | ALL | Passport | NATIONAL\_PASSPORT | 2007 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Passport | | ALL | Passport | DIPLOMATIC\_PASSPORT | 2023 | Diplomatic Passport | | ALL | Passport | SERVICE\_PASSPORT | 2022 | Service Passport | | ALL | Passport | SERVICE\_PASSPORT | 2024 | Passport for Public Affairs | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2017 | Residence Permit | | ALL | TravelDocument | HOME\_RETURN\_PERMIT | 2012 | Mainland Travel Permit | | ALL | Visa | VISA | 2002 | Visa | | ALL | Visa | VISA | 2024 | Visa | | MACAU | DriversLicense | DRIVER\_LICENSE | 2000 | Carta de condução de Macau (Driving License) | | MACAU | Passport | NATIONAL\_PASSPORT | 2009 | Macau Passport | | MACAU | Passport | NATIONAL\_PASSPORT | 2019 | Macau Passport | | MACAU | ResidenceDocument | PERMANENT\_RESIDENT\_IDENTITY | 2002 | Bilhete de Identidade de Residente Permanente de Macau (Macau Permanent Resident Identity Card) | | MACAU | ResidenceDocument | PERMANENT\_RESIDENT\_IDENTITY | 2013 | Bilhete de Identidade de Residente Permanente de Macau (Macau Permanent Resident Identity Card) | ## East Timor (TLS) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :----------------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Bilhete de Identidade (Citizen Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passaporte / Passport | ## Hong Kong (HKG) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :---------------- | :---------------------------- | :------ | :---------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2000 | Driving License | | ALL | Passport | NATIONAL\_PASSPORT | 2007 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2019 | Passport | | ALL | ResidenceDocument | PERMANENT\_RESIDENT\_IDENTITY | 2003 | Permanent Identity Card | | ALL | ResidenceDocument | PERMANENT\_RESIDENT\_IDENTITY | 2018 | Permanent Identity Card | ## India (IND) ### National IDs | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :------------------------------- | :------ | :----------------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2003 | Union of India Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2007 | Indian Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2011 | Indian Union Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2024 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2005 | Aadhaar Card (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Aadhaar Card (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Identification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Identification Card | | ALL | IdentificationCard | DIPLOMATIC\_IDENTIFICATION\_CARD | 2023 | Diplomatic Identity Card | | ALL | IdentificationCard | PENSIONERS\_IDENTITY\_CARD | 2024 | Pensioner's Identity Card | | ALL | IdentificationCard | AIRFORCE\_IDENTIFICATION\_CARD | 2023 | Retired Officers Identity Card | | ALL | IdentificationCard | AIRFORCE\_IDENTIFICATION\_CARD | 2024 | Air force Identification Card | | ALL | IdentificationCard | MASKED\_IDENTIFICATION\_CARD | 2005 | Masked Identification Card | | ALL | IdentificationCard | MASKED\_IDENTIFICATION\_CARD | 2015 | Masked Identification Card | | ALL | MedicalCard | MEDICAL\_CARD | 2020 | Medical Card | | ALL | MedicalCard | MEDICAL\_CARD | 2024 | Medical Card | | ALL | Military | MILITARY\_CARD | 2020 | Retired Officer's Identity Card | | ALL | Military | MILITARY\_CARD | 2021 | Indian Armed Forces Identity Card | | ALL | Military | PENSIONERS\_IDENTITY\_CARD | 2020 | Pensioner's Identity Card | | ALL | Military | PENSIONERS\_IDENTITY\_CARD | 2021 | Military Pensioner's Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2005 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2019 | Passport | | ALL | TaxIdentification | TAX\_DEPARTMENT | 2000 | Tax Identification Card | | ALL | TaxIdentification | TAX\_DEPARTMENT | 2010 | Tax Identification Card | | ALL | TaxIdentification | TAX\_DEPARTMENT | 2015 | Tax Identification Card | | ALL | TaxIdentification | TAX\_DEPARTMENT | 2019 | Tax Identification Card | | ALL | TaxIdentification | TAX\_DEPARTMENT | 2020 | Tax Identification Card | | ALL | Visa | VISA | 2000 | Visa | | ALL | Visa | VISA | 2001 | Visa | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2000 | Elector Photo Identity Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2009 | Voter Identification Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2010 | Election Commission of India Identity Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2015 | Voter Identification Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2022 | Voter Identification Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2023 | Voter Identification Card | ### Andaman and Nicobar | State | Type of ID | Subtype of ID | Version | Description | | :-------------------- | :------------- | :--------------- | :------ | :---------------------------------- | | ANDAMAN\_AND\_NICOBAR | DriversLicense | DRIVERS\_LICENSE | 2024 | Andaman and Nicobar Driving License | ### Andhra Pradesh | State | Type of ID | Subtype of ID | Version | Description | | :-------------- | :------------- | :--------------- | :------ | :-------------------------------------------- | | ANDHRA\_PRADESH | DriversLicense | DRIVERS\_LICENSE | 2010 | Andhra Pradesh - Indian Union Driving License | | ANDHRA\_PRADESH | DriversLicense | DRIVERS\_LICENSE | 2011 | Andhra Pradesh - Indian Union Driving License | | ANDHRA\_PRADESH | DriversLicense | DRIVERS\_LICENSE | 2020 | Andhra Pradesh - Indian Union Driving License | | ANDHRA\_PRADESH | DriversLicense | DRIVERS\_LICENSE | 2021 | Andhra Pradesh - Indian Union Driving License | | ANDHRA\_PRADESH | DriversLicense | DRIVERS\_LICENSE | 2024 | Andhra Pradesh - Indian Union Driving License | ### Arunachal Pradesh | State | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------- | :--------------- | :------ | :-------------------------------- | | ARUNACHAL\_PRADESH | DriversLicense | DRIVERS\_LICENSE | 2020 | Arunachal Pradesh Driving License | | ARUNACHAL\_PRADESH | DriversLicense | DRIVERS\_LICENSE | 2023 | Arunachal Pradesh Driving License | ### Assam | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :--------------- | :------ | :------------------------------------------------- | | ASSAM | DriversLicense | DRIVERS\_LICENSE | 2010 | Government of Assam - Indian Union Driving License | | ASSAM | DriversLicense | DRIVERS\_LICENSE | 2021 | Assam Driving License | | ASSAM | DriversLicense | DRIVERS\_LICENSE | 2022 | Assam Driving License | ### Bihar | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :--------------- | :------ | :------------------------------------------------- | | BIHAR | DriversLicense | DRIVERS\_LICENSE | 2016 | Government of Bihar - Indian Driving License | | BIHAR | DriversLicense | DRIVERS\_LICENSE | 2022 | Indian Union Driving License - Government of Bihar | ### Chandigarh | State | Type of ID | Subtype of ID | Version | Description | | :--------- | :------------- | :--------------- | :------ | :--------------------------------- | | CHANDIGARH | DriversLicense | DRIVERS\_LICENSE | 2008 | Driving License - Chandigarh State | ### Chhattisgarh | State | Type of ID | Subtype of ID | Version | Description | | :----------- | :------------- | :--------------- | :------ | :-------------------------------------------------------- | | CHHATTISGARH | DriversLicense | DRIVERS\_LICENSE | 2008 | Indian Union Driving License - Chhattisgarh State | | CHHATTISGARH | DriversLicense | DRIVERS\_LICENSE | 2009 | Indian Union Driving License - Government of Chhattisgarh | | CHHATTISGARH | DriversLicense | DRIVERS\_LICENSE | 2023 | Chhattisgarh Driving License | ### Dadra and Nagar Haveli | State | Type of ID | Subtype of ID | Version | Description | | :------------------------ | :------------- | :--------------- | :------ | :------------------------------------- | | DADRA\_AND\_NAGAR\_HAVELI | DriversLicense | DRIVERS\_LICENSE | 2016 | Dadra and Nagar Haveli Driving License | ### Delhi | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :--------------- | :------ | :---------------------------------------------------------------- | | DELHI | DriversLicense | DRIVERS\_LICENSE | 2002 | Delhi Driving License | | DELHI | DriversLicense | DRIVERS\_LICENSE | 2003 | Indian Union Driving License - Transport Department GNCT of Delhi | | DELHI | DriversLicense | DRIVERS\_LICENSE | 2009 | Driving License - Transport Department Government of NCT of Delhi | | DELHI | DriversLicense | DRIVERS\_LICENSE | 2019 | Driving License - Transport Department Government of NCT of Delhi | | DELHI | DriversLicense | DRIVERS\_LICENSE | 2021 | Indian Union Driving License - Transport Department GNCT of Delhi | ### Goa | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :--------------- | :------ | :--------------------------------------- | | GOA | DriversLicense | DRIVERS\_LICENSE | 2017 | Indian Union Driving License - Goa State | ### Gujarat | State | Type of ID | Subtype of ID | Version | Description | | :------ | :------------- | :--------------- | :------ | :--------------------------------------------------- | | GUJARAT | DriversLicense | DRIVERS\_LICENSE | 2005 | Union of India Driving License - Gujarat State | | GUJARAT | DriversLicense | DRIVERS\_LICENSE | 2008 | Gujarat Driving License | | GUJARAT | DriversLicense | DRIVERS\_LICENSE | 2014 | Gujarat State Driving License | | GUJARAT | DriversLicense | DRIVERS\_LICENSE | 2020 | Indian Union Driving License - Government of Gujarat | ### Gurgaon | State | Type of ID | Subtype of ID | Version | Description | | :------ | :------------- | :--------------- | :------ | :---------------------- | | GURGAON | DriversLicense | DRIVERS\_LICENSE | 2017 | Gurgaon Driving License | ### Haryana | State | Type of ID | Subtype of ID | Version | Description | | :------ | :------------- | :--------------- | :------ | :--------------------------------------------- | | HARYANA | DriversLicense | DRIVERS\_LICENSE | 2006 | Indian Driving License - Government of Haryana | | HARYANA | DriversLicense | DRIVERS\_LICENSE | 2016 | Haryana Driving License | ### Himachal Pradesh | State | Type of ID | Subtype of ID | Version | Description | | :---------------- | :------------- | :--------------- | :------ | :------------------------------------------------------------ | | HIMACHAL\_PRADESH | DriversLicense | DRIVERS\_LICENSE | 2013 | Indian Union Driving License - Government of Himachal Pradesh | | HIMACHAL\_PRADESH | DriversLicense | DRIVERS\_LICENSE | 2024 | Himachal Pradesh Driving License | ### Jammu and Kashmir | State | Type of ID | Subtype of ID | Version | Description | | :------------------ | :------------- | :--------------- | :------ | :----------------------------------------------------------- | | JAMMU\_AND\_KASHMIR | DriversLicense | DRIVERS\_LICENSE | 2010 | Indian Union Driving License - Government of Jammu & Kashmir | | JAMMU\_AND\_KASHMIR | DriversLicense | DRIVERS\_LICENSE | 2014 | Indian Union Driving License - Government of Jammu & Kashmir | | JAMMU\_AND\_KASHMIR | DriversLicense | DRIVERS\_LICENSE | 2024 | Jammu and Kashmir Driving License | ### Jharkhand | State | Type of ID | Subtype of ID | Version | Description | | :-------- | :------------- | :--------------- | :------ | :--------------------------------------------- | | JHARKHAND | DriversLicense | DRIVERS\_LICENSE | 2014 | Indian Union Driving License - Jharkhand State | | JHARKHAND | DriversLicense | DRIVERS\_LICENSE | 2017 | Indian Union Driving License - Jharkhand State | ### Karnataka | State | Type of ID | Subtype of ID | Version | Description | | :-------- | :------------- | :--------------- | :------ | :--------------------------------------------------- | | KARNATAKA | DriversLicense | DRIVERS\_LICENSE | 2005 | Indian Union Motor Driving License - Karnataka State | | KARNATAKA | DriversLicense | DRIVERS\_LICENSE | 2010 | Driving License - Karnataka State | ### Kerala | State | Type of ID | Subtype of ID | Version | Description | | :----- | :------------- | :--------------- | :------ | :------------------------------------------ | | KERALA | DriversLicense | DRIVERS\_LICENSE | 2016 | Indian Union Driving License - Kerala State | | KERALA | DriversLicense | DRIVERS\_LICENSE | 2018 | Kerala Driving License | | KERALA | DriversLicense | DRIVERS\_LICENSE | 2019 | Indian Union Driving License - Kerala State | ### Madhya Pradesh | State | Type of ID | Subtype of ID | Version | Description | | :-------------- | :------------- | :--------------- | :------ | :----------------------------- | | MADHYA\_PRADESH | DriversLicense | DRIVERS\_LICENSE | 2020 | Madhya Pradesh Driving License | ### Maharashtra | State | Type of ID | Subtype of ID | Version | Description | | :---------- | :----------------- | :------------------------- | :------ | :----------------------------------------------------------- | | MAHARASHTRA | DriversLicense | DRIVER\_LICENSE | 2000 | Maharashtra State Motor Driving License - The Union of India | | MAHARASHTRA | DriversLicense | DRIVER\_LICENSE | 2005 | Maharashtra Driving License | | MAHARASHTRA | DriversLicense | DRIVER\_LICENSE | 2023 | Maharashtra Driving License | | MAHARASHTRA | IdentificationCard | PENSIONERS\_IDENTITY\_CARD | 2024 | Maharashtra Pensioner's Identity Card | ### Manipur | State | Type of ID | Subtype of ID | Version | Description | | :------ | :------------- | :--------------- | :------ | :--------------------------------------------------- | | MANIPUR | DriversLicense | DRIVERS\_LICENSE | 2019 | Indian Union Driving License - Government of Manipur | ### Mizoram | State | Type of ID | Subtype of ID | Version | Description | | :------ | :------------- | :--------------- | :------ | :---------------------- | | MIZORAM | DriversLicense | DRIVERS\_LICENSE | 2022 | Mizoram Driving License | ### Nagaland | State | Type of ID | Subtype of ID | Version | Description | | :------- | :------------- | :--------------- | :------ | :----------------------- | | NAGALAND | DriversLicense | DRIVERS\_LICENSE | 2018 | Nagaland Driving License | | NAGALAND | DriversLicense | DRIVERS\_LICENSE | 2020 | Nagaland Driving License | ### Odisha | State | Type of ID | Subtype of ID | Version | Description | | :----- | :------------- | :--------------- | :------ | :------------------------------------------ | | ODISHA | DriversLicense | DRIVERS\_LICENSE | 2019 | Indian Union Driving License - Odisha State | | ODISHA | DriversLicense | DRIVERS\_LICENSE | 2020 | Indian Union Driving License - Odisha State | ### Punjab | State | Type of ID | Subtype of ID | Version | Description | | :----- | :------------- | :--------------- | :------ | :------------------------------------------ | | PUNJAB | DriversLicense | DRIVERS\_LICENSE | 2000 | Indian Union Driving License - Punjab State | | PUNJAB | DriversLicense | DRIVERS\_LICENSE | 2021 | Indian Union Driving License - Punjab State | | PUNJAB | DriversLicense | DRIVERS\_LICENSE | 2023 | Punjab Driving License | | PUNJAB | DriversLicense | DRIVERS\_LICENSE | 2024 | Punjab Driving License | ### Rajasthan | State | Type of ID | Subtype of ID | Version | Description | | :-------- | :------------- | :--------------- | :------ | :---------------------------------------- | | RAJASTHAN | DriversLicense | DRIVERS\_LICENSE | 2012 | Driving License - Government of Rajasthan | | RAJASTHAN | DriversLicense | DRIVERS\_LICENSE | 2015 | Driving License - Government of Rajasthan | | RAJASTHAN | DriversLicense | DRIVERS\_LICENSE | 2024 | Rajasthan International Driving Permit | ### Sikkim | State | Type of ID | Subtype of ID | Version | Description | | :----- | :------------- | :--------------- | :------ | :--------------------- | | SIKKIM | DriversLicense | DRIVERS\_LICENSE | 2020 | Sikkim Driving License | | SIKKIM | DriversLicense | DRIVERS\_LICENSE | 2021 | Sikkim Driving License | ### Tamil Nadu | State | Type of ID | Subtype of ID | Version | Description | | :---------- | :------------- | :--------------- | :------ | :------------------------------------------------------ | | TAMIL\_NADU | DriversLicense | DRIVERS\_LICENSE | 2000 | India Driving License - Tamil Nadu | | TAMIL\_NADU | DriversLicense | DRIVERS\_LICENSE | 2003 | Union of India Driving License - Tamil Nadu | | TAMIL\_NADU | DriversLicense | DRIVERS\_LICENSE | 2005 | India Driving License - Tamil Nadu | | TAMIL\_NADU | DriversLicense | DRIVERS\_LICENSE | 2020 | Indian Driving License - Tamil Nadu | | TAMIL\_NADU | DriversLicense | DRIVERS\_LICENSE | 2023 | Indian Union Driving License - Government of Tamil Nadu | ### Telangana | State | Type of ID | Subtype of ID | Version | Description | | :-------- | :----------------- | :------------------------------ | :------ | :----------------------------------------------------------------- | | TELANGANA | DriversLicense | CERTIFICATE\_OF\_TRANSPORTATION | 2005 | Certificate of Registration - Telangana State Transport Department | | TELANGANA | DriversLicense | DRIVERS\_LICENSE | 2014 | Indian Union Driving License - Telangana State | | TELANGANA | DriversLicense | DRIVERS\_LICENSE | 2021 | Indian Union Driving License - Telangana State | | TELANGANA | DriversLicense | DRIVERS\_LICENSE | 2022 | Telangana Driving License | | TELANGANA | DriversLicense | INTERNATIONAL\_DRIVING\_PERMIT | 2020 | Telangana International Driving Permit | | TELANGANA | IdentificationCard | POLICE\_IDENTIFATION\_CARD | 2020 | Telangana Police Identification Card | ### Tripura | State | Type of ID | Subtype of ID | Version | Description | | :------ | :------------- | :--------------- | :------ | :---------------------- | | TRIPURA | DriversLicense | DRIVERS\_LICENSE | 2020 | Tripura Driving License | | TRIPURA | DriversLicense | DRIVERS\_LICENSE | 2024 | Tripura Driving License | ### Uttarakhand | State | Type of ID | Subtype of ID | Version | Description | | :---------- | :------------- | :--------------- | :------ | :--------------------------------------------------------- | | UTTARAKHAND | DriversLicense | DRIVERS\_LICENSE | 2013 | Indian Union Driving License - Government of Uttarakhand | | UTTARAKHAND | DriversLicense | DRIVERS\_LICENSE | 2016 | Union of India Driving License - Government of Uttarakhand | ### Uttar Pradesh | State | Type of ID | Subtype of ID | Version | Description | | :------------- | :------------- | :--------------- | :------ | :------------------------------------------- | | UTTAR\_PRADESH | DriversLicense | DRIVERS\_LICENSE | 2019 | Indian Union Driving License - Uttar Pradesh | | UTTAR\_PRADESH | DriversLicense | DRIVERS\_LICENSE | 2020 | Uttar Pradesh Driving License | ### West Bengal | State | Type of ID | Subtype of ID | Version | Description | | :----------- | :------------- | :--------------- | :------ | :------------------------------------------------------------- | | WEST\_BENGAL | DriversLicense | DRIVERS\_LICENSE | 2000 | West Bengal Driving License | | WEST\_BENGAL | DriversLicense | DRIVERS\_LICENSE | 2002 | West Bengal Driving License | | WEST\_BENGAL | DriversLicense | DRIVERS\_LICENSE | 2003 | West Bengal Driving License | | WEST\_BENGAL | DriversLicense | DRIVERS\_LICENSE | 2006 | Indian Union Driving License - West Bengal State | | WEST\_BENGAL | DriversLicense | DRIVERS\_LICENSE | 2007 | West Bengal Driving License | | WEST\_BENGAL | DriversLicense | DRIVERS\_LICENSE | 2008 | Indian Union Driving License - Government of West Bengal State | | WEST\_BENGAL | DriversLicense | DRIVERS\_LICENSE | 2012 | Indian Union Driving License - West Bengal State | | WEST\_BENGAL | DriversLicense | DRIVERS\_LICENSE | 2013 | Indian Union Driving License - Government of West Bengal State | | WEST\_BENGAL | DriversLicense | DRIVERS\_LICENSE | 2014 | Indian Union Driving License - Government of West Bengal State | | WEST\_BENGAL | DriversLicense | DRIVERS\_LICENSE | 2015 | Indian Union Driving License - West Bengal State | | WEST\_BENGAL | DriversLicense | DRIVERS\_LICENSE | 2018 | West Bengal Driving License | | WEST\_BENGAL | DriversLicense | DRIVERS\_LICENSE | 2019 | West Bengal Driving License | | WEST\_BENGAL | DriversLicense | DRIVERS\_LICENSE | 2020 | Indian Union Driving License - Government of West Bengal State | | WEST\_BENGAL | DriversLicense | DRIVERS\_LICENSE | 2023 | West Bengal Driving License | | WEST\_BENGAL | DriversLicense | DRIVERS\_LICENSE | 2024 | West Bengal Driving License | | WEST\_BENGAL | DriversLicense | DRIVERS\_LICENSE | 2026 | West Bengal Driving License | ## Indonesia (IDN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :----------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2000 | Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2019 | Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2023 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2000 | Kartu Tanda Penduduk (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Kartu Identitas Anak (Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Paspor / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Paspor / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2022 | Paspor / Passport | | ALL | Passport | DIPLOMATIC\_PASSPORT | 2024 | Diplomatic Passport | ## Iran (IRN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :-------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2010 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2012 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2024 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2011 | Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2007 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2011 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2014 | Passport | | ALL | Visa | VISA | 2018 | Visa | ## Iraq (IRQ) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :-------------------------- | :------ | :------------------------ | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Identification Card | | ALL | DriversLicense | DRIVERS\_LICENSE | 2023 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2025 | Driving License | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2025 | Voter Identification Card | | ALL | Military | MILITARY\_CARD | 2026 | Military Card | | ALL | Passport | NATIONAL\_PASSPORT | 2011 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Passport | ## Israel (ISR) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :---------------------------------- | :------ | :-------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2009 | Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2018 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2000 | Domestic Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2013 | Domestic Identity Card | | ALL | Military | MILITARY\_CARD | 2024 | Military Card | | ALL | Passport | NATIONAL\_PASSPORT | 2011 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Passport | | ALL | TravelDocument | CONSULAR\_CARD | 2024 | Consular Card | | ALL | TravelDocument | TEMPORARY\_IMMIGRATION\_CERTIFICATE | 2010 | Temporary Immigration Certificate | ## Japan (JPN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :---------------------------------------- | :------ | :------------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2000 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2006 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2016 | Residence Card | | ALL | ResidenceDocument | SPECIAL\_PERMANENT\_RESIDENT\_CERTIFICATE | 2024 | Special Permanent Resident Certificate | | ALL | Visa | VISA | 2000 | Visa | | ALL | Visa | VISA | 2001 | Visa | | ALL | Visa | VISA | 2002 | Visa | | ALL | Visa | VISA | 2024 | Visa | ## Jordan (JOR) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :----------------------------- | :------ | :--------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 1996 | Driving License | | ALL | DriversLicense | INTERNATIONAL\_DRIVING\_PERMIT | 2020 | International Driving Permit | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2012 | ID Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2025 | Identification Card | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2025 | Residence Permit | | ALL | Passport | NATIONAL\_PASSPORT | 2008 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passport | | ALL | Military | MILITARY\_CARD | 2022 | Military Card | | ALL | Military | MILITARY\_CARD | 2023 | Military Card | | ALL | Military | MILITARY\_CARD | 2024 | Military Card | | ALL | Other | INVESTOR\_CARD | 2020 | Investor Card | ## Kazakhstan (KAZ) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :------------------ | | ALL | DriversLicense | DRIVERS\_LICENSE | 2005 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2016 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2008 | Identification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2009 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2009 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2021 | Passport | ## Kuwait (KWT) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2004 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2014 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2011 | Civil ID Card | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2019 | Civil ID Card | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2022 | Residence Permit | ## Kyrgyzstan (KGZ) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :---------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2019 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2020 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2021 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2005 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2025 | Identity Card | | ALL | Passport | DIPLOMATIC\_PASSPORT | 2021 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2011 | National Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2021 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2025 | Passport | ## Laos (LAO) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :------------------ | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passport | ## Lebanon (LBN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------ | :------ | :------------------------------------------ | | ALL | DriversLicense | DRIVERS\_LICENSE | 2010 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2018 | Permis de Conduire (Driving License) | | ALL | DriversLicense | INTERNATIONAL\_DRIVERS\_LICENSE | 2020 | International Driving Permit | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Identity Card | | ALL | IdentificationCard | REFUGEE\_IDENTIFICATION\_CARD | 2025 | Refugee Identity Card | | ALL | Military | MILITARY\_DRIVERS\_LICENSE | 2017 | Military Driver License | | ALL | Military | MILITARY\_IDENTIFICATION\_CARD | 2025 | Military Identification Card | | ALL | TravelDocument | CONSULAR\_CARD | 2021 | Carte D'Identite Consulaire / Consular Card | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Passeport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passeport / Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2023 | Residence Permit | ## Malaysia (MYS) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :--------------------------------- | :------ | :------------------------------------------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2000 | Driving License | | ALL | DriversLicense | LEARNERS\_PERMIT | 2000 | Lesen Belajar Memandu Malaysia (Malaysian Learner's Driving License) | | ALL | DriversLicense | DRIVER\_LICENSE | 2025 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2012 | Identity Card | | ALL | IdentificationCard | DIPLOMATIC\_IDENTIFICATION\_CARD | 2024 | Diplomatic Identification Card | | ALL | Military | MILITARY\_CARD | 2020 | Military Card | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Residence Pass - Talent | | ALL | IdentificationCard | POLICE\_IDENTIFICATION\_CARD | 2020 | Police Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2008 | Pasport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Pasport / Passport | | ALL | Visa | VISA | 2022 | Multiple Entry Visa | | ALL | Permit | WORK\_PERMIT | 2023 | Employment Pass | | ALL | ResidenceDocument | STUDENT\_PASS | 2020 | Student Pass | | ALL | Other | PROFESSIONAL\_IDENTIFICATION\_CARD | 2020 | Malaysian Vocational License | ## Maldives (MDV) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | National Identity Card | | ALL | DriversLicense | DRIVERS\_LICENSE | 2018 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2023 | Driving License | | ALL | Permit | WORK\_PERMIT | 2020 | Work Permit | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passport | ## Mongolia (MNG) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :-------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2014 | Mongolian Driver's License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2022 | Driver's License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2013 | Citizen Identity Card of Mongolia | | ALL | Passport | NATIONAL\_PASSPORT | 2007 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Passport | ## Myanmar (MMR) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :----------------- | :------ | :-------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2006 | Driving License | | ALL | Passport | NATIONAL\_PASSPORT | 2014 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Passport | | ALL | Visa | VISA | 2014 | Visa | ## Nepal (NPL) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :----------------------------- | :------ | :--------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2007 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2015 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2021 | Driving License | | ALL | DriversLicense | PROBATIONARY\_DRIVERS\_LICENSE | 2022 | Probationary Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2023 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2018 | National Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2024 | National Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2022 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2010 | Citizenship Certificate | ## Oman (OMN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :---------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2015 | Vehicle Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2006 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2025 | Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2014 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2010 | Resident Card | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2025 | Residence Permit | ## Pakistan (PAK) | State | Type of ID | Subtype of ID | Version | Description | | :------------------------ | :----------------- | :------------------------------ | :------ | :----------------------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2002 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2012 | National Identity Card | | ALL | DriversLicense | DRIVERS\_LICENSE | 2020 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2021 | National Driving Permit | | ALL | DriversLicense | INTERNATIONAL\_DRIVING\_PERMIT | 2022 | International Driving Permit | | ALL | DriversLicense | INTERNATIONAL\_DRIVING\_PERMIT | 2023 | International Driving Permit | | ALL | DriversLicense | INTERNATIONAL\_DRIVING\_PERMIT | 2024 | International Driving Permit | | ALL | DriversLicense | INTERNATIONAL\_DRIVING\_PERMIT | 2025 | International Driving Permit | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Passport | | ALL | TravelDocument | TRAVEL\_IDENTIFICATION\_CARD | 2014 | National Identity Card Overseas Pakistanis | | ALL | Other | REFUGEE\_IDENTIFICATION\_CARD | 2024 | Refugee Identity Card | | AZAD\_JAMMU\_AND\_KASHMIR | DriversLicense | DRIVERS\_LICENSE | 2023 | Azad Jammu & Kashmir Driving License | | BALOCHISTAN | DriversLicense | DRIVERS\_LICENSE | 2024 | Balochistan Driver License | | ISLAMABAD | DriversLicense | DRIVERS\_LICENSE | 2015 | Islamabad Driving License | | ISLAMABAD | DriversLicense | DRIVERS\_LICENSE | 2020 | Islamabad Driving License / Permit | | KHYBER\_PAKHTUNKHWA | DriversLicense | DRIVERS\_LICENSE | 2024 | Khyber Pakhtunkhwa Driver's License | | KHYBER\_PAKHTUNKHWA | DriversLicense | INTERNATIONAL\_DRIVERS\_LICENSE | 2021 | International Driving License | | KHYBER\_PAKHTUNKHWA | DriversLicense | DRIVERS\_LICENSE | 2023 | Khyber Pakhtunkhwa Driver's License | | PUNJAB | DriversLicense | DRIVERS\_LICENSE | 2007 | Punjab Driving License | | SINDH | DriversLicense | DRIVERS\_LICENSE | 2006 | Sindh Driving License | | SINDH | DriversLicense | DRIVERS\_LICENSE | 2016 | Sindh Driving License | | SINDH | DriversLicense | LEARNERS\_PERMIT | 2024 | Sindh Driving License | ## Palestine (PSE) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :-------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2010 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2011 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Identity Card | | ALL | DriversLicense | DRIVERS\_LICENSE | 2010 | Driving License | | ALL | Passport | NATIONAL\_PASSPORT | 2009 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Passport | ## Philippines (PHL) ### National IDs | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :-------------------------------------- | :------ | :--------------------------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2000 | Non-Professional Driver's License | | ALL | DriversLicense | DRIVER\_LICENSE | 2017 | Non-Professional Driver's License | | ALL | DriversLicense | DRIVER\_LICENSE | 2023 | Driver's License | | ALL | IdentificationCard | CITIZENCARD | 2021 | Philippine Identification Card | | ALL | IdentificationCard | DIPLOMATIC\_IDENTIFICATION\_CARD | 2025 | Diplomatic Identification Card | | ALL | IdentificationCard | EPHIL\_CARD | 2023 | Philippine Identification | | ALL | IdentificationCard | EPHIL\_CARD\_PDF | 2023 | Ephil Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Philippine Identification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Philippine Identification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2022 | Philippine Identification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Philippine National ID | | ALL | IdentificationCard | POLICE\_CLEARANCE\_IDENTIFICATION\_CARD | 2011 | Police Clearance ID Card | | ALL | IdentificationCard | POLICE\_CLEARANCE\_IDENTIFICATION\_CARD | 2012 | Online Police Clearance Card | | ALL | IdentificationCard | POLICE\_CLEARANCE\_IDENTIFICATION\_CARD | 2013 | Police Clearance Identification Card | | ALL | IdentificationCard | POLICE\_CLEARANCE\_IDENTIFICATION\_CARD | 2014 | Police Clearance Card | | ALL | IdentificationCard | POLICE\_CLEARANCE\_IDENTIFICATION\_CARD | 2017 | Caloocan City Police Clearance Identification Card | | ALL | IdentificationCard | POLICE\_CLEARANCE\_IDENTIFICATION\_CARD | 2019 | Police Clearance Data Card | | ALL | IdentificationCard | POLICE\_CLEARANCE\_IDENTIFICATION\_CARD | 2020 | Police Identification Card | | ALL | IdentificationCard | POLICE\_CLEARANCE\_IDENTIFICATION\_CARD | 2021 | Valenzuela City Police Clearance Identification Card | | ALL | IdentificationCard | POLICE\_CLEARANCE\_IDENTIFICATION\_CARD | 2022 | Manila City Clearance Data Card | | ALL | IdentificationCard | POLICE\_CLEARANCE\_IDENTIFICATION\_CARD | 2023 | Cebu City Police Clearance Identification Card | | ALL | IdentificationCard | POLICE\_CLEARANCE\_IDENTIFICATION\_CARD | 2024 | Police Clearance Identity Card | | ALL | IdentificationCard | POLICE\_CLEARANCE\_IDENTIFICATION\_CARD | 2025 | Police Clearance Identity Card | | ALL | IdentificationCard | POLICE\_IDENTIFICATION\_CARD | 2022 | Makati City Police Clearance Identification Card | | ALL | IdentificationCard | POLICE\_IDENTIFICATION\_CARD | 2023 | Police Identity Card | | ALL | IdentificationCard | POLICE\_IDENTIFICATION\_CARD | 2024 | Police Identification Card | | ALL | IdentificationCard | PROFESSIONAL\_IDENTIFICATION\_CARD | 2024 | Professional License ID | | ALL | IdentificationCard | UMID\_CARD | 2000 | Unified Multi-Purpose ID | | ALL | IdentificationCard | UMID\_CARD | 2001 | Unified Multi-Purpose ID | | ALL | IdentificationCard | UMID\_CARD | 2002 | Unified Multi-Purpose ID | | ALL | MedicalCard | MEDICAL\_CARD | 2009 | PhilHealth Insurance Card | | ALL | MedicalCard | MEDICAL\_CARD | 2010 | PhilHealth Insurance Card | | ALL | MedicalCard | MEDICAL\_CARD | 2012 | PhilHealth Insurance Card | | ALL | MedicalCard | MEDICAL\_CARD | 2013 | Medical Card | | ALL | Military | MILITARY\_CARD | 2019 | Military Card | | ALL | Military | MILITARY\_CARD | 2022 | Military Card | | ALL | Military | MILITARY\_CARD | 2023 | Military Card | | ALL | Military | MILITARY\_CARD | 2024 | Military Card | | ALL | Military | MILITARY\_CARD | 2025 | Military Card | | ALL | Other | COAST\_GUARD | 2020 | Cost Guard Card | | ALL | Other | FIRE\_PROTECTION\_BUREAU\_ID | 2022 | Fire Protecation BUREAU ID | | ALL | Other | GSIS\_ECARD\_PLUS | 2020 | GSIS eCard Plus | | ALL | Other | MARITIME\_INDUSTRY\_AUTHORITY | 2020 | Maritime Industry Authority Card | | ALL | Other | MARITIME\_INDUSTRY\_AUTHORITY | 2021 | Maritime Industry Authority Card | | ALL | Other | MARITIME\_INDUSTRY\_AUTHORITY | 2022 | Maritime Industry Authority Card | | ALL | Other | NBI\_CLEARANCE | 2020 | National Bureau Investigation Clearance | | ALL | Other | PHILPOST | 2015 | Postal Identity Card - PHLPOST | | ALL | Other | PHILPOST | 2018 | Postal Identity Card - PHLPOST | | ALL | Other | PHILPOST | 2020 | Postal Identity Card - PHLPOST | | ALL | Other | PROFESSIONAL\_REGULATION\_COMMISSION | 2000 | Professional Identification Card | | ALL | Other | PROFESSIONAL\_REGULATION\_COMMISSION | 2010 | Professional Identification Card | | ALL | Other | SOCIAL\_SECURITY\_CARD | 2011 | Social Security System Number | | ALL | Other | SOCIAL\_SECURITY\_CARD | 2024 | Social Security Card | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Pasaporte / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Pasaporte / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Pasaporte / Passport | | ALL | ResidenceDocument | ALIEN\_CERTIFICATE\_OF\_REGISTRATION | 2020 | Alien Certificate of Registration | | ALL | ResidenceDocument | SPECIAL\_INVESTOR\_RESIDENT\_VISA | 2020 | Special Investor's Resident Visa | | ALL | TaxIdentification | TAX\_IDENTIFICATION | 2017 | TIN (Taxpayer Identification Number) ID | | ALL | TaxIdentification | TAX\_IDENTIFICATION | 2020 | TIN (Taxpayer Identification Number) ID | | ALL | TaxIdentification | TAX\_IDENTIFICATION | 2021 | TIN (Taxpayer Identification Number) ID | | ALL | TaxIdentification | TAX\_IDENTIFICATION | 2022 | TIN (Taxpayer Identification Number) ID | | ALL | Visa | VISA | 2016 | Visa | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2010 | Voter's ID | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2011 | Voter's ID | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2022 | Voter Identification Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2024 | Voter's Certification | ### Local Disability Identification Cards | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------- | :------ | :------------------------------------------------------------ | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1938 | City of Lipa Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1939 | City of Caloocan Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1940 | City Government of Valenzuela Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1941 | City of Cauayan Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1943 | City of Santa Rosa Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1944 | Municipality of Concepcion Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1945 | City of Santa Rosa Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1946 | San Antonio Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1947 | Naga City Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1948 | Municipality of Bulalacao Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1949 | Municipality of Tanza Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1950 | Province of Capiz Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1951 | Tuguegarao City Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1952 | City of Liliw Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1953 | Municipality of Dinalupihan Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1954 | City of Bacoor Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1955 | City of Talisay Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1956 | Municipality of Rizal Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1957 | City of Santiago Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1958 | City of Pasay Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1959 | City of Makati Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1960 | City Government of Tanauan Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1961 | Municipality of Marilao Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1962 | Municipality of Tapaz Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1963 | City of Himamaylan Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1964 | Municipality of Los Baños Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1965 | Municipality of Subic Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1966 | Municipality of Daraga Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1967 | Municipality of Jaro Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1968 | City Government of Pasig Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1969 | Municipality of Santa Barbara Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1970 | Municipality of Pateros Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1973 | City of Tagaytay Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1974 | City of Navotas Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1975 | Municipality of Cabatuan Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1976 | Province of Batangas Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1978 | Municipality of Kalibo Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1979 | Iloilo City Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1980 | City of Caloocan Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1983 | City of Imus Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1984 | City of Davao Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1985 | City of San Juan Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1987 | City of Parañaque Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1989 | Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1993 | City of Bacoor Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1995 | City of Paranaque Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1997 | City of Cotabato Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1998 | Province of Rizal Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 1999 | City of General Trias Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2000 | City of Malolos Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2001 | City of Antipolo Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2002 | Victoria, Laguna Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2003 | Province of Pampanga Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2004 | City of Muntinlupa Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2005 | Las Pinas City Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2006 | Cebu City Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2007 | Municipality of Balete Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2008 | Municipality of GAMU Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2009 | Bacolod City Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2010 | Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2011 | Province of Bulacan Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2012 | Municipality of Talavera Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2013 | Municipality of Oton Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2015 | City of Manila Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2016 | City of Binan Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2017 | City Government of Calamba Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2018 | Marikina City Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2019 | City Government of Pasig Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2020 | City of San Pedro Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2021 | Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2022 | Municipality of La Paz, Tarlac Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2023 | Municipality of Liliw Disability Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2024 | Municipality of Cataingan Disability Identification Card | ### Local Senior Identification Cards | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :--------------------------- | :------ | :-------------------------------------------------------------- | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1928 | Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1929 | Bacolod City Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1930 | Municipality of Concepcion Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1931 | City of Surigao Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1932 | Municipality of Tubod Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1934 | City of Bacoor Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1935 | City of Valenzuela Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1936 | Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1937 | City of Iloilo Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1938 | Municipality of Tangcal Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1940 | Cebu City Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1941 | City of Santa Rosa Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1942 | City Government of Digos Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1943 | Municipality of Plaridel Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1944 | Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1945 | Baguio City Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1946 | Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1947 | Province of Batangas Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1948 | City of Santa Rosa Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1949 | Tacloban City Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1951 | Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1952 | Municipality of Silang Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1953 | Las Piñas City Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1954 | City of Mandaluyong Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1955 | Municipality of Irosin Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1956 | City of San Fernando Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1958 | Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1959 | City of San Juan Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1960 | Siquijor Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1961 | Municipality of Lucban Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1962 | City of Antipolo Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1965 | Cebu Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1971 | Cagayan de Oro City Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1972 | San Juan, Batangas Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1975 | BAC Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1976 | City of Taguig Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1977 | Municipality of Taytay Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1979 | City of San Carlos Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1980 | Pasig City Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1981 | Guihulngan City Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1985 | Bataan Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1987 | Cavinti City Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1989 | Cagayan de Oro City Senior Citizens Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1990 | City of Manila Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1992 | City of Silay Senior Citizen's Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1993 | City of Caloocan Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1994 | Cainta Rizal Senior Citizens Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1995 | City Government of Makati Senior Citizen's Blu Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1996 | City Government of Tacloban Senior Citizens Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1997 | City of San Jose del Monte Senior Citizens Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1998 | City of Manila Senior Citizens Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 1999 | Province of Quezon Senior Citizens Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2001 | City Government of Mabalacat Senior Citizen's Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2002 | Las Piñas Senior Citizens Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2003 | Marikina City Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2004 | Municipality of Angono Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2005 | Las Pinas City Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2006 | Municipality of Taytay Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2007 | Municipality of Baliwag Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2009 | City of Mandaluyong Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2010 | Senior Citizen / Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2011 | City of Malolos Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2012 | Municipality of Carmen Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2013 | Quezon Province Senior Citizen / Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2014 | Province of Zamboanga del Norte Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2015 | City of Surigao Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2016 | Quezon City Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2017 | Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2020 | Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2021 | Legazpi City Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2022 | Dipolog City Senior Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2023 | Municipality of Naic Senior Citizens Identification Card | | ALL | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2024 | Cebu City Senior Identification Card | ### Local Residence Cards | State | Type of ID | Subtype of ID | Version | Description | | :---- | :---------------- | :-------------- | :------ | :------------------------------------------------- | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1800 | Municipality of Gandara Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1801 | Municipality of Bulan Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1802 | Barangay San Antonio Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1803 | Barangay Platero Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1804 | Barangay San Matias Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1805 | City of Marikina Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1806 | Barangay Malanday Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1807 | City of Gapan Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1808 | Barangay Lalakay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1809 | City of Marikina Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1810 | Imus City Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1811 | Barangay Talangan Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1812 | City of Manila Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1813 | Barangay San Isidro Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1814 | Barangay Malusak Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1815 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1818 | Barangay Dela Paz Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1819 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1820 | Barangay Canlalay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1821 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1822 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1823 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1824 | Province of Zambales Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1825 | City of Manila Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1826 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1827 | Municipality of Binangonan Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1828 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1829 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1830 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1831 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1832 | Municipality of Abuyog Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1833 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1834 | Municipality of Bulusan Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1835 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1836 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1837 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1839 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1840 | Barangay San Rafael Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1841 | City of Manila Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1849 | Barangay Malaban Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1850 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1851 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1852 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1853 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1854 | Barangay Yapak Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1855 | City of Passi Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1856 | Barangay Muzon Proper Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1857 | Barangay Manggahan Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1858 | Barangay Santo Cristo Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1859 | Barangay Sicsican Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1860 | Barangay Fort Bonifacio Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1861 | Barangay Dila Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1862 | Barangay Ibayo Tipas Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1865 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1866 | City of Sorsogon Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1867 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1868 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1869 | Municipality of Gen. Mariano Alvarez Resident Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1886 | Barangay Resident Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1890 | Barangay Resident Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1894 | Barangay Bayan Luma 7 Resident Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1895 | Barangay San Jose Resident Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1897 | Barangay Baliwasan Resident Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1904 | Barangay Resident Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1905 | City of Caloocan Resident Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1908 | Payatas Resident Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1911 | Barangay Resident Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1912 | Barangay Camino Nuevo Resident Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1918 | City of Sorsogon Resident Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1919 | Barangay Isio Resident Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1921 | Barangay Resident Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1922 | City of Cabanatuan Resident Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1931 | Barangay Santo Niño Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1932 | Barangay Upper Bicutan Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1933 | Barangay Cupang Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1934 | Barangay Marikina Heights Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1939 | Barangay Sampaloc Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1942 | Barangay San Dionisio Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1943 | Barangay Santo Cristo Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1947 | Barangay San Bartolome Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1949 | Barangay Talaba 1 Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1950 | Barangay East Poblacion Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1954 | Barangay Sabutan Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1957 | Barangay Anabu Ii- c Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1958 | Barangay Tungkong Mangga Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1968 | City of Antipolo Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1970 | Barangay Malanday Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1977 | Barangay Mariblo Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1978 | Barangay Tandang Sora Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1979 | Barangay Tambo Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1980 | Barangay Sauyo Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1981 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1982 | Barangay Santiago Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1983 | City of Quezon Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1984 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1985 | City of Parañaque Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1986 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1987 | Barangay Culiat Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1988 | Barangay San Isidro Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1989 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1990 | City of Tagaytay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1991 | Barangay Muzon South Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1992 | Barangay Muzon Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1994 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1995 | Old Capitol Site Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1996 | Barangay Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1997 | Barangay Batasan Hills Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1998 | Barangay Resident's Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 1999 | Barangay San Jose Resident Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 2000 | Barangay Resident Identification Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 2001 | Barangay Identification Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 2002 | Barangay Identification Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 2003 | Barangay Resident Identification Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 2004 | Barangay Resident Identification Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 2005 | Municipality of Magallanes Resident Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 2006 | Barangay Resident Identification Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 2007 | Barangay Timugan Identification Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 2008 | Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 2009 | Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 2010 | Residence Card | | ALL | ResidenceDocument | RESIDENCE\_CARD | 2023 | Alien Certificate of Registration | ## Qatar (QAT) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2010 | ID Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2011 | ID Card | | ALL | Passport | NATIONAL\_PASSPORT | 2008 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2010 | Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Residence Permit | ## Russia (RUS) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------ | :------ | :---------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2011 | Driver's License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2008 | Identity Card | | ALL | IdentificationCard | TEMPORARY\_IDENTIFICATION\_CARD | 2024 | Temporary Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2000 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2008 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Passport | | ALL | Visa | VISA | 2021 | Viza / Visa | ## Saudi Arabia (SAU) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :----------------------------- | :------ | :--------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2012 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Driving License | | ALL | DriversLicense | INTERNATIONAL\_DRIVING\_PERMIT | 2023 | International Driving Permit | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2010 | National ID Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2013 | National ID Card | | ALL | Military | MILITARY\_CARD | 2020 | Military Card | | ALL | Passport | DIPLOMATIC\_PASSPORT | 2003 | Diplomatic Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2007 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2022 | Saudi Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2015 | Resident Identity Card | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2024 | Premium Resident Identity | | ALL | TravelDocument | CONSULAR\_CARD | 2020 | Consular Card | | ALL | TravelDocument | CONSULAR\_CARD | 2021 | Consular Identity Card | ## Singapore (SGP) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :----------------------------- | :------ | :----------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2002 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2001 | Identity Card | | ALL | Military | MILITARY\_IDENTIFICATION\_CARD | 2010 | Singapore Armed Forces Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2005 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passport | | ALL | Permit | WORK\_PERMIT | 2000 | Work Permit | | ALL | Permit | WORK\_PERMIT | 2001 | Work Permit | | ALL | Permit | WORK\_PERMIT | 2019 | Work Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2005 | Identity Card | | ALL | TravelDocument | LONG\_TERM\_VISIT\_PASS | 2023 | Long-Term Visit Pass | ## South Korea (KOR) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :---------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2000 | Driver's License | | ALL | DriversLicense | DRIVER\_LICENSE | 2020 | Driver's License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2000 | Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2008 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2022 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2018 | Alien Registration Card | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2023 | Residence Card | ## Sri Lanka (LKA) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2006 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2011 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2023 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2018 | National Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2022 | Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Passport | ## Syrian Arab Republic (SYR) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------ | :------ | :--------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2000 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2024 | Identification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2025 | Identification Card | | ALL | DriversLicense | DRIVERS\_LICENSE | 2019 | Driving License | | ALL | DriversLicense | INTERNATIONAL\_DRIVERS\_LICENSE | 2019 | International Driving Permit | | ALL | Military | MILITARY\_CARD | 2014 | Military Card | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Passport | | ALL | Passport | TRAVEL\_DOCUMENT | 2025 | Travel Document | ## Taiwan (TWN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------- | :------ | :----------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2015 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2019 | Driving License | | ALL | DriversLicense | INTERNATIONAL\_DRIVING\_PERMIT | 2020 | International Driving Permit | | ALL | IdentificationCard | MEDICAL\_CARD | 2012 | Nationa Health Insurance Card | | ALL | IdentificationCard | NATIONAL\_IDENTIFICATION\_CARD | 2005 | National Identity Card | | ALL | IdentificationCard | DIPLOMATIC\_IDENTIFICATION\_CARD | 2024 | Diplomatic Identification Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2020 | Disability Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2008 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Resident Certificate | | ALL | TravelDocument | HOME\_RETURN\_PERMIT | 2024 | Home Return Permit | | ALL | Visa | VISA | 2023 | Visa | ## Tajikistan (TJK) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :-------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2014 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Passport | ## Thailand (THA) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------------ | :------ | :--------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2010 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Private Car Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2001 | Thai National ID Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD\_FOR\_FOREIGNERS | 2025 | Identification Card for Foreigners | | ALL | TravelDocument | CONSULAR\_CARD | 2020 | Consular Card | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2020 | Passport | | ALL | Passport | EMERGENCY\_PASSPORT | 2023 | Emergency Passport | ## Turkey (TUR) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :---------------------------------------- | :------ | :-------------------------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2010 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2016 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2022 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2006 | Türkiye Cumhuriyeti Kimlik Kartı (Turkish Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2007 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Republic of Turkey Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2024 | Identification Card (Blue Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD\_FOR\_FOREIGNERS | 2023 | Identification Card for Foreigners | | ALL | Other | TEMPORARY\_PROTECTION\_IDENTITY\_DOCUMENT | 2014 | Geçici Koruma Kimlik Belgesi (Temporary Protection Identity Document) | | ALL | Permit | WORK\_PERMIT | 2023 | Work Permit | | ALL | Permit | WORK\_PERMIT | 2024 | Fixed Term Work Permit | | ALL | Permit | WORK\_PERMIT | 2025 | Work Permit | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Pasaport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Pasaport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2022 | Pasaport / Passport | | ALL | Passport | TEMPORARY\_PASSPORT | 2024 | Temporary Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2010 | Residence Permit Document | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2021 | Residence Permit Document | ## Turkish Republic of Northern Cyprus (XCT) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :--------------------------- | :------ | :------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2020 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2022 | Identity Card | | ALL | IdentificationCard | POLICE\_IDENTIFICATION\_CARD | 2013 | Police Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2021 | Pasaport / Passport | ## Turkmenistan (TKM) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :----------------- | :------ | :----------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2003 | Permis de Conduire / Driving License | | ALL | Passport | NATIONAL\_PASSPORT | 1998 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2025 | Passport | ## United Arab Emirates (ARE) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------ | :------ | :--------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2001 | Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2002 | Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2003 | Driving License | | ALL | DriversLicense | INTERNATIONAL\_DRIVERS\_LICENSE | 2020 | International Driving Permit | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2011 | Identity Card | | ALL | MedicalCard | MEDICAL\_CARD | 2018 | Health Card | | ALL | Passport | NATIONAL\_PASSPORT | 2011 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Passport | | ALL | Passport | DIPLOMATIC\_PASSPORT | 2022 | Diplomatic Passport | | ALL | Visa | VISA | 2020 | Residence Permit | | ALL | ResidenceDocument | GOLDEN\_CARD | 2022 | Golden Card | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2000 | Resident Identity Card | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2021 | Resident Identity Card | ## Uzbekistan (UZB) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :-------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2018 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2006 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2019 | Passport | ## Vietnam (VNM) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------- | :------ | :----------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2000 | Driver's License | | ALL | DriversLicense | DRIVER\_LICENSE | 2003 | Driver's License | | ALL | DriversLicense | DRIVER\_LICENSE | 2025 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 1999 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2000 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2024 | Identity Card | | ALL | IdentificationCard | DIPLOMATIC\_IDENTIFICATION\_CARD | 2025 | Diplomatic Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2005 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2022 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Passport | ## Yemen (YEM) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :-------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2019 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passport | --- ## Caribbean The following tables list supported identification documents for the Caribbean, organized by country. ## Antigua and Barbuda (ATG) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :---------------------- | :------ | :------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2020 | Driver's License | | ALL | MedicalCard | SOCIAL\_SECURITY\_BOARD | 2022 | Social Security Board Card | | ALL | MedicalCard | SOCIAL\_SECURITY\_BOARD | 2024 | Social Security Board Card | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passport | ## Anguilla (AIA) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :--------------- | :------ | :------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2021 | Driver License | ## Aruba (ABW) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :---------------------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Cedula di Identidad (Identification Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2022 | Identity Card | | ALL | DriversLicense | DRIVERS\_LICENSE | 2015 | Rijbewijs (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2020 | Rijbewijs (Driving License) | ## Barbados (BRB) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :------------------ | | ALL | DriversLicense | DRIVERS\_LICENSE | 2015 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2009 | Identification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Passport | ## Bermuda (BMU) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :-------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2014 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2024 | Bermuda Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2004 | Passport | ## Bonaire (BES) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :--------------- | :------ | :-------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2018 | Rijbewijs (Driving License) | ## Cayman Islands (CYM) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2018 | Driver's License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2008 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2020 | Passport | ## Cuba (CUB) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :----------------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Carné de Identidad (Identity Card) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2003 | Permis de Conduire (Driving License) | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Pasaporte (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Pasaporte / Passport | ## Curaçao (CUW) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2017 | Rijbewijs (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Identiteitskaart (Identity Card) | ## Dominica (DMA) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :--------- | :----------------- | :------ | :---------- | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2022 | Passport | ## Dominican Republic (DOM) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------- | :------ | :--------------------------------------------------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2000 | Licencia de Conducir (Driving License) | | ALL | DriversLicense | DRIVER\_LICENSE | 2022 | Licencia Motocicletas (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2024 | Permiso de Aprendizaje (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2026 | Licencia de Conducir (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2001 | Cédula de Identidad y Electoral (Identity and Electoral Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2026 | Cédula de Identidad y Electoral (Identity and Electoral Card) | | ALL | IdentificationCard | DIPLOMATIC\_IDENTIFICATION\_CARD | 2024 | Carnet de Identificación Diplomática / Diplomatic Identification Card | | ALL | IdentificationCard | INTERNATIONAL\_IDENTITY\_CARD | 2020 | International Identity Card | | ALL | IdentificationCard | POLICE\_IDENTIFICATION\_CARD | 2022 | Policia Carnet de Identidad / Police Identification Card | | ALL | IdentificationCard | POLICE\_IDENTIFICATION\_CARD | 2023 | Policia Nacional Dominicana Carnet de Identidad / Police Identification Card | | ALL | IdentificationCard | POLICE\_IDENTIFICATION\_CARD | 2024 | Policia Carnet de Identidad / Police Identification Card | | ALL | IdentificationCard | POLICE\_IDENTIFICATION\_CARD | 2025 | Police Identity Card | | ALL | MedicalCard | SOCIAL\_SECURITY\_CARD | 2024 | Social Security Card | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2022 | Residencia Permanente / Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2023 | Residencia Temporal / Residence Permit | | ALL | Permit | WORK\_PERMIT | 2022 | Permiso Temporal de Trabajo / Work Permit | | ALL | Military | MILITARY\_CARD | 2023 | Military Card | | ALL | Military | MILITARY\_CARD | 2024 | Military Card | | ALL | Military | MILITARY\_CARD | 2025 | Military Card | | ALL | TravelDocument | CONSULAR\_CARD | 2021 | Consular Card | | ALL | TravelDocument | CONSULAR\_CARD | 2022 | Consular Card | | ALL | TravelDocument | CONSULAR\_CARD | 2024 | Consular Card | | ALL | Passport | NATIONAL\_PASSPORT | 2009 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2014 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2026 | Passport | | ALL | Visa | VISA | 2019 | Visa | | ALL | Visa | VISA | 2022 | Visa | ## Grenada (GRD) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :----------------- | :------ | :--------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2019 | Driver's License | | ALL | Passport | NATIONAL\_PASSPORT | 2001 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2019 | Passport | ## Haiti (HTI) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :-------------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2015 | Permis de Conduire (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2005 | Carte D'Identification Nationale (National Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Carte D'Identification Nationale (National Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Passeport / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passeport / Passport | ## Jamaica (JAM) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :-------------------------- | :------ | :--------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2017 | Driver's License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Elector Registration Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Passport | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2010 | Elector Registration Identification Card | ## Puerto Rico (PRI) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :-------------------------- | :------ | :------------------------------------------------------------------ | | ALL | DriversLicense | DRIVERS\_LICENSE | 2008 | Licencia de Conducir (Driver's License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2018 | Driver's License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2019 | Licencia de Conducir (Driver's License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Tarjeta de identificación (Identification Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Identification Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2015 | Tarjeta De Identificacion Electoral (Electoral Identification Card) | | ALL | Other | FISHERMAN\_LICENSE | 2020 | Fisherman License | | ALL | Other | FIREARMS\_LICENSE | 2020 | Firearm License | ## Saint Kitts and Nevis (KNA) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | National Identification Card | | ALL | DriversLicense | DRIVERS\_LICENSE | 2019 | Drivers' License | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Passport | ## Saint Lucia (LCA) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :---------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | National ID Card | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Driver's License | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Official Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Passport | ## Sint Maarten (Dutch part) (SXM) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :--------------- | :------ | :--------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2015 | Driver's License | ## Saint Vincent and the Grenadines (VCT) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2022 | National Identity Card | | ALL | DriversLicense | DRIVERS\_LICENSE | 2024 | Drivers License | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passport | ## The Bahamas (BHS) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :------------------ | | ALL | DriversLicense | DRIVERS\_LICENSE | 2021 | Driver's License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2011 | Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passport | ## Trinidad and Tobago (TTO) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | National Identification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2011 | National Identification Card | | ALL | DriversLicense | DRIVERS\_LICENSE | 2006 | Driver's License | | ALL | Passport | NATIONAL\_PASSPORT | 2007 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passport | | ALL | Permit | WORK\_PERMIT | 2024 | Work Permit | ## US Virgin Islands (VIR) | Type of ID | Subtype of ID | Version | Description | | :------------------ | :-------------------------- | :------ | :----------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2018 | Driver's License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2019 | Driver's License Under 21 | | DriversLicense | DRIVERS\_LICENSE | 2023 | Virgin Islands Driver License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2025 | Virgin Islands Driver's License (Under 21) | | DriversLicense | DRIVERS\_LICENSE | 2025 | Virgin Islands Driver's License | | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Identification Card | | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2020 | Virgin Islands Voter Identification Card | --- ## Central America The following tables list supported identification documents for Central America, organized by country. ## Belize (BLZ) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :---------------- | :---------------------------- | :------ | :------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2016 | Belize Driver's License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2021 | Belize Driver's License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2022 | Belize Driver's License | | ALL | ResidenceDocument | PERMANENT\_RESIDENCE\_CARD | 2025 | Permanent Residence Card | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Passport | | ALL | MedicalCard | SOCIAL\_SECURITY\_BOARD\_CARD | 2020 | Social Security Board Card | ## Costa Rica (CRI) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :---------------------------------- | :------ | :-------------------------------------------------------------------------------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2000 | Licencia de Conducir (Driver License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 1999 | Cedula de Identidad (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Cedula de Identidad (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2025 | Cedula de Identidad (Identity Card) | | ALL | IdentificationCard | TARJETA\_DE\_IDENTIDAD\_DE\_MENORES | 2010 | Tarjeta de Identidad de Menores de Edad / Identity Card for Minors | | ALL | IdentificationCard | TARJETA\_DE\_IDENTIDAD\_DE\_MENORES | 2026 | Tarjeta de Identidad de Menores de Edad / Identity Card for Minors | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Pasaporte (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2022 | Pasaporte (Passport) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2005 | Documento de Identidad Migratorio para Extranjeros (Immigration Identity Document for Foreigners) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2023 | Documento de Identidad Migratorio para Extranjeros (Immigration Identity Document for Foreigners) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT\_PDF | 2023 | Documento de Identidad Migratorio para Extranjeros (Digital Immigration Identity Document for Foreigners) | | ALL | TravelDocument | CONSULAR\_CARD | 2024 | Consular Card | | ALL | Permit | WORK\_PERMIT | 2024 | Work Permit | | ALL | Visa | VISA | 2024 | Visa | ## El Salvador (SLV) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :------------------------------------------------------ | | ALL | DriversLicense | DRIVER\_LICENSE | 2000 | Licencia de Conducir (Driver License) | | ALL | DriversLicense | DRIVER\_LICENSE | 2017 | Licencia de Conducir / Driver License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2000 | Documento Unico de Identidad (Unique Identity Document) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Documento de Identidad Personal / Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2022 | Documento Unico de Identidad (Unique Identity Document) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Carnet de Identificación Personal / Identification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2026 | Carnet de Identificación Personal / Identification Card | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2010 | Carné de Residencia / Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2024 | Residencia Definitiva / Residence Permit | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Pasaporte (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2024 | Pasaporte / Passport | ## Guatemala (GTM) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------------------------------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2011 | Licencia de Conducir (Driver License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2017 | Licencia de Conducir (Driver License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2020 | Licencia de Conducir (Driver License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2009 | Documento Personal de Identificacion (Personal Identification Document) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2025 | Documento Personal de Identificación / Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Documento Personal de Identificacion (Personal Identification Document) | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Pasaporte (Passport) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2000 | Documento Personal de Identificacion - Extranjero Domiciliado (Residence Document) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2011 | Documento Personal de Identificacion - Extranjero Domiciliado (Residence Document) | | ALL | TravelDocument | CONSULAR\_CARD | 2017 | Identificacion Consular (Consular ID Card) | | ALL | TravelDocument | CONSULAR\_CARD | 2020 | Cédula Diplomática / Consular Card | ## Honduras (HND) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :----------------------------- | :------ | :---------------------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2019 | Licencia de Conducir (Driver License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2022 | Permiso de Conducir (Driver License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2023 | Permiso de Conducir (Driver License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2024 | Permiso de Conducir / Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2009 | Tarjeta de Identidad (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Documento Nacional de Identificacion (National Identity Document) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2015 | Carnet de Extranjero Residente / Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Residence Permit / Carnet de Extranjero Residente | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Pasaporte (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2022 | Pasaporte (Passport) | | ALL | TravelDocument | CONSULAR\_IDENTIFICATION\_CARD | 2018 | Matricula Consular (Consular ID) | | ALL | TravelDocument | CONSULAR\_IDENTIFICATION\_CARD | 2025 | Matricula Consular / Consular ID Card | ## Nicaragua (NIC) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :-------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2021 | Licencia de Conducir (Driver License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2009 | Cedula de Identidad (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Cedula de Identidad (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Cedula de Identidad (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2026 | Cedula de Identidad (Identity Card) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2010 | Cedula de Residencia / Residence Permit | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Pasaporte (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2019 | Pasaporte (Passport) | | ALL | TravelDocument | CONSULAR\_CARD | 2020 | Carnet Consular / Consular Card | | ALL | TravelDocument | CONSULAR\_CARD | 2025 | Carnet de Servicio / Consular Card | ## Panama (PAN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :-------------------------- | :------ | :--------------------------------------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2001 | Licencia de Conducir (Driving License) | | ALL | DriversLicense | DRIVER\_LICENSE | 2025 | Licencia de Conducir / Driver's License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Cedula de Identidad (Domestic Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Cedula de Identidad (Domestic Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Documento de Identidad (Identity Card) | | ALL | IdentificationCard | YOUTH\_IDENTIFICATION\_CARD | 2018 | Cedula Juvenil (Youth ID) | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Pasaporte / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2019 | Pasaporte / Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2000 | Permiso de Residencia Provisional (Provisional Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2015 | Carné de Residente Permanente (Permanent Resident Card) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2021 | Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2023 | Carné de Residente Permanente (Permanent Resident Card) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2024 | Residence Permit | | ALL | ResidenceDocument | PERMANENT\_RESIDENCE\_CARD | 2000 | Residente Permanente / Residence Permit | | ALL | TravelDocument | CONSULAR\_CARD | 2020 | Consular Card | | ALL | Permit | WORK\_PERMIT | 2019 | Permiso de Trabajo / Work Permit | --- ## Europe The following tables list supported identification documents for Europe, organized by country. The table for the United Kingdom is further divided by state. ## Albania (ALB) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------- | :------ | :------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2005 | Leje Drejtimi (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2015 | Certifikatë Aftësimi Profesional (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2019 | Leje Drejtimi (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2013 | Letërnjoftim ID (Identity Card) | | ALL | IdentificationCard | DIPLOMATIC\_IDENTIFICATION\_CARD | 2025 | Diplomatic Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Pasaportë (Passport) | ## Andorra (AND) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :---------------- | :----------------- | :------ | :---------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 1990 | Permis de Conduir (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2025 | Driving License | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2024 | Residence Permit | | ALL | Passport | NATIONAL\_PASSPORT | 2005 | Passaport (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2007 | Passaport (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passaport (Passport) | ## Austria (AUT) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------- | :------ | :----------------------------------------------------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2010 | Führerschein Republik Österreich (Driving license for the Republic of Austria) | | ALL | DriversLicense | DRIVER\_LICENSE | 2013 | Führerschein (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2014 | Identity Card of the Republic of Austria | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Identity Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2020 | Identity Card for Disabled Persons | | ALL | MedicalCard | MEDICAL\_CARD | 2020 | Medical Card | | ALL | Passport | NATIONAL\_PASSPORT | 2014 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2024 | Passport | | ALL | ResidenceDocument | RESIDENCE\_DOCUMENT | 2012 | Aufenthaltskarte (Residence Card) | | ALL | ResidenceDocument | RESIDENCE\_DOCUMENT | 2017 | Legitimation Card Republic of Austria - Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_DOCUMENT | 2021 | Aufenthaltsberechtigungskarte (Residence Permit Card) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2011 | Aufenthaltstitel (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Aufenthaltstitel (Residence Permit) | | ALL | Visa | VISA | 2020 | Visum / Visa | ## Belarus (BLR) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2012 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Identity Card | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2021 | Residence Permit | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2021 | Passport | ## Belgium (BEL) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :---------------------------- | :------ | :---------------------------------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2010 | Rijbewijs / Permis de Conduire (Driving License) | | ALL | DriversLicense | DRIVER\_LICENSE | 2013 | Rijbewijs / Permis de Conduire (Driving License) | | ALL | DriversLicense | DRIVER\_CARD | 2020 | Driver Card | | ALL | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE | 2013 | Provisional Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2014 | Identiteitskaart / Carte D'Identite (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Identiteitskaart / Carte D'Identite (Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2014 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2022 | Passport | | ALL | Passport | TRAVEL\_DOCUMENT | 2024 | Travel Document | | ALL | ResidenceDocument | RESIDENCE\_DOCUMENT | 2013 | Verblijfstitel (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_DOCUMENT | 2015 | E Kaart / E Card (Residence Document) | | ALL | ResidenceDocument | RESIDENCE\_DOCUMENT | 2021 | Document de Sejour / Verblijfsdocument (Residence Document) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2021 | Aufenthaltstitel (Residence Permit) | | ALL | ResidenceDocument | SPECIAL\_IDENTITY\_CARD | 2013 | Special Identity Card | | ALL | Visa | VISA | 2019 | Visa | ## Bosnia and Herzegovina (BIH) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :-------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2015 | Vozacka Dozvola (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2013 | Licna Karta (Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2014 | Pasos (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Pasos (Passport) | ## Bulgaria (BGR) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :---------------------------------------- | :------ | :--------------------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2014 | Driver Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Licna Karta (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2024 | Licna Karta (Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2019 | Passport | | ALL | ResidenceDocument | RESIDENCE\_DOCUMENT | 2015 | Certificate for EU Citizen (Residence Document) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2019 | Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2024 | Residence Permit | | ALL | ResidenceDocument | TEMPORARY\_PROTECTION\_IDENTITY\_DOCUMENT | 2020 | Identity Card for subsidiary protection beneficiaries (Bulgaria) | | ALL | Visa | VISA | 2023 | Visa | ## Croatia (HRV) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 1994 | Vozacka Dozvola (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Vozacka Dozvola (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2024 | Vozacka Dozvola (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2003 | Osobna Iskaznica (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Osobna Iskaznica (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Osobna Iskaznica (Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2009 | Putovnica (Passport) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Dozvola boravka (Residence Permit) | | ALL | Visa | VISA | 2023 | Viza / Visa | ## Cyprus (CYP) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------- | :------ | :----------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2014 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2014 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Identity Card | | ALL | IdentificationCard | DIPLOMATIC\_IDENTIFICATION\_CARD | 2025 | Diplomatic Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2014 | Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Residence Permit | ## Czech Republic (CZE) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2004 | Řidičský Průkaz (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2012 | Občanský Průkaz (National Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Občanský Průkaz (National Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2009 | Cestovní Pas (Passport) | | ALL | Passport | EMERGENCY\_PASSPORT | 2024 | Emergency Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2006 | Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2013 | Povolení k Pobytu (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2015 | Identity Card and Long Term Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Povolení k Pobytu (Residence Permit) | | ALL | Visa | VISA | 2022 | Visa | ## Denmark (DNK) | State | Type of ID | Subtype of ID | Version | Description | | :------------- | :---------------- | :------------------ | :------ | :----------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 1997 | Kørekort (Driving License) | | ALL | DriversLicense | DRIVER\_LICENSE | 2013 | Kørekort (Driving License) | | ALL | DriversLicense | DRIVER\_LICENSE | 2018 | Kørekort (Driving License) | | ALL | DriversLicense | DRIVER\_LICENSE | 2025 | Driving License | | ALL | MedicalCard | MEDICAL\_CARD | 2014 | Sundhedskort (Health Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2021 | Passport | | ALL | ResidenceDocument | RESIDENCE\_DOCUMENT | 2018 | Opholdskort (Residence Card) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 1998 | Opholdstilladelse (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2010 | Opholdstilladelse (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2018 | Opholdstilladelse (Residence Permit) | | FAROE\_ISLANDS | DriversLicense | DRIVERS\_LICENSE | 2020 | Faroe Islands Driving License | | GREENLAND | DriversLicense | DRIVERS\_LICENSE | 2010 | Kalaallit Nunaat Driver License | | GREENLAND | DriversLicense | DRIVERS\_LICENSE | 2024 | Greenland Driving License | ## Estonia (EST) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------- | :------ | :----------------------------------------------------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Juhiluba (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2020 | Juhiluba (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2011 | Isikutunnistus (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Isikutunnistus (Identity Card) | | ALL | IdentificationCard | DIPLOMATIC\_IDENTIFICATION\_CARD | 2022 | Diplomatic Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2014 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2021 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2016 | Rahvusvahelise Kaitse Taotleja Tunnistus (Certificate of Applicant for International Protection) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2018 | Elamisluba (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Elamisluba (Residence Permit) | ## Finland (FIN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :-------------------------- | :------ | :---------------------------------------------------------------------------- | | ALAND | DriversLicense | DRIVERS\_LICENSE | 2015 | Aland Körkort (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2000 | Ajokortti Körkort (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Ajokortti Körkort (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2019 | Ajokortti Körkort (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2024 | Driving License / Permis de Conduire | | ALL | DriversLicense | DRIVER\_QUALIFICATION\_CARD | 2022 | Driver Qualification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2011 | Identitetskort (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Identitetskort (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Identitetskort (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Identitetskort (Identity Card) | | ALL | IdentificationCard | MINORS\_ID | 2024 | Minor's Identity Card | | ALL | MedicalCard | MEDICAL\_CARD | 2025 | Medical Card | | ALL | Passport | NATIONAL\_PASSPORT | 2000 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2006 | Passi / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2025 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2012 | Finnish Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2017 | Identitetskort (Identity Card) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Identitetskort /Identity Card (this document authorizes residence in Finland) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2023 | Residence Permit | | ALL | Visa | VISA | 2019 | Viisumi (Visa) | | ALL | Visa | VISA | 2022 | Viisumi (Visa) | | ALL | MedicalCard | MEDICAL\_CARD | 2024 | Health Insurance Card | ## France (FRA) | State | Type of ID | Subtype of ID | Version | Description | | :------------- | :----------------- | :--------------------------------- | :------ | :------------------------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 1999 | Permis de Conduire (Driver's License) | | ALL | DriversLicense | DRIVER\_LICENSE | 2013 | Permis de Conduire (Driver's License) | | ALL | DriversLicense | DRIVER\_QUALIFICATION\_CARD | 2020 | Driver Qualification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 1994 | Carte Nationale D'Identite (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Carte Nationale D'Identite (Identity Card) | | ALL | IdentificationCard | PROFESSIONAL\_IDENTIFICATION\_CARD | 2024 | Professional Identification Card | | ALL | Military | MILITARY\_ID | 2009 | Carte D'identité Militaire (Military Card) | | ALL | Military | MILITARY\_ID | 2020 | Carte D'Identite Militaire (Military ID Card) | | ALL | Military | MILITARY\_ID | 2023 | Carte D'Identite Militaire (Military ID Card) | | ALL | Passport | DIPLOMATIC\_PASSPORT | 2008 | Passeport Diplomatique (Diplomatic Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2008 | Passeport (Passport) | | ALL | Passport | EMERGENCY\_PASSPORT | 2023 | Passeport D'urgence / Emergency Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2001 | Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2011 | Titre de Séjour (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Titre de Séjour (Residence Permit) | | ALL | Visa | VISA | 2010 | Visa | | ALL | Visa | VISA | 2020 | Visa | | ALL | MedicalCard | MEDICAL\_CARD | 2023 | Medical Card | | ALL | MedicalCard | MEDICAL\_CARD | 2024 | Medical Card | | NEW\_CALEDONIA | DriversLicense | DRIVER\_LICENSE | 2024 | New Caledonia Permis de Conduire (Driving License) | ## Georgia (GEO) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------- | :------ | :----------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2006 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2012 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2025 | Identity Card | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2021 | Temporary Residence Card | | ALL | ResidenceDocument | TEMPORARY\_RESIDENCE\_CARD | 2025 | Temporary Residence Card | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2025 | Passport | ## Germany (DEU) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :--------------------- | :------ | :---------------------------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2011 | Führerschein (Driver's License) | | ALL | DriversLicense | DRIVER\_LICENSE | 2013 | Führerschein (Driver's License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2007 | Personalausweis (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Personalausweis (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Personalausweis (Identity Card) | | ALL | IdentificationCard | TEMP\_GERMAN\_IDCARD | 2004 | Vorlaufiger Personalausweis (Temporary Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2007 | Reisepass (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Reisepass (Passport) | | ALL | Passport | TEMPORARY\_PASSPORT | 2014 | Vorläufiger Reisepass (Temporary Passport) | | ALL | ResidenceDocument | FICTIONAL\_CERTIFICATE | 2020 | Fictional Certificate | | ALL | ResidenceDocument | FICTIONAL\_CERTIFICATE | 2024 | Fiktionsbescheinigung (Fictional Certificate) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2011 | Aufenthaltstitel (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2019 | Aufenthaltstitel (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2021 | Residence Permit | | ALL | Visa | VISA | 2018 | Visum (Visa) | | ALL | MedicalCard | MEDICAL\_CARD | 2024 | Medical Card | ## Gibraltar (GIB) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------ | :------ | :------------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Identity Card / Carte D'Identite | | ALL | Other | CIVIL\_REGISTRATION\_CARD | 2020 | Civilian Registration Card | | ALL | DriversLicense | DRIVERS\_LICENSE | 2023 | Driving License | ## Greece (GRC) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :-------------------------------- | :------ | :------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2009 | Driver's License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Driver's License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2023 | Driver's License | | ALL | IdentificationCard | DOMESTIC\_IDENTIFICATION\_CARD | 2016 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Identity Card | | ALL | IdentificationCard | POLICE\_IDENTIFICATION\_CARD | 2020 | Police Identification Card | | ALL | IdentificationCard | POLICE\_IDENTIFICATION\_CARD | 2025 | Police Identification Card | | ALL | Military | MILITARY\_ID | 2022 | Military ID Card | | ALL | Passport | DIPLOMATIC\_PASSPORT | 2006 | Diplomatic Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2020 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2024 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2013 | Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Residence Permit | | ALL | ResidenceDocument | ASYLUM\_SEEKER\_CARD | 2020 | Asylum Seeker Card | | ALL | Other | FIREFIGHTER\_IDENTIFICATION\_CARD | 2024 | Firefighter Identity Card | ## Hungary (HUN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------------ | :------ | :------------------------------------------ | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Vezetői Engedély (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2012 | Személyazonosító Igazolvány (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Személyazonosító Igazolvány (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2022 | Temporary Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD\_FOR\_FOREIGNERS | 2016 | ID Card for foreigners | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Útlevél (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Útlevél (Passport) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2018 | Tartózkodási Engedély (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2019 | Permanent Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Tartózkodási Engedély (Residence Permit) | ## Iceland (ISL) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :----------------- | :------ | :----------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 1997 | Ökuskírteini (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2002 | Ökuskírteini (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2016 | Ökuskírteini (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2024 | Ökuskírteini (Driving License) | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Vegabréf (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Vegabréf (Passport) | ## Interpol (XPO) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :---------------------------------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2014 | Interpol Identification Card (Carte D'Identification) | | ALL | Passport | PASSPORT | 2013 | Interpol Passport / Passeport | ## Ireland (IRL) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :-------------------------- | :------ | :--------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2013 | Ceadúnas Tiomána (Driving License) | | ALL | DriversLicense | LEARNER\_PERMIT | 2013 | Cead Foghlamor (Learner's Permit) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Passport Card | | ALL | IdentificationCard | AGE\_CARD | 2020 | Age Card | | ALL | Other | PUBLIC\_SERVICES | 2013 | Public Services Card | | ALL | Other | PUBLIC\_SERVICES | 2014 | Public Services Card | | ALL | Passport | NATIONAL\_PASSPORT | 2006 | Pas / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Pas / Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2001 | Certificate of Registration | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2017 | Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Residence Permit | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2020 | Electoral Identity Card | ## Italy (ITA) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------- | :------ | :---------------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2000 | Patente di Guida (Driver's License) | | ALL | DriversLicense | DRIVER\_LICENSE | 2013 | Patente di Guida (Driver's License) | | ALL | IdentificationCard | DOMESTIC\_DOCUMENT\_OF\_IDENTITY | 2000 | Carta di Identità (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2004 | Carta di Identità (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Carta di Identità (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Carta di Identità (Identity Card) | | ALL | MedicalCard | HEALTH\_CARD | 2022 | Tessera Sanitaria (Health Insurance Card) | | ALL | MedicalCard | HEALTH\_CARD | 2025 | Health Card | | ALL | Passport | NATIONAL\_PASSPORT | 2005 | Passaporto (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Passaporto (Passport) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2011 | Permesso di Soggiorno (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2013 | Permesso di Soggiorno (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2021 | Permesso di Soggiorno (Residence Permit) | | ALL | TravelDocument | CONSULAR\_CARD | 2023 | Consular Card | | ALL | Visa | VISA | 2005 | Visto (Visa) | | ALL | Visa | VISA | 2019 | Visto (Visa) | ## Jersey (JEY) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :-------------- | :------ | :-------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2014 | Driving License | ## Kosovo (RKS) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :-------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2008 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2021 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2024 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2013 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2024 | Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2011 | Passaporte / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Passaporte / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2024 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2021 | Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2025 | Residence Permit | ## Latvia (LVA) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :----------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2014 | Vadītāja Apliecība (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2012 | Personas Apliecība (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Personas Apliecība (Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Pase (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Pase (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2024 | Pase (Passport) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2021 | Permanent Residence Card | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2024 | Residence Permit | ## Liechtenstein (LIE) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :---------------- | :----------------- | :------ | :----------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2018 | Permis de Conduire (Driving License) | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Aufenthaltskarte (Residence Card) | ## Lithuania (LTU) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------- | :------ | :--------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2000 | Permis de Conduire (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2010 | Vairuotojo Pazymejimas (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2011 | Vairuotojo Pazymejimas (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Vairuotojo Pazymejimas (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2017 | Vairuotojo Pazymejimas (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Personal Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2012 | Personal Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Identity Card | | ALL | IdentificationCard | PENSIONERS\_IDENTITY\_CARD | 2024 | Pensioner certificate | | ALL | Passport | NATIONAL\_PASSPORT | 2019 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2012 | Leidimas Gyventi (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Leidimas Gyventi (Residence Permit) | | ALL | Visa | VISA | 2020 | Viza / Visa | ## Luxembourg (LUX) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :----------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Permis de Conduire (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2008 | Identity Card / Carte D'Identite | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2014 | Identity Card / Carte D'Identite | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Identity Card / Carte D'Identite | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Pass / Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2013 | Titre de Sejour (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Titre de Sejour (Residence Permit) | | ALL | TravelDocument | CONSULAR\_CARD | 2024 | Consular Card | ## Malta (MLT) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2020 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2014 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2008 | Passaport (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2021 | Passaport (Passport) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Permess Ta 'Residenza (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2025 | Residence Permit | ## Moldova (MDA) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :---------------------------------------- | :------ | :------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2015 | Permis de Conducere (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2007 | Buletin de Identitate (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2014 | Buletin de Identitate (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Buletin de Identitate (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2025 | Buletin de Identitate (Identity Card) | | ALL | Other | TEMPORARY\_PROTECTION\_IDENTITY\_DOCUMENT | 2023 | Temporary Protection Identity Document | | ALL | Passport | NATIONAL\_PASSPORT | 2014 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Passport | ## Monaco (MCO) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :-------------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2009 | Identity Card / Carte D'Identite | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Carte D'identité (Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2005 | Passeport / Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2017 | Carte de Resident (Resident Card) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2023 | Residence Permit | ## Montenegro (MNE) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :------------------------------------------------------------------------ | | ALL | DriversLicense | DRIVERS\_LICENSE | 2008 | Vozacka Dozvola (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2020 | Vozacka Dozvola (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2008 | Licna Karta (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Licna Karta (Identity Card) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2022 | Permanent Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2023 | Dozvola za privremeni boravak i rad (Temporary residence and work permit) | | ALL | Passport | NATIONAL\_PASSPORT | 2008 | Pasos (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2020 | Pasos (Passport) | ## Netherlands (NLD) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------- | :------ | :----------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2006 | Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2013 | Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2018 | Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2025 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2014 | Identity Card | | ALL | IdentificationCard | DIPLOMATIC\_IDENTIFICATION\_CARD | 2016 | Diplomatic Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2006 | Paspoort (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2014 | Paspoort (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2024 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2014 | Dutch Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2022 | Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2026 | Residence Permit | | ALL | Visa | VISA | 2023 | Visa | ## Norway (NOR) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :--------------------------- | :------ | :------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 1989 | Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2007 | Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2013 | Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2018 | Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2023 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Handelsbanken BankID | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Identity Card | | ALL | MilitaryCard | MILITARY\_CARD | 2024 | Military Card | | ALL | Passport | NATIONAL\_PASSPORT | 2011 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2021 | Passport | | ALL | Passport | IMMIGRATION\_PASSPORT | 2023 | Immigration Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Residence Card | | ALL | ResidenceDocument | TEMPORARY\_RESIDENCE\_PERMIT | 2012 | Residence Permit | | ALL | ResidenceDocument | ASYLUM\_SEEKER\_CARD | 2023 | Asylum Seeker Card | ## Poland (POL) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------------------ | :------ | :--------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2000 | Prawo Jazdy (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2001 | Permis de Conduire (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2002 | Prawo Jazdy (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Prawo Jazdy (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2013 | Dowód Osobisty (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Dowód Osobisty (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Dowód Osobisty (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2022 | Karta Polaka (Pole's Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2011 | Paszport (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Paszport (Passport) | | ALL | Passport | TEMPORARY\_PASSPORT | 2024 | Temporary Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2018 | Karta Pobytu (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Karta Pobytu (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2024 | Residence Permit | | ALL | ResidenceDocument | SPECIAL\_IDENTITY\_CARD | 2010 | Special Identity Card | | ALL | ResidenceDocument | TEMPORARY\_FOREIGNER\_IDENTITY\_CERTIFICATE | 2024 | Temporary Foreigner Identity Certificate | | ALL | ResidenceDocument | TEMPORARY\_FOREIGNER\_IDENTITY\_CERTIFICATE | 2025 | Temporary Foreigner Identity Certificate | | ALL | Military | MILITAR\_IDENTIFICATION\_CARD | 2025 | Military Identification Card | ## Portugal (PRT) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------------ | :------ | :-------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 1999 | Carta de Condução (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Carta de Condução (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2014 | Carta de Condução (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Cartão de Cidadão (Citizen Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2024 | Cartão de Cidadão (Identity Card) | | ALL | IdentificationCard | DIPLOMATIC\_IDENTIFICATION\_CARD | 2025 | Diplomatic Identification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD\_FOR\_FOREIGNERS | 2024 | Identification Card for Foreigners | | ALL | Passport | NATIONAL\_PASSPORT | 2009 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2008 | Título de Residência (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Título de Residência (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2024 | Residence Permit | | ALL | ResidenceDocument | ASYLUM\_SEEKER\_CARD | 2020 | Asylum Seeker Card | | ALL | Visa | VISA | 2010 | Visto (Visa) | | ALL | Visa | VISA | 2019 | Visto (Visa) | ## Republic of North Macedonia (MKD) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :---------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2007 | Vozacka Dozvola (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2007 | Licna Karta (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2008 | Licna Karta (Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Pasos (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Pasos (Passport) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2019 | Permanent Residence Permit for Foreigners | ## Romania (ROU) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------- | :------ | :------------------------------------ | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Permis de Conducere (Driving License) | | ALL | DriversLicense | DRIVER\_QUALIFICATION\_CARD | 2022 | Driver Qualification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Carte de Identitate (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2022 | Carte de Identitate (Identity Card) | | ALL | IdentificationCard | DIPLOMATIC\_IDENTIFICATION\_CARD | 2025 | Diplomatic Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2008 | Pasaport/Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2019 | Pasaport/Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2024 | Pasaport/Passport | | ALL | Passport | TEMPORARY\_PASSPORT | 2020 | Pasaport/Passport | | ALL | Passport | TEMPORARY\_PASSPORT | 2023 | Pasaport/Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2013 | Permis de ședere (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Permis de ședere (Residence Permit) | ## Saint Martin (French part) (MAF) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :--------------- | :------ | :----------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2019 | Permis de Conduire (Driving License) | ## San Marino (SMR) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :------------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Carta D'identità / Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2024 | Carta D'identità / Identity Card | | ALL | DriversLicense | DRIVERS\_LICENSE | 2021 | Driving License | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Passaporto (Passport) | ## Serbia (SRB) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------------ | :------ | :-------------------------------------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2011 | Vozacka Dozvola (Driving License) | | ALL | DriversLicense | DRIVER\_QUALIFICATION\_CARD | 2025 | Driver Qualification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2008 | Licna Karta (Identity Card) | | ALL | IdentificationCard | DIPLOMATIC\_IDENTIFICATION\_CARD | 2020 | Diplomatic Identification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD\_FOR\_FOREIGNERS | 2022 | Licna karta za strance / Identification Card for Foreigners | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2011 | Dozvola za privremeni boravak i rad (Residence and work permit) | | ALL | Passport | NATIONAL\_PASSPORT | 2008 | Pasos (Passport) | ## Slovakia (SVK) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------------------------------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2008 | Vodičský Preukaz (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Vodičský Preukaz (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2015 | Vodičský Preukaz (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2013 | Občiansky Preukaz (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2022 | Občiansky Preukaz (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2025 | Občiansky Preukaz (Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2008 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2024 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2019 | Povolenie Na Pobyt (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Pobyt rodinného príslušníka občana EÚ (Residence Card of EU Citizen Family Member) | ## Slovenia (SVN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :------------------------------------ | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Voznisko Dovoljenje (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2015 | Voznisko Dovoljenje (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 1998 | Osebna Iskaznica (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2022 | Osebna Iskaznica (Identity Card) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2021 | Residence Permit | | ALL | Passport | NATIONAL\_PASSPORT | 2006 | Potni List (Passport) | ## Spain (ESP) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------- | :------ | :---------------------------------------------------------------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2004 | Permiso de Conduccion (Driver's License) | | ALL | DriversLicense | DRIVER\_LICENSE | 2013 | Permiso de Conduccion (Driver's License) | | ALL | DriversLicense | DRIVER\_CARD | 2020 | Tarjeta de Conductor / Driver Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2006 | Documento Nacional de Identidad (National Identity Document) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Identification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Documento Nacional de Identidad (National Identity Document) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Documento Nacional de Identidad (National Identity Document) | | ALL | IdentificationCard | CITIZENCARD | 2020 | Citizen Card | | ALL | Military | MILITARY\_CARD | 2020 | Military Card | | ALL | Military | MILITARY\_DRIVERS\_LICENSE | 2025 | Military Driving License | | ALL | Passport | NATIONAL\_PASSPORT | 2008 | Pasaporte (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Pasaporte (Passport) | | ALL | ResidenceDocument | RESIDENCE\_DOCUMENT | 2017 | Certificado de Registro de Ciudadano de la Union (Union Citizen Registration Certificate) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2010 | Tarjeta de Identidad de Extranjero (Foreigner Identity Card) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2011 | Permiso de Residencia (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Permiso de Residencia (Residence Permit) | | ALL | TravelDocument | CONSULAR\_CARD | 2020 | Consular Card | | ALL | TravelDocument | CONSULAR\_CARD | 2021 | Consular Card | | ALL | TravelDocument | CONSULAR\_CARD | 2023 | Consular Card | | ALL | Visa | VISA | 2019 | Visado (Visa) | | ALL | Visa | VISA | 2021 | Visado (Visa) | ## Sweden (SWE) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2007 | Körkort Sverige (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Körkort Sverige (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2016 | Körkort Sverige (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2024 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2025 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2007 | Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2012 | National Identity Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2013 | Identitetskort (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Identitetskort (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Nationellt Identitetskort (National Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2022 | Identitetskort (Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2022 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2011 | Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2021 | Residence Permit | ## Switzerland (CHE) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------- | :------ | :---------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2003 | Führerausweise (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2023 | Führerausweise (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2003 | Identitatskarte (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Identitatskarte (Identity Card) | | ALL | IdentificationCard | DIPLOMATIC\_IDENTIFICATION\_CARD | 2024 | Diplomatic Identification Card | | ALL | IdentificationCard | DIPLOMATIC\_IDENTIFICATION\_CARD | 2025 | Diplomatic Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2022 | Passport | | ALL | Passport | TEMPORARY\_PASSPORT | 2024 | Temporary Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2016 | Aufenthaltstitel (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2019 | Aufenthaltstitel (Residence Permit) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Aufenthaltstitel (Residence Permit) | | ALL | Visa | VISA | 2022 | Visa | | ALL | Visa | VISA | 2023 | Visa / Visum | ## Ukraine (UKR) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :--------------------------- | :------ | :------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 1996 | Permis de Conduire / Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2005 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2014 | Driving License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2021 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Passport of the Citizen of Ukraine (Identity Card) | | ALL | IdentificationCard | PENSIONERS\_IDENTITY\_CARD | 2024 | Pensioner's Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2007 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2005 | Permanent Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2018 | Permanent Residence Permit | | ALL | ResidenceDocument | TEMPORARY\_RESIDENCE\_PERMIT | 2018 | Temporary Residence Permit | ## United Kingdom (GBR) ### All States | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------- | :------ | :------------------------------ | | DriversLicense | DRIVER\_LICENSE | 2006 | Driving License | | DriversLicense | DRIVER\_LICENSE | 2007 | Driving License | | DriversLicense | DRIVER\_LICENSE | 2013 | Driving License | | DriversLicense | DRIVER\_LICENSE | 2015 | Driving License | | DriversLicense | DRIVER\_LICENSE | 2019 | Driver Qualification Card | | DriversLicense | DRIVER\_LICENSE | 2022 | Driving License | | DriversLicense | DRIVER\_CARD | 2018 | Driver Card | | DriversLicense | DRIVER\_QUALIFICATION\_CARD | 2022 | Driver Qualification Card | | DriversLicense | PROVISIONAL\_DRIVER\_LICENSE | 2007 | Provisional Driving License | | DriversLicense | PROVISIONAL\_DRIVER\_LICENSE | 2013 | Provisional Driving License | | DriversLicense | PROVISIONAL\_DRIVER\_LICENSE | 2015 | Provisional Driving License | | DriversLicense | PROVISIONAL\_DRIVER\_LICENSE | 2021 | Provisional Driving License | | DriversLicense | INTERNATIONAL\_DRIVERS\_LICENSE | 2023 | International Drivers License | | DriversLicense | INTERNATIONAL\_DRIVERS\_LICENSE | 2024 | International Drivers License | | IdentificationCard | CITIZENCARD | 2010 | CitizenCard - Proof of Age Card | | IdentificationCard | CITIZENCARD | 2011 | CitizenCard - Proof of Age Card | | IdentificationCard | CITIZENCARD | 2012 | CitizenCard - Proof of Age Card | | IdentificationCard | CITIZENCARD | 2015 | CitizenCard - Proof of Age Card | | IdentificationCard | CITIZENCARD | 2021 | CitizenCard - Proof of Age Card | | IdentificationCard | CITIZENCARD | 2025 | CitizenCard - Proof of Age Card | | IdentificationCard | IDENTIFICATION\_CARD | 2009 | National Identity Card | | IdentificationCard | DIPLOMATIC\_IDENTIFICATION\_CARD | 2024 | Diplomatic Identity Card | | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2020 | UK Disabled ID | | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2024 | National Disability Card | | Military | MILITAR\_IDENTIFICATION\_CARD | 2017 | British Army Identity Card | | Military | MILITAR\_IDENTIFICATION\_CARD | 2024 | Military Identity Card | | Military | MILITAR\_IDENTIFICATION\_CARD | 2025 | British Army Identity Card | | Passport | NATIONAL\_PASSPORT | 2006 | Passport | | Passport | NATIONAL\_PASSPORT | 2010 | Passport / Passeport | | Passport | NATIONAL\_PASSPORT | 2015 | Passport / Passeport | | Passport | NATIONAL\_PASSPORT | 2020 | Passport / Passeport | | Passport | NATIONAL\_PASSPORT | 2023 | Passport | | Passport | NATIONAL\_PASSPORT | 2025 | Passport | | Passport | TRAVEL\_DOCUMENT | 2020 | Travel Document | | ResidenceDocument | RESIDENCE\_PERMIT | 2004 | Residence Permit | | ResidenceDocument | RESIDENCE\_PERMIT | 2008 | Residence Permit | | ResidenceDocument | RESIDENCE\_PERMIT | 2021 | Residence Permit | | Visa | VISA | 2010 | Entry Clearance (Visa) | | Visa | VISA | 2020 | Visa | ### Falkland Islands | Type of ID | Subtype of ID | Version | Description | | :------------- | :-------------- | :------ | :------------------------------- | | DriversLicense | DRIVER\_LICENSE | 2020 | Falkland Islands Driving License | ### Guernsey | Type of ID | Subtype of ID | Version | Description | | :------------- | :-------------- | :------ | :----------------------- | | DriversLicense | DRIVER\_LICENSE | 2013 | Guernsey Driving License | ### Isle of Man | Type of ID | Subtype of ID | Version | Description | | :------------- | :-------------- | :------ | :-------------------------- | | DriversLicense | DRIVER\_LICENSE | 2006 | Isle of Man Driving License | | DriversLicense | DRIVER\_LICENSE | 2022 | Isle of Man Driving License | ### Montserrat | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :-------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2022 | Montserrat Driver's License | ### Scotland | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------ | :------ | :------------------------------------------------ | | IdentificationCard | CITIZENCARD | 2020 | Scotland National Entitlement Card (Saltire card) | ### Wales | Type of ID | Subtype of ID | Version | Description | | :------------- | :-------------- | :------ | :-------------------- | | DriversLicense | DRIVER\_LICENSE | 2007 | Wales Driving License | | DriversLicense | DRIVER\_LICENSE | 2013 | Wales Driving Licence | ## Vatican City (VAT) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :--------- | :----------------- | :------ | :-------------------- | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Passaporto / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Passaporte / Passport | --- ## Supported KYC documents Supported documents are the identification documents that document verification can correctly classify and extract information from. This section lists them by the geographic region where they are issued. Each regional page is organized by country (and by state where relevant) and lists, for every document: - **Type of ID** — the document class (e.g. `Passport`, `DriversLicense`, `IdentificationCard`) - **Subtype of ID** — the specific document variant - **Version** — the issue year of the supported document version - **Description** — the document's official name ## Regions - [Africa](/docs/supported-documents/africa) - [Asia](/docs/supported-documents/asia) - [Caribbean](/docs/supported-documents/caribbean) - [Central America](/docs/supported-documents/central-america) - [Europe](/docs/supported-documents/europe) - [North America](/docs/supported-documents/north-america) - [Oceania](/docs/supported-documents/oceania) - [South America](/docs/supported-documents/south-america) --- ## North America The following tables list supported identification documents for North America, organized by country, then state. ## Canada (CAN) ### All States | Type of ID | Subtype of ID | Version | Description | | :------------------- | :------------------------------ | :------ | :----------------------------------------------------- | | IdentificationCard | IDENTIFICATION\_CARD | 2013 | Identification Card | | IdentificationCard | CANADIAN\_CITIZENSHIP\_CARD | 2002 | Certificate of Canadian Citizenship | | IdentificationCard | CERTIFICATE\_OF\_INDIAN\_STATUS | 2010 | Certificate of Indian Status | | IdentificationCard | CERTIFICATE\_OF\_INDIAN\_STATUS | 2012 | Certificate of Indian Status | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2022 | Citizenship Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2023 | Métis Nation - Saskatchewan Tribal Identification Card | | DriversLicense | DRIVERS\_LICENSE | 2023 | Driver's License | | Military | MILITARY\_CARD | 2010 | Canadian Forces Identification Card | | Military | TEMPORARY\_IDENTIFICATION\_CARD | 2020 | Temporary Identification Card | | Other | FIREARMS\_LICENSE | 2010 | Firearms License | | Other | FIREARMS\_LICENSE | 2020 | Firearms License | | Other | INDIAN\_STATUS\_CERTIFICATE | 2007 | Certificate of Indian Status | | Other | INDIAN\_STATUS\_CERTIFICATE | 2008 | Certificate of Indian Status | | Other | INDIAN\_STATUS\_CERTIFICATE | 2009 | Certificate of Indian Status | | Passport | NATIONAL\_PASSPORT | 2007 | Passport | | Passport | NATIONAL\_PASSPORT | 2013 | Passport | | Passport | NATIONAL\_PASSPORT | 2023 | Passport | | Passport | TEMPORARY\_PASSPORT | 2023 | Temporary Passport / Passeport Provisoire | | ResidenceDocument | RESIDENCE\_PERMIT | 2009 | Permanent Resident Card | | ResidenceDocument | RESIDENCE\_PERMIT | 2013 | Permanent Resident Card | | ResidenceDocument | RESIDENCE\_PERMIT | 2021 | Permanent Resident Card | | Visa | VISA | 2019 | Visa | ### Alberta | Type of ID | Subtype of ID | Version | Description | | :----------------- | :----------------------------- | :------ | :----------------------------------- | | DriversLicense | DRIVER\_LICENSE | 2009 | Alberta Operator's Licence | | DriversLicense | DRIVER\_LICENSE | 2018 | Alberta Driver's Licence | | DriversLicense | DRIVER\_LICENSE | 2026 | Alberta Driver's Licence | | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Alberta Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Alberta Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2026 | Alberta Identification Card | | IdentificationCard | ENHANCED\_IDENTIFICATION\_CARD | 2023 | Alberta Enhanced Identification Card | ### British Columbia | Type of ID | Subtype of ID | Version | Description | | :----------------- | :--------------------------- | :------ | :-------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2020 | British Columbia Driver's Licence | | DriversLicense | DRIVERS\_LICENSE | 2022 | British Columbia Driver's Licence and Services Card | | DriversLicense | DRIVERS\_LICENSE | 2025 | British Columbia Driver's Licence | | DriversLicense | ENHANCED\_DRIVERS\_LICENSE | 2009 | British Columbia Enhanced Driver's Licence | | DriversLicense | LEARNERS\_DRIVERS\_LICENSE | 2020 | British Columbia Learner Driver Licence | | DriversLicense | LEARNERS\_DRIVERS\_LICENSE | 2022 | British Columbia Learner Driver Licence | | IdentificationCard | IDENTIFICATION\_CARD | 2016 | British Columbia Identity Card | | IdentificationCard | IDENTIFICATION\_CARD | 2020 | British Columbia Services Card | | IdentificationCard | IDENTIFICATION\_CARD | 2021 | British Columbia Identity Card | | IdentificationCard | IDENTIFICATION\_CARD | 2025 | British Columbia Identity Card | | MedicalCard | MEDICAL\_CARD | 2010 | British Columbia Care Card | | MedicalCard | SERVICES\_CARD | 2022 | British Columbia Services Card | | Other | SERVICES\_CARD | 2010 | British Columbia Services Card | | Other | SERVICES\_CARD | 2022 | British Columbia Services Card | | Other | TRIBAL\_IDENTIFICATION\_CARD | 2015 | British Columbia Citizenship & ID Card | ### Manitoba | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------- | :------ | :--------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2009 | Manitoba Driver's Licence | | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Manitoba Identification Card | ### Newfoundland | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------- | :------ | :-------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2007 | Newfoundland and Labrador Driver Licence | | DriversLicense | DRIVERS\_LICENSE | 2018 | Newfoundland and Labrador Driver Licence | | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Newfoundland and Labrador Identification Card | | MedicalCard | MEDICAL\_CARD | 2010 | Newfoundland and Labrador Medical Care Plan | ### New Brunswick | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------- | :------ | :----------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2009 | New Brunswick Driver Licence | | DriversLicense | DRIVERS\_LICENSE | 2017 | New Brunswick Driver Licence | | IdentificationCard | IDENTIFICATION\_CARD | 2021 | New Brunswick Identification Card | | MedicalCard | MEDICAL\_CARD | 2010 | New Brunswick Medicare Assurance - maladie | ### Northwest Territories | Type of ID | Subtype of ID | Version | Description | | :----------------- | :-------------------------- | :------ | :----------------------------------------------- | | DriversLicense | DRIVER\_LICENSE | 2008 | Northwest Territories Driver's Licence | | DriversLicense | DRIVER\_LICENSE | 2020 | Northwest Territories Driver's Licence | | DriversLicense | TEMPORARY\_DRIVERS\_LICENSE | 2024 | Northwest Territories Temporary Driver's License | | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Northwest Territories Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Northwest Territories Identification Card | ### Nova Scotia | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------ | :------ | :------------------------------------ | | DriversLicense | DRIVERS\_LICENSE | 2010 | Nova Scotia Driver Licence | | DriversLicense | DRIVERS\_LICENSE | 2017 | Nova Scotia Driver Licence | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2010 | Nova Scotia Driver License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Nova Scotia Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Nova Scotia Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2025 | Nova Scotia Identification Card | | MedicalCard | MEDICAL\_CARD | 2010 | Nova Scotia Health Card | ### Nunavut | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------- | :------ | :-------------------------- | | DriversLicense | DRIVER\_LICENSE | 2008 | Nunavut Driver's Licence | | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Nunavut Identification Card | | MedicalCard | MEDICAL\_CARD | 2010 | Nunavut Health Card | ### Ontario | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------- | :------ | :-------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2011 | Ontario Driver's Licence | | DriversLicense | ENHANCED\_DRIVERS\_LICENSE | 2010 | Ontario Enhanced Driver's License | | IdentificationCard | IDENTIFICATION\_CARD | 2011 | Ontario Photo Card | | MedicalCard | MEDICAL\_CARD | 2020 | Ontario Health Card | | Other | BIRTH\_CERTIFICATE | 2010 | Ontario Birth Certificate | ### Prince Edward Island | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------- | :------ | :--------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2007 | Prince Edward Island Driver Licence | | DriversLicense | DRIVERS\_LICENSE | 2017 | Prince Edward Island Driver Licence | | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Prince Edward Island Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Prince Edward Island Identification Card | | MedicalCard | MEDICAL\_CARD | 2010 | Prince Edward Island Health Card | ### Quebec | Type of ID | Subtype of ID | Version | Description | | :------------- | :-------------- | :------ | :------------------------------------------------ | | DriversLicense | DRIVER\_LICENSE | 2009 | Quebec Permis de conduire (Driver Licence) | | DriversLicense | DRIVER\_LICENSE | 2015 | Quebec Permis de conduire (Driver Licence) | | MedicalCard | MEDICAL\_CARD | 2010 | Quebec Regie de L'assurance maladie (Health Card) | | MedicalCard | MEDICAL\_CARD | 2018 | Quebec Regie de L'assurance maladie (Health Card) | ### Saskatchewan | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------- | :------ | :------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2016 | Saskatchewan Driver's Licence | | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Saskatchewan Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Saskatchewan Identification Card | | Military | MILITARY\_CARD | 2024 | Saskatchewan Military Card | ### Yukon | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------- | :------ | :-------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2010 | Yukon Operator's Licence | | DriversLicense | DRIVERS\_LICENSE | 2024 | Permis de Conduire (Operator's License) | | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Yukon General Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2024 | Yukon General Identification Card | ## Mexico (MEX) ### All States | Type of ID | Subtype of ID | Version | Description | | :------------------ | :----------------------------------------------- | :------ | :--------------------------------------------------------------------------------------------------------------- | | IdentificationCard | IDENTIFICATION\_CARD | 2000 | Cédula Profesional | | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Cédula Profesional | | IdentificationCard | DIGITAL\_IDENTIFICATION\_CARD | 2020 | Digital Cédula Profesional | | IdentificationCard | AIRFORCE\_IDENTIFICATION\_CARD | 2021 | Licencia Federal de Técnico Aeronáutico (Federal Aeronautical Technician License - Airforce Identification Card) | | IdentificationCard | AIRFORCE\_IDENTIFICATION\_CARD | 2024 | Airforce Identification Card | | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2009 | Tarjeta INAPAM | | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2010 | Tarjeta INAPAM | | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2011 | Tarjeta INAPAM | | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2013 | Tarjeta INAPAM | | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2014 | Tarjeta INAPAM | | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2015 | Tarjeta INAPAM | | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2020 | Tarjeta INAPAM | | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2023 | Tarjeta INAPAM | | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2024 | Tarjeta INAPAM | | IdentificationCard | SENIOR\_IDENTIFICATION\_CARD | 2025 | Tarjeta INAPAM | | MedicalCard | MEDICAL\_CARD | 2010 | Tarjera IMSS | | Military | MILITARY\_CARD | 2010 | Military Card | | Military | MILITARY\_CARD | 2018 | Tarjeta de Identidad Militar / Military Card | | Military | MILITARY\_CARD | 2019 | Tarjeta de Identidad Militar (Military Card) | | Military | MILITARY\_CARD | 2021 | Credencial de Identidad Militar | | Military | MILITARY\_CARD | 2022 | Credencial de Identidad Militar | | Military | MILITARY\_CARD | 2024 | Tarjeta de Identidad Militar / Military Card | | Military | MILITARY\_CARD | 2025 | Military Card | | Passport | NATIONAL\_PASSPORT | 2000 | Passport | | Passport | NATIONAL\_PASSPORT | 2002 | Passport | | Passport | NATIONAL\_PASSPORT | 2008 | Passport | | Passport | NATIONAL\_PASSPORT | 2012 | Passport | | Passport | NATIONAL\_PASSPORT | 2015 | Passport | | Passport | NATIONAL\_PASSPORT | 2022 | Passport | | ResidenceDocument | PERMANENT\_RESIDENCE\_CARD | 2000 | Credencial de Residente Permanente | | ResidenceDocument | PERMANENT\_RESIDENCE\_CARD | 2001 | Credencial de Residente Permanente | | ResidenceDocument | PERMANENT\_RESIDENCE\_CARD | 2012 | Credencial de Residente Permanente | | ResidenceDocument | PERMANENT\_RESIDENCE\_CARD | 2020 | Credencial de Residente Permanente | | ResidenceDocument | PERMANENT\_RESIDENCE\_CARD | 2022 | Credencial de Residente Permanente | | ResidenceDocument | RESIDENCE\_PERMIT | 2010 | Credencial de Inmigrado | | ResidenceDocument | TEMPORARY\_RESIDENCE\_CARD | 2000 | Credencial de Residente Temporal | | ResidenceDocument | TEMPORARY\_RESIDENCE\_CARD | 2012 | Credencial de Residente Temporal | | ResidenceDocument | TEMPORARY\_RESIDENCE\_CARD | 2022 | Credencial de Residente Temporal | | ResidenceDocument | VISITORS\_PERMIT | 2020 | Credencial de Visitante | | ResidenceDocument | VISITORS\_PERMIT | 2022 | Credencial de Visitante | | TravelDocument | MATRICULA\_CONSULAR | 2011 | Matricula Consular / Consular ID Card | | TravelDocument | MATRICULA\_CONSULAR | 2019 | Consular ID Card | | TravelDocument | MATRICULA\_CONSULAR | 2023 | Consular ID Card | | TravelDocument | MATRICULA\_CONSULAR | 2024 | Matricula Consular (Consular Card) | | Visa | VISA | 2021 | Visa | | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2002 | Credencial para Votar | | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2008 | Credencial para Votar | | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2013 | Credencial para Votar | | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2014 | Credencial para Votar | | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2019 | Credencial para Votar | | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2026 | Credencial para Votar / Voter Identification Card | | Other | BIRTH\_CERTIFICATE | 2020 | Acta de Nacimiento / Birth Certificate | | Other | DIGITAL\_CURP\_CERTIFICATE\_FOR\_FOREIGNERS\_PDF | 2026 | Digital CURP Cerificate for Foreigners | | DriversLicense | FEDERAL\_DRIVERS\_LICENSE | 2015 | Nationwide Drivers License | | DriversLicense | FEDERAL\_DRIVERS\_LICENSE | 2018 | Nationwide Drivers License | | DriversLicense | FEDERAL\_DRIVERS\_LICENSE | 2019 | Nationwide Drivers License | | DriversLicense | DIGITAL\_FEDERAL\_DRIVERS\_LICENSE\_PDF | 2025 | Digital Federal Driver License | | MedicalCard | MEDICAL\_CARD | 2022 | Credencial del Instituto de Seguridad Social de Estado de México y Municipios | ### Aguascalientes | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :----------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2014 | Aguascalientes Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2017 | Aguascalientes Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2019 | Aguascalientes Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2022 | Aguascalientes Drivers License | ### Baja California | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------- | :------ | :--------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2014 | Baja California Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2016 | Baja California Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2018 | Baja California Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2019 | Baja California Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2020 | Baja California Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2021 | Baja California Drivers License | | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2023 | Baja California Disability Identification Card | ### Baja California Sur | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :---------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2016 | Baja California Sur Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2022 | Baja California Sur Drivers License | ### Campeche | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :----------------------- | | DriversLicense | DRIVERS\_LICENSE | 2019 | Campeche Drivers License | ### CDMX | Type of ID | Subtype of ID | Version | Description | | :------------- | :---------------------------- | :------ | :-------------------------------------------- | | DriversLicense | DRIVER\_LICENSE | 1929 | Mexico City Drivers License | | DriversLicense | DRIVER\_LICENSE | 2000 | Mexico City Drivers License | | DriversLicense | DRIVER\_LICENSE | 2004 | Mexico City Drivers License | | DriversLicense | DRIVER\_LICENSE | 2005 | Mexico City Drivers License | | DriversLicense | DRIVER\_LICENSE | 2014 | Mexico City Drivers License | | DriversLicense | DRIVER\_LICENSE | 2018 | Mexico City Drivers License | | DriversLicense | DRIVER\_LICENSE | 2019 | Mexico City Drivers License | | DriversLicense | DRIVER\_LICENSE | 2021 | Mexico City Drivers License | | DriversLicense | DRIVER\_LICENSE | 2024 | CDMX Licencia para Conducir / Driving License | | DriversLicense | DRIVER\_LICENSE | 2025 | CDMX Licencia para Conducir / Driving License | | DriversLicense | DIGITAL\_DRIVER\_LICENSE\_APP | 2023 | Mexico City Digital Drivers License | | DriversLicense | DIGITAL\_DRIVER\_LICENSE\_APP | 2024 | Mexico City Digital Drivers License | ### Chiapas | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :---------------------- | | DriversLicense | DRIVERS\_LICENSE | 2013 | Chiapas Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2016 | Chiapas Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2017 | Chiapas Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2025 | Chiapas Drivers License | ### Chihuahua | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :------------------------ | | DriversLicense | DRIVERS\_LICENSE | 2016 | Chihuahua Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2017 | Chihuahua Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2019 | Chihuahua Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2020 | Chihuahua Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2021 | Chihuahua Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2022 | Chihuahua Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2024 | Chihuahua Drivers License | ### Coahuila | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :----------------------- | | DriversLicense | DRIVERS\_LICENSE | 2016 | Coahuila Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2020 | Coahuila Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2024 | Coahuila Drivers License | ### Colima | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :--------------------- | | DriversLicense | DRIVERS\_LICENSE | 2016 | Colima Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2017 | Colima Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2018 | Colima Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2022 | Colima Drivers License | ### Durango | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :---------------------- | | DriversLicense | DRIVERS\_LICENSE | 2015 | Durango Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2016 | Durango Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2023 | Durango Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2025 | Durango Drivers License | ### Estado De Mexico | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :--------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2011 | Mexico State Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2014 | Mexico State Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2018 | Mexico State Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2021 | Mexico State Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2022 | Mexico State Drivers License | ### Guanajuato | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2015 | Guanajuato Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2019 | Guanajuato Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2020 | Guanajuato Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2023 | Guanajuato Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2025 | Guanajuato Drivers License | ### Guerrero | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :-------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 1985 | Guerrero Drivers License (Juan R. Escudero) | | DriversLicense | DRIVERS\_LICENSE | 1896 | Guerrero Drivers License (Tecoanapa) | | DriversLicense | DRIVERS\_LICENSE | 1897 | Guerrero Drivers License (Constitucional de Tixtla) | | DriversLicense | DRIVERS\_LICENSE | 1898 | Guerrero Drivers License (Acapulco) | | DriversLicense | DRIVERS\_LICENSE | 1900 | Guerrero Driving License (Taxco) | | DriversLicense | DRIVERS\_LICENSE | 1901 | Guerrero Driving License (Ixcateopan de Cuauhtemoc) | | DriversLicense | DRIVERS\_LICENSE | 1902 | Guerrero Drivers License (Chilpancingo) | | DriversLicense | DRIVERS\_LICENSE | 1903 | Guerrero Drivers License (La Union de Isidoro Montes de Oca) | | DriversLicense | DRIVERS\_LICENSE | 1904 | Guerrero Drivers License (Chilpancingo) | | DriversLicense | DRIVERS\_LICENSE | 1905 | Guerrero Drivers License (Zihuatanejo de Azueta) | | DriversLicense | DRIVERS\_LICENSE | 1906 | Guerrero Drivers License (H. Ayuntamiento de Alcozauca) | | DriversLicense | DRIVERS\_LICENSE | 1908 | Guerrero Drivers License (H. Ayuntamiento Municipal de Cutzamala de Pinzon) | | DriversLicense | DRIVERS\_LICENSE | 1909 | Guerrero Drivers License (Tecpan de Galeana) | | DriversLicense | DRIVERS\_LICENSE | 1910 | Guerrero Drivers License (La Unión de Isidoro Montes de Oca) | | DriversLicense | DRIVERS\_LICENSE | 1911 | Guerrero Drivers License (Huitzuco) | | DriversLicense | DRIVERS\_LICENSE | 1912 | Guerrero Drivers License (H. Ayuntamiento de Apaxtla) | | DriversLicense | DRIVERS\_LICENSE | 1914 | Guerrero Drivers License (Pilcaya) | | DriversLicense | DRIVERS\_LICENSE | 1915 | Guerrero Drivers License (Zitlala) | | DriversLicense | DRIVERS\_LICENSE | 1916 | Guerrero Drivers License (Ayuntamiento de Zirándaro) | | DriversLicense | DRIVERS\_LICENSE | 1919 | Guerrero Drivers License (Hueycantenango) | | DriversLicense | DRIVERS\_LICENSE | 1920 | Guerrero Drivers License (General Canuto A. Neri) | | DriversLicense | DRIVERS\_LICENSE | 1922 | Guerrero Drivers License (Malinaltepec) | | DriversLicense | DRIVERS\_LICENSE | 1925 | Guerrero Drivers License (Chilpancingo de los Bravo) | | DriversLicense | DRIVERS\_LICENSE | 1926 | Guerrero Drivers License (Iguala de la Independencia) | | DriversLicense | DRIVERS\_LICENSE | 1927 | Guerrero Drivers License (General Heliodoro Castillo) | | DriversLicense | DRIVERS\_LICENSE | 1928 | Guerrero Driving License (Taxco) | | DriversLicense | DRIVERS\_LICENSE | 1929 | Guerrero Drivers License (Buenavista de Cuéllar) | | DriversLicense | DRIVERS\_LICENSE | 1930 | Guerrero Driving License (Copalillo) | | DriversLicense | DRIVERS\_LICENSE | 1931 | Guerrero Drivers License (Cocula) | | DriversLicense | DRIVERS\_LICENSE | 1932 | Guerrero Driving License (Coyuca de Benitez) | | DriversLicense | DRIVERS\_LICENSE | 1934 | Guerrero Drivers License | | DriversLicense | DRIVERS\_LICENSE | 1936 | Guerrero Drivers License (Acapulco) | | DriversLicense | DRIVERS\_LICENSE | 1943 | Guerrero Drivers License (General Canuto A. Neri) | | DriversLicense | DRIVERS\_LICENSE | 1944 | Guerrero Drivers License (H. Ayuntamiento de Alcozauca) | | DriversLicense | DRIVERS\_LICENSE | 1948 | Guerrero Drivers License (Malinaltepec) | | DriversLicense | DRIVERS\_LICENSE | 1950 | Guerrero Drivers License (Teloloapan) | | DriversLicense | DRIVERS\_LICENSE | 1951 | Guerrero Drivers License (Chilpancingo) | | DriversLicense | DRIVERS\_LICENSE | 1952 | Guerrero Drivers License (Apaxtla de Castrejon) | | DriversLicense | DRIVERS\_LICENSE | 1953 | Guerrero Drivers License (Juan R. Escudero) | | DriversLicense | DRIVERS\_LICENSE | 1957 | Guerrero Drivers License (Gral. Canuto A. Neri) | | DriversLicense | DRIVERS\_LICENSE | 1959 | Guerrero Drivers License (Municipal Constitucional de Juan R. Escudero) | | DriversLicense | DRIVERS\_LICENSE | 1961 | Guerrero Drivers License (Buenavista de Cuellar) | | DriversLicense | DRIVERS\_LICENSE | 1962 | Guerrero Drivers License (H. Ayuntamiento de Cuautepec) | | DriversLicense | DRIVERS\_LICENSE | 1963 | Guerrero Drivers License (Chilpancingo de los Bravo) | | DriversLicense | DRIVERS\_LICENSE | 1967 | Guerrero Drivers License (La Union de Isidoro Montes de Oca) | | DriversLicense | DRIVERS\_LICENSE | 1969 | Guerrero Drivers License (Acapulco de Juarez) | | DriversLicense | DRIVERS\_LICENSE | 1971 | Guerrero Drivers License (Hueycantenango) | | DriversLicense | DRIVERS\_LICENSE | 1973 | Guerrero Drivers License (Malinaltepec) | | DriversLicense | DRIVERS\_LICENSE | 1974 | Guerrero Drivers License (Acapulco de Juarez) | | DriversLicense | DRIVERS\_LICENSE | 1975 | Guerrero Drivers License (Zihuatanejo de Azueta) | | DriversLicense | DRIVERS\_LICENSE | 1976 | Guerrero Drivers License (Malinaltepec) | | DriversLicense | DRIVERS\_LICENSE | 1979 | Guerrero Drivers License (Tetipac) | | DriversLicense | DRIVERS\_LICENSE | 1980 | Guerrero Drivers License (Tetipac) | | DriversLicense | DRIVERS\_LICENSE | 1982 | Guerrero Drivers License (Pilcaya) | | DriversLicense | DRIVERS\_LICENSE | 1986 | Guerrero Drivers License (Pedro Ascencio Alquisiras) | | DriversLicense | DRIVERS\_LICENSE | 1987 | Guerrero Drivers License (Iliatenco) | | DriversLicense | DRIVERS\_LICENSE | 1989 | Guerrero Drivers License (Iguala de la Independencia) | | DriversLicense | DRIVERS\_LICENSE | 1990 | Guerrero Drivers License (Iguala de la Independencia) | | DriversLicense | DRIVERS\_LICENSE | 1991 | Guerrero Drivers License (Copalillo) | | DriversLicense | DRIVERS\_LICENSE | 1992 | Guerrero Drivers License (Copalillo) | | DriversLicense | DRIVERS\_LICENSE | 1993 | Guerrero Drivers License (Cocula) | | DriversLicense | DRIVERS\_LICENSE | 1994 | Guerrero Drivers License (Chilpancingo) | | DriversLicense | DRIVERS\_LICENSE | 1996 | Guerrero Drivers License | | DriversLicense | DRIVERS\_LICENSE | 1997 | Guerrero Drivers License (Atlamaljancingo del Monte) | | DriversLicense | DRIVERS\_LICENSE | 1998 | Guerrero Drivers License (Atenango del Rio) | | DriversLicense | DRIVERS\_LICENSE | 1999 | Guerrero Drivers License (Acapulco de Juarez) | | DriversLicense | DRIVERS\_LICENSE | 2000 | Guerrero Drivers License (Acapulco de Juarez) | | DriversLicense | DRIVERS\_LICENSE | 2001 | Guerrero Drivers License (Buenavista de Cuellar) | | DriversLicense | DRIVERS\_LICENSE | 2002 | Guerrero Drivers License (Pilcaya) | | DriversLicense | DRIVERS\_LICENSE | 2003 | Guerrero Drivers License (Tlacoapa) | | DriversLicense | DRIVERS\_LICENSE | 2004 | Guerrero Drivers License (Cuetzala del Progreso) | | DriversLicense | DRIVERS\_LICENSE | 2005 | Guerrero Drivers License (Buenavista de Cuellar) | | DriversLicense | DRIVERS\_LICENSE | 2006 | Guerrero Drivers License (Acapulco de Juarez) | | DriversLicense | DRIVERS\_LICENSE | 2007 | Guerrero Drivers License (Tepecoacuilco) | | DriversLicense | DRIVERS\_LICENSE | 2008 | Guerrero Drivers License (Cocula) | | DriversLicense | DRIVERS\_LICENSE | 2009 | Guerrero Drivers License (Pungarabato) | | DriversLicense | DRIVERS\_LICENSE | 2010 | Guerrero Drivers License (Jose Joaquin de Herrera) | | DriversLicense | DRIVERS\_LICENSE | 2011 | Guerrero Drivers License (Tetipac) | | DriversLicense | DRIVERS\_LICENSE | 2012 | Guerrero Drivers License (Copalillo) | | DriversLicense | DRIVERS\_LICENSE | 2013 | Guerrero Drivers License (Gral. Canuto A. Neri) | | DriversLicense | DRIVERS\_LICENSE | 2016 | Guerrero Drivers License (Atlamaljancingo del Monte) | | DriversLicense | DRIVERS\_LICENSE | 2017 | Guerrero Drivers License (Juchitan) | | DriversLicense | DRIVERS\_LICENSE | 2018 | Guerrero Drivers License (Pilcaya) | | DriversLicense | DRIVERS\_LICENSE | 2019 | Guerrero Drivers License (Cocula) | | DriversLicense | DRIVERS\_LICENSE | 2020 | Guerrero Drivers License (Juchitan) | | DriversLicense | DRIVERS\_LICENSE | 2021 | Guerrero Drivers License (Juchitan) | | DriversLicense | DRIVERS\_LICENSE | 2022 | Guerrero Drivers License (Juchitan) | | DriversLicense | DRIVERS\_LICENSE | 2023 | Guerrero Drivers License (State Drivers License) | | DriversLicense | DRIVERS\_LICENSE | 2025 | Guerrero Driving License (Chilpancingo) | | DriversLicense | DRIVERS\_LICENSE | 2026 | Guerrero Driving License (Tabasco) | ### Hidalgo | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :---------------------- | | DriversLicense | DRIVERS\_LICENSE | 2014 | Hidalgo Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2018 | Hidalgo Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2019 | Hidalgo Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2022 | Hidalgo Drivers License | ### Jalisco | Type of ID | Subtype of ID | Version | Description | | :------------- | :-------------- | :------ | :---------------------- | | DriversLicense | DRIVER\_LICENSE | 2004 | Jalisco Drivers Licence | | DriversLicense | DRIVER\_LICENSE | 2013 | Jalisco Drivers Licence | | DriversLicense | DRIVER\_LICENSE | 2017 | Jalisco Drivers Licence | | DriversLicense | DRIVER\_LICENSE | 2018 | Jalisco Drivers Licence | | DriversLicense | DRIVER\_LICENSE | 2019 | Jalisco Drivers Licence | | DriversLicense | DRIVER\_LICENSE | 2020 | Jalisco Drivers Licence | | DriversLicense | DRIVER\_LICENSE | 2021 | Jalisco Drivers Licence | | DriversLicense | DRIVER\_LICENSE | 2022 | Jalisco Drivers Licence | | DriversLicense | DRIVER\_LICENSE | 2024 | Jalisco Drivers License | ### Michoacan | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :------------------------ | | DriversLicense | DRIVERS\_LICENSE | 2012 | Michoacan Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2017 | Michoacan Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2018 | Michoacan Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2020 | Michoacan Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2022 | Michoacan Drivers License | ### Morelos | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :---------------------- | | DriversLicense | DRIVERS\_LICENSE | 2015 | Morelos Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2019 | Morelos Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2020 | Morelos Driving License | | DriversLicense | DRIVERS\_LICENSE | 2024 | Morelos Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2025 | Morelos Drivers License | ### Nayarit | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :---------------------- | | DriversLicense | DRIVERS\_LICENSE | 2016 | Nayarit Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2018 | Nayarit Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2019 | Nayarit Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2021 | Nayarit Drivers License | ### Nuevo Leon | Type of ID | Subtype of ID | Version | Description | | :------------- | :-------------- | :------ | :------------------------- | | DriversLicense | DRIVER\_LICENSE | 2016 | Nuevo Leon Drivers License | | DriversLicense | DRIVER\_LICENSE | 2017 | Nuevo Leon Drivers License | | DriversLicense | DRIVER\_LICENSE | 2018 | Nuevo Leon Drivers License | | DriversLicense | DRIVER\_LICENSE | 2020 | Nuevo Leon Drivers License | | DriversLicense | DRIVER\_LICENSE | 2021 | Nuevo Leon Drivers License | | DriversLicense | DRIVER\_LICENSE | 2022 | Nuevo Leon Drivers License | ### Oaxaca | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :--------------------- | | DriversLicense | DRIVERS\_LICENSE | 2018 | Oaxaca Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2019 | Oaxaca Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2023 | Oaxaca Drivers License | ### Puebla | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :--------------------- | | DriversLicense | DRIVERS\_LICENSE | 2014 | Puebla Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2015 | Puebla Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2016 | Puebla Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2018 | Puebla Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2019 | Puebla Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2020 | Puebla Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2023 | Puebla Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2024 | Puebla Driving License | | DriversLicense | DRIVERS\_LICENSE | 2025 | Puebla Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2026 | Puebla Drivers License | ### Queretaro | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :------------------------ | | DriversLicense | DRIVERS\_LICENSE | 2015 | Queretaro Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2016 | Queretaro Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2017 | Queretaro Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2022 | Queretaro Drivers License | ### Quintana Roo | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :---------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 1997 | Quintana Roo Drivers License (Felipe Carrillo Puerto) | | DriversLicense | DRIVERS\_LICENSE | 1999 | Quintana Roo Drivers License (Felipe Carillo Puerto) | | DriversLicense | DRIVERS\_LICENSE | 2000 | Quintana Roo Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2001 | Quintana Roo Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2002 | Quintana Roo Drivers License (Othon P. Blanco) | | DriversLicense | DRIVERS\_LICENSE | 2004 | Quintana Roo Drivers License (Puerto Morelos) | | DriversLicense | DRIVERS\_LICENSE | 2006 | Quintana Roo Drivers License (Felipe Carillo Puerto) | | DriversLicense | DRIVERS\_LICENSE | 2007 | Quintana Roo Drivers License (Bacalar) | | DriversLicense | DRIVERS\_LICENSE | 2009 | Quintana Roo Drivers License (Solidaridad) | | DriversLicense | DRIVERS\_LICENSE | 2010 | Quintana Roo Drivers License (Benito Juarez) | | DriversLicense | DRIVERS\_LICENSE | 2011 | Quintana Roo Drivers License (Lazaro Cardenas) | | DriversLicense | DRIVERS\_LICENSE | 2012 | Quintana Roo Drivers License (Jose Maria Morelos) | | DriversLicense | DRIVERS\_LICENSE | 2013 | Quintana Roo Driving License | | DriversLicense | DRIVERS\_LICENSE | 2014 | Quintana Roo Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2015 | Quintana Roo Drivers License (Tulum) | | DriversLicense | DRIVERS\_LICENSE | 2016 | Quintana Roo Drivers License (Cozumel) | | DriversLicense | DRIVERS\_LICENSE | 2017 | Quintana Roo Drivers License (Cozumel) | | DriversLicense | DRIVERS\_LICENSE | 2018 | Quintana Roo Drivers License (Tulum) | | DriversLicense | DRIVERS\_LICENSE | 2019 | Quintana Roo Drivers License (Benito Juarez) | | DriversLicense | DRIVERS\_LICENSE | 2020 | Quintana Roo Drivers License (Solidaridad) | | DriversLicense | DRIVERS\_LICENSE | 2021 | Quintana Roo Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2022 | Quintana Roo Drivers License (Solidaridad) | | DriversLicense | DRIVERS\_LICENSE | 2023 | Quintana Roo Drivers License (Puerto Morelos) | | DriversLicense | DRIVERS\_LICENSE | 2024 | Quintana Roo Drivers License (Solidaridad) | ### San Luis Potosi | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :------------------------------ | | DriversLicense | DRIVERS\_LICENSE | 2017 | San Luis Potosi Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2020 | San Luis Potosi Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2021 | San Luis Potosi Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2025 | San Luis Potosi Drivers License | ### Sinaloa | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :---------------------- | | DriversLicense | DRIVERS\_LICENSE | 2010 | Sinaloa Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2015 | Sinaloa Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2018 | Sinaloa Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2019 | Sinaloa Drivers License | ### Sonora | Type of ID | Subtype of ID | Version | Description | | :------------- | :-------------- | :------ | :--------------------- | | DriversLicense | DRIVER\_LICENSE | 2015 | Sonora Drivers License | | DriversLicense | DRIVER\_LICENSE | 2016 | Sonora Drivers License | | DriversLicense | DRIVER\_LICENSE | 2022 | Sonora Drivers License | ### Tabasco | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :---------------------- | | DriversLicense | DRIVERS\_LICENSE | 2013 | Tabasco Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2019 | Tabasco Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2021 | Tabasco Drivers License | ### Tamaulipas | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2019 | Tamaulipas Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2020 | Tamaulipas Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2021 | Tamaulipas Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2022 | Tamaulipas Drivers License | ### Tlaxcala | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :----------------------- | | DriversLicense | DRIVERS\_LICENSE | 2019 | Tlaxcala Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2022 | Tlaxcala Drivers License | ### Veracruz | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :----------------------- | | DriversLicense | DRIVERS\_LICENSE | 2016 | Veracruz Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2017 | Veracruz Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2018 | Veracruz Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2019 | Veracruz Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2022 | Veracruz Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2025 | Veracruz Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2026 | Veracruz Drivers License | ### Yucatan | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :---------------------- | | DriversLicense | DRIVERS\_LICENSE | 2018 | Yucatan Drivers License | ### Zacatecas | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :------------------------ | | DriversLicense | DRIVERS\_LICENSE | 2014 | Zacatecas Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2015 | Zacatecas Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2017 | Zacatecas Drivers License | | DriversLicense | DRIVERS\_LICENSE | 2018 | Zacatecas Drivers License | ## United Nations (UNO) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :----------------------------- | :------ | :--------------------------- | | ALL | Military | MILITARY\_CARD | 2020 | Military Card | | ALL | IdentificationCard | UNHCR\_CARD | 2022 | UNHCR Card | | ALL | IdentificationCard | UNHCR\_CARD | 2023 | UNCHR Card | | ALL | IdentificationCard | UNHCR\_CARD | 2024 | UNCHR Card | | ALL | DriversLicense | DRIVING\_PERMIT | 2022 | Driving Permit | | ALL | DriversLicense | INTERNATIONAL\_DRIVING\_PERMIT | 2024 | International Driving Permit | | ALL | TravelDocument | LAISSEZ\_PASSER | 2022 | Laissez Passer | | ALL | TravelDocument | LAISSEZ\_PASSER | 2023 | Laissez Passer | | ALL | Passport | PASSPORT | 2012 | Laisses-Passer (Passport) | ## USA (USA) ### All States | Type of ID | Subtype of ID | Version | Description | | :------------------- | :------------------------------------- | :------ | :--------------------------------------------------------------------------------------------- | | TribalIdentification | ENHANCED\_TRIBAL\_IDENTIFICATION\_CARD | 2025 | Enhanced Tribal Identification Card | | TribalIdentification | ENHANCED\_TRIBAL\_IDENTIFICATION\_CARD | 2026 | Enhanced Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1831 | Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1832 | Narragansett Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1833 | Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1834 | Tribel Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1845 | Northern Arapaho Tribe of Wyoming Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1849 | Chemehuevi Indian Tribe | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1851 | Susanville Indian Rancheria | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1852 | Association Of Village Council Presidents Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1854 | Moak Tribe Of Western Shoshone Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1855 | Picayune Ranceria of the Chukchansi Indians Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1857 | Kickapoo Traditional Tribe Of Texas Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1859 | Apache Tribe Of Oklahoma Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1862 | Eastern Shoshone Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1967 | Ho-Chunk Nation Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1968 | Kalispel Tribe Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1969 | Cyrene Marie Red Elk Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1871 | Redding Rancheria Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1872 | Seminole Tribe of Florida Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1873 | Village Of Wainwright Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1875 | Spokane Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1879 | The San Carlos Apache Tribe Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1886 | Confederated Tribes Of The Warm Springs Reservation Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1897-98 | Stillaguamish Tribe Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1898 | Yurok Tribe Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1899 | Mashantucket Pequot Tribal Nation Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1900 | Central Council of the Tlingit and Haida Indian Tribes of Alaska Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1903 | Ute Indian Tribe Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1904 | Nottawaseppi Huron Band of the Potawatomi Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1908 | Native Village of Point Hope Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1909 | Quartz Valley Indian Reservation Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1914 | White Mountain Apache Tribe Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1916 | Native Village of Ouzinkie Tribal ID | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1918 | Nez Perce Tribe Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1919 | Fond Du Lac Band of Lake Superior Chippewa Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1920 | Winnebago Tribe of Nebraska Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1921 | Native Village of Kotzebue Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1922 | Bear River Band of Rohnerville Rancheria Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1923 | White Earth Reservation Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1924 | Pueblo of Laguna Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1925 | Quinault Indian Nation Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1926 | The Klamath Tribe Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1927 | Traditional Village of Togiak Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1928 | Shakopee Mdewakanton Sioux Community Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1929 | Little Traverse Bay Bands of Odawa Indians Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1930 | Eastern Band of Cherokee indians Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1932 | Cowlitz Indian Tribe Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1933 | Yavapai - Apache Nation Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1934 | Comanche Nation Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1937 | Grand Traverse Band of Ottawa and Chippewa Indians Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1943 | Lummi Nation Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1948 | Native Village of Eyak Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1949 | Sitka Tribe of Alaska Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1950 | Saint Regis Mohawk Tribe Identity Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1951 | Choctaw Nation of Oklahoma Tribal Identity Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1952 | Alabama - Coushatta Tribe Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1958 | Fort Peck Sioux Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1960 | Ute Mountain Ute Tribe Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1961 | Lummi Nation Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1964 | The Tulalip Tribe Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1965 | Oneida Nation Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1966 | Seneca Nation of Indians Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1967 | Quechan Tribe Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1969 | North Fork Rancheria of Mono Indians of California Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1972 | Fort Belknap Indian Community Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1973 | The Shoshone - Bannock Tribes Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1974 | Enhanced Tribal Identification Card (The Confederated Salish and Kootenai Tribes) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1975 | Lac Courte Oreilles Tribal Membership Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1976 | Tribal Identification Card (Three Affiliated Tribes of the Fort Berthold Reservation) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1977 | Tribal Membership Identification Card (Bishop Paiute Tribe) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1978 | Tribal Identification Card (Muckleshoot Indian Tribe) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1979 | Pascua Yaqui Tribe Membership Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1980 | Tribal Identification Card (Northern Cheyenne Tribe) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1981 | Tribal Identification Card (Muscogee - Creek Nation Citizenship ID) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1984 | Tribal Identification Card (Northern Arapaho Tribe) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1985 | Tribal Identification Card (Rosebud Sioux Tribe) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1986 | Tribal Identification Card (Mescalero Apache Tribe) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1987 | Tribal Identification Card (Confederated Tribes and Bands of the Yakama Nation) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1988 | Tribal Identification Card (Assiniboine and Sixous Tribes) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1989 | Cheyenne and Arapaho Tribes Membership Identification | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1990 | Tribal Identification Card (Lac Vieux Desert Band of Lake Superior Chippewa) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1992 | Lower Brule Sioux Tribal Member Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1993 | Tribal Membership Identification Card (Tonka Tribe of Oklahoma) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1994 | Lower Elwha Klallam Tribe Membership Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1995 | Tribal Identification Card (Kiowa Tribe) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1996 | White Earth Reservation Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1997 | Santee Sioux Nation Tribal Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1998 | Tribal Identification Card (St. Croix Chippewa of Wisconsin Tribe) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 1999 | Tribal Identification Card (Citizen Potawatomi Nation) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2000 | Tribal Identification Card (Sac and Fox Nation) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2001 | Official Membership ID Card (Oglala Sioux Tribe) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2003 | Tribal Identification Card (Coeur D'Alene Tribe) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2004 | Tribal Identification Card (Salt River Pima-Maricopa Indian Community) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2005 | Tribal Identification Card (Citizen of the Cherokee Nation) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2006 | Tribal Enrollment Identification Card (Chippewa Cree Tribe) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2007 | Tribal Identification Card (Turtle Mountain Band of Chippewa Indians) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2008 | Official Tribal Identification Card of Leech Lake Band of Ojibwe | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2009 | Tribal Identification Card (Red Lake Band of Chippewa Indians) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD\_UNDER21 | 2009 | Reno Sparks Indian Colony Tribal Identification Card (Under 21) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2010 | Tribal Identification Card (Mississippi Band of Choctaw Indians) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD\_UNDER21 | 2010 | Three Affiliated Tribes of the Fort Berthold Reservation Tribal Identification Card (Under 21) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2016 | Tribal Identification Card (The Blackfeet Nation) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2017 | Muscogee (Creek) Nation Citizenship ID | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2018 | Bois Forte Band of Chippewa Membership Identification | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2019 | Tribal Identification Card (Sisseton-Wahpeton Oyate Tribe) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2020 | Tribal Identification Card (Omaha Tribe of Nebraska) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2021 | Crow Tribal Membership Identification | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD\_UNDER21 | 2016 | Hoopa Valley Tribal Minor Identification Card (Under 21) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD\_UNDER21 | 2017 | Ute Indian Tribe Minor Identification Card (Under 21) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD\_UNDER21 | 2021 | Bear River Band of Rohnerville Rancheira Tribal Identity Card (Under 21) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2022 | Tribal Identification Card (Mille Lacks Band of Ojibwe) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2023 | Tribal Identification Card (Standing Rock Sioux Tribe) | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2024 | Menominee Tribe of Wisconsin Identification Card | | TribalIdentification | TRIBAL\_IDENTIFICATION\_CARD | 2025 | Native Village of Savoonga Tribal Identification Card | | DriversLicense | FOREIGN\_DRIVERS\_LICENSE | 2022 | Foreign Driver License | | Passport | NATIONAL\_PASSPORT | 2006 | Passport | | Passport | NATIONAL\_PASSPORT | 2020 | Passport | | Passport | NATIONAL\_PASSPORT | 2021 | Passport | | Passport | NATIONAL\_PASSPORT | 2022 | Passport | | ResidenceDocument | PERMANENT\_RESIDENCE\_CARD | 2017 | Permanent Residence Card | | TravelDocument | GLOBAL\_ENTRY | 2008 | Global Entry Card | | TravelDocument | NEXUS | 2008 | NEXUS Card | | TravelDocument | SENTRI | 2008 | SENTRI Card | | TravelDocument | FASTEXPRES | 2008 | FAST/EXPRESS Card | | Other | BIRTH\_CERTIFICATE | 2010 | Certificate of Live Birth | | Other | BIRTH\_CERTIFICATE | 2011 | Birth Certificate | | MedicalCard | SOCIAL\_SECURITY\_CARD | 2016 | Social Security Card | ### Alabama | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2005 | Alabama Driver License / Vessel License / FN Vessel License / FN Commercial Driver License / FN Driver License / FN Nonresident Vessel License / Nonresident Vessel License | | DriversLicense | DRIVERS\_LICENSE | 2010 | Alabama Driver License / Commercial Driver License | | DriversLicense | LEARNERS\_PERMIT | 2010 | Alabama Learner's Permit | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2010 | Alabama Driver License (Under 21) / Graduated Driver License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2005 | Alabama Nondriver Identification Card / FN Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Alabama Nondriver Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2010 | Alabama Nondriver Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2010 | Alabama Firearms License | ### Alaska | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------------- | :------ | :--------------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2014 | Alaska Driver License / Commercial License / Driver - Motorcycle License | | DriversLicense | DRIVERS\_LICENSE | 2019 | Alaska Driver License / Commercial Driver's License / CDL & Motorcycle License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2014 | Alaska Driver License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2019 | Alaska Driver License (Under 21) / Commercial Driver's License (Under 21)  / CDL & Motorcycle License (Under 21) | | DriversLicense | DRIVERS\_LICENSE | 2025 | Alaska Driver License | | DriversLicense | LEARNERS\_PERMIT | 2019 | Alaska Driver Permit / Commercial Learner's Permit | | DriversLicense | LEARNERS\_PERMIT | 2025 | Alaska Driver Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2019 | Alaska Driver Permit (Under 21) / Commercial Learner's Permit (Under 21) | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2019 | Alaska Provisional Driver License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2014 | Alaska Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Alaska Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2019 | Alaska Identification Card (Under 21) | | Other | IDENTIFICATION\_CARD | 2023 | Alaska Identification Card for Inmates | | Other | FIREARMS\_LICENSE | 2020 | Alaska Concealed Handgun Permit | ### Arizona | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :------------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2001 | Arizona Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2014 | Arizona Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2023 | Arizona Driver License / Commercial Driver License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2001 | Arizona Driver License (Under 21) / Graduated Driver License (Under 21) / Commercial Driver License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2014 | Arizona Driver License (Under 21) / Graduated Driver License (Under 21) / Commercial Driver License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2023 | Arizona Driver License (Under 21) / Graduated Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2001 | Arizona Instruction Permit | | DriversLicense | LEARNERS\_PERMIT | 2014 | Arizona Instruction Permit | | DriversLicense | LEARNERS\_PERMIT | 2023 | Arizona Instruction Permit / Limited - Term Instruction Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2001 | Arizona Instruction Permit (Under 21) / Graduated Instruction Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2014 | Arizona Instruction Permit (Under 21) / Graduated Instruction Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2023 | Arizona Instruction Permit (Under 21) / Graduated Instruction Permit (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2001 | Arizona Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2014 | Arizona Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Arizona Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2001 | Arizona Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2014 | Arizona Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2023 | Arizona Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2020 | Arizona Concealed Weapons Permit | ### Arkansas | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :----------------------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2011 | Arkansas Driver's License / Commercial Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2018 | Arkansas Driver's License / Commercial Driver's License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2011 | Arkansas Driver's License (Under 21) / Commercial Driver's License (Under 21) / Intermediate Driver's License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2018 | Arkansas Driver's License (Under 21) / Commercial Driver's License (Under 21) / Intermediate Driver's License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2006 | Arkansas Non Driver Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2011 | Arkansas Non - Driver's Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Arkansas Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2015 | Arkansas Non - Driver's Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2018 | Arkansas Identification Card (Under 21) | | Other | ENHANCED\_FIREARMS\_LICENSE | 2020 | Arkansas Concealed Handgun Carry License | ### California | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------------- | :------ | :-------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2000 | California Driver License | | DriversLicense | DRIVERS\_LICENSE | 2010 | California Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2018 | California Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2025 | California Driver License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2000 | California Driver License (Under 21) / Commercial Driver License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2010 | California Driver License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2018 | California Driver License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2025 | California Driver License (Under 21) | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2010 | California Provisional Driver License (Under 21) | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2018 | California Provisional Driver License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2000 | California Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2010 | California Identification Card / Senior Citizen Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2018 | California Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2025 | California Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2018 | California Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2025 | California Identification Card (Under 21) | | Other | IDENTIFICATION\_CARD | 2018 | San Francisco City ID Card | | Other | FIREARMS\_LICENSE | 2009 | California License to Carry Concealed Pistol, Revolver or other Firearm | | Other | FIREARMS\_LICENSE | 2025 | California Firearms License | ### Colorado | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :------------------------------------------------------------------------------------------------ | | DriversLicense | DRIVERS\_LICENSE | 2014 | Colorado Driver License / Commercial Driver License / Restricted License / Probationary License / | | DriversLicense | DRIVERS\_LICENSE | 2016 | Colorado Driver License / Commercial Driver License / Restricted Driver License | | DriversLicense | DRIVERS\_LICENSE | 2020 | Colorado Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2022 | Colorado Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2016 | Colorado Driver License (Under 21) / Restricted Driver License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2020 | Colorado Driver License (Under 21) / Commercial Driver License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2022 | Colorado Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2014 | Colorado Instruction Permit / Restricted Permit | | DriversLicense | LEARNERS\_PERMIT | 2016 | Colorado Instruction Permit / Restricted Permit | | DriversLicense | LEARNERS\_PERMIT | 2020 | Colorado Instruction Permit / Commercial Learner Permit | | DriversLicense | LEARNERS\_PERMIT | 2022 | Colorado Instruction Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2016 | Colorado Instruction Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2020 | Colorado Instruction Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2022 | Colorado Instruction Permit (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2014 | Colorado Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Colorado Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Colorado Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2022 | Colorado Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2016 | Colorado Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2019 | Colorado Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2022 | Colorado Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2010 | Colorado Concealed Handgun Permit | | Other | FIREARMS\_LICENSE | 2020 | Colorado Concealed Handgun Permit | ### Connecticut | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :---------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2011 | Connecticut Driver License / Commercial Driver License / Commercial Driver Instruction Permit | | DriversLicense | DRIVERS\_LICENSE | 2017 | Connecticut Driver License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2011 | Connecticut Driver License (Under 21) / Motorcycle Permit (Under 21) / Commercial Driver License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2017 | Connecticut Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2011 | Connecticut Adult Learner Permit | | DriversLicense | LEARNERS\_PERMIT | 2017 | Connecticut Adult Learner Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2011 | Connecticut Learner Permit (Under 21) / Adult Learner Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2017 | Connecticut Learner Permit (Under 21) / Adult Learner Permit (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2011 | Connecticut Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Connecticut Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2011 | Connecticut Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2017 | Connecticut Identification Card (Under 21) | | Other | IDENTIFICATION\_CARD | 2020 | Connecticut Park City Resident Card | | Other | FIREARMS\_LICENSE | 2010 | Connecticut Permit to Carry Pistols and Revolvers | ### Delaware | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :---------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2010 | Delaware Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2018 | Delaware Driver License / Commercial Driver's License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2010 | Delaware Driver License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2018 | Delaware Driver License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Delaware Non-Driver Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Delaware Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2010 | Delaware Non-Driver Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2018 | Delaware Identification Card (Under 21) | | Other | BIRTH\_CERTIFICATE | 2020 | Delaware Birth Certificate | ### District Of Columbia | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :-------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2002 | Washington, D.C. Driver's License / Commercial Driver's License / Learner's Permit / CDL Learner's Permit | | DriversLicense | DRIVERS\_LICENSE | 2023 | Washington, DC Driver License | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2023 | Washington DC Learner Permit | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE | 2023 | Washington DC Provisional Driver License | | DriversLicense | LEARNERS\_PERMIT | 2023 | Washington, DC Learner Permit | | DriversLicense | DRIVERS\_LICENSE | 2017 | Washington, DC Driver License / Temporary Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2017 | Washington, DC Driver License (Under 21) / Temporary Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2017 | Washington, DC Learner Permit (Under 21) / Temporary Learner Permit (Under 21) | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE | 2017 | Washington, DC Provisional Driver License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2013 | District of Columbia Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Washington, DC Identification Card / Temporary Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Washington, DC Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2013 | District of Columbia Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2017 | Washington, DC Identification Card (Under 21)  / Temporary Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2023 | Washington, DC Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2010 | District of Columbia Concealed Carry Pistol License | ### Florida | Type of ID | Subtype of ID | Version | Description | | :----------------- | :--------------------------------------- | :------ | :------------------------------------------------------------------ | | DriversLicense | DRIVERS\_LICENSE | 2004 | Florida Driver License / Learner License / CDL | | DriversLicense | DRIVERS\_LICENSE | 2017 | Florida Driver License / CDL | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2004 | Florida Driver License (Under 21) / CDL (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2017 | Florida Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2004 | Florida Learner License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2017 | Florida Learner's License / Learner's Permit / CDL Learner's Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2017 | Florida Learner's License (Under 21) | | DriversLicense | TEMPORARY\_DRIVERS\_LICENSE | 2017 | Florida Temporary Driver License | | DriversLicense | TEMPORARY\_LEARNERS\_PERMIT | 2017 | Florida Temporary Learner's License | | IdentificationCard | IDENTIFICATION\_CARD | 1999 | Florida Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2013 | Florida Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Florida Identification Card | | IdentificationCard | TEMPORARY\_IDENTIFICATION\_CARD | 2017 | Florida Temporary Identification Card | | IdentificationCard | TEMPORARY\_IDENTIFICATION\_CARD\_UNDER21 | 2017 | Florida Temporary Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2013 | Florida Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2017 | Florida Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2020 | Florida Concealed Weapon or Firearm License | | Other | FIREARMS\_LICENSE | 2025 | Statewide Firearm License | ### Georgia | Type of ID | Subtype of ID | Version | Description | | :------------------ | :------------------------------------- | :------ | :-------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2012 | Georgia Driver's License / Limited - Term Driver's License / Commercial Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2019 | Georgia Driver's License / Limited - Term Driver's License / Commercial Driver's License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2012 | Georgia Driver's License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2019 | Georgia Driver's License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2012 | Georgia DL Instructional Permit / Commercial Learner's Permit | | DriversLicense | LEARNERS\_PERMIT | 2019 | Georgia DL Instructional Permit / CDL Instructional Permit / Limited - Term DL Instructional Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2012 | Georgia DL Instructional Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2019 | Georgia DL Instructional Permit (Under 21)  /  Limited - Term DL Instructional Permit (Under 21) | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE | 2012 | Georgia Provisional Driver's License | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2019 | Georgia Provisional Driver's License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2012 | Georgia Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Georgia Identification Card / Limited - Term Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2012 | Georgia Identification Card (Under 21) / ID for Voting Purpose | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2019 | Georgia Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2020 | Georgia Weapons Carry License | | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2022 | Georgia Voter Identification Card | ### Guam | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :----------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2017 | Guam Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2019 | Guam Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2020 | Guam Driver's License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2019 | Guam Driver's License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2020 | Guam Driver's License (Under 21) / Intermediate License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Guam Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Guam Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2018 | Guam Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2019 | Guam Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2021 | Guam Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2010 | Guam Firearm Identification Card | ### Hawaii | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------------- | :------ | :--------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2015 | Hawaii Driver License | | DriversLicense | DRIVERS\_LICENSE | 2021 | Hawaii Limited Purpose Driver License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2009 | Hawaii Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2009 | Hawaii Driver License - PERMIT | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2009 | Hawaii Driver License - PERMIT (Under 21) | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2009 | Hawaii Driver License - PROVISIONAL (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Hawaii Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2014 | Hawaii Identification Card (Under 21) | ### Idaho | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2011 | Idaho Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2016 | Idaho Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2023 | Idaho Driver's License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2011 | Idaho Driver's License (Under 21) / Commercial Driver's License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2016 | Idaho Driver's License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2023 | Idaho Driver's License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2016 | Idaho Instruction Permit | | DriversLicense | LEARNERS\_PERMIT | 2023 | Idaho Instruction Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2016 | Idaho Instruction Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2023 | Idaho Instruction Permit (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2011 | Idaho Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Idaho Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Idaho Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2018 | Idaho Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2023 | Idaho Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2013 | Idaho Concealed Weapons License | | Other | FIREARMS\_LICENSE | 2016 | Idaho Concealed Weapons License | | Other | ENHANCED\_FIREARMS\_LICENSE | 2023 | Idaho Enhanced Concealed Weapons License | ### Illinois | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :----------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2007 | Illinois Driver's License / CDL | | DriversLicense | DRIVERS\_LICENSE | 2016 | Illinois Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2020 | Illinois Driver's License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2016 | Illinois Driver's License (Under 21) / TVDL (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2007 | Illinois ID Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2007 | Illinois ID Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Illinois Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Illinois Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2016 | Illinois Identification Card (Under 21) | | Other | IDENTIFICATION\_CARD | 2000 | Illinois Identification Card | | Other | IDENTIFICATION\_CARD | 2020 | City of Chicago Identification Card (Illinois) | | Other | FIREARMS\_LICENSE | 2010 | Illinois Concealed Carry License | | Other | FIREARMS\_LICENSE | 2024 | Illinois Firearm Owner's Identification Card | ### Indiana | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2010 | Indiana Operator License / Commercial Driver's License / DUP Operator Driver License / Motorcycle Only License / Amend Commercial Driver License / Chauffeur License | | DriversLicense | DRIVERS\_LICENSE | 2019 | Indiana Operator License / Commercial Driver's License / Driver's License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2019 | Indiana Driver's License (Under 21) / Operator License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2019 | Indiana Learner Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2010 | Indiana Learner Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2019 | Indiana Learner Permit (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Indiana Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Indiana Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2010 | Indiana Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2019 | Indiana Identification Card (Under 21) | | Other | IDENTIFICATION\_CARD | 2020 | City of Union / City Municipal Identification Card | | Other | FIREARMS\_LICENSE | 2020 | Indiana License to Carry Handgun | ### Iowa | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :------------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2013 | Iowa Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2018 | Iowa Driver License / Limited - Term Driver License / Commercial Driver License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2013 | Iowa Driver License (Under 21) / Commercial Driver License (Under 21) / Intermediate Driver License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2018 | Iowa Driver License (Under 21) / Commercial Driver License (Under 21) / Intermediate Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2018 | Iowa Limited - Term Instruction Permit / Instruction Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2013 | Iowa Instruction Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2018 | Iowa Instruction Permit (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2005 | Iowa Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2013 | Iowa Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Iowa Identification Card / Limited - Term Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2013 | Iowa Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2018 | Iowa Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2013 | Iowa Non - Professional Permit to carry weapons | ### Kansas | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :----------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2004 | Kansas Driver's License / CDL | | DriversLicense | DRIVERS\_LICENSE | 2012 | Kansas Driver's License / Commercial Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2017 | Kansas Driver's License / Commercial Driver's License / Learner's Permit / Commercial Learner's Permit | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2012 | Kansas Driver's License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2017 | Kansas Driver's License / Commercial Driver's License (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2017 | Kansas Learner's Permit (Under 21) / Commercial Learner's Permit (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2012 | Kansas Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Kansas Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2012 | Kansas Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2017 | Kansas Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2017 | Kansas Concealed Carry License | ### Kentucky | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------------------ | :------ | :----------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2004 | Kentucky Hardship Driver's License / Kentucky Commercial Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2012 | Kentucky Driver's License / Kentucky Commercial Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2019 | Kentucky Driver's License / Kentucky Commercial Driver's License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2012 | Kentucky Driver's License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2019 | Kentucky Driver's License (Under 21) / Commercial Driver's License Limited - Term | | DriversLicense | LEARNERS\_PERMIT | 2011 | Kentucky Instruction Permit | | DriversLicense | LEARNERS\_PERMIT | 2019 | Kentucky Instruction Permit / Commercial Learner's Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2012 | Kentucky Instruction Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2019 | Kentucky Instruction Permit (Under 21)  / Commercial Driver's License Limited - Term | | IdentificationCard | IDENTIFICATION\_CARD | 2012 | Kentucky Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Kentucky Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2012 | Kentucky Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2019 | Kentucky Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_VALID\_WITHOUT\_PHOTO | 2019 | Kentucky Identification Card (valid without photo) | | Other | FIREARMS\_LICENSE | 2009 | Kentucky Concealed Deadly Weapons License | ### Louisiana | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :----------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2001 | Louisiana Personal Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2013 | Louisiana Personal Driver's License / Chauffeur's License / Commercial License | | DriversLicense | DRIVERS\_LICENSE | 2015 | Louisiana Personal Driver's License / Chauffeur's License / Commercial License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2015 | Louisiana Personal Driver's License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2015 | Louisiana Temporary Instructional Permit / Commercial Learner's Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2015 | Louisiana Temporary Instructional Permit (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2001 | Louisiana Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2013 | Louisiana Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Louisiana Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2015 | Louisiana Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2020 | Louisiana Concealed Handgun Permit | | Other | FIREARMS\_LICENSE | 2025 | Louisiana Concealed Handgun Permit | ### Maine | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2011 | Maine Driver's License / CDL Operator | | DriversLicense | DRIVERS\_LICENSE | 2019 | Maine Driver's License / Commercial Driver's License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2011 | Maine Driver's License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2019 | Maine Driver's License (Under 21) / Commercial Driver's License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2011 | Maine Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Maine Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2011 | Maine Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2019 | Maine Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2010 | Maine Permit to Carry Concealed Firearms | ### Mariana Islands | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------ | :------ | :---------------------------------------------------------------------- | | IdentificationCard | IDENTIFICATION\_CARD | 2014 | Mariana Islands Identification Card | | DriversLicense | DRIVERS\_LICENSE | 2020 | Mariana Islands Driver License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2020 | Mariana Islands Driver License (Under 21) / Driver License Limited Term | | Other | DRIVERS\_LICENSE | 2023 | Mariana Islands Driver's License | | Other | DRIVERS\_LICENSE\_UNDER21 | 2025 | Mariana Islands Driver's License (Under 21) | | Other | IDENTIFICATION\_CARD | 2025 | Municipality of Saipan Identification Card | ### Maryland | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------------- | :------ | :---------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2002 | Maryland Driver's License / Commercial Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2016 | Maryland Driver's License / Commercial Driver's License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2016 | Maryland Driver's License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2002 | Maryland Learner's Instructional Permit / Moped Operator's Permit | | DriversLicense | LEARNERS\_PERMIT | 2017 | Maryland Learner's Instructional Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2016 | Maryland Learner's Instructional Permit (Under 21) | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE | 2002 | Maryland Provisional Driver's License | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE | 2017 | Maryland Provisional Driver's License | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2016 | Maryland Provisional Driver's License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2002 | Maryland Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Maryland Identification Card / Limited Term Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2002 | Maryland Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2016 | Maryland Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2020 | Maryland Handgun Permit | ### Massachusetts | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------------- | :------ | :----------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2010 | Massachusetts Driver's License / Commercial Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2016 | Massachusetts Driver's License / Commercial Driver's License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2010 | Massachusetts Under 21 Driver's License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2016 | Massachusetts Under 21 Driver's License | | DriversLicense | JUNIOR\_OPERATORS\_LICENSE\_UNDER21 | 2010 | Massachusetts Junior Operator's License (Under 21) | | DriversLicense | JUNIOR\_OPERATORS\_LICENSE\_UNDER21 | 2016 | Massachusetts Junior Operator's License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2004 | Massachusetts Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2005 | Massachusetts Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Massachusetts Identification Card / Liquor ID Card | | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Massachusetts Identification Card / Liquor ID Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2004 | Massachusetts Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2016 | Massachusetts Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2009 | Massachusetts License to Carry Firearms | ### Michigan | Type of ID | Subtype of ID | Version | Description | | :----------------- | :-------------------------------------- | :------ | :---------------------------------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2011 | Michigan Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2024 | Michigan Driver's License / Chauffeur's License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2011 | Michigan Driver License (Under 21)  / Commercial Driver License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2024 | Michigan Driver's License (Under 21) | | DriversLicense | ENHANCED\_DRIVERS\_LICENSE | 2011 | Michigan Enhanced Driver License / Enhanced Chauffeur License / Enhanced Commercial Driver License | | DriversLicense | ENHANCED\_DRIVERS\_LICENSE | 2024 | Michigan Enhanced Driver's License / Enhanced Chauffeur's License | | DriversLicense | ENHANCED\_DRIVERS\_LICENSE\_UNDER21 | 2011 | Michigan Enhanced Driver License (Under 21) / Enhanced Chauffeur License (Under 21) / Enhanced Commercial Driver License (Under 21) | | DriversLicense | ENHANCED\_DRIVERS\_LICENSE\_UNDER21 | 2024 | Michigan Enhanced Driver's License (Under 21) | | DriversLicense | ENHANCED\_LEARNERS\_PERMIT\_UNDER21 | 2011 | Michigan Enhanced Graduated Driver License (Under 21) | | IdentificationCard | ENHANCED\_IDENTIFICATION\_CARD | 2011 | Michigan Enhanced Identification Card | | IdentificationCard | ENHANCED\_IDENTIFICATION\_CARD\_UNDER21 | 2024 | Michigan Enhanced Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2011 | Michigan Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2024 | Michigan Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2011 | Michigan Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2024 | Michigan Identification Card (Under 21) | | Other | IDENTIFICATION\_CARD | 2025 | Michigan Identification Card | | Other | FIREARMS\_LICENSE | 2024 | Michigan Concealed Pistol License | ### Minnesota | Type of ID | Subtype of ID | Version | Description | | :----------------- | :----------------------------------------------- | :------ | :------------------------------------------------------------------------------------------------------------ | | DriversLicense | DRIVERS\_LICENSE | 2004 | Minnesota Driver's License / Driver's License Commercial / Motorized Bicycle | | DriversLicense | DRIVERS\_LICENSE | 2018 | Minnesota Driver's License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2004 | Minnesota Driver's License (Under 21) / Driver's License Commercial (Under 21) / Motorized Bicycle (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2018 | Minnesota Driver's License (Under 21) | | DriversLicense | ENHANCED\_DRIVERS\_LICENSE | 2018 | Minnesota Enhanced Driver's License | | DriversLicense | ENHANCED\_DRIVERS\_LICENSE\_UNDER21 | 2018 | Minnesota Enhanced Driver's License (Under 21) | | DriversLicense | ENHANCED\_LEARNERS\_PERMIT | 2018 | Minnesota Enhanced Instruction Permit | | DriversLicense | ENHANCED\_PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2018 | Minnesota Enhanced Provisional Driver's License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2018 | Minnesota Instruction Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2004 | Minnesota Instruction Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2018 | Minnesota Instruction Permit (Under 21) | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2018 | Minnesota Provisional Driver's License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2004 | Minnesota Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Minnesota Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2004 | Minnesota Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2018 | Minnesota Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2020 | Minnesota Permit to Carry a Pistol | ### Mississippi | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :------------------------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2001 | Mississippi Driver License / Commercial License | | DriversLicense | DRIVERS\_LICENSE | 2016 | Mississippi Driver License / Commercial Driver License / Light Commercial Driver License / Non-US Citizen Driver License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2024 | Mississippi Driver License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2001 | Mississippi Driver License (Under 21) / Commercial License (Under 21) /  Non-US Citizen Driver License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2016 | Mississippi Driver License (Under 21) / Commercial Driver License (Under 21)  / Light Commercial Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2016 | Mississippi Learner's Permit / Commercial Learner's Permit / Non-US Citizen Commercial Learner's Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2001 | Mississippi Learner's Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2016 | Mississippi Learner's Permit (Under 21) / Restricted Learner's Permit (Under 21) / Commercial Learner's Permit (Under 21) | | DriversLicense | DRIVERS\_LICENSE | 2024 | Mississippi Driver License | | DriversLicense | LEARNERS\_PERMIT | 2024 | Mississippi Learner's Permit | | IdentificationCard | IDENTIFICATION\_CARD | 2001 | Mississippi Identification Card / Non-US Citizen Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Mississippi Identification Card / Person with disabilities Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2024 | Mississippi Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2001 | Mississippi Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2016 | Mississippi Identification Card (Under 21) / Person with disabilities Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2024 | Mississippi Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2010 | Mississippi Firearms Permit | | Other | FIREARMS\_LICENSE | 2020 | Mississippi Firearms Permit | | Other | FIREARMS\_LICENSE | 2024 | Mississippi Firearms Permit | ### Missouri | Type of ID | Subtype of ID | Version | Description | | :----------------- | :-------------------------------------- | :------ | :------------------------------------------------------------------------ | | DriversLicense | DRIVERS\_LICENSE | 2003 | Missouri Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2012 | Missouri Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2020 | Missouri Driver License / Commercial Driver License / Non-Domiciled CDL | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2012 | Missouri Driver License (Under 21) / Commercial Driver License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2020 | Missouri Driver License (Under 21) | | DriversLicense | INTERMEDIATE\_DRIVERS\_LICENSE\_UNDER21 | 2012 | Missouri Intermediate Driver License (Under 21) | | DriversLicense | INTERMEDIATE\_DRIVERS\_LICENSE\_UNDER21 | 2020 | Missouri Intermediate Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2012 | Missouri Instruction Permit | | DriversLicense | LEARNERS\_PERMIT | 2020 | Missouri Instruction Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2012 | Missouri Instruction Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2020 | Missouri Instruction Permit (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2012 | Missouri Nondriver License | | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Missouri Nondriver Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2012 | Missouri Nondriver License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2020 | Missouri Nondriver Identification Card (Under 21) | ### Montana | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :---------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2008 | Montana Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2016 | Montana Driver License / Commercial License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2016 | Montana Driver License (Under 21) / Commercial License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2025 | Montana Driver License (Under 21) | | DriversLicense | DRIVERS\_LICENSE | 2025 | Montana Driver License | | IdentificationCard | IDENTIFICATION\_CARD | 2008 | Montana Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Montana Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2025 | Montana Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2008 | Montana Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2016 | Montana Identification Card (Under 21) | ### Nebraska | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------------- | :------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2017 | Nebraska Driver License / Operators License / School Bus Permit / Medical Hardship Permit / Non - Domiciled CDL / Commercial Drivers License / Restricted CDL | | DriversLicense | DRIVERS\_LICENSE | 2021 | Nebraska Driver's License / Commercial Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2026 | Nebraska Driver's License / Commercial Driver's License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2003 | Nebraska School Learners Permit (Under 21) / Provisional Operators Permit (Under 21) / Operators License (Under 21) / Restricted CDL | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2017 | Nebraska Driver License (Under 21) / Commercial Driver's License (Under 21) / Limited - Term Driver License (Under 21) / Restricted CDL (Under 21) / Non - Domiciled CDL (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2021 | Nebraska Driver's License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2026 | Nebraska Driver's License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2017 | Nebraska Learners Permit /  Limited - Term Learners Permit / Commercial Learner's Permit / Non - Domiciled CLP | | DriversLicense | LEARNERS\_PERMIT | 2022 | Nebraska Learner's Permit / Commercial Learner's Permit | | DriversLicense | LEARNERS\_PERMIT | 2026 | Nebraska Learner's Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2017 | Nebraska Commercial Learner's Permit (Under 21)  /  Learners Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2021 | Nebraska Learner's Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2026 | Nebraska Learner's Permit (Under 21) | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2017 | Nebraska Provisional Operators Permit (Under 21) | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2021 | Nebraska Provisional Operator's Permit (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2009 | Nebraska Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Nebraska Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2026 | Nebraska Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2017 | Nebraska Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2021 | Nebraska Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2026 | Nebraska Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2020 | Nebraska Concealed Handgun Permit | ### Nevada | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :--------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2010 | Nevada Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2021 | Nevada Driver License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2010 | Nevada Driver License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2021 | Nevada Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2021 | Nevada Instruction Permit / Commercial Learner Permit / Instruction Permit Driver Authorization Card | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2010 | Nevada Instruction Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2021 | Nevada Instruction Permit (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Nevada Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Nevada Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2010 | Nevada Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2021 | Nevada Identification Card (Under 21) | ### New Hampshire | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2011 | New Hampshire Operator License | | DriversLicense | DRIVERS\_LICENSE | 2017 | New Hampshire Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2025 | New Hampshire Driver License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2017 | New Hampshire Driver License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2025 | New Hampshire Driver License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2011 | New Hampshire Non Driver ID | | IdentificationCard | IDENTIFICATION\_CARD | 2017 | New Hampshire Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2025 | New Hampshire Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2008 | New Hampshire Non Driver ID (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2017 | New Hampshire Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2025 | New Hampshire Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2020 | New Hampshire Pistol / Revolver License | ### New Jersey | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :--------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2011 | New Jersey Auto Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2011 | New Jersey Auto Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2011 | New Jersey Probationary Auto License | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2011 | New Jersey Probationary Auto License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2011 | New Jersey - FOR IDENTIFICATION ONLY | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2018 | New Jersey - FOR IDENTIFICATION ONLY (Under 21) | | Other | IDENTIFICATION\_CARD | 2019 | New Jersey County of Essex Resident Card | | Other | IDENTIFICATION\_CARD | 2022 | City of New Ark Municipal Identification Card | | Other | IDENTIFICATION\_CARD | 2023 | City of Paterson New Jersey Municipal Identification Card | | Other | IDENTIFICATION\_CARD | 2024 | City of Elizabeth NJ Identification Card | | Other | IDENTIFICATION\_CARD | 2025 | New Jersey Identification Card | ### New Mexico | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------------- | :------ | :------------------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2007 | New Mexico Driver's License (Interlock License)  / Commercial Driver's License  / Restricted Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2016 | New Mexico Driver's License / Commercial Driver's License / Driver's Interlock License / Commercial Learner's Permit | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2007 | New Mexico Driver's License (Under 21) / Interlock Driver's License (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2007 | New Mexico Restricted Driver's License (Under 21) | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2007 | New Mexico Provisional License (Under 21) / Provisional Interlock License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2016 | New Mexico Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2007 | New Mexico Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2010 | New Mexico Concealed Handgun License | ### New York | Type of ID | Subtype of ID | Version | Description | | :----------------- | :-------------------------------------- | :------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVER\_LICENSE | 2005 | New York State Driver License / Enhanced Commercial Driver License / Enhanced Restricted Use Driver License / Restricted Use Driver License / Commercial Driver License / Enhanced Driver License / Enhanced Conditional Driver License / Conditional Driver License | | DriversLicense | DRIVER\_LICENSE | 2010 | New York State Driver License | | DriversLicense | DRIVER\_LICENSE | 2017 | New York State Driver License | | DriversLicense | DRIVER\_LICENSE | 2022 | New York State Driver License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2017 | New York State Driver License Under 21 | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2022 | New York State Driver License Under 21 | | DriversLicense | ENHANCED\_DRIVER\_LICENSE | 2017 | New York State Enhanced Commercial Driver License / Enhanced Driver License | | DriversLicense | LEARNERS\_PERMIT | 2005 | New York State Learner Permit / Enhanced Learner Permit | | DriversLicense | LEARNERS\_PERMIT | 2017 | New York State Learner Permit | | DriversLicense | LEARNERS\_PERMIT | 2022 | New York State Learner Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2005 | New York State Learner Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2017 | New York State Learner Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2022 | New York State Learner Permit (Under 21) | | IdentificationCard | CITY\_IDENTIFICATION\_CARD | 2021 | New York City Identification Card | | IdentificationCard | ENHANCED\_IDENTIFICATION\_CARD | 2017 | New York State Enhanced Identification Card | | IdentificationCard | ENHANCED\_IDENTIFICATION\_CARD\_UNDER21 | 2017 | New York State Enhanced Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2005 | New York State Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2017 | New York State Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2018 | NYC Identification Card | | Other | IDENTIFICATION\_CARD | 2020 | Westchester County Clerk Identification Card | | Other | IDENTIFICATION\_CARD | 2021 | NYC Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2022 | New York State Enhanced Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2017 | New York State Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2022 | New York State Identification Card (Under 21) | | IdentificationCard | CITY\_IDENTIFICATION\_CARD | 2021 | New York City Identification Card | | MedicalCard | MEDICAL\_CARD | 2015 | New York State Medical Card | | Other | FIREARMS\_LICENSE | 2010 | New York Firearms License | | Other | FIREARMS\_LICENSE | 2015 | New York Firearms License | ### North Carolina | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------------- | :------ | :------------------------------------------------------------------------------------------ | | DriversLicense | DRIVERS\_LICENSE | 2008 | North Carolina Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2015 | North Carolina Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2024 | North Carolina Driver License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2015 | North Carolina Driver License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2016 | North Carolina Driver License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2024 | North Carolina Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2015 | North Carolina Learner Permit / Commercial Learner Permit | | DriversLicense | LEARNERS\_PERMIT | 2024 | North Carolina Learner Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2024 | North Carolina Learner Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2015 | North Carolina Limited Learner Permit (Under 21) / Learner Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2016 | North Carolina Limited Learner Permit (Under 21) | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2015 | North Carolina Full Provisional License (Under 21) / Limited Provisional License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2008 | North Carolina Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2015 | North Carolina Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2024 | North Carolina Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2014 | North Carolina Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2015 | North Carolina Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2024 | North Carolina Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2020 | North Carolina Concealed Handgun Permit | ### North Dakota | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :----------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2006 | North Dakota Driver License / Motorized Bicycle Permit / Commercial Driver License / Motorcycle Permit | | DriversLicense | DRIVERS\_LICENSE | 2014 | North Dakota Driver License / Permanent Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2023 | North Dakota Driver License / Commercial Driver License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2017 | North Dakota Driver License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2023 | North Dakota Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2014 | North Dakota Instruction Permit / Temporary Instruction Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2014 | North Dakota Instruction Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2023 | North Dakota Instruction Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2023 | North Dakota Instruction Permit (Under 21) | | DriversLicense | TEMPORARY\_DRIVERS\_LICENSE | 2023 | North Dakota Temporary Operator Permit / Temporary Driver License | | IdentificationCard | IDENTIFICATION\_CARD | 2006 | North Dakota Non - Driver Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2014 | North Dakota Non - Driver Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2023 | North Dakota Non - Driver Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2006 | North Dakota Non - Driver Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2014 | North Dakota Non - Driver Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2023 | North Dakota Non - Driver Identification Card (Under 21) | ### Ohio | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :------------------------------------------------------------------------------- | | DriversLicense | DRIVER\_LICENSE | 2009 | Ohio Driver License / Commercial License | | DriversLicense | DRIVER\_LICENSE | 2018 | Ohio Driver License / Commercial License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2018 | Ohio Driver License (Under 21) / Commercial License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2018 | Ohio Temporary Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2018 | Ohio Temporary Permit (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2009 | Ohio Identification Card / Temporary Instruction Permit ID | | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Ohio Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2015 | Ohio Identification Card (Under 21) / Temporary Instruction Permit ID (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2018 | Ohio Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2020 | Ohio License to Carry Concealed Handgun | ### Oklahoma | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :-------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2012 | Oklahoma Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2020 | Oklahoma Driver License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2012 | Oklahoma Driver License (Under 21) / Intermediate Driver License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2020 | Oklahoma Driver License (Under 21) / Intermediate Driver License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2026 | Oklahoma Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2012 | Oklahoma Learner Permit | | DriversLicense | LEARNERS\_PERMIT | 2020 | Oklahoma Learner Permit | | DriversLicense | LEARNERS\_PERMIT | 2026 | Oklahoma Learner Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2012 | Oklahoma Learner Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2020 | Oklahoma Learner Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2026 | Oklahoma Learner Permit (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2012 | Oklahoma Non - Driver Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Oklahoma Non - Driver Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Oklahoma Non - Driver Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2026 | Oklahoma Non - Driver Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2012 | Oklahoma Non - Driver Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2020 | Oklahoma Non - Driver Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2026 | Oklahoma Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2020 | Oklahoma Handgun License | ### Oregon | Type of ID | Subtype of ID | Version | Description | | :----------------- | :-------------------------------------- | :------ | :-------------------------------------------------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2004 | Oregon Driver License / Instruction Permit / CDL Instruction Permit / Commercial Driver License / Motorcycle Instruction Permit / Moped Restriction | | DriversLicense | DRIVERS\_LICENSE | 2018 | Oregon Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2004 | Oregon Driver License (Under 21) / Commercial Drivers License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2018 | Oregon Driver License (Under 21) / Commercial Drivers License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2018 | Oregon Instruction Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2004 | Oregon Provisional Instruction Permit (Under 21) / CDL Instruction Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2018 | Oregon Provisional Instruction Permit (Under 21) / CDL Instruction Permit (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_VALID\_WITHOUT\_PHOTO | 2018 | Oregon Driving License (valid without photo) | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2004 | Oregon Provisional License (Under 21) / Provisional Student Permit (Under 21) | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2018 | Oregon Provisional Driver License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2004 | Oregon Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Oregon Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2004 | Oregon Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2018 | Oregon Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2022 | Oregon Concealed Handgun License | ### Pennsylvania | Type of ID | Subtype of ID | Version | Description | | :----------------- | :-------------------------------------- | :------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2007 | Pennsylvania Driver's License (Under 21) / Temporary Driver's License (Under 21) / Limited Commercial Driver's License (Under 21) / Limited License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2017 | Pennsylvania Driver's License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2022 | Pennsylvania Driver's License (Under 21) | | DriversLicense | DRIVER\_LICENSE | 2007 | Pennsylvania Driver's License / Limited Commercial Driver's License / Commercial Driver's License / Limited License | | DriversLicense | DRIVER\_LICENSE | 2017 | Pennsylvania Driver's License / Commercial Driver's License | | DriversLicense | DRIVER\_LICENSE | 2022 | Pennsylvania Driver's License / Commercial Driver's License | | DriversLicense | JUNIOR\_DRIVERS\_LICENSE | 2007 | Pennsylvania Junior Driver's License | | DriversLicense | JUNIOR\_DRIVERS\_LICENSE | 2017 | Pennsylvania Junior Driver's License (Under 21) | | DriversLicense | JUNIOR\_DRIVERS\_LICENSE | 2022 | Pennsylvania Junior Driver's License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_VALID\_WITHOUT\_PHOTO | 2022 | Pennsylvania Driving License (valid without photo) | | IdentificationCard | IDENTIFICATION\_CARD | 2007 | Pennsylvania Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Pennsylvania Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2022 | Pennsylvania Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2007 | Pennsylvania Identification Card (Under 21) / Pennsylvania Temporary Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2018 | Pennsylvania Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2022 | Pennsylvania Identification Card (Under 21) | | Other | IDENTIFICATION\_CARD | 2024 | City of Philadelphia Identification Card | | Other | BIRTH\_CERTIFICATE | 2020 | Pennsylvania Birth Certificate | | Other | FIREARMS\_LICENSE | 2020 | Pennsylvania License to Carry Firearms | ### Rhode Island | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------------- | :------ | :-------------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2007 | Rhode Island Driver License / Commercial Driver License | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2016 | Rhode Island Learner Permit (Under 21) | | DriversLicense | DRIVERS\_LICENSE | 2018 | Rhode Island Driver License / Commercial Driver License / Non - Domiciled CDL | | DriversLicense | LEARNERS\_PERMIT | 2018 | Rhode Island Learner Permit | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2016 | Rhode Island Driver License (Under 21)  / Commercial Driver License (Under 21) / Non - Domiciled CDL (Under 21) | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2016 | Rhode Island Provisional Driver License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2007 | Rhode Island Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Rhode Island Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2016 | Rhode Island Identification Card | | Other | IDENTIFICATION\_CARD | 2025 | Rhode Island Identification Card | | Other | FIREARMS\_LICENSE | 2020 | Rhode Island Pistol Permit | ### South Carolina | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2010 | South Carolina Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2018 | South Carolina Driver's License / Commercial Driver's License / Provisional Driver's License / Moped Driver's License / Route Restricted Driver's License / Temporary Alcohol Driver's License / Limited - Term Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2025 | South Carolina Driver's License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2010 | South Carolina Driver's License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2018 | South Carolina Driver's License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2017 | South Carolina Commercial Beginner's Permit / Beginner's Permit | | DriversLicense | LEARNERS\_PERMIT | 2025 | South Carolina Beginner's Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2018 | South Carolina Beginner's Permit (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2025 | South Carolina Driver's License (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2025 | South Carolina Beginner's Permit (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2010 | South Carolina Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2018 | South Carolina Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2025 | South Carolina Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2010 | South Carolina Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2018 | South Carolina Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2025 | South Carolina Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2020 | South Carolina Concealed Weapons Permit | ### South Dakota | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2018 | South Dakota Driver License / Operator License / Commercial Driver License / Limited - Term Driver License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2018 | South Dakota Driver License (Under 21) / Commercial Driver License (Under 21) / Limited - Term Restricted Minor's Permit (Under 21) / Operator License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2018 | South Dakota Instruction Permit / Limited - Term Instruction Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2018 | South Dakota Instruction Permit (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2010 | South Dakota Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2018 | South Dakota Identification Card (Under 21) | ### Tennessee | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------ | :------ | :-------------------------------------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2003 | Tennessee Driver License / Commercial Driver License / Restricted Driver License / Temporary Restricted Driver License / Learner Permit | | DriversLicense | DRIVERS\_LICENSE | 2016 | Tennessee Driver License | | DriversLicense | DRIVERS\_LICENSE | 2024 | Tennessee Driver License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2011 | Tennessee Driver License (Under 21) / Intermediate Unrestricted Driver License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2019 | Tennessee Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2011 | Tennessee Learner Permit  / Temporary Learner Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2011 | Tennessee Learner Permit (Under 21) | | DriversLicense | TEMPORARY\_LEARNERS\_PERMIT | 2011 | Tennessee Temporary Learner Permit | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2024 | Tennessee Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2024 | Tennessee Learner Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2024 | Tennessee Learner Permit (Under 21) | | DriversLicense | TEMPORARY\_LEARNERS\_PERMIT | 2024 | Tennessee Temporary Learner Permit | | DriversLicense | TEMPORARY\_DRIVERS\_LICENSE | 2024 | Tennessee Temporary Driver License | | IdentificationCard | IDENTIFICATION\_CARD | 2003 | Tennessee Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Tennessee Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Tennessee Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2016 | Tennessee Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2024 | Tennessee Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2024 | Tennessee Identification Card (Under 21) | | IdentificationCard | TEMPORARY\_IDENTIFICATION\_CARD | 2024 | Tennessee Temporary Identification Card | | Other | FIREARMS\_LICENSE | 2020 | Tennessee Handgun Carry Permit | | Other | FIREARMS\_LICENSE | 2025 | Tennessee Handgun Carry Permit | ### Texas | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------------- | :------ | :------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2002 | Texas Driver License | | DriversLicense | DRIVERS\_LICENSE | 2009 | Texas Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2020 | Texas Driver License | | DriversLicense | DRIVERS\_LICENSE | 2025 | Texas Driver License | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2009 | Texas Provisional Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2009 | Texas Learner Permit (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2009 | Texas Driver License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2020 | Texas Driver License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2025 | Texas Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2020 | Texas Commercial Learner Permit | | DriversLicense | LEARNERS\_PERMIT | 2025 | Texas Learner Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2020 | Texas Learner Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2025 | Texas Learner Driver License (Under 21) | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2020 | Texas Provisional Driver License (Under 21) | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2025 | Texas Provisional Driver License (Under 21) | | DriversLicense | LIMITED\_TERM\_DRIVERS\_LICENSE | 2020 | Texas Limited-Term Driver License | | IdentificationCard | IDENTIFICATION\_CARD | 2002 | Texas Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2009 | Texas Identification Card / Limited - Term Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Texas Identification Card / Limited - Term Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2025 | Texas Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2009 | Texas Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2020 | Texas Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2025 | Texas Identification Card (Under 21) | | Other | BIRTH\_CERTIFICATE | 2018 | Texas Certification of Vital Record | | Other | FIREARMS\_LICENSE | 2009 | Texas Concealed Handgun License | | Other | FIREARMS\_LICENSE | 2024 | Texas License to Carry Handgun | | Other | FIREARMS\_LICENSE | 2025 | Texas License to Carry Handgun | ### USCIS | Type of ID | Subtype of ID | Version | Description | | :---------------- | :--------------------------------- | :------ | :---------------------------- | | Permit | EMPLOYMENT\_AUTHORIZATION\_CARD | 2011 | Employment Authorization Card | | Permit | EMPLOYMENT\_AUTHORIZATION\_CARD | 2018 | Employment Authorization Card | | Permit | EMPLOYMENT\_AUTHORIZATION\_CARD | 2022 | Employment Authorization Card | | TravelDocument | TRAVEL\_DOCUMENT | 2010 | Travel Document | | TravelDocument | TRAVEL\_DOCUMENT | 2017 | Travel Document | | ResidenceDocument | PERMANENT\_RESIDENT\_CARD\_ALLAGES | 2010 | Permanent Resident Card | | ResidenceDocument | PERMANENT\_RESIDENT\_CARD\_ALLAGES | 2015 | Permanent Residence Card | | ResidenceDocument | PERMANENT\_RESIDENT\_CARD\_ALLAGES | 2023 | Permanent Resident Card | ### US Department of State | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------- | :------ | :------------------------------------------------------------------------------ | | DriversLicense | DRIVERS\_LICENSE | 2019 | United States Department of State Driver's License / Graduated Driver's License | | IdentificationCard | GOVERNMENT\_IDENTIFICATION\_CARD | 2010 | United States Government Identification Card | | TravelDocument | PASSPORT\_CARD\_ALLAGES | 2012 | Passport Card | | TravelDocument | VISA\_B1\_B2 | 2008 | B1/B2 VISA - Border Crossing Card | | TravelDocument | VISA\_B1\_B2 | 2021 | B1/B2 VISA - Border Crossing Card | | Visa | VISA\_ALLAGES | 2009 | VISA | | Visa | VISA\_ALLAGES | 2010 | VISA | | Visa | VISA\_ALLAGES | 2023 | VISA | | Visa | VISA\_ALLAGES | 2024 | Immigrant Visa | ### Utah | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2016 | Utah Driver License / Commercial Driver License / Privilege Driver License | | DriversLicense | DRIVERS\_LICENSE | 2021 | Utah Driver License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2016 | Utah Driver License (Under 21) /  Limited - Term Driver License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2021 | Utah Driver License (Under 21) | | DriversLicense | PRIVILEGE\_CARD | 2022 | Utah Driving Privilege Card | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2023 | Utah Privilege Driver License (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2006 | Utah Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2016 | Utah Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Utah Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2006 | Utah Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2010 | Utah Concealed Firearm Permit | ### Vermont | Type of ID | Subtype of ID | Version | Description | | :----------------- | :----------------------------------------------- | :------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2013 | Vermont Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2014 | Vermont Enhanced Driver's License / Enhanced Operator's License / Enhanced Commercial Driver's License / | | DriversLicense | DRIVERS\_LICENSE | 2019 | Vermont Driver's License / Driver's Privilege Card / Commercial Driver's License / Nondomiciled Commercial Driver's License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2013 | Vermont Driver's License (Under 21) / Driver's Privilage Card (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2019 | Vermont Driver's License (Under 21) / Junior Driver's License (Under 21) / Junior Driver's Privilege Card (Under 21) / Nondomiciled Commercial Driver's License (Under 21) / Commercial Driver's License (Under 21) / Driver's Privilege Card (Under 21) | | DriversLicense | ENHANCED\_DRIVERS\_LICENSE | 2019 | Vermont Enhanced Driver's License | | DriversLicense | ENHANCED\_DRIVERS\_LICENSE\_UNDER21 | 2014 | Vermont Enhanced Driver's License (Under 21) / Enhanced Operator's License (Under 21) | | DriversLicense | ENHANCED\_DRIVERS\_LICENSE\_UNDER21 | 2019 | Vermont Enhanced Driver's License (Under 21) /  Enhanced Junior Driver's License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2019 | Vermont Learner's Permit / Nondomiciled Commercial Learner's Permit / Learner's Privilege Card | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2003 | Vermont Learner's Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2019 | Vermont Learner's Permit (Under 21) / Commercial Learner's Permit (Under 21) / Learner's Privilege Card (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_VALID\_WITHOUT\_PHOTO | 2019 | Vermont Learner Permit (valid without photo) | | DriversLicense | LEARNERS\_PERMIT\_VALID\_WITHOUT\_PHOTO\_UNDER21 | 2019 | Vermont Learner Permit Under 21 (valid without photo) | | IdentificationCard | IDENTIFICATION\_CARD | 2013 | Vermont Nondriver Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Vermont Nondriver Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2013 | Vermont Nondriver Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2019 | Vermont Nondriver Identification Card (Under 21) / Enhanced Nondriver Identification Card (Under 21) | ### Virginia | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :--------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2018 | Virginia Driver's License / Commercial Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2023 | Virginia Driver's License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2018 | Virginia Driver's License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2023 | Virginia Driver's License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2018 | Virginia DL Learner's Permit / CDL Learner's Permit | | DriversLicense | LEARNERS\_PERMIT | 2023 | Virginia DL Learner's Permit / Commercial Learner's Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2018 | Virginia DL Learner's Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2023 | Virginia DL Learner's Permit (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Virginia Identification Card / Children's ID Card | | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Virginia Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2018 | Virginia Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2023 | Virginia Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2020 | Virginia Concealed Handgun Permit | | Other | FIREARMS\_LICENSE | 2021 | Virginia Concealed Handgun Permit | ### Washington | Type of ID | Subtype of ID | Version | Description | | :----------------- | :----------------------------------------------- | :------ | :------------------------------------------------------------------------------------------------------------ | | DriversLicense | DRIVERS\_LICENSE | 2010 | Washington Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2018 | Washington Driver License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2010 | Washington Driver License (Under 21) / Intermediate License (Under 21) / Commercial Driver License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2017 | Washington Driver License (Under 21) / Intermediate License (Under 21) | | DriversLicense | ENHANCED\_DRIVERS\_LICENSE | 2018 | Washington Enhanced Driver License | | DriversLicense | ENHANCED\_DRIVERS\_LICENSE\_UNDER21 | 2017 | Washington Enhanced Intermediate Driver License (Under 21) / Enhanced Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2018 | Washington Instruction Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2017 | Washington Instruction Permit (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_VALID\_WITHOUT\_PHOTO\_UNDER21 | 2017 | Washington Driving License Under 21 (valid without photo) | | DriversLicense | LEARNERS\_PERMIT\_VALID\_WITHOUT\_PHOTO\_UNDER21 | 2017 | Washington Learner Permit Under 21 (valid without photo) | | IdentificationCard | ENHANCED\_IDENTIFICATION\_CARD | 2017 | Washington Enhanced Identification Card | | IdentificationCard | ENHANCED\_IDENTIFICATION\_CARD\_UNDER21 | 2017 | Washington Enhanced Identification Card (Under 21) | | IdentificationCard | ENHANCED\_IDENTIFICATION\_CARD\_UNDER21 | 2022 | Washington Enhanced Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2010 | Washington Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Washington Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2010 | Washington Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2017 | Washington Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2010 | Washington Concealed Pistol License | | Other | FIREARMS\_LICENSE | 2020 | Washington Concealed Pistol License | ### West Virginia | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | DriversLicense | DRIVERS\_LICENSE | 2011 | West Virginia Driver's License / Commercial DL / M - Cycle Only DL / BI - OPTIC Lens DL | | DriversLicense | DRIVERS\_LICENSE | 2020 | West Virginia Driver's License | | DriversLicense | DRIVERS\_LICENSE | 2023 | West Virginia Driver's License | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2011 | West Virginia Driver's License (Under 21) / Commercial DL (Under 21) / M - Cycle Only DL (Under 21) / BI - OPTIC Lens DL (Under 21) / Graduated DL (Under 21) / Level 2 - Intermed DL | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2020 | West Virginia Driver's License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2023 | West Virginia Intermediate DL (Under 21) / Commercial Driver's License (Under 21) / West Virginia Intermediate DL 2 (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2020 | West Virginia Instruction Permit | | DriversLicense | LEARNERS\_PERMIT | 2023 | West Virginia Learner's Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2011 | West Virginia Instruction Permit (Under 21) / CDL INST Permit (Under 21) / Level 1 - INST Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2020 | West Virginia Instruction Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2023 | West Virginia Instruction Permit (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2011 | West Virginia Non - Oper ID Card / Secondary ID | | IdentificationCard | IDENTIFICATION\_CARD | 2023 | West Virginia Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2011 | West Virginia Non - Oper ID Card (Under 21)  / Secondary ID (Under 21) / Youth ID (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2020 | West Virginia Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2023 | West Virginia Identification Card (Under 21) | | Other | FIREARMS\_LICENSE | 2009 | West Virginia Concealed Pistol / Revolver Permit | ### Wisconsin | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------------------ | :------ | :----------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2012 | Wisconsin Driver License Regular / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2015 | Wisconsin Driver License Regular | | DriversLicense | DRIVERS\_LICENSE | 2023 | Wisconsin Driver License Regular | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2005 | Wisconsin Driver License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2012 | Wisconsin Driver License Regular (Under 21) / Probationary Driver License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2015 | Wisconsin Driver License Regular (Under 21) / Commercial Driver License (Under 21) | | DriversLicense | DRIVERS\_LICENSE\_UNDER21 | 2023 | Wisconsin Driver License Regular (Under 21) / Probationary Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2015 | Wisconsin Instruction Permit | | DriversLicense | LEARNERS\_PERMIT | 2023 | Wisconsin Instruction Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2005 | Wisconsin Instruction Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2015 | Wisconsin Instruction Permit (Under 21) | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2023 | Wisconsin Instruction Permit (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2012 | Wisconsin Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Wisconsin Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Wisconsin Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Wisconsin Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2012 | Wisconsin Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2015 | Wisconsin Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2023 | Wisconsin Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_VALID\_WITHOUT\_PHOTO | 2023 | Wisconsin Identity Card (valid without photo) | | Other | FIREARMS\_LICENSE | 2020 | Wisconsin Concealed Carry License | ### Wyoming | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :---------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2010 | Wyoming Driver License / Commercial Driver License | | DriversLicense | DRIVERS\_LICENSE | 2020 | Wyoming Driver License | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2004 | Wyoming Driver License (Under 21) / Commercial Driver License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2010 | Wyoming Driver License (Under 21) / Commercial Driver License (Under 21) | | DriversLicense | DRIVER\_LICENSE\_UNDER21 | 2020 | Wyoming Driver License (Under 21) | | DriversLicense | LEARNERS\_PERMIT | 2020 | Wyoming Instruction Permit / Limited Term Instruction Permit / Commercial Learners Permit | | DriversLicense | LEARNERS\_PERMIT\_UNDER21 | 2020 | Wyoming Instruction Permit (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD | 2004 | Wyoming Identification Card | | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Wyoming Identification Card | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2010 | Wyoming Identification Card (Under 21) | | IdentificationCard | IDENTIFICATION\_CARD\_UNDER21 | 2020 | Wyoming Identification Card (Under 21) | --- ## Oceania The following tables list supported identification documents for Oceania, organized by country. The table for Australia is further divided by state. ## Australia (AUS) ### All States | Type of ID | Subtype of ID | Version | Description | | :---------------- | :------------------ | :------ | :-------------------------------------------------------------- | | MedicalCard | MEDICAL\_CARD | 2018 | Medicare Card | | MedicalCard | MEDICAL\_CARD | 2019 | Medicare Card | | MedicalCard | MEDICAL\_CARD | 2020 | Medicare Card | | Military | MILITARY\_CARD | 2020 | Military Card | | Passport | NATIONAL\_PASSPORT | 2008 | Passport | | Passport | NATIONAL\_PASSPORT | 2022 | Passport | | Passport | EMERGENCY\_PASSPORT | 2025 | Emergency Passport | | ResidenceDocument | RESIDENCE\_PERMIT | 2017 | Australian Government ImmiCard (Evidence of Immigration Status) | | ResidenceDocument | RESIDENCE\_PERMIT | 2018 | Australian Government Permanent Resident Evidence | ### Capital Territory | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------- | :------ | :-------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2015 | Australian Capital Territory Driver License | | DriversLicense | HEAVY\_VEHICLE\_DRIVERS\_LICENSE | 2015 | Australian Capital Territory Heavy Vehicle Driver License | | DriversLicense | LEARNER\_DRIVERS\_LICENSE | 2015 | Australian Capital Territory Learner Driver License | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE | 2015 | Australian Capital Territory Provisional Driver License | | DriversLicense | PROBATIONARY\_DRIVERS\_LICENSE | 2024 | Australian Capital Territory Probationary Driver License | | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Australian Capital Territory Proof of Identity Card | ### New South Wales | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------- | :------ | :------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2015 | New South Wales Driver License | | DriversLicense | HEAVY\_VEHICLE\_DRIVERS\_LICENSE | 2015 | New South Wales Heavy Vehicle Driver License | | DriversLicense | LEARNERS\_PERMIT | 2015 | New South Wales Learner Driver License | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE | 2015 | New South Wales Provisional Driver License | | IdentificationCard | IDENTIFICATION\_CARD | 2012 | New South Wales Photo Card | | Other | COMPETENCY\_CARD | 2022 | New South Wales Competency Card | | Other | FIREARMS\_LICENSE | 2020 | Firearms License | ### Northern Territory | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------- | :------ | :----------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2012 | Northern Territory of Australia Driver License | | DriversLicense | DRIVERS\_LICENSE | 2015 | Northern Territory of Australia Driver License | | DriversLicense | HEAVY\_VEHICLE\_DRIVERS\_LICENSE | 2015 | Northern Territory of Australia Heavy Vehicle Driver License | | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Northern Territory of Australia Evidence of Age Card | ### Queensland | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------- | :------ | :-------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2015 | Queensland Driver License | | DriversLicense | DRIVERS\_LICENSE | 2020 | Queensland Driver License | | DriversLicense | HEAVY\_VEHICLE\_DRIVERS\_LICENSE | 2015 | Queensland Heavy Vehicle Driver License | | DriversLicense | HEAVY\_VEHICLE\_DRIVERS\_LICENSE | 2020 | Queensland Heavy Vehicle Driver License | | DriversLicense | INDUSTRY\_AUTHORITY\_CARD | 2024 | Queensland Industry Authority Card | | IdentificationCard | IDENTIFICATION\_CARD | 2011 | Queensland Adult Proof of Age Card | | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Queensland Photo Identification Card | ### South Australia | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------- | :------ | :--------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2015 | South Australia Driver's License | | DriversLicense | HEAVY\_VEHICLE\_DRIVERS\_LICENSE | 2015 | South Australia Heavy Vehicle Driver's License | | DriversLicense | LEARNERS\_PERMIT | 2015 | South Australia Learner's Permit | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE | 2015 | South Australia Provisional Driver's License | | IdentificationCard | IDENTIFICATION\_CARD | 2015 | South Australia Proof of Age Card | ### Tasmania | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------- | :------ | :------------------------------------ | | DriversLicense | DRIVERS\_LICENSE | 2015 | Tasmania Driver License | | DriversLicense | HEAVY\_VEHICLE\_DRIVERS\_LICENSE | 2015 | Tasmania Heavy Vehicle Driver License | | DriversLicense | LEARNERS\_PERMIT | 2015 | Tasmania Learner Driver License | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE | 2015 | Tasmania Provisional Driver License | | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Tasmania Personal Information Card | ### Victoria | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------- | :------ | :------------------------------------ | | DriversLicense | DRIVERS\_LICENSE | 2014 | Victoria Driver License | | DriversLicense | HEAVY\_VEHICLE\_DRIVERS\_LICENSE | 2014 | Victoria Heavy Vehicle Driver License | | DriversLicense | LEARNERS\_PERMIT | 2014 | Victoria Learner Permit | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE | 2014 | Victoria Probationary Driver License | | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Victoria Proof of Age Card | | Other | MARINE\_LICENSE | 2020 | Victoria Marine License | ### Western Australia | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------------------- | :------ | :----------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2016 | Western Australia Driver's License | | DriversLicense | HEAVY\_VEHICLE\_DRIVERS\_LICENSE | 2016 | Western Australia Heavy Vehicle Driver's License | | DriversLicense | LEARNERS\_PERMIT | 2016 | Western Australia Learner's Permit | | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE | 2016 | Western Australia Provisional Driver's License | | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Western Australia Photo Card | ## American Samoa (ASM) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :------------------------------------- | :------ | :-------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2003 | Driver License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2021 | Driver License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2023 | Driver License | | ALL | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2003 | Provisional Driver License | | ALL | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE\_UNDER21 | 2021 | American Samoa Provisional License (Under 21) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2003 | Identification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Identification Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2023 | Voter Registration Card | | ALL | ResidenceDocument | RESIDENCE\_DOCUMENT | 2020 | Immigration Identification Card | ## Federated States of Micronesia (FSM) | State | Type of ID | Subtype of ID | Version | Description | | :------ | :------------- | :----------------- | :------ | :--------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2019 | Driver's License | | ALL | Passport | NATIONAL\_PASSPORT | 2019 | Passport | | POHNPEI | DriversLicense | DRIVERS\_LICENSE | 2022 | Pohnpei Driver License | ## Fiji (FJI) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :---------------------------- | :------ | :--------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2010 | Driver License Permit | | ALL | DriversLicense | LEARNERS\_PERMIT | 2010 | Lerarner's Driving License | | ALL | DriversLicense | PROVISIONAL\_DRIVERS\_LICENSE | 2010 | Provisional Driver License | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2020 | Passport | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2010 | Voter Identification Card | | ALL | TaxIdentification | TAX\_IDENTIFICATION\_CARD | 2023 | Taxpayer Identification Card | ## Kiribati (KIR) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :--------- | :----------------- | :------ | :---------- | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Passport | ## Marshall Islands (MHL) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :--------- | :----------------- | :------ | :---------- | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Passport | ## Nauru (NRU) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :----------------- | :------ | :------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2017 | Driver Licence | | ALL | Passport | NATIONAL\_PASSPORT | 2024 | Passport | ## New Zealand (NZL) | State | Type of ID | Subtype of ID | Version | Description | | :------------ | :----------------- | :----------------- | :------ | :-------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2000 | Driver License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2010 | Driver License | | ALL | IdentificationCard | AGE\_CARD | 2024 | Evidence of Age Document | | ALL | MedicalCard | MEDICAL\_CARD | 2020 | Kiwi Access Card | | ALL | Military | MILITARY\_CARD | 2020 | New Zealand Defence Force Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2009 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2021 | Passport | | ALL | Other | FIREARMS\_LICENSE | 2024 | Firearms License | | ALL | Other | FIREARMS\_LICENSE | 2025 | Firearms License | | COOK\_ISLANDS | DriversLicense | DRIVERS\_LICENSE | 2024 | Driver License | ## Northern Mariana Islands (MNP) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :--------------- | :------ | :------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2021 | Driver License | ## Palau (PLW) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Identification Card | | ALL | DriversLicense | DRIVERS\_LICENSE | 2022 | Vehicle Operator License | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Passport | | ALL | TravelDocument | CONSULAR\_CARD | 2020 | Consular Identification Card | | ALL | TravelDocument | ENTRY\_PERMIT | 2024 | Entry Permit | ## Papua New Guinea (PNG) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2010 | Driver's License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2019 | Driver's License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2025 | Driver's License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | National Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2006 | Passport | ## French Polynesia (PYF) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :-------------- | :------ | :----------------------------------- | | ALL | DriversLicense | DRIVER\_LICENSE | 2020 | Permis de Conduire (Driving License) | ## Samoa (WSM) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :----------------- | :------ | :---------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2020 | Drivers License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2023 | Private Drivers License | | ALL | Passport | NATIONAL\_PASSPORT | 2016 | Passport | ## Solomon Islands (SLB) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------- | :----------------- | :------ | :-------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2023 | Driving License | | ALL | Passport | NATIONAL\_PASSPORT | 2022 | Passport | ## Tonga (TON) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2018 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2015 | National Identity Card | | ALL | Passport | NATIONAL\_PASSPORT | 2004 | Passport | ## Tuvalu (TUV) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :--------- | :----------------- | :------ | :---------- | | ALL | Passport | NATIONAL\_PASSPORT | 2021 | Passport | ## Vanuatu (VUT) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :---------------------------------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2024 | Carte D'Identite Nationale de Vanuatu (Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2019 | Passport | --- ## South America The following tables list supported identification documents for South America, organized by country. The tables for Argentina, Brazil, and Peru are further divided by ID type or state. ## Argentina (ARG) ### All States | Type of ID | Subtype of ID | Version | Description | | :----------------- | :--------------------------- | :------ | :-------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 1959 | Licencia de Conducir / Driver License | | DriversLicense | DRIVERS\_LICENSE | 1960 | Licencia de Conducir (Provincia del Chaco) / Driver License | | DriversLicense | DRIVERS\_LICENSE | 1961 | Licencia de Conducir / Driver License | | DriversLicense | DRIVERS\_LICENSE | 1963 | Licencia de Conducir (Provincia del Neuquen) / Driver License | | DriversLicense | DRIVERS\_LICENSE | 1967 | Licencia de Conductor (Municipalidad de Mocoreta Corrientes) / Driver License | | DriversLicense | DRIVERS\_LICENSE | 1968 | Licencia de Conductor (Municipalidad de Santa Sylvina - Chaco) / Driver License | | DriversLicense | DRIVERS\_LICENSE | 1969 | Licencia de Conductor (Villa Angela - Chaco) / Driver License | | DriversLicense | DRIVERS\_LICENSE | 1970 | Municipalidad de Colon Licencia de Conductor / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1971 | Provincia de Formosa Licencia de Conductor / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1972 | Paclin - Catamarca Licencia de Conductor / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1973 | Municipalidad de Naschel San Luis Licencia de Conductor / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1974 | Municipalidad Villa el Chocon Licencia de Conductor / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1975 | Municipalidad de Conscripto Bernardi Licencia de Conductor / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1976 | Gobierno de Formosa Licencia de Conducir | | DriversLicense | DRIVERS\_LICENSE | 1978 | Municipalidad de Fernández Oro Licencia de Conductor | | DriversLicense | DRIVERS\_LICENSE | 1979 | Municipalidad de Alcaraz Licencia de Conductor / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1981 | Municipalidad de Cutral-Co Licencia de Conductor / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1982 | Municipalidad de Ingeniero Juarez Licencia de Conductor / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1983 | Municipalidad de Calilegua Licencia de Conductor / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1984 | Licencia de Conducir Unica (Municipalidad de Puerto Vilelas) / Driver License | | DriversLicense | DRIVERS\_LICENSE | 1986 | Licencia de Conductor (Municipalidad de Pampa Blanca) / Driver License | | DriversLicense | DRIVERS\_LICENSE | 1987 | Licencia de Conducir (Driving License) | | DriversLicense | DRIVERS\_LICENSE | 1989 | Licencia de Conductor / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1990 | Licencia de Conductor / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1992 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1994 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1995 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1996 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1997 | Licencia de Conducir (Driving License) | | DriversLicense | DRIVERS\_LICENSE | 1998 | Licencia de Conducir (Driving License) | | DriversLicense | DRIVERS\_LICENSE | 1999 | Licencia de Conducir (Driving License) | | DriversLicense | DRIVERS\_LICENSE | 2000 | Licencia Nacional de Conducir (National Driver's License) | | DriversLicense | DRIVERS\_LICENSE | 2001 | Licencia Nacional de Conducir (National Driver's License) | | DriversLicense | DRIVERS\_LICENSE | 2002 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 2004 | Licencia Nacional de Conducir (National Driver's License) | | DriversLicense | DRIVERS\_LICENSE | 2005 | Licencia de Conductor (Villa Angela - Chaco) / Driver License | | DriversLicense | DRIVERS\_LICENSE | 2006 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 2007 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 2012 | Municipalidad de San Carlos Licencia de Conductor / Driving License | | DriversLicense | DRIVERS\_LICENSE | 2013 | Licencia de Conducir / Driving License (Provincia de la Pampa) | | DriversLicense | DRIVERS\_LICENSE | 2014 | Licencia de Conducir (Municipalidad de Monte Caseros) / Driver License | | DriversLicense | DRIVERS\_LICENSE | 2016 | Pueblo de Libertador Licencia de Conductor / Driving License | | DriversLicense | DRIVERS\_LICENSE | 2020 | Licencia de Conducir (Provincia del Chaco) / Driver License | | DriversLicense | DRIVERS\_LICENSE | 2021 | Licencia de Conducir (Provincia de Corrientes-Paso de la Patria) / Driver License | | DriversLicense | DRIVERS\_LICENSE | 2024 | Licencia de Conducir / Driving License (Municipio Presidencia Roque Sáenz Peña) | | DriversLicense | DRIVERS\_LICENSE | 2025 | Municipalidad de Alvear Licencia de Conductor / Driving License | | IdentificationCard | DIGITAL\_IDENTITY\_CARD | 2019 | Documento Nacional de Identidad (National Identity Document) | | IdentificationCard | IDENTIFICATION\_CARD | 2000 | Documento Nacional de Identidad (National Identity Document) | | IdentificationCard | IDENTIFICATION\_CARD | 2009 | Cedula de Identidad (Identity Card) | | IdentificationCard | IDENTIFICATION\_CARD | 2012 | Documento Nacional de Identidad (National Identity Document) | | IdentificationCard | IDENTIFICATION\_CARD | 2013 | Cedula de Identidad (Identity Card) | | IdentificationCard | IDENTIFICATION\_CARD | 2015 | Documento Nacional de Identidad Extranjero (National Foreign Identity Document) | | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Documento Nacional de Identidad (National Identity Document) | | IdentificationCard | IDENTIFICATION\_CARD | 2024 | Alcaldia Municipal de San Miguel Carné de Identificación Personal / Identity Card | | IdentificationCard | POLICE\_IDENTIFICATION\_CARD | 2020 | Police Identification Card | | IdentificationCard | POLICE\_IDENTIFICATION\_CARD | 2024 | Police Identification Card | | Passport | NATIONAL\_PASSPORT | 2009 | Pasaporte (Passport) | | Passport | NATIONAL\_PASSPORT | 2010 | Pasaporte (Passport) | | Passport | NATIONAL\_PASSPORT | 2014 | Pasaporte (Passport) | | Passport | NATIONAL\_PASSPORT | 2023 | Pasaporte (Passport) | ### Córdoba | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :--------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2017 | Cordoba Licencia de Conducir (Driving License) | ### Formosa | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :--------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2024 | Formosa Licencia de Conducir / Driving License | ### Misiones | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :---------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2008 | Misiones Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 2020 | Misiones Licencia de Conducir / Driving License | ### Río Negro | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :------------------------ | | DriversLicense | DRIVERS\_LICENSE | 2020 | Rio Negro Driving License | ### San Luis | Type of ID | Subtype of ID | Version | Description | | :----------------- | :------------------- | :------ | :------------------------------------------- | | IdentificationCard | IDENTIFICATION\_CARD | 2024 | San Luis Cedula de Identidad (Identity Card) | ### Yala | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------- | :------ | :------------------------------------------ | | DriversLicense | DRIVERS\_LICENSE | 2023 | Yala Licencia de Conducir / Driving License | ## Bolivia (BOL) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :---------------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2013 | Licencia para Conducir (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2018 | Licencia para Conducir (Driving License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2025 | Licencia para Conducir (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2001 | Cedula de Identidad (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2002 | Cedula de Identidad (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Cedula de Identidad (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Cedula de Identidad (Identity Card) | | ALL | MedicalCard | MEDICAL\_CARD | 2010 | Medical Card | | ALL | Passport | NATIONAL\_PASSPORT | 2010 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2021 | Cedula de Identidad de Extranjero (Foreigner Identity Card) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2024 | Cédula de Identidad de Extranjero (Residence Permit) | | ALL | Visa | VISA | 2023 | Visa | ## Brazil (BRA) ### National IDs | Type of ID | Subtype of ID | Version | Description | | :---------------- | :------------------------------------ | :------ | :---------------------------------------------------------------------------------------------- | | DriversLicense | DRIVERS\_LICENSE | 2019 | Carteira Nacional de Habilitação (Nation Wide Drivers License) | | DriversLicense | DRIVERS\_LICENSE | 2023 | Carteira Nacional de Habilitação (Nation Wide Drivers License) | | DriversLicense | DRIVER\_LICENSE | 2002 | Carteira Nacional de Habilitação (Nation Wide Drivers License) | | DriversLicense | DRIVER\_LICENSE | 2005 | Carteira Nacional de Habilitação (Nation Wide Drivers License) | | DriversLicense | DRIVER\_LICENSE | 2018 | Carteira Nacional de Habilitação (Nation Wide Drivers License) | | DriversLicense | DIGITAL\_DRIVERS\_LICENSE\_PDF | 2020 | Carteira Nacional de Habilitação (Nation Wide Drivers License) | | DriversLicense | DRIVER\_LICENSE | 2022 | Carteira Nacional de Habilitação (Nation Wide Drivers License) | | DriversLicense | INTERNATIONAL\_DRIVERS\_LICENSE | 2024 | International Driver License | | Other | BIRTH\_CERTIFICATE | 2009 | Certidão de Nascimento (Birth Certificate) | | Other | BIRTH\_CERTIFICATE | 2010 | Certidão de Nascimento (Birth Certificate) | | Other | BIRTH\_CERTIFICATE | 2011 | Certidão de Nascimento (Birth Certificate) | | Other | BIRTH\_CERTIFICATE | 2013 | Certidão de Nascimento (Birth Certificate) | | Other | FIREFIGHTER\_IDENTIFICATION\_CARD | 2010 | Carteira de Identidade - Corpo de Bombeiros Militar (Identity Card - Military Fire Department) | | Other | FIREFIGHTER\_IDENTIFICATION\_CARD | 2011 | Carteira de Identidade - Corpo de Bombeiros Militar (Identity Card - Military Fire Department) | | Other | WORK\_AND\_SOCIAL\_SECURITY\_REGISTRY | 2009 | Carteira de Trabalho e Previdência Social (Work Card and Social Security) | | Other | WORK\_AND\_SOCIAL\_SECURITY\_REGISTRY | 2010 | Carteira de Trabalho e Previdência Social (Work Card and Social Security) | | Other | REFUGEE\_IDENTIFICATION\_CARD | 2010 | Refugee Identification Card | | Passport | NATIONAL\_PASSPORT | 2010 | Passaporte (Passport) | | Passport | NATIONAL\_PASSPORT | 2011 | Passaporte (Passport) | | Passport | NATIONAL\_PASSPORT | 2015 | Passaporte (Passport) | | Passport | NATIONAL\_PASSPORT | 2018 | Passaporte (Passport) | | Passport | NATIONAL\_PASSPORT | 2023 | Passaporte (Passport) | | ResidenceDocument | CONSULAR\_IDENTIFICATION\_CARD | 2017 | Carteira de Matricula Consular (Consular ID Card) | | ResidenceDocument | MIGRATORY\_REGISTER | 2011 | Documento Provisório de Registro Nacional Migratório (National Migration Registration Document) | | ResidenceDocument | MIGRATORY\_REGISTER | 2012 | Carteira de Registro Nacional Migratório (National Migration Registration Card) | | ResidenceDocument | MIGRATORY\_REGISTER | 2013 | Carteira de Registro Diplomático (Diplomatic Registration Card) | | ResidenceDocument | RESIDENCE\_PERMIT | 2000 | Cedula de identidade de estrangeiro (Foreigner Identity Card) | | ResidenceDocument | RESIDENCE\_PERMIT | 2019 | Carteira de Registro Nacional Migratório (National Migration Registration Card) | | Visa | VISA | 2012 | Visa | ### Federal Professional Identity Cards | Type of ID | Subtype of ID | Version | Description | | :--------- | :----------------------------- | :------ | :------------------------------------------------------------------------------------------------------------------------ | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1844 | Identidade Funcional / Functional Identity Card | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1845 | Carteira de Identidade Funcional / Functional Identity Card | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1848 | Cedula de Identidade Profissional (Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1849 | Cedula de Identidade Profissional (Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1853 | Carteira de Identidade de Procurador do estado de Santa Catarina (Professional Identity Card for attorneys) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1855 | Carteira de Identidade Profissional (Professional Identity Card for industrial technicians) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1857 | Identidade Funcional de Vereador / Professional Identity Card of Councilor | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1858 | Carteira de Identidade Profissional (Professional Identity Card for accountants) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1859 | Carteira de Identidade Profissional (Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1861 | JETHRO International Chaplain Card | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1864 | Estado do Tocantins Carteira de identidade Funcional / Domestic Identification Card | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1865 | Cartão do Senador da Republica / Republic Senator Card | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1866 | Carteira de Identidade Profissional (Professional Identity Card for employees in Ministry of Finance) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1871 | Carteira de Identidade Parlamentar / Identity Card for employees in Parliament | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1872 | Carteira de Identidade Profissional (Professional Identity Card for people who work in finance) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1873 | Cedula de Identidade Profissional (Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1878 | Carteira de Identidade Profissional (Professional Identity Card for economists) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1879 | Carteira de Identidade Profissional (Professional Identity Card for judges) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1881 | Carteira de Identidade Profissional (Professional Identity Card for judges) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1883 | Carteira de Identidade Profissional (Professional Identity Card for inspectors) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1885 | Carteira de Identidade Profissional (Professional Identity Card for physiotherapist) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1887 | Carteira de Identidade Profissional (Professional Identity Card for researchers) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1889 | Carteira de Identidade Profissional (Professional Identity Card for opticians) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1891 | Carteira de Identidade Profissional (Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1893 | Carteira de Identidade Profissional (Professional Identity Card for real estate brokers) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1894 | Carteira de Identidade Profissional (Professional Identity Card for representatives) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1896 | Carteira de Identidade Profissional (Professional Identity Card for judicial technicians) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1897 | Carteira de Identidade Profissional (Professional Identity Card for judges) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1900 | Carteira de Identidade Profissional (Professional Identity Card for attorneys) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1902 | Carteira de Identidade Profissional (Professional Identity Card for pilots) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1903 | Cedula de Identidade / Domestic Identification Card | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1904 | Carteira de Identidade Profissional COFECI-CRECI (Professional Identity Card for real estate agents) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1905 | Identidade Funcional / Functional Identity Card | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1906 | Identidade Funcional / Functional Identity Card | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1907 | Carteira de Identidade Profissional (Professional Identity Card for real estate agents) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1908 | Carteira de Identidade Profissional (Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1909 | Carteira de Identidade Profissional (Biologist Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1910 | Carteira de Identidade Profissional (Professional Identity Card for professors) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1911 | Carteira de Identidade Profissional (Administrators Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1912 | Carteira de Identidade Profissional (Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1913 | Carteira de Identidade Profissional (Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1914 | Carteira de Identidade Profissional (Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1915 | Carteira de Identidade Profissional (Professional Identity Card for judiciary) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1916 | Carteira de Identidade Profissional (Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1917 | Carteira de Habilitação de Amador (Amateur Driving License) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1918 | Carteira de Identidade Profissional (Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1919 | Carteira de Identidade Profissional (Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1920 | Carteira de Identidade Profissional (Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1921 | Carteira de Identidade Profissional CRECI (Professional Identity Card for real estate agents) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1922 | Carteira de Identidade Profissional (Professional Identity Card for judiciary) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1923 | Carteira de Identidade Profissional (Professional Identity Card for advocates) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1925 | Carteira de Identidade Profissional CFBM (Biomedicine Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1926 | Carteira de Identidade Profissional (Professional Identity Card for judges) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1929 | Carteira de Identidade Profissional CRP (Professional Identity Card for Psychologists) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1930 | Carteira de Identidade Profissional INEP (Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1931 | Carteira de Identidade Profissional CRECI (Professional Identity Card for real estate agents) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1932 | Carteira de Identidade Profissional CRCSP (Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1933 | Carteira de Identidade Profissional - Tribunal de justiça de Minas Gerais (Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1934 | Carteira de Identidade Profissional CRBio (Biologist Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1939 | Carteira de Identidade Profissional CREFITO (Physiotherapist Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1943 | Carteira de Identidade Profissional (Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1944 | Carteira de Identidade Profissional (Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1945 | Carteira de Identidade Profissional - FENAJ (Professional Identity Card for journalists) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1951 | Carteira de Identidade Profissional (Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1955 | Carteira Nacional de Vigilante - CNV (National Security Guard Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1956 | Carteira de Identidade Profissional - CRA (Professional Identity Card for administrators) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1958 | FUNAI - National Indian Foundation card | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1960 | Carteira de Identidade Indígena - FUNAI (Indigenous Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1961 | Carteira de Identidade de Contabilista (Accountant Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1962 | Carteira de Identidade Profissional (Professional Identity Card for those working in the Ministry of Education) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1963 | Carteira de Identidade Profissional COFEN (Professional Identity Card for nursing technicians) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1964 | Carteira de Identidade Profissional CFQ (Professional Identity Card for chemists) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1966 | Carteira de Identidade Profissional (Professional Identity Card for judicial technicians) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1967 | Carteira de Identidade Profissional (Professional Identity Card for radiology technician) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1971 | Carteira de Identidade Profissional (Professional Identity Card for Psychologists) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1972 | Campo Grande Guarda Civil Metropolitana / Police Identification Card | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1978 | Carteira de Identidade Profissional CFM (Professional Identity Card for doctors) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1979 | Carteira de Identidade Profissional CONFEA (Professional Identity Card for engineers, architects and agronomists) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1980 | Carteira de Identidade Profissional CAU (Professional Identity Card for architects and urban planners) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1981 | Cedula de Identidade de Medico (Doctor's Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1982 | Carteira de Identidade Profissional COFEN (Professional Identity Card for nursing technicians) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1983 | Carteira de Identidade Profissional CFMV (Professional Identity Card for veterinarians) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1984 | Carteira de Identidade Profissional COFEN (Professional Identity Card for nursing assistants) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1985 | Carteira de Identidade de doador de órgãos e tecidos (Organ and tissue donor Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1986 | Carteira de Identidade Profissional CFA (Administrators Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1987 | Carteira de Identidade Profissional CBMDF (Identity Card of the Federal District Military Fire Department) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1988 | Carteira de Identidade Profissional COFEN (Professional Identity Card for experts) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1989 | Carteira de Identidade Profissional CRESS (Professional Identity Card for social workers) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1990 | Carteira de Identidade Profissional CREFONO (Professional Identity Card for speech therapists) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1991 | Carteira de Identidade Profissional CFF (Professional Identity Card for pharmacists) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1992 | Carteira de Identidade Profissional CFO (Professional Identity Card for odontologist) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1994 | Carteira de Identidade Profissional CRTR (Professional Identity Card for radiology technicians) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1995 | Carteira de Identidade Profissional COFECI-CRECI (Professional Identity Card for real estate agents) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1996 | Carteira de Identidade Profissional CFP (Professional Identity Card for psychologists) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1997 | Carteira de Identidade Profissional CRP (Professional Identity Card for psychologists) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1998 | Carteira de Identidade Profissional CFMV (Professional Identity Card for veterinarians) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 1999 | Carteira de Identidade Profissional CRTR (Professional Identity Card for radiology technicians) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 2000 | Carteira de Identidade Profissional CONFEA (Professional Identity Card for engineers, architects and agronomists) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 2001 | Carteira de Identidade Profissional CFM (Professional Identity Card for doctors) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 2002 | Carteira de Identidade Profissional COFECI-CRECI (Professional Identity Card for real estate agents) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 2003 | Carteira de Identidade Profissional OAB (Professional Identity Card for lawyers) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 2004 | Carteira de Identidade Profissional OAB (Professional Identity Card for lawyers) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 2005 | Carteira de Identidade Profissional CRC (Professional Identity Card for accounting) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 2006 | Carteira de Identidade Profissional COFEN (Professional Identity Card for nurses and nursing technicians) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 2007 | Carteira de Identidade Profissional CFBM (Professional Identity Card for nurses and biomedical sciences) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 2012 | Carteira de Identidade Profissional CREFITO (Professional Identity Card for physiotherapists and occupational therapists) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 2015 | Carteira de Identidade Profissional CAU (Professional Identity Card for architects and urban planners) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 2016 | Carteira de Identidade Profissional CRESS (Professional Identity Card for social workers) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 2018 | Carteira de identidade Funcional - Ministerio da Saude (Identity Card for Ministry of Health workers) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 2019 | Carteira de Identidade Profissional CRA (Administrators Professional Identity Card) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 2020 | Carteira de Identidade Profissional CFF (Professional Identity Card for pharmacists) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 2021 | Carteira de Identidade Profissional CONFEA (Professional Identity Card for engineers and agronomists) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 2023 | Carteira de Identidade Profissional CFMV (Professional Identity Card for veterinarians) | | FederalID | DOMESTIC\_IDENTIFICATION\_CARD | 2024 | Carteira de Identidade Profissional CFM (Professional Identity Card for doctors) | ### Federal Police Identity Cards | Type of ID | Subtype of ID | Version | Description | | :--------- | :--------------------------- | :------ | :-------------------------------------------------------------------------------------------------------------------------- | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1949 | Police Identity Card | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1951 | Guarda Civil Municipal / Police Identity Card | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1952 | Polícia Legislativa Federal / Police Identity Card | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1954 | Policial Legislativo Federal / Police Identity Card | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1958 | Polícia Militar Identidade Funcional / Police Identity Card | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1960 | Guarda Civil Municipal / Police Identity Card | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1961 | Policia Civil Certificado Digital / Civil Police Digital Certificate | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1965 | Guarda Civil Carteira de Identidade Funcional / Police Identity Card | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1967 | Policia Civil Documento de Identidade Funcional / Civil Police Identity Card | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1969 | Estado de Mato Grosso do Sol Policia Civil Identidade / Police Identification Card | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1972 | Campo Grande Guarda Civil Metropolitana / Police Identification Card | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1973 | Estado de Minas Gerais Policia Civil Identidade Funcional / Police Identification Card | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1974 | Estado de Minas Gerais Identidade Funcional / Police Identification Card | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1976 | Policia Civil Delegado / Police Identification Card | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1977 | Polícia Militar Carteira de Identidade / Military Police Identity Card | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1981 | Polícia Rodoviária Federal (Federal Highway Police Identification Card) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1984 | Polícia Militar Carteira de Identidade / Military Police Identity Card | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1985 | Carteira de Identidade Policia Militar / Police Identity Card | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1987 | Polícia Militar Carteira de Identidade / Police Identity Card | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1990 | Carteira de Identidade Policia Militar - Estado de Mato Grosso (Military Police Identity Card - State Mato Grosso) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1991 | Police Identification Card | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1992 | Carteira de Identidade Policia Militar - Estado de Maranhão (Military Police Identity Card - State of Maranhão) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1993 | Carteira de Identidade Policia Militar - Estado de Alagoas (Military Police Identity Card - State of Alagoas) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1994 | Carteira de Identidade Policia Militar - Estado de São Paulo (Military Police Identity Card - State of São Paulo) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1995 | Carteira de Identidade Policia Militar - Estado de Roraima (Military Police Identity Card - State of Roraima) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1996 | Carteira de Identidade Policia Militar - Estado de Pará (Military Police Identity Card - State of Pará) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1997 | Carteira de Identidade Policia Militar - Estado de Espirito Santo (Military Police Identity Card - State of Espirito Santo) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 1998 | Carteira de Identidade Policia Militar - Estado do Acre (Military Police Identity Card - State of Acre) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 2001 | Carteira de Identidade Policia Militar - Estado de Paraná (Military Police Identity Card - State of Paraná) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 2002 | Carteira de Identidade Policia Militar - Estado do Paraíba (Military Police Identity Card - State of Paraíba) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 2004 | Carteira Nacional de Vigilante (Police Identification Card) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 2005 | Carteira de Identidade Policia Militar (Military Police Identity Card) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 2006 | Polícia Militar / Police Identity Card | | FederalID | POLICE\_IDENTIFICATION\_CARD | 2007 | Carteira de Identidade Policia Militar (Military Police Identity Card) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 2010 | Carteira de Identidade Policia Militar (Military Police Identity Card) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 2013 | Carteira de Identidade Policia Civil (Civil Police Identity Card) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 2014 | Carteira de Identidade Policia GOIAS (GOIAS Police Identity Card) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 2015 | Carteira de Identidade Policia Militar (Military Police Identity Card) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 2016 | Carteira de Identidade Funcional - BRIGADA MILITAR (Military Brigade Identity Card) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 2017 | Carteira de Identidade Policia Militar - Estado do Paraíba (Military Police Identity Card - State of Paraíba) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 2018 | Identidade Funcional - POLICIA MILITAR (Military Police Identity Card) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 2019 | Carteira de Identidade - POLICIA MILITAR (Military Police Identity Card) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 2020 | Carteira de Identidade - POLICIA MILITAR (Military Police Identity Card) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 2021 | Guarda Municipal Carteira de Idenitdade (Municipal Guard Identity Card) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 2022 | Carteira de Identidade - POLICIA MILITAR (Military Police Identity Card) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 2023 | Carteira de Identidade - Policia Militar de Minas Gerais (Identity Card - Military Police of Minas Gerais) | | FederalID | POLICE\_IDENTIFICATION\_CARD | 2025 | Polícia Penal Identidade Funcional / Police Identity Card | ### Federal Military Identity Cards | Type of ID | Subtype of ID | Version | Description | | :--------- | :----------------------------- | :------ | :--------------------------------------------------------------------------------------------- | | FederalID | AIRFORCE\_IDENTIFICATION\_CARD | 2014 | Carteira de Identidade Militar (Militar Identity Card) | | FederalID | AIRFORCE\_IDENTIFICATION\_CARD | 2015 | Carteira de Identidade Militar (Militar Identity Card) | | FederalID | MILITAR\_IDENTIFICATION\_CARD | 2001 | Carteira de Identidade - Corpo de Bombeiros Militar (Military Identity Card) | | FederalID | MILITAR\_IDENTIFICATION\_CARD | 2004 | Militar Identification Card | | FederalID | MILITAR\_IDENTIFICATION\_CARD | 2005 | Militar Identification Card | | FederalID | MILITAR\_IDENTIFICATION\_CARD | 2006 | Militar Identification Card | | FederalID | MILITAR\_IDENTIFICATION\_CARD | 2007 | Militar Identification Card | | FederalID | MILITAR\_IDENTIFICATION\_CARD | 2010 | Carteira de identidade do exercito (Military Identity Card) | | FederalID | MILITAR\_IDENTIFICATION\_CARD | 2011 | Militar Identification Card | | FederalID | MILITAR\_IDENTIFICATION\_CARD | 2012 | Corpo de Bomberios Militar Identidade Funcional / Militar Identity Card | | FederalID | MILITAR\_IDENTIFICATION\_CARD | 2013 | Militar Identification Card | | FederalID | MILITAR\_IDENTIFICATION\_CARD | 2015 | Military Identity Card | | FederalID | MILITAR\_IDENTIFICATION\_CARD | 2017 | Militar Identification Card | | FederalID | MILITAR\_IDENTIFICATION\_CARD | 2020 | Carteira de Identidade Militar (Military Identity Card) | | FederalID | MILITAR\_IDENTIFICATION\_CARD | 2021 | Bombeiro Militar Identidade Funcional / Militar Identity Card | | FederalID | MILITAR\_IDENTIFICATION\_CARD | 2022 | Carteira de Identidade Militar (Military Identity Card) | | FederalID | MILITAR\_IDENTIFICATION\_CARD | 2023 | Carteira de Identidade Militar (Military Identity Card) | | FederalID | MILITAR\_IDENTIFICATION\_CARD | 2024 | Carteira de Identidade - Corpo de Bombeiros Militar (Identity Card - Military Fire Department) | | FederalID | MILITAR\_IDENTIFICATION\_CARD | 2025 | Carteira de Identidade - Corpo de Bombeiros Militar (Military Identity Card) | | FederalID | MILITAR\_SERVICE\_CARD | 2010 | Certificado de Dispensa de Incorporacao (Certificate of exemption from incorporation) | | FederalID | NAVY\_IDENTIFICATION\_CARD | 1990 | Cartao de Identificacao da Marina (Navy Identity Card) | | FederalID | NAVY\_IDENTIFICATION\_CARD | 2000 | Cartao de Identificacao da Marina (Navy Identity Card) | ### Federal Other IDs | Type of ID | Subtype of ID | Version | Description | | :--------- | :--------------------------------- | :------ | :-------------------------------------------------------------------------------------------------------- | | FederalID | DIGITAL\_IDENTIFICATION\_CARD\_PDF | 2024 | Federal Digital Identification Card | | FederalID | DIGITAL\_IDENTIFICATION\_CARD\_PDF | 2025 | Federal Digital Identification Card | | FederalID | DIGITAL\_IDENTIFICATION\_CARD\_PDF | 2026 | Federal Digital Identification Card | | FederalID | DIGITAL\_IDENTITY\_CARD | 2021 | Carteira Nacional de Habilitação (Digital Identity Card) | | FederalID | DISABILITY\_IDENTIFICATION\_CARD | 2024 | Disability Identification Card | | FederalID | FEDERAL\_IDENTIFICATION | 2000 | Carteira de Identidade Federal (Federal Identity Card) | | FederalID | IDENTIFICATION\_CARD | 2000 | Carteira Especial de Identidade (Special Identity Card) | | FederalID | IDENTIFICATION\_CARD | 2001 | Titulo Eleitoral (Voter Registration Card) | | FederalID | IDENTIFICATION\_CARD | 2002 | Estado De Rio de Janeiro - Cedula de Identidade (State Rio de Janeiro - Identification Card) | | FederalID | IDENTIFICATION\_CARD | 2004 | Carteira de Identidade Profissional COFEN (Professional Identity Card for nurses and nursing technicians) | | FederalID | IDENTIFICATION\_CARD | 2013 | Carteira de Identidade de Contabilista CRC (Accountant Identity Card) | | FederalID | IDENTIFICATION\_CARD | 2019 | Carteira de Identidade Federal (Federal Identity Card) | | FederalID | IDENTIFICATION\_CARD | 2020 | Carteira de Identidade Federal (Federal Identity Card) | | FederalID | IDENTIFICATION\_CARD | 2021 | Cedula de Identidade Profissional CREF (Professional Identity Card for physicists) | | FederalID | IDENTIFICATION\_CARD | 2022 | Carteira de Identidade - Estado de Mato Grosso (Mato Grosso Identity Card) | | FederalID | IDENTIFICATION\_CARD | 2024 | Estado De Mato Grosso - Carteira de Identidade (State Mato Grosso - Identification Card) | | FederalID | TAX\_IDENTIFICATION | 2000 | Cadastro de Pessoas Físicas (Taxpayer Registry Identification) | | FederalID | TAX\_IDENTIFICATION | 2009 | Cadastro de Pessoas Físicas (Taxpayer Registry Identification) | | FederalID | TAX\_IDENTIFICATION | 2010 | Comprovante de Inscrição CPF (Proof of CPF Registration) | | FederalID | TAX\_IDENTIFICATION | 2011 | Cadastro de Pessoas Físicas (Taxpayer Registry Identification) | ## Chile (CHL) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :------------------------------------------------------------------------------------------ | | ALL | DriversLicense | DRIVER\_LICENSE | 2000 | Licencia de Conductor (Driving License) | | ALL | DriversLicense | DRIVER\_LICENSE | 2019 | Licencia de Conductor / Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2000 | Identification Personal - Cedula de Ciudadania (Personal Identification - Citizenship Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2007 | Cedula de Identidad (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2013 | Cedula de Identidad (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2024 | Cedula de Identidad (Identity Card) | | ALL | ResidenceDocument | RESIDENCE\_DOCUMENT | 2025 | Cédula de Identidad Extranjero (Residence Document) | | ALL | Passport | NATIONAL\_PASSPORT | 2013 | Pasaporte (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2025 | Pasaporte / National Passport | | ALL | Passport | EMERGENCY\_PASSPORT | 2022 | Pasaporte de Emergencia (Emergency Passport) | | ALL | Visa | VISA | 2019 | Visa | ## Colombia (COL) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :---------------------------- | :------ | :------------------------------------------------------------ | | ALL | DriversLicense | DRIVER\_LICENSE | 2000 | Drivers License | | ALL | DriversLicense | DRIVER\_LICENSE | 2012 | Drivers License | | ALL | DriversLicense | DRIVER\_LICENSE | 2013 | Drivers License | | ALL | DriversLicense | DRIVER\_LICENSE | 2024 | Licencia de Conducción (Driving License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2000 | Cédula de Ciudadanía | | ALL | IdentificationCard | MINORS\_ID | 2008 | Tarjeta de Identidad (Minors Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Cédula de Ciudadanía | | ALL | Military | MILITARY\_CARD | 2010 | Ministerio de Defensa Nacional | | ALL | Military | MILITARY\_CARD | 2018 | Military Card | | ALL | Passport | NATIONAL\_PASSPORT | 2007 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2024 | Pasaporte / Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2026 | Passport | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2000 | Cédula de Extranjería | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2014 | Cédula de Extranjería | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Permiso por Protección Temporal | | ALL | ResidenceDocument | IMMIGRATION\_CARD | 2014 | Cedula de Extranjeria (Foreigner ID) | | ALL | ResidenceDocument | IMMIGRATION\_CARD | 2015 | Cedula de Extranjería (Immigration Card) | | ALL | ResidenceDocument | PEP\_TUTOR | 2026 | Permiso por Protección Temporal - Tutor | | ALL | ResidenceDocument | TEMPORARY\_PROTECTION\_PERMIT | 2020 | Permiso por Proteccion Temporal (Temporary Protection Permit) | | ALL | TravelDocument | CONSULAR\_CARD | 2023 | Registro Consular / Consular Registration Card | | ALL | Visa | VISA | 2010 | Visa | | ALL | Visa | VISA | 2017 | Visa | | ALL | Visa | ELECTRONIC\_VISA | 2023 | Electronic Visa | | ALL | MedicalCard | HEALTH\_CARD | 2022 | Carné de Servicios de Salud / Health Card | ## Ecuador (ECU) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :--------------------------- | :------ | :-------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2018 | Licencia de Conducir (Driver's License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2019 | Licencia de Conducir (Driver's License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2000 | Cedula de Ciudadania (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2011 | Cedula de Ciudadania (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Cedula de Identidad (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2021 | Cedula de Ciudadania (Identity Card) | | ALL | IdentificationCard | POLICE\_IDENTIFICATION\_CARD | 2020 | Police Identification Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2024 | Voter Identification Card | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2025 | Voter Identification Card | | ALL | Military | MILITARY\_CARD | 2023 | Military Card | | ALL | Military | MILITARY\_CARD | 2024 | Military Card | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Pasaporte (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2020 | Pasaporte (Passport) | | ALL | TravelDocument | CONSULAR\_ID\_CARD | 2024 | Consular Identity Card | ## Guyana (GUY) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2010 | Driver's License | | ALL | DriversLicense | DRIVERS\_LICENSE | 2019 | Driver License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2017 | Guyana Identification Card | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2025 | Guyana Identification Card | | ALL | Passport | NATIONAL\_PASSPORT | 2014 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Passport | | ALL | Passport | NATIONAL\_PASSPORT | 2025 | Passport | ## Paraguay (PRY) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :--------------------------- | :------ | :---------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2017 | Licencia de Conducir (Driver's License) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2008 | Cedula de Identidad Civil (Civil Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2018 | Cedula de Identidad Civil (Civil Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2023 | Cedula de Identidad Civil (Civil Identity Card) | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2020 | Residence Permit | | ALL | ResidenceDocument | RESIDENCE\_PERMIT | 2024 | Residence Permit | | ALL | ResidenceDocument | TEMPORARY\_RESIDENCE\_PERMIT | 2025 | Temporary Residence Permit | | ALL | Passport | NATIONAL\_PASSPORT | 2012 | Pasaporte (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2014 | Pasaporte (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2023 | Pasaporte (Passport) | | ALL | TravelDocument | CONSULAR\_CARD | 2020 | Consular Card | ## Peru (PER) ### National IDs | Type of ID | Subtype of ID | Version | Description | | :----------------- | :---------------------------- | :------ | :----------------------------------------------------------- | | IdentificationCard | IDENTIFICATION\_CARD | 2000 | Documento Nacional de Identidad (Identity Card) | | IdentificationCard | IDENTIFICATION\_CARD | 2001 | Documento Nacional de Identidad (Identity Card) | | IdentificationCard | IDENTIFICATION\_CARD | 2013 | Documento Nacional de Identidad (Identity Card) | | IdentificationCard | IDENTIFICATION\_CARD | 2020 | Documento Nacional de Identidad (Identity Card) | | IdentificationCard | IDENTIFICATION\_CARD | 2025 | Identification Card | | IdentificationCard | REFUGEE\_IDENTIFICATION\_CARD | 2019 | Carne de Solicitante de Refugio (Refugee Identity Card) | | Military | MILITARY\_CARD | 2011 | Military Card | | Military | MILITARY\_CARD | 2015 | Carnet de Tropa Servicio Militar / Military Card | | Military | MILITARY\_CARD | 2016 | Military Card | | Military | MILITARY\_CARD | 2017 | Military Card | | Military | MILITARY\_CARD | 2018 | Military Card | | Military | MILITARY\_CARD | 2019 | Military Card | | Military | MILITARY\_CARD | 2020 | Military Card | | Military | MILITARY\_CARD | 2021 | Military Card | | Military | MILITARY\_CARD | 2022 | Military Card | | Military | MILITARY\_CARD | 2025 | Military Card | | Military | MILITARY\_CARD | 2026 | Military Card | | Passport | NATIONAL\_PASSPORT | 2000 | Pasaporte (Passport) | | Passport | NATIONAL\_PASSPORT | 2014 | Pasaporte (Passport) | | Passport | NATIONAL\_PASSPORT | 2016 | Pasaporte (Passport) | | ResidenceDocument | RESIDENCE\_PERMIT | 2000 | Residence Permit | | ResidenceDocument | RESIDENCE\_PERMIT | 2017 | Carné de Extranjería (Foreigner Identity Card) | | ResidenceDocument | RESIDENCE\_PERMIT | 2021 | Carné de Extranjería (Foreigner Identity Card) | | ResidenceDocument | TEMPORAL\_RESIDENCE\_PERMIT | 2018 | Permiso Temporal de Permanencia (Temporary Residence Permit) | | ResidenceDocument | TEMPORAL\_RESIDENCE\_PERMIT | 2020 | Carné Temporal de Permanencia (Temporary Residence Card) | | TravelDocument | CONSULAR\_CARD | 2020 | Consular Card | | Visa | VISA | 2024 | Visa | ### Drivers Licenses | Type of ID | Subtype of ID | Version | Description | | :------------- | :--------------------------- | :------ | :------------------------------------------------------------------------------------------------------ | | DriversLicense | DRIVERS\_LICENSE | 1884 | Municipalidad Provincial de Azangaro Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1885 | Municipalidad Provincial de Jauja Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1889 | Licencia de Conducir (Municipalidad Provincia de Canta) / Driver License | | DriversLicense | DRIVERS\_LICENSE | 1890 | Municipalidad Provincial de Chupaca Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1892 | Municipalidad Provincial de Cutervo Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1893 | Municipalidad Provincial de Puno Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1896 | Municipalidad Provincial de Chiclayo Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1897 | Municipalidad Provincial de la Convencion Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1899 | Municipalidad Provincial de Paita Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1901 | Municipalidad Provincial de Yauyos Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1902 | Municipalidad Provincial de Tambopata Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1903 | Municipalidad Provincial Sánchez Carrión Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1904 | Municipalidad Provincial de Dos de Mayo Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1905 | Municipalidad Provincial de Huamalies Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1906 | Municipalidad Provincial de Cajamarca Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1907 | Municipalidad Provincial de Andahuaylas Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1910 | Municipalidad Provincial de Acobamba Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1911 | Municipalidad Provincial de Chepén Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1912 | Municipalidad Provincial de Canta Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1914 | Provincia de Mariscal Caceres - Juanjui Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1915 | Municipalidad Provincial de la Mar San Miguel Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1918 | Municipalidad Provincial de Zarumilla Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1920 | Municipalidad Provincial de Contralmirante Villar Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1921 | Municipalidad Provincial de Padre Abad Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1922 | Municipalidad Provincial de Utcubamba Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1923 | Municipalidad Provincial de Ayabaca Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1924 | Municipalidad Provincial de Condesuyos Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1925 | Municipalidad Provincial de Paucartambo Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1926 | Municipalidad Provincial de Satipo Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1928 | Licencia de Conducir Vehiculos Menores (Municipalidad Provincial de Pallasca Cabana) / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1929 | Licencia de Conducir (Municipalidad Provincial de Oxapampa) / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1930 | Licencia de Conducir (Lamas) / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1932 | Municipalidad Provincial de Palpa - Ica Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1933 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1934 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1936 | Municipalidad Provincial de Pisco Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1937 | Licencia de Conducir Vehiculos Menores (Municipalidad Provincial de Ascope) / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1938 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1939 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1941 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1942 | Municipalidad Provincial de Chincha Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1943 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1944 | Licencia de Conducir Vehiculos Menores (Municipalidad Provincial de Coronel Portillo) / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1945 | Licencia de Conducir (Driving License) | | DriversLicense | DRIVERS\_LICENSE | 1947 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1948 | Licencia de Conducir (Driving License) | | DriversLicense | DRIVERS\_LICENSE | 1949 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1950 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1951 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1953 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1955 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1956 | Licencia de Conducir Vehiculos Menores (Municipalidad Provincial de Camana) / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1957 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1958 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1959 | Licencia de Conducir (Driving License) | | DriversLicense | DRIVERS\_LICENSE | 1960 | Licencia de Conducir (Driving License) | | DriversLicense | DRIVERS\_LICENSE | 1961 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1962 | Licencia de Conducir (Driving License) | | DriversLicense | DRIVERS\_LICENSE | 1963 | Municipalidad Provincial de Chucuito - Juli Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1964 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1965 | Municipalidad Provincial de Huanuco Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1966 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1967 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1968 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1969 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1970 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1974 | Municipalidad Provincial de Rioja Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1975 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1977 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1978 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1980 | Licencia de Conducir Vehiculos Menores (Municipalidad Provincial de Huaral) / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1981 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1983 | Municipalidad Provincial de Antabamba Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1985 | Licencia de Conducir Vehiculos Menores (Municipalidad Provincial de la Convencion) / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1988 | Licencia de Conducir (Driving License) | | DriversLicense | DRIVERS\_LICENSE | 1989 | Licencia de Conducir (Driving License) | | DriversLicense | DRIVERS\_LICENSE | 1990 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1991 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1993 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1995 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1997 | Licencia de Conducir (Driving License) | | DriversLicense | DRIVERS\_LICENSE | 1998 | Licencia de Conducir Vehiculos Menores (Municipalidad Provincial de Tahuamanu) / Driving License | | DriversLicense | DRIVERS\_LICENSE | 1999 | Licencia de Conducir (Driver License) | | DriversLicense | DRIVERS\_LICENSE | 2000 | Licencia de Conducir (Driver License) | | DriversLicense | DRIVERS\_LICENSE | 2002 | Licencia de Conducir Vehiculos Menores (Driver's License for Minor Vehicles) | | DriversLicense | DRIVERS\_LICENSE | 2006 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 2009 | Municipalidad Provincial de Atalaya Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 2010 | Municipalidad Provincial de Antabamba Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 2011 | Licencia de Conducir Vehiculos Menores (Driver's License for Minor Vehicles) | | DriversLicense | DRIVERS\_LICENSE | 2012 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 2013 | Municipalidad Provincial de Leoncio Prado Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 2015 | Municipalidad Provincial de Canta Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 2016 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 2019 | Municipalidad Provincial de Maynas Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 2020 | Licencia de Conducir / Driving License | | DriversLicense | DRIVERS\_LICENSE | 2024 | Municipalidad Provincial de Ferreñafe Licencia de Conducir / Driving License | | DriversLicense | ELECTRONIC\_DRIVERS\_LICENSE | 2019 | Licencia de Conducir Electrónica / Electronic Drivers License | | DriversLicense | ELECTRONIC\_DRIVERS\_LICENSE | 2020 | Licencia de Conducir Electrónica (Electronic Driver License) | | DriversLicense | ELECTRONIC\_DRIVERS\_LICENSE | 2024 | Licencia de Conducir Electronica / Electronic Driving License | ## Suriname (SUR) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------- | :------ | :--------------------------- | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2019 | Identification Card | | ALL | DriversLicense | DRIVERS\_LICENSE | 2018 | Rijbewijs (Driver's License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2021 | Driver License | | ALL | Passport | NATIONAL\_PASSPORT | 2014 | Paspoort (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2018 | Paspoort (Passport) | ## Uruguay (URY) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :------------------ | :-------------------------- | :------ | :------------------------------------------------------ | | ALL | DriversLicense | DRIVER\_LICENSE | 2000 | Licencia Nacional de Conductor (Driver License) | | ALL | DriversLicense | DRIVER\_LICENSE | 2014 | Licencia Nacional de Conductor / Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2015 | Permiso Unico Nacional de Conduccion (Driver's License) | | ALL | DriversLicense | DRIVER\_LICENSE | 2016 | Licencia Nacional de Conductor / Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2017 | Licencia Nacional de Conductor / Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2018 | Licencia de Conductor / Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2019 | Licencia Nacional de Conductor / Driving License | | ALL | DriversLicense | DRIVER\_LICENSE | 2023 | Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2000 | Cedula de Identidad (Identity Card) | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2001 | Carteira de Identidade (Identity Card) | | ALL | Passport | NATIONAL\_PASSPORT | 2014 | Pasaporte (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2015 | Pasaporte (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2020 | Pasaporte (Passport) | | ALL | Visa | VISA | 2023 | Visa | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2008 | Carte Electoral (Voter Card) | | ALL | VoterIdentification | VOTER\_IDENTIFICATION\_CARD | 2010 | Cartao de Eleitor (Voter Card) | ## Venezuela (VEN) | State | Type of ID | Subtype of ID | Version | Description | | :---- | :----------------- | :------------------------------- | :------ | :-------------------------------------------------------------- | | ALL | DriversLicense | DRIVERS\_LICENSE | 2000 | Licencia para Conducir (Driver's License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2017 | Licencia para Conducir (Driver's License) | | ALL | DriversLicense | DRIVERS\_LICENSE | 2024 | Licencia para Conducir / Driving License | | ALL | IdentificationCard | IDENTIFICATION\_CARD | 2000 | Cedula de Identidad (Identity Card) | | ALL | IdentificationCard | HOMELAND\_CARD | 2020 | Carnet de la Patria / Homeland Card | | ALL | IdentificationCard | DISABILITY\_IDENTIFICATION\_CARD | 2020 | Certificado de la Discapacidad / Disability Identification Card | | ALL | Military | MILITARY\_CARD | 2020 | Fuerza Armada Nacional Bolivariana Military Card | | ALL | Passport | NATIONAL\_PASSPORT | 2000 | Pasaporte (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2007 | Pasaporte (Passport) | | ALL | Passport | NATIONAL\_PASSPORT | 2017 | Pasaporte (Passport) | | ALL | Visa | VISA | 2019 | Visa | --- ## Transaction Monitoring(Transaction-monitoring) Transaction Monitoring is Zyphe's real-time payment-screening capability. Where KYC and KYB verify **who** a user is at onboarding and AML screens them against sanctions, PEP, and adverse-media lists, Transaction Monitoring watches **what they do afterwards**: evaluating each payment event as it happens and returning an **Allow**, **Review**, or **Block** decision before your platform moves any funds. Because Zyphe already verifies your users, every monitored transaction is tied to a **verified identity**. A single rule can combine transactional signals (amount, counterparty, country, timing) with identity signals (KYC risk score, account age). This is what closes the loop between onboarding, screening, and ongoing activity: **full-cycle compliance** from the first verification to every subsequent payment. ## The decision model Your integration reports a transaction event; Zyphe evaluates it synchronously against your organization's enabled **rules**. Each rule that fires contributes a probability, and the contributions are combined into a single risk probability with a probabilistic union (noisy-OR): ```text P(risk) = 1 − ∏ (1 − pᵢ) ``` `P(risk)` is compared against your organization's thresholds to produce the verdict: | Condition | Decision | | ------------------------------------ | -------- | | `P(risk)` below the review threshold | Allow | | `P(risk)` ≥ review threshold | Review | | `P(risk)` ≥ block threshold | Block | This is the **same combinator** used by Zyphe's generalized scoring engine. See [Scoring](/docs/guides/scoring) for the underlying mathematics of tags, banding, and thresholds. Transaction Monitoring applies it to per-transaction rules rather than to verification-flow signals. ## Privacy-preserving by design Like the rest of Zyphe, Transaction Monitoring works over decentralized identity: only the minimal attributes needed to evaluate a rule are read from the user's vault, and every evaluation is written to a hash-chained audit trail. Personal data is not centralized to enable monitoring. ## Sandbox-first Transaction Monitoring can be enabled in **sandbox only**: a prospect gets the full rule builder, templates, lists, and evaluation loop against synthetic data, with no production entitlement and no data-processing agreement required. This makes it possible to design and backtest a rule set before any real payment traffic or contract is in place. ## Where to go next Templates in the catalog are **starters** (UIF _indicatori di anomalia_, FCA/JMLSG, universal primitives), not an exhaustive list of rules you can write. Instantiating a template copies it into your rule set so you can name it and set cutoffs; you can also author a rule from a blank builder. See [Templates vs rules](/docs/guides/transaction-monitoring/rules-and-templates#templates-vs-rules). The same AI-agent modes used on KYC and KYB (Disabled / Suggest / Auto-pilot) are the intended first-line triage for TM alerts. They are not yet configurable; see [Antifraud controls](/docs/how-it-works/antifraud-controls#ai-agents-as-first-line-analysts). This page is the conceptual overview. To configure and operate Transaction Monitoring, reporting events, authoring rules, instantiating regulator-informed templates, curating lists, tuning thresholds, and handling alerts. See the **[Transaction Monitoring guides](/docs/guides/transaction-monitoring)**. --- ## Verification Process ## Overview The onboarding flow can be composed by a single step or multiple steps. Any onboarding flow contains at least one **Identity Verification** step (**IDV**) such as a Document Verification or a login with eID. Typically, a complete identity verification flow includes both a Document Verification step (to scan and validate the identity document) and a Liveness Verification step (to ensure the person is real and matches the document). All critical operations such as document scanning and liveness checks are always performed on our platform through a secure HTTPS connection. That way we can add a first layer of security ensuring that the acquisition is performed properly, reducing the risk of deep fake. The platform provides two distinct methods to integrate with your app: ### Public Web Link Each onboarding flow is associated with a unique public web link that can be shared with the users. Once they click on it, they are redirected to a designated flow on our platform. In this setup, users must authenticate via email by manually entering their email address, clicking the link sent to their inbox, and completing the flow. It involves the following steps: - The user clicks a button on your website containing the link to the proper verification flow on the Zyphe Platform - The user is redirected to the Zyphe platform - The user authenticate on the Zyphe platform with his email - The user performs any verification step directly on the Zyphe platform - Zyphe notify your backend about the verification result via the Webhook and make the result accessible within the dashboard Here, you can find a video that demonstrates integration and identity verification using the public web link: ### SDK The SDK integration supports 2 different approaches: #### Dynamic link generation Using the nodejs SDK it's possible to dynamically generate the verification session together with a link that redirects to our platform to complete the verification. ```mermaid sequenceDiagram actor User participant AF as App frontend participant AB as App backend (nodejs sdk) participant ZB as Zyphe backend participant ZF as Zyphe frontend User->>+AF: start verification AF->>+AB: request AB->>+ZB: create verification session ZB-->>+AB: verification session token AB-->>+AB: generate verification session link AB-->>+AF: verification session link AF-->>+User: redirect User->>+ZF: perform verification ``` #### Embed into your web app Using the browser SDK it's possible to embed the verification flow directly into your application through an iframe. ```mermaid sequenceDiagram actor User participant AF as App frontend (browser sdk) participant ZB as Zyphe backend User->>+AF: start verification AF->>+ZB: create verification session ZB-->>+AF: verification session token AF-->>+AF: render iframe AF-->>+User: ready User->>+AF: perform verification ``` :::info The browser integration is done through an iframe to ensure that the javascript that is executed is not manipulated and the communication between the SDK and the backend is properly authenticated. ::: --- ## Verification types Zyphe verifies individuals (KYC) and businesses (KYB), screens them for financial-crime risk and monitors their payments, using checks you compose into flows: document verification with chip reading, liveness and face match, proof of address, minimum age, geolocation, phone, crypto wallet, Italian SPID/CIE, gambling self-exclusion registers, AML screening (sanctions, PEP, watchlists and adverse media), business verification with UBO discovery, US TIN Check and Transaction Monitoring. A user who is already verified can reuse that result through reusable credentials and KYC Passport. Every check returns a structured status that your backend reads from webhooks or the API. :::tip[This page is a map] Each row links to the page that explains how the check works and to the guide that configures it. Status values are defined once, in [Statuses and codes](/docs/reference/statuses-and-codes), and payload fields in [Webhook Payload](/docs/guides/webhook/webhook-payload). ::: ## All checks at a glance | Check | What it verifies | The user provides | You get back | Coverage | | ------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | **[Document verification](/docs/how-it-works/document-verification)**[Set up →](/docs/guides/create-a-flow/document-verification) | The ID is authentic, readable and allowed by your filters; the contactless chip is read when present | A capture or upload of the ID | `data.dv.status`, [`reasons[]`](/docs/reference/statuses-and-codes#document-verification-reasons-datadvreasons), `documentType`; images through the [Export API](/docs/guides/export-api) | Documents from 190+ countries; see [Supported KYC documents](/docs/supported-documents) | | **[Minimum age](/docs/how-it-works/document-verification#what-it-does)**[Set up →](/docs/guides/create-a-flow/document-verification) | The document's date of birth meets your minimum age | Nothing extra | [`DATE_OF_BIRTH_BELOW_MINIMUM_AGE`](/docs/reference/statuses-and-codes#country-age-and-field-rules) | As document verification | | **[Liveness and face match](/docs/how-it-works/liveness)**[Set up →](/docs/guides/create-a-flow/liveness) | A live person (not a photo, screen, video or mask) whose face matches the ID portrait | An active liveness capture | [Liveness and face-match reasons](/docs/reference/statuses-and-codes#face-liveness-and-uniqueness), `scoreBiometricSelfie` | Portrait match threshold, 75% by default | | **[Proof of address](/docs/how-it-works/proof-of-address)**[Set up →](/docs/guides/create-a-flow/proof-of-address) | A recent address document of an allowed type, in the verified name | An upload such as a utility bill, bank statement or pay slip | `data.poa.status`, [`reason`](/docs/reference/statuses-and-codes#proof-of-address-reasons-datapoareason), `documentType` | The types and maximum age you set | | **[Geolocation](/docs/guides/create-a-flow/geolocation)** | The device's GPS country matches its IP country; can flag VPNs and blacklisted IPs | Device location, with permission | `data.geolocation`: `country`, `ipAddress`, `vpn`, `blacklistedIp` | Country level | | **[Phone](/docs/guides/create-a-flow/phone-verification)** | Control of a phone number, by SMS one-time code | A number in E.164 format, and the code | `data.phone`: `status`, `phoneNumberLast4` | E.164 numbers | | **[Crypto wallet](/docs/guides/create-a-flow/wallet)** | Control of a wallet address, by a signed SIWX message | A wallet connection and a signature | `data.wallet`: `walletAddress`, `walletChain`, `signature` | Ethereum and Solana, plus testnets | | **[SPID / CIE](/docs/integrations/italian-digital-identity-ecosystem-spid-and-cie)**[Set up →](/docs/guides/create-a-flow/spid-cie) | An identity asserted by an Italian SPID provider or the CIE card | A SPID or CIE login | `data.spid`: `userInfo` (name, fiscal number, date of birth and more) | Italy | | **[Self-exclusion registers](/docs/how-it-works/self-exclusion)** | The player is not on their market's gambling self-exclusion register, at signup, first deposit and on triggers | Nothing extra | A positive result rejects the action and is recorded | GAMSTOP (UK), Spelpaus (Sweden), Coalition for Fantasy Sports / idPair (US daily fantasy sports) | | **[AML screening](/docs/aml)**[Risk scoring →](/docs/aml/risk-scoring) | Sanctions, PEP, watchlists and adverse media, at onboarding and on re-screening | Nothing extra | `data.aml`: [`status`](/docs/reference/statuses-and-codes#aml-result-moderation-dataamlstatus), `hasPep`, `hasSanctions`, `riskScorePercent` (0 to 100) | More than 100,000 lists and sources | | **[KYB](/docs/how-it-works/kyb)**[Set up →](/docs/guides/kyb) | Company details against its documents and the official register, plus its owners, directors and screening | Business information, documents, owners and directors | `data.kybCase`: [`status`](/docs/reference/statuses-and-codes#kyb-case-status), `decision`; a rating from `LOW` to `CRITICAL` | Registers in 49 countries and territories, all US states and DC | | **[UBO discovery](/docs/guides/kyb/ownership-discovery)** | Ownership traced through registers to the people with 25% or more effective ownership | Nothing: the owner and director steps are skipped | `ownershipStructure`, `uboSuggestions`, a per-node cost preview | Jurisdictions with shareholder or UBO data in [Country coverage](/docs/guides/kyb/country-coverage) | | **[TIN Check](/docs/guides/tin-check)** | A US TIN and name against IRS records, plus watchlists and related lookups | Nothing in a flow; on KYB, a US business's EIN | `outcome` (`MATCH`, `MISMATCH`, `NOT_ISSUED`), `watchlists[]` | US SSNs and EINs | | **[Transaction Monitoring](/docs/transaction-monitoring)**[Set up →](/docs/guides/transaction-monitoring) | Each payment against your rules and the verified identity's signals | Nothing: your backend reports each payment | [`ALLOW`, `REVIEW` or `BLOCK`](/docs/reference/statuses-and-codes#transaction-monitoring-decisions), with `P(risk)` | Your rules and lists, from regulator-informed templates | | **[Reusable credentials](/docs/reusable-credentials-one-click-kyc)** | A returning user's eligible credential, shared by access grant instead of a new check | Consent and a vault unlock | The verification result, under the grant | Valid credentials your flow accepts | | **[KYC Passport](/docs/data-flows/kyc-passport)**[Set up →](/docs/guides/kyc-passport) | Partners you invite reuse your flow's KYC data, with the user's consent | Consent to the listed partners | Partner access grants | Partners invited before the user verifies | | **[Proof of KYC](/docs/advanced-topics/on-chain-verifiable-proof-of-kyc)** | A holder completed KYC, without exposing identity attributes | A completed KYC | A soulbound token, mint voucher, attestation, Verifiable Credential or zero-knowledge proof | On-chain and off-chain verifiers | ## Turning checks on Most checks are flow steps you add in the dashboard: see [KYC Overview](/docs/guides/create-a-flow) and [KYB Overview](/docs/guides/kyb). Some need more: - **Enabled by Zyphe support:** phone verification, SPID / CIE, and the optional biometric uniqueness check on liveness. - **Enabled per organization:** TIN Check, and the Export API that returns document images and files. - **Order in the flow:** a liveness step links to a Document Verification step; proof of address needs a Document Verification or SPID step before it. - **Off by default on the KYB step:** UBO discovery, which takes a credit budget and has to be available for your deployment and the country, and agent research. - **Set where the screening runs:** person AML screening belongs to the Document Verification step, and company, UBO and director screening to the KYB step. **AML Agent Mode** is set on those steps. - **Outside a flow:** TIN Check runs from the dashboard or from your backend with a secret API key, and Transaction Monitoring evaluates the payment events your backend reports. Transaction Monitoring can be enabled in sandbox before a production contract. - **No configuration guide yet:** self-exclusion registers, described in [Self-exclusion checks](/docs/how-it-works/self-exclusion). ## How results come back Each step writes its own result, and the verification run as a whole has its own status. A single webhook can carry three layers: the delivery `event`, the run's `flowStatus`, and the step's `data..status`. They are not synonyms; see [Three layers of status](/docs/reference/statuses-and-codes#three-layers-of-status). - **Webhooks** are sent per check type, for example `verification.dv.completed`, `verification.poa.failed` or `verification.aml.refreshed`. The full list is in [Canonical webhook event types](/docs/reference/statuses-and-codes#canonical-webhook-event-types). - **`REVIEW` means keep the user pending.** Act on the final `COMPLETED`, `FAILED` or `REJECTED` event. See [Manual review](/docs/guides/manual-review). - **Document images and address files are not in webhooks.** They come from the [Export API](/docs/guides/export-api), which also returns liveness captures. ## What you can add on top of the checks | Capability | What it adds | Where | | ------------- | -------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | Scoring | Turns AML screening results, form answers, workflow actions and assigned tags into scores from 0 to 100, each with a level | [Scoring](/docs/guides/scoring) | | Manual review | A person resolves a document verification result that automated checks could not finalize | [Manual review](/docs/guides/manual-review) | | AI agents | **AML Agent Mode** and **KYB Agent Mode** (Disabled, Suggest, Auto-pilot) on the step that produced the screening or case | [Antifraud controls](/docs/how-it-works/antifraud-controls#ai-agents-as-first-line-analysts) | | Flow Builder | Branches a flow on step outputs, custom data and the AML risk score | [Flow Builder](/docs/guides/create-a-flow#10-flow-builder) | Three more flow steps support the checks without being checks themselves: **Document Selection** routes the user to the right document and country, **Form** collects extra answers (which can feed a score), and **Sharing** passes verified data to partner flows. See [KYC Overview](/docs/guides/create-a-flow). ## Data sources What each check is checked against, as the linked pages describe it. | Check | Checked against | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Document verification | The document's own security features and layout against supported document templates, the MRZ against the OCR reading, and, where present, the contactless chip, whose contents are signed by the issuing authority | | Liveness and face match | The portrait from document verification, which can come from the chip. Liveness, face matching and injection-attack detection run in-house rather than through a third-party biometric vendor ([zyphe.com/security](https://www.zyphe.com/security)) | | Proof of address | The identity verified earlier in the flow, for the name match, and your allowed document types and maximum document age | | Geolocation | Reverse geocoding of the device's GPS coordinates, against the IP-based country derived from request headers or Cloudflare trace data; known VPN and proxy services; IP blacklists and reputation databases | | Phone | A one-time code sent by SMS through AWS SNS | | Crypto wallet | The signature over a SIWX message, verified with SECP256K1 (Ethereum) or ED25519 (Solana) | | SPID / CIE | The user's SPID identity provider or their CIE | | Self-exclusion registers | GAMSTOP, Spelpaus, and Coalition for Fantasy Sports / idPair | | AML screening | Sanctions regimes, politically exposed person data, law-enforcement and regulatory watchlists, and adverse media, drawn from more than 100,000 lists and sources through third-party screening data sources | | KYB | Official company registers, including published beneficial-ownership registers where a jurisdiction has one, and the documents the applicant uploads. With agent research on (off by default), the KYB agent can also consult extra sources and web searches within a set limit | | UBO discovery | Directors, shareholders and UBOs as returned by the official registers listed in [Country coverage](/docs/guides/kyb/country-coverage) | | TIN Check | IRS records, the Social Security Death Master File, the USPS address database, the FATCA list of registered foreign financial institutions, and watchlists such as the OFAC sanctions list | | Transaction Monitoring | Your rules and lists (country-risk sets, keyword packs, counterparty block and allow lists), rolling velocity counters, and signals from the verified identity | The register-data supplier used for business verification is named in the sub-processor list, Annex III of the data processing agreement, which is available on request. See [Privacy, consent and retention](/docs/privacy-consent-and-retention#sub-processors-and-the-dpa). ## Related - [How it works](/docs/how-it-works): the product explainers this page links to - [Antifraud controls](/docs/how-it-works/antifraud-controls): which fraud each check catches and how they combine - [Statuses and codes](/docs/reference/statuses-and-codes): every status, event and reason code - [Privacy, consent and retention](/docs/privacy-consent-and-retention): what you decide as controller and what Zyphe retains - [Quickstart](/docs/quickstart): run a first check in sandbox