Trustless, Not Lawless: Designing KYC Compliance for a Decentralized Web3 Future

Why talk about KYC in Web3?

Sumsub is among the world’s largest KYC providers and certainly the leading provider in the crypto space. Our crypto clients to date, however, are almost exclusively centralized businesses, including some of the largest centralized crypto exchanges, hot wallets, and onramps. 

The reason for this is that these crypto businesses tend to operate in a similar manner to more traditional financial businesses like brokerages, or even banks, which means traditional AML regulations typically apply to them. 

The cornerstone of these regulations is the principle of “Know Your Customer” (KYC). In essence, this means you need to know who you’re providing services to and that you’re actually allowed to provide these services. 

But these principles don’t apply to Web3, a huge part of the crypto universe. This comes down to the nature of blockchain, which allows anyone to create their own wallet and stay in control of their funds with private keys. Think of it like opening a bank account without a bank! 

These Web3 wallets, which can be called unhosted, self-hosted or non-custodial wallets, fall outside of AML regulations because the businesses aren’t actually providing a financial service, and they aren’t controlling the user’s funds. Instead, they’re just providing software for users to create and use these wallets as they wish. 

Users can use their Web3 wallets with other services to make crypto transactions, such as various decentralized finance (DeFi) services like decentralized exchanges (DEXs). 

Why should Web3 businesses care about KYC?

First of all, Web3 wallet holders interact with centralized businesses like onramps and offramps. Cards tied to a Web3 wallet, for example, are a type of offramp. Offramps therefore need to conduct KYC for their clients, which introduces friction into the user experience. Understandably, Web3 wallets want to minimize this friction. 

Secondly, there is a broader question of trust in the crypto space. The same aspects of Web3 that many value so much can also make it easier for bad actors to take advantage of the system. That’s why, in many cases, it’s important to verify that users can be trusted, which is where identity verification can help. 

Finally, while traditional AML regulations might not currently apply to Web3 businesses, there are clear signs this could change in the future. In fact, many consider it a question of when, not if, some form of AML regulation will extend to Web3. This is why we’re seeing more and more Web3 businesses taking proactive steps to future-proof their compliance processes. 

What Web3 gets wrong about KYC

We often hear misconceptions from our Web3 partners and clients when they talk about KYC. One of the most common is thinking there’s some kind of “standard” KYC procedure (i.e., the checks required by one party being exactly the same as those required for another party). As a consequence, they tend to think it’s possible to skip KYC if another business has conducted its own KYC on an individual. 

This reflects a lack of understanding of regulatory requirements, which understandably stems from the fact that the Web3 space is not currently covered by AML regulations, and so they have limited experience with AML requirements.

Given Sumsub’s leading position in compliance solutions and domain knowledge of crypto specifically, we are in a unique position to both clarify the challenges that face Web3, and find potential solutions. 

Suggested read: What Is Crypto KYC and Why Do Exchanges Need It in 2025?

Back to basics: What are compliance requirements?

In a general sense, “compliance” just means following the law. For our purposes, this is compliance with AML/CFT regulations with a specific focus on when a business starts a new relationship with a potential client, like opening an account. AML rules also apply to areas like ongoing transaction monitoring, Travel Rule, case management, and filing reports with financial intelligence units (FIUs). Sumsub provides solutions for all of these, but for now, we’re focusing just on onboarding. 

At the account opening stage, AML requirements typically include what’s known as Know Your Customer (KYC), which itself is composed at least of two parts: 

1. Identity verification (IDV) — who we’re dealing with. This part typically includes liveness and deepfake detection;
2. AML screening — comparing the identified individual against databases of sanctioned individuals, prohibited types of transfers, and, in some cases, politically exposed persons (PEPs). This might include screening for adverse media. 

There’s also a broader process known as Customer Due Diligence/Enhanced Due Diligence (CDD/EDD). This is more of a risk-based requirement, with businesses expected to run extra checks depending on the risks involved and the type of service they’re offering.

These checks can include things like verifying addresses or sources of funds. Some are explicitly required by regulation, while others depend on the risk-based judgement of the money laundering reporting officer (MLRO).

Important KYC principles

KYC checks are business-specific

The specific KYC/CDD requirements for each business are defined by the MLRO based on applicable regulations, the services offered, and the risks involved. For example, one business might only require ID verification and AML screening, while another might include a proof of address. Another consideration is the types of IDs that are accepted. Some may only accept passports, while others may accept a driver’s license. These checks are tailored to each business and aren’t “standard” or “one-size-fits-all,” even if the process looks almost identical to the user. A customer might upload the same document to two different platforms, but one extracts only their name and date of birth, while the other also captures place of birth or nationality. Behind the scenes, the level of checks is driven by what each MLRO has decided is necessary.

