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

# KYC Rejections and Resubmissions

> When a KYC application does not pass, this page helps you tell two kinds of rejection apart from the API response: a fixable rejection (the problem can be corrected, and the application is re-reviewed once the documents are re-uploaded) and a REFUSE decision (the review has concluded and the application was not approved). Each has its own handling path. This page covers only the rejection branch.

## 📄 Guide

A KYC status in the DeCard-Managed model consists of a top-level `status` plus a `statusDescription` text, and resubmission is signalled in a machine-readable way through `needExtraInfo` (boolean): `true` = prompt the user to supply more information, `false` = the user has already submitted, so do not prompt again. The "fixable vs. `REFUSE`" split below is a business-process distinction, derived from `needExtraInfo`, the review outcome, and `statusDescription` together. Once you understand this fork, you can guide users correctly: a case that only needs a re-upload is not treated as unrecoverable, and a case already in `REFUSE` is not pushed through repeated submissions.

### Terminology (REFUSE / REJECTED)

Different layers of the same system use different English variants, so here is the clarification:

| Where it appears                                      | English                                    | Description                                                                                                                                                                                                                          |
| ----------------------------------------------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Top-level `status` enum value in the API response** | `REFUSE`                                   | Code literal, uppercase; the top-level status for a KYC review that was not approved (alongside `UNDO` / `INIT` / `PENDING` / `PASS`)                                                                                                |
| **`statusDescription` sub-status value**              | `POA_REJECTED` / `POI_REJECTED`            | Code literal, uppercase; appears only under `status=INIT`, meaning proof of address / proof of identity was not accepted (the application is still in progress under `INIT` and is fixable, so this is **not** a top-level `REFUSE`) |
| **Narrative wording on this page**                    | "rejected", "not accepted", "not approved" | Plain-language wording; uppercase English is used only when quoting code enums                                                                                                                                                       |

> Always rely on the literal values actually returned in the API response fields.

***

## 1. Fixable Rejection (Temporary / Fixable)

When the KYC review finds a **correctable** problem (expired document, blurred photo, address mismatch, missing page, and so on), DCS does not immediately reach a `REFUSE` decision. Instead, it reports a specific sub-status through `statusDescription` while `status` stays at `INIT`. The user **does not have to redo the whole KYC flow** and only needs to re-upload the document concerned.

### Signals to check

| Signal                             | Source                             | Meaning                                                                                                                                                          |
| ---------------------------------- | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `status = INIT`                    | KYC top-level status               | The user's KYC is still in progress and has not reached `PENDING` (submission complete) or `REFUSE` (review concluded)                                           |
| `statusDescription = POA_REJECTED` | KYC sub-status                     | Proof of address (POA) was not accepted; address documents must be re-uploaded                                                                                   |
| `statusDescription = POI_REJECTED` | KYC sub-status                     | Proof of identity (POI) was not accepted; identity documents must be re-uploaded                                                                                 |
| `needExtraInfo = true`             | Card application / query responses | **Native machine-readable resubmission signal of the DeCard-Managed model**: the user has not submitted the additional information yet, so prompt them to upload |
| `needExtraInfo = false`            | Card application / query responses | The user has already submitted; even if `status` is still `PENDING`, simply wait for the review and **do not prompt again**                                      |

> `needExtraInfo` is the most direct machine-readable field for driving the resubmission flow; it answers "is anything still needed from the user?". The breakdown of what was rejected comes from `status` plus the `statusDescription` text.

### Resubmission steps

1. **You do not need a new Sumsub share token.** When POA/POI is not accepted, the original application context still applies (the original `sumsubShareToken` remains valid), so you can send the user straight to re-upload **without issuing a new token**. This differs from starting a brand-new KYC application.

