DeFi regulation in Malta

MFSA and MDIA assess different subjects

The MFSA crypto-assets hub covers the Maltese framework for crypto-asset service providers and issuers under the Markets in Crypto-Assets Act, Chapter 647. Start there to identify the relevant financial service route and current application materials.

MDIA's Technology Assessment Recognition Framework concerns technology solutions and their controls. Its subject can be the technology used by a provider, but that does not make its recognition the provider's MiCA authorization.

Prepare the provider route around the actual services

MiCA Article 59 distinguishes CASPs authorized under Article 63 from specified financial entities using Article 60. Determine the applicant's status and each proposed service before selecting a form. An issuer application and a CASP application also have different subjects.

1. List the client actions the platform enables and the entity responsible for each.
2. Classify the assets and identify any financial-instrument or payment-services question requiring a separate analysis.
3. Open the MFSA application forms and rulebook from the current crypto-assets hub. Keep a copy of the version used.
4. Prepare governance, prudential and ICT evidence for the chosen route, including the third parties that support its operation.
5. Reconcile the application with client terms and deployed behavior before submission.

MiCA requires the authorization to identify the permitted crypto-asset services. The entity name and service permissions matter when checking a provider; a logo or a claim that a platform is based in Malta is not equivalent evidence.

The MFSA hub links the Maltese fee regulations separately from application forms. Use those official materials for a current fee calculation. The capital or insurance arrangements addressed by MiCA Article 67 and the cost of implementing controls are separate budget items. A statutory examination period is not a promise of the total elapsed time until authorization.

Choose a TARF level for a defined technology objective

MDIA describes four assessment levels: self-assessment at Level 0, a technology sandbox at Level 1, technology review at Level 2 and technology assurance at Level 3. Certification follows a successful Level 3 assessment; MDIA aligns its ITA Systems Audit for DLT with that level.

Before choosing a level, write a boundary statement for the solution. Name the deployment, interfaces, administrative roles and dependencies. Specify whether the assessment examines control design, implementation or evidence of operation. Ask which recognition the engagement can actually produce and how later changes affect its scope.

Keep the resulting document with the version of the solution it examined. A recognition covering one component should not be displayed as proof that every product feature or business process has been assessed.

Prepare evidence for the service and its dependencies

DORA Article 2(1)(f) includes MiCA-authorized CASPs in its scope. The following inventory is an editorial preparation aid. It helps separate technical observations from conclusions about regulatory status.

Pharos Production's guide to structuring a DORA ICT-provider register explains how contracts, provider identifiers and supported functions connect in the data model. That is useful when assembling the dependency evidence for a covered CASP. The register remains one part of the wider operational requirements.

Delegated Regulation 2025/299 also addresses service continuity when distributed-ledger problems are outside the provider's control. Document the response and client communication, including what the team can establish about the external outage.

Check the boundary before reusing a report

A team can publish open-source contracts, operate an interface and provide a client service in the same project. Assess those roles separately. MiCA Recital 22's fully decentralized, intermediary-free scenario is not established merely by using a permissionless blockchain.

For each assessment or application artifact, ask who commissioned it, what version it concerns and which decision it supports. Recheck the MFSA materials when the service set changes. Recheck the technology assessment boundary when the deployment changes.

Continue with the MiCA security obligations guide for the relationship between regulatory requirements and technical work, and the smart contract standards guide for assessment methods. Use the downloadable inventory to identify missing evidence before commissioning another report.