What Is Digital Public Infrastructure

Digital Public Infrastructure (DPI) represents a paradigm shift in how government digital services are designed. Instead of building monolithic solutions for each individual public service, the DPI approach calls for creating shared, modular, and interoperable building blocks that any service — public or private — can reuse. The most effective analogy is physical infrastructure: just as roads, power grids, and water systems are shared platforms upon which diverse services are built, DPI provides the “digital rails” on which verified identities, instant payments, and secure data exchanges run.

As of 2025, at least 64 countries have DPI-type digital identity systems, 97 countries have interoperable digital payment systems, and 103 countries have structured data exchange frameworks. DPI is no longer a theoretical concept: it is operational infrastructure touching billions of people.

Formal Definition of DPI

According to UNDP and the G20, Digital Public Infrastructure is defined as a set of shared, open, and interoperable technology platforms that enable the delivery of digital services at national scale. DPI components are designed as software code, platforms, applications, and APIs that are modular in nature and can be combined to create a complete technology stack.

How DPI Differs from Traditional e-Government

Traditional e-Government has produced silos: each ministry builds its own system with its own user database, its own authentication mechanism, and its own payment gateway. The result is duplication, incompatibility, and exponential costs. DPI flips this logic: build the foundational blocks once, and the entire ecosystem reuses them.

Aspect Traditional e-Government DPI Approach
Architecture Monolithic, per-service Modular, building-block based
Identity Separate databases per agency Shared identity layer
Payments Proprietary gateways Interoperable payment rails
Data Point-to-point exchange Standardized data exchange layer
Marginal Cost High (each service from scratch) Low (building block reuse)
Time-to-Market Years Weeks/Months
Vendor Lock-in High Reduced (open standards)

The Three Foundational Pillars of DPI

Every DPI implementation is built on three interconnected pillars that, combined, create a complete digital ecosystem. These pillars are not independent: their power emerges from synergy.

1. Digital Identity

The first pillar is the ability to uniquely verify the identity of every citizen, business, or device in the ecosystem. Without a robust digital identity system, no other service can function securely. DPI digital identity must be: universal (covering the entire population), verifiable (with cryptographic proofs), minimal (sharing only necessary data), and interoperable (working across different agencies and services).

2. Digital Payments

The second pillar enables real-time economic value exchange between any pair of actors in the ecosystem. A DPI payment rail is not simply a gateway: it is an open infrastructure that allows any bank, fintech, or institution to send and receive instant payments through standardized APIs. The reference model is UPI in India, which in January 2026 processed 21.7 billion transactions worth over 28,330 billion rupees.

3. Data Exchange

The third pillar provides a secure, standardized layer for information exchange between different systems, respecting user consent and privacy regulations. A DPI data exchange framework ensures that data flows where it is needed, when it is needed, with complete traceability and end-to-end encryption.

The Synergy of the Three Pillars

When a citizen applies for a government subsidy, the three pillars work together: digital identity verifies who the applicant is, data exchange retrieves the necessary data (income, residence, family status) from various sources without requiring the citizen to produce paper documents, and digital payment disburses the subsidy directly to the bank account in real time. What traditionally required weeks of bureaucracy is completed in seconds.

India Stack: The Global Reference Model

India Stack is the most mature and studied DPI case in the world. Launched progressively from 2009, it represents an ecosystem of digital infrastructure serving over 1.4 billion people. Its success has inspired the G20, the United Nations, and dozens of countries to replicate the model. As of 2025, India has exported UPI technology to over 25 countries.

Aadhaar: Biometric Identity at National Scale

Aadhaar is the largest digital identity system in the world, with over 1.3 billion enrollments. Each resident receives a unique 12-digit number linked to their biometric data (fingerprints and iris scan). Aadhaar’s architecture is built on security-by-design principles: biometric protocols were embedded into the infrastructure from conception, not added retroactively.

The Aadhaar verification API exposes an authentication endpoint supporting three modes:

# Aadhaar Authentication API - Verification Flow

# 1. Demographic Authentication
POST /api/v2/auth/demographic
Content-Type: application/xml
{
  "aadhaar_number": "XXXX-XXXX-XXXX",
  "name": "...",
  "dob": "YYYY-MM-DD",
  "gender": "M|F|T",
  "address": {
    "house": "...",
    "street": "...",
    "pincode": "XXXXXX"
  }
}