Verification methods 

Local regulations may or may not specify exactly how identity verification checks should be done. Regardless, what checks are made and the way they’re carried out, the evidence collected, and how it’s stored all depend on the judgment of the MLRO—the individual responsible for approving KYC procedures.

KYC check non-fungibility

Because of the points above, KYC isn’t fungible. In other words, a KYC check done for Business A doesn’t automatically satisfy the requirements for Business B, even if everything else seems identical. Every business is responsible for performing its own KYC checks and confirming that it meets its regulatory obligations. In short, the “know” in “Know Your Customer” can’t be outsourced; it has to be done independently by each business. 

This means businesses need to be able to answer for themselves if they were to be audited by the authorities. That’s why there’s no such thing, at least not yet, as a universal, one-size-fits-all KYC process that everyone can simply accept without applying their own reviews.

Some checks need to be re-done

The nature of some checks, like AML screening, means they need to be done both at the point of onboarding and thereafter. In other words, knowing that someone was not on sanctions lists a week ago doesn’t mean they’re not on them now. 

Can you ever rely on someone else’s KYC?

There is, however, a small exception to the principle of non-fungibility. In some cases, regulations allow a business to rely on the KYC processes performed by another business. This is called “reliance” KYC. The legal bar for using KYC reliance is very high: typically, both businesses must be similar in nature, operate under the same regulatory framework (e.g., within the same jurisdiction), and the reliant business must have conducted due diligence of the other’s AML policies. Formal bilateral agreements are also required between the two parties. 

In short, the standards for reliance are high and very difficult to meet, especially given the cross-border nature of the crypto ecosystem. 

Relevance of KYC regulations to Web3

It’s important for us to remember that the principles of AML regulations were developed over several decades, long before blockchain technology emerged. As a result, they don’t fully account for the capabilities of the technology, nor do they always align with the values of the Web3 community.

Conflict with the values of the Web3 community

As things stand today, the core principles of the Web3 community—such as privacy, decentralization, trustlessness, and permissionlessness—are largely not a priority for regulators. That said, some values, like privacy, do align with data protection laws (which are separate from AML regulations) that emphasize data minimization and only collecting what’s necessary.

There are features of blockchain technology that don’t exist in the Web2 or offline world, particularly the use of cryptography to prove immutability, meaning that a cryptographic claim hasn’t been altered since the moment it was created. However, while the technology can confirm that the claim’s data hasn’t changed, it doesn’t verify the validity of the original claim itself. Trust in the claim still depends on knowing who issued it, on what basis, and whether the issuer is a reliable party.

Suggested read: How KYC Providers Can Help Crypto Businesses Scale

Existing Web3 KYC and identification solutions

There’s a lot of discussion on different technologies for enabling Web3 KYC, so we’d like to share our perspective. Rather than focusing on specific providers, we’ll look at the general types of technologies involved, like soulbound tokens (SBTs), on-chain attestations (OAs), and zero-knowledge proofs (ZKPs).

First, let’s say Party A performs certain checks (collecting data, analyzing it, making a decision, and retaining the evidence) and then uses one of these technologies to generate a cryptographic statement about an individual subject to KYC. The word “statement” is important here: whether it’s a ZKP, an SBT, or an OA, it’s ultimately just a statement, claim, or declaration made by Party A.

This claim can either be shared directly with Party B or made publicly available on-chain. At their core, these technologies are simply a secure means of transmitting a claim from a trusted source to a recipient. Party B can then be sure about who issued the statement (i.e., the identity of Party A, the “source of trust”) and that the statement hasn’t been altered since it was issued. 

Next, Party B can decide whether they trust Party A, but typically, they’d review the exact verification process used for issuing the statement. Even if Party B is completely satisfied with the issuer and their methods, that isn’t enough to satisfy KYC requirements. If a regulator audits Party B, the best they can say is, “This statement was issued in this exact way by Party A,” which is unlikely to be acceptable for a regulator.

While they are great ways to transmit information securely and programmatically, these technologies don’t replace the requirements of AML regulations. Most notably, they tend to miss the core principle that KYC must be carried out by each party independently. You can’t skip KYC just because you are certain that another business has already done theirs. 

