The Future of Digital Public Infrastructure: A Thesis for Rapid Global Adoption

PRAMOD VARMA, RAHUL MATTHAN, RUDRA CHAUDHURI & C. V. MADHUKAR

Source Link

INTRODUCTION

India’s presidency of the G20 in 2023 placed digital public infrastructure (DPI) on the global map.1 Until November 2022, DPI as a term did not exist for most people around the world. In a period of nine months, between December 2022 and August 2023, not only was the grammar and syntax of DPI created, but a suggested framework for DPI was also accepted by the G20 member states.2

There were two tracks in the G20 discussions during India’s presidency that dealt directly with DPI: the Digital Economy Working Group (DEWG),3 under what is known as the Sherpa Track, and the Global Partnership for Financial Inclusion,4 under the Finance Track. Both tracks arrived at a consensus on the suggested principles for building DPI. To be clear, the use of technology for inclusion is a concept that has existed for a long time.5 What is new is that, for the first time,6 a framework—marrying technology, governance, and the role of communities—has been agreed upon multilaterally.

In September 2023, the United Nations launched its High Impact Initiative on DPI.7 Aid agencies around the world have highlighted the need to deploy DPI in one hundred countries by 2030, thereby helping fulfill the targets of the Sustainable Development Goals (SDGs). The 50-in-5 campaign, described as a “country-led advocacy campaign,” was launched by various international organizations in November 2023 as one more step to advance the adoption of inclusive and safe DPI.8 It aims to help fifty countries “design, launch, and scale components of their digital public infrastructure.”

There is growing consensus among many countries and multilaterals within and outside of the G20 that DPI can deliver global development outcomes at a rate that is otherwise impossible to imagine. Decisionmakers across the world, including those in some of the world’s largest companies and philanthropic organizations, understand that not only does DPI work but that its global deployment can enable speedier financial inclusion. They see India’s DPI journey—as well as similar approaches from Brazil, Estonia, Singapore, and others—as a key model for achieving these aims.9

At the same time, how exactly countries can use the DPI approach to advance the SDGs must be better understood. Experts who have tracked India’s impressive DPI build-out have tended to follow in its footsteps, but India’s path might not be suitable for countries that have somewhat different characteristics. While most countries are keen to adopt DPIs (for example, digital identities, electronic payments, and verifiable credentialing) similar to what India has done, countries with smaller populations might need to explore other options to rapidly deploy and scale these DPIs.

There is a better way to enable countries to roll out DPIs with less friction. This is especially the case for countries with relatively small populations of less than 1 million people, which is true for more than seventy-five jurisdictions across the globe. This paper highlights an alternative approach: what we call the “DPI as a packaged Solution” (DaaS) model for rapid DPI deployment. It is a new way to think about rolling out solutions that incorporate the DPI approach at scale and speed. It is fully packaged, easier to adopt, cloud-ready (meaning it can be deployed within private and public cloud environments), well-productized, and suited for all countries, especially ones with smaller populations. It can dramatically cut down the long definition, procurement, and IT implementation phases of a typical DPI rollout to achieve a rapid rollout model. In addition, it can enable a shift from an approach driven by inputs and capital expenditure (CapEx) to an approach driven by outcomes and operating expenses (OpEx), significantly reducing traditional risks associated with large IT projects.

All DPI pilot efforts can start with the DaaS model and, if necessary, move to a more traditional, customized model as they scale. This ability to shift, if required, from the DaaS model to another allows countries to rapidly launch pilots, see early success, and decide on a long-term deployment strategy without long decision and procurement cycles upfront.

We believe that the DaaS-based pilots can be launched three to six months after the country has identified a use case and a committed sponsor (such as a government department or a ministry). This is by no means a complete articulation of all the details pertaining to how the DaaS model can be implemented and piloted for driving early success. It is our attempt to propose the idea so that policymakers, funders, and countries can consider this approach compared to the high-risk, CapEx-intensive, time-intensive, and custom-built model that is commonly suggested as the only way by which DPI can be deployed and accessed.

To elicit feedback, this thought experiment on the DaaS model has already been circulated among a limited audience, including system integrators, cloud providers, consultants, and experts. These stakeholders have spent years deploying DPI in different parts of the world. Early input and feedback from experts and countries have been incredibly useful in shaping this approach. A version of this paper was also presented at the Global Technology Summit 2023 to DPI experts from twenty-five countries.10 The early feedback seemed to suggest that there exists a sufficiently high degree of enthusiasm for the DaaS model that justifies its further effort.