# 2. Biometric Authentication (Fingerprint/Iris)
POST /api/v2/auth/biometric
{
  "aadhaar_number": "XXXX-XXXX-XXXX",
  "biometric_data": {
    "type": "FIR|IIR",   # Fingerprint / Iris
    "position": "LEFT_INDEX",
    "data": "<base64_encoded_biometric>"
  },
  "device_info": {
    "device_id": "...",
    "rdsv": "...",        # Registered Device Service version
    "mi": "...",          # Model Info
    "mc": "..."           # Machine Code (signed)
  }
}

# 3. OTP-based Authentication
POST /api/v2/auth/otp/generate
{ "aadhaar_number": "XXXX-XXXX-XXXX" }

POST /api/v2/auth/otp/verify
{
  "aadhaar_number": "XXXX-XXXX-XXXX",
  "otp": "XXXXXX",
  "txn_id": "..."
}

# Response (common to all methods)
{
  "status": "Y|N",
  "auth_token": "...",
  "txn_id": "...",
  "err_code": null,
  "info": {
    "auth_type": "DEMO|BIO|OTP",
    "timestamp": "2026-03-09T10:30:00Z"
  }
}

UPI: Interoperable Instant Payments

The Unified Payments Interface (UPI) is the real-time payment rail developed by NPCI (National Payments Corporation of India). UPI’s architecture is built around a central switch that interconnects all banks and Payment Service Providers (PSPs) in the country, enabling instant, 24/7, zero-cost bank-to-bank transfers.

UPI’s layered architecture comprises:

  • App Layer: user-facing applications (Google Pay, PhonePe, Paytm, BHIM)
  • PSP Layer: Payment Service Providers that handle transactions on behalf of banks
  • NPCI Switch: the core infrastructure that routes transactions between different banks
  • Bank Systems: participating banks’ core banking systems
  • Authentication Layer: device binding, encrypted PIN, and multi-factor verification
  • Settlement Layer: interbank settlement in multiple daily cycles
# UPI Architecture - Transaction Flow

# 1. User initiates payment from the app
# 2. Request reaches the PSP (Payment Service Provider)
# 3. PSP forwards to NPCI Central Switch
# 4. Switch identifies the destination bank
# 5. Destination bank confirms fund availability
# 6. Switch completes the transaction and notifies both parties

# Simplified technical flow:

[Payer App] --> [Payer PSP] --> [NPCI UPI Switch] --> [Payee PSP] --> [Payee Bank]
     ^                              |                                      |
     |                              v                                      v
     |                     [Transaction Log]                    [Credit Account]
     |                              |
     +--------- [Response: Success/Failure] <--------+

# Collect Request API (simplified example)
POST /upi/v2/collect
{
  "payer_vpa": "user@bankpsp",
  "payee_vpa": "merchant@bankpsp",
  "amount": {
    "value": "500.00",
    "currency": "INR"
  },
  "txn_note": "Payment for order #12345",
  "txn_id": "TXN202603091030ABC",
  "device_fingerprint": "...",
  "encrypted_pin": "<encrypted_upi_pin>"
}

# Response
{
  "status": "SUCCESS",
  "txn_id": "TXN202603091030ABC",
  "rrn": "631012345678",   # Retrieval Reference Number
  "approval_number": "ABC123",
  "timestamp": "2026-03-09T10:30:05Z",
  "payer_vpa": "user@bankpsp",
  "payee_vpa": "merchant@bankpsp",
  "amount": "500.00"
}

DigiLocker and ONDC: Data Exchange and Open Commerce

DigiLocker is the document exchange platform that allows Indian citizens to store and share official documents (driver’s license, school certificates, health cards) in verifiable digital format. The architecture is based on a consent-based sharing model: the document is never copied; instead, a verifiable link to the original is provided, with temporal validity controlled by the holder.

The Open Network for Digital Commerce (ONDC) extends the DPI paradigm to e-commerce, creating an open protocol that separates search/discovery platforms from sellers and logistics services, eliminating the monopoly of closed platforms.

