The systems and technologies that societies use to function form its infrastructure. Public infrastructure is fundamentally non-excludable, meaning one can’t be denied its use without just and equitable reason. Some infrastructure is non-rivalrous, such that one person's use of that infrastructure will not affect another's ability to use it.
Many digital services—communications, entertainment, and e-commerce—have become so ubiquitous today that they are beginning to redefine what comes under necessary infrastructure. However, since these services are mostly provided by private entities and subject to terms and conditions, they are excludable at the discretion of the party providing them, as they can determine who accesses such services. Consequently, even though it may seem like many of these services are essential, they cannot be called digital public infrastructure (DPI).
However, since these services are mostly provided by private entities and subject to terms and conditions, they are excludable at the discretion of the party providing them, as they can determine who accesses such services.
Other types of digital services are both non-excludable and non-rivalrous. National identity systems, electronic authentication and credentialing services, digital payment systems, and electronic procurement services, among others, can be consumed by everyone in a non-rivalrous manner. These services are DPI and are the subject of this essay.
Recently, there has been an increase in the deployment of DPI around the world. The COVID-19 pandemic
accelerated the use of these systems as enforced isolation left people with no choice but to rely on these digital alternatives. The
OECD has reported that governments and citizens who use DPIs are now convinced of the benefits they offer, and efforts are underway to deepen the use of DPIs across several domains.
In this context, many important questions arise about how these efforts ought to be organised. This essay will attempt to answer two: Who should build DPIs; and how it should be financed.
The Design Principles
While DPIs are built to suit the problem they have been designed to address, they must conform to certain broad design principles. Taking these principles into account will help visualise the incentives that need to be brought into play and help develop the foundational principles that need to be considered for DPI.
All DPIs should possess three key design features:
- Interoperable: To maximise their benefits to users, DPIs must be fundamentally interoperable. This will ensure that user data is does not get trapped in silos and becomes inaccessible to all but a few stakeholders who will extract value from them. A lack of interoperability also denies customers the benefits arising from competitive markets, including improved services and greater innovation.
- Modular: DPIs should also be modular by design. Rather than developing a monolithic design, we should think of it as a stack of components that can be assembled in different configurations. Some components will be foundational, such as those that identify network participants uniquely in the ecosystem, and those that serve as registries. Others, such as the payments components or the data transfer request frameworks, will be operational but only invoked in connection with certain aspects of the service.
- Protocols: Central to this design philosophy is a set of common protocols to which all components must adhere. This will allow components that are developed by different entities to interact with each other. Care must be taken to ensure that the incentives of the various network participants are appropriately aligned. Their ability to exercise control over various components of the infrastructure will affect their incentives.
A lack of interoperability also denies customers the benefits arising from competitive markets, including improved services and greater innovation.
Building Digital Public Infrastructure
There are various actors that hold an interest in and may contribute to the development of DPIs. These entities can be organised across three broad categories: Public sector, private sector, and non-profits entities. Public sector entities are primarily funded entirely by the government and subject to government control. Private sector entities receive their funding entirely from private sources and are privately managed. Regardless of their source of funds, non-profits are prevented by their charter from engaging in profit-making activities.
It is important to be mindful about how the design, development, and operation of DPIs should be funded. As much as public, private, and non-profit entities have to contribute, they each have their own unique shortcomings. Care must be taken to ensure that the involvement of these entities leverages all they have to offer, without falling prey to their shortcomings. This section briefly discusses these concepts in relation to each stakeholder in the DPI ecosystem.
- Public Entities: Public enterprises lack the experience needed to design and implement innovative digital platforms. Their thinking tends to be path dependent and the systems they build cleave closely to traditional processes. Left entirely to the public sector, DPIs will merely digitise existing offline processes.
Given that there is no requirement of revenue to sustain public funded projects, efficiency cannot be effectively gauged, which may result in delays and inefficient resource allocation. Public funded projects also carry risks of
politicisation and soft-budget constraints.
Care must be taken to ensure that the involvement of these entities leverages all they have to offer, without falling prey to their shortcomings.
That said, the public sector operates at scale and has the experience, institutional capacity, and resources to implement large infrastructure projects. As discussed by
Mazzucato, given the unpredictability associated with financing new or nascent markets, the public sector has the capacity to provide high-risk capital for long-term research and development for innovation that requires trial and error as compared to private financing, which is focused on short-term goals.
Accordingly, the public sector should implement the capital-intensive elements of DPIs and help scale the overall solution. They could also be responsible for operating those elements (for example, registries like Aadhaar that allocate roles and responsibilities among participants and give them the power to operate the infrastructure) that require the sort of neutrality that only government entities can provide. In this context, modular solutions will enable public-sector funding for the foundational elements that require long-term vision, innovation risks, and sufficient capital, with the private sector building on this system to scale it.
- Private Entities: Private entities are entrepreneurial and innovative by nature, attributes that must be put to good use in the design of DPIs. That said, they are motivated by commercial outcomes and will always maximise shareholder profit. Solutions often require values (such as equity and access, which are not copacetic with private sector targets), particularly when digital goods are being built in nascent or non-existent markets. As discussed later, the government’s BHIM application paved the way for private sector entities to build their own platforms to enter the digital payments space.
The DPI should be designed to maximise private sector innovation while still ensuring that they do not assume so much control over the infrastructure as to unfairly disadvantage their competitors.
There is also a risk of private sector innovations being designed to favour their own interests. Government and non-profit participation are required here to implement protocols to minimise such risks. The DPI should be designed to maximise private sector innovation while still ensuring that they do not assume so much control over the infrastructure as to unfairly disadvantage their competitors.
- Non-Profit Entities: Non-profit entities also have a role to play in building DPIs. Where there is insufficient commercial incentive for private entities to invest in essential components of the DPI, philanthropic capital, which usually has a long time-horizon, could step in. One key area of non-profit funding is research and conceptualisation of digital public goods. This requires long-term research, which the government often does not have the resources to invest in, especially given that political agendas and budgets shift with every election. The private sector also sees no monetary gain from such investments. For instance, recognising the need for an open stack operating across sectors and stakeholders may require long-term investment of resources with no immediate revenue. iSPIRT, a non-profit think-tank, has been involved in the development and evolution of the India Stack, and more recently its consent layer (the Data Empowerment Protection Architecture).
Similarly, having philanthropic capital design and manage the initial rollout of the infrastructure offers a level of neutrality that would not have been possible had private entities been involved at this early stage. Finally, philanthropic entities can also help update and maintain the technical standards needed to keep the infrastructure continuously evolving.
However, non-profit funding also requires monitoring and oversight, given that non-profits have donor-driven agendas, no public accountability, and lower competitive concerns.
Distribution of funding across stakeholders may also lead to greater cost efficiencies, reduce delays, and increase innovation and ideation.
DPIs should be built using a combination of public, private, and philanthropic capital. Distribution of funding across stakeholders may also lead to greater cost efficiencies, reduce delays, and increase innovation and ideation. In deciding which component is the responsibility of which type of entity, care should be taken to align responsibilities and incentives to maximise the contributions of the parties towards the stated objective.
The Case of the Unified Payment Interface
India's unified payment interface (UPI) is an example of DPI whose design, financing, and operation reflects many of the principles outlined in this essay. This section examines the design of UPI to demonstrate how various stakeholders participated in its design and financing.
UPI enables anyone with a bank account to make real-time digital payments using a mobile device. UPI is a payments system that runs on a central server operated by the National Payments Corporation of India (NPCI), a non-profit organisation that is responsible for its management. All licensed banks send and receive payment messages through the NPCI server. The banks hold user funds and are responsible for updating balances to reflect receipts and payments through the system. However, the banks are not the customer interface. That is provided by payment apps that are built and operated by private sector payment service providers.
- Interoperable Architecture: UPI has been built using a set of common protocols. This means that each bank and payment service provider get to use the same set of application programming interfaces to connect to every other entity on the system. Customers can use any one of several payment apps, offering them choice and service quality assurance. This in turn forces service providers to continuously innovate to retain clients and grow their market share.
- Modular Design: The UPI architecture is entirely modular. At the base is the NPCI to enable transfers payment messages to and from banks and the payment service providers. Given the centrality of this function, it is operated by a non-profit organisation with quasi-regulatory authority over the ecosystem. Banks in the middle layer of the infrastructure ensure that their systems conform to UPI protocols so that payments can be made to and from the customer accounts under their care. Private entities develop digital payment applications at the edge of the infrastructure. This is what customers use to make and receive payments.
- Design of the Specification: The core design of the UPI specifications was conducted by iSPIRT. This ensured that no one private sector entity received an undue advantage because they wrote the specifications. At the same time, the design of the digital infrastructure was not left to government entities without the expertise required to build such a digital system.
- Proof of Concept to Catalyse Innovation: When UPI was first rolled out, the NPCI built and funded the first payment app, BHIM. This app was a necessary proof of concept to demonstrate how digital payments could be conducted on UPI, and enabled the creation of an environment where other private fintech companies saw enough potential in the nascent digital payments market to build their own payment apps. This is what catalysed the digital payments revolution in India.
The banks hold user funds and are responsible for updating balances to reflect receipts and payments through the system.
Today, BHIM has a small market share compared to apps like Google Pay and PhonePe, which
dominate the market. Unlike BHIM, these other entities are motivated to maximise shareholder profit. As a result, they are constantly innovating to ensure that their applications grow their market share. As per
reports, this in turn has improved the customer experience with new features and improved service quality.
Conclusion
DPIs must, by definition, be non-excludable and non-rivalrous. They are distinct from other digital infrastructure that are excludable at the discretion of the technology companies that provide them. Care must be taken to ensure that the design, implementation, financing, and management of the infrastructure is oriented towards these outcomes.
This essay describes a framework within which these issues can be considered. Though not an exhaustive articulation of all relevant issues, nor a provision for all relevant solutions, the essay offers a set of foundational assumptions that can be used to frame the design of DPIs.
The views expressed above belong to the author(s). ORF research and analyses now available on Telegram! Click here to access our curated content — blogs, longforms and interviews.
PREV
