Skip to main content

​
📄 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.

​
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.

​
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.
Core KYC flowCore KYC flow
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 and 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).
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; Sumsub’s own documentation is at 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.