Real-World Impact of India Stack

  • Aadhaar: 1.3+ billion enrollments, 100+ billion authentications performed
  • UPI: 21.7 billion transactions/month (Jan 2026), exported to 25+ countries
  • DigiLocker: 200+ million users, 6+ billion documents issued
  • Savings: over $33 billion saved in direct transfers (intermediary elimination)
  • Inclusion: 500+ million bank accounts opened via Jan Dhan Yojana + Aadhaar

The European Approach: eIDAS 2.0 and EUDI Wallet

Europe is building its own DPI with a different approach from India: where India Stack was born from a need for financial inclusion in a country with limited infrastructure, the European approach starts from protecting fundamental rights, privacy-by-design, and digital sovereignty. The eIDAS 2.0 Regulation (EU Regulation 2024/1183) is the legislative pillar that requires every Member State to provide a digital identity wallet to its citizens by December 2026.

EUDI Wallet: Architecture and Principles

The EU Digital Identity Wallet (EUDI) is designed according to principles that are fundamentally different from centralized systems:

  • Local storage: data resides on the user’s device, not on central servers
  • User control: the user decides which information to share and with whom
  • Zero tracking: the design ensures no actor can profile the user
  • Privacy dashboard: complete transparency on how and with whom information is shared
  • Free of charge: issuance, use, and revocation free for all natural persons
# EUDI Wallet - Simplified Architecture

# Main Components:

[Citizen Device]
    |
    +-- [EUDI Wallet App]
    |       |
    |       +-- [Credential Store]     # PID, attestations, certificates
    |       +-- [Crypto Engine]        # Private keys, digital signature
    |       +-- [Privacy Dashboard]    # Sharing logs, revocations
    |       +-- [Consent Manager]      # Granular consent management
    |
    +-- [Secure Element / TEE]         # Hardware-backed key storage

# Verifiable Presentation Flow
# 1. The Relying Party requests specific attributes
# 2. The Wallet shows the user what is being requested
# 3. The user selectively approves/denies
# 4. The Wallet creates a signed Verifiable Presentation
# 5. The Relying Party verifies the signature and validity

# Example: Age verification without revealing date of birth
POST /wallet/v1/presentation
{
  "verifier_id": "bar-nightclub-001",
  "requested_claims": ["age_over_18"],
  "purpose": "Age verification for entry",
  "nonce": "abc123xyz",
  "response_uri": "https://verifier.example.com/callback"
}

# Wallet Response (selective disclosure)
{
  "vp_token": "<signed_verifiable_presentation>",
  "presentation_submission": {
    "descriptor_map": [
      {
        "id": "age_over_18",
        "format": "mso_mdoc",
        "path": "$.credentials[0]"
      }
    ]
  },
  "disclosed_claims": {
    "age_over_18": true
    # NOTE: date of birth is NOT shared
  }
}

eIDAS 2.0 Implementation Timeline

Date Milestone Detail
May 2024 Regulation approved EU Regulation 2024/1183 published in the Official Journal
December 2024 First implementing acts Technical specifications for data formats and cross-border interoperability
July 2025 Full implementing acts Standards for security, reliability, and technical wallet functionalities
December 2026 Wallets available Every Member State must make an EUDI Wallet available to its citizens
December 2027 Mandatory acceptance Mandatory acceptance by regulated private sectors and Very Large Online Platforms

EBSI: European Blockchain Services Infrastructure

EBSI adds an additional layer to the European DPI architecture: a permissioned blockchain that provides verifiable credentials, notarization, traceability, and timestamping services shared across all Member States. EBSI is not a replacement for traditional systems but a complement that adds immutability and cryptographic verifiability guarantees to cross-border processes.

GovStack: The Building Block Standard

GovStack is an international initiative led by ITU, GIZ, Estonia, and DIAL that defines open technical specifications for government digital service building blocks. With the GovSpecs 2.0 (2025-2027) strategy, GovStack has consolidated a framework that over 20 countries are already adopting to design their DPI architectures. Starting in 2026, the specifications also integrate AI-readiness features.

The Nine Foundational Building Blocks

GovStack defines nine building blocks that form the foundation of any government digital service. Each building block is independently deployable, exposes standardized RESTful APIs, and communicates with others through well-defined protocols.

