CCAS Study Guide | Cryptoasset AFC Concepts and Cases

CCAS Guide: Cryptoasset Mechanics, Financial Crime Standards, and AFC Controls

ACAMS describes the Certified Cryptoasset AFC Specialist as a credential for professionals managing financial crime risk involving cryptoassets and digital assets. This guide is intended for AML, compliance, blockchain analytics, law-enforcement, regulatory, and digital-asset risk practitioners.

For the established CCAS exam, ACAMS states a format of 100 questions in 175 minutes and currently lists English as the exam language. ACAMS has announced redesigned materials and an exam for 19 November 2026, so candidates should confirm which version applies when booking.

The guide moves from blockchain transactions and custody through virtual-asset standards to risk assessment, monitoring, investigations, reporting, and control testing. It treats international standards, applicable local law, institutional policy, and good practice as distinct sources of requirements.

Study scope and priorities

Area	Coverage	Study priority
Cryptoassets and blockchain	Transactions, wallets, exchanges, stablecoins, DeFi, NFTs, smart contracts, and custody.	Editorial priority: establish how value moves before interpreting a risk signal. No official domain weight is asserted.
AML foundations for cryptoassets and blockchain	FATF standards, VASP status, transfer information, sanctions, predicate crime, and jurisdiction.	Editorial priority: map each expectation to the activity, entity, transaction, and governing jurisdiction. No official domain weight is asserted.
Risk management programmes for cryptoassets and blockchain	Risk assessment, onboarding, screening, analytics, monitoring, investigations, reporting, governance, and testing.	Editorial priority: practise decisions that combine on-chain and off-chain evidence. No official domain weight is asserted.

60 core concepts 1-10

1. A blockchain records state transitions

Cryptoassets and blockchain

A blockchain transaction proposes a change to a network's recorded state, such as moving spendable value or calling a contract. The visible record shows accepted instructions and resulting state under that chain's rules; it does not itself explain the economic purpose or identify the human actor. Start analysis with the chain, asset, transaction identifier, block, and relevant addresses, then distinguish directly observed facts from interpretations. ACAMS frames these mechanics as part of CCAS preparation.

Applied example: A customer sends tokens to an unfamiliar address. An analyst records the transaction hash, token contract, chain, amount, and confirmation status before asking the customer who controls the destination.

Common mistake: Treating a blockchain entry as a complete payment narrative confuses a technical state change with identity and purpose. Recover those facts from customer, exchange, and other off-chain records.

2. Consensus and settlement confidence

Cryptoassets and blockchain

Consensus rules determine which proposed transactions enter a valid chain history. Confirmation count, validator design, and the possibility of reorganisation affect how confidently a recipient can treat a transfer as settled. An AFC team should record the chain-specific status at the decision time and define when to credit, release, or investigate funds. A transaction observed in a mempool may never be included, while one in a block can still face chain-specific reversal risk.

Applied example: A platform sees a large deposit broadcast on a chain with recent reorganisations. It records the pending transaction but delays customer credit until its documented confirmation condition is met.

Common mistake: Calling every broadcast transaction final can release value before settlement. Apply a chain-specific confirmation rule and preserve the time and block height used for the decision.

3. UTXO and account-based tracing

Cryptoassets and blockchain

Unspent transaction output systems consume earlier outputs and create new ones; account-based systems update balances and may execute contract calls. The difference changes what a trace means. In a UTXO transaction, one output may be change returned to the sender, whereas an account transaction can trigger several token movements through logs. Select the correct ledger model before labelling a recipient, calculating exposure, or explaining a transfer path to an investigator.

Applied example: A bitcoin payment creates two outputs. The analyst compares output amounts, address history, and later spending before tentatively identifying one output as change and tracing the merchant payment separately.

Common mistake: Assuming every UTXO output is a third-party payment inflates counterparties. Change identification is an inference that should be documented with its supporting indicators and remaining uncertainty.

4. Keys, addresses, and control

Cryptoassets and blockchain

A private key or signing arrangement authorises transactions; an address is a destination or account identifier derived within a chain's design. Knowing an address does not establish who can sign for it. Control may rest with one person, a custodian, a multisignature group, or a smart contract. For a risk decision, separate evidence of address use from evidence of signing authority, beneficial ownership, and the customer's stated relationship to the wallet.

