Individual Accounts

Partner-owned individual accounts represent end-customers onboarded by a single partner. Each IndividualOnboarding record is the canonical customer record for a person — it bundles the client profile, the debit account, the addresses, and risk/compliance flags into one document tied to exactly one Partner via partnerId.

The data of an individual

An IndividualOnboarding record groups five categories of data:

Field group	Examples
Identity	firstName, lastName, email, phoneNumber, legalId, applicationId
Address	address.{street, buildingNumber, apartmentNumber, city, stateProvince, zipCode, country} (both residential and delivery)
Accounts	Underlying B2BAccount linking the individual to a settlement account, with IBAN and customerType
Compliance	applicationStatus, applicationDate, riskStatus, riskLevel, isPep, operationStatus, dashboardStatus
Orasys sync	orasysCustomer.{isCreated, requestId, errors, retryCount} — tracking the downstream Orasys account-creation flow

The clientCode (e.g. PNVS-0001) is the immutable identifier you use across every other endpoint — it's the canonical handle for the individual in IT-Card too.

Lifecycle states

Each IndividualOnboarding progresses through three stages. The state is split across two flags:

Stage	applicationStatus	operationStatus	Meaning
Draft	PENDING / SUBMITTED	Pending	Profile created, but the customer hasn't completed KYC / onboarding.
Active	APPROVED	Active	Customer is fully onboarded; cards can be issued against them.
Inactive	REJECTED	Inactive	Onboarding rejected (KYC failure, sanctions hit, etc.) or the customer churned. No new cards can be issued.

The dashboard-side state uses a parallel DashboardStatus flag (ACTIVE / INACTIVE / PENDING / REJECTED / APPROVED) that's visible to the partner on the CIP dashboard.

Risk & compliance

Every individual carries risk metadata:

• riskLevel — LOW / MEDIUM / HIGH / VERY HIGH (set by the KYC pipeline).
• riskStatus — current risk state.
• isPep — boolean flag for politically-exposed persons.
• hasAgreedToTerms, hasAgreedToTariffs, hasCompletedBiometrics — onboarding checkpoints.

High-risk individuals (HIGH / VERY HIGH) and isPep: true customers are blocked from card issuance by the partner-side validation.

Tenant scoping

Every route under /individual/accounts/:id/* runs through assertPartnerIndividualAccess, which:

1. Reads :id from the URL
2. Looks up the IndividualOnboarding record by _id
3. Verifies the record's partnerId matches req.auth.partnerId
4. Returns 403 Forbidden if the partner doesn't own the resource

If the record doesn't exist, returns 404 Not Found.

Lifecycle

State	Trigger
Draft	Account created via POST /individual/accounts (not yet active)
Active	Cards issued via /cards/virtual or /cards/physical
Closed	Account terminated by partner (not exposed in stage 1)

Stage 1 limitation

The PATCH /individual/accounts/:id endpoint is disabled in stage 1. Account updates must be coordinated through the CIP dashboard or a separate support workflow.

What you can do

The Individual Accounts area covers:

• Account onboarding — create a new individual account owned by your partner.
• Account lookup — list and fetch accounts by id.
• Card issuance — issue a virtual or physical card against an account.
• Account-scoped reads — audit logs, card status history, and transactions for an account.

For the exact endpoint shapes, parameters, and the Try it widget, see the List of endpoints → page.