Building Block Function Use Case Example
Identity Digital identity verification and management Public service login, KYC, digital signature
Payments Payment processing and transfers Taxes, subsidies, public salaries
Consent Consent management for data sharing Authorization to access health and tax data
Digital Registries Structured authoritative data registries Civil registry, land registry, business register
Messaging Multi-channel notifications and communications SMS, email, push notifications for deadlines, alerts
Information Mediator Secure inter-system data exchange Data sharing between ministries, cross-database verification
Registration Service and program enrollment School enrollment, healthcare registration
Scheduler Appointment and resource booking Healthcare appointments, document pickup scheduling
Workflow Multi-step process orchestration Building permit request, approval pipeline 
# GovStack Building Blocks - Complete Architecture Example
# Use case: Social subsidy application

# 1. REGISTRATION BB - Citizen registers on the platform
POST /api/v1/registration/applications
{
  "program_id": "social-subsidy-2026",
  "applicant": {
    "identity_ref": "ID-2026-XXXX",
    "contact": {
      "email": "citizen@email.com",
      "phone": "+39XXXXXXXXXX"
    }
  }
}
# Response: { "application_id": "APP-001", "status": "SUBMITTED" }

# 2. IDENTITY BB - Verify applicant identity
POST /api/v1/identity/verify
{
  "identity_ref": "ID-2026-XXXX",
  "verification_type": "STRONG",
  "purpose": "social-subsidy-eligibility",
  "required_loa": "HIGH"    # Level of Assurance
}
# Response: { "verified": true, "loa": "HIGH", "method": "eID+biometric" }

# 3. CONSENT BB - Request consent for tax data access
POST /api/v1/consent/requests
{
  "subject_id": "ID-2026-XXXX",
  "requester": "ministry-of-welfare",
  "data_sources": [
    {
      "provider": "tax-authority",
      "data_type": "annual_income",
      "period": "2025"
    },
    {
      "provider": "social-security",
      "data_type": "employment_status",
      "period": "current"
    }
  ],
  "purpose": "Social subsidy eligibility verification",
  "retention_period": "90d",
  "expires_at": "2026-04-09T00:00:00Z"
}
# Response: { "consent_id": "CON-001", "status": "PENDING_APPROVAL" }

# 4. INFORMATION MEDIATOR BB - Data retrieval (post-consent)
POST /api/v1/mediator/query
{
  "consent_id": "CON-001",
  "queries": [
    {
      "source": "tax-authority",
      "endpoint": "/citizen/income",
      "params": { "year": 2025, "citizen_id": "ID-2026-XXXX" }
    },
    {
      "source": "social-security",
      "endpoint": "/citizen/employment",
      "params": { "citizen_id": "ID-2026-XXXX" }
    }
  ]
}
# Response: aggregated data from multiple sources

# 5. WORKFLOW BB - Decision orchestration
POST /api/v1/workflow/execute
{
  "workflow_id": "subsidy-evaluation",
  "application_id": "APP-001",
  "input_data": {
    "identity_verified": true,
    "income_2025": 18500.00,
    "employment_status": "unemployed",
    "household_size": 3
  }
}
# Response: { "decision": "APPROVED", "amount": 600.00, "frequency": "monthly" }

# 6. PAYMENTS BB - Subsidy disbursement
POST /api/v1/payments/disbursements
{
  "beneficiary_id": "ID-2026-XXXX",
  "amount": 600.00,
  "currency": "EUR",
  "payment_method": "bank_transfer",
  "reference": "APP-001",
  "schedule": {
    "type": "RECURRING",
    "frequency": "MONTHLY",
    "start_date": "2026-04-01"
  }
}
# Response: { "payment_id": "PAY-001", "status": "SCHEDULED" }

# 7. MESSAGING BB - Notify citizen
POST /api/v1/messaging/send
{
  "recipient_id": "ID-2026-XXXX",
  "template": "subsidy-approved",
  "channels": ["sms", "email", "push"],
  "parameters": {
    "amount": "600.00 EUR",
    "start_date": "April 1, 2026",
    "reference": "APP-001"
  }
}
# Response: { "message_id": "MSG-001", "delivered": ["sms", "email"] }

Interoperability Frameworks: X-Road and DIGIT

X-Road: Estonia’s Digital Backbone

X-Road is the interoperability framework developed by Estonia in 2001 and now adopted by over 25 countries. It is the component that enables secure data exchange between any information system connected to the government network, and has been released as open source under the MIT license since 2016.