Applied example: A customer supplies a deposit address for a regulated exchange. The analyst recognises that the customer may use the address while the exchange controls the keys and requests account-level evidence.

Common mistake: Equating address possession with legal ownership misstates control. A screenshot or small test transfer may show access, but neither alone establishes the full custody arrangement.

5. Wallets are arrangements, not single objects

Cryptoassets and blockchain

A wallet may be software, hardware, a custodial account, or a signing service that manages keys and transaction instructions. Its risk depends on who controls keys, who can freeze or reverse an internal ledger entry, and whether customer balances map to distinct on-chain addresses. Document the arrangement before applying a control intended for a self-hosted wallet. The same user interface can conceal materially different custody and recovery models.

Applied example: Two customers say they use mobile wallets. One signs locally with a recovery phrase; the other holds an account at a custodian. The onboarding team assigns different evidence and control questions.

Common mistake: Treating a wallet brand as proof of self-custody overlooks account-based services. Ask who signs, who holds the keys, and what happens if account access is lost.

6. Fees, gas, and transaction intent

Cryptoassets and blockchain

Network fees pay for inclusion or execution and can change with congestion or computational work. A transaction's native-asset amount may therefore be only a fee, while its economically relevant value moves as a token or contract event. Inspect input data, logs, and asset units before ranking a transfer by value. Unusual fee patterns can warrant inquiry, but a high fee alone does not prove laundering or a particular predicate crime.

Applied example: A transfer shows little native coin leaving a customer's account but a large stablecoin movement in the event log. The analyst values the stablecoin transfer and records gas separately.

Common mistake: Using only the native-coin field can miss the actual transfer. Read contract events and asset decimals, then check that the event represents an executed movement.

7. Pending transactions and nonce order

Cryptoassets and blockchain

On account-based chains, a nonce helps order a sender's transactions and prevents the same signed instruction from being replayed in the ordinary sequence. Pending transactions can be replaced or fail, so a monitoring decision should distinguish broadcast, inclusion, and execution success. This matters when a customer claims a payment occurred or when a screening alert arises before settlement. Preserve the transaction status seen at each operational step.

Applied example: A user submits a withdrawal, then replaces it with a higher-fee transaction to another address. Operations checks the confirmed nonce and recipient before closing the original alert.

Common mistake: Reading the first broadcast hash as the completed withdrawal may attach risk to the wrong destination. Reconcile replacement transactions and final execution status before concluding.

8. Token contracts and transfer events

Cryptoassets and blockchain

A token can be represented by a contract whose code and state govern balances, transfers, minting, and administrative powers. The contract address and chain identify the asset more reliably than a ticker, which can be copied. Analysts should check whether a transfer event corresponds to a successful transaction and whether token behaviour changes the apparent flow. Contract upgrades, freezes, or transfer taxes can alter the risk and the amount actually received.

Applied example: A customer reports receiving a familiar stablecoin ticker. The investigator verifies the chain and contract address, discovers a lookalike token, and avoids treating its nominal balance as equivalent value.

Common mistake: A ticker match does not authenticate an asset. Verify the contract and execution result, especially when a fraudulent token imitates a widely used name.

9. Exchange deposits and internal ledgers

Cryptoassets and blockchain

A centralised exchange can assign deposit addresses while recording customer entitlements on an internal ledger. Once funds enter an omnibus wallet, public-chain tracing may show the exchange's subsequent movements rather than the individual customer's trade or withdrawal. An investigation therefore needs exchange account records, timestamps, and transaction identifiers where available. Distinguish an on-chain transfer to a service from an off-chain allocation inside that service.

Applied example: Funds reach an exchange deposit address and later leave its hot wallet. The analyst records the service attribution but does not assign the later withdrawal to the same customer without exchange records.

Common mistake: Following an exchange hot wallet as if it were one customer's wallet creates false continuity. Internal ledger records are needed to bridge that attribution gap.

10. Custody segregation and operational risk

Cryptoassets and blockchain

Custody design affects both asset protection and financial crime visibility. Segregated addresses may simplify some tracing, while omnibus custody can require reliable internal allocation records. Hot wallets, cold storage, key ceremonies, and withdrawal approvals also shape the risk of unauthorised transfers. An AFC assessment should connect these mechanics to reconciliation, access controls, and incident evidence rather than assume that on-chain transparency compensates for weak internal records.

