Crypto-Backed Investment Products: MiCA + MiFID II in One Onboarding

Crypto-backed investment products sit at an uncomfortable intersection. MiCA governs the cryptoasset layer. MiFID II governs the investment product layer. The customer sees one onboarding screen. The compliance team is accountable for two distinct regulatory frameworks — and the audit file has to reflect both.

VOVE ID helps EU issuers build onboarding flows that handle this stack without splitting the customer experience or collapsing the underlying control logic. This article covers where the two regimes divide, what that means for investor onboarding in practice, and where most crypto-backed product flows currently fail. For the foundational AML and KYC frameworks that apply across these structures, see the hub links below in the relevant sections.

Where MiCA covers the asset and MiFID II covers the product

MiCA establishes EU rules for cryptoassets and cryptoasset services — stablecoins, tokens, CASP licensing, reserve requirements. MiFID II remains the applicable framework when the product itself is a financial instrument or investment service: a structured note, a portfolio, a recommendation engine, a tokenised exposure to a traditional asset class.

The boundary is product-specific and fact-dependent. A USDC payment rail is not the same as a USDC-backed structured note sold to retail. A tokenised fund is not the same as a crypto exchange. Issuers that assume crypto settlement or tokenisation automatically places the entire product under MiCA — and nothing else — are building on a flawed premise.

For onboarding, the practical implication is that the customer file has to support whichever obligations actually apply. A crypto wallet or payment function creates AML and source-of-funds obligations. A structured note, portfolio management service, or investment recommendation creates suitability or appropriateness obligations under MiFID II. The same customer may face both tracks during a single onboarding journey — at different points, with different evidence requirements.

For a full breakdown of AML obligations in EU cryptoasset contexts, see our AML Requirements Explained 2026.

Two-stage structure: entry checks and product-fit checks

The most workable design separates the onboarding journey into two functional layers.

The entry layer covers identity, sanctions and PEP screening, country risk, and source-of-funds assessment where the risk model requires it. This layer runs for every investor regardless of which product they are accessing. It produces a verified identity record with associated risk signals.

The product layer determines whether a suitability or appropriateness assessment is required for the specific product and distribution context, then captures the data needed to support that decision. This is where the MiFID II logic lives — which product, which investor category, which questions, which disclosures, which version of the assessment.

The two layers do not require two separate customer journeys. Known identity, country, risk and funding data should carry through. What cannot be collapsed is the evidence trail: the product-layer assessment needs to be attributable to a specific product, distribution model, and investor interaction — not bundled into a generic "onboarding completed" record.

This structure also makes regulatory change manageable. A new collateral asset, a new distribution country, or a new execution model can update the product-layer controls without rebuilding the identity infrastructure underneath.

What actually goes wrong: the Dutch structured note example

Consider an issuer that launches a USDC-backed structured note to retail investors in the Netherlands. The customer flow looks clean — identity check, wallet connection, disclosure acknowledgement, subscription. One journey, fast completion, high conversion.

Then the AFM asks to review the onboarding records for a cohort of investors. The issuer can produce identity documents, wallet addresses, and signed disclosure confirmations. It cannot produce which version of the suitability assessment applied to this product, how the investor's answers influenced the decision, whether the USDC funding route was evaluated against any documented risk criteria, or who approved edge cases.

The AFM's question is not whether the customer completed an onboarding flow. It is whether the issuer can demonstrate that the applicable MiCA and MiFID II obligations were met at the point of sale, with evidence specific to that investor and that product. A clean UI is not an audit file.

The failure here is structural. One journey was built without separate, preservable control logic for the two regulatory layers it had to satisfy.

Building one flow with two control layers

VOVE ID is designed around this problem. Issuers can build a single investor experience where the compliance layers behind it are conditional, versioned, and independently auditable.

The platform collects identity and AML information first. Source-of-funds requests trigger based on transaction value, payment route, and customer risk signals — not uniformly applied to every investor. The product-specific investor assessment appears when the distribution model requires it, with the exact questions, disclosures, and decision rules recorded against the investor record.

Each step in the process — submitted data, documents, screening results, assessment questions, investor answers, decision logic, manual reviews, final status — is captured in a structured record. When the product changes, the controls update. The historical decisions remain tied to the version of the rules that applied when they were made.

That is the answer to what every regulator eventually asks during a review: not "did this investor onboard?" but "which obligations applied, what was collected, and why was this investor accepted for this product on this date?"

For the identity verification framework that underpins the entry layer, see our KYC Requirements Explained 2026.

Crypto-backed onboarding: what the file needs to show

• The asset layer: Which cryptoasset or payment route is involved, and what AML, screening, and source-of-funds obligations does it trigger.
• The product layer: Which MiFID II controls apply to this instrument and distribution model, and what evidence was collected to support the investor assessment.
• The investor record: Identity, AML, assessment, disclosures, and the final decision — in one connected file.
• Version control: Which version of the questions, disclosures, and rules applied at the time of the decision.

Q&A

Does MiCA replace MiFID II for crypto-backed products?

No. They address different subject matter. MiCA governs the cryptoasset. MiFID II governs the investment product or service. The applicable framework depends on the specific structure of the asset, product, and service. Issuers should get legal advice on their exact setup.

Can one onboarding flow support both sets of obligations?

Yes — if it is built as one orchestrated journey with separate, conditional control layers and a distinct evidence trail for each decision. A single screen sequence that records completion but not the underlying logic does not meet this standard.

Why do versioned assessments matter?

Because the questions, disclosures, and rules that applied at the time of a decision need to be retrievable as they were — not as they are now. Products change. Regulatory expectations change. The record has to reflect what was true when the investor was accepted.

What is the CASP transitional period deadline?

Under MiCA, the transitional period for crypto-asset service providers ends 1 July 2026. Firms relying on transitional arrangements need to have their licensing and compliance infrastructure in place before that date.

Conclusion

Crypto-backed investment products do not need two parallel customer journeys. They need one journey where the compliance logic behind each regulatory layer — MiCA for the asset, MiFID II for the product — is preserved separately, versioned, and auditable. The investor experience stays coherent. The audit file stays precise.

Running a crypto-backed investment product under MiCA and MiFID II and not certain your onboarding file would survive an AFM or BaFin review?

This article is intended for general informational purposes only and does not constitute legal, financial, or regulatory advice. KYC/KYB/AML requirements may vary depending on jurisdiction, industry, and specific business circumstances. For up-to-date and binding compliance obligations, readers should refer to the relevant regulatory authorities or consult qualified professionals.