KYC origins — banking, not hosting
Know-Your-Customer (KYC) is a regulatory framework born in the banking sector. The contemporary version stems from the US Bank Secrecy Act of 1970 (anti-money-laundering provisions) and the international anti-money-laundering recommendations published by the Financial Action Task Force (FATF). FATF's 40 Recommendations form the de facto global KYC standard; member countries (essentially every developed economy) implement them through their domestic banking regulators.
The basic obligation is that financial institutions must verify the identity of their customers ("customer due diligence"), maintain records of those verifications, and report suspicious activity to financial-intelligence units. The threshold for triggering KYC varies by jurisdiction and account type but is generally low — opening any bank account in 2026 requires identity verification at the level of a government-issued ID and (often) proof of address.
KYC was never designed for hosting. Hosting is not a regulated financial service; the FATF recommendations do not apply to a hosting provider any more than they apply to a magazine subscription service or a bicycle rental company. Why hosting providers ever introduced KYC is a question worth answering separately.
Why hosting providers ever introduced KYC
The reason is downstream of payment-rail integration, not direct regulatory obligation. A hosting provider that accepts credit cards through a payment processor (Stripe, Adyen, Worldpay) inherits some of the processor's KYC obligations — particularly around chargebacks, fraud prevention, and sanctions compliance. The processor's contract typically requires the merchant to maintain customer-identity records sufficient to dispute chargebacks and to refuse service to sanctioned individuals. This is enforced contractually, not legally; a hosting provider is not directly subject to FATF, but their payment processor is, and the obligation flows through the contract.
Beyond payments, some hosting providers face KYC pressure from upstream infrastructure (datacenters that require KYC on tenants), regulatory expansion (the EU's eIDAS regulation creates an electronic-identity framework that some providers anticipate will eventually extend to hosting), and law-enforcement coordination programs that incentivise voluntary KYC adoption.
The result is that most large mainstream hosts (AWS, Google Cloud, Azure, DigitalOcean, Linode/Akamai, OVH) require KYC at signup — driven primarily by their fiat payment infrastructure, secondarily by upstream pressure. Hosts that operate on different payment rails (crypto-only, prepaid voucher, cash-by-mail) escape the primary driver and can credibly offer no-KYC service.
The four layers of KYC at a typical host
Layer 1 — government-issued ID upload. Photograph or scan of a passport, driver's licence, or national ID card. The most onerous and the most identifying. Many large hosts require this for new accounts above a usage threshold; some require it at signup. No-KYC hosts do not collect this layer.
Layer 2 — verified email address. The host sends a confirmation link to an email address and requires the customer to click through. The host then trusts that email as the account identifier. Most hosts (KYC and no-KYC alike) require this layer in some form, primarily for service-delivery reasons (sending you credentials, billing notifications, security alerts). Working email is not the same as identifying email; alias services like SimpleLogin and anonaddy provide working email that does not link to a real identity.
Layer 3 — verified phone number. The host sends an SMS code and requires verification. Phone verification is harder to defeat than email verification because phone-number registries are increasingly KYC'd themselves (most countries require ID for SIM card purchase). Hosts that require phone verification are doing identity verification through the back door; no-KYC hosts skip this layer.
Layer 4 — payment-method identity. A credit card carries cardholder name, billing address, and (often) a verified phone number that the issuing bank attached during card issuance. Even if the host doesn't actively check, the data is in the transaction record and accessible to the host on subpoena. Crypto payment, particularly Monero, breaks this linkage — there is no cardholder name on the transaction. No-KYC hosts that accept crypto skip this layer entirely.
A genuinely no-KYC host skips layers 1, 3, and 4 (no ID, no phone, no card) and accepts layer 2 (email) at face value, requiring only that it works for service delivery. This is the standard operating model for offshore crypto-only hosts.
What no-KYC providers do not collect
Government-issued ID: not collected, not stored, not requested. There is no ID upload form anywhere in the signup flow.
Real name: not requested. The signup form may have an optional "name" field for invoicing display; you can put any string. Common practice is to use a pseudonym matching the email handle, or to leave the field blank.
Address: not collected. Some no-KYC providers ask for a billing country (for tax purposes if any apply); the country can be self-declared and is not verified.
Phone number: not collected. The signup flow does not include a phone-verification step.
Payment-method identity: zero linkage. Crypto payment carries no cardholder data; the only identifier on the transaction is the deposit address (which is unique to the order) and the inbound transaction hash. Neither maps to your real identity unless you took an upstream KYC step (acquiring the crypto from a regulated exchange).
EFF's anonymity principles give a useful framing for what "identity-free service" actually requires. Privacy Guides' privacy-respecting services maintains a curated list of no-KYC service providers across hosting, email, VPN, and other categories.
What no-KYC providers still need
A working email address. Service delivery requires sending credentials, billing reminders, security alerts, and (occasionally) outage notifications. The email needs to be deliverable; it does not need to identify you. SimpleLogin, anonaddy, mailtm aliases all work; ProtonMail and Tutanota work; the email account on a self-hosted mail server on the same VPS works. The standard for "working" is just "can receive a delivery confirmation"; we don't pursue verification beyond the initial click.
A way to receive payment confirmation. Crypto payment is asynchronous — your wallet broadcasts the transaction, the network confirms it, and we credit your order. The /pay/ page polls for confirmation in real time, but the delivery mechanism (email, panel notification) needs a working channel. Same email as above.
Optional account credentials, if you choose to create an account. Many no-KYC hosts offer account-less ordering (no login required to deploy), but if you want a panel for managing multiple servers, you create an account with username + password (or webauthn). The username can be any string; we don't enforce real names.
An understanding of the AUP. Every reputable no-KYC host has an Acceptable Use Policy that prohibits universally illegal content (CSAM, credible threats, identity theft, sanctions violations). "No-KYC" doesn't mean "anything goes"; it means "we don't verify your identity, but we still expect you to operate within the law."
The honest limits of no-KYC
No-KYC at the host does not eliminate identity exposure if you collect identity from your own users. If you run an e-commerce site that requires customer addresses for shipping, you've created a database of identifying information that exists regardless of host policy. The host's no-KYC policy applies to the relationship between you and the host, not the relationship between you and your users.
No-KYC at the host does not eliminate criminal liability. If you commit fraud, harassment, or another crime through a no-KYC service, your home jurisdiction can still pursue you through other channels (financial-rail forensics on your own bank accounts, OSINT correlation of your public communications, traffic analysis on your home internet). The no-KYC host doesn't have your identity, but other parties to your activity may.
No-KYC at the host does not protect against your own operational-security failures. If you log into the host's panel from your home IP without Tor, the host's authentication logs link your home IP to the account. If you mention the server by name in a chat that links to your real identity, the linkage is created retroactively. No-KYC is the absence of host-side identification, not a magic shield against all identification.
No-KYC providers comply with valid in-jurisdiction court orders. If a Swiss court issues a valid order for whatever data we have on a specific account, we comply with the narrow scope of the order. The data we have is small (working email, payment hashes, account creation timestamp, and authentication logs from the most recent few weeks) and rarely identifying on its own — but "no-KYC" doesn't mean "resists all legal process."
How to evaluate whether a host is genuinely no-KYC
Look at the signup flow. A genuinely no-KYC host will not ask for a phone number, will not require an SMS code, and will not have a "verify identity" step gated by ID upload. The signup is typically: pick plan → pick coin → create order → pay → receive credentials. Anywhere in that flow that asks for ID or phone is a sign that the no-KYC label is not literal.
Look at the payment options. Crypto-only or crypto-primary is consistent with no-KYC; credit-card-primary with crypto as an afterthought is usually not, because the credit-card pipeline drags KYC obligations through the contract.
Look at the AUP and Privacy Policy. A no-KYC host should explicitly state what data they collect (typically: email + payment hash + IPs from authenticated sessions for the last N days). A vague "we collect what we need" is a warning sign; a specific itemised list is the standard.
Look for a warrant canary. Hosts genuinely committed to minimal data collection typically also publish a canary at /canary/ or similar. The canary is an active signal of the host's operational posture.
Test it. Sign up with an alias email, pay in crypto, see whether anything later in the lifecycle prompts for ID. If the host is genuinely no-KYC, your account works indefinitely without a verification step.
