Describing a Registries Reference Architecture for Governed Registries: Using Barcelona's Padró

Whole-of-Government requires more than Building Blocks

In an earlier post I documented how four different digital identities can be used to complete one municipal procedure in Barcelona — the Padró Municipal d’Habitants, the register of residents. That post looked at the identity side of the story. This one steps back to look at the procedure itself, because the padró is a perfect example of something GovStack has not, until now, had a good word for: a governed registry.

In GovStack we describe reusable software components called Building Blocks. The Registry Building Block specifies what a registry component must do — store records, manage their lifecycle, expose them through an API.¹ But a register of residents is not just a database. The Barcelona padró only works because:

• A law says the register must exist, and puts someone in charge of keeping it;
• A national body reconciles every municipality’s copy so a person cannot be registered in two places at once;
• Everyone agrees on the minimum set of fields a resident record must contain;
• There exists a whole layer of shared digital infrastructure — electronic identities, electronic signatures, certificate validation — lets residents prove who they are and lets the resulting certificate be trusted anywhere in the country.

Take any one of those away and the registry stops being trustworthy. In the blog-post Achieving technical interoperability in government systems: From Protocol to Whole-of-Government² Vaher, Lüeck and Ramkumar define whole-of-government interoperability as being achieved “once all parties agree on how data is being exchanged and used”. While gathering data and managing is achieved by the Registration BB and the Registries BB, achieving Whole-of-Government interoperability for a Registry, say, making a registry achieving the status of a trusted registry, and being referred-to by other parties as the single source of truth requires something beyond the Building Blocks.

This piece is provided as part of a wider conversation on Reference Architectures in the context of GovStack that extend the PAERA document, specially on its chapter 2, on Reference Architectures³, as well as GovStack’s general Interoperability Framework⁴. It is part of an ongoing conversation on adjusting the GovStack approach to interoperability. It exemplifies what the term Reference Architecture would do for governed Registries, and how to use it to describe specific instances of it, in this case Spain’s Residents registry.

What is a Reference Architecture?

Borrowing from the international standard for architecture description (ISO/IEC/IEEE 42010⁵) and from one of the best-known examples of the genre, the Industrial Internet Reference Architecture⁶, a Reference Architecture is reusable guidance for a whole class of related systems. It is not software and it is not a single country’s implementation. It describes the moving parts a system in that class may or may not have, and lets each government decide how to assemble them.

A GovStack Reference Architecture describes those parts through four viewpoints — the same interoperability layers GovStack already uses to talk about whole-of-government interoperability⁴:

• Governance — the legal basis (what authorises the system to exist) and the organisational arrangement (who is responsible for what);
• Semantic — what the data means: the shared fields, vocabularies and schemas;
• Technical — how the systems actually talk: the protocols, APIs and exchange patterns;
• Infrastructure — the shared prerequisites everything relies on: identity systems, signature services, trust anchors, registries.

The same registry pattern, described once, can then be applied at national, regional or municipal level. Barcelona applies it municipally — and that is exactly what makes it such a clear worked example.

The Governed Registries Reference Architecture

A governed registry is a register whose existence, custody and reconciliation are defined by rule, so that records kept locally carry trust globally. At the centre is a registry; around it sit the four viewpoints that make it governed:

