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.
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, and payload fields in Webhook Payload.
All checks at a glance
| Check | What it verifies | The user provides | You get back | Coverage |
|---|---|---|---|---|
| Document verification Set up → | 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[], documentType; images through the Export API | Documents from 190+ countries; see Supported KYC documents |
| Minimum age Set up → | The document's date of birth meets your minimum age | Nothing extra | DATE_OF_BIRTH_BELOW_MINIMUM_AGE | As document verification |
| Liveness and face match Set up → | 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, scoreBiometricSelfie | Portrait match threshold, 75% by default |
| Proof of address Set up → | 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, documentType | The types and maximum age you set |
| 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 | 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 | 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 Set up → | 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 | 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 Risk scoring → | Sanctions, PEP, watchlists and adverse media, at onboarding and on re-screening | Nothing extra | data.aml: status, hasPep, hasSanctions, riskScorePercent (0 to 100) | More than 100,000 lists and sources |
| KYB Set up → | Company details against its documents and the official register, plus its owners, directors and screening | Business information, documents, owners and directors | data.kybCase: status, decision; a rating from LOW to CRITICAL | Registers in 49 countries and territories, all US states and DC |
| UBO 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 |
| 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 Set up → | Each payment against your rules and the verified identity's signals | Nothing: your backend reports each payment | ALLOW, REVIEW or BLOCK, with P(risk) | Your rules and lists, from regulator-informed templates |
| Reusable credentials | 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 Set up → | 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 | 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 and KYB Overview. 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.
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.<type>.status. They are not synonyms; see Three layers of status.
- Webhooks are sent per check type, for example
verification.dv.completed,verification.poa.failedorverification.aml.refreshed. The full list is in Canonical webhook event types. REVIEWmeans keep the user pending. Act on the finalCOMPLETED,FAILEDorREJECTEDevent. See Manual review.- Document images and address files are not in webhooks. They come from the 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 |
| Manual review | A person resolves a document verification result that automated checks could not finalize | 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 |
| Flow Builder | Branches a flow on step outputs, custom data and the AML risk score | 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.
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) |
| 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 |
| 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.
Related
- How it works: the product explainers this page links to
- Antifraud controls: which fraud each check catches and how they combine
- Statuses and codes: every status, event and reason code
- Privacy, consent and retention: what you decide as controller and what Zyphe retains
- Quickstart: run a first check in sandbox