No-KYC crypto payment processors: the complete 2026 guide

What "no-KYC" actually means in practice

Search for "no-KYC crypto payment processor" and you'll get a directory of services that don't ask for your passport at signup. Some of them are legitimately non-custodial. Most of them aren't. The distinction matters enormously, because "no-KYC" is a policy choice; "non-custodial" is an architectural one.

A policy can change. An architecture can't, at least not without rebuilding the whole product. If a processor holds your funds — even for a minute, even in an omnibus wallet, even "in transit" — they are legally a money transmitter in most jurisdictions, and that designation comes with mandatory KYC obligations that they will be forced to enforce the moment a regulator asks. The "no-KYC" claim becomes "no-KYC until the volume gets interesting," at which point your account is frozen and your funds are held pending document review.

This is not theoretical. It's the entire business model of the custodial crypto-payments industry. Read on.

The three architectural tiers, ranked

Tier 1: Custodial with KYC

Examples: Coinbase Commerce, BitPay (after their 2021 KYC requirement). The customer pays the processor. The processor settles to the merchant either in fiat (after on-ramp) or in crypto (after batch settlement). The merchant must complete business KYC, which typically involves uploading articles of incorporation, beneficial-ownership disclosures, and proof of address. The processor can freeze your account at any time and will, if your industry triggers their automated review system. Common triggers: high refund rates, unusual transaction sizes, MCC codes flagged as elevated risk.

Tier 2: Custodial without KYC (the "no-KYC" middle ground)

Examples: NOWPayments, Plisio, CoinGate's anonymous tier. These services accept signups without KYC but still hold your funds during settlement — typically for minutes to hours, sometimes days during "review." The "no-KYC" claim is real at signup, but it's conditional. From the NOWPayments terms of service, slightly paraphrased: "We reserve the right to request identity verification at any time, and to suspend withdrawals pending review." Most of these services have a volume threshold (often around $10,000 lifetime) at which they auto-trigger KYC requests.

For low-volume merchants, this is workable. For anyone doing real volume in an industry the processor's compliance team doesn't understand, it's a time bomb.

Tier 3: Non-custodial (the real answer)

Examples: BTCPay Server (self-hosted), Sovrn. The customer pays the merchant's own address — derived from the merchant's own keys — directly. The processor never sees the funds. There's no settlement step, because settlement happened on-chain the moment the customer's transaction confirmed. No "review" is possible because there are no funds to review. No KYC is collected because there's no legal basis to collect it: the processor isn't a money transmitter.

This is the only category where "no-KYC" isn't a policy that can be reversed by tomorrow's compliance memo. It's a structural property of how the product works.

Why this distinction is the entire game

Here's a thought experiment. You're a research-peptide merchant doing $30,000 a month through a Tier 2 processor. The processor has KYC'd you, your business is in good standing, payments are flowing fine. One Tuesday your processor's risk team rotates a new policy: any merchant in MCC 5912 (drug stores and pharmacies, which is what their MCC mapping has decided your business falls under) is now classed as elevated risk, requires a 90-day rolling reserve of 20% of monthly volume, and must complete enhanced due diligence within 14 days.

You have two weeks to choose between (a) compliance theatre that will reduce your working capital by $6,000, (b) finding a new processor, (c) writing off the funds in transit.

None of this can happen at a Tier 3 processor. There's no risk team rotating policies, because there's no risk: the processor's revenue isn't tied to the merchant's volume in the way that creates principal-agent problems. The processor takes a small fee on each transaction, the merchant gets the rest, the funds never sit on the processor's balance sheet, and the regulator has nothing to ask the processor about.

The legal reality (this is not legal advice)

In the United States, FinCEN's guidance on money transmitters (specifically 2019-G001) is clear about the principle: an entity that accepts value from one person and transmits it to another is a money transmitter, regardless of whether the value is fiat or crypto. The KYC obligations under the Bank Secrecy Act follow from that designation.

What makes a non-custodial processor different is that it never accepts value. Customer A pays Customer B directly, on-chain. The processor's only role is to generate the receive address, watch the chain for confirmation, and (optionally) fire a webhook. None of those activities qualify the processor as a money transmitter under FinCEN's framework, and so the BSA/KYC requirements don't attach.

