Security tokens in Spain: regulation and issuance steps

Security tokens represent rights associated with financial instruments through a digital record. In Spain, Law 6/2023 provides for securities to be represented using distributed ledger technology, or DLT. That connects issuance design with requirements for documentation, holder identification and administration of the register.

Understanding the framework requires distinguishing issuance from the services used to offer, hold or trade the security. Each activity has its own requirements, which the platform needs to reflect in its operation. Creating a token does not independently grant authorization or ensure a market where investors can sell it.

What security token means in Spain

Security token is a market term for a token representing a financial instrument. Treatment depends on specific rights and characteristics, not on using Ethereum, a private network or a token standard. Law 6/2023 recognises DLT representation while maintaining requirements for securities and their records.

Buying a token linked to property does not necessarily transfer registered ownership of that property. The right may be debt, a company interest or another contractual position. Documentation must explain it and identify the obligor.

A sequence for designing an issuance

1. Define rights and classification

Describe holder rights, potential payments, issuer obligations and transfer conditions. Assess the structure before programming. Article 2 of MiCA excludes financial instruments; changing a label cannot move them into a more convenient regime.

2. Identify the offering and participants

Determine countries, recipients and distribution channels. Assess documentation, prospectus requirements or exemptions for the specific offering. A prospectus exemption does not automatically remove other disclosure, distribution or investment service obligations.

3. Design recordkeeping and custody

Articles 6 to 8 of Spanish law set requirements for DLT representation, the issuance document and responsible entities. Check participant authorisations and distinguish recordkeeping, key custody, administration and technology development.

4. Implement and test controls

Define holder onboarding, transfers, restrictions, recovery, corporate events and contract upgrades. Test errors and rejected operations. Retain evidence of who can modify rules or move assets and under which procedure.

Secondary trading and liquidity

Technical transferability does not guarantee buyers, prices or an exit. Eligibility restrictions and market rules may limit operations. The DLT pilot regime applies to infrastructures with specific permissions; it does not make every platform an authorised market.

What investor documentation should explain

An issuance must identify the party owing obligations to the holder and describe the acquired right. For debt, relevant terms include maturity, interest, repayment conditions, security, and payment priority. For equity, the share class, voting and economic rights, and applicable restrictions matter. An interface displaying a balance and an expected return is insufficient.

Article 7 of Law 6/2023 connects the securities' rights with the issuance document. For DLT representation, it also requires information about the system's operation and governance. The document and smart contract should be understandable together without describing incompatible operations.

An issuance document and a prospectus address different requirements. Whether a prospectus must be published depends on the offer or admission and relevant exemptions. The absence of that requirement does not justify routinely removing the issuance document or the terms explaining the security's rights.

From subscription to exercise of rights

The operating process must cover more than investor onboarding. After subscription, the system needs to connect holder, address, and position, then handle transfers, restrictions, and events throughout the issuance. The registration role is examined in the guide to ERIR in Spain.

Consider a hypothetical debt issuance whose terms provide for periodic payments. Calculating a payment requires determining which positions qualify, when that reference is taken, and how exceptions are handled. A contract can automate part of the calculation or execution, but needs the funds and instructions defined by the product model.

Payments through an external channel require reconciliation between records. Marking a payment complete in an interface does not establish that the holder received the money. Tests should include rejected and duplicate payments and incomplete information, alongside the successful workflow.

Testing an issuance before deployment

A useful technical review starts with concrete properties. For example, an account without issuance permission must not create securities, a restricted position must not move through an alternative function, and recovery must preserve the link between holder and position. These are examples of acceptance criteria; configuration depends on the agreed structure.

Test what happens when contracts are upgraded or administrators change. Delivery should identify versions, addresses, permissions, and procedures. Assess an audit report against that scope and verify that it corresponds to the deployment, rather than merely a similar repository.

These checks supply evidence about system behavior. Issuer solvency, valuation of rights, and the availability of buyers remain separate questions, even when every technical test passes.

What to check before appointing providers

Request a responsibility map, regulatory sources, asset documentation and operating costs. Check entities against official registers and interpretations against CNMV questions and answers. Avoid proposals that promise full compliance merely by deploying a contract.

Legal assessment of the transaction and technical review of software address different risks. The issuer must maintain information and procedures throughout the instrument's life, beyond preparing its launch.

To develop the design, see MiFID II and tokenization: classification, services and limits and how a tokenization project is implemented.