Identity Verification (KYC and KYB)
Identity requirements follow the tenant's committed KYC/KYB policy. XKOVA runs know your customer (KYC) and know your business (KYB) checks through a swappable identity provider. The subject completes a hosted flow at the provider, the provider posts a signed result back, and the verification gate moves the subject to verified, in progress (held for manual approval), or rejected.
The hosted flow plus callback model
Verification does not run inside XKOVA's own UI. The subject is handed a link to the provider's hosted flow, where they complete the identity steps the provider requires. When they finish, the provider posts a signed result back to XKOVA, and that callback drives the gate. This keeps sensitive identity capture at the provider and keeps XKOVA's surface free of personal data it does not need to hold.
The path a verification takes
- The subject is handed a link to the provider's hosted flow.
- The subject completes the identity steps the provider requires.
- The provider posts a signed callback to XKOVA with the result.
- XKOVA verifies the signature and moves the subject to verified, in progress (when the result is held for manual approval), or rejected.
The two checks
| Check | Subject |
|---|---|
| KYC | An individual member. |
| KYB | A business entity. |
The signed callback
The provider's result is delivered as a signed webhook so XKOVA can trust it came from the provider and
was not tampered with. XKOVA verifies the signature before acting on the verdict; an unverified callback is
rejected. The verdict normalizes to one of three states, verified, in progress, or rejected, which the gate
then enforces. A result awaiting manual approval reads as in progress on the subject; verified and an explicit policy-derived not_required pass
the gate. A missing status does not mean verification is optional. Provider callbacks use their configured verification scheme. Customer webhook delivery is a separate
contract, described in Webhooks.
Example vendors
The identity adapter is interchangeable. Examples of the kind of provider that plugs in here include Persona, Alloy, and Onfido. The institution verifies with one provider, and switching is an adapter and configuration change rather than a change to how the gate behaves. This is the orchestration model from Integrations and Orchestration applied to identity. Production verification fails closed until an approved real provider template is configured. Example vendor names do not mean every adapter ships or is self-serve. XKOVA ships a sandbox identity provider so the full member to verified loop runs in local development, with demo subjects that map to pass, fail, and review verdicts.
Related
- Screening (KYT and BSA): the transaction side of compliance.
- Policies and Quorum Governance: how a held verification is cleared.
- Operator Onboarding: where verification sits in setup.
Read Member Verification State
GET /v1/account-holders/self/verification returns verification state for the
session-bound member. In your BFF, call resolved.resources.self.verification() after
resolving the application session. Keep the XKOVA member-session credential on the server.
See Embedded Member Xperience.