X-Road’s architecture is built on three key components:

  • Central Server: maintains the member registry, security policies, and global network configuration
  • Security Server: installed at each participating organization, handles authentication, authorization, encryption, and logging for every transaction
  • Service Provider/Consumer: the information systems that produce or consume services via X-Road

Each organization’s and Security Server’s identity is verified using X.509 certificates issued by a trusted Certification Authority. Every message is digitally signed, encrypted in transit, and immutably logged on both sides of the communication. 

# X-Road - Interoperability Architecture

#   Organization A               Central Server            Organization B
#   +----------------+      +-------------------+      +----------------+
#   |  Information    |      | - Member Registry |      |  Information   |
#   |  System A       |      | - Security Policy |      |  System B      |
#   |  (Consumer)     |      | - Config Sync     |      |  (Provider)    |
#   +-------+--------+      +-------------------+      +-------+--------+
#           |                                                   |
#   +-------+--------+                                 +-------+--------+
#   | Security Server|  <--- TLS + Signed SOAP --->   | Security Server|
#   | - Auth         |                                 | - Auth         |
#   | - Encryption   |                                 | - Encryption   |
#   | - Logging      |                                 | - Logging      |
#   | - Timestamping |                                 | - Timestamping |
#   +----------------+                                 +----------------+

# Requirements met by X-Road:
# 1. Interoperability: works across heterogeneous systems with language-agnostic APIs
# 2. Data integrity: no information altered during transfer
# 3. Privacy: all data encrypted, protected from unauthorized access
# 4. Non-repudiation: every transaction signed and logged on both sides

# X-Road request example (SOAP/REST)
# Service: population.registry/getCitizenData/v3
{
  "client": {
    "xRoadInstance": "EE",
    "memberClass": "GOV",
    "memberCode": "70000001",
    "subsystemCode": "welfare-system"
  },
  "service": {
    "xRoadInstance": "EE",
    "memberClass": "GOV",
    "memberCode": "70000002",
    "subsystemCode": "population-registry",
    "serviceCode": "getCitizenData",
    "serviceVersion": "v3"
  },
  "id": "REQ-2026-03-09-001",
  "protocolVersion": "4.0"
}

DIGIT India: Data Empowerment and Protection Architecture

On the Indian side, the DIGIT (Digital Infrastructure for Governance, Impact and Transformation) framework provides an open-source platform for digitizing urban and rural public services. Unlike X-Road, which is a pure interoperability layer, DIGIT is a broader ecosystem that includes pre-built microservices, analytics dashboards, and citizen engagement tools.

Complementary to DIGIT, the DEPA (Data Empowerment and Protection Architecture) defines how citizen data can be securely shared through Account Aggregators, fiduciary entities regulated by the Reserve Bank of India that mediate financial data flows with the user’s explicit consent.

API Design for Government Services

API design is the technical core of DPI. Government APIs must meet requirements that go well beyond those of commercial APIs: 99.99% availability, guaranteed backward compatibility for years, complete audit trails, multi-language support, and compliance with national and international standards.

Design Patterns for Government APIs

# API Gateway for Government Services - Reference Patterns

# Standardized URL structure:
# /{country}/gov/api/{version}/{domain}/{resource}

# Examples:
# GET  /it/gov/api/v2/citizens/CF-XXXXXX/profile
# POST /it/gov/api/v2/welfare/applications
# GET  /it/gov/api/v2/tax/declarations?year=2025

# Standard Headers (mandatory for all government APIs):
#
# X-Request-ID:        Unique UUID for traceability
# X-Correlation-ID:    ID to correlate cross-service requests
# X-Gov-Client-ID:     Calling system identifier
# X-Gov-Consent-Token: User consent token (where required)
# X-Gov-Audit-Actor:   Operator identifier (for audit)
# Accept-Language:     Response language (it, en, de, fr, ...)

# Versioning: URI-based for major, header for minor
# GET /it/gov/api/v2/citizens/...
# X-Api-Version: 2.3.1

# Differentiated rate limiting by consumer type:
# - Internal PA systems:       10,000 req/min
# - Accredited entities:        1,000 req/min
# - Citizen applications:         100 req/min
# - Developers (sandbox):          50 req/min

