MiCAR Legal Services Explained: What to Outsource vs. Do In-House (Contracts, SaaS/IT, Token Docs)
If you're building or investing in a crypto business in the EU, the hard part isn't learning what MiCAR is - it's deciding what to standardise internally versus what to outsource to specialised counsel, so you don't ship the wrong token, publish a non-compliant white paper, or walk into a CASP authorisation process unprepared.
MiCAR (Regulation (EU) 2023/1114) applies in stages: rules for "stablecoin-like" tokens (ARTs and EMTs) from June 30, 2024, and most remaining provisions - including the framework for crypto-asset service providers - from December 30, 2024. DORA, the EU's ICT-resilience rulebook, applies from January 17, 2025. In practice, token classification, disclosure, governance, operational resilience, marketing discipline and commercial/IT contracting all have to work together - especially if you're raising money or onboarding EU users.
This guide maps the three main MiCAR workstreams to a simple question: who should own each deliverable - your team, or your lawyers?
30 Dec 2024
most MiCAR provisions apply, incl. the CASP framework
17 Jan 2025
DORA applies - ICT resilience becomes part of the authorisation narrative
3
core workstreams: classification, white paper, CASP readiness
8
deliverables your in-house team can own - checklist below
Workstream 1: token classification is the "gate decision" - rarely safe to DIY
Your obligations depend first on whether the crypto-asset is in MiCAR's scope at all, then on which category it falls into - ART, EMT, or "other crypto-asset" (most utility tokens). Misclassification triggers the wrong disclosure track, the wrong licensing path, and the wrong messaging to investors.
Two developments raised the bar well above "we think it's a utility token": ESMA's guidelines for assessing whether a crypto-asset qualifies as a financial instrument (which would move it outside MiCAR into traditional securities regulation, on a substance-over-labeling basis), and the Joint European Supervisory Authorities' guidelines - applicable from 2025 - which set out a standardised classification test and templates for the explanations or legal opinions that accompany white papers in specific cases.
What an investor/exchange-grade opinion actually contains
An English-language classification / regulatory-boundary opinion (MiCAR scope and category, plus the financial-instrument question); an assumptions-and-qualifications section; reliance language with named addressees where appropriate; and annexes - token factsheet, feature matrix, disclosure-mapping summary. What it never contains: guarantees of regulator views, authorisation decisions, or listing outcomes. Opinions are fact-dependent - if token features change, the analysis needs refreshing.
DeFi and governance tokens get the same treatment, not a pass. "Decentralised" doesn't automatically mean "unregulated" - the analysis looks at token rights and admin/upgrade keys, actual distribution patterns (team, investors, community, vesting), whether governance control is genuinely decentralised or concentrated in a small group, and whether marketing implies returns, redemption or guaranteed value. The deliverable is a defensible analysis and a consistent disclosure posture - never a promise that a token sits "outside" regulation.
Interactive: the in-house base - eight deliverables your team should own
The economics of legal work are simple: the more of this foundation you build internally, the cheaper, faster and more defensible the outsourced work becomes. Tick what exists today:
What in-house can (and should) own across all three workstreams
- A token factsheet: rights, economics, supply mechanics, governance powers, redemption/peg claims, any "stable value" language
- A feature-change log - classification isn't one-time; changed features mean refreshed analysis
- A supporting evidence pack: technical documentation, smart contract audits, protocol specifications
- The technical description for the white paper: protocol, token mechanics, smart contracts
- Product roadmap and use cases - written without valuation promises
- Risk inputs from engineering and security: key management, custody model, admin keys
- First-draft internal policies (to be hardened by counsel, not invented by them)
- A vendor map: cloud, custody, market makers, compliance tooling - with contracts collected in one place
Quick test: in-house or outsource?
Four deliverables from a typical token launch. Who should own each?
Deliverable 1: The token factsheet - rights, supply mechanics, governance powers, and every place "stable" or "yield" appears in your materials.
In-house. Nobody knows your token's facts better than your team - and counsel can only be as good as the facts supplied. The factsheet (plus the feature-change log that keeps it current) is the single highest-leverage internal deliverable: it feeds classification, the white paper, and listing diligence.
Deliverable 2: The classification opinion - MiCAR scope and category, plus whether the token is likely a financial instrument under ESMA's approach.
Outsource. This is the gate decision, and since the Joint ESA guidelines standardised the test and templates, investors and exchanges expect a structured, third-party-reliable legal view - not an internal memo. Getting it wrong means the wrong disclosure track, licensing path and investor messaging.
Deliverable 3: The white paper's technical description - protocol architecture, token mechanics, consensus-mechanism data.
In-house. Engineering owns the technical truth - outsourcing it produces expensive, second-hand descriptions. Counsel's job comes next: the legal architecture around it (required sections, risk factors, disclaimers, conflicts) and the liability-aware wording.
Deliverable 4: The consistency sweep - cross-checking the white paper against token terms, the website, the pitch deck, and exchange listing questionnaires.
Outsource. MiCAR imposes consistency requirements across all communications, and the white paper carries a civil-liability framework. The liability lens - flagging statements that create investor expectations (returns, stability, redemption) and tightening the wording - is precisely the judgment call teams shouldn't make about their own marketing.
Workstream 2: white papers are regulated disclosure with liability - not marketing PDFs
Regulation (EU) 2023/1114
The practical trap: writing a "token deck", not a disclosure document
MiCAR requires a crypto-asset white paper in many offering or admission-to-trading scenarios, and creates a civil-liability framework around its content. For many "other crypto-assets", the regime generally involves notification and publication rather than prior approval - but the content, consistency and liability obligations apply in full. ESMA has also supported machine-readable formatting work for white papers, including taxonomy resources - a signal that these are controlled documents, not growth assets.
BSA's five-step review method: (1) required-content checklist - each MiCAR disclosure item mapped to an owner and evidence; (2) consistency sweep across token terms, website, deck and listing questionnaires; (3) liability lens on statements creating investor expectations; (4) risk-factor calibration to your actual model - key/admin controls, custody, oracle/bridge risk, liquidity reliance; (5) version control - what triggers a revision, who signs off, how publication or notification is handled.
Anonymised matter snapshots (illustrative, not guaranteed outcomes)
EU consumer app - utility token
Pre-launch and listing preparation, Romania operations. Delivered: disclosure mapping, full consistency review across white paper/website/token terms, tailored risk factors (custody, admin keys, liquidity assumptions).
Payments-linked token - EMT/ART boundary case
Multi-country EEA go-to-market, pre-raise. Delivered: category analysis memo, white paper outline with required-disclosures checklist, marketing review to remove or qualify "stable value" wording and implied redemption commitments.
Infrastructure protocol - governance token
EEA user base, non-EU foundation, documentation refresh ahead of EU-facing distribution. Delivered: risk-factor refresh, disclosure consistency review on tokenomics and governance powers, communications guidance for EU marketing.
Workstream 3: CASP readiness is mostly "operational law" - governance, outsourcing, DORA, contracts
Authorisation isn't about forms; it's about demonstrating a real operating business with controls, people and documented accountability. A complete file typically covers: governance and people (org structure, fit-and-proper evidence, conflicts policy and register); compliance and client protection (complaints handling, "fair, clear, not misleading" marketing controls, custody safeguards where in scope); the operational model (programme of operations, outsourcing inventory and governance, negotiated contracts with audit/incident/exit rights); DORA-aligned ICT documentation (risk policy, incident playbook, BC/DR with testing evidence, third-party ICT risk pack); and the financial plan.
The outsourcing decision most teams get wrong
Trying to outsource everything - compliance, risk, security, even core operations. Regulators focus on substance ("letterbox" entity or real business?), outsourcing governance (do you still control critical functions?), operational resilience and client protection. This is exactly where legal, compliance and IT contracting converge - and where DORA makes your cloud contract, custody stack and vendor exit plans part of the authorisation narrative, not paperwork handled separately from it.
A transparent status snapshot: how BSA tracks CASP-readiness mandates
Deliverable category | Illustrative status across recent mandates |
|---|---|
Governance pack (org chart, fit-and-proper, conflicts register) | Typically prepared and finalised early, ahead of other workstreams |
Outsourcing inventory and contracts | Drafted and negotiated in parallel with the operations narrative; timing depends on vendor responsiveness |
ICT/DORA-aligned documentation | Frequently the longest-running workstream - it depends on third-party provider input and testing evidence |
Full application file submitted to ASF | Submitted for a subset of engagements to date; others in pre-submission gap analysis or document finalisation |
Post-submission regulator queries | Handled on a pending/responsive basis - timelines are set by the regulator, not the applicant |
Illustrative of how BSA structures and tracks this work - not a disclosure of specific client files, and not a guarantee of authorisation, licence counts or timelines.
Romania/ASF context, stated carefully: practitioner analysis (e.g., Chambers Practice Guides) positions ASF as central for CASPs and most non-EMT crypto-assets, with the National Bank of Romania relevant for EMT-adjacent or prudentially supervised entities. ESMA lists Romania among Member States using an 18-month grandfathering period under Article 143(3). BSA's approach is to plan the ASF process conservatively - no assumed shortcuts, no guaranteed timelines - and to build an evidence-based file that can travel across the EEA.
"In a MiCAR world, your commercial contracts have to match your operational model and your regulatory commitments: custody/MPC/HSM agreements with audit and incident rights, cloud/SaaS terms with availability and exit provisions, market-maker agreements with conflicts disclosures, listing agreements that define who publishes what. The projects that fail usually fail here - not in the legal theory."
- Why BSA bridges MiCAR work with SaaS/IT contracting in the same workflow
Frequently asked questions
What MiCAR work can a crypto startup realistically do in-house?
Token feature documentation, technical descriptions, internal evidence packs, first-draft policies, and vendor mapping. The parts that typically require specialist counsel: classification/perimeter analysis, white paper legal drafting and liability controls, and CASP readiness - especially outsourcing and governance design.
Do MiCAR white papers need regulator approval?
For many "other crypto-assets", the regime generally involves notification and publication rather than prior approval - though content, consistency and liability obligations apply in full. Always confirm the track for your specific token category and jurisdiction.
Has BSA supported CASP authorisation processes end-to-end?
BSA has worked across the CASP-readiness deliverable set - governance packs, outsourcing files, ICT/DORA-aligned documentation - from early gap analysis through document finalisation and, for a subset of engagements, submission to ASF. BSA doesn't disclose client-identifying details and doesn't promise authorisation outcomes or timelines.
Does BSA advise DeFi protocols and governance tokens?
Yes - by examining token rights and admin/upgrade keys, actual distribution and vesting, whether governance control is genuinely decentralised, and whether marketing creates unsupportable investor expectations. Typical deliverables: a classification memo addendum, distribution and communications guidance, and risk-factor enhancements for EU-facing materials.
How does BSA help with MiCAR fundraising diligence?
With a diligence-ready package: token classification memo, white paper drafting and disclosure mapping, marketing alignment review, and "regulatory hygiene" contracting (SaaS/IT, custody, outsourcing) - reducing execution risk and supporting investors' underwriting of regulatory exposure. Get in touch.
Planning a token launch, EU listing, or CASP authorisation strategy?
Start with a two-step readiness sprint: (1) a classification and documentation map - which regime applies, which documents must exist, who owns which inputs; and (2) an operational and contracting gap assessment - policies, outsourcing, DORA-adjacent ICT controls, and market-facing terms. Scoped and practical, without unnecessary legal overbuild.
Sources and references
Regulation (EU) 2023/1114 (MiCAR): EUR-Lex · ESMA MiCA hub (supervisory materials, white paper formatting/taxonomy, authorisation convergence, list of Article 143(3) grandfathering periods): esma.europa.eu · Joint ESA guidelines and templates for crypto-asset classification: eba.europa.eu · Regulation (EU) 2022/2554 (DORA): EUR-Lex · EIOPA - DORA explainer: eiopa.europa.eu · EDPB - Guidelines 02/2025 on blockchain and data protection: edpb.europa.eu · Chambers Practice Guides - Romania blockchain/crypto trends: practiceguides.chambers.com · Buju, Stanciu & Asociații (BSA): bsa.ro
Disclaimer: This article is for general informational purposes only and does not constitute legal advice. Its application depends on the specific facts of each project; a dedicated legal analysis is required for a formal opinion. Anonymised examples and status snapshots illustrate typical deliverables and working methods only - they are not a guarantee of any outcome, timeline, or licensing decision.