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

# Business KYB

> Verifying a company — the states, why the status values differ from KYC, and the one route available.

**KYB** (Know Your Business) verifies a company or business rather than a person. It applies to
parties with `partyType: ORGANISATION` and is tracked on `kybStatus` — a **different field with
different values** from KYC.

## States

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

| `kybStatus` | Meaning                                          |
| ----------- | ------------------------------------------------ |
| `PENDING`   | Created, awaiting a verdict. The starting state. |
| `VERIFIED`  | Approved.                                        |
| `DENIED`    | Declined.                                        |

<Warning>
  KYB does not reuse the KYC values. The pending state is `PENDING`, not `VERIFICATION_PENDING`, and the
  failure state is `DENIED`, not `REJECTED`. Only `VERIFIED` is shared.

  If you branch on verification status, read the field that matches the party's type — a check written
  against `VERIFICATION_PENDING` silently never matches an organisation.
</Warning>

| Party type     | Field       | Pending                | Approved   | Declined   |
| -------------- | ----------- | ---------------------- | ---------- | ---------- |
| `INDIVIDUAL`   | `kycStatus` | `VERIFICATION_PENDING` | `VERIFIED` | `REJECTED` |
| `ORGANISATION` | `kybStatus` | `PENDING`              | `VERIFIED` | `DENIED`   |

## 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": "ORGANISATION",
    "name": "Acme Trading BV",
    "vatNumber": "NL123456789B01",
    "externalId": "org-4471",
    "address": {
      "addressLine1": "123 Main Street",
      "city": "Amsterdam",
      "postalCode": "1012AB",
      "country": "NL"
    }
  }'
```

`name` is required for organisations — and it must be the **legal** entity name, not a trading or
display name, because it's what gets checked against registry records and what appears as the
beneficiary name on bank rails. `vatNumber` is optional but speeds verification along where you have it.

`firstName` and `lastName` don't apply to organisations.

<Note>
  Downstream bank-account provisioning requires the account holder to have a legal name. An
  organisation party with no `name` fails virtual-bank-account creation with `party-name-required`.
</Note>

## One route: hosted verification

Organisations verify through the [hosted verification link](/guides/finance/onboarding/hosted-verification).
[`POST /parties/{partyId}/verification`](/api-reference/Finance-API/parties/create-a-verification-link)
returns the **KYB** flow URL automatically — the party's stored `partyType` decides which flow you get,
so there is no parameter to set.

<Warning>
  **[Sumsub token sharing](/guides/finance/onboarding/sumsub-token-sharing) is not available for
  organisations.** It's KYC-only. Supplying `party.sumsubToken` with `partyType: ORGANISATION` is
  rejected with `400 verification-kyc-only`.
</Warning>

## What gets collected

KYB verifies the business itself — registry existence, incorporation details, ownership structure —
and typically also identifies its representatives and beneficial owners. That makes it a heavier
process than individual KYC, and usually a slower one.

Practically: expect KYB to sit in `PENDING` longer than KYC sits in `VERIFICATION_PENDING`, and don't
build UI that treats a multi-day pending state as an error.

## After the verdict

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

The verdict flips `kybStatus` on the party and clears the account's `kycStatus` for money movement.
Note that the *account* field is called `kycStatus` regardless of whether its holder is an individual
or an organisation — there is no `kybStatus` on an account.

[Register a webhook](/guides/finance/webhooks) rather than polling for days.

### If it's denied

`DENIED` is terminal for that attempt. You can mint a fresh link — a `DENIED` party isn't `VERIFIED`,
so it won't hit `party-already-verified`. For a disputed decision, quote the party's `ivCaseReference`
from [Get verification linkage](/api-reference/Finance-API/parties/get-verification-linkage) to Venly
support.

## Organisations as pay-out recipients

A verified organisation is often the beneficiary of a [pay-out](/guides/finance/payouts) rather than
the account holder. That needs a cleared `kybStatus` **and** an `ACTIVE` `PAYOUT_RECIPIENT` role on
the paying account — see [the recipient gate](/guides/finance/onboarding/roles-and-entities#the-recipient-gate).
A cleared KYB alone is not enough; a missing role surfaces as `422 recipient-not-authorized`.

## Next steps

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

  <Card title="Individual KYC" icon="user" href="/guides/finance/onboarding/individual-kyc">
    The natural-person equivalent.
  </Card>

  <Card title="Roles & entities" icon="sitemap" href="/guides/finance/onboarding/roles-and-entities">
    How an organisation party relates to accounts and pay-outs.
  </Card>

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