Individual onboarding

The end-to-end journey for an INDIVIDUAL applicant — one person onboarding for themselves. A caller starts the onboarding with a single request and then polls its status; Ark runs the whole journey in the background.

The request body is StartIndividualOnboardingRequest:

Field	What it carries
party	The applicant (entityType: INDIVIDUAL): identity details, phones, emails, and at least one address.
documents	Identity documents to submit for verification (e.g. driver's licence, passport).
productKey	The account product to open.
productVersion	Version of that product.
cardType	Card to issue (PHYSICAL, VIRTUAL, or PHYSICAL_AND_VIRTUAL).
riskScoringContext	Optional applicant-disclosed facts the risk rule can't derive from party (e.g. PEP, source of wealth).

For how the three onboarding flows compare, see the onboarding overview.

States

The onboarding reports a high-level status plus a granular currentStep at every point.

Status	Meaning
INITIATED	Accepted by the API; not yet executing. This is the status returned by the start call.
IN_PROGRESS	Steps are executing (address validation, risk assessment, provisioning).
PENDING_ACTION	Waiting on identity verification — in particular a manual review, which can take up to ~3 days.
COMPLETED	Terminal success — the party, account, and card have been provisioned.
FAILED	Terminal failure — a step failed, identity was not verified, or the risk assessment was not LOW. The reason is on the state's errors.

The journey

1. Validate the address. The applicant's free-text addresses[0].addressLine is resolved to a canonical delivery-point address in two calls: a PAF autocomplete lookup picks the best-match address id, then a metadata call resolves that id to the full canonical record (dpid, street, locality, postcode, state). This canonical address — not the caller's raw text — is what Ark uses for the rest of the journey. Any dpid the caller supplied is ignored and re-derived here, so an inconsistent text/dpid pair can never reach the downstream connectors.
2. Verify identity (KYX). Ark creates the applicant's verification record and party shell with the identity vendor (GreenID for individuals), receiving a verification id. Each item in documents is then uploaded against that id. The onboarding moves to PENDING_ACTION and a polling loop watches the verification:
   • Clean applicants pass within minutes.
   • Others enter a manual review and the onboarding stays PENDING_ACTION until the verification reaches a terminal outcome or the review window elapses. The loop polls every minute for the first 10 minutes, then hourly, with a hard cap of 3 days.
   • On VERIFIED the onboarding returns to IN_PROGRESS. Any other outcome — DECLINED, ERRORED, or a 3-day TIMEOUT — ends the onboarding as FAILED.
3. Assess risk. A business-rules risk assessment runs against the applicant's facts — what Ark can derive from party (citizenship, postcode, legal structure) merged with any disclosed riskScoringContext. The rule key is risk-scoring-individual. Only a LOW result proceeds; a MEDIUM, HIGH, or unrecognised result ends the onboarding as FAILED and routes the applicant to manual review. Risk runs before provisioning, so a non-low outcome never leaves a half-provisioned party.
4. Provision party + account + card. For low-risk, verified applicants, Ark provisions, in order, the party, the account (per productKey / productVersion), and the card (per cardType) in core banking (UDA). The party becomes active in core banking at this step. Once the card is created the onboarding reaches COMPLETED.

Result

On success the workflowType on the response is individual. The created partyId, accountId, cardId, and their core-system references are carried on the provisioning step's result (the provisioning entry in the state's results).