Identity Verification (KYC and KYB)

Before a member or a business can transact, they are verified. 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; only verified passes the gate. For the signature scheme and delivery model, see Webhooks.

Verification gates fail closed. A missing or unknown verification status is treated as not verified, never as a pass, so a gated action cannot slip through on an absent result.

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. 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.

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.

Identity verification is driven through the hosted flow and signed callback above rather than a public REST surface. For the public operations XKOVA does expose, see the operations list or the interactive reference.

Was this helpful?