This is also the analysis that's been upheld in FinCEN's published guidance on similar architectures. The same architecture, in different forms, underlies why Uniswap's interface (no custody) is treated differently from Coinbase's exchange (custody).

How Sovrn's architecture eliminates KYC at every layer

Sovrn doesn't ask for KYC because Sovrn's architecture makes KYC unenforceable. Specifically:

• EVM chains (Optimism, Base, etc): Every merchant gets their own deterministic splitter contract via CREATE2. Customer sends to the splitter. The splitter's receive() function instantly forwards 99.5% to the merchant's wallet and 0.5% to Sovrn's fee wallet, atomically in the same transaction. No custody. No reversibility. The contract is open-source, immutable once deployed, and has no admin keys.
• Bitcoin: Sovrn allocates a unique receive address per payment, derived deterministically from a BIP-84 master key. The customer pays that address. Sovrn's watcher detects the payment and broadcasts a sweep transaction with two outputs — merchant + Sovrn — in one tx. The ~30-second window between detection and sweep is the inherent Bitcoin trade-off (no smart contracts).
• Solana: Ephemeral keypair per payment. Customer pays the keypair. Sovrn signs a two-transfer forwarding tx and broadcasts. Sub-second finality.

At no point does Sovrn the company hold a balance that belongs to the merchant. There is no withdrawal step because there's nothing to withdraw. There is no "compliance review" because there's nothing to review.

The same property that makes Sovrn no-KYC also makes Sovrn unable to freeze the merchant's account. The two facts are the same fact.

What you should look for in a no-KYC processor

1. Read the terms of service for the word "custody." If the processor's ToS describes them holding funds, even briefly, even "in escrow" or "in transit" — they're Tier 2 at best. The "no-KYC" is conditional.
2. Look for the words "money transmitter license" or "MTL." If they have one, they are by definition a money transmitter, and they must KYC their customers under the BSA. The "no-KYC" claim is a policy that will reverse the moment they grow.
3. Check whether the processor publishes the source of their settlement contracts. If they don't, you can't verify that the architecture is what they claim it is. Sovrn's splitter contracts are open-source and live on the Optimism block explorer for anyone to read.
4. Ask: where does my address come from? If the processor generates the address from their keys and forwards funds to you later, they had custody, even if it was brief. If the address is derived from your xpub or routes directly to a contract you control, custody never happened.
5. Ask: what happens if the processor's website goes down right after the customer pays? In a real non-custodial architecture, your funds are already yours. The processor's outage is a UX problem, not a financial one. In a custodial architecture, your funds are sitting in the processor's wallet pending settlement — and an outage during that window is your problem to negotiate.

Why Sovrn charges 0.5% when others charge 1–4%

The custodial processors charge what they charge because their costs are large: insurance against custody risk, compliance teams, money-transmitter licensing in every state they operate, audit, KYC vendor fees, chargeback exposure, and (most expensive of all) the cost of the float they hold for the merchant.

Sovrn has none of those costs because Sovrn has no custody. Our marginal cost per transaction is approximately $0.0003 (Solana RPC + a price-feed lookup). At 0.5%, our margin on a $100 transaction is $0.499. We didn't pick 0.5% because we're undercutting anyone. We picked it because it's a clean, sustainable rate that lets us run the business without ever needing to add a custody step.

The catch (every honest article has one)

The trade-off of non-custodial is that refunds are manual. In a custodial system, the processor can issue a refund from their pool. In a non-custodial system, the funds aren't in any pool — they're already in the merchant's wallet — and the merchant has to send them back from there. Sovrn provides a one-click refund button in the dashboard that constructs the refund transaction, but the funds come from the merchant, not Sovrn.

For most merchants this is fine. For some (e.g. high refund-rate consumer goods), it's an operational consideration worth thinking through before you commit to a non-custodial rail. Most of our merchants run dual rails: Sovrn for the customers who want to pay in crypto, a fiat processor for the rest, and refunds are handled per-rail.

When to use Sovrn vs the alternatives