ERIR in Spain: roles and requirements for tokenized securities

A tokenized securities issuance needs a system that identifies holders, records transfers, and supports the rights attached to each security. In Spain, the entity responsible for administering registration and recordkeeping, known as an ERIR, has legal responsibilities over that register when securities are represented using distributed ledger technology, or DLT.

Designing an issuance requires understanding what this entity controls and how its work connects to smart contracts. Network selection, administrative permissions, and position recovery must reflect the legal structure of the security. This guide separates statutory requirements from implementation decisions that the project participants need to agree. Responsibilities must also be defined for a lost key, a disputed transfer or a holder’s request to exercise their rights.

What an ERIR is and when it is involved

Article 8.4 of Law 6/2023 governs the entities responsible for administering registration and recordkeeping for transferable securities represented using DLT. The role belongs to securities regulation. It is neither a quality label for any token nor a designation that a software provider acquires simply by developing smart contracts.

The starting point is the instrument's classification and applicable law. Among other situations, Article 5 addresses a valid choice of Spanish law for the registration, transfer, and representation of securities. Neither the location of network nodes nor a token's commercial name is sufficient to determine the regime of an issuance.

Once that legal framework is established, Article 6 permits DLT representation and requires the system to identify holders, determine their securities, and preserve the integrity of the issuance. Those functions must be addressed before a deployed token can be treated as a completed securities issuance.

Who can perform the role

The issuer appoints one or more responsible entities in the issuance document. The law allows the issuer itself to perform the role, but in all cases requires the relevant authorization for the activity in Article 126(a). Being the issuer does not automatically provide that authorization.

Questions 12 and 13 in the CNMV guidance explain how securities custody authorization, administrative procedures, and the ERIR register for issuances relate. Check both the entity's authorized activities and its appointment for the particular issuance. A trading name or a general claim to be regulated does not establish that scope.

For securities admitted to trading on DLT infrastructures, Article 8.5 assigns responsibility to market infrastructures authorized under the applicable European rules. This situation must be assessed separately from an issuance not admitted to trading. Appointing an ERIR for registration does not authorize the promoter to operate a trading venue.

The issuance document defines the security and the system

Article 7 requires identification of the securities and the responsible entity. For DLT, the document must contain sufficient information about the system's operation and governance. The issuer deposits a copy with the responsible entity; both must make it available to holders and interested members of the public under the statutory requirements.

The technical consequence is that the documentation must describe the system that will actually operate. If a contract can freeze a position, change an implementation, or reassign powers, those capabilities belong in the governance assessment. Documenting ordinary transfers while leaving administrative powers outside the design is insufficient.

A useful implementation practice is to map each operation to its responsible party, permission, evidence, and exception procedure. For instance: who requests a correction, who checks its grounds, who authorizes execution, and how the action remains traceable. This matrix does not replace the legal document; it helps establish whether the software can support it.

Holders, positions, and transfers

Article 8.4 assigns the ERIR responsibility for managing holder identification, corporate events, entries, and encumbrances. Article 10 provides for the constitution of DLT-represented securities through their first registration in favor of the issuer or subscribers. Article 11 governs the effects of a recorded transfer.

A blockchain address is a technical identifier, but does not by itself explain who is entitled to exercise the rights. Article 13 contemplates both the ultimate beneficiary and an authorized entity acting on behalf of its clients, with that capacity recorded. The architecture must correctly reflect the selected holding model.

In practice, identities, addresses, and positions need to be connected without assuming each person uses just one wallet. A transfer to another holder must also be distinguished from an address change for the same holder. Both may move tokens, but involve different legal circumstances and procedures.

Encumbrances, inheritance, and entitlement certificates

Article 12 requires mechanisms to register matters such as attachments, judicial enforcement, transfers following death, and other encumbrances. An implementation restricted to minting and transferring tokens between addresses leaves these operations unresolved.

Each situation needs a connection between a legally valid instruction and its technical execution. The system does not decide whether a court order is authentic or who is entitled to inherit. Procedures and responsible parties must check the documentation before acting on the register.

