MiCA's definitions aren't bureaucracy - they determine your licensing path, capital obligations, and right to operate across 27 EU member states.
MiCA compliance is not just a regulatory checkbox - it is a definitional exercise. Before you can build a compliance programme, choose a jurisdiction, or structure a service offering, you need to know what category your business falls into under EU law.
The Markets in Crypto-Assets Regulation (MiCA), which entered full effect across the European Union, did something no previous framework had achieved: it standardised the regulatory vocabulary for crypto services across all 27 member states. One set of definitions. One classification system. One compliance baseline.
Before MiCA, the crypto regulatory framework across Europe was fragmented. The same activity - custody, exchange, transfer - could be defined differently in Germany, Poland, and the Netherlands, regulated under different rules, or fall outside regulation entirely. That fragmentation made institutional adoption difficult and cross-border operation expensive.
MiCA ended that. For businesses in Central-Eastern Europe - where the gap between local frameworks and EU-wide standards was widest - this standardisation is commercially significant. Understanding the terminology is not academic. It determines whether you need authorisation, what capital you must hold, and what obligations you carry toward clients.
Under MiCA, a crypto-asset is any digital representation of value that can be transferred and stored electronically using cryptographic technology. Broadly speaking, this covers:
The classification test is functional, not technical. MiCA does not ask how an asset was built - it asks what it does. If a digital asset holds value and can be transferred, it is within scope. If your business handles such assets professionally, MiCA applies to you.
NFTs and certain DeFi assets may fall outside MiCA's scope depending on their characteristics - but the default assumption for any professional crypto activity should be that MiCA applies until you have legal confirmation otherwise.
A CASP is any natural or legal person that provides one or more crypto-asset services as a business activity. This is the central category in MiCA's compliance structure. The definition is intentionally broad:
If you provide any of these services as a commercial activity - not occasionally, but as part of your business model - you are a CASP under MiCA. That classification triggers mandatory authorisation requirements. There is no de minimis threshold below which CASP obligations disappear entirely.
For e-commerce businesses and fintech operators: if your platform facilitates crypto transactions for clients, even as one feature among many, the CASP classification question needs a legal answer.
Read more in our ARI10 article focusing on what CASP means for businesses.
A competent authority is the national financial regulator designated by each EU member state to supervise MiCA compliance within its jurisdiction. Examples include:
Your competent authority is more than a regulator. It is your regulatory home. They issue authorisation, conduct ongoing supervision, enforce MiCA obligations, and - if needed - impose sanctions.
The choice of jurisdiction for authorisation has real consequences. Different national competent authorities have different processing timelines, different interpretations of certain MiCA requirements, and different supervisory postures. For businesses based in Central-Eastern Europe, the local regulatory relationships matter.
ARI10 itself for example holds authorisation from the AFM under MiCA (Reference Number: 41000022) through WEB3 Technology B.V.'s EU-licensed infrastructure. Read our official announcement article here.
Custody is the safekeeping and administration of crypto-assets on behalf of clients. Under MiCA, custodians face a non-negotiable requirement: strict asset segregation. Client assets must be held completely separate from the custodian's own funds.
Client assets cannot be commingled with company capital. They cannot be used for operational purposes. They cannot be pledged as collateral. They must sit in dedicated wallets, accounts, or infrastructure that is clearly identifiable as client property at all times.
This requirement exists because the alternative - custodians treating client assets as available capital - is precisely what created catastrophic losses in several high-profile crypto collapses. MiCA's asset segregation rule is the structural fix for that failure mode.
Settlement is the final, irrevocable transfer of crypto-asset ownership from one party to another. MiCA requires that settlement terms be explicit (defined in advance), transparent (disclosed to all parties), timely (executed within agreed timeframes), and irrevocable (once complete, the transaction cannot be reversed).
For business clients, clear settlement terms are operationally essential. They determine when an asset is legally owned, when a transfer is complete, and how cash flows and asset positions are recorded. Ambiguous settlement creates accounting uncertainty and counterparty risk.
Operational safeguards are the technical, organisational, and procedural measures that CASPs must implement under MiCA to manage operational risk. The requirements cover:
These are not optional enhancements. They are MiCA compliance requirements - and they directly correspond to the operational failures that damaged the crypto industry's reputation before regulated infrastructure became the norm.
Stablecoins receive their own regulatory regime within MiCA - because their failure poses systemic risks that go beyond individual investors.
MiCA draws a clear line between two stablecoin categories:
The distinction matters for issuers, but also for businesses that use stablecoins for settlement or treasury purposes. Understanding what type of stablecoin you are holding - and who issued it under which regulatory framework - is part of MiCA-compliant operations.
For any stablecoin issuer, reserve assets are the underlying holdings that back the token's value. For an EMT pegged to EUR, MiCA requires:
Both must be held in segregated accounts, separate from the issuer's own operational funds.
This requirement is the mechanism by which MiCA ensures that a stablecoin can actually honour its stability promise. A stablecoin with inadequate or low-quality reserves is not a stablecoin in any meaningful sense - it is a risk instrument marketed as stability. MiCA's reserve requirements make that distinction enforceable.
Redemption rights are the legally enforceable guarantee that stablecoin holders can exchange their tokens for the underlying reserve assets at par value (1:1) on demand.
Without redemption rights, the stability of a stablecoin depends entirely on market confidence - which, as the industry has demonstrated, can collapse overnight. With legally mandated redemption rights under MiCA, stability is contractual, not aspirational.
For business clients using stablecoins for B2B settlement or treasury management, this distinction matters: MiCA-compliant stablecoins carry real redemption obligations, not promises.
Authorisation under MiCA is the formal determination by a national competent authority that a business meets the requirements to operate as a CASP. It is mandatory. Operating as a CASP without authorisation is a legal violation in every EU member state.
Authorisation is:
The authorisation process involves demonstrating compliance with MiCA's requirements across governance, capital, operational safeguards, AML/CFT obligations, and transparency standards. For businesses that have been operating informally, this is a significant undertaking - which is why choosing a gateway provider that is already authorised matters.
Passporting is the mechanism that makes the EU a single market for crypto services. An authorised CASP can provide services in any EU member state on the basis of its home authorisation – without requiring separate authorisation from each national regulator.
Importantly, passporting is not automatic. Before extending services into another member state, a CASP must submit a formal notification to its home competent authority, specifying the services it intends to provide and the member states concerned. The home authority then transmits this notification to the host authority, and a statutory waiting period applies before services can commence. This procedural step ensures that host regulators are informed and that supervisory cooperation is in place, even though no second authorisation is required.
Pre-MiCA, operating across multiple EU countries meant navigating 27 different regulatory frameworks - 27 different application processes, timelines, capital requirements, and supervisory relationships. Passporting replaces that with a single authorisation, recognised across the entire EU after the notification process is complete.
For Central-Eastern European businesses with EU-wide ambitions, this is one of MiCA's most commercially significant provisions. One compliant structure. EU-wide reach.
MiCA requires CASPs to maintain minimum levels of own funds - capital held against operational losses and insolvency risk. Under Article 67 of MiCA, the specific floor depends on the services the CASP is authorised to provide:
These are MiCA's absolute floors. Actual requirements may be higher based on the fixed overheads calculation (one quarter of fixed annual overheads), which is the binding test for most established businesses.
Why it matters: Capital requirements exist because regulated service providers must have financial exposure alongside their clients. A provider that cannot absorb operational losses is a systemic risk to the clients it serves. Capital requirements ensure providers can continue operations even under market stress.
MiCA requires that all costs associated with crypto-asset services be clearly documented and communicated to clients before service delivery. This covers service fees, transaction costs, and any additional charges that apply under specific circumstances.
Fee transparency serves two functions: it prevents client disputes by establishing expectations upfront, and it enables competitive comparison - allowing clients to accurately assess the true cost of a service and make informed choices between providers.
CASPs must clearly disclose the risks associated with the crypto-assets they handle and the services they provide. Required disclosures cover risks such as:
Risk disclosure requirements protect clients - but they also protect service providers. A client who understood the risks at the point of engagement has far less legal recourse than one who was inadequately informed.
MiCA's regulatory terminology is not abstract compliance language. It is the framework through which institutional clients, boards, and regulators will assess your crypto services.
When you can explain that your custodian maintains asset segregation, that your settlement terms are irrevocable, that your capital meets MiCA's class requirements, and that you hold EU passporting rights through an authorised CASP - you are speaking a language that institutions recognise and trust.
For businesses in Central-Eastern Europe navigating the transition to regulated crypto infrastructure, this vocabulary is the starting point. It is how you build the compliance framework. It is how you explain your services to legal and finance teams. It is how you demonstrate that operating with crypto is not a risk - it is a regulated activity, subject to the same standards as traditional financial services.
ARI10 has been aligned with EU and Polish regulatory frameworks since 2017. Our infrastructure supports MiCA-aligned crypto transaction processing for B2B clients across CEE - with KYC/KYB automation.
The language of regulated crypto is already built into what we do. Let us help your business speak it.
Crypto-asset services are provided by WEB3 Technology B.V., a company incorporated in the Netherlands, authorized and regulated by the AFM as a Crypto-Asset Service Provider under MiCA (AFM Reference Number: 41000022). ARI10 and ARI10 NL are registered brand names of WEB3 Technology B.V. ARI10 Sp. z o.o. is a separate Polish entity, independently registered under the Polish Virtual Currency Activities register (RDWW-227), and is not covered by the AFM authorization.
