> ## 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 sub-pages. ## ๐Ÿ“„ Guide As a card issuer regulated by the Monetary Authority of Singapore (MAS) with its own BIN, DCS has full KYC/AML and Travel Rule capability built in โ€” an end user must pass KYC before a card can be issued, topped up or spent, and cross-border fund movements must additionally satisfy the Travel Rule. We offer both a direct API integration and a hosted (H5) self-service flow, so you can choose how deep to integrate. In DeCard-managed mode the **review decision happens inside DCS** (automated review plus manual review where needed), so you never handle document retention, liveness detection or anti-money-laundering screening yourself. *** ## 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/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 [card application parameter dictionary](../how-to-use/managing-cards/application-data-dictionary). | 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 status line A user (`externalUserId`) submits KYC once. DCS runs the automated review internally (roughly 3 minutes) plus manual review where needed, and the outcome always resolves to a single top-level `status` (five values in total). Within `PENDING`, the case may move from automated to manual review; that transition is expressed by the sub-status `statusDescription` rather than by two separate top-level states. | Status | Meaning | | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `UNDO` | No KYC attempted; the user has not submitted any KYC material or application | | `INIT` | Initial / in progress โ€” the user has entered the KYC flow; the exact stage is broken out by `statusDescription` (material / POA / POI under review or rejected) | | `PENDING` | Application submitted successfully and under review (awaiting automated review, or awaiting manual review) | | `PASS` | KYC approved; the user is compliance-cleared | | `REFUSE` | KYC not approved; the material does not meet requirements or failed verification | > For how to tell "rejected but resubmission is possible" apart from "not approved", see [KYC rejections and resubmission](../customer-success/kyc-rejections). The overall lifecycle of a user's KYC and compliance status: The overall KYC and compliance lifecycle The overall KYC and compliance lifecycle > **Who does what**: DCS receives and securely stores documents, runs automated and manual review, performs AML screening, advances the status, and notifies you. The partner initiates the application, guides the user through the steps that need user participation (face verification, resubmission), and drives card issuing based on the outcome. > Besides the API, DCS also offers a hosted H5 guidance page, where the user completes KYC (identity verification, face verification, resubmission) directly on a DCS-hosted page, so you do not need to build a KYC front end. See [H5 KYC / card application guidance page](../integration-resources/h5-kyc-guidance). *** ## Travel Rule: a separate gate beyond KYC The Travel Rule is a compliance gate separate from KYC: before a user can obtain an on-chain deposit address, they must first upload their Travel Rule information (identity, address and, where required, source of funds or wealth). See [Travel Rule](../how-to-use/virtual-accounts/travel-rule). *** ## 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 [Sumsub KYC data sharing](../customer-success/kyc-vendor); Sumsub's own documentation is at [Manage sharing partners](https://docs.sumsub.com/docs/manage-sharing-partners). *** ## Next steps Once KYC is approved (`PASS`), you can apply for a virtual card for the user โ€” continue with [How-to ยท Issuing cards](../how-to-use/managing-cards/issuing-cards). If users are to top up themselves, complete [Travel Rule](../how-to-use/virtual-accounts/travel-rule) first. > The other two pages in this Basic Concepts group โ€” [Account and asset model: ledgering](./ledgering-system) and [Transaction lifecycle](./transaction-lifecycle) โ€” are background reading and do not block card issuing; you can come back to them before you integrate balances and transactions.