Meeting KYC Requirements without PCI Scope

Is the pain of solving a problem worse than the pain of living with it? 

This is the dilemma merchants face with owning their own customer data. Know Your Customer (KYC) compliance is the first step to protecting the payment ecosystem. KYC requirements ensure everyone that you do business with is who they say they are. In practical terms for merchants, this means checking details like addresses and CVV codes to ensure customers are using their own valid payment methods. When credit card details can’t be matched to the other information a customer provides, merchants must be prepared to decline the business. 

Accessing this customer data is a big driver of a merchant continuing to work with their payment service provider (PSP.)  When a PSP handles KYC requirements on behalf of a merchant, that data stays with the PSP. 

But when a merchant has multiple sub-merchants on their platforms—think VSaaS or Creators—managing KYC requirements in-house can improve your fail rate by associating payment data with the raw personally identifiable information (PII). 

Meaning, if you can own the data, and access it—without having to touch it—that’s powerful. 

But is the pain of the shift worth solving the problem? Meaning, do you ask for that customer information again? Do you try to get it from your PSP?

Why use a third-party to meet KYC requirements? 

If you are looking to maintain or evolve into multi-PSP processing, owning the KYC data without becoming PCI compliant yourself allows for easily boarding customers to a different PSP for any reason.  

Most large acquirers make it difficult to own your customer PII, which is a big reason why merchants continue to work with a full-service PSP. Getting KYC is not easy. But, if you can vault the PII without having to store it yourself, it can be accessed for underwriting with any other PSP or acquirer. This is particularly useful in the VSaaS space. 

Oftentimes, a merchant working with a full-service PSP does not have access to this KYC data. Meaning, to get it, you need to ask the customer again, or retrieve it from the PSP. 

Return to Top

What are common challenges in KYC implementations? 

In a KYC implementation, the most common pain points are associated with data collection and eventual analysis. Collecting PII data necessary to conduct KYC comes with risk and constraints to an organization. 

• Storing PII Introduces Risk: Attackers value social security numbers and other types of PII even more than you. So, when storing PII, you’re increasing the cybersecurity threat to your organization. 
• Costs: Over 140 countries have data residency laws that prescribe how PII must be handled. Each year, new and emerging requirements create new costs and potential delays for organizations. These can vary from region to region, or industry to industry. 
• KYC Providers Can Be Limiting: Whether it’s pricing, regulations, or uptime, a single KYC tool makes it difficult to continually optimize for new requirements, and maintaining operations. 
• Losing Control of Your Data: When PSPs or third parties own your KYC data, it’s often not accessible or usable when migration providers or negotiating new buy rates. In some cases, you’re forced to re-collect customer information.

Return to Top

Can tokenization help meet KYC requirements? 

Yes. 

Tokenization, which transforms a raw value into an undecipherable token, reduces an application's compliance scope and provides some optionality for using sensitive data. For most, however, an in-house solution rarely finds funding, nor does it address all of the challenges posed by PII and other sensitive data types. 

Instead, product teams are turning to data tokenization platforms, or secure data vaults. These solutions offer PCI Level 1 and SOC 2 certified environments to store and encrypt raw values outside a developer’s existing systems. Merchants then use modern developer tools and services to manage, process, and share their encrypted data or its corresponding token. 

This gives a payments engineer the best of both worlds:

• Security and Compliance: Sensitive data never enters your environment, keeping your organization out of PCI scope and GDPR scope. 
• Ownership and Flexibility: You control who can access, process, or transfer data across any third-party. 

From searching to performing machine learning, a developer can do almost anything with and to the encrypted data held within the vault, while retaining just a plaintext token in their system, and nonetheless limiting their exposure to compliance requirements. 

Return to Top

Protecting PII While Running KYC Checks 

When PII is stored with a third-party tokenization provider, the data is protected in a vault, with the merchant holding just an undecryptable token for KYC checks. 

The merchant uses that token to instruct the vault to submit payment information to their choice of PSP or gateway. This keeps the PII from ever coming into their own environment. 

This is how you could meet KYC requirements using Basis Theory, and storing PII within a token vault: 

1. Collect and tokenize PII using Basis Theory Elements. The Elements SDK handles the encryption and tokenization automatically. 
2. With Basis Theory’s Proxy, use your preferred KYC mechanism to verify the identity. The Proxy swaps tokens for plaintext values in transit, keeping your systems away from the raw PII. 
3. The results can be tokenized and stored for future use. 

And poof! An end-to-end KYC check is completed without ever handling raw data. This approach reduces the risk of a data breach, and the cost of PCI compliance. 

The result? A modern, secure KYC framework that lets product teams focus on growth, not governance. 

Our white paper digs deeper into the regulatory landscape surrounding KYC at the state and federal levels. The guide also shares how Basis Theory’s KYC Data Engine can be a powerful ally in setting up a secure vault and becoming a resource for making credit decisionsing, identifying verification, and customer service. 

Return to Top