Three of this paper’s authors have played a role in building DPIs in India and are actively involved in advising several countries on incorporating the DPI approach. It is our hope that this paper will carry the idea behind the DaaS model to a broader audience. We have begun to see a new market ecosystem for the growth of this kind of DPI deployment, where consultants are expanding DPI business practices, cloud providers are sandboxing DPI packages and innovative solutions, and funding agencies and philanthropic organizations are exploring different options for outcome-oriented, quicker, safer, and responsible deployment of DPI.

The rest of this paper proceeds as follows: First, we briefly introduce DPI. This has been detailed in the existing literature and popularized through and because of India’s presidency of the G20. Second, we outline the more traditional ways of deploying DPI projects and highlight the pros and cons of exercising this approach globally, especially in low-population countries. Third, we explain the DaaS model and lay out our theory of change. Fourth, we detail the crucial need for packaging DPI offerings toward the DaaS model while keeping in mind the need to square the circle on governance, privacy, and institutional support—essential for either of the two models of deployment detailed here.

WHAT IS DPI?

There are essentially two ways of building digital assets in any country. The first is what might be called the siloed digitization approach. It involves the engagement of various vendors to build and operate digital systems, digitizing one business process at a time using a full-stack solution, where the solution builder ends up building all the components and capabilities necessary. While this approach digitizes the systems and data, building customized full-stack solutions each time is both expensive and of poor design. The full-stack approach reduces reusability, interoperability, evolvability, and extendibility and incurs significant costs. Countries that choose to be fiscally prudent would be wise to leverage shared digital infrastructure and drive reuse, efficiency, and interoperability rather than rebuilding full-stack solutions each time. Full-stack solutions, in most cases, tend to result in the creation of proprietary systems that are not in the interests of countries when it comes to critical digital infrastructure.

The second, the DPI approach,11 is based on the creation of shared technology infrastructure building blocks (and not full solutions), where different DPI building blocks can be combined, reused, and leveraged when building various solutions instead of rebuilding them every time.12 DPIs, by their nature, are able to interoperate with each other, allowing for the creation of multiple interconnected solutions by both public and private ecosystems. They also make it easier to combine layers of infrastructure and assets in new ways to innovate in times of crisis or when new requirements are discovered. DPIs are essentially reusable building blocks for many solutions built by the ecosystem.

DPI can also be likened to railroads—the core infrastructure on top of which a diverse set of transportation solutions are built by both public and private enterprises. Thus, DPI establishes the core technology infrastructure along with a well-defined governance model on top of which both government and private innovators can create novel solutions as the need for them develops. As is evident, the private sector plays a crucial role, building out the citizen-/consumer-facing diverse applications on top of a set of core digital infrastructure building blocks.

Take, for instance, the case of instant/fast payments through the Unified Payments Interface (UPI) in India. The core framework for the digital payment infrastructure has been set up through a set of interoperable protocols and governance mechanisms developed by the National Payments Corporation of India (NPCI), a not-for-profit entity operating the payment backbone in India. Google’s GPay, WhatsApp-based payments, Walmart-owned PhonePe, and many others have built out technology solutions for both consumers and businesses on top of this core infrastructure. Over 12 billion transactions (as of February 2024) are completed every month through UPI.13 As a result of this design, while the private sector gets to innovate, it does not do so by creating an end-to-end, proprietary, closed-loop system. Such an approach allows countries to avoid getting trapped in monopolistic silos and drive fair market competition. In addition, the openness of the UPI infrastructure avoids the usual challenge of vendor lock-in of the critical national infrastructure.14

Similarly, to successfully deploy a direct benefit transfer framework (more generally referred to as government-to-people payments) at scale, a country typically needs to have in place an identification system, interoperable digital payments, an account mapper, and digital credentialing. With these already in place, countries like India were able to create a direct benefit transfer system for pandemic assistance as well as a vaccination platform soon after the outbreak of the COVID-19 pandemic in a matter of days with minimal financial commitment.

Under India’s presidency of the G20, the outcome documents described DPI as a “set of shared digital systems that should be secure and interoperable, and can be built on open standards and specifications to deliver and provide equitable access to public and/or private services at societal scale.”15

Now, the question is: globally, how can as many countries as possible build and deploy their own DPI building blocks without taking decades and spending billions of dollars?

THE CURRENT WAY OF DEPLOYING DPI: THE TRADITIONAL CUSTOM BUILD MODEL

