> ## Documentation Index > Fetch the complete documentation index at: https://docs.kirafin.ai/llms.txt > Use this file to discover all available pages before exploring further. # What we verify by entity type > Who gets checked when you onboard a business, and what the API asks you for. Two things are checked when you create a sub-client: **the business itself**, and **each person tied to it**. They are checked separately and can land in different places, which is why a business can be waiting on one person rather than on itself. This page is the API surface — what you send, what comes back. It is not the policy behind the decision. ## The business Identified by its registration: legal name, formation country and date, address, and a tax identifier. Its trading profile is part of the check too — industry, purpose, expected volumes — because those are what the check is assessed against. The value sets for each of those fields are in [User values](/reference/users/values). ## The people tied to it Each person you list is checked in their own right, with their own identity details and documents. A business is not verified until they are. Who has to be listed is a rule about the business, not about any one person. When someone required is missing, `missing_fields` names them. ## What the API gives you back | Field | What it tells you | | --------------------- | -------------------------------------------------------------------------------------------- | | `status` | Where the sub-client is in its lifecycle. The field to branch on | | `verification_status` | The result of the identity check itself | | `missing_fields` | What is still outstanding, grouped by product, plus a `general` key holding every token once | | `eligible_products` | What the sub-client can already use, and the gaps where it cannot | `missing_fields` is the one to build on. It is machine-readable, it names the field rather than describing it, and it is what you show to whoever can supply it — usually your own customer. ## Liveness Some people are additionally asked to complete a liveness check, through a hosted link. Its result arrives on `user.liveness_completed`, naming which person completed it, and it is **independent of the sub-client's own status** — a liveness result does not move `status` by itself. What has to be attached, and how.