Applied example: A custodian sweeps deposits into one treasury wallet. The reviewer tests whether each sweep can be reconciled to the customer ledger and whether withdrawal approvals are attributable.

Common mistake: Calling pooled custody inherently opaque misses the role of internal records. The control question is whether allocations, approvals, and exceptions can be reconstructed and tested.

60 core concepts 11-20

11. Self-hosted wallet exposure

Cryptoassets and blockchain

A self-hosted wallet is controlled outside an intermediary's custodial account, but its address alone does not reveal the controller. Risk assessment can use transaction history, customer declarations, proof of control where appropriate, and the purpose of the transfer. The applicable information or verification duty depends on jurisdiction, direction, amount, and service role. Do not collapse a wallet-type classification into a conclusion that every transfer is illicit or unidentified.

Applied example: A customer withdraws to a new self-hosted address. The platform checks relevant screening results, asks for the transaction purpose under its risk rules, and records the customer's declared control.

Common mistake: Treating every self-hosted address as anonymous and prohibited discards useful evidence. Equally, a signed message proves key access at a time, not the complete beneficial ownership story.

12. Stablecoin design and redemption

Cryptoassets and blockchain

Stablecoins seek a reference value through different reserve, collateral, or algorithmic designs. Their legal claims, redemption routes, issuer powers, and depegging risks differ. AFC analysis should identify the token contract, issuer or operator, mint and burn process, and available freeze functions before assuming a transfer has the same risk profile as bank money. The reference currency is a pricing target, not proof of an enforceable redemption claim.

Applied example: A firm considers accepting a dollar-referenced token. The analyst compares issuer redemption terms, reserve disclosures, chain availability, and freeze powers before selecting monitoring and exposure limits.

Common mistake: Calling all dollar-pegged tokens equivalent obscures issuer and contract risk. Check who can redeem, on what terms, and whether on-chain supply changes reconcile with the arrangement.

13. Minting, burning, and supply flows

Cryptoassets and blockchain

Minting creates token units, while burning removes units from circulation under a contract's rules. These events can reflect legitimate issuance and redemption, bridging, collateral mechanics, or misuse of privileged functions. Trace the authorising address, contract role, related off-chain instruction, and subsequent distribution. An analyst should not count a mint as incoming customer funds without checking whether corresponding value was received and who had authority to create the tokens.

Applied example: A stablecoin issuer mints tokens to a treasury wallet after a customer subscription. Compliance reconciles the issuance request, reserve movement, authorised signer, and later transfer to the customer.

Common mistake: Assuming every large mint is suspicious ignores ordinary issuance. Assuming every mint is backed is equally weak; verify authorisation and supporting financial records.

14. Bridges and cross-chain movement

Cryptoassets and blockchain

A bridge may lock an asset on one chain and issue a representation on another, or move value through liquidity and message-passing arrangements. Tracing across chains requires matching the actual mechanism, event identifiers, amounts, timing, and bridge records. A new destination address may have no obvious public link to the source user. Record confidence and gaps rather than treating a bridge label as proof that a specific recipient owns both sides.

Applied example: Funds enter a bridge contract on Chain A and a wrapped token appears on Chain B. The investigator matches message identifiers and amounts before extending the trace to the receiving address.

Common mistake: Connecting two similar-sized transfers solely by timing can join unrelated users. Use bridge-specific events or service records and state the remaining attribution uncertainty.

15. Liquidity pools and swaps

Cryptoassets and blockchain

A decentralised exchange pool exchanges assets according to contract rules and available liquidity. A swap can change asset type without changing the user's underlying economic control, but routers, aggregators, and pooled reserves complicate a simple input-to-output trace. Analyse transaction call paths, event logs, received amounts, and slippage. A pool's participation does not by itself identify every liquidity provider as a counterparty to the customer's transaction.

Applied example: A customer swaps an asset through an aggregator that uses two pools. The analyst reconstructs each executed leg and the final received token before calculating the customer's exposure.

Common mistake: Assigning a customer's risk to every pool participant confuses shared liquidity with direct dealing. Follow the executed swap path and keep service exposure distinct from identity attribution.

16. Smart-contract permissions

Cryptoassets and blockchain

Smart contracts can encode transfers, collateral, governance, and administrative powers. Read the function actually called, the caller's permissions, and relevant state changes before describing a transaction. Upgrade keys, pause roles, and token allowances may create control or theft risks even when the contract's marketing describes it as decentralised. Code-level observations inform the risk assessment, while legal classification still requires analysis of the people and activities behind the service.