The traditional custom build (TCB) approach involves building the various layers of infrastructure from scratch in a custom way and then finding innovative ways in which to combine these capabilities to develop digital solutions (see figure 1).

Typically, the building and the deployment of these assets as DPI are carried out in-country by certified implementation partners and system integrators who have the appropriate level of knowledge and experience. For the agency in charge of the DPI, this involves identifying a consultant via a request for proposal (RFP), defining the end-to-end detailed specifications, designing the subsequent RFPs to build and operate, selecting vendors, and then actually getting the technology infrastructure implemented by the selected vendor. This cycle can take anywhere from one to three years and requires significant up-front investments before a pilot can even start.

Due to DPI efforts across the globe, much of what is required to build these core DPIs is typically available as a set of open-source assets, or digital public goods (DPGs). These include not only the source code and/or specifications, standards, and protocols with respect to the digital goods that make up the underlying infrastructure of these systems but also the legal documentation, governance models, and other artifacts that are necessary for implementing and rolling out DPIs.

India’s digital identification program, for instance, was custom-built, owned, and operated by the Indian identification authority. To achieve this, the authority assembled a small but highly experienced team to ensure openness and vendor neutrality while fully leveraging the IT and government ecosystems within India. This entirely custom-built strategy requires high capacity and a procurement- and CapEx-heavy approach with long lead times. This TCB model necessitates that countries have a deep capacity, an institutional base, and a mature ecosystem to make the best of this approach. It is also heavily front-loaded (from a time and cost perspective) and has a very high failure risk. As an alternative, countries could explore the approach proposed in this paper for a rapid DaaS-based pilot while still retaining the ability to use a more traditional model in the long run.

The advantage of using the TCB model is that it offers a high degree of customization. Individual building blocks can be created as per the exact specifications of the country in which they are deployed and combined in unique ways to address the specific use cases relevant to the domestic requirements of the country in question.

Whether or not a country can effectively leverage the TCB model depends on several factors. These include the country’s population; the size of its economy; the technology talent available; its capacity to build, operate, and maintain core infrastructure systems; and its desire to have more flexibility in designing solutions. Typically, countries with large economies and a high degree of domestically available technology talent and capacity are better suited for this model.

The success of this model also depends on the ability to muster the requisite political will. In addition to this, procurement is usually complex, timelines long, risks high, and the investment required to build local technical and implementation capacity demanding. Depending on what the country intends to build, it could take as long as two to three years to even begin the pilot on the ground, considering the time needed for project preparation, political buy-in, the organization of financial resources, the design and implementation of the RFP, the procurement processes, and the actual deployment.

The TCB model involves high friction, high investment, high risk, and high time commitment. This is not to say that this approach should no longer be exercised. But given the availability of many open-source DPG assets and knowledge, this approach is not generally advisable for most countries.

THE ALTERNATIVE: THE DAAS MODEL

The DaaS model is designed to offer essential DPI building blocks as a set of fully packaged, preconfigured, cloud-ready (private or public cloud environments), one-click-deployable, plug-and-play components, along with prepackaged training and a certified ecosystem to address capacity gaps. Such fully packaged DPI building blocks that use open assets allow the adopting country to exercise administrative control of the cloud instance and data, enabling it to quickly configure the DPI building blocks on a private or public cloud and start pilots rapidly. This means that countries that adopt this model can deploy a DPI building block relatively quickly without the long definition, procurement, build, and test cycles, as well as with a minimum capacity compared to the TCB model, without having to make significant upfront capital investments. The DaaS model is essentially like using pre-built software products (privately or publicly hosted)—a well-understood and successful approach—except that in DaaS, core software is open-source, ensuring that countries are not subject to vendor and/or technology lock-in. The DaaS model of offering prepackaged, product-like offerings is amenable for generalized infrastructure building blocks that require minimal customization compared to final user-facing solutions that typically need a lot more contextualization and customization.

The DaaS model and DPI packages will be designed with management control, avoidance of technology/IP lock-in, and technical and legal guarantees that safeguard the sovereignty of national data and ensure the privacy of citizen data and the security of the system. (This is discussed in detail toward the end of this section.) Even though a cloud offering has benefits, if required, each country can be offered a separate instance of the DPI solution with complete control over the administration and operation of the solution.

