The MiCA framework in Venvera helps your organisation manage its obligations under Regulation (EU) 2023/1114, the Markets in Crypto-Assets Regulation, the first EU-wide regime for crypto-asset markets. It is built for the compliance owner at a crypto-asset service provider or token issuer who has to prove readiness to a national competent authority.

Regulatory Context

Who is in scope?

Scope follows the activity you perform. You are in scope if you are a crypto-asset service provider (CASP) - running an exchange or trading platform, providing custody, executing or receiving and transmitting orders, placing, advising, or managing portfolios of crypto-assets - or if you issue, offer to the public, or seek admission to trading a crypto-asset. MiCA sorts crypto-assets into three buckets that carry different duties: asset-referenced tokens (ARTs), e-money tokens (EMTs), and other crypto-assets. Classifying each asset correctly is the first control, because everything downstream depends on it.

The key dates

MiCA applies in two waves. The rules for asset-referenced and e-money tokens have applied since 30 June 2024. The rules for crypto-asset service providers have applied since 30 December 2024. Member states may run a transitional window for CASPs already operating under national law, so track any grandfathering entitlement and its expiry against a plan to reach full authorisation (control MICA-4).

ℹ️
Classify your assets first. Whether a crypto-asset is an ART, an EMT, or "other" decides which reserve, redemption, and white-paper duties apply. Record that decision under Authorisation & Scope before working the rest of the set.

Enabling MiCA

MiCA appears in the left navigation once your subscription includes it. The first time you open MiCA › Controls, Venvera initialises the 26-control set for your organisation, and the dashboard begins tracking coverage. If the dashboard shows "No controls yet", open the controls page once to seed them.

Using the MiCA module

Open MiCA to reach the dashboard. It gives you a coverage ring (controls implemented or scoped out), per-area progress bars, a native-versus-overlay split, and cards that take you into the three working surfaces: the controls list, the gap assessment, and the board report.

The 26 controls across 6 areas

MiCA in Venvera is a set of 26 controls (MICA-1 to MICA-26) grouped into six assessment areas:

AreaControlsWhat it covers
Authorisation & ScopeMICA-1 to MICA-4Asset classification, CASP authorisation, white-paper conditions before an offer, cross-border and transitional entitlements.
Governance & PrudentialMICA-5 to MICA-10Fit-and-proper management, governance and internal control, prudential own-funds safeguards, conflicts of interest, outsourcing, business continuity.
Client Asset ProtectionMICA-11 to MICA-15Segregation and safeguarding of client crypto-assets and funds, custody policy and register, custody liability, reserve backing for ARTs and EMTs, redemption rights.
Conduct & DisclosureMICA-16 to MICA-20Acting honestly and fairly, white-paper content, marketing rules, cost and risk disclosure, complaints handling.
Market IntegrityMICA-21 to MICA-24Inside-information handling, insider-dealing and manipulation prohibitions, suspicious-transaction detection and reporting.
Reporting & ResilienceMICA-25 to MICA-26Record-keeping and regulatory reporting, ICT resilience under DORA, and AML and Travel Rule obligations.

The controls list

Open MiCA › Controls to record where you stand on each control. You set an implementation status - implemented, partial, not implemented, or not applicable - and attach evidence. Use Not applicable deliberately: MICA-14 and MICA-15 (reserve backing and redemption) only bite if you issue ARTs or EMTs, and MICA-24 (suspicious-transaction reporting) applies only if you arrange or execute transactions. Scoping those out keeps your coverage honest instead of penalising you for duties you do not have.

The gap assessment

Open MiCA › Gap Assessment to score readiness before you commit to statuses. There is one maturity question per control, rated on a 0 to 4 scale (Not Started, Initial, Developing, Established, Embedded). Answers are weighted by control importance and rolled up into a per-area and an overall percentage with a red, amber, or green rating - below 40% is Significant Gaps, 40 to 70% is Partial Maturity, and 70% or above is Substantially Embedded.

✅
Completing an assessment writes your answers back to the controls. A maturity of 4 marks the linked control implemented, 2 or 3 marks it partial, and 0 or 1 marks it not implemented. Run the assessment once and your controls list is populated for you.

The board report

From Reports, generate the MiCA Board Report as a Word document. It renders your coverage ring and per-area bars and walks the board through authorisation, governance, client asset protection, conduct, and market integrity - the readiness picture in a form a non-technical board and a competent authority can both read. Generating it needs the reports permission and an active MiCA entitlement.

Native controls, shared work with DORA

All 26 MiCA controls are native: they are crypto-market-specific and are satisfied directly, not inherited from another framework. The dashboard shows a native-versus-overlay split that other frameworks use to close controls through the cross-framework crosswalk; for MiCA the overlay side is empty, so nothing is auto-satisfied by unrelated evidence.

There is one important operational overlap. A CASP is also a DORA financial entity, so the ICT security and operational-resilience duties behind MICA-26, and the ICT continuity in MICA-10, are the same work you already do for DORA. You do not perform that work twice: you run your DORA resilience programme once and evidence MICA-26 directly against it, citing the same policies, testing, and incident-response arrangements. The crypto-specific duties - authorisation, reserves, custody segregation, white papers, redemption, and market-abuse surveillance - are MiCA-only and are never met by evidence from another framework.

⚠️
Venvera documents and tracks your MiCA programme. It does not hold client assets, execute transactions, or replace authorisation by a competent authority. Reserve attestations, custody reconciliations, and authorisation decisions are produced outside the platform and recorded as evidence against the controls.

Scenario: a crypto exchange works client asset protection

Nadia is Head of Compliance at a Frankfurt-based crypto exchange authorised as a CASP. She enables MiCA and starts on the gap assessment. The overall score lands amber - Partial Maturity - and the Client Asset Protection area is her weakest, sitting red.

She opens that area and walks its five controls. On MICA-11 she scores 2 (Developing): client funds are held at a credit institution, but segregation from the firm's own account is not yet fully evidenced. On MICA-12 she scores 3: there is a custody policy and a per-client register, but periodic client statements are still manual. MICA-14 and MICA-15 do not apply - the exchange issues no tokens of its own - so she will mark those Not applicable on the controls page rather than let them drag her score down.

When she completes the assessment, Venvera writes the answers back: MICA-11 and MICA-12 flip to partial, and the dashboard ring ticks up. Over the next fortnight her team attaches the segregation reconciliation and the automated-statement runbook as evidence, moves both controls to implemented, and Nadia generates the MiCA Board Report to show the audit committee that client-asset protection is now green - with the reconciliation and custody register cited as proof.