# Standard response envelope:
{
  "meta": {
    "request_id": "550e8400-e29b-41d4-a716-446655440000",
    "timestamp": "2026-03-09T10:30:00Z",
    "api_version": "2.3.1",
    "locale": "en-US"
  },
  "data": {
    # ... response payload
  },
  "pagination": {
    "total": 150,
    "page": 1,
    "per_page": 20,
    "next_cursor": "eyJpZCI6MTIzfQ=="
  },
  "errors": null,
  "warnings": [
    {
      "code": "DEPRECATED_FIELD",
      "message": "The 'tax_id_old' field will be removed in v3",
      "target": "data.tax_id_old"
    }
  ]
}

# Standard error response (RFC 7807 - Problem Details):
{
  "type": "https://gov.it/errors/consent-required",
  "title": "Consent required",
  "status": 403,
  "detail": "Access to tax data requires explicit citizen consent",
  "instance": "/it/gov/api/v2/tax/declarations?year=2025",
  "extensions": {
    "consent_url": "https://consent.gov.it/request/CON-001",
    "required_scopes": ["tax:read:annual_income"],
    "expires_in": 3600
  }
}

Consent Management: The Heart of Privacy in DPI

The Consent Building Block is arguably the most critical component in modern DPI, especially in contexts like Europe where GDPR imposes stringent requirements. Consent management is not a simple “accept/reject”: it is a complex system that must handle granular, revocable consents with temporal expiration and complete audit trails. 

# Consent Management Service - Reference Implementation

# Consent data model
{
  "consent_id": "CON-2026-03-001",
  "version": 1,
  "status": "ACTIVE",             # PENDING | ACTIVE | REVOKED | EXPIRED
  "subject": {
    "id": "CITIZEN-ID-XXX",
    "type": "NATURAL_PERSON"
  },
  "controller": {
    "id": "MINISTRY-WELFARE",
    "name": "Ministry of Labour and Social Policies",
    "dpo_contact": "dpo@welfare.gov.example"
  },
  "purpose": {
    "code": "SOCIAL_SUBSIDY_EVAL",
    "description": "Social subsidy eligibility evaluation",
    "legal_basis": "GDPR Art. 6(1)(a) - Explicit consent"
  },
  "data_items": [
    {
      "source": "tax-authority",
      "category": "FINANCIAL",
      "specific_data": ["annual_income", "tax_declarations"],
      "period": "2024-2025",
      "access_type": "READ_ONCE"    # READ_ONCE | READ_RECURRING | STREAM
    },
    {
      "source": "social-security",
      "category": "EMPLOYMENT",
      "specific_data": ["employment_status", "contribution_history"],
      "period": "current",
      "access_type": "READ_RECURRING"
    }
  ],
  "constraints": {
    "retention_period": "90d",
    "geographic_restriction": "EU",
    "no_automated_decisions": true,
    "no_third_party_sharing": true
  },
  "lifecycle": {
    "created_at": "2026-03-09T10:00:00Z",
    "granted_at": "2026-03-09T10:05:23Z",
    "expires_at": "2026-06-09T10:05:23Z",
    "revoked_at": null,
    "last_accessed": "2026-03-09T10:30:00Z",
    "access_count": 1
  },
  "audit_trail": [
    {
      "action": "CREATED",
      "timestamp": "2026-03-09T10:00:00Z",
      "actor": "welfare-portal",
      "ip": "x.x.x.x"
    },
    {
      "action": "GRANTED",
      "timestamp": "2026-03-09T10:05:23Z",
      "actor": "citizen-wallet",
      "method": "EUDI_WALLET_CONFIRM"
    },
    {
      "action": "DATA_ACCESSED",
      "timestamp": "2026-03-09T10:30:00Z",
      "actor": "welfare-evaluation-service",
      "data_source": "tax-authority"
    }
  ],
  "signature": "<digital_signature_of_consent_record>"
}

# Consent management APIs:

# Create consent request
POST   /api/v1/consent/requests

# Citizen grants/denies consent
PUT    /api/v1/consent/{consent_id}/grant
PUT    /api/v1/consent/{consent_id}/deny

# Revoke consent (GDPR-guaranteed right)
DELETE /api/v1/consent/{consent_id}

# Verify consent status (for data providers)
GET    /api/v1/consent/{consent_id}/verify
# Response: { "valid": true, "scopes": [...], "expires_in": 7776000 }