If a country wishes to procure support for a DaaS template and have it managed by a commercial provider, it will need to put out a request for quote for discovering the best price. Through a competitive ecosystem of trained and certified DaaS providers, getting commercial support for managing DPI pilots or beyond becomes very viable. Unlike the TCB model, where everything is custom-built—thereby resulting in more complex procurement, build, and implementation phases—in the DaaS model, a standard DPI package can be procured like a software product by requesting the best quote from a set of competing vendors who all offer the same DPI package across various private or public cloud services. This dramatically reduces complexity, eliminates the long procurement-through-implementation cycle, and allows countries to launch DPI pilots within three to six months without heavy up-front investment.

While the DaaS model is in fact suitable for all countries, as highlighted earlier, it is likely to be most suitable for countries with smaller populations that lack the economies of scale to build, operate, and maintain custom digital infrastructure on their own. These countries often lack adequate technology talent and do not have the capacity to upskill quickly.

The advantage of the DaaS model is that countries will get ready-made DPIs and solutions that they can use immediately, despite limitations in their internal technical capabilities to build such solutions (see figure 2). The model also addresses long-term ownership, data privacy, and system management control. It does away with the challenges of CapEx investment, procurement cycles, capacity building, and project implementation. It can be designed so that countries will own and control their data at all times and always have the option to migrate to a more traditional deployment if they so choose. The DaaS model can be scaled rapidly to far more countries than would be possible under the traditional model at a lower cost.

A perceived disadvantage of the DaaS approach is that it is not as customizable as the TCB model. But given the generalized nature of the infrastructure building blocks that necessitates minimal contextualization and open-source modular and extensible assets at its core, countries can easily extend and build their own variants on top of the core DPI package. They could do this without necessarily having to customize the core. Such an approach gives the country the best of both worlds—the ability to use an open packaged core that (like an operating system) can be upgraded from time to time and the ability to build custom extensions and applications on top without having to depend on the DPI package provider. If the need arises to also take control or customize the core itself, countries can do that because DaaS offerings use open assets with no IP lock-in.

When a given country implements DPI through the DaaS model, a country-specific instance could be quickly created. The country will have the option to configure the DPI cloud-based package to brand it in accordance with national requirements as well as to conform to legal, regulatory, and nation-specific customs and laws. Each country-specific instance of the DPI package will be created by spinning off within a private or a public cloud by a one-click-installable DPI package and then configuring it. Rollout in a country may require the services of one or more service providers certified for the DPI package to carry out such work. While these service providers will be responsible for the rollout, the country will, at all times, retain control over instance, data, service-level agreements (SLAs), and other factors that might have policy implications. Below, we outline a range of policy imperatives that adopting countries need to consider when implementing the DaaS model.

Privacy

In both the TCB model and the DaaS model, all elements of DPI can be planned to ensure privacy by design. They can be designed to ensure that personal data can only be processed with the consent of the individual to whom it pertains and that various privacy principles (purpose limitation, data minimization, retention restrictions, and so on) and other best practices can be implemented within the DPI package. Since all DPIs that are deployed as part of the DPI package are open-source or based on open assets, their compliance with privacy principles can be independently verified through the inspection of the code. Countries should engage independent experts to audit the deployment and ensure alignment with their privacy regulations. When countries adopt the DaaS model using commercial providers for managing support and SLAs, they should also ensure that the relevant DaaS provider is contractually bound to privacy- and data security-related obligations.

Data Security

The DaaS model can be designed to comply with the highest standards of data security both at the data and systems levels. Data minimization, encryption, perimeter security, access controls, transmission level security, and other aspects can be built into the core DPI package to minimize data breach risks. To the extent possible, data should be federated so that there is no central honey pot of data. Cloud-based DaaS offerings could have built-in global best practices and techniques for cybersecurity that have been pretested in many different contexts. Countries should also engage security experts to ensure independent security tests and audits of the cloud instance.

Sovereignty

The DaaS model can be designed to ensure that each country instance of a DPI package will be under the sovereign authority of the country that has procured it. As a result, all administrative actions with regard to DPI packages and the cloud instances can be placed under the exclusive control of the recipient country. Policymakers and other administrative personnel in the country can be trained on the administration of DPI packages to ensure adequate internal capacity to administer and manage that DPI without having to rely excessively on private providers. The software elements that comprise a given DPI package would necessarily consist of various open assets and, as a result, the code and assets could be scrutinized to ensure that there are no back doors to citizens’ data.

Governance

Where necessary, recipient countries will need to make appropriate amendments to their laws and regulations to enable the provision of government services through DPIs as well as to allow the many features that DPI solutions enable to be availed under existing legal regimes. For this purpose, the DaaS model could offer, in a packaged form, a list of suggested regulatory and governance frameworks along with policy templates that they could implement to ensure that the DPI solutions being deployed conform to democratic principles.

