A crypto business can have a strong product, experienced founders and real market demand, then lose momentum because its compliance framework was treated as a document for the licence application rather than an operating system. Knowing how to design crypto compliance controls means building rules that protect the business when onboarding volume rises, counterparties ask difficult questions, a transaction triggers an alert, or a regulator requests evidence.
For founders planning a CASP operation under MiCA, or operating across several markets, the goal is not to collect policies. The goal is to create a controlled commercial environment: one that can access banking and payment rails, evidence sound governance, and grow without constantly rebuilding its risk function.
Start with the business model, not a generic policy pack
Controls should reflect what the business actually does, where it operates and who bears the risk. A custody provider faces materially different exposure from a crypto-to-fiat exchange, broker, portfolio manager or token issuer. The same is true for a business serving retail clients versus professional clients, or one using its own liquidity versus connecting clients to external venues.
Before drafting procedures, map the full operating model. Identify the legal entities involved, their jurisdictions, the services provided, customer segments, supported assets, payment methods, wallet flows, third-party technology providers and outsourced functions. This exercise also needs to identify where decisions are made and where funds, data and private keys are held.
This is where corporate structure becomes a compliance issue rather than a back-office choice. A holding company, an EU operating entity, an offshore technology company and a payment partner can each have different responsibilities. If those responsibilities are unclear, controls will be unclear too. Regulators, banks and institutional counterparties will look for a coherent explanation of the group, not a diagram created after the fact.
Build a risk assessment that drives real decisions
A business-wide risk assessment should be the control framework’s foundation. It needs to assess money laundering, terrorist financing, sanctions, fraud, consumer protection, operational and cyber risks in a way that is specific to the model.
Avoid scoring every risk as high simply to appear cautious. That approach makes prioritisation impossible and often produces controls nobody can operate. Instead, assess inherent risk first, then decide what mitigations reduce it to an acceptable residual level. Document the rationale, the owner and the review cycle.
For a crypto-asset service provider, the assessment will commonly consider:
- customer geography, legal form, source of wealth profile and expected activity;
- products such as custody, exchange, transfers, staking or token distribution;
- blockchain exposure, including mixers, privacy-enhancing tools, high-risk addresses and cross-chain activity;
- transaction channels, fiat funding routes, wallet types and third-party intermediaries; and
- delivery channels, including non-face-to-face onboarding, affiliates, APIs and white-label arrangements.
The risk assessment must lead to rules. If a jurisdiction is rated high risk, define whether customers from that jurisdiction are prohibited, restricted, subject to enhanced due diligence or escalated for approval. If self-hosted wallets create higher exposure, state what evidence, screening or transaction limits apply. A risk register that never changes onboarding or monitoring decisions is not a useful control.
How to design crypto compliance controls across the customer journey
The strongest frameworks follow the customer and the asset through the complete lifecycle. They do not isolate onboarding from transaction monitoring, or monitoring from offboarding.
Customer acceptance and onboarding
Set a clear customer acceptance policy before commercial teams begin acquiring clients. Define prohibited categories, geographic restrictions, acceptable customer types and the approval authority for exceptions. For corporate clients, beneficial ownership and the purpose of the relationship require particular attention. A polished corporate registry extract is not, by itself, evidence that the business activity is credible.
Customer due diligence should verify identity, establish beneficial ownership, screen for politically exposed persons, sanctions and adverse media, and capture an expected activity profile. Enhanced due diligence should be triggered by defined factors, not individual instinct alone. High-risk customers may require source-of-funds evidence, source-of-wealth analysis, senior management approval and more frequent review.
The commercial trade-off is real. More friction can reduce conversion. But weak onboarding can cost far more through frozen bank accounts, failed due diligence by a payment partner, enforcement action or an inability to scale into regulated markets. Design tiered verification and risk-based limits so low-risk customers can move efficiently while higher-risk relationships receive appropriate scrutiny.
Wallet, blockchain and transaction monitoring
Crypto monitoring cannot rely only on fiat-style thresholds. A series of small transfers can be more significant than one large transaction when addresses are linked to sanctions exposure, darknet activity, scams, ransomware or stolen funds.
Use documented monitoring scenarios that combine blockchain analytics with customer context. Relevant triggers may include rapid movement through newly created wallets, exposure to high-risk services, unexplained changes from expected activity, unusual fiat-to-crypto conversion patterns, or transfers involving sanctioned or restricted geographies. Alerts should be risk-ranked, assigned to trained reviewers and resolved with evidence, not merely closed because the customer has passed initial KYC.
Calibration matters. If every alert is generated at the same severity, the team will spend its time clearing noise. If thresholds are too relaxed, meaningful risk will be missed. Review alert volumes, escalation outcomes and false-positive rates regularly, especially after launching a new asset, payment route or customer segment.
Travel Rule and transfer controls
Where the Travel Rule applies, collect, verify and transmit required originator and beneficiary information through a reliable process. The control design must address what happens when data is missing, a counterparty CASP cannot exchange information, or a transfer is associated with a self-hosted wallet.
Do not leave these decisions to customer support. Set operational rules for holds, rejection, release, escalation and record retention. The procedure should be usable at pace, including outside standard office hours if the business offers continuous trading or withdrawal services.
Give every control an owner and an audit trail
A policy does not perform a control. People, systems and governance perform it. For each material control, document its purpose, frequency, owner, inputs, evidence produced, escalation route and testing method. This creates accountability and makes it possible to demonstrate that the framework is operating as designed.
The compliance function needs sufficient authority to challenge commercial pressure. Senior management should receive meaningful management information: high-risk onboarding decisions, open monitoring alerts, sanctions matches, suspicious activity reports, complaints, control failures, training completion and key outsourced-provider issues. A board that receives only a statement that compliance is ‘under control’ cannot discharge its responsibilities.
Independence also matters. First-line teams can collect documents and handle routine activity, but compliance oversight and internal review should be able to identify failure without being measured solely on revenue or customer conversion.
Test the controls before a regulator or bank tests them for you
Control testing should include sample reviews, quality assurance, thematic reviews and scenario-based exercises. Test whether an analyst follows the procedure when a politically exposed person is onboarded, when a wallet receives exposure to a sanctioned address, or when a customer disputes a transaction. The most valuable findings often emerge at the handover between teams.
Keep evidence organised and retrievable. Regulatory readiness is not achieved by producing policies at speed when asked. It is demonstrated through version-controlled procedures, completed customer files, alert investigations, management minutes, training records, vendor assessments and documented remediation.
Technology vendors can improve speed and coverage, but outsourcing screening, analytics or onboarding tools does not outsource accountability. Assess providers carefully, define service levels, protect access to data and ensure the business can explain how automated decisions are reviewed. A tool should support judgement, not replace it.
Treat compliance as part of your expansion architecture
As the business adds jurisdictions, products, affiliates, payment methods or acquisition targets, the original risk assessment may no longer be fit for purpose. Change management should require compliance sign-off before material launches, with clear testing and approval gates.
This is particularly relevant for groups moving towards MiCA authorisation. The compliance design must align with governance, capital planning, outsourcing arrangements, ICT security, complaints handling and safeguarding obligations. A licence application is stronger when these elements are built into the operating model rather than assembled as separate workstreams.
Ivyascent approaches this work as a growth decision as much as a regulatory one: aligning licensing, entities, tax and operational controls so expansion does not create avoidable exposure. The right framework will not eliminate risk. It will give management the visibility and discipline to take risk deliberately, protect valuable market access and build a crypto business that counterparties are prepared to trust.
The most useful closing test is simple: when a high-risk customer, wallet or jurisdiction appears tomorrow, can your team show exactly what happens next, who decides, and why? If the answer is yes, your controls are beginning to do their job.