# List active consents for a citizen
GET    /api/v1/consent/subject/{subject_id}
# Response: paginated list of all active/expired/revoked consents

# Full audit trail
GET    /api/v1/consent/{consent_id}/audit

Security and Privacy by Design in DPI

Security in a DPI system cannot be an afterthought: it must be built into the architecture’s DNA from conception. As highlighted by the World Economic Forum, security-by-design principles were embedded into Aadhaar’s biometric protocols, UPI’s transaction frameworks, and data sharing architectures before a single user was onboarded.

DPI Security Principles

Principle Implementation Example
Zero Trust Every request authenticated and authorized, no implicit trust mTLS between all microservices, short-lived JWTs
Data Minimization Share only strictly necessary data EUDI Wallet: age verification without revealing date of birth
Encryption Everywhere Encryption in transit (TLS 1.3) and at rest (AES-256) X-Road: every message signed and encrypted end-to-end
Immutable Audit Tamper-proof logs of every operation Blockchain-backed audit trail for consents and access
Consent-First No data access without explicit verifiable consent DEPA Account Aggregator: signed digital consent
Federated Architecture No single point of failure or compromise X-Road: distributed data, no central database
Hardware Security Cryptographic keys in Secure Element or HSM EUDI Wallet: private keys in device TEE

Lesson from the April 2025 UPI Outage

On April 12, 2025, UPI experienced its largest outage in over three years, lasting more than 5 hours. NPCI’s post-mortem analysis revealed that the cause was flooding of the “Check Transaction Status” API: the systems had no rate limit on transaction status check requests. This case demonstrates that even the most mature DPIs must rigorously apply rate limiting, circuit breaking, and graceful degradation principles on every single endpoint, including seemingly secondary ones.

Scaling DPI: From Prototype to Population Scale

Taking a DPI from prototype to serving an entire population is one of the most complex engineering challenges in the technology landscape. The numbers speak for themselves: UPI processes over 700 million transactions per day, Aadhaar handles hundreds of millions of monthly authentications, and X-Road in Estonia processes over 1 billion queries per year for a country of 1.3 million inhabitants.

Architectural Patterns for Scalability

  • Event-Driven Architecture: building blocks communicate via asynchronous events, decoupling producers and consumers and enabling independent scaling
  • CQRS (Command Query Responsibility Segregation): separation between write operations (transactions, registrations) and reads (queries, reports), with databases optimized for each
  • Geographic Sharding: data partitioning by region/state to reduce latency and comply with data residency requirements
  • Circuit Breaker: every integration between building blocks protected by circuit breakers to prevent cascading failures
  • Blue-Green Deployment: zero-downtime updates, critical for services that cannot afford interruptions
  • Multi-Region Active-Active: active replication across multiple data centers for disaster recovery with near-zero RPO

Case Studies: Three DPI Models Compared

Estonia: e-Residency and the World’s Most Digital Government

Estonia is the most cited case of complete government digitization. With only 1.3 million inhabitants, 99% of public services are available online (the only exceptions being marriage, divorce, and real estate transactions, which still require physical presence). The e-Residency program, launched in 2014, allows anyone in the world to obtain an Estonian digital identity and access the country’s business services.

The technical core is X-Road, which since 2001 has interconnected all public administration information systems. Each agency maintains its own data (“once only” principle: data is recorded once and shared where needed), and X-Road ensures secure, signed, and logged exchange.

India: UPI and Financial Inclusion at Billion-Person Scale

India Stack has demonstrated that DPI can work at unprecedented scale. The journey was: Aadhaar (identity, from 2009) → Jan Dhan Yojana (bank accounts for all, from 2014) → UPI (instant payments, from 2016) → DigiLocker (documents, from 2015) → ONDC (open commerce, from 2022). This sequence — known as the JAM Trinity (Jan Dhan + Aadhaar + Mobile) — brought over 500 million people into the formal digital economy.

Singapore: SingPass and the Smart Nation Model

SingPass (Singapore Personal Access) serves 97% of citizens and permanent residents aged 15 and above and handles approximately 300 million transactions per year across 2,700+ services from 800+ public and private entities. Singapore’s NDI (National Digital Identity) architecture stands out for:

  • MyInfo: pre-populated digital profile with government-verified data, eliminating the need for repeated data entry
  • Face Verification: biometric facial authentication for high-risk transactions
  • Sign: legally valid digital signature integrated into the ecosystem
  • Verify: in-person identity verification via QR code, without sharing physical documents
