They should start with a risk assessment, then build a risk based compliance programme that fits their business model and local jurisdiction. The core controls are KYC and CDD, ongoing blockchain transaction monitoring, and timely SAR and STR filing. Firms also need registration and licensing, because regulators may review whether the programme is proportionate before approval.
What compliance has to cover once a crypto business becomes an obliged entity
Once a cryptocurrency business falls under 5AMLD, aml compliance is no longer a light-touch policy exercise. It becomes a regulated operating model that has to identify customers, understand the business relationship, monitor transactions, and escalate suspicious activity in a way that fits both the firm’s products and the jurisdiction where it operates. The right standard is proportionality, not minimalism.
The practical implication is that the compliance programme should be built around the actual risk profile of the business, not around a generic exchange checklist. A custodial platform, a brokerage, a fiat on-ramp, and a business that only provides wallet infrastructure can face very different customer, transaction, and reporting obligations. That is why the initial risk assessment matters: it determines what due diligence depth, monitoring intensity, and control coverage are defensible.
For the AML baseline, the business should be able to show how it collects and verifies customer information, screens for higher-risk customers or counterparties, and keeps that information current as relationships change. It should also be able to explain how it decides when enhanced due diligence is needed, how blockchain monitoring is tuned to the business model, and how suspicious activity reports or suspicious transaction reports are handled on time. Regulators generally want evidence that the programme works in practice, not just that a policy exists.
- Build customer onboarding and verification rules that match the products you actually offer.
- Document how transaction monitoring thresholds and alerts are calibrated.
- Keep escalation and reporting ownership explicit, so suspicious activity is not delayed by unclear handoffs.
For broader compliance governance, firms should treat registration, licensing, and AML control design as linked requirements. If the business cannot explain its customer base, its transaction flows, and its control choices, it is harder to defend approval or ongoing supervision. In that sense, proportionality is not a free pass, it is the standard by which the programme is judged.
Why risk-based design matters more than copying a generic AML template
A risk-based programme is the only sensible starting point because crypto businesses do not all face the same exposure. Some firms handle large volumes of retail flows, some operate cross-border by default, and some have limited visibility into where value ultimately moves after the first transaction. Those differences affect both financial-crime exposure and the cost of false positives, so the controls need to be tuned rather than copied.
That design choice affects three things most directly: the depth of due diligence, the sensitivity of transaction monitoring, and the level of governance the business can justify to regulators. A higher-risk model usually requires stronger customer screening, more aggressive alerting, better sanctions and adverse-media handling where applicable, and clearer evidence that unusual activity is reviewed by trained staff. A lower-risk model still needs controls, but not necessarily the same intensity or operational burden.
The most common failure is treating AML as a static onboarding step. In practice, customer risk changes, transaction patterns change, and product usage changes. The programme needs a feedback loop so that risk scoring, monitoring rules, and escalation criteria are revisited when the business expands into new markets, supports new asset types, or adds new payment rails.
- Re-test the risk assessment whenever the product, customer mix, or geography changes materially.
- Align alert thresholds to the actual transaction patterns of the business, not to a default vendor profile.
- Keep a record of why the control set is proportionate for the specific model and jurisdiction.
For firms with third-party dependence, the governance question also extends to who sees what, who reviews what, and who can act when something suspicious is detected. That is especially important when outsourced onboarding, hosted wallets, or external analytics are part of the operating model.
What regulators and investigators expect to see in day-to-day operations
In day-to-day terms, the programme has to produce usable evidence. That means a clear audit trail from customer onboarding through to ongoing monitoring, investigation, decision-making, and reporting. If a reviewer asks why a customer was accepted, why a transaction was escalated, or why a report was filed late or not filed at all, the firm should be able to reconstruct the decision from records rather than from memory.
Good operations also depend on timely handoffs. Screening and monitoring outputs are only useful if analysts can investigate them quickly, compare them against customer context, and route true concerns to the reporting function without unnecessary delay. Where suspicious activity is overlooked, the problem is often not the absence of a tool, but weak case management, poor alert tuning, or unclear accountability between compliance, operations, and the business.
For that reason, businesses should be especially careful about evidence quality. Regulators commonly focus on whether the firm can show consistent KYC/CDD decisions, a defensible monitoring methodology, documented escalation criteria, and a timely reporting process. If the programme is too informal, the firm may look compliant on paper but fail under review because it cannot demonstrate repeatable execution.
- Retain onboarding records, monitoring outcomes, investigation notes, and filing evidence in a way that supports review.
- Make ownership of suspicious activity decisions explicit, including who can close alerts and who can approve filings.
- Use monitoring metrics that show both coverage and quality, not just alert volume.
Risk and Threat Considerations
Crypto AML programmes are exposed to both regulatory risk and abuse risk. If onboarding is weak or monitoring is poorly tuned, bad actors can use the platform for layering, rapid value movement, or concealment through fragmented transactions, while the firm itself faces supervisory action, delayed approval, or licence pressure.
Failure mechanism: The controls fail when customer risk is assessed only at onboarding, transaction monitoring is not calibrated to the actual typologies the business sees, or suspicious activity is not escalated fast enough to meet reporting expectations.
Impact: The business can miss suspicious patterns, file late or incomplete reports, and appear disproportionate or under-controlled during regulatory review, which can lead to fines, restrictions, or loss of operating credibility.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | Risk-based AML programmes depend on a documented risk strategy. |
| PR.AA — Identity Management, Authentication, and Access Control | AML onboarding and ongoing customer verification rely on identity assurance and access control. | |
| DE.CM — Continuous Monitoring | Blockchain transaction monitoring maps to continuous monitoring of suspicious activity. | |
| Recommendation — Define a risk strategy that drives proportionate AML controls for the business model and jurisdiction. Apply identity and access controls to customer onboarding, verification, and internal case handling. Continuously monitor transactions and alert on patterns that indicate suspicious activity. | ||
| CIS Controls v8 | 5 — Account Management | KYC/CDD and customer lifecycle governance depend on managing account status and ownership. |
| 8 — Audit Log Management | AML investigations and reporting require reliable audit trails for review and evidence. | |
| 13 — Network Monitoring and Defense | Ongoing monitoring of transaction activity requires detection and alerting capabilities. | |
| Recommendation — Maintain accurate account lifecycle records and remove access when risk or status changes. Collect and retain audit logs that support investigations, reporting, and supervisory review. Monitor activity continuously and tune alerts to detect suspicious transaction patterns. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Crypto firms often rely on wallets, keys, and internal credentials that must be governed securely. |
| NHI-06 — Least Privilege and Access Governance | AML operations need constrained access to sensitive customer and transaction data. | |
| NHI-08 — Visibility and Monitoring | AML compliance requires visibility into transaction flows and suspicious behaviour. | |
| Recommendation — Protect keys and credentials that support transaction systems and compliance tooling. Limit access to compliance systems and sensitive records to approved roles only. Improve visibility into customer and transaction activity so analysts can investigate effectively. | ||
Practitioner Guidance
What to prioritise: Start with the jurisdiction-specific risk assessment, then use it to justify the minimum viable control set. If the business model changes, update the assessment before you expand volume or launch new flows.
What to verify: Check that KYC/CDD decisions, monitoring thresholds, escalation paths, and SAR or STR filing steps are all traceable in records. If you cannot reconstruct a decision chain, the control is not yet ready for supervisory scrutiny.
Common mistake: Treating compliance as a vendor purchase. Tools can support onboarding and transaction analysis, but they do not replace ownership, calibrated thresholds, or a team that can explain why the programme is proportionate.
Practitioner takeaway: The strongest AML programme is not the most restrictive one, it is the one that can justify its risk choices, prove its decisions, and adapt quickly when the business or jurisdiction changes.
Related resources from NHI Mgmt Group
- How should compliance teams implement customer due diligence under Kenya’s AML framework in higher-risk onboarding flows?
- How should compliance teams implement risk-based customer due diligence under South Africa’s AML rules?
- How should crypto businesses implement transaction monitoring when they need both compliance and privacy controls?
- How should crypto businesses in Australia structure compliance when they may fall under both AUSTRAC and ASIC rules?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