So, are these technologies and products useless? From a traditional AML compliance perspective, the answer is unfortunately yes. But that doesn’t mean they have no value. They can help solve other challenges, like proving that a Web3 wallet is controlled by a real and unique human, or revealing certain attributes about this person, like their country of residence. 

These can be very useful for risk management, fraud prevention, or complying with other regulatory requirements where the standard of proof might be different from AML regulations.

Suggested read: Crypto Fraud: “What The Fraud?” Podcast

How can KYC be streamlined in general and applied in a Web3 context?

If we accept the principle that any business subject to KYC requirements must do it themselves, then it’s clear there’s no way to “skip” KYC altogether. The real question then becomes “how can we improve the user experience, making KYC as frictionless as possible while aligning it with the benefits of blockchain technology and at least some of Web3’s core values?”

Streamlining KYC experiences in general

A standard KYC check consists of three checks:

1. ID document verification
2. Liveness detection and facematch
3. AML screening

ID document verification is usually the most cumbersome step. It requires the user to photograph, scan, or upload an identity document, which then needs to go through a plethora of authenticity checks and data extraction processes. This step introduces friction and can lead to user drop-off. It is also a major point where fraud can occur. If the document image is of poor quality, it may also cause the face check to fail. Conversely, a high-quality document image usually increases the likelihood of passing the liveness detection and facematch step.

In Sumsub’s experience, the vast majority of drop-offs happen at the document capture step, hence optimizing it has the greatest impact on the overall experience. It’s important to note that liveness detection and AML screening still need to be performed at the time of the KYC being done. These steps can’t be skipped or reused.

Sumsub’s data, however, shows that removing the document capture step reduces the time to complete KYC by up to 50% and improves the end-to-end conversion by up to 30%.

Sumsub Reusable Identity suite of products

Sumsub helps reduce friction for users by allowing documents from previous successful KYC attempts to be reused in subsequent KYC checks. It’s similar to saving your card details with Stripe for faster checkout, only here you’re saving your identity documents for faster KYC. Documents can be shared either from another client, with the consent to do so, or from Sumsub directly if the user has created a personal profile with Sumsub, known as a Sumsub ID. In the end, the result is the same—it’s significantly quicker to complete and leads to higher conversion rates.

How Sumsub is bridging Web3 and off-chain verification

Sumsub leverages Sumsub ID to create a Web3 digital representation of a user’s off-chain identity. As discussed, there are some Web3 use cases where it’s necessary to establish trust or reduce risks, while in others, full AML compliance is required. 

For non-KYC use cases like proving a person’s humanity or uniqueness (i.e., Sybil protection), Sumsub can serve as an issuer of on-chain credentials that attest to these characteristics. We’ve already demonstrated this by issuing attestations through both the Solana Attestation Service (SAS) and Linea’s Verax Attestation Service.

On Solana, our attestation acts as “proof of IDV”, where Sumsub retains the user’s identity profile off-chain. On Linea, the attestation is “proof of humanity and uniqueness” using only a liveness check and a facematch performed on a vector face mask without storing the actual photo.

These examples are part of a broader trend, with many players now issuing various types of OAs. SAS launched with around 10 issuers, while Verax currently has around 30. However, many of these issuers don’t verify a person’s real identity; instead, they rely on signals like social media profiles or on-chain activity. As a result, these attestations are not ultimately useful for compliance purposes.

For use cases that do require KYC, there needs to be a mechanism to link the on-chain credential to real-world identity information. This can take the form of a pair of identities: one stored off-chain that contains personally identifiable information (PII), and another on-chain that derives from it and serves as an access token to the off-chain record.

The full circle of how this could work is shown in the diagram below:

In this setup, the user creates an off-chain identity profile with Sumsub (a Sumsub ID) and can then request Sumsub to issue any type of on-chain credential needed for a specific use case or ecosystem. They can use this credential online. If a real-world, off-chain KYC check is later required, the Web3 dApp can request user authorization, such as an access authorization in their wallet, to access the user’s off-chain PII and trigger Sumsub to (re)run AML-compliant KYC checks.

Crucially, it’s this final step of re-running the KYC checks that completes the circle and ensures AML compliance. On-chain credentials alone cannot fulfill this requirement.

Looking ahead

Sumsub is investing into decentralised Web3 identity solutions. We plan to be working with more ecosystems to issue the various types of on-chain credentials. 

If you’re an L1/L2 blockchain, a dApp, or any centralized business working with Web3, we would love to hear from you and build together!

Book a demo