Known Customer Credential Guide (KCCs)

Performing KYC on tbDEX

To transact on tbDEX, PFIs need to translate their compliance requirements into the format of a Verifiable Credential. For example, a PFI offering on-ramps or off-ramps on tbDEX may require the presentation of a VC that proves the person requesting services has previously completed KYC with that PFI. 

To help PFIs get started using tbDEX, we’ve developed a standard type of Verifiable Credential that’s specifically designed to represent a PFIs KYC and sanctions requirements, called the Known Customer Credential (KCC). 


A KCC is a provable expression of the result of a compliance process.


The Issuance flow provides a standard means of prompting customers to complete a PFI’s existing sanctions, IDV and customer due diligence process, and can be used to represent successful completion of KYC in an issued Verifiable Credential. Essentially, the KCC is proof that the PFI has verified the identity of the individual who controls the associated DID and performed the necessary compliance checks.


KCCs are a useful tool for PFIs offering services on tbDEX, and may generally be useful for any activity that could benefit from a user presenting proof of regulated compliance processes and procedures without requiring the user to present their personal information again. 


KCCs leverage widely adopted and security-reviewed protocols from the OpenID Foundation, along with other open standards. For an in-depth technical overview of KCCs, including a list of all standards used, refer to the KCC Technical Guide.

Context

To provide clarity on how KCCs function, many of the examples in this guide will refer to a user named Alice transacting via a fictional mobile application called Mobile Wallet. Mobile Wallet is a mobile application that individuals use to:

  1. Purchase digital assets using fiat currency from PFIs on tbDEX.

  2. Sell digital assets for fiat currency to a PFI on tbDEX.

  3. Manage and secure their digital identity information. Mobile Wallet also acts as a self-custodial digital wallet for Identity information.

    • It creates a DID for the user and securely stores the private keys for that DID directly on-device.

    • It stores Verifiable Credentials issued to the user directly on-device.


⚠️ Note: While our example focuses on a Mobile Wallet capable of purchasing, storing, and selling digital assets, KCCs may generally be used for any type of financial transaction.



Now let’s dive into how a KCC can be used to meet the requirements of a PFI’s KYC and sanctions compliance program.

Step 1: Setting requirements for your offerings

To transact with PFIs on tbDEX, Alice first opens Mobile Wallet and searches for PFIs offering services of interest to her. Alice sees a handful of PFIs offering the service she wants in her region, each of which requires Alice present a Verifiable Credential to access the service. Alice settles on one PFI, which has positive reviews and offers competitively priced services.


⚠️ Note: Mobile Wallet has total discretion over how much or little of this process to display to the user. Additionally, there is no limitation on the kinds of services a PFI can offer on tbDEX. We’ll dive into specific examples in future sections.


The type of Verifiable Credential the PFI requires to transact on tbDEX is a KCC issued by the PFI. What this means is the PFI will provide services to Alice if she can prove she has completed and passed their own unique KYC process and the necessary compliance checks..


⚠️ Note: As a Compliance Officer at this PFI, this means setting the following requirement with your Engineering team: “tbDEX Offerings must require a Verifiable Credential of type ‘KCC’ that was issued from our PFI’s DID.”


Step 2: Alice applies for the KCC

The next step is to enable Alice to apply for the required KCC, assuming she doesn’t have one already. To accomplish this step, Mobile Wallet renders the PFI’s onboarding flow in a Web View. This is effectively the KCC application process. Alice then completes the onboarding flow by providing her personal information,  a government-issued photo ID, and/or biometric information. For technical how-tos for this process, see here

⚠️ Note: Consult your Engineering, Risk, and Compliance teams to ensure that the web-based onboarding flow meets the security, legal, and compliance requirements of your PFI’s existing KYC processes. 


Step 3: Issuance of the KCC to Mobile Wallet

In addition to identity verification, the PFI’s onboarding flow may include processes such as Sanctions or PEP Screening, Customer Due Diligence (CDD) or Enhanced Due Diligence (EDD). Additional information may be required to be collected and verified to meet the PFI’s regulatory requirements.

If all is successful, the PFI issues Alice the KCC attesting to her status as a customer of the PFI whose identity has been successfully verified, which is held by Alice in the Mobile Wallet. At a minimum, the KCC is bound to Alice’s DID, meaning only the person controlling Alice’s DID can construct an authentic presentation of the KCC.