Article 14 governs certificates of entitlement and their issuance conditions. Designing this function requires establishing which rights a certificate evidences, how it remains consistent with the register, and how applicable restrictions are handled while it is valid. An explorer screenshot or a PDF generated by an interface does not automatically constitute that certificate.

Registration and private-key custody

Administration of the register and custody of private keys are related but distinct matters. Identify who holds the keys used to instruct operations and who has the powers required to maintain the register correctly. CNMV question 27 addresses this distinction and recovery of positions.

The technical design should separate investor keys from administrative keys. It should also define revocation, replacement, and operator access controls. A key that can change restrictions or execute recoveries needs controls appropriate to those powers, even if it is not used for ordinary transfers.

A lost wallet also creates an identification problem. Before acting, the responsible parties must establish who is entitled to the position and which address may receive it. The solution should not depend on an improvised intervention by the developer. The workflow must be agreed, documented, and tested before holders are onboarded.

The technology provider's role

The development team implements the agreed functions, integrates systems, and supplies evidence of their behavior. The ERIR retains its legal responsibilities when using third-party software. Service agreements, access arrangements, and operating procedures should reflect that separation.

Acceptance criteria should cover issuance, permitted and rejected transfers, position restrictions, permission changes, and recovery. They should include failures: duplicate instructions, incomplete information, an unavailable network access provider, or discrepancies between the interface and the register.

A token standard may supply components for particular controls. Choosing it does not establish that an issuance complies with the law. A code audit does not validate the issuance document or authorize a financial activity either. The guide to what a smart contract audit demonstrates explores that distinction.

Register continuity and liability

Article 5.2 of Royal Decree 814/2023 requires a contingency plan to manage incidents and maintain register continuity if the network fails or becomes unviable. Backing up the interface database alone does not address that requirement.

As an operational response to that objective, the project should test which information is needed to reconstruct positions, who declares a contingency, and how the history of actions is preserved. If migration to another network is contemplated, specify how the valid state is established and how incompatible active representations of the same issuance are prevented.

Liability also has an express legal basis. Article 8.6 provides for liability toward parties harmed by omitted, inaccurate, or delayed registrations and by intentional or negligent breaches of legal obligations. This does not make the ERIR a guarantor of the issuer's solvency or the price of the securities; it defines responsibility for its role.

Hypothetical example of a debt issuance

Suppose a company is preparing a DLT-represented debt issuance governed by the Spanish regime. This example connects the roles; it does not describe an actual transaction or settle the legal conditions of a particular offer.

The rights attached to the security, its economic terms, and transfer rules are defined first. The issuer appoints the authorized entity and prepares the issuance document. The technology provider translates the agreed requirements into verifiable permissions and operations, with acceptance criteria for each workflow.

During subscription, the system connects the holder to their position and records the securities. A later transfer request is checked against the applicable conditions. If the holder reports losing wallet access, a recovery procedure uses identity checks and documented authorization instead of treating the request as an ordinary transfer.

When an economic event must be processed, holders, positions, and entitlements are reconciled against the issuance documentation. If an incident occurs, the ERIR and other participants act within their responsibilities and agreed plan. The outcome should be reconstructible from evidence, rather than only from what a screen displays.

Assessing an ERIR and preparing integration

Start with legal identity, authorization, and scope for the proposed issuance. Then examine how work is allocated among issuer, ERIR, key custodian, and technology provider. When one entity supplies several services, each function should remain identifiable.

The commercial proposal should distinguish setup, register maintenance, corporate events, support, integrations, and possible exceptional interventions. There is no single price that can be inferred from the law. Comparing proposals requires understanding volume, complexity, responsibilities, and exit arrangements.

Before deployment, the team should be able to demonstrate a complete registration, transfer, restriction, and recovery workflow, identifying responsible parties and evidence. Offering, distribution, and trading require their own assessment, covered in the article on security tokens in Spain. A tokenization project must connect those decisions to an architecture that can operate throughout the life of the security.