Applied example: A protocol claims immutable operation, but an administrator can upgrade its withdrawal contract. The reviewer records that power, its signers, and the effect on customer asset and screening controls.

Common mistake: Equating deployed code with absence of human control misses privileged roles. Conversely, an admin key alone does not settle every regulatory definition; examine what its holder actually does.

17. NFTs and economic substance

Cryptoassets and blockchain

A non-fungible token records a distinct token identifier, but its rights, market liquidity, and financial crime exposure depend on the arrangement. Consider what the holder receives, who operates the marketplace, how payments settle, and whether repeated trades create artificial prices. A token's uniqueness does not automatically place it outside virtual-asset rules. Equally, a collectible label alone does not prove that a service performs a regulated financial activity.

Applied example: A marketplace shows repeated high-priced sales of one token between linked accounts. The analyst compares funding sources, fees, ownership history, and stated commercial purpose before escalating possible wash trading.

Common mistake: Treating every NFT sale as ordinary art commerce ignores settlement and market manipulation signals. Treating every NFT as a regulated virtual asset skips the required functional analysis.

18. Privacy techniques and evidence limits

Cryptoassets and blockchain

Privacy features can obscure amounts, addresses, or links between transactions, with different effects across chains and tools. A visibility gap is an evidence limitation, not proof of criminal purpose. Record what remains observable, such as entry and exit points, timing, customer activity, and service records. Risk decisions should account for legitimate privacy uses and the specific control weakness created by reduced traceability, including whether enhanced inquiry can resolve it.

Applied example: A customer receives funds after a privacy-enhancing transfer. The investigator documents the unobservable segment, gathers exchange withdrawal records, and assesses the customer's explanation against known counterparties.

Common mistake: Inferring guilt from unavailable chain detail overstates the evidence. Ignoring the blind spot is also unsound; explain how it affects confidence and which corroboration is feasible.

19. Mixers and pooled transactions

Cryptoassets and blockchain

Mixing arrangements combine or transform flows to reduce direct transaction linkage. The mechanism may be custodial, contract-based, or embedded in a coin's privacy design, and each offers different evidence. Analyse deposit and withdrawal windows, denomination rules, service attribution, and any available off-chain information. A probabilistic match can support an inquiry but should not be presented as a confirmed path or as proof that the customer intended to conceal proceeds.

Applied example: A withdrawal follows deposits to a mixing service. The analyst records the service interaction, tests plausible output links, and seeks source-of-funds records before deciding whether the pattern merits escalation.

Common mistake: A matching amount after a mixer is not a unique fingerprint. Pooling and timing collisions create alternative explanations that must appear in the case rationale.

20. Reconstructing a multi-chain journey

Cryptoassets and blockchain

A useful transaction narrative follows value through each chain, service, contract, and asset conversion while marking breaks in observable continuity. Use a chronology with transaction identifiers, amounts, exchange rates where relevant, and evidence sources. Separate direct ledger facts from inferred links and customer-level attribution. This structure helps investigators avoid double-counting wrapped assets, confusing internal exchange movements with customer actions, or treating a cluster label as a verified person.

Applied example: An analyst maps a token swap, bridge deposit, wrapped-token mint, and exchange deposit. The case timeline cites each event and flags the exchange account owner as unconfirmed.

Common mistake: A polished flow chart can conceal weak links. Label every inferred cross-chain connection and service attribution so a reviewer can reproduce or challenge the conclusion.

60 core concepts 21-30

21. Standards, law, policy, and practice

AML foundations for cryptoassets and blockchain

The FATF Recommendations set international standards that jurisdictions implement through their own laws and supervisory rules. Institutional policy may impose stricter controls, while good practice can inform design without becoming a universal legal duty. For any scenario, identify the entity, location, activity, and effective legal instrument before naming a requirement. This source hierarchy prevents a control developed for one market or business model from being presented as binding everywhere.

Applied example: A global exchange drafts a common wallet-screening standard. Its legal team then maps local licensing, reporting, and recordkeeping duties by entity rather than calling the group standard a statutory rule.

Common mistake: Citing an international recommendation as if it directly creates a filing deadline confuses standard-setting with implementation. Find the applicable domestic rule and its covered-person definition.

