KYC status and workflow

​

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.

​

Policy-facing review concepts

These policy-facing review concepts describe the onboarding journey. They are not current API enums, webhook values, or guaranteed transitions. 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

​

Verification timeline

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 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 for the current action loop.

​

Support

For KYC policy questions, contact compliance@swipelux.com. For API issues, contact support@swipelux.com.