Crypto KYC Rules in 2026: Why Exchanges, DeFi, and Wallets Differ

A user verifies on a centralized exchange, uploads a passport, sits through a liveness check, waits for approval. A week later they connect a wallet to a DeFi front-end and get asked for the exact same thing again, from scratch. Then a wallet provider asks a third time.

None of this is a glitch. It's what happens when crypto KYC requirements aren't one rule but a patchwork that lands differently on exchanges, DeFi front-ends, and custodial wallets, and every platform builds its own verification from zero instead of trusting anyone else's. This post maps who actually has a KYC obligation in Web3, which regulations put it there, and why the same user keeps re-verifying even when two platforms are covered by the same rule.

Who Actually Has a KYC Obligation in Web3

"Crypto business" is not a legal category. The obligation to run KYC attaches to specific activities, custody, exchange, transfer, and control, not to the word a platform uses to describe itself. That's why the same question, "do we need KYC," gets a different answer depending on which part of the stack you're actually running.

Crypto Exchanges Are the Clearest Case

A platform that exchanges virtual assets for fiat, or one virtual asset for another, on behalf of a customer is a virtual asset service provider (VASP) under the Financial Action Task Force's Recommendation 15. That's the global floor almost every national regulator builds on. In the US, that means registering with FinCEN as a money services business under the Bank Secrecy Act. In the UK, it means registering with the FCA under the Money Laundering Regulations. In the EU, it means CASP authorization under MiCA. None of these give an exchange a way to opt out. If you take custody, run the order book, or settle the trade, you're the obligated party, not your customer.

DeFi Front-Ends: Obligation Follows the Entity, Not the Code

This is the part most explainers skip. A genuinely permissionless smart contract with no operator doesn't have a customer relationship to run KYC on, there's no "who" to onboard. But that's rarely the full picture. If a company builds the front-end, takes a protocol fee, holds admin keys, or controls which wallets can connect, regulators increasingly treat that entity as the VASP, not the contract. FATF's own guidance points at exactly this: the obligation follows whoever has "control or sufficient influence" over the arrangement, whether or not they call themselves decentralized. Publishing open-source code doesn't change who's running the interface a user actually clicks through.

Custodial Wallets: Obligation Follows Custody

A wallet provider that holds private keys on a user's behalf, or that can move funds without the user's direct signature, is functionally custodying an asset, which puts it in the same VASP category as an exchange. A non-custodial wallet, where the user alone holds the keys, generally isn't a VASP by that definition. The line isn't the word "wallet," it's whether the provider can move the user's funds without them.

KYC Requirements for Crypto Platforms: The Regulatory Patchwork

Three layers stack on top of each other. FATF Recommendation 15 sets the international floor: any FATF member country is expected to regulate VASPs for AML and counter-terrorist financing. MiCA is the EU's implementation of that floor, requiring CASP authorization under Regulation (EU) 2023/1114 before a firm can serve EU clients. Everywhere else, local AML law fills the gap differently, FinCEN's Bank Secrecy Act regime in the US, FCA registration in the UK, and dozens of other national frameworks in between, each with its own thresholds and paperwork.

We've covered both of the deep layers in full elsewhere: what a VASP actually is and who's on the hook, and what MiCA's CASP authorization deadline means for exchanges still unlicensed. What matters for this post is simpler: because the floor is global but the implementation is local, the same platform can be fully obligated in one jurisdiction and outside scope in another. That's a big part of why verification doesn't travel between platforms, even ones facing the same underlying rule.

Why the Same User Gets KYC'd Five Times Across Five Platforms

Every platform above builds its own KYC flow and treats the result as proprietary. Your passport scan, your liveness check, your proof of address, none of it moves with you. It gets uploaded fresh, checked fresh, and stored fresh at every single platform, even when two of those platforms answer to the exact same FATF-derived obligation.

The cost of that shows up as drop-off. Onboarding abandonment runs anywhere from around 25% at a bank a user already trusts to well over 60% on a newer platform, and document upload alone is consistently the single biggest friction point in that funnel. Crypto platforms don't get a pass on this just because their users are more tech-comfortable, a five-minute re-verification is still five minutes a user didn't expect to spend again.