22. The virtual-asset regulatory perimeter

AML foundations for cryptoassets and blockchain

Determine whether an asset and activity fall within a jurisdiction's virtual-asset framework by examining function and actual service delivery. The FATF virtual-asset guidance discusses stablecoins, peer-to-peer activity, and DeFi, but its 2021 text should be read with current FATF Recommendations and local law. Labels such as NFT or decentralised do not decide the perimeter. Identify who facilitates exchange, transfer, safekeeping, or related financial activity and what control they exercise.

Applied example: A company markets an NFT platform with a built-in exchange feature. Counsel analyses the token's use, the company's control over trading, and applicable local definitions before assigning obligations.

Common mistake: Applying one blanket rule to all NFTs or DeFi protocols skips the activity test. Document the functional facts and jurisdiction-specific definition before concluding coverage.

23. Identifying the VASP role

AML foundations for cryptoassets and blockchain

A virtual-asset service provider analysis asks what business activity an entity performs for another person and whether it controls or facilitates relevant value movement. A software publisher, hosted exchange, wallet custodian, and protocol operator may have different roles even when all touch the same chain. Map contracting parties, fees, governance powers, keys, and customer touchpoints. The broader AML foundations in the CAMS guide help frame customer and transaction duties once the covered role is established.

Applied example: A team operates a swap interface, sets fees, and can change routing contracts. The assessor records those powers and customer relationships before deciding whether local VASP rules apply.

Common mistake: Calling a service decentralised because users sign transactions can miss an operator's control. Calling all software developers VASPs ignores whether they actually provide a covered service.

24. Licensing and registration mapping

AML foundations for cryptoassets and blockchain

A provider's permission to operate depends on the activities it performs and the jurisdictions where it has a regulatory nexus. Separate AML registration, prudential or market authorisation, and any passporting or notification route. Review the entity's legal structure, customers, products, and outsourced functions before concluding that one licence covers the group. Record effective dates and transitional provisions because a rule's adoption date may differ from the date it applies.

Applied example: A custody firm adds exchange services in another market. Compliance maps both activities to the relevant legal entities and checks whether existing permissions cover the new customer flow.

Common mistake: A licence in one jurisdiction is not automatic permission elsewhere. Identify the local activity and nexus, then verify the specific authorisation or exemption route.

25. MiCA scope and AML duties

AML foundations for cryptoassets and blockchain

The EU Markets in Crypto-assets Regulation addresses cryptoasset and service authorisation, conduct, and token categories. Those questions are distinct from AML obligations, even when the same firm is affected by both regimes. Examine the asset, service, entity, and any exclusion or special route before drawing a conclusion. MiCA's relevant application dates and transitional limits should be checked against the actual decision date; a prior grandfathering period should not be assumed to continue indefinitely.

Applied example: An EU firm offers custody and issues a token. Its team analyses service authorisation and token classification under MiCA, then separately maps applicable AML and transfer-information obligations.

Common mistake: Treating MiCA authorisation as proof of complete AML compliance merges different duties. Test each regime's scope, effective date, and evidence requirements separately.

26. Travel Rule information purpose

AML foundations for cryptoassets and blockchain

Transfer-information rules seek to make originator and beneficiary information available to relevant providers and authorities for eligible transfers. The data requirements, timing, thresholds, and handling of missing information depend on the applicable regime. Map both providers' roles, the transfer direction, and the jurisdiction before designing a message flow. Information exchange is distinct from identity proofing, sanctions adjudication, and the customer's underlying economic purpose, although those controls can use the same data.

Applied example: A provider receives a transfer from another service with incomplete beneficiary data. It applies the relevant local rule and risk procedure, requests correction, and records its disposition.

Common mistake: Assuming that a transmitted name proves the sender's identity overstates what the message establishes. Verify the source, required fields, and any separate customer due diligence duty.

27. Counterparty VASP due diligence

AML foundations for cryptoassets and blockchain

Before relying on another provider to exchange transfer information or handle assets, assess whether it is the actual counterparty service and whether its controls are credible. Evidence may include regulatory status, legal entity details, technical endpoints, security, data handling, and sanctions exposure. A directory label or blockchain heuristic is a starting point, not a legal identity check. Reassess when the counterparty changes ownership, product, or operating jurisdiction.

