AML/KYC Compliance for Crypto Companies:A Practical Guide (2026)
AML/KYC Compliance for Crypto Companies:
A Practical Guide (2026)
A compliance programme that exists on paper is not a compliance programme. This guide covers what VARA, FCA, MiCA, and FATF-aligned regulators actually look for when they inspect a VASP — and the four failures that cost licences.
Why Crypto AML/KYC Is Not a Copy-Paste from Banking
Most early-stage crypto compliance programmes are built by copying a bank's AML framework and replacing "bank account" with "wallet." This is the wrong starting point. Crypto compliance has the same objectives as banking compliance — prevent money laundering, identify customers, report suspicious activity — but the risk model, the technical infrastructure, and the regulatory expectations are meaningfully different. Understanding the three differences below is the foundation for building a programme that actually works under inspection. See our AML/KYC compliance services for a full programme assessment.
Traditional banking KYC assumes a direct link between a verified identity and an account. The account is the identity. In crypto, wallets are pseudonymous — the same person can control thousands of wallets, none of which are registered in their name. Counterparty wallets may have no KYC attached to them at all. This means that crypto compliance cannot rely on the assumption that a verified customer is the only person using their account.
The compliance logic in crypto must account for on-chain behaviour, not just identity documents. Who sent funds to your customer's wallet before they arrived? Did the source address appear on a sanctions list or have a known association with a mixer? Has the customer's transaction pattern changed in a way that suggests account sharing or a change in use? These questions do not arise in the same way in traditional banking because the account-to-identity link is assumed. In crypto, that link must be actively maintained.
FATF Recommendation 16 — the Travel Rule — requires VASPs to collect and transmit originator and beneficiary information on virtual asset transfers above the threshold (USD/EUR 1,000 in most jurisdictions). Banks have SWIFT, which has carried originator/beneficiary data for decades. VASPs have no equivalent legacy infrastructure. Most crypto transactions — particularly on-chain transfers between wallets — were designed to be anonymous and carry no metadata.
The practical result is that VASPs must either use a dedicated Travel Rule solution (Notabene, Sygna Bridge, VerifyVASP, and others) to exchange data with counterparty VASPs, or implement bilateral data-sharing arrangements. The technology exists, but implementation requires integration effort, counterparty identification, and — critically — operational processes for what happens when the counterparty VASP does not respond or cannot be verified.
VARA, the FCA, and AIFC inspectors have shifted their inspection methodology in 2024–2025. Earlier inspections focused heavily on documentation — does the firm have an AML policy, a risk assessment, a compliance manual? Current inspections go straight to operations: pull five transaction monitoring alerts from last quarter. Show us how they were reviewed. What is the rationale for the decision to clear them? Where is the SAR decision log? Show us three EDD files for PEP-status customers.
This shift matters because it means the quality of your AML programme is now measured by what your compliance team does day-to-day, not what your policy says they should do. A programme that has excellent documentation but inconsistent operation — reviewers clearing alerts in bulk, EDD files without source of wealth analysis, SARs filed late or not at all — will fail an operational inspection even if the paperwork is perfect. See our full compliance framework services for gap analysis against current inspection standards.
What Regulators Actually Require in 2026
The regulatory baseline for crypto AML/KYC has risen significantly since 2022. If you benchmarked your programme against 2022 standards and have not reviewed it since, you are likely behind — particularly on Travel Rule implementation and unhosted wallet treatment. Below is the current minimum requirement across the three frameworks that most VASPs and CASPs operate under. Our crypto licensing services include a full regulatory mapping for your jurisdiction.
FATF Recommendation 16 — the Travel Rule — is the baseline requirement for all VASPs globally. Any jurisdiction with a FATF-aligned regulatory framework (which includes the UAE, EU, UK, Singapore, and Kazakhstan/AIFC) requires VASPs to implement it. The standard requires VASPs to collect and transmit originator and beneficiary data on transfers above the USD/EUR 1,000 threshold.
- Originator data required: name, account number (wallet address), physical address or national identity number or date and place of birth
- Beneficiary data required: name, account number (wallet address)
- Applies to all transfers above USD/EUR 1,000, whether to another VASP or to an unhosted wallet
- Counterparty VASP must be identified and verified as a legitimate VASP — no data transmission to shell entities
- Records must be retained for minimum 5 years and available on regulatory request
From December 2024, CASPs authorised under MiCA must comply with the revised Transfer of Funds Regulation (TFR), which implements the FATF Travel Rule into EU law with additional requirements. MiCA TFR goes beyond the FATF baseline in several respects — most importantly for unhosted wallets. Our MiCA compliance service covers the full TFR requirements for EU CASPs.
- Full Travel Rule implementation required for all CASP-to-CASP transfers above EUR 0 (no de minimis threshold at the CASP level)
- Unhosted wallet transfers above EUR 1,000 require the CASP to collect and verify wallet ownership — self-declaration alone is insufficient above EUR 1,000
- On-chain analysis required for unhosted wallet transfers to assess risk before processing
- Batch transfers require individual Travel Rule data per originator — no aggregation
- Counterparty CASP verification: must confirm the counterparty is a licensed CASP before transmission
Outside the EU, the two most important regulatory frameworks for crypto companies are VARA (Dubai/UAE) and AIFC (Kazakhstan). Both are FATF-aligned but have jurisdiction-specific requirements that go beyond the FATF baseline in operational terms.
- VARA (Dubai): detailed AML/CFT Rulebook published in 2023; mandatory MLRO appointment; transaction monitoring system required (not spreadsheets); annual AML risk assessment; VARA inspections now include operational testing of TMS alerts
- AIFC (Kazakhstan): FATF-aligned framework; risk-based approach with documented methodology; annual AML audit by an approved external auditor required; Travel Rule compliance required for transfers above USD 1,000
- FCA (UK): Cryptoasset businesses must register under the MLRs; TFR compliance required from January 2024; FCA has issued 3 enforcement actions related to TFR non-compliance in 2024
- MAS (Singapore): PSA framework; Travel Rule implemented via MAS Notice PSN02; VASPs must use a designated Travel Rule solution
The Four Core Components of a Crypto AML Programme
A complete AML programme has four components, and regulators check all four. Missing or under-developed controls in any one of them is enough to trigger a formal finding. The left column names the component; the right column describes what regulators actually look for when they inspect it — not what the regulations say, but what the evidence requirement is in practice. Our AML/KYC compliance services cover gap assessment across all four areas.
KYC Tiers: What Risk-Based Approach Means in Practice
A risk-based approach does not mean doing less. It means calibrating the depth of your due diligence to the risk the customer actually presents. In practice, this requires documented criteria for assigning customers to tiers, evidence that the criteria are applied consistently, and EDD files that demonstrate substantive analysis — not just additional documents.
SDD applies where regulation explicitly permits a reduced level of customer identification — typically for customers who are themselves regulated financial institutions, listed company accounts, or low-value accounts where risk is demonstrably minimal. SDD is not a discretionary option that firms can apply based on their own judgment — it requires a documented regulatory basis.
The most common SDD error in crypto companies is applying SDD to customers simply because they are low-volume, have been on the platform a long time, or are "known" to staff. None of these are grounds for SDD. Most crypto companies over-apply SDD, which means their CDD programme is under-performing at the bottom of the risk scale. If challenged, the firm must demonstrate not just that they considered the customer low risk, but that the applicable regulation permits SDD for that customer category.
Standard CDD is the baseline for all customers who do not qualify for SDD and do not present elevated risk factors. It requires: identity verification against official documents, address verification, business purpose and nature of the anticipated relationship, basic source of funds (for most retail crypto customers, this means the origin of the funds used to fund the account — salary, business income, savings — not a full wealth statement).
Two operational failures appear consistently at inspection. First, static KYC files — collected once at onboarding in 2021 and never updated, even when the customer's transaction profile or risk indicators have changed. Standard CDD must be refreshed periodically (annually for medium-risk, immediately when a material change occurs). Second, incomplete beneficial ownership information for corporate customers — company registration documents are collected but the ultimate beneficial owner behind the holding structure is not identified or verified.
- ✓ Identity verified against government-issued ID
- ✓ Address verified (utility bill, bank statement)
- ✓ Source of funds documented (basic)
- ✓ Beneficial ownership confirmed for corporates
- ✓ KYC refreshed periodically or on trigger event
EDD is triggered by elevated risk indicators. The most common EDD triggers in crypto are: PEP status or close association with a PEP; high-risk jurisdiction of residence or business; unusual or high-volume transaction patterns; business type that presents elevated ML/TF risk (exchange, mixer-adjacent, gambling, high-value assets); and source of funds that cannot be verified through standard documentation.
EDD must include source of wealth analysis, not just source of funds. Source of funds identifies where the specific money in the transaction came from. Source of wealth identifies how the customer accumulated the wealth they hold overall. For a customer depositing USD 500,000, source of funds might be "wire from personal account at Barclays." Source of wealth requires understanding whether that wealth was earned, inherited, generated through business, or otherwise acquired — and seeing evidence to support it.
- ⚡ PEP status or PEP family/close associate
- ⚡ High-risk jurisdiction
- ⚡ Unusual transaction patterns or volume
- ⚡ Business type: exchange, mixer-adjacent, gambling
- ⚡ Source of funds cannot be verified
- ⚡ Large transaction volume relative to stated business
Travel Rule Compliance: The Part Most Companies Get Wrong
The Travel Rule is the compliance area where the gap between policy and practice is widest. Most crypto companies have a Travel Rule policy. Far fewer have a Travel Rule implementation. Regulators now ask for evidence of actual data transmission — not a policy that says you will transmit. The requirements differ significantly between transfers involving another VASP and transfers to or from unhosted wallets, as detailed below. For a full compliance gap assessment, see our AML/KYC compliance services.
Common Failures That Cost Licences — and the Readiness Checklist
The four failures below account for the majority of VASP licence suspensions and enforcement actions in 2024–2025 across VARA, the FCA, and AIFC-supervised firms. They are not sophisticated edge cases — they are basic operational gaps that exist because compliance infrastructure was not built to match the written programme. The readiness checklist that follows lets you assess your position before an inspection does it for you. For a structured gap assessment, see our compliance framework services.
Transaction monitoring generates alerts — sometimes hundreds per day for active platforms. When the alert queue is too large and the review team too small, the practical response is bulk clearance: marking alerts as reviewed without actually reviewing them, or applying a single generic rationale across multiple unrelated alerts. This is the most common single finding in VASP inspections.
Why it is treated as a critical failure: regulators treat bulk alert clearance as equivalent to having no transaction monitoring at all. If you cannot demonstrate that a human reviewed the alert, understood the transaction pattern, and made a reasoned decision to clear or escalate — with that rationale recorded — the monitoring system is treated as non-functional for compliance purposes.
A file labelled "Enhanced Due Diligence" that contains a passport, a utility bill, a bank statement, and a brief note saying "PEP reviewed — relationship approved" is not EDD. It is standard CDD with a label. Regulators have become increasingly explicit about this: EDD must contain substantive analysis, not just additional documents.
What a valid EDD file contains: a narrative account of who the client is and their business history; source of wealth analysis with supporting evidence (not just a declaration form); the specific risk factors that triggered EDD and how they were assessed; the senior compliance officer or MLRO approval record with date and basis for the decision; and an ongoing monitoring note confirming the EDD will be refreshed at defined intervals.
A VASP has a Travel Rule policy document that describes how it will collect and transmit originator and beneficiary data. The policy is well-drafted and references FATF Recommendation 16 correctly. The VASP has never transmitted Travel Rule data to a counterparty VASP. No Travel Rule solution is integrated. When a regulator asks for transmission logs, there are none.
Why this is treated as a fundamental failure: the Travel Rule is a legal obligation, not a target. Having a policy that describes compliance but no operational implementation is — from the regulator's perspective — worse than having no policy, because it demonstrates that the firm is aware of the obligation and has chosen not to implement it. This is the framing that leads to formal enforcement rather than a remediation notice.
The VASP has a designated MLRO or compliance officer. That person's name appears on the licence application and the AML policy document. In practice, they have no access to transaction data, have not reviewed any TMS alerts, have not signed off on any EDD files, and have not filed or reviewed any SAR decisions. They are a named individual with no documented compliance function.
The regulatory consequence: a compliance officer with no documented authority and no evidence of operational function is treated as a governance failure at the licence level — not a staffing oversight. VARA, the FCA, and AIFC all require the compliance officer to be genuinely empowered to perform the function. "Genuinely empowered" means access to systems, documented sign-off authority, evidence of regular reporting to the board or senior management, and records of decisions made.
WCR Legal works with VASP and CASP licence holders on AML/KYC programme assessments — identifying operational gaps against current inspection standards before regulators do. We focus on what the evidence shows, not what the policy says.
