> ## Documentation Index
> Fetch the complete documentation index at: https://docs.venlyfinance.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Individual KYC

> Verifying a natural person — the states, both routes, and what happens to the account.

**KYC** (Know Your Customer) verifies a natural person. It applies to parties with
`partyType: INDIVIDUAL` and is tracked on `kycStatus`.

## States

Read `kycStatus` from [Get a party](/api-reference/Finance-API/parties/get-party-details):

| `kycStatus`            | Meaning                                          |
| ---------------------- | ------------------------------------------------ |
| `VERIFICATION_PENDING` | Created, awaiting a verdict. The starting state. |
| `VERIFIED`             | Approved.                                        |
| `REJECTED`             | Declined.                                        |

<Note>
  The account under this party has its **own** `kycStatus`, and that one is what gates money movement.
  It also accepts a fourth value, `NOT_REQUIRED`, which parties never carry. See
  [Roles & entities](/guides/finance/onboarding/roles-and-entities#account).
</Note>

## Create the party

```bash theme={null}
curl -X POST https://api.venlyfinance.com/v1/parties \
  -H "Authorization: Bearer {access_token}" \
  -H "Content-Type: application/json" \
  -d '{
    "partyType": "INDIVIDUAL",
    "firstName": "Jane",
    "lastName": "Doe",
    "externalId": "user-12345",
    "address": {
      "addressLine1": "123 Main Street",
      "city": "Amsterdam",
      "postalCode": "1012AB",
      "country": "NL"
    }
  }'
```

`firstName` and `lastName` are required for individuals. `externalId` is your own identifier — useful
for reconciling against your user table, and filterable on
[List parties](/api-reference/Finance-API/parties/list-all-parties).

The party comes back with `status: ACTIVE` and `kycStatus: VERIFICATION_PENDING`. `ACTIVE` here means
the record is live, **not** that Jane has been identified.

## Two routes

<CardGroup cols={2}>
  <Card title="Hosted verification link" icon="link" href="/guides/finance/onboarding/hosted-verification">
    Venly hosts the flow. Mint a link, hand it to Jane, wait for the verdict. Works for anyone.
  </Card>

  <Card title="Sumsub token sharing" icon="forward" href="/guides/finance/onboarding/sumsub-token-sharing">
    Already verified Jane in your own Sumsub account? Forward a share token instead of re-verifying.
  </Card>
</CardGroup>

Token sharing is the narrower one — it needs a `SELF_CUSTODY` company wallet type and must happen at
account creation. If either doesn't hold, use the hosted link.

There is also [tenant-managed KYC](/guides/finance/kyc-verification#tenant-managed-kyc), where you
declare `kycStatus: NOT_REQUIRED` on the account and skip Venly's verification. It needs a flag a Venly
admin enables on your tenant, and is granted for testing rather than production — so treat it as a way
to exercise money movement in tests, not as a third onboarding route.

## What gets collected

The hosted flow collects and checks identity documents, a selfie/liveness check, and the person's
address details, then returns a single approve/decline verdict. You never handle the documents —
they go straight to verification, and Venly's API only ever exposes the resulting
status.

Supply the party's `address` when you create it where you have it. It's used in verification and
in downstream bank-rail provisioning, which requires a legal name and address on the account holder.

## After the verdict

The verdict is asynchronous and flips `kycStatus` on the party, which in turn clears the account.

```mermaid theme={null}
stateDiagram-v2
    [*] --> VERIFICATION_PENDING: party created
    VERIFICATION_PENDING --> VERIFIED: approved
    VERIFICATION_PENDING --> REJECTED: declined
    VERIFIED --> [*]
```

[Register a webhook](/guides/finance/webhooks) to be told, rather than polling — KYC verdicts are
human-paced.

Once `VERIFIED`, the account still needs its wallet cleared before it can transact. See
[Wallet readiness](/guides/finance/kyc-verification#wallet-readiness-aml-and-permits-for-self-custody).

### If it's rejected

`REJECTED` is terminal for that verification attempt. The party stays in place, but its account can't
move money. Minting a new link for a rejected party is allowed — a `REJECTED` party is not
`VERIFIED`, so it doesn't hit the `party-already-verified` conflict. If a rejection looks wrong,
quote the party's `ivCaseReference` from
[Get verification linkage](/api-reference/Finance-API/parties/get-verification-linkage) to Venly
support; that reference survives a decline specifically so it can be investigated.

## Next steps

<CardGroup cols={2}>
  <Card title="Hosted verification link" icon="link" href="/guides/finance/onboarding/hosted-verification">
    The default route, step by step.
  </Card>

  <Card title="Business KYB" icon="building" href="/guides/finance/onboarding/business-kyb">
    The organisation equivalent.
  </Card>

  <Card title="Troubleshooting" icon="wrench" href="/guides/finance/onboarding/troubleshooting">
    Every verification error code.
  </Card>

  <Card title="Account verification" icon="id-card" href="/guides/finance/kyc-verification">
    How a verified party turns into an account that can transact.
  </Card>
</CardGroup>