> ## 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.
# Compliance and the KYC flow
> The material the KYC flow needs, the markets cards can be issued in and the per-region document requirements; statuses and error codes are covered in the related guides.
## ๐ Guide
Whether you are an exchange, a wallet or a platform, you can hand cardholder identity verification to DCS โ we offer both a direct API integration and a hosted (H5) self-service flow, so you can choose how deep to integrate without handling document retention, liveness detection or anti-money-laundering screening yourself. As a card issuer regulated by the Monetary Authority of Singapore (MAS), DCS verifies every user's proof of identity (POI) and proof of address (POA) and runs a risk assessment against anti-money-laundering (AML) rules. Only users who have passed KYC can apply for and use a virtual card.
***
## Compliance: supported markets and document requirements
Before issuing a card to an end user, settle two compliance facts with DCS first: whether cards can be issued in that user's region, and which documents they need to prepare. Both are decided by your agreement with DCS together with the user's region.
## What KYC consists of
DCS compliance requires four categories of material from each user:
1. **POI (proof of identity)** โ establishes *who this person is*
2. **POA (proof of address)** โ establishes *where this person lives*
3. **Liveness (face verification)** โ establishes *that this is a real person, acting for themselves*
4. **Background information** (employment status, source of funds, account purpose and so on) โ feeds the anti-money-laundering risk assessment
## KYC documents (POI and POA)
DCS whitelists the documents of certain countries and regions so that one document serves as both proof of identity (POI) and proof of address (POA) โ a user whose document is whitelisted submits that single document plus a face check and background information, with no separate proof of address. If the identity document carries no address, the user must supply a POA as well. For the image requirements, see [KYC document requirements](../customer-success/faq-kyc-documents).
## Cardholder eligibility
* **Age**: between 18 and 70
* **Tax status**: not a US resident and not a US tax resident
* **Residence**: only regions covered by your agreement with DCS can be issued cards
## Background information
AML rules require the user to submit the relevant information. For the complete enumerations, see [KYC application parameter dictionary](../how-to-use/kyc/kyc-application-fields).
| Item | Description / options |
| ---------------------------------------- | -------------------------------------------------------------------------- |
| Employment status | Employed / business owner / self-employed / unemployed / retired / student |
| Industry, occupation, seniority | See the parameter dictionary |
| Account purpose | Everyday spending / investment / bill payment and so on |
| Source of funds, source-of-funds country | Own bank account / third-party account / crypto top-up and so on |
| Source of wealth | Employment income / savings / inheritance / business income and so on |
***
## Mental model: one application, one ticket, one status line
In the Partner-Managed model, KYC is carried by a **KYC ticket**: a user (`customerId`) starts KYC once, which creates a single ticket (`kycTicketId`), and from then on every status change and every result lookup happens against that ticket.
Ticket status changes are pushed to the partner through the `KYC_TICKET` webhook, and you can also pull the current status through the query API at any time.
> **Who does what**: DCS receives and securely stores the documents, verifies their authenticity, runs AML screening, performs manual review where needed, and advances and notifies the status. The partner starts the application, guides the user through the steps that need the user's own participation (such as face verification), and moves on to card issuing based on the result.
***
## The KYC flow: two ways to integrate
Pick one based on how deeply you want to integrate. Both converge on the same end state: ticket `PASSED`, then apply for a virtual card.
* **API mode** โ Create the user โ call `apply-kyc` to get a `kycTicketId` โ receive the result through the `KYC_TICKET` webhook or the query API. The user may be asked to complete face verification along the way. For execution details such as status values, face verification guidance, resubmission and reject codes, see [How-to ยท Apply for KYC](../how-to-use/kyc/apply-kyc) and [KYC reject codes](../how-to-use/kyc/kyc-reject-codes).
* **H5 hosted mode** โ Create the user โ call `apply-kyc-h5` โ exchange the guidance link for an H5 URL and send it to the user. Document capture, liveness check and background information are all completed on the DCS-hosted page. For the step-by-step flow and idempotency behavior, see [How-to ยท Apply for KYC (H5 mode)](../how-to-use/kyc/h5-kyc-guidance).
> Tickets in both modes are keyed by `kycTicketId` and share the same query API and the same webhook. The only difference is who captures the documents. For the exact status values and reject codes, follow the links above to the matching How-to page.
***
## Sumsub token integration (data provider)
* **You are the data provider**: obtain the UAT and PROD tokens from DCS and add them in the Sumsub console; your registered Sumsub name is visible in the DCS Sumsub console.
For more on Sumsub and KYC vendor integration, see [KYC vendor](../customer-success/faq-kyc-vendor); Sumsub's own documentation is at [Manage sharing partners](https://docs.sumsub.com/docs/manage-sharing-partners).
***
## Next steps
Once KYC is `PASSED`, you can apply for a virtual card for that user. Continue with [How-to ยท Apply for a virtual card](../how-to-use/cards/virtual-card).