And the stakes for getting it wrong keep rising. Crypto exchanges accounted for the largest share of global AML penalties in 2025, over $900 million, more than any other regulated sector tracked. Repeating the same checks at every hop isn't just annoying for users, it's expensive for platforms to build and still doesn't guarantee the checks are actually thorough.

KYC for DeFi Platforms: How Portable Credentials Cut Repeat Verification

The fix isn't lighter KYC. It's KYC that travels. In a reusable-credential model, a user verifies once with a trusted issuer, government ID, liveness, the works, and receives a signed, cryptographically verifiable credential back. From then on, they present that credential to any platform that accepts it, instead of uploading documents to a new party every time. The platform gets the same assurance a fresh check would give it; the user gets to skip the paperwork.

Hypersign's Reusable KYC works exactly this way: verify once, then reuse a signed credential across partners with explicit consent and cryptographic proof behind it, rather than re-collecting raw documents at every new platform. We've written more on the mechanism itself in why reusable KYC is the future of Web3 onboarding.

A few places this shows up concretely. A user who verified on a centralized exchange presents that same credential to a DeFi front-end instead of starting from zero. A client transferring between two MiCA-licensed CASPs presents a credential instead of re-running full onboarding at the receiving firm, cutting the time to a working account from days to minutes. A custodial wallet provider accepts a credential a user already holds instead of building its own document-collection flow from scratch.

What Compliance Teams Should Ask Before Choosing a KYC Flow

If you're evaluating a KYC stack for an exchange, DeFi front-end, or wallet, price per check isn't the question that matters most a year in. These are:

• Does the credential stay portable, or does it lock into one vendor? A verification result you can't reuse anywhere else is just an expensive one-time check.
• Does it cover the jurisdictions you actually operate in? A flow built only for FATF's floor won't clear MiCA's CASP bar or FinCEN's BSA requirements on its own.
• What does re-verification actually cost per touchpoint? Multiply your per-check price by how many times the average user re-verifies across your product surface, not just once.
• Is data minimized or fully re-collected every time? Selective disclosure, proving "verified over 18" without handing over a full date of birth, reduces what you're liable for storing.
• Is there an audit-ready record for every check? Given how 2025's AML enforcement numbers looked, "we think we checked" isn't an answer a regulator accepts.

If you want a head-to-head look at how specific vendors stack up on these questions, we've compared nine of them in Best KYC Providers for Web3 Companies in 2026.

Which KYC Approach Fits Your Crypto Platform

If you're running a custodial exchange, your obligation is settled, the only open question is whether your KYC stack can also handle Travel Rule data and cross-border onboarding without rebuilding every time a new jurisdiction enters the picture. If you're operating a DeFi front-end, the honest first step is figuring out whether your entity has enough control over the interface to be treated as the VASP, before you decide how much verification to run. If you're a custodial wallet provider, the moment you can move user funds without their signature, you're in scope, full stop.

Across all three, the platforms that will spend the least on repeat verification over the next few years are the ones built to accept a credential a user already holds, not just to issue new checks of their own. That's the whole case for verify-once-use-everywhere: same assurance, a fraction of the friction, and less of your users' data sitting in one more silo. See how it fits into a broader Web3 identity stack on our Web3 identity page.

FAQs about KYC for Crypto

Do all crypto platforms need KYC?

No. Obligation depends on whether the platform custodies assets, exchanges value between virtual assets or fiat, or has an identifiable entity controlling it, not on whether it markets itself as an exchange. FATF's Recommendation 15 defines the obligated category by activity, and a platform can fall outside it entirely if it never takes custody or control.

What KYC do DeFi platforms need to do?

DeFi front-ends with identifiable governance, a fee-taking treasury, or a company operating the interface increasingly face the same VASP-style KYC and AML duties as centralized exchanges. The underlying protocol being open source or non-custodial doesn't exempt whoever runs the front-end and controls user access to it.

Why do I have to do KYC again on every crypto platform I use?

Because most platforms treat identity verification as proprietary and non-transferable, so your documents and liveness check don't carry over even when two platforms face the same underlying obligation. Portable, verifiable credentials are the emerging fix: verify once, then present a signed credential instead of re-uploading documents.

About Hypersign

Hypersign runs reusable KYC and KYB on verifiable credentials, so a user verifies once and presents a signed, cryptographic credential to any accepting partner instead of re-uploading documents at every new platform. See the full Reusable KYC solution or explore Hypersign for Web3.