While these are, of course, recommendations that will need to be reviewed in the context of the countries’ existing regulatory frameworks, they will be a useful starting point for countries to ensure that the DPI solutions align with their existing regulatory systems. The DaaS model will also offer recommendations on the various alternatives of institutions that could be established to deploy and operate DPI.

THE DAAS OFFER

The DaaS offer is a consolidated bundle that contains all the components required to implement a given DPI in a country, including the software specifications, code, license terms, documentation, governance frameworks, policy templates, and institutional design template.

As an illustration, a DaaS offer could contain the following components.

Software and Documentation

This includes

• the software, protocols, application programming interfaces, system architecture, scripts, and digital workflows that comprise the technical design of the DPI, along with all necessary and relevant documentation required for a systems integrator to be able to deploy them;
• the procedures and processes that would need to be followed to deploy the DPI package, such as project documents, tender documents, and drafts of the RFP and commercial contracts (including SLAs) for the engagement of system integrators and consultants;
• commercial and pricing models that could be used for engagement of the system interface and consultants and that are benchmarked against globally competitive vendors; and
• licenses, where applicable, for the use of the various digital assets contained in the DPI package.

Implementation Details

This includes

• a step-by-step description of the processes, workflows, and practices that are required to roll out the DPI in a new jurisdiction, including the reorganization of government agencies and the establishment of new private sector market players;
• details of the stakeholder ecosystem that need to be established—across private, public, and civil society ecosystems—along with the responsibilities of the various participants and the steps that need to be taken from the initial deployment to a steady state;
• description of the indicative steps that are required to integrate the DPI ecosystem with existing governance frameworks;
• training for and certification of country personnel; and
• training for and certification of DaaS providers to create an atmosphere of competition by ensuring that the country has a choice of vendors and clouds to pick from.

Governance Packages

This includes

• details of the enabling legislative and regulatory frameworks required to invest the requisite legal status in DPI to perform its functions (for example, the legality of a digital identity) as well as to enable additional features (for example, the legal enforceability of digital signatures as evidence of authentication);
• guidelines for data governance, including the necessary organizational and technical measures that need to be put in place to ensure data sovereignty, data protection, and data security;
• recommendations as to the design of the regulatory and supervisory institutions that need to be established for the deployment and management of DPI within the country; and
• description and details of the training and certification mechanisms required to bring market participants on board the DPI ecosystems.

For a given DPI package, the DPG owner—the entity that owns and manages the primary open-source DPG that is at the core of that DPI package—will typically be responsible for supervising the creation of the package. For this purpose, they may work with technology service providers (TSPs), typically system integrators or independent software vendors (ISVs), who may be tasked with the creation and commercial support of such DaaS offerings. These TSPs will have access to the software components, documentation, and associated assets that are required to create the DPI package. They may also offer additional value-added services or products, such as reporting on top of the core DPI package, to differentiate their offering, but these must clearly be separated from the core DPI package in terms of intellectual property, pricing, and usage terms.

The entity that owns the DPGs could also be responsible for creating the training and certification programs around a DPI package. It will also be responsible for ensuring that the package offered by the TSP/ISV complies to data security and privacy and performs in the same manner across the DaaS providers to ensure consistency across the ecosystem. Multiple TSPs/ISVs should be encouraged and certified to offer DPI packages to foster a competitive ecosystem with many opportunities for innovation.

To the extent possible, the underlying technology of the DPI package should be released as open-source with the possibility of incorporating contributions from around the world. There should be long-term visibility over the evolution of such digital goods to ensure that they remain consistent with the latest developments in technology and respond to the changing needs of the country.

CONCLUSION

In this paper, we have proposed that DPI adoption within countries can be significantly accelerated through the use of the DaaS model as compared to the currently prominent TCB approach. Given the availability of well-designed, modular, and extensible open-source digital goods, the DaaS approach can become viable through the creation of DPI packages built on the DaaS model, training and certification programs, one-click deployment options on private or public clouds, and the pretesting for security and functionality. The establishment of supporting SI/ISV/cloud ecosystem providers and other knowledge assets, such as policy and implementation templates, will further this process.

The DaaS model promises significant value to countries. It potentially allows for rapid procurement and deployment. It ensures that there is no vendor/technology lock-in of critical digital infrastructure. The DaaS model uses open-source DPG assets. It ensures that countries retain the management of data and, most importantly, their ability to achieve digital transformation outcomes without losing quality, security, or sovereignty.