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

# KYC status and workflow

> Separate KYC review concepts from current capability, application, task, and submission states.

## Verification status and workflow

The policy-facing KYC journey moves from information collection through review to an approval or rejection decision. Current API resources expose separate capability, application, task, and submission lifecycles.

<Warning>
  Policy review labels and timing estimates do not define API behavior. Do not
  implement a state machine from the labels below.
</Warning>

## Policy-facing review concepts

These policy-facing review concepts describe the onboarding journey. They are not current API enums, webhook values, or guaranteed transitions.

| Policy label           | Meaning                                                      |
| ---------------------- | ------------------------------------------------------------ |
| `not_started`          | The customer exists, but KYC work has not started            |
| `incomplete`           | KYC work started, but required information is missing        |
| `pending_verification` | The review is waiting for customer completion                |
| `under_review`         | Submitted information or documents are under review          |
| `approved`             | The policy review approved the customer for applicable flows |
| `rejected`             | The policy review rejected the customer                      |

Use these labels only when discussing the policy journey. Do not send them as current status values unless a current generated schema explicitly asks for the same value in its own context.

## Standard KYC review flow

1. Create the individual customer.
2. Discover and request an eligible capability.
3. Read the current task detail.
4. Send the customer to a first-party hosted verification session or submit the complete task answers requested by the task.
5. Let the review run while current resources report their own review states.
6. Refetch the current resources to determine whether more action is required or the capability is ready, restricted, rejected, or canceled.

The policy journey can describe this as not started, pending verification, under review, and then approved or rejected. Those terms do not define the API transition sequence.

## Enhanced KYC review flow

1. Complete the currently requested standard identity and liveness work.
2. Read the latest task when enhanced review requests additional information.
3. Provide requested proof of address, proof of funds, or other evidence through the current hosted session or task submission.
4. Upload documents only when the current task asks for them.
5. Continue monitoring current resources during manual review.
6. Stop or continue based on the current capability, application, task, and submission states.

The compliance team may also coordinate an enhanced review through the customer's registered email address.

## Common rejection reasons

| Reason                 | Resolution                                                       |
| ---------------------- | ---------------------------------------------------------------- |
| Document not readable  | Provide a clear, high-resolution image                           |
| Document expired       | Provide a valid, non-expired identity document                   |
| Face not matching      | Make sure the selfie clearly matches the identity-document photo |
| Incomplete information | Provide every item requested by the current task                 |
| Suspicious activity    | Contact support for manual review                                |

## Verification timeline

| Stage            | Typical duration  |
| ---------------- | ----------------- |
| Document upload  | Immediate         |
| Automated checks | 1-3 minutes       |
| Standard review  | 1-24 hours        |
| Enhanced review  | 1-3 business days |

These durations are typical policy estimates, not guaranteed API behavior.

## Current API state vocabularies

The current resources use separate closed vocabularies:

* **Capability status:** `pending`, `ready`, `restricted`, `rejected`, `canceled`
* **Application status:** `requested`, `in_review`, `action_required`, `ready`, `rejected`, `disabled`, `canceled`
* **Task status:** `action_required`, `in_review`, `satisfied`, `rejected`, `canceled`
* **Submission outcome:** `in_review`, `accepted`, `changes_requested`, `rejected`

Do not collapse these vocabularies into one verification status.

## Events and current state

Use currently documented [Webhooks](/integration/webhooks) as change notifications, then refetch the current customer, capability, application, and task resources. Events do not replace authoritative resource reads, and no policy-facing label implies a particular event.

See [Capabilities and tasks](/integration/onboarding/capabilities-and-requirements#complete-current-tasks) for the current action loop.

## Support

For KYC policy questions, contact [compliance@swipelux.com](mailto:compliance@swipelux.com). For API issues, contact [support@swipelux.com](mailto:support@swipelux.com).


## Related topics

- [Individual onboarding API workflow](/knowledge-base/individual-onboarding/api-workflow.md)
- [KYB workflow](/knowledge-base/business-onboarding/kyb-workflow.md)
- [Overview](/knowledge-base/compliance/overview.md)
- [Governance and Roles](/knowledge-base/compliance/governance-retention-and-privacy.md)
- [KYC verification levels](/knowledge-base/individual-onboarding/verification-levels.md)