DeFi regulation & security
DeFi regulation in Spain
Start with the exact legal entity and its current permission. This guide separates provider verification, token disclosure and the security checks needed before an integration.
- Sources checked
- Published
- Prepared by
- DeFi Security Alliance
Scope: Provider authorization, token classification and security evidence. Tax, individual legal advice and a complete analysis of every financial-services regime are outside this guide.
Check the provider's current status in Spain
The CNMV MiCA guide states that the Spanish transition has ended and points readers to current CNMV and ESMA provider registers. Check the legal entity supplying the service, the permission and the services covered. A familiar brand name is insufficient.
For an applicant, MiCA Articles 59 to 63 distinguish authorization from notification for eligible existing institutions. For a customer or integration team, the practical task is to establish which entity is on the other side of the contract. Keep these two tasks separate in a review file.
A DeFi label cannot answer either question. Document the customer relationship, key control, order handling and upgrade powers before assessing whether the activity falls within a regulated service. MiCA's recital 22 explains the distinction concerning fully decentralized services without an intermediary.
Create a provider verification record
The following DeFiSec worksheet is a repeatable due-diligence method. Complete it against current official records and the actual service contract. It is not a list of approved providers.
| Check | Record to retain | Reason to investigate |
|---|---|---|
| Legal entity | Contracting name, identifier and register entry | The website brand and contract name refer to different group companies |
| Permission | Current authority record and date checked | Only an old registration or an application receipt is supplied |
| Service scope | Authorized services compared with the proposed integration | The product includes custody or transfers absent from the stated scope |
| Cross-border service | Home authority and relevant notification information | A domestic permission is presented as proof of every cross-border activity |
| Token information | Asset classification, white paper where applicable and contract address | The documentation concerns a different token, issuer or deployed contract |
Retain a dated reference or permissible copy of each source consulted. Recheck when the entity, service or supported token changes. An entry in a register cannot establish that a particular smart contract has been audited or that the integration is operationally safe.
Review the token independently of the provider
CNMV publishes resources for provider authorization and notification, and for crypto-asset white papers. Use the appropriate document for the activity. A provider permission and a token disclosure address different subjects.
MiCA Article 2 excludes assets qualifying as financial instruments from its scope. For a tokenized asset, record the rights attached to the token: payment claims, redemption, governance, transfer conditions and any interest in an underlying instrument. Classification must precede the choice of a MiCA disclosure route.
Once the legal classification is established, the engineering team can turn relevant transfer and eligibility rules into verifiable behavior. Pharos Production's guide to implementing compliance controls for tokenized real-world assets is useful for that technical discussion. Apply the EU-relevant analysis to the chosen legal structure; a software control does not determine the classification.
For Title II crypto-assets, Article 8 does not require prior approval of the white paper. Treat notification, publication and authorization as distinct events. Match the disclosure to the supported asset and retain its version.
Check security before the integration goes live
After resolving legal scope, review the technical connection. Identify who can pause transfers, rotate keys and reconcile balances. Test a supplier outage and document the customer impact. DORA and the CASP continuity requirements provide the regulatory context for in-scope providers; the test must reflect the service actually offered.
Keep regulatory status, disclosure review and technical findings in separate columns of the same decision record. This makes an unresolved contract vulnerability visible even when the provider's authorization has been confirmed. The security tools directory supports selection of testing and monitoring tools for that work.
Continue your research
Sources and further reading
Legislation and regulator publications establish the legal basis. Technical resources explain implementation. Source checks cover the passages cited in this guide.
- MiCA — Regulation (EU) 2023/1114European Union ·
- DORA — Regulation (EU) 2022/2554European Union ·
- CASP business continuity — Delegated Regulation (EU) 2025/299European Commission ·
- MiCA: nueva regulación de criptoactivosCNMV ·
- RWA compliance controlsPharos Production ·