Applied example: A service proposes a new transfer-information partner. The compliance team verifies the legal entity, licence status where relevant, secure messaging endpoint, and escalation process before activating transfers.

Common mistake: A familiar brand name may cover several entities with different permissions. Tie the review to the contracting entity and actual service route.

28. EU crypto-transfer information

AML foundations for cryptoassets and blockchain

The EU transfer-information regulation applies to relevant cryptoasset transfers involving a cryptoasset service provider. It specifies accompanying information and additional conditions for certain transfers involving self-hosted addresses. Analyse the provider nexus, direction, amount, and relevant provision; a general exemption below EUR 1,000 should not be inferred for crypto-transfer information. Pure person-to-person transfers without a provider are outside this regulation's crypto-transfer scope, though other laws may still matter.

Applied example: An EU service sends cryptoassets to a customer's self-hosted address. Its team identifies the applicable information duty and checks whether the transfer's amount triggers additional ownership or control assessment.

Common mistake: Importing a threshold from another regime can erase required information. Read the EU provision for the actual transfer type and keep screening and identity proofing separate.

29. Peer-to-peer activity and risk

AML foundations for cryptoassets and blockchain

A transfer directly between self-hosted users may occur without a regulated intermediary at the transfer point. That fact affects which provider duties attach, but it does not erase risk when a customer later enters or exits a service. Assess the source of funds, known counterparties, asset history, and product exposure at the point where the institution acts. Controls should respond to evidenced risk rather than assume that every peer-to-peer transfer has the same purpose.

Applied example: A customer deposits tokens received from a direct peer-to-peer sale. The exchange reviews transaction history and the sale evidence under its onboarding and monitoring rules.

Common mistake: Calling a direct transfer legally unregulated everywhere confuses the transfer with surrounding services. Identify the covered entity and local rule at each step.

30. Sanctions nexus before screening decisions

AML foundations for cryptoassets and blockchain

A sanctions conclusion requires the relevant jurisdictional nexus, legal instrument, designated person or property interest, and prohibited activity. Screening an address or name is a detection step, not the complete legal analysis. A match may be false, stale, or linked only through uncertain attribution. Escalate plausible matches with the transaction status and evidence preserved, then apply the applicable blocking, rejection, licensing, or reporting rules for that regime.

Applied example: A withdrawal address resembles one associated with a listed actor. The team pauses the transfer under its procedure, confirms the address attribution, and assesses the governing sanctions nexus.

Common mistake: Treating a vendor risk score as a legal designation skips identity and nexus checks. A score can prioritise review but cannot supply the applicable prohibition.

60 core concepts 31-40

31. U.S. sanctions ownership analysis

AML foundations for cryptoassets and blockchain

Under OFAC's U.S. 50 Percent Rule, an entity owned 50 percent or more in aggregate, directly or indirectly, by blocked persons is itself blocked even if unnamed. Control below that threshold does not automatically block it under this ownership rule, although other restrictions or facts may matter. Trace ownership through the actual structure and document sources. Do not mechanically multiply percentages through an already blocked intermediate entity or import the U.S. test into another jurisdiction.

Applied example: Two blocked persons collectively own 55 percent of a cryptoasset firm. A U.S.-nexus reviewer assesses the ownership chain, confirms the interests, and escalates the resulting blocking analysis.

Common mistake: Calling a 30 percent controlled company automatically blocked under OFAC's ownership rule misstates that rule. Check aggregate ownership and separately analyse any other applicable restriction.

32. UK ownership and control

AML foundations for cryptoassets and blockchain

UK financial sanctions require analysis under the relevant UK regulations and guidance, including ownership and control concepts that should not be replaced with OFAC's automatic ownership test. Assess voting rights, board appointment powers, and other means of directing an entity where the applicable regime requires it. Record the evidence and legal basis for the conclusion. A cryptoasset address associated with a company does not by itself resolve who owns or controls that company.

Applied example: A UK service discovers a customer company whose minority investor is designated. The reviewer examines governance rights and actual influence under UK rules before deciding whether asset-freeze duties apply.

Common mistake: Using the U.S. 50 percent threshold as a universal UK answer can miss control or misstate coverage. Apply the UK instrument and supported facts.

33. Designations, aliases, and adjudication

AML foundations for cryptoassets and blockchain

