> ## 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. # Roles & entities > Company, party, account, wallet, and role — which object holds identity, and which one gates money. Four objects, and it matters which one you're asking about. Verification lives on the **party**. The gate on money movement lives on the **account**. Permission to receive a pay-out lives on the **role**. ```mermaid theme={null} flowchart TD C["Company (your tenant)
provisioned by Venly"] --> P1["Party · INDIVIDUAL
kycStatus"] C --> P2["Party · ORGANISATION
kybStatus"] P1 -->|"role: ACCOUNT_HOLDER"| A["Account
kycStatus gates money"] P2 -->|"role: PAYOUT_RECIPIENT"| A A --> W["Wallet · per chain
amlStatus"] ``` ## Company (tenant) You. Created and configured by Venly, not through the API. Your company carries the settings that silently decide what the rest of the API will let you do: | Setting | Why you care | | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Wallet type — `VENLY_MANAGED` or `SELF_CUSTODY` | Decides whether Venly generates wallets or you supply addresses, and whether [Sumsub token sharing](/guides/finance/onboarding/sumsub-token-sharing) is available at all. See [Venly-managed vs self-custody](/guides/finance/managed-vs-self-custody). | | Supported chains | Creating an account on a chain you're not configured for fails, even if the API accepts the enum value. | | Supported assets | Constrains `targetCryptocurrency` and pay-in/pay-out asset choices. | | Verification tenant provisioned | Without it, every verification call returns `verification-not-provisioned`. | | Tenant-managed KYC enabled | Whether you may declare `kycStatus: NOT_REQUIRED`. Enabled by a **Venly admin** per tenant; granted for testing rather than production use. | | Deposit settlement | Whether a customer-signed [wallet-ownership proof](/guides/finance/virtual-bank-accounts#proving-wallet-ownership) is required before a virtual bank account can be created. Call `prepare` to find out at runtime. | Most "why does this work in the docs but not for me" moments trace back to this table. None of it is visible in the API responses, so if a call fails on configuration grounds, check with Venly rather than reworking your request. ## Party The legal identity behind an account — a natural person or a business. **This is the only object that gets identity-verified.** | `partyType` | Required fields | Verification field | States | | -------------- | ------------------------------- | ------------------ | ------------------------------------------------- | | `INDIVIDUAL` | `firstName`, `lastName` | `kycStatus` | `VERIFICATION_PENDING → VERIFIED` (or `REJECTED`) | | `ORGANISATION` | `name` (optionally `vatNumber`) | `kybStatus` | `PENDING → VERIFIED` (or `DENIED`) | A party's own `status` is separate and unrelated to verification: | `status` | Meaning | | ----------- | ---------------------------------------------------------------------------------- | | `ACTIVE` | The record is usable. **Set immediately on creation — not a verification signal.** | | `SUSPENDED` | Temporarily unusable. | | `BLOCKED` | Permanently unusable. | Parties are created independently of accounts and can be reused: one party can hold roles on several accounts. See [Individual KYC](/guides/finance/onboarding/individual-kyc) and [Business KYB](/guides/finance/onboarding/business-kyb). ## Account The money container. It holds wallets, virtual bank accounts, and pay-out routes. An account carries its **own** `kycStatus`, and **this is the field every money-movement endpoint checks**: | `kycStatus` | Money movement | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | `VERIFICATION_PENDING` | Blocked | | `VERIFIED` | Allowed | | `REJECTED` | Blocked | | `NOT_REQUIRED` | Allowed — you verify end-users yourself. Needs an admin-enabled tenant flag ([tenant-managed KYC](/guides/finance/kyc-verification#tenant-managed-kyc)) | Don't read the party's `kycStatus` to decide whether you can transfer. Read the **account's**. They're related but they are different fields on different objects, and only one of them is the gate. An account needs exactly one active account-holder party. If it resolves to zero or several, provisioning calls fail with `account-holder-unresolved`. ## Party role The link between a party and an account, and what that party is allowed to do there. | `roleType` | Meaning | | ------------------ | ---------------------------------------------------------------------------------------- | | `ACCOUNT_HOLDER` | The party owns or co-owns the account. Multiple holders enable joint accounts. | | `PAYOUT_RECIPIENT` | The party is an allowed [pay-out](/guides/finance/payouts) destination for this account. | Each role has a `status` of `ACTIVE` or `INACTIVE`. ### The recipient gate `PAYOUT_RECIPIENT` is the one role with teeth beyond bookkeeping. Before you can create a [pay-out route](/api-reference/Finance-API/payout-routes/create-a-payout-route) for a bank account, its owning party needs an `ACTIVE` `PAYOUT_RECIPIENT` role on the paying account **with cleared KYC/KYB**. It's re-checked on every pay-out request, not just at route creation — so setting the role to `INACTIVE` stops future pay-outs immediately. A party can hold `PAYOUT_RECIPIENT` **and** `ACCOUNT_HOLDER` on the same account. That's the self-payout case: a user withdrawing to their own bank account. Manage roles with [Add a party to an account](/api-reference/Finance-API/accounts/add-a-party-to-an-account) and [Remove a party](/api-reference/Finance-API/accounts/remove-a-party-from-an-account). ## Wallet Where crypto actually sits, one per chain per account. Wallets aren't identity-verified, but they are **screened**, and screening is its own gate: | `amlStatus` | Money movement | | ----------- | ------------------------------- | | `PENDING` | Blocked — screening in progress | | `APPROVED` | Allowed | | `FLAGGED` | Blocked — needs manual review | | `BLOCKED` | Blocked | A wallet has **no `status` field**. For self-custody, readiness also requires a `CONFIRMED` [permit](/guides/finance/permits-and-allowances). See [Wallets & balances](/guides/finance/wallets). ## Quick reference | Question | Read | | -------------------------------------- | ----------------------------------------------------------------------------------- | | Has this person passed KYC? | Party `kycStatus` | | Has this business passed KYB? | Party `kybStatus` | | Can this account move money? | **Account `kycStatus`** | | Is the wallet cleared? | Wallet `amlStatus` (+ permit for self-custody) | | Can this party receive a pay-out here? | `PAYOUT_RECIPIENT` role `status` + the party's KYC/KYB | | Where is the verification case? | [Verification linkage](/api-reference/Finance-API/parties/get-verification-linkage) | ## Next steps How these objects move from created to able-to-transact. The full resource graph.