Written for the analyst with a live decision, not the project team
Most crypto compliance content is written for the person managing the FSMA authorisation project. This is written for the person who has to make a real decision on a real customer before that project finishes. Those are different jobs, and the timeline that matters for one is not the timeline that matters for the other.
What counts as a cryptoasset, in terms that actually matter to you
Skip the blockchain explainer. For a working analyst, a cryptoasset is defined by what triggers a regulatory duty, not by how the technology functions underneath. Under the Money Laundering Regulations, a cryptoasset is a cryptographically secured digital representation of value or contractual rights, transferable and storable electronically. The definition is wide on purpose: exchange tokens, stablecoins, and a broad range of digital assets all sit inside it. The operative question is never really is this crypto, it is does dealing in this trigger a registration duty.
Owning crypto and dealing in crypto are two different questions
These get conflated constantly, and the conflation causes real onboarding mistakes. An individual holding cryptoassets personally, in their own wallet, for their own account, triggers no FCA registration duty at all. Ownership is unregulated.
The duty attaches to the business providing the service, not the person holding the asset. Exchange cryptoassets for money or other cryptoassets by way of business, or safeguard cryptoassets or the private keys controlling them on behalf of customers, and you are a cryptoasset exchange provider or custodian wallet provider under the Money Laundering Regulations. That duty has been in force since 10 January 2020. Nothing about that changes this year.
Two regimes are live at once right now, and that is the actual complication
| Regime | Status now | What it covers | Key date |
|---|---|---|---|
| MLR registration | In force, has been since 2020 | AML and counter terrorist financing supervision only | Ongoing |
| FSMA cryptoasset authorisation | Application gateway opens 30 September 2026 | Full financial services authorisation, stablecoin issuance, safeguarding, arranging deals, staking | Regime commences 25 October 2027 |
Registration under the MLRs does not convert into FSMA authorisation, and does not guarantee it. A firm correctly registered and supervised since 2020 still has to make a fresh case under the new regime. This is not a formality layered on top of what already exists, it is a separate gate.
The AML and sanctions obligations that sit underneath both regimes
A registered cryptoasset business carries the core MLR duties any MLR-regulated firm carries, though exactly how those duties apply varies by the specific regulated activity the firm performs: a business wide risk assessment, customer due diligence and enhanced due diligence where warranted, ongoing transaction monitoring, staff training, and suspicious activity reporting. Sanctions and PEP screening sit under a separate regime, UK financial sanctions law, not the MLRs, and that obligation applies regardless of MLR registration status. Either way, the firm needs an MLRO who genuinely understands cryptoassets, not a traditional finance background stretched thin to cover it.
The Travel Rule, the one obligation that is genuinely crypto specific
Part 7A only applies to a defined "cryptoasset transfer"
Regulation 64B defines this narrowly: either a transfer between cryptoasset businesses, or an unhosted wallet transfer as defined there. Not every movement of a cryptoasset on a blockchain is a "cryptoasset transfer" for Part 7A purposes.
Two transfer types are excluded entirely, not by value
Regulation 64A(2) excludes transfers within Article 3.9 of the funds transfer regulation. Regulation 64A(3) excludes transfers where both the originator and the beneficiary are cryptoasset businesses acting on their own behalf. Neither exclusion depends on the transfer's value.
Base originator and beneficiary information travels with every covered transfer, no threshold
Regulation 64C(1) and (5) require the originator's business to attach both parties' names, the registered or trading name of any party that is a firm, and account numbers or a unique transaction identifier for both originator and beneficiary. No monetary threshold applies, and the transfer must not proceed without it. A narrow batch-file exception under Regulation 64C(7) lets qualifying transfers to a beneficiary business operating wholly outside the UK carry this information at the batch level instead of on every constituent transfer.
Extra verification-grade information runs on two separate routes, not one threshold
If every cryptoasset business executing the transfer operates in the UK, the beneficiary's business can request the further Regulation 64C(6) information and must receive it within three working days, no threshold on this route (Reg 64C(2)). If not every executing business is UK-based, that further information must automatically accompany the transfer once it, aggregated with linked transfers, reaches ยฃ800 (Reg 64C(4), amended from EUR 1,000 by SI 2026/621 reg 32, effective 30 June 2026). For an individual originator, paragraph (6) asks for one of: a customer identification number, an address, an identity document number, or date and place of birth (alternatives, not a checklist to satisfy in full).
Unhosted wallet transfers run under their own rule, with their own ยฃ800 threshold
A transfer to or from an unhosted wallet is itself a defined "cryptoasset transfer" under Regulation 64B, not a gap in the regime. With no receiving business to exchange full Part 7A information with, Regulation 64G instead lets the firm request specified information from its own customer, with enhanced information required once the transfer meets ยฃ800 (Reg 64G(1)(b), amended from EUR 1,000 by the same SI 2026/621, reg 33), a separate threshold from Reg 64C(4)'s, not the same provision. This is where most real friction sits.
Since 1 September 2023, Part 7A of the Money Laundering Regulations has applied this regime to every cryptoasset transfer within Regulation 64B's definition, unless a Regulation 64A(2) or (3) exclusion applies. Whether Part 7A applies at all does not depend on value, only specific additional-information elements within it do, and those run on different rules depending on where the businesses involved are based. It is the direct crypto equivalent of correspondent banking information requirements.
Why crypto KYC does not map cleanly onto a traditional onboarding checklist
From 1 February 2027, Regulation 34A introduces a specific enhanced due diligence requirement for cryptoasset exchange providers and custodian wallet providers that have, or propose to have, a correspondent relationship with a similar provider based in a third country, mirroring the correspondent banking EDD model: understanding the respondent's business, assessing its reputation and supervision quality from credible public sources, and assessing its AML/CTF controls. It does not create a general rule about unhosted wallets or lower transparency jurisdictions across the board, those remain matters for the firm's own risk-based judgement outside this specific correspondent relationship gateway.