A list match is an alert requiring identity comparison, not a final conclusion. Compare identifiers, aliases, dates, locations, corporate links, and transaction context; for wallet indicators, check attribution provenance and whether the indicator is current. The UN consolidated list identifies listed parties, while each applicable regime and domestic implementation determine measures. The CGSS guide provides a broader sanctions study path for candidates who need more depth in regime analysis.

Applied example: A customer shares a listed person's common name. The reviewer compares date of birth, location, identifiers, and corporate links, then records why the alert is or is not a match.

Common mistake: Clearing a match on name similarity alone or freezing solely because of it are both unsupported. Use discriminating identifiers and the relevant legal measure.

34. EU restrictive-measure analysis

AML foundations for cryptoassets and blockchain

EU restrictive measures arise through specific legal instruments with their own persons, prohibitions, exemptions, and territorial reach. A reviewer should identify the instrument and relevant EU nexus before deciding what a cryptoasset service may do. Ownership or control questions require support from the applicable EU text and guidance, not a borrowed U.S. or UK shortcut. Maintain a traceable legal rationale because a blockchain address label cannot describe every prohibited dealing.

Applied example: An EU exchange flags an address linked to a designated company. It confirms the link, identifies the relevant EU regulation, and assesses whether holding or transferring the assets is prohibited.

Common mistake: Assuming all sanctions lists impose the same result obscures different measures and exceptions. Cite the applicable EU instrument and the conduct it regulates.

35. Predicate crime and proceeds

AML foundations for cryptoassets and blockchain

Cryptoassets can carry proceeds from fraud, ransomware, theft, corruption, or other predicate offences, but on-chain movement alone rarely proves the underlying crime. Establish the alleged source event, affected parties, amount, timing, and connection to the assets. Then test alternative explanations, such as legitimate exchange activity or unrelated pooled funds. A defensible case narrative separates evidence of a predicate offence from evidence of subsequent layering or integration.

Applied example: Tokens arrive after a reported phishing theft and move through two swaps. The investigator links the theft report to the source transaction before characterising later transfers as possible laundering.

Common mistake: Calling every rapid swap laundering assumes both illicit origin and intent. Anchor the theory in a supported source event and explain what remains uncertain.

36. Proportionate risk treatment

AML foundations for cryptoassets and blockchain

A risk-based approach adjusts controls to evidenced exposure while preserving applicable minimum duties. FATF's financial-inclusion guidance supports proportionate measures and, where permitted, simplified measures for lower-risk situations. In cryptoasset services, assess the product, customer, geography, transaction pattern, and available safeguards before increasing or reducing friction. Alternative identification methods may help an eligible customer, but they are not the same as dispensing with customer due diligence.

Applied example: A low-value service considers access for customers lacking conventional documents. It checks local permission for alternative identification, sets suitable limits, and monitors whether the observed risk stays within assumptions.

Common mistake: Blanket exclusion of an entire customer group can be disproportionate. Blanket simplification is also weak; document the lower-risk basis and retain required checks.

37. U.S. legal duties depend on coverage

AML foundations for cryptoassets and blockchain

The U.S. Bank Secrecy Act framework and implementing rules establish duties for covered institutions and activities. A cryptoasset business must identify its actual status, services, and applicable rule before assuming a programme, record, or report is mandatory. Regulatory priorities may inform risk assessment without creating a new filing trigger by themselves. Map legal requirements to operational owners and distinguish them from voluntary institutional controls that exceed the legal floor.

Applied example: A firm launches a new payment feature. Counsel determines its U.S. regulatory status and applicable BSA obligations before compliance configures monitoring and reporting workflows.

Common mistake: Copying a bank's filing procedure into every cryptoasset firm can misstate coverage. Start with the legal classification and effective rule, then design the control.

38. Regulatory change and effective dates

AML foundations for cryptoassets and blockchain

Cryptoasset rules can be adopted, published, amended, and applied on different dates. Maintain a change log that records the legal text, effective date, affected entity, product, system, and control owner. Test transitional provisions against the specific decision date rather than rely on a historical summary. This matters when a service expands across jurisdictions or when a new transfer-information rule changes what must accompany a transaction.

Applied example: A group revises its EU cryptoasset procedures after a rule takes effect. It maps each affected entity and product, updates system fields, and records when the new workflow became operational.

Common mistake: Treating publication as immediate applicability may create false compliance statements. Conversely, relying on an expired transition can leave a live obligation unimplemented.