Dimension Estonia India Singapore EU (eIDAS 2.0)
Population Served 1.3M + e-Residents 1.4 billion 5.9 million 450 million (target)
Launch Year 2001 (X-Road) 2009 (Aadhaar) 2003 (SingPass) 2024 (eIDAS 2.0)
Identity eID card + Mobile-ID Aadhaar (biometric) SingPass + NRIC EUDI Wallet
Data Exchange X-Road (federated) DEPA + DigiLocker MyInfo + APEX EBSI + eDelivery
Payments SEPA + e-invoicing UPI (21.7B txn/month) PayNow + SGQR SEPA Instant + EPI
Architecture Federated, decentralized Central switch + APIs Centralized, cloud-native Wallet-based, decentralized
Open Source Yes (X-Road MIT) Partial (MOSIP, DIGIT) Partial (Singapore GovTech) Under definition
Privacy Model Once-only principle Consent-based sharing Centralized with controls Privacy-by-design, GDPR

Implementing DPI: Lessons Learned

The 7 Golden Rules for Successful DPI

  1. Start with identity: without a robust identity layer, nothing works. It is the prerequisite for everything else.
  2. Open standards, not mandatory open source: specifications must be open; implementations can vary. GovStack demonstrates that open standards enable diverse but interoperable implementations.
  3. Privacy from day zero: the architecture must include consent, data minimization, and audit trails from the first commit. Adding them later is exponentially more expensive.
  4. Radical modularity: each building block must be replaceable, upgradeable, or scalable independently. If changing the payment system requires modifying the identity system, the architecture is wrong.
  5. Design for failure: at national scale, failures are not exceptions but statistical certainties. Circuit breakers, exponential backoff retries, and graceful degradation are mandatory.
  6. Sandbox first: before going to production, provide a complete sandbox environment where developers and agencies can test integrations. Adoption depends on developer experience.
  7. Measure everything: transactions per second, P99 latency, error rate, adoption rate, cost per transaction. Without metrics, you cannot optimize.

The Future of DPI: 2026-2030 Trends

The DPI landscape is rapidly evolving. Several emerging trends will redefine the architecture of digital public infrastructure in the coming years:

  • AI-Readiness in Building Blocks: GovSpecs 2.0 plans to integrate AI-ready features into building block specifications starting in 2026, enabling proactive and predictive services
  • Generalized Verifiable Credentials: beyond identity, verifiable credentials will extend to academic degrees, professional licenses, health certifications, and work qualifications
  • Cross-border DPI: interoperability between national DPIs will become the norm, with EUDI Wallet and UPI export as reference models
  • Decentralized Identity (SSI): Self-Sovereign Identity models, where citizens fully control their data without depending on a central provider, will gain traction
  • Green DPI: energy efficiency and environmental sustainability will become design requirements, with carbon footprint metrics per transaction

Conclusion

Digital Public Infrastructure is not a technology project: it is a social architecture choice. Deciding to build shared, open, and interoperable building blocks means choosing a model where innovation is distributed, where any actor — public or private — can build services on the same foundations, and where the marginal cost of a new digital service approaches zero.

The three models we analyzed — India Stack for scale, Estonia for architectural elegance, Singapore for efficiency — demonstrate that there is no single way to implement DPI, but there are universal principles: modularity, interoperability, privacy-by-design, open standards, and design for failure. With GovStack standardizing building blocks, eIDAS 2.0 bringing the digital wallet to 450 million Europeans, and India exporting UPI to 25+ countries, we are at the beginning of an era where DPI will become infrastructure as fundamental as electricity or the Internet.

For developers and software architects, understanding DPI patterns is not just a technical competency: it is the key to participating in building the digital infrastructure for the next generation of public services.

Resources for Further Reading

  • GovStack Specifications: specs.govstack.global — complete technical specifications of building blocks
  • X-Road Documentation: x-road.global — documentation and source code of the Estonian framework
  • India Stack: indiastack.org — documentation of the Indian DPI ecosystem
  • EUDI Wallet: ec.europa.eu/digital-building-blocks — technical specifications of the European wallet
  • OECD DPI Report 2025: comparative analysis of DPI across OECD countries