graph TD                                                                                 
    GOV["GOVERNANCE viewpoint\nLegal: a law creates the registry & assigns custody\nOrg: 
         who gathers, who reconciles, who issues"]                                                
    SEM["SEMANTIC \nviewpoint\nminimum record fields & meaning"]                           
    REG["REGISTRY (BB)\nat the centre"]                                                  
    INF["INFRASTRUCTURE \nviewpoint\nidentity, signature, trust anchors"]                  
    TEC["TECHNICAL \nviewpoint\nhow copies are exchanged,\nauthenticated and certified"]   
    GOV <--> REG                                                                         
    SEM <--> REG                                                                         
    REG <--> INF                                                                         
    TEC <--> REG  

The Registry Building Block is autonomous — it can be specified and tested on its own. But to deliver a governed registry it depends on the four viewpoints around it. Let us walk through each one using the Barcelona padró.

Governance — Legal: a law brings the registry into being

The padró is not a product someone decided to build; it is a register the law requires. Ley 7/1985 (Reguladora de las Bases del Régimen Local, LBRL) establishes the Padrón Municipal as a mandatory register in every municipality (Article 15) and states what it is for.⁷ Ley 4/1996 then modernised it into the padrón continuo — a permanently maintained, computerised register rather than a periodic census.⁸

The crucial governance move is in Article 17 LBRL: it makes municipalities responsible for creating and maintaining their own padrón, and it gives a single national body the duty to coordinate and reconcile all of them. A law that would otherwise produce thousands of disconnected local lists instead produces one coherent national infrastructure. This is the defining feature of a governed registry: custody is local, but the rules and reconciliation are shared.

Governance — Organisational: who gathers, who reconciles, who issues

The legal text translates into clear institutional roles:

Role in the Reference Architecture	Who plays it in Barcelona
Registrar (gathers and maintains records)	The Ajuntament de Barcelona, like every other Spanish municipality
Reconciliation authority (deduplicates across registrars)	The Instituto Nacional de Estadística (INE) — it ensures nobody is registered in two municipalities and maintains the authoritative national record9
Certificate issuer (produces trusted proof for residents)	The Ajuntament, issuing the certificat d’empadronament under its own institutional seal10
Relying parties (consume the certificate)	Schools, the health service, immigration, courts, banks — anywhere in Spain and the EU

This division of labour is the answer to the question “who is in charge?” — and it is reusable. Any governed registry needs a registrar, a reconciliation authority and a way to issue trusted proof; the Reference Architecture names those roles so another country can fill them with its own institutions.

Semantic — the minimum fields a record must contain

For local registers to reconcile into one national record, they must agree on what a resident record is. Ley 4/1996 set the mandatory minimum content of every padrón entry (amending Article 16 LBRL).⁸ Every municipality, regardless of its software, must capture at least:

• Name and surnames
• Sex
• Habitual address
• Nationality
• Place and date of birth
• National identity document number (DNI) — or, for foreign nationals, the equivalent document (NIE / passport)
• Academic or school qualification held
• Any further data needed for the electoral census, subject to fundamental-rights safeguards

This list is the semantic layer. It is the shared vocabulary that lets the INE merge Barcelona’s records with Girona’s, and lets a certificate issued in one municipality be understood everywhere. In GovStack terms, this is the data model the Registry Building Block must hold — but the authority for that model lives in the law, not in the software.

Technical — how the copies are exchanged, authenticated and certified

The technical viewpoint covers how the systems actually communicate:

• Registrar → reconciliation authority. Every change a municipality makes is transmitted to the INE. Real Decreto 141/2024 moved this from monthly batches to real-time updates, so the national record is always current.⁹
• Resident → registrar. A resident registers or requests a certificate online through Barcelona’s Seu Electrònica, authenticating with any accepted electronic identity. The identity federation that makes this possible — the AOC’s VALId gateway and the national Cl@ve gateway — is the subject of the previous post.¹¹
• Certificate → relying party. The certificate the Ajuntament issues carries a Código Seguro de Verificación (CSV) and an electronic seal, defined by Ley 39/2015, so any third party can confirm it is genuine online — making a digital certificate as valid as a paper original.¹²

These are the contracts and patterns of the architecture. They are deliberately separable from the infrastructure that fulfils them, which is the last viewpoint.

Infrastructure — the shared prerequisites that make trust possible

This is the layer the user of the registry never sees but cannot do without. For Barcelona’s padró to be created with a reliable identity and certified in a way others trust, Spain provides a stack of shared, reusable digital infrastructure:

• Electronic identity systems — DNIe, Cl@ve, the FNMT certificate and Catalonia’s idCAT Mòbil — so a resident can prove who they are when registering, even with a local identity like idCAT Mòbil;
• Electronic signature and seal services — Cl@ve Firma, the FNMT and DNIe certificates — so submissions can be signed and certificates sealed with legal force;
• Trust anchors and validation infrastructure — the @firma platform, the Spanish Trusted List and the EU Trust Service Status List — so any signature or seal can be validated against a recognised root;
• The national register itself — the INE’s coordinated database — and the municipal electronic offices that connect to it.

Notice that these are not part of the registry; they are shared infrastructure the registry leans on. The same identity and signature infrastructure serves tax filing, healthcare and dozens of other procedures. This is precisely why a governed registry is a systemic achievement: it reuses infrastructure that already exists for the whole government.

Putting it together: the Building Blocks around the registry

Mapping the architecture back to GovStack makes the dependency explicit. The Registry Building Block is at the centre, but it is enabled by others:

Viewpoint	Barcelona instance	GovStack Building Block
Registry (centre)	The padró municipal — records of residents	Registry BB — record storage, lifecycle, API1
Infrastructure	idCAT Mòbil and other eIDs prove the resident’s identity at registration	Identity BB — federated identity, upstream federation13
Infrastructure	Cl@ve Firma / FNMT / DNIe sign submissions and seal certificates	eSignature BB14
Technical / Governance	Data shared between Ajuntament and INE under the LBRL and data-protection law	Consent BB for downstream disclosure of the certificate15
Infrastructure (trajectory)	The empadronament certificate becomes a verifiable credential in the EUDI Wallet	Wallet BB16

The arrow worth remembering points inward: the registry is the point of the exercise, but it is only trustworthy because the legal, organisational, semantic, technical and infrastructure pieces around it are all in place.

Why describe it this way?

Naming these parts as a Reference Architecture does three useful things:

1. It makes the pattern portable. A government that wants a trustworthy population register can ask: do we have a law that creates it and assigns custody? a body that reconciles copies? an agreed minimum record? identity and signature infrastructure to lean on? Those are the same questions whether the register is run nationally or, as in Barcelona, municipally.
2. It keeps Building Blocks honest about their boundaries. The Registry BB stays small and reusable; the Reference Architecture, not the BB specification, carries the legal and organisational context.
3. It tells you what is missing. If a country has the Registry BB but no reconciliation authority, the Reference Architecture shows you the gap before it becomes a duplicated-records problem.

The Barcelona padró is one implementation of a Governed Registries Reference Architecture. The next step is to write that Reference Architecture down properly — its roles, its viewpoints and the contracts between them — so that it can be reused well beyond Spain. That is the work this blog is building towards.

---

Sources consulted

• Instituto Nacional de Estadística. “Padrón Municipal — Legislación.” https://idapadron.ine.es/repositorio/legislacion/a2301alt.htm.
• Ajuntament de Barcelona. “Registration at the Municipal Register of Residents.” Barcelona International Welcome. https://www.barcelona.cat/internationalwelcome/en/registration-municipal-register-residents-city-barcelona.
• GovStack Initiative. GovStack Architecture — 4. Interoperability Architecture. https://specs.govstack.global/architecture/4-interoperability-architecture.

---

References