Step 4: Presentation of the KCC for financial services

Once Alice has received the KCC in Mobile Wallet, when requesting a quote from the PFI, she then presents the KCC to the PFI in order to meet the requirements of their offering.


⚠️ Note: Mobile Wallet may abstract away this step for Alice after receiving consent, since she has just undergone KYC. This enables her to seamlessly transact with her selected PFI immediately after successful KYC, without the need for a subsequent, manual presentation of the KCC.


Although all required personal information is collected and verified by the PFI, only the following information is visible in the content of the KCC when it is presented:

KCC Properties Elements Example Values Description
Issuer issuer "did:example:issuer" The DID of the entity that issued the credential
Issuance Date issuanceDate "2023-05-19T08:02:04Z" The date the credential was issued
Expiration Date expirationDate "2026-05-19T08:02:04Z" The date the credential expires
Credential Subject id

countryOfResidence

jurisdiction

tier
"did:example:subject"

"US"

"US"

"Tier 1"
The DID of the subject that the credential is being issued to

ISO-3166-2 letter country code representing subject's verified country of residence

(Optional) ISO-3166-2 letter country code representing the legal jurisdiction where the issuer has performed IDV

(Optional) The tier your customer falls into, assuming your business performs tier-based KYC
Credential Schema id

type
"https://vc.schemas.host/kcc.schema.json"

"JsonSchema"
URL to the schema used for the KCC

Format type of the schema used for the KCC
Evidence kind

checks
"document_verification"

["passport","utility_bill"]
(Optional) The evidence describing the due diligence performed by the PFI to verify the identity of the known customer. Can be used to describe multiple “kinds” of compliance “checks”.

We have included several optional fields in the KCC properties. The “tier” element nested under the Credential Subject refers to an internal classification of the level of due diligence completed on a particular individual. The Evidence property of the KCC can be used to express the specific compliance processes performed to verify the identity of the individual and comply with applicable regulatory obligations.

Step 5: Verification of the presented KCC

After receiving the presented KCC from Alice, the PFI performs a number of checks on the KCC to ensure it meets the acceptance criteria. 

The first set of checks the PFI performs are authenticity checks, which can be easily performed using the SDKs.

  • Verify that the KCC was issued by your PFI or a PFI you trust

  • Verify the integrity and authenticity of the KCC, ensuring it has not been tampered with

  • Check that the DID presenting the KCC is Alice’s DID

  • Ensure the KCC is not expired


Next, the PFI’s Compliance systems look up the DID referenced in the KCC, and cross-check that DID with the DIDs recorded in their customer database, confirming that:

  • Alice’s account remains open and clear from any compliance concerns that may have surfaced during on-going monitoring

  • Alice is eligible to perform the transaction and has not exceeded transaction limits


⚠️ Note: PFIs may fully automate these checks and run them in parallel, resulting in a seamless experience for Alice.


At this stage, it is also critical that the PFI is reasonably assured that Alice is the person presenting the KCC, and not someone else. To address this concern, the PFI’s Compliance team should consider the following questions:

  • Does Mobile Wallet have strong authentication controls in place for accessing the wallet and signing KCC presentations? (such as biometric authentication controls, or the requirement for a pre-set pin?)

  • Does Mobile Wallet implement robust data security controls to protect Alice’s KCC and private key from theft and use by third parties?

Step 6: Fulfillment of the payment

The PFI has now received a digitally verifiable proof that Alice fulfilled the requirements of their KYC and sanctions program and may now proceed with the transaction. 

⚠️ Note: It is recommended the PFI maintain an audit trail of the presented KCC for a time period that aligns with their regulatory record keeping requirements, as proof of their KYC process being fulfilled.

What’s possible

This guide covered how to use Decentralized Identifiers and Verifiable Credentials on tbDEX in support of a PFI’s KYC and sanctions program. The SDKs provide you with the ability to implement your own PFI’s KYC program and represent the result of those processes as a Verifiable Credential called the KCC. A KCC can be presented to access a PFIs services from any application without an explicit partner integration. In future versions of this guide, we’ll walk through the third party reliance of KCCs and the incentives in place to enable reliance.

Up next, we’ll walk through how a PFI can enable On and Off Ramps on tbDEX, and show you how DIDs and VCs are used to fulfill PFIs’ compliance requirements for these transactions.

Next
Next

Ramps on tbDEX Compliance Guide