> ## Documentation Index > Fetch the complete documentation index at: https://docs.carbn.xyz/llms.txt > Use this file to discover all available pages before exploring further. # User Onboarding Status > User onboarding status and how to handle them ## 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. ``` created → active ``` **What happens**: User provides complete, accurate information that passes all automated verification checks immediately. **Timeline**: Typically under 1 minute **User experience**: Seamless onboarding with immediate access ``` created → incomplete → active ``` **What happens**: User's basic information is valid, but additional documents are needed (e.g., proof of address, tax documents). **Timeline**: Depends on how quickly user provides missing documents **User experience**: Clear guidance on what's needed, easy document upload process ``` created → under_review → active created → under_review → rejected ``` **What happens**: Automated checks flag something that requires human review (e.g., document quality issues, name variations). **Timeline**: Up to next business day **User experience**: "Under review" messaging with expected timeline ``` created → rejected ``` **What happens**: Critical information is incorrect or invalid (e.g., wrong tax ID format, prohibited jurisdiction). **Timeline**: Immediate **User experience**: Clear error messages with specific guidance on what went wrong ``` created → incomplete → under_review → active created → under_review → incomplete → active ``` **What happens**: Multiple verification steps are needed, or additional documents are requested during manual review. **Timeline**: Varies based on user responsiveness and review complexity **User experience**: Step-by-step progress tracking with clear next actions ### 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](/api-reference/user-management/get-user-details) would result in something like this: ```json theme={null} { "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: ```json theme={null} { "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: ```json theme={null} { "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](/documentation/developer-platform/users/compliance/rejection-reasons) for `developer_reason` and `reason` mappings for KYC rejection reasons.