​
Turnaround response time

The average decision time for KYC is typically less than one minute. If a manual review is required for KYC, the decision may take until next business day.

​
User Status Transitions

All KYC flows for individual users begin with users created with basic information. If the provided information is sufficient, they can move directly to active, rejected, or under_review. If something is missing or more information is needed, they move to incomplete status.

​
User Journey Scenarios

While KYC generally works quickly, there are different paths users can take through the verification process. Understanding these scenarios helps you build better user experiences and handle edge cases appropriately.

Happy Path - Instant Approval

​
Under Review

In this scenario, the user has provided all required information and documents, but automated verification checks have flagged something that requires human review. This could be due to document quality issues, name variations, or other factors that need manual verification. In this scenario, fetching the user via Get User Details would result in something like this: 
{
  "id": "user_john_uuid",
  // ...
  "status": "under_review",
  "created_at": "Thu, 04 May 2023 15:40:40.832827000 UTC +00:00",
  "updated_at": "Thu, 04 May 2023 15:40:40.832827000 UTC +00:00"
}
You can see that the user’s KYC status is under_review. This means all required information has been submitted, but a human reviewer needs to manually verify the details. No additional action is required from the user at this point. After the manual review is complete, one of two things will happen:
  • Carbn will approve your user, and the KYC status on the user will move to active
  • Carbn will reject your user, and the KYC status on the user will move to rejected.

​
Incomplete Status

When a user is in incomplete status, it means required information or documents are missing. You can check what’s needed by examining the requirements_due field in the user object: 
{
  "id": "user_jane_uuid",
  "status": "incomplete",
  "requirements_due": [
    "proof_of_address",
    "tax_document"
  ],
  "created_at": "Thu, 04 May 2023 15:40:40.832827000 UTC +00:00",
  "updated_at": "Thu, 04 May 2023 15:40:40.832827000 UTC +00:00"
}
The requirements_due array tells you exactly what documents or information need to be provided. Common requirements include:
  • id_verification - Government-issued photo ID
  • proof_of_address - Utility bill, bank statement, or government document
  • tax_document - Tax identification document specific to the user’s country
  • source_of_funds - Documentation proving origin of funds (for Enhanced Due Diligence)
To resolve incomplete status, submit the required documents through the appropriate API endpoints. Once all requirements are satisfied, the user will move to active, rejected, or under_review status.

​
Immediate Rejection

Sometimes, your user could immediately move from created to rejected and skip under_review entirely. The primary reason this happens is when the tax identification number is entered incorrectly. Without a valid tax identification number, Carbn is unable to verify any of the other details you have sent up for your user (birth date, address, name). In this scenario, the user starts off created with basic information, but after attempting to verify submitted information, there was an issue detected with the submission. It is possible to move directly to rejected and skip under_review entirely. In the rejected scenario, fetching the user would result in something like this: 
{
  "id": "user_123",
  "first_name": "John",
  "last_name": "Doe",
  "email": "johndoe@johndoe.com",
  "type": "individual",
  "status": "rejected",
  "rejection_reasons": [
    {
      "developer_reason": "Missing required ID details.",
      "reason": "Cannot validate ID -- upload a clear photo of the full ID",
      "created_at": "2020-01-02T00:00:00.000Z"
    },
    {
      "developer_reason": "Blurry face portrait.",
      "reason": "Cannot validate ID -- upload a clear photo of the full ID",
      "created_at": "2020-01-02T00:00:00.000Z"
    }
  ],
  "user_id": "user_123"
}
You can see that the user’s KYC status is rejected and that there are two fields shared with rejection reasons:
  • developer_reason is meant to be used by developers for internal purposes only. This field can contain sensitive information intended for only the developer and is provided to help with troubleshooting potential issues or protecting against potential abuse.
  • reason can be shared by a developer directly with their users.
For reference, see our page on Rejection Reasons for developer_reason and reason mappings for KYC rejection reasons.