DeFi regulation in Estonia

Use the Finantsinspektsioon route

The Finantsinspektsioon authorization guide directs CASP applications to its application portal from 18 March 2026. Use the current portal instructions and the documents for a CASP, rather than copying the separate ART issuer procedure on the same page.

The 30 June 2026 transition notice records the end of the earlier RAB regime and restrictions on unlicensed providers' active business. A pending application does not allow new customer acquisition while waiting for approval. Check the current license or eligible institutional route and any cross-border basis.

A DeFi service still requires an activity analysis: identify custody, execution, transfer and control of the interface. The fully decentralized case in MiCA Recital 22 cannot be established from the use of smart contracts alone.

Separate language, fee and assessment stages

The CASP subsection requires an Estonian application. An applicant wishing to provide accompanying documents in English must explicitly request this in the application. Prepare the language request and a clear attachment index together.

The published processing fee is EUR 3,000. This is a procedure fee, not the prudential safeguard required by MiCA Article 67 and not an estimate of the total cost of authorization. Keep capital, the application fee and supplier expenditure in separate budget lines.

The guide distinguishes a 25-working-day completeness check from a 40-working-day assessment of the complete CASP application, with a possible specified suspension of up to 20 working days. ART assessment periods differ. Do not use either timetable as a guaranteed launch date.

Prepare the portal evidence package

This DeFiSec worksheet organizes material for the CASP route. The portal and official forms determine the required submission format.

For supplier records supporting the ICT description, Pharos Production's DORA register implementation guide explains how to join contract, entity and service information. Keep this register consistent with the architecture submitted through the portal.

Reconcile the permission with the deployed product

Keep inactive services out of customer onboarding until their permission is established. A planned custody feature or a changed execution model should trigger another scope check. Where an older service is being closed or restricted, preserve a controlled route for customer information and asset return.

Test operational recovery with the actual wallet, ledger and reconciliation dependencies. Record observed results and unresolved failures. A written continuity policy and a code audit answer different questions. Neither alone demonstrates that the provider can recover the service. See the EU evidence guide for the broader control inventory.