> For the complete documentation index, see [llms.txt](https://faq.finchtrade.com/guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://faq.finchtrade.com/guide/regulatory-compliance/mica-explained-for-embedded-crypto.md). # MICA explained for embedded crypto The Markets in Crypto-Assets regulation (MiCA) is the EU's harmonised crypto framework, in force since 2024. For B2B platforms adding crypto features, MiCA is the central regulatory question if any of their activity touches the EU. This page walks through what MiCA actually requires, how it affects embedded crypto integrations, and where the boundaries sit. ## What MiCA is MiCA is an EU regulation (not a directive) — meaning it applies directly across all EU member states without each having to transpose it into national law. It establishes: * A harmonised framework for crypto-asset issuance (covering tokens like asset-referenced tokens, e-money tokens, and other crypto-assets) * A licensing regime for crypto-asset service providers (CASPs) operating in the EU * Conduct, governance, and disclosure rules for both issuers and CASPs * Supervisory cooperation between national competent authorities and ESMA at the EU level The intent is to bring crypto into a regulated framework comparable to (though distinct from) traditional financial services regulation in the EU. ## What MiCA requires for service providers CASPs — businesses providing in-scope crypto services to EU clients — need authorisation. The activities that trigger CASP requirements include exchange of crypto-assets, custody, transfer services, operating a trading platform, executing orders for clients, placing crypto-assets, reception and transmission of orders, advice, and portfolio management. Once authorised, CASPs face ongoing obligations: * Capital and prudential requirements (varying by service type) * Governance and management standards * Conflict-of-interest rules * Disclosure to clients * Complaints handling and dispute resolution * Operational resilience and information security * Ongoing reporting to supervisors Authorisation in one EU member state can be passported across the EU under standard conditions, which is one of MiCA's main improvements over the pre-MiCA patchwork. ## What MiCA means for embedded crypto integrations For B2B platforms adding crypto features, MiCA matters in three different ways depending on the integration model. ### 1. The platform performs in-scope activity in the EU If the platform itself is performing CASP-scope activity for EU clients — exchange, custody, transfer, etc. — the platform needs CASP authorisation. No partnership with a non-CASP infrastructure provider substitutes for this. The platform is the regulated party. This is the heaviest regulatory path for the platform. Authorisation takes time and capital; ongoing compliance is significant. ### 2. The platform partners with a CASP-authorised infrastructure provider If the regulated activity sits with a CASP-authorised partner, the platform can operate within the partner's authorisation under defined arrangements. The structure depends on the activity and the partner; common variants include outsourcing arrangements, tied-agent structures (under MiFID, where applicable), and reseller arrangements. This shortens the platform's regulatory path significantly but constrains it to the partner's authorisation scope. ### 3. The platform structures activity to stay outside MiCA's reach Some platforms keep their EU-touching activity outside MiCA scope by avoiding the in-scope services — software-only, non-custodial, advisory-only without execution, or B2B-only outside MiCA's retail focus. This works for some products and not others. For products where users hold balances, trade actively, or rely on the platform to move funds, staying outside scope is usually impractical. ## The reverse-solicitation question A specific question that comes up: can a non-EU operator serve EU clients without CASP authorisation if the EU client initiates the relationship? MiCA does include limited reverse-solicitation provisions, but they're narrower than they often appear. The basic principle: a non-EU operator can provide services to an EU client at the EU client's exclusive initiative, without the operator marketing into the EU. The boundaries are tight — any active marketing into the EU usually disqualifies reverse-solicitation as a defence. For platforms thinking "we'll just rely on reverse-solicitation," this is usually not a robust strategy. Active platforms with EU users typically need either CASP authorisation or a CASP partnership. ## What MiCA doesn't cover A few things to be clear about. **Non-EU activity.** MiCA is EU regulation. A platform operating outside the EU isn't subject to MiCA for that activity. Other jurisdictions have their own frameworks (FCA in the UK, FinCEN in the US, etc.). **Other obligations.** AML, KYC, sanctions, GDPR, consumer protection, and other regulations continue to apply alongside MiCA. CASP authorisation doesn't substitute for these. **DeFi and fully decentralised protocols.** MiCA explicitly excludes fully decentralised activity from CASP requirements. The boundary is fact-specific; "fully decentralised" is a high bar. **Some token types.** Certain tokens (typically NFTs and fully decentralised utility tokens) are out of scope of MiCA's issuer rules. The CASP rules still apply to services involving them in some cases. ## Where FinchTrade fits — and doesn't To be explicit: **FinchTrade is not a CASP.** We are not authorised under MiCA. Our framework is Swiss VQF, which is separate from MiCA. What this means for partners: **We can typically support:** * B2B and professional-client activity globally where Swiss VQF provides adequate authorisation * Cross-border activity that doesn't trigger MiCA-specific CASP requirements * Most non-EU markets **We cannot support:** * Activity targeting EU retail clients in a way that requires CASP authorisation * Activities specifically requiring CASP scope (operating a trading platform serving EU retail, custodial wallet services for EU consumers, etc.) * Any structure that would amount to operating without required authorisation in the EU For partners whose use case requires CASP authorisation, we'll be explicit about the gap. The right path for those partners is either to get their own CASP authorisation or to partner with a CASP-licensed operator. We can refer where appropriate. For partners whose use case fits within Swiss VQF coverage, [Regulated Crypto Access](file:///3576885/solutions/regulated-crypto-access/overview.md) is the relevant solution. The fastest way to get a clear answer is a scoping conversation. ## How MiCA might evolve MiCA is new and will continue to be interpreted and refined. Key areas of ongoing development: * Technical standards from ESMA filling in details left to secondary legislation * Supervisory practices as national authorities apply MiCA in practice * Potential amendments addressing gaps or unintended consequences * Interaction with other EU frameworks (DORA, AMLD6, MiFID, etc.) For partners building businesses that depend on MiCA interpretation, ongoing legal engagement is part of the price of operating in the EU. Static positions don't survive long.