2 of 7

Digitisation of Social Protection in India: An Overview�

Traditional SP Delivery

SP Delivery through DPI

Fragmented front-end for citizen
Siloed back-end for administration
Limitation in generating and utilisation of real-time information

Unified front-end for citizen
Integrated back-end for administration
Generation and utilization of real-time information
Opportunities for third-party innovation

All over India, we are seeing the prevalence of platform-based social protection delivery. We have the Jan Aadhaar system in Rajasthan, the Parivar Pehchan Patra in Haryana, and the Samagra system of Madhya Pradesh which have surfaced in recent years. All of these systems have some basic features in common, in that they intend to provide citizens a single platform through which they can obtain a wide range of G2C services – including SP benefits from multiple government departments. At the back-end too, many of these systems look similar – in that they create process efficiency for the administrator by eliminating the duplication of admin processes.

In the ‘traditional’ paradigm of SP delivery, a citizen would have to run pillar to post to obtain the range of SP benefits they were entitled to. A daily wage labourer might have to approach the programme officer to receive an MGNREGA job card, and then the social welfare office for their Old Age pensions, and the local kotedar for a ration card. At each of these points, the person must submit application forms and documents to prove who they are, and that they are eligible for each of the schemes. Of course, there are other barriers that stand in a prospective beneficiaries way – uncooperative front end staff, corruption, technical failures, hold-ups in admin processes etc. Clearly, there is fragmentation of the front end for the citizen. If all services can be provided by a single-touchpoint to the citizen, it effectively reduces the barriers that stand between the citizen and the social protection system.

This fragmentation reflects in administrative processes as well, since each department processes applications, verifies eligibility, and disburses benefits through standalone processes. If deparmnets could instead share information across each other, instead of adopting siloed processes,various process efficiencies could be created.

These are the two primary pillars that set the SP-ODE paradigm apart from the traditional models of SP delivery. Since the model rests atop digital infrastrcutre, it facilitated the generation of real-time information, which can be useful towards improving monitoring capabilities, and also creates opportunities for various types of innovation.

3 of 7

Social Protection Tech Systems

An SP-ODE is an assemblage of entities and processes (both digital and otherwise) that will together constitute a citizen-centric welfare delivery system, i.e., be inclusive, responsible, and efficient, while supported by a system of accountability.

4 of 7

What metrics do you care about in building DPI?�Imagine you are a Policymaker/Private Sector/Citizen/Civil Society…

5 of 7

What does a DPI in Social Protection look like?

Digital public infrastructure (Aadhaar, DigiLocker, etc.)

Citizen registry with supporting ID system

Interoperable Digital Platforms

Identification & Enrolment

Coordination & Orchestration

Payments

Delivery of Cash Benefits & Ancillary Services

Grievance Redressal

Processes supported

Example:

The use of Rajasthan’s citizen data repository, mapped to the Jan Aadhaar ID, to identify which citizens are eligible for a given scheme.

The system also hosts a wide range of stakeholders who play various roles in each of the processes.

So how does this all work, really?

We are all familiar with India’s digital public infrastructure in the form of Aadhaar, Digilocker, Indistack, and so on.

The SP system builds on top of the DPI and is fundamentally modular in nature.

Typically, state governments create extant citizen registries, which are databases with demographic information and supported by a localized ID system. These ID systems are typically mapped to Aadhaar to retain the ability to be a proof of unique-identity.

Another key component is the digital platform, which is accessible by citizens on one end, and all participating government departments on the other. Other stakeholders that may access the platform and plug into the system include CSCs, fair price shops, hospitals, etc.

Most SP-ODEs are system in-flux, and could be structured slightly differently – theoretically an SPODE could host the entire social protection delivery chain.

there are 6 processes that the platform could support….starting from identifying the eligible citizens using the citizen registry, facilitating enrolment through the platform, distributing cash/non-cash benefits to citizens, and providing avenues of grievance redress through the platform.

With that context out of the way, I invite Ava to build upon our nascent thinking of which stakeholders are key to the functioning of an SP=ODE.

6 of 7

Who is core to digital social protection delivery?

Service Providers

Technical Developers

State authorities

Last-mile Intermediaries

Oversee the design and delivery of social protection benefits
Collect, protect, and regulate the use and transfer of citizen data
Implement system level changes through grievance mechanisms.
E.g. Central, State, Local

Intermediate between citizens and the tech system at the point of service delivery
Offline infrastructure at the last mile can offer re-entry loops for excluded citizens
Feed crucial information about gaps in system
E.g. CSCs, CSOs, Business correspondents

Financial Institutions

Disbursing SP benefits through the Direct Benefit Transfer system
Preventing financial harm to beneficiaries
E.g. Banks, Financial service providers

Building the tech infrastructure for SP-ODEs (such as tech companies)
Developing new services on top the SP-ODE that match citizen needs
E.g. Private software developers, open-source communities

Ensure provision of ‘non-cash’ services
Understand and resolve particular citizen grievances.
E.g. Hospitals, LPG agencies

Knowledge Builders

Raise awareness around digital social protection and enhance adoption
Enable transparency of social and technical improvements that can be implemented
E.g. Research institutions, policy teams

Citizens

Beneficiaries of social protection and primary users of the system
Hold the system accountable by virtue of their role as taxpayers
Rest atop the conceptualisation and development of these systems

Innovators

7 of 7

1.2. Key Attributes of Citizen-Centric SP-ODEs

Citizen-centric SP-ODEs should adhere to the following four attributes:

Efficient SP-ODEs minimise citizens’ search costs, eliminate process inefficiencies to result in better benefit delivery, and incorporate performance data to improve processes that do not work well for citizens.

Responsible SP-ODEs handle citizens’ personal data in a way that protects their personal data, and upholds their privacy while preserving their autonomy and trust in the use of their data.

Inclusive SP-ODEs strive to eliminate all forms of exclusion across the social protection delivery chain and offer a re-entry loop for those excluded.