2. **Guide the user to resubmit**: generate a resubmission link through the H5 guidance-page endpoint and bring the user back to the upload page:

   ```
   POST /redirect/v2/guidance-link
   ```

   Set `action` to:

   | `action`        | Meaning                                                                                                                            |
   | --------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
   | `KYC_EXTRA_DOC` | KYC additional information (re-upload a missing or unacceptable document). **`applyId` is conditionally required for this action** |

   <Warning>
     **`applyId` is conditionally required**: when `action = KYC_EXTRA_DOC`, the guidance-link request **must carry `applyId`**, and omitting it makes the call fail. For the remaining guidance-page parameters (language / theme / mode / redirect URLs, and so on), see [H5 KYC and Card Application Guidance Page](../integration-resources/h5-kyc-guidance).
   </Warning>

3. **Once the user has re-uploaded**, the application goes back into review (`status` returns to the in-progress description of `PENDING` / `INIT`). You can keep polling or wait for the webhook carrying the final outcome.

4. **For acceptable POA/POI document types** and which countries require additional POA, see [KYC Documents](./kyc-documents).

<Frame>
  <img className="block dark:hidden" src="https://mintcdn.com/dcs-0bf7a937/oUoeUKtwWWK2o-Li/imgs/en/diagrams/va-kyc-resubmit-light.svg?fit=max&auto=format&n=oUoeUKtwWWK2o-Li&q=85&s=1f2815d7e874a18bff6b28c11e5e7b1b" alt="Resubmitting documents after a KYC rejection" width="619" height="444" data-path="imgs/en/diagrams/va-kyc-resubmit-light.svg" />

  <img className="hidden dark:block" src="https://mintcdn.com/dcs-0bf7a937/oUoeUKtwWWK2o-Li/imgs/en/diagrams/va-kyc-resubmit-dark.svg?fit=max&auto=format&n=oUoeUKtwWWK2o-Li&q=85&s=bfe03af2f4c133735e324673d0bd7acf" alt="Resubmitting documents after a KYC rejection" width="619" height="444" data-path="imgs/en/diagrams/va-kyc-resubmit-dark.svg" />
</Frame>

> **How Sumsub tokens relate to the rejection flow**: configuring the token sharing mechanism (data provider / data recipient) is a one-off integration task. Once it is set up **before go-live**, **nothing needs to be reconfigured** during a rejection and resubmission cycle. For the steps, see [Sumsub Token Sharing](./kyc-vendor).

***

## 2. Not Approved (Final / `REFUSE`)

When `status` is **`REFUSE`**, the KYC review **was not approved**: the information the user submitted does not meet the requirements or failed verification. This decision is normally made by the Operations team during manual review, for business reasons such as an AML hit, a sanctions list match, a restricted regulatory jurisdiction, or identity fraud.

For `REFUSE`:

* Unlike a fixable rejection (`statusDescription = POA_REJECTED / POI_REJECTED`, which is still in progress under `INIT`), `REFUSE` is a not-approved decision at the **KYC top-level status**, so you should generally not keep pushing the user through the resubmission flow to re-upload documents.
* Whether and how to show the rejection reason to the end user must follow the customer-facing wording you agreed with DCS (some reasons cannot be disclosed externally for compliance reasons).
* If you disagree with the decision, use the manual appeal and support escalation path described in [Escalations and Support Paths](./escalations-and-support-paths).

> `REFUSE` is the terminal state of that KYC application, and the same application cannot be continued with additional documents. Business rules allow a brand-new application to be started, but the system caps submissions at 10 per 24 hours (the limit is configurable). Once the cap is reached, wait for the window to reset instead of retrying in a loop.

***

## Next steps

* Country-by-country allow lists for proof of identity (POI) and proof of address (POA): [KYC Documents](./kyc-documents)
* The two integration directions for Sumsub token sharing and how to configure them: [Sumsub Token Sharing](./kyc-vendor)
* Complete parameter reference for the resubmission guidance page (guidance-link): [H5 KYC and Card Application Guidance Page](../integration-resources/h5-kyc-guidance)
* The appeal path when you disagree with a KYC rejection: [Escalations and Support Paths](./escalations-and-support-paths)