A crypto compliance audit is an independent, risk-based assessment of whether a digital asset business's compliance controls are suitably designed and working as intended. It goes beyond reading policies. Auditors trace risks to controls, inspect evidence, test selected transactions or cases, evaluate exceptions and confirm that weaknesses are corrected.
The work may cover customer due diligence, transaction monitoring, sanctions, the Travel Rule, suspicious activity reporting, custody, wallet governance, third parties, DeFi exposure and operational resilience. The exact scope depends on the firm's activities, jurisdictions, customers, products, delivery channels and risk profile.
This guide explains how to build a practical audit that gives management and the board reliable assurance. It is educational rather than legal advice. Firms should confirm the rules and guidance that apply to their particular business and locations.
What is a crypto compliance audit?
A crypto compliance audit methodically compares a firm's obligations, policies and risk appetite with what happens in practice. Its purpose is to answer three questions:
1. Are the right controls designed for the risks?
2. Have those controls been implemented?
3. Do they operate effectively and produce reliable evidence?
The third question matters. A policy might require all high-risk customers to receive enhanced due diligence, yet files may lack source-of-funds evidence or approval. Equally, staff may perform a control every day, but the control may fail to cover a supported blockchain or customer segment. Performance alone does not cure poor design.
Compliance audits are not all the same
These reviews can inform one another, but none automatically replaces another. A clean smart-contract review does not show that CDD is effective. A reserve attestation does not prove that sanctions alerts are investigated. Clear terminology helps boards understand what assurance they have actually received.
Why crypto compliance controls require specialist testing?
Traditional audit principles still apply, but crypto changes the evidence, systems and risk pathways.
First, activity is split between on-chain records and off-chain systems. An auditor may need to connect a blockchain transaction to a customer, account, device, case, approval and regulatory decision. A block explorer proves that a transaction occurred; it does not by itself establish the customer's identity, economic purpose or the firm's decision-making.
Second, controls depend heavily on data and vendor attribution. A transaction-monitoring tool may assign risk to a wallet based on clustering, typologies and external intelligence. Auditors must understand coverage, data lineage, version changes and the firm's use of vendor output. Purchasing a recognised tool is not evidence that it is configured appropriately.
Third, settlement can be fast and irreversible. Key compromise, address substitution or an approval failure can cause immediate loss. Preventive controls over wallets and signing may therefore deserve more attention than a later detective review.
Finally, crypto products change quickly. New chains, bridges, tokens, staking services, DeFi protocols or self-hosted-wallet flows can create gaps between the approved business model and the controls actually deployed.
The regulatory context for crypto compliance auditing
Audit criteria must be jurisdiction-specific. A global standard or vendor setting should not be treated as law in every market.
United Kingdom
The FCA states that it supervises UK cryptoasset businesses for AML/CTF under the Money Laundering Regulations 2017. In-scope businesses must register before providing relevant services in the UK and must comply with the MLRs. The FCA describes its supervisory approach as risk-based. See the FCA's cryptoassets AML/CTF regime.
Regulation 21 of the MLRs requires an in-scope relevant person, where appropriate to the size and nature of its business, to establish an independent audit function that examines and evaluates the adequacy and effectiveness of its AML policies, controls and procedures and makes recommendations. The applicability and proportionality assessment should be documented rather than assumed.
The UK Travel Rule has applied to relevant cryptoasset transfers since 1 September 2023. The FCA says firms remain responsible for compliance even when using third-party suppliers and should adapt processes as implementation develops across jurisdictions. See the FCA's updated Travel Rule expectations.
As of 3 September 2026, the FCA says the new UK cryptoasset regime is expected to take effect on 25 October 2027. Firms should distinguish current obligations from future requirements and monitor transition material. See the FCA's new cryptoasset regime.
United States
Whether a US crypto business is an MSB depends on its activities and the applicable definitions. For covered money services businesses, 31 CFR 1022.210 requires a written, risk-commensurate AML programme with internal controls, a designated compliance person, training and independent review. The review's scope and frequency must be commensurate with risk, and the reviewer cannot be the person designated for day-to-day compliance. See the official eCFR Part 1022.
European Union and global standards
EU cryptoasset service providers may need to consider MiCA, the EU Transfer of Funds Regulation and EBA guidance, alongside national supervisory expectations. The EBA's Travel Rule guidelines apply from 30 December 2024 and address missing or incomplete information and the procedures needed to detect and manage affected transfers. See the EBA Travel Rule guidance.
FATF Recommendation 15 provides an important global reference for virtual assets and VASPs, but FATF standards need national implementation. In July 2026, FATF reported continued progress alongside significant gaps in effective implementation and highlighted risks involving fraud, stablecoins, unhosted wallets, offshore VASPs and DeFi. See FATF's 2026 targeted update.
The audit file should identify which criteria are law, regulatory rules, formal guidance, internal policy or industry practice. That distinction prevents an auditor from presenting a recommended enhancement as a statutory breach.
What should a crypto compliance audit cover?
A risk assessment should drive scope. The following domains form a useful audit universe, but not every review needs to test all of them.
How to perform a crypto compliance audit
The IIA's Global Internal Audit Standards organise engagement work around effective planning, conducting work, communicating results and monitoring action plans. A crypto-specific programme can use the same disciplined lifecycle.
1. Define the mandate, objective and independence
Start by agreeing why the audit is being performed and who will rely on it. The objective may be annual independent AML review, board assurance, readiness for a regulatory application, post-incident testing or targeted assurance over a new product.
Document the reviewer's authority, access to systems and people, reporting line, competence and conflicts. Independence does not always require an external firm, but the reviewer should not test their own work or own the day-to-day control they assess. Where specialist blockchain, sanctions or cybersecurity skills are needed, define how experts will support the engagement.
2. Build the audit universe and risk-based scope
List the relevant legal entities, licences or registrations, products, customer types, jurisdictions, tokens, chains, wallets, systems, vendors and outsourced processes. Then compare that universe with the firm's risk assessments and previous audits.
Scope should prioritise the areas with the greatest inherent risk, significant change, control concerns, overdue actions or regulatory importance. A new cross-chain service, for example, may deserve attention even if transaction volume is still modest because its controls have not been proven.
Record what is excluded and why. A clearly bounded audit is more credible than a broad label that creates false assurance.
3. Set criteria and map risks to controls
For each objective, identify the applicable requirement or expectation. Then map the risk, control objective, control owner, frequency, system, evidence and testing approach.
A useful risk-control matrix should answer:
4. What could go wrong?
5. Which control prevents or detects it?
6. Who performs and reviews the control?
7. How often does it operate?
8. What population does it cover?
9. What evidence should exist?
10. Which criterion makes the control necessary?
Avoid copying a generic controls library without reconciling it to the business model. Controls for a retail exchange, institutional custodian and DeFi-facing fintech will not be identical.
4. Perform walkthroughs and test control design
Walk through real examples from beginning to end. For onboarding, follow a customer from application through identity checks, risk rating, screening, approvals and account activation. For monitoring, trace an on-chain transfer through data ingestion, risk scoring, alert creation, investigation and any reporting decision.
Ask the person who performs the control to demonstrate it in the live or controlled environment. Compare the demonstration with the procedure, system configuration and evidence. Walkthroughs often expose undocumented workarounds, manual hand-offs and mismatches between teams.
Conclude whether the control is designed to address the stated risk. If it cannot do so, testing more samples will not make it effective.
5. Test operating effectiveness
Operating-effectiveness testing asks whether the control ran as designed, consistently, throughout the period and by an authorised person.
Define the population before selecting samples. Examples include all high-risk customers approved during the period, all alerts closed without escalation, all additions to supported assets, or all emergency wallet-access events. Reconcile the population to an independent source where possible.
Select items using a method suited to the risk. Combine random selection with targeted items such as high values, high-risk jurisdictions, unusual assets, manual overrides, late cases and known incidents. Document why the sample supports the conclusion; do not imply statistical assurance when using a small judgemental sample.
6. Use data analysis without losing professional judgement
Data analysis can test entire populations for missing fields, late reviews, duplicate identifiers, thresholds, alert backlogs or unsupported assets. On-chain analytics can identify exposure patterns and compare internally recorded activity with public-ledger data.
However, an automated test is only as reliable as its inputs and logic. Validate field definitions, timestamps, time zones, joins, exclusions and extraction dates. Preserve the query or procedure so another reviewer can reproduce the result.
7. Evaluate exceptions and reach conclusions
An exception is not automatically a finding. Confirm the facts with the control owner, determine whether the exception is isolated or systemic and assess its cause, consequence and wider population impact.
Consider whether compensating controls reduced the risk. Then decide whether more testing is needed. One failed sanctions escalation could justify expanding the sample if it suggests a recurring configuration or training issue.
Conclusions should address the audit objective, not merely count passed samples. A 95% pass rate may still be unacceptable if the failed item involved a material sanctions exposure or an unauthorised wallet transfer.
8. Report findings clearly
A useful finding sets out the criterion, condition, cause, consequence and agreed action. It distinguishes confirmed facts from potential risk and avoids dramatic language.
The report should explain the scope, period, methodology, limitations and overall conclusion. Prioritise issues using a defined rating method, but do not let a colour replace analysis. Boards need to understand the risk, why the control failed and what management will do.
Read the supporting guide on documenting and remediating crypto compliance audit findings for a detailed method.
9. Validate remediation and close the issue
An action is not complete because a new policy has been uploaded. Inspect the changed control, confirm implementation and test evidence that it now operates. For a revised monitoring rule, this may involve configuration review, back-testing and a sample of new alerts.
Track owners, milestones, dependencies, due dates and overdue risk acceptance. Escalate repeated extensions or residual risk outside appetite. Closure should be based on evidence, not assertion.
How to test design and operating effectiveness?
The distinction can be summarised simply:
11. Design effectiveness: If the control operates exactly as described, is it capable of reducing the risk to an acceptable level?
12. Implementation: Has the designed control actually been put in place?
13. Operating effectiveness: Did the implemented control operate consistently, by the right people, using reliable information, during the review period?
Consider a rule that alerts when a customer sends funds directly to a sanctioned address. The rule may be implemented and may alert correctly for direct exposure. However, if the firm's risk assessment requires detection of indirect exposure and the rule cannot identify it, the design may be inadequate. Conversely, a well-designed rule may fail operationally if one blockchain was never connected to the monitoring tool.
Testing should therefore cover the control's objective, logic, inputs, coverage, performer, reviewer, frequency, evidence and response to exceptions.
Evidence and sampling in a crypto environment
Good evidence is relevant, reliable and sufficient for the conclusion. Stronger evidence often comes directly from systems, independently generated records or reperformance. Screenshots can help, but they may omit filters, dates, context or later changes.
Typical evidence includes:
14. policy and procedure versions;
15. risk assessments and approval records;
16. system configurations and change logs;
17. complete customer, transaction, alert or wallet populations;
18. case notes and supporting documents;
19. blockchain transaction hashes and address records;
20. vendor data dictionaries and coverage statements;
21. access logs, signing records and reconciliation reports;
22. committee minutes and management information; and
23. remediation tickets and closure-test results.
Protect personal data, SAR confidentiality, private-key material and security-sensitive information. An audit team rarely needs seed phrases or private keys. Evidence requests should be proportionate and handled through approved secure channels.
For financial-audit-related considerations, ICAEW's cryptocurrency audit guide highlights the importance of understanding wallets, custody, blockchain-data reliability, third parties and management controls. A compliance audit can use those questions where relevant while keeping its own objective clear.
A practical crypto compliance audit example
Hypothetical example: A UK crypto exchange adds two new blockchain networks and enables withdrawals to self-hosted wallets. Internal audit scopes transaction monitoring, sanctions screening and Travel Rule controls for the first three months after launch.
The walkthrough shows that customer and transaction data reach the case-management platform. However, the chain inventory reveals that one network is screened before withdrawal but is not included in post-transaction behavioural monitoring. The approved launch checklist marked monitoring as complete because the team tested only direct wallet screening.
The auditor records a design and governance weakness: the launch control did not require separate confirmation of screening, behavioural monitoring and Travel Rule coverage. Data analysis identifies the affected transaction population. Compliance performs a retrospective review, technology connects the missing feed and product governance revises the launch checklist. Internal audit then validates the data connection, back-testing and new control evidence before closure.
This example shows why a crypto compliance audit should connect product governance, system coverage, data and case outcomes rather than reviewing each in isolation.
Common crypto compliance audit findings
The following weaknesses recur across financial crime and digital asset environments:
24. risk assessments do not match live products, chains, geographies or customer types;
25. policies are generic, contradictory or not followed in practice;
26. CDD and EDD decisions lack evidence or clear differentiation;
27. monitoring scenarios have weak rationale, incomplete coverage or little tuning;
28. alert backlogs and quality issues are hidden by high-level metrics;
29. vendor risk scores are accepted without internal challenge;
30. sanctions list feeds, wallet screening or escalation procedures are not tested;
31. Travel Rule exceptions are not consistently risk-assessed;
32. wallet inventories, access rights or approval thresholds are outdated;
33. on-chain balances do not reconcile cleanly to internal records;
34. third-party assurance is collected but not evaluated against the service used;
35. audit actions close on policy changes without testing operation; and
36. management information reports activity but not control effectiveness.
The FCA's April 2026 CDD review reported examples including insufficiently detailed policies, undefined review cycles, failure to follow procedures and weak evidence of EDD. Its May 2026 sanctions controls review discussed weaknesses in risk assessments, coverage, third-party reliance, screening configuration and assurance testing. Although those reviews were not limited to crypto firms, their themes are useful audit prompts.
How to make the audit programme sustainable?
A one-off audit can identify problems, but a sustainable assurance programme connects change to future testing.
Maintain an auditable inventory of products, chains, assets, wallets, systems and key vendors. Link material changes to risk assessment, compliance approval and control testing. Use a rolling audit universe so that high-risk domains receive the right frequency and specialist skills.
Track a small set of meaningful indicators. Examples include overdue high-risk reviews, alert ageing, quality-assurance failure rates, unmonitored transaction value, unresolved reconciliation breaks, unsupported asset exposure, Travel Rule exception rates and overdue critical actions. Define each metric so that changes can be explained.
Finally, share lessons across the three lines. Operations own controls, compliance provides oversight and challenge, and internal audit gives independent assurance. Clear boundaries reduce duplication and preserve independence while allowing each team to use relevant evidence.
Frequently asked questions
What does a crypto compliance audit examine?
It examines whether the firm's compliance framework is appropriate for its risks and whether controls operate effectively. Scope may include governance, risk assessment, CDD, sanctions, transaction monitoring, blockchain analytics, Travel Rule processes, reporting, custody, third parties and remediation.
How often should a crypto compliance audit be performed?
There is no safe universal frequency. The timetable should reflect applicable law, regulatory expectations, the firm's risk profile, previous findings and material change. Some US MSBs, for example, must ensure the independent review's scope and frequency are commensurate with risk under 31 CFR 1022.210.
Who can conduct an independent crypto AML review?
The answer depends on the applicable regime. A suitably skilled internal employee or external provider may be acceptable in some circumstances, but the reviewer should be independent of the activity tested and free from conflicts. Confirm local requirements and document competence and independence.
What is the difference between control design and operating effectiveness?
Design asks whether the control could address the risk if performed correctly. Operating effectiveness asks whether it actually ran as designed, consistently and with reliable evidence during the period. Both are needed for a strong assurance conclusion.
Can blockchain data replace traditional audit evidence?
No. Blockchain data can provide strong evidence of recorded on-chain activity, but it may not identify the customer, explain business purpose, prove legal ownership or show the firm's approvals and decisions. Auditors usually need to connect on-chain and off-chain records.
Does using a well-known blockchain analytics tool prove compliance?
No. The firm remains responsible for coverage, configuration, thresholds, investigation and response. Auditors should test how the tool is integrated and used, not merely confirm that a licence exists.
How long does a crypto compliance audit take?
Duration depends on scope, entities, systems, transaction volume, evidence quality and issue complexity. A narrowly scoped control review may take weeks, while a multi-jurisdictional programme audit can take longer. Define scope and information needs before estimating.
Is a crypto compliance audit legal advice?
No. An audit assesses controls against defined criteria. Legal counsel may be needed to interpret novel products, jurisdictional reach or uncertain obligations.
Build practical crypto compliance audit skills
Strong assurance requires more than a checklist. Auditors and control teams need to connect regulation, governance, customer controls, on-chain monitoring, custody and evidence into one defensible testing approach.
The Crypto Compliance Audit and Testing for Internal Control Teams course is designed for professionals who want to develop their knowledge of crypto compliance auditing, internal control testing, AML controls, blockchain analytics, transaction monitoring, Travel Rule compliance, sanctions assurance, custody controls and emerging digital asset risks.
Explore the course to continue developing practical crypto compliance audit skills.
