The Markets in Crypto-Assets Regulation (MiCA) is now the operating baseline for any crypto-asset business serving clients in the European Union. Whether you're issuing a token, running an exchange, or offering custody, the question is no longer whether MiCA applies | it's whether your compliance programme can withstand a regulator actually reading it. This checklist walks through what that looks like in practice.
1. Confirm which MiCA category applies to you
MiCA doesn't treat all crypto-asset activity the same way. Before building anything else, map your business against the regulation's core categories:
- Crypto-Asset Service Provider (CASP) | exchanges, custodians, brokers and portfolio managers
- Asset-Referenced Token (ART) issuer | tokens referencing a basket of assets
- E-Money Token (EMT) issuer | tokens referencing a single fiat currency
- Issuers of other crypto-assets not covered by the above
Getting this classification wrong early tends to cascade into every later step, since authorisation requirements, capital thresholds and ongoing obligations differ meaningfully between categories.
2. Prepare your authorisation file
CASP authorisation under MiCA generally requires a governance and fit-and-proper file, a programme of operations, a business continuity plan, and | critically | an AML/CTF policy that a national competent authority will scrutinise as closely as your business plan. Authorities increasingly expect this documentation to be specific to your actual product, not adapted from a generic template.
3. Build AML/KYC controls that match your risk profile
MiCA authorisation sits on top of existing AML/CTF obligations, not instead of them. Your programme needs to address:
- Risk-based customer due diligence, scaled to product and geography
- Enhanced due diligence procedures for politically exposed persons and high-risk jurisdictions
- A defensible, regularly updated country and counterparty risk methodology
- Transaction monitoring calibrated to on-chain and off-chain typologies
- A clear escalation and suspicious activity reporting pathway
One detail worth flagging explicitly: prohibited-country lists inherited from older policies or copy-pasted from unrelated jurisdictions sometimes end up incorrectly including EU or EEA member states. That kind of error is an easy, avoidable red flag in front of a regulator.
4. Assign clear governance and accountability
Authorities want to see a named, fit-and-proper individual accountable for compliance | not a diffuse committee. For smaller and mid-sized Web3 companies, this is often where a fractional MLRO or outsourced compliance officer earns their keep: the accountability is real and named, without the cost of a full internal function from day one.
5. Plan for ongoing obligations, not just the application
Authorisation is a milestone, not the finish line. Post-authorisation, CASPs and token issuers under MiCA carry ongoing obligations including periodic reporting, governance reviews, incident notification, and | as of the Digital Operational Resilience Act (DORA) | ICT risk management and third-party risk oversight for critical service providers.
6. Revisit the file as your product evolves
Web3 products move fast. A compliance file written for your product at launch can be materially out of date within a year. Building a review cadence | even a simple annual one | into your compliance calendar avoids the file quietly drifting away from what the business actually does.
The bottom line
MiCA rewards specificity. Authorities can tell the difference between a compliance programme built for your actual business and one assembled from templates. The companies that move through authorisation fastest tend to be the ones that treat the AML/CTF policy as seriously as the product roadmap | with clear ownership, honest documentation, and a plan for keeping it current.