PLAYBOOK ON DIGITAL SOCIAL PROTECTION DELIVERY SYSTEMS Towards Dynamic Inclusion and Interoperability © 2024 International Bank for Reconstruction and Development/The World Bank. 1818 H Street NW, Washington, DC 20433, USA. Telephone: 202–473–1000; Internet: www.worldbank.org. Some rights reserved This work is a product of the staff of The World Bank with external contributions. The findings, interpretations, and conclu- sions expressed in this work do not necessarily reflect the views of The World Bank, its Board of Executive Directors, or the governments they represent. The World Bank does not guarantee the accuracy of the data included in this work. The boundaries, colors, denominations, and other information shown on any map in this work do not imply any judgment on the part of The World Bank concerning the legal status of any territory or the endorsement or acceptance of such boundaries. Rights and Permissions This work is available under the Creative Commons Attribution 3.0 IGO license (CC BY 3.0 IGO) http://creativecommons.org/licenses/by/3.0/igo. Under the Creative Commons Attribution license, you are free to copy, distribute, transmit, and adapt this work, including for commercial purposes, under the following conditions: Attribution—Please cite the work as follows: Karippacheril, Tina George, Luis Iñaki Alberro Encinas, Ana Lucia Cardenas Mar- tinez, Conrad Daly, and Satyajit Suri. 2024. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability. ©World Bank. License: CC BY 3.0 IGO. Translations—If you create a translation of this work, please add the following disclaimer along with the attribution: This translation was not created by The World Bank and should not be considered an official World Bank translation. The World Bank shall not be liable for any content or error in this translation. Adaptations—If you create an adaptation of this work, please add the following disclaimer along with the attribution: This is an adaptation of an original work by The World Bank. Views and opinions expressed in the adaptation are the sole responsibility of the author or authors of the adaptation and are not endorsed by The World Bank. Third‑party content—The World Bank does not necessarily own each component of the content contained within the work. The World Bank therefore does not warrant that the use of any third-party-owned individual component or part contained in the work will not infringe on the rights of those third parties. The risk of claims resulting from such infringement rests solely with you. If you wish to re-use a component of the work, it is your responsibility to determine whether permission is needed for that re-use and to obtain permission from the copyright owner. Examples of components can include, but are not limited to, tables, figures, or images. All queries on rights and licenses should be addressed to World Bank Publications, The World Bank Group, 1818 H Street NW, Washington, DC 20433, USA; fax: 202–522–2625; e-mail: pubrights@ worldbank.org. Photos: Cover and page viii: Photo © Dominic Chavez/World Bank Page 1: https://www.flickr.com/photos/worldbank/32798792577/ (Photo: World Bank / Sarah Farhat) Page 11: https://www.flickr.com/photos/worldbank/3492673512/ (Photo: © Simone D. McCourtie / World Bank) Page 145: https://www.flickr.com/photos/worldbank/34351889973/ (Rama George-Alleyne / World Bank) Page 169: https://www.flickr.com/photos/worldbank/21978712908/ (Photo © Dominic Chavez / World Bank) Page 177: https://www.flickr.com/photos/worldbank/7826373720/ (Photo: Arne Hoel / World Bank) Contents Acknowledgments .....................................................................................................................................................................v Acronyms and Abbreviations .................................................................................................................................................vi Executive Summary ................................................................................................................................................................ viii I. INTRODUCTION...................................................................................................................................................... 3 1. Motivation....................................................................................................................................................................................................................................3 2. Setting the scene: social protection, people, and technology........................................................................................................................... 7 3. Scope............................................................................................................................................................................................................................................ 8 II. CONCEPTUAL FRAMEWORK............................................................................................................................... 11 Part 1. Core Characteristics.......................................................................................................................................................11 A. Levels of social protection.................................................................................................................................................................................................11 B. Ontology of DSPDS................................................................................................................................................................................................................18 Spotlight 1. Understanding different starting points of DSPDS............................................................................................................................. 31 Part 2. Data..................................................................................................................................................................................35 A. Data ............................................................................................................................................................................................................................................ 35 B. Processing ...............................................................................................................................................................................................................................46 Part 3. Delivery Chain............................................................................................................................................................... 49 A. Assess.........................................................................................................................................................................................................................................49 Spotlight 2. Evolution of welfare assessment in Chile.............................................................................................................................................. 71 B. Enroll........................................................................................................................................................................................................................................... 73 C. Provide ...................................................................................................................................................................................................................................... 76 D. Manage.....................................................................................................................................................................................................................................80 Part 4. Technology.................................................................................................................................................................... 85 A. Architecture ............................................................................................................................................................................................................................ 85 B. Applications..............................................................................................................................................................................................................................91 C. Database.................................................................................................................................................................................................................................. 97 D. Data exchange and interoperability...........................................................................................................................................................................99 E. Infrastructure........................................................................................................................................................................................................................ 103 Spotlight 3. Indicative functional overview and requirements for dSR..........................................................................................................104 Part 5. Governance................................................................................................................................................................... 111 A. Strategic (“High-level”)...................................................................................................................................................................................................... 115 B. Administrative (“Back office”)........................................................................................................................................................................................ 128 C. Operational (“Front office”).............................................................................................................................................................................................132 Part 6. Performance................................................................................................................................................................ 135 A. Results chain..........................................................................................................................................................................................................................135 B. DSPDS performance metrics......................................................................................................................................................................................... 138 C. Social protection system performance................................................................................................................................................................... 139 III. ASSESSMENT TOOL.......................................................................................................................................... 145 STEP 1. Country and social protection context...........................................................................................................................................................147 STEP 2. Systems assessment............................................................................................................................................................................................... 151 Bibliography..............................................................................................................................................................................169 Annex.......................................................................................................................................................................................... 177 Annex 1. Exemplar of synergies: interoperability between DSPDS and disaster risk information systems...................................177 Annex 2. List of potential indicators to monitor the performance of DSPDS..............................................................................................179 Annex 3. Business process and journey maps ..........................................................................................................................................................184 Annex 4. Glossary: IT cheat sheet ................................................................................................................................................................................... 186 Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability iii ASSESSMENT Contents Boxes 1. Governments develop interoperable systems as part of their overall agenda to build trust with people through their day-to-day interactions and delivery of benefits and services to them........................................................................................16 2. Traditional versus novel data sources...................................................................................................................................................................... 43 3. Perils of vendor lock-in ....................................................................................................................................................................................................88 4. Situating data protection and privacy ................................................................................................................................................................... 120 5. Principles for protecting personal data .................................................................................................................................................................123 6. Data and the “GDPR era”................................................................................................................................................................................................ 125 7. The elements of consent ..............................................................................................................................................................................................127 Figures A. Social protection delivery chain....................................................................................................................................................................................xi B. DSPDS: common component systems and their functions........................................................................................................................... xii 1. Our present times are defined by a polycrisis and long-term global challenges.................................................................................. 4 2. Social protection benefits and services..................................................................................................................................................................... 6 3. Core characteristics of DSPDS....................................................................................................................................................................................... 12 4. Social protection policies, programs, and delivery systems...........................................................................................................................14 5. DSPDS: common component systems and their functions............................................................................................................................19 6. Coverage and data collection methods for social registries around the world.................................................................................... 21 7. Dynamic social registry (dSR)........................................................................................................................................................................................ 22 8. Unique identification........................................................................................................................................................................................................ 24 9. Beneficiary operations management systems (BOMS) and integrated beneficiary registry (IBR)............................................... 25 10. Multi-program multi-provider payments............................................................................................................................................................... 27 11. From data generation to intervention delivery...................................................................................................................................................36 12. Benchmark of harmonized socioeconomic questionnaires.........................................................................................................................40 13. Modular data sets (illustrative).....................................................................................................................................................................................40 14. dSR and IBR data sources................................................................................................................................................................................................44 15. Half-life of data in static and dynamic social registries (illustrative)..........................................................................................................46 16. DSPDS data pipelines........................................................................................................................................................................................................ 47 17. Social protection delivery systems are facilitated by interactions between people and institutions......................................50 18. Outreach for DSPDS........................................................................................................................................................................................................... 53 19. dSR zoom-in: data intake modalities........................................................................................................................................................................58 20. Methodology for the measurement of multidimensional poverty in Mexico....................................................................................... 70 21. Evolution of government to person payments for social protection........................................................................................................77 22. Payments zoom-in: provision modalities............................................................................................................................................................... 79 23. An architectural framework for DSPDS, data flow, and interoperability...................................................................................................90 24. Data protection and privacy principles.................................................................................................................................................................. 124 25. Frequent interactions between people and DSP...............................................................................................................................................133 26. Results chain for DSPDS..................................................................................................................................................................................................137 27. Social protection delivery confusion cube........................................................................................................................................................... 142 A3.1. Delivery chain process map for unemployment assistance benefits and services in fictional country................................. 184 A3.2. Journey map for unemployment assistance benefits and services—fictional person’s experience........................................ 185 Tables 1. Trade-offs between directly and indirectly collected data............................................................................................................................. 42 2. Sample codebooks for household members and relationships................................................................................................................. 56 3. Household definitions across the world.................................................................................................................................................................56 4. Common approaches to assessing needs and conditions............................................................................................................................64 5. DSPDS and dSR architectural models for data management .....................................................................................................................100 A. Country at a glance...........................................................................................................................................................................................................147 B. Program mapping............................................................................................................................................................................................................. 148 C. Cross-cutting systems................................................................................................................................................................................................... 149 iv Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability Acknowledgments Dedicated to the memory of John Blomquist Former Global Lead on Social Protection Delivery Systems, World Bank. The Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability was prepared by World Bank staff working with an Inter-Agency Social Protection Assessment (ISPA) Working Group and Reference Group of the Social Protection Inter-Agency Coordination Board (SPIAC-B). ISPA offers a set of practical tools that help countries improve their social protection system by analyzing its strengths and weaknesses and offering options for further action. These can be applied across countries, facilitating dialogue and ensuring the development of countries’ social protection systems as well as international practices that will help countries to learn from each other. SPIAC-B is composed of 25 intergovernmental agencies and 10 government bodies. Eleven civil society organizations act as observers. For more information see: https://www.ilo.org/newyork/at-theun/social-protection-inter-agency- cooperation-board/lang--en/index.htm. The Playbook has been in the making since 2018, initially through a standalone working group and reference group, and later under the Digital Social Protection working group of SPIAC-B. The World Bank team was led by Tina George Karippacheril, as part of a core team with Luis Iñaki Alberro Encinas, Ana Lucia Cardenas, Conrad C. Daly, Satyajit Suri, and Andres de la Roche, with contributions from Ana Veronica Lopez, Ines Rodriguez Caillava, Kenichi Nishikawa Chavez, Luz Stella Rodriguez, Vasumathi Anandan, Marco Schaefer, Kathy Lindert, Ruslan Yemtsov, Sandor Sipos, Anush Bezhanyan, Margaret Grosh, and John Blomquist. The Playbook has benefited from extensive consultations and written inputs from colleagues, including Melis Guven, Ubah Thomas Ubah, Sandor Karacsony, Phillippe Leite, Asha Williams, Oleksiy Sluchynskyy, Mohammed Almenfi, Victoria Strokova (Social Protection and Jobs), Marelize Gorgens (Health), Alex Twinomugisha, and Subhashini Rajasekaran (Education). A number of colleagues from the inter-agency group were instrumental in development and finalization of the Playbook: Veronika Wodsak, Christina Behrendt, and Ernesto Brodersohn (ILO); Ralf Radermacher, Anita Mittal, Dominique Leska, Saurabh Bhattarai, Kelvin Hui, and Alicia Spengler (GIZ); Clare McCrum, Emily Henderson, and Roopa Hinton (FCDO); Andres Chamba, Ana Ocampo, Clare O’Brien, Edgardo Yu, and Paul Vonkittilitz (WFP); Alejandro Grinspun and Omar Benammour (FAO); Mariana Balboni and Almudena Fernandez (UNDP); Lisa Hannigan (DFAT); Valentina Barca (consultant to DFAT, FCDO, and GIZ), Tomoo Okubo, Atif Khurshid, and Natalia WinderRossi (UNICEF); Alejandro Grinspun (FAO); Rodrigo Assumpçao (previously ILO), Caroline Tassot (previously OECD), Ermioni Sokou, Doerte Bosse, and Juergen Hohmann (EC); Pontus Korsgren and Britta Olofsson (SIDA); and Wendy Walker and Anand Ramesh Kumar (ADB). The following organizations contributed to its development (in alphabetic order): Asian Development Bank (ADB), Department of Foreign Affairs and Trade (DFAT, Australia); Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ, Germany); European Commission (EC); Food and Agriculture Organization of the United Nations (FAO); Foreign, Commonwealth & Development Office (FCDO, UK); International Labor Organization (ILO); Organization for Economic Cooperation and Development (OECD); Swedish International Development Cooperation Agency (SIDA); United Nations Children’s Fund (UNICEF); United Nations Development Program (UNDP); World Bank Group (WBG); and World Food Programme (WFP). The task was supported by a grant from the Rapid Social Response Fund (RSR), Identification for Development (ID4D) Multidonor Trust Fund (MDTF). Contacts: Tina George Karippacheril (Senior Social Protection Specialist) tgeorge1@worldbank.org; Luis Iñaki Alberro Encinas (Senior Social Protection Specialist) lalberroencinas@worldbank.org; Ana Lucía Cárdenas Martínez (Social Protection Consultant) acardenasmartine@worldbank.org; Conrad C. Daly (Senior Counsel) cdaly@worldbank.org; and Satyajit Suri (Technical Consultant) ssuri3@worldbank.org. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability v ACRONYMS EXECUTIVE SUMMARY ASSESSMENTAND ABBREVIATIONS Acronyms and Abbreviations ADB Asian Development Bank GIZ Deutsche Gesellschaft für Internationale AI artificial intelligence Zusammenarbeit ASPIRE Atlas of Social Protection: Indicators of Resilience GRM grievance redress mechanism and Equity HCD human-centered design BISP Benazir Income Support Program HIN household unique identity number BOMS Beneficiary operations management systems HMT hybrid means testing CBT community-based targeting IBR integrated beneficiary registry CCT conditional cash transfer ICT information and communication technology CDD customer due diligence IDP internally displaced populations CDR call detail records IFMIS integrated financial management information CMIS case management information system systems CODI Core Diagnostic Instrument IGC income generating capacity CONEVAL Consejo Nacional de Evaluación de la Política de ILO International Labor Organization Desarrollo Social IPA Innovations for Poverty Action COTS commercial off-the-shelf ISAS Integrated Social Assistance System CPU central processing unit ISPA Inter-Agency Social Protection Assessments CRM customer relationship management IT information technology CRVS civil registration and vital statistics JSON JavaScript Object Notation CSAE Centre for the Study of African Economies KYC Know Your Customer CSE Calificación Socioeconómica LDSW locally developed software CUIS Cuestionario único de información LLM large language model socioeconómica MDSF Ministerio de Desarrollo Social y Familia DBMS database management systems MDTF multidonor trust fund DCI Digital Convergence Initiative MIS management information systems DDB distributed database MoFSP Ministry of Family and Social Policy DDBMS distributed database management system MOSIP Modular Open Source Identity Platform DFAT Department of Foreign Affairs and Trade MoU memoranda of understanding DNP Department of National Planning MPI multidimensional poverty indexes DPA data protection authority MSDF Ministerio de Desarrollo Social y Familia DPG digital public goods MT means-testing DPI digital public infrastructure MVC model view controller DNI Documento Nacional de Identidad NSER National Socioeconomic Registry DRIS disaster risk information systems OCHA Office for the Coordination of Humanitarian DSPDS digital social protection delivery systems Affairs dSR dynamic social registry OECD Organization for Economic Cooperation and DV data virtualization Development EC European Commission OLAP online analytical processing ESB enterprise service bus PII personally identifiable information ETL extract, transform, load PIN personal identification number EU European Union PMT proxy means tests EWS early warning systems PSP payment service providers FCDO Foreign, Commonwealth & Development Office PWP public works program FLOSS free/libre open source software QR code Quick Response code FOSS free and open source RDBMS relational database management software FPS Ficha de Protección Social RENAPER Registro Nacional de las Personas GBV gender-based violence RIB Registro Integrado de Beneficiarios GDP gross domestic product RSH Registro Social de Hogares GDPR General Data Protection Regulation RSR rapid social response GIS geospatial information systems RUN national identity number vi Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability SASPP Sahel Adaptive Social Protection Program TSA Treasury single account SCTP social cash transfer program UBR Unified Beneficiary Registry (Malawi) SEDESOL Secretaría de Desarrollo Social UCLG United Cities and local Governments SFTP Secure File Transfer Protocol UN United Nations SIDA Swedish International Development UNDP United Nations Development Program Cooperation Agency UNHCR United Nations High Commissioner for Refugees SIFODE Sistema de Focalización para el Desarrollo UNICEF United Nations Children’s Fund SOA service-oriented architecture USSD Unstructured Supplementary Service Data SIIS Integrated System for Social Information VEMTAS Unified Electronic Application and Appointment SISBEN Identification of Potential Beneficiaries of Social Subsystem, Argentina Programs VPN virtual private network SP social protection WBG World Bank Group SPJ social protection and jobs WFP World Food Programme TCV time, costs, and visits XML Extensible Markup Language TOGAF The Open Group Architecture Framework Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability vii EXECUTIVE SUMMARY Executive Summary Our present times are defined by a polycrisis and long-term global challenges. The COVID-19 pandemic, climate change, conflict, inflationary pressures, food insecurity, and weak governance all continue to portend setbacks to human capital and reversal of declines in poverty, with consequences for productivity and economic growth. At the halfway point of the 2030 Sustainable Development Goals, a staggering 670 million individuals continue to endure extreme poverty. Although social protection was expanded in response to the COVID-19 crisis, 4 billion people still lack any form of social protection.1 Despite these trials, this is a time of great possibility to do things differently for social protection programs, to adapt and shift gears. The concept of dynamic inclusion2 and coordination of various actors has become more important than ever for individuals to manage their life cycle risks and for governments to be able to anticipate shocks and respond to an expanding crisis. When social protection systems are dynamic, inclusive, and facilitate the coordination of various actors, they help to place vulnerable people at the heart of the delivery of social programs. Developing a dynamic and interoperable framework that enables the coordination and articulation of social protection measures is paramount to maximizing their impact in a way that is inclusive. The technology landscape of today—and that of tomorrow—brings new possibilities for governments to deliver social services to people, particularly to the poor, rural, remote, and vulnerable. Accelerating growth in technology presents a unique opportunity to solve intractable development challenges while being cognizant of associated risks and unknowns. Harnessing new data sources and technologies, such as artificial intelligence (AI), needs to go beyond “digital,” helping to limit exclusion in the delivery of social programs—especially for the poor and vulnerable, those falling behind, and those with limited-to-no internet access—while ensuring the protection and privacy of data.3 1. See UN (2023). 2. Dynamic inclusion implies that anyone can apply for social protection programs at any time through open and a continuous intake and registration. 3. Although none doubt that technology significantly impacts development, discussions on dynamic social registries, identification, and payment systems tend to swing from one extreme to another. Portrayals range from dystopian depictions where technologies further disadvantage the disadvantaged and punish the poor, to overly optimistic—and often simplistic—utopias where technology results in inclusion and presents infinite possibilities. As countries catch up, few have robust safeguards in place. Data protection and data governance play a vital role in growing capacity, accountability, and trust. Daly et al. (forthcoming) provide concrete pointers on how social protection actors might integrate those principles into the delivery of social protection programs. viii “WHAT MATTERS” GUIDANCE NOTE Delivering social protection programs in a progressively digital world calls for a big picture, systems-thinking approach to building shared infrastructure that functions in a whole-of-government way, even when starting points come from fragmented initiatives. This is by no means a new concept.4 The digital public infrastructure (DPI) approach outlined by the G205 offers a modern continuum to that whole-of-government conceptualization. Social protection programs at large would benefit from tapping into the shared systems-thinking approach while still operating within their specific contextual realities and constraints of working with people in need. Whereas digital delivery systems are presented here in the context of social protection, this should not be construed as serving narrow sectoral interests. Sectors have a critical role in creating national DPI and digital public goods (DPG), upon which other structures (public and private) should be able to build further. Such a vision is necessary from a social protection delivery perspective but also comes from the nature of data exchanges across organizational and political structures, and the aspiration of providing adequate, comprehensive, and sustainable social protection for all members of society. Designing digital delivery systems for scaling-up social programs encompasses the policies, data, processes, governance, technology, and performance criteria required for social protection delivery. To this end, so- called “digital social protection delivery systems” (DSPDS) personify a DPI approach for social programs with intertwined investments in multiple public service platforms,6 including unique identification systems, dynamic social registries (dSR), beneficiary operations management systems (BOMS), multi-program–multi-provider payments, and integrated beneficiary registries (IBR), all designed to be interoperable with each other from conception. DSPDS also use geospatial, case management, grievance redress and complaint and appeals systems, and a host of multi-sectoral administrative and big data sources. DSPDS embody the notion of “invisible engines”7 that empower programs to deliver results from governments to people, impacting households in multiple ways. DSPDS help governments to answer several fundamental questions: (i) Who is who? (ii) Who is in need? (iii) Where are they? (iv) How will they be paid or reached? and (v) Who has received some form of assistance? DSPDS build upon a gamut of DPG,8 function in low-tech environments, recognize the digital divide, are context-specific, and are deployable in a culturally appropriate manner. Building DSPDS to be interoperable across government enables the articulated delivery of social protection policies, exploiting complementarities, and reducing redundancies among different programs. Social protection delivery systems are the operating environment for implementing social protection benefits and services, bridging people and institutions all along the delivery chain. DSPDS refer to a set of interoperable systems that exchange information seamlessly to facilitate the dynamic inclusion of people as well as the coordination and effective delivery of social programs. They bring new capabilities as well as new risks and responsibilities with profound implications for the relationship of trust between governments and people. The throughput of these systems are “data” collected from multiple sources, curated, shared via informed consent by individuals and households, and analyzed to make policy decisions through a systematic, whole-of-government effort. The Playbook on Digital Social Protection Delivery Systems offers a modular DSPDS framework for a holistic approach to data management, analytics, and decision support to scale-up the delivery of social protection to people in a time of expanding crises. The Playbook comprises a Guidance Note and an Assessment Tool designed 4. See, for example, Heeks (2001), Fountain (2004), Dunleavy et al. (2008), Margetts and Dunleavy (2013), and Dunleavy and Margetts (2015). 5. See Hong (2003). 6. “Two-sided platforms” or “multi-sided platforms” in economics refers to the mediating role of service platforms between two or more groups of agents (Evans, Hagiu, and Schmalense 2008; Rochet and Tirole 2003). Platforms are defined as “building blocks (products, technologies, or services) that act as a foundation upon which an array of firms (a business ecosystem) develop complementary products, technologies, or services” (Gawer 2009). 7. “Software platforms are the invisible engines that have created, touched, or transformed nearly every major industry for the past quarter century. They power everything from mobile phones and automobile navigation systems to search engines and web portals” (Evans, Schmalensee, and Hagiu 2008). 8. Examples of existing DPG that DSPDS could leverage include, but are not limited to, MOSIP, OpenG2P, OpenSPP, and OpenCRVS. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability ix EXECUTIVE SUMMARY for social protection policy makers and practitioners working in low- and middle-income countries. On the one hand, the Guidance Note sets up a forward-looking framework to address the core characteristics of DSPDS cascading down to data, processes, technologies, institutions, and performance criteria involved in designing, implementing, and governing such systems. On the other hand, the Assessment Tool is meant to be used to take stock of existing systems plotting out from the Guidance Note. While certain component systems receive greater attention and constitute the focus of the Playbook (for example, dSR), it does not dive deep into other key components, such as unique identification and payments, as there are existing ISPA tools for such systems (ISPA 2017, 2020). In line with the Social Protection Inter-Agency Cooperation Board (SPIAC-B), social protection is defined as “the set of policies and programs aimed at preventing or protecting all people against poverty, vulnerability, and social exclusion throughout their life cycles, placing a particular emphasis on vulnerable groups.”9 The Playbook is mostly focused on non-contributory social protection programs, but core tenets of this report can be extrapolated to contributory schemes. As countries transition toward universal social protection, it is crucial to prioritize support to the poorest and vulnerable, with social assistance playing a central role. CORE CHARACTERISTICS: POLICY, PROGRAMS, AND DELIVERY SYSTEMS DSPDS cannot operate in a policy vacuum: these information systems are a means to an end, not the end in itself. National social protection policies have been adopted by an increasing number of governments to set the strategic, medium-, and long-term goals of social protection programs. Digital delivery systems are enabling instruments to reach those policy objectives. Believing that more advanced “machinery” for efficient social protection delivery is an end unto itself might tempt governments and other stakeholders to create highly sophisticated digital delivery systems that leverage the latest technologies available. However, while there are indeed great potential benefits to such systems, there are also risks, known and unknown, that merit careful attention. Investments in DSPDS must be firmly anchored in robust legal and policy frameworks that inform their design and provide the necessary guardrails to ensure they are used effectively for their intended purposes and subject to overall good governance arrangements, including data protection and cybersecurity provisions. When articulated with the appropriate social protection policies, delivery systems can constitute a powerful operating environment for implementing programs. Social protection delivery systems perform different functions along the implementation phases10 of a delivery chain (Figure A). These phases are common to most social protection programs and include assessment (outreach, intake and registration, and assessment of needs and conditions), enrollment (eligibility determination, enrollment and benefit-service package decisions, and onboarding), provision (payments of benefits and provision of services), and management (beneficiary operations management including their compliance, data updates, grievances, exits, and case outcomes). Key actors interact all along that delivery chain, including, on the one hand, people (be they applicants or beneficiaries) and, on the other hand, institutions (central and local). These interactions are facilitated by communications, technology, and data infrastructure. Fragmentation of social protection programs across sectors often results in the proliferation of siloed information systems for each program. Social protection benefits and services are multidimensional in nature; that is, they are designed for different population groups, life cycle stages, and risk factors, usually resulting in 9. Social Protection Interagency Coordination Board (SPIAC-B). https://socialprotection.org/connect/stakeholders/social-protection-inter-agency-cooperation-board- spiac-b#:~:text=What%20is%20Social%20Protection%20for,particular%20emphasis%20on%20vulnerable%20groups. 10. Because the focus of the Playbook is on non-contributory schemes, the step of contribution collection is not included here. x Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability FIGURE A ASSESS ENROLL PROVIDE MANAGE Social Assessment Eligibility Determination and of Benefits Notification Provision of Benefits Beneficiaries Compliance, Exit Decisions, protection Outreach Intake & of Needs and Registration Conditions Enrollment and Service Decisions Package and Onboarding and/or Services Updating and Grievances Notifications and Case Outcomes delivery chain 1 RECURRING 2 3 4 5 6 7 CYCLE 8 9 SOURCE: Lindert et al. (2020). institutional, political, and operational fragmentation. A national social protection system may include, for example, food and cash assistance for households, maternal health benefits for women, school feeding and scholarships for children, unemployment benefits and productive inclusion measures for workers, disability benefits for the disabled, social pensions for the elderly, and pro bono legal services, among others. Integrating delivery functions across multiple programs reduces fragmentation, improves coordination, and promotes harmonization across social protection programs and beyond, generating synergies and much-needed fiscal efficiencies, but more importantly, ensuring that people are effectively protected at different points in their life cycle. Building DSPDS calls for a business-process orientation and an open and interoperable systems architecture approach to enable data exchanges to achieve greater functionality, produce richer analytical outputs, and optimize costs. A process- oriented, delivery chain approach to building interoperable systems assures that social protection programs’ processes are streamlined, and that high-quality data can be generated, stored, managed, and analyzed. As such, given the complexity of social protection programs involving large flows of personal data and transactions, it is paramount to implement data protection and privacy safeguards by-design. DSPDS refers not just to individual systems but also to their ability to communicate and exchange data with each other seamlessly and efficiently for decision-making, program delivery, and monitoring and evaluation of social policy. DSPDS provides an adaptable and extensible framework to help governments render a more holistic and comprehensive view of who needs support and who receives what, while at the same time reducing administrative burdens for people. Just as different gears in an engine must mesh perfectly to transfer power and make the engine work, different DSPDS component systems must work together seamlessly to ensure data flows are smooth, reliable, and secure (Figure B). Various component systems support social protection delivery and each system is distinct with its own specific functions; but when they are connected through interoperability11 they become a whole greater than the sum of its parts, delivering social protection effectively and efficiently to individuals and households. Core components of DSPDS often include dynamic social registries (dSR), beneficiary operations management systems (BOMS), integrated beneficiary registries (IBR), multi-program multi-provider payments, unique identification, and civil registration and vital statistics systems (CRVS). However, there is no single blueprint for determining which component systems are necessary for a given country or context. Other information systems can also be made interoperable with DSPDS to improve the efficiency and effectiveness of social protection delivery, including program inventories, data analytics platforms, grievance redress and complaints and appeals systems, social insurance, disability registries, farmer’s registries, employment services systems, tax registries, and geospatial information systems (GIS), among others. 11. When describing DSPDS it is important to differentiate integration from interoperability, as they are often conflated. Integration is the process of linking independently designed applications to work together as one system so that the data contained in each becomes part of a larger, more comprehensive system. Integration also enables access to data and functionality from such independent applications through a single interface or service. Interoperability is the ability of systems to interact with each other by exchanging data using common syntactic and semantic data standards. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability xi EXECUTIVE SUMMARY FIGURE B DSPDS: common component systems and their functions DSPDS DIGITAL SOCIAL Education Cash Transfers Health BENEFICIARY PROTECTION OPERATIONS DELIVERY Humanitarian MANAGEMENT SYSTEMS SYSTEMS Disability Social Insurance PROGRAM DATA INVENTORIES EXCHANGE CIVIL REGISTRATION INTEGRATED AND VITAL CRVS BENEFICIARY REGISTRY STATISTICS GEOGRAPHIC MULTI-PROGRAM INFORMATION UNIQUE MULTI-PROVIDER GRIEVANCE SYSTEM IDENTIFICATION PAYMENTS REDRESS MECHANISM SYSTEM GIS CASE MANAGEMENT INFORMATION SYSTEM DATA ANALYTICS DATA EXCHANGE DYNAMIC SOCIAL CM REGISTRY GRM ASSESS ENROLL PROVIDE MANAGE Land / Property Financial / Banking Telecommunications Education Health Road Density Utilities Vehicles Taxes Farmer’s Registry Satellite Imagery Disaster Risk DATA PROTECTION AND PRIVACY LAYER UNIQUE DYNAMIC BENEFICIARY INTEGRATED MULTI-PROGRAM IDENTIFICATION SOCIAL OPERATIONS BENEFICIARY MULTI-PROVIDER REGISTRY MANAGEMENT REGISTRY PAYMENTS SYSTEMS Intake Unique gateway to Beneficiary data Dynamically Enable biographic and apply to one or more management and intake data on governments biometric data programs on-demand grievance redress the benefits to make of individuals delivered to payments to Dynamic data intake Enrollment decisions individuals and people and Determine the from multiple sources and determination of households viceversa unicity of benefit levels and/or individuals and Continuous data service package Assess Interoperate authenticate updates through coverage of with other them interoperability and Payments social systems to self-updating administration and protection ensure third functionalities reconciliation programs parties' acceptance of CIVIL Identify digital REGISTRATION Assess the needs and Compliance with AND VITAL conditions of conditionalities or complementary transactions STATISTICS applicants accompanying or redundant measures benefit Payments Establish a Reach people in need allocations provision and person’s of support and Program’s reconciliation existence quickly scale up social performance and record assistance for measurement and vital events shock-response monitoring SOURCE: Original for this publication. xii Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability DATA Data are the core input and output of DSPDS, supporting all stages of the social protection delivery chain. As the throughput of DSPDS, data are transformed into information by multiple processes along its life cycle, including harmonization, cleaning, deduplication, integration, exploitation, and destruction, among others. DSPDS thus play an important role in enabling and automating social protection delivery chain processes: recording, transforming, and exploiting data to inform policy decisions, as well as supporting program implementation, monitoring, and evaluations. Due to the nature and the sheer amount of data that they help to manage, DSPSD play a growing role in ensuring the equitable application of the social contract for data in the ever-growing digital economy.12 DSPDS enable the interoperability of data from different sources into biographic, socioeconomic, and benefit management data sets to reduce redundancies and exploit complementarities between them. Beyond the specific contents of these data sets, modularity and minimalism are key attributes needed to dynamically update social registries. Social registries are one of the main components of the DSPDS machinery that can manage the intake and registration and the assessment of needs and conditions processes of the delivery chain.13 Modular and minimal data support the transition of a social registry from a static database updated once every few years through administrator-driven sweeps to a dynamic social registry.14 A dSR is updated on-demand and combines different types of data through various direct and indirect data intake methods15 by applicants and by administrators of social programs. DSPDS data lie within a static-to-dynamic spectrum, depending on their nature and source. Due to the ever- changing circumstances of poverty and vulnerability, the socioeconomic data used to represent and capture such phenomena have a latent half-life, depreciating or losing currency as time passes. As such, to keep dSR data up to date, the system can harness self-reported data directly collected from households through questionnaires purposefully designed for social registries, and indirectly collected data such as administrative records generated by other entities and made interoperable with the dSR. Relevant trade-offs between directly and indirectly collected data in quality, cost, and timeliness should be considered when populating dSR data sets. Hybrid approaches, whereby directly and indirectly collected data are combined and complemented, can decrease the overall costs of keeping a dSR up-to-date and lead to a more accurate and fairer prioritization of policies. The consolidation of socioeconomic questionnaires can reduce the administrative burden of data collection for households. However, the length of a harmonized questionnaire directly impacts the cost and logistics of administering it to large numbers of households, further motivating the need for modular data sets. These factors are important to keep in mind when updating a dSR and responding to shocks, be it conflict, climate, health, economic or other. 12. The Playbook builds on the position announced in the World Development Report 2021: Data for Better Lives, namely in its call “for a new social contract for data—one that enables the use and reuse of data to create economic and social value, promotes equitable opportunities to benefit from data, and fosters citizens’ trust that they will not be harmed by misuse of the data they provide” (World Bank 2021). 13. Some countries do not use social registries to enable the assess stage of the delivery chain. For instance, some highly formalized economies verify income and assets directly from administrative databases, without pulling those records into a separate registry. In other instances, central population registries capturing sociodemographic information and at times, employment status, may be sufficient. In the Playbook, we reason that the advantages of having a social registry are multifold. Social registries serve as a repository of a wide range of socioeconomic information pertaining to individuals and households. In contrast, administrative data sources often lack the breadth and depth of the data that a social registry can provide. A comprehensive approach ensures that the government has a complete and accurate understanding of an individual or household’s needs and conditions, enabling more precise targeting of social benefits and services. By consolidating information through a cohesive system, social registries significantly reduce the administrative burden placed on both applicants and government agencies. Note that, regardless of what information system is utilized at this stage, complete and accurate understanding of an individual’s or household’s needs and conditions may still require a social worker’s assessment. 14. A dSR is an information system that intakes data dynamically from multiple sources facilitated by an interoperability framework with data security and privacy protocols based on people’s consent such that information can be continuously updated on-demand. The dynamic nature of dSR can be contrasted with more static social registries that intake data through sporadic or even periodic but administrator-driven registration campaigns. See Leite et al. (2017) for further discussion. 15. Direct intake of data refers to information generated through an intentional and direct process involving the active participation of individuals who provide self-reported data through specific questionnaires designed for social registries. Indirect intake of data, on the other hand, refers to information that is generated indirectly or automatically as a byproduct of transactions, services, benefits, or events. In this case, administrative records are considered indirectly collected data because they are created without the active involvement or responses of individuals for the purposes of social protection. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability xiii EXECUTIVE SUMMARY The availability of different data sources can vary greatly among countries depending on the maturity of their data ecosystem. As such, data directly collected through self-reported questionnaires has been the earliest and most commonly used data source for social registries, particularly through in-person interviews. As social registries evolve and become more dynamic, they can utilize remote data collection mechanisms such as web- based platforms or Unstructured Supplementary Service Data (USSD), and interoperate with other systems that provide administrative data, such as tax systems, vehicle registries, disability registries, farmer registries, health management systems, and education management systems, among others. While many programs rely on “traditional” data sources to assess needs and conditions and to monitor programs, an increasing number are considering novel sources such as “big data” to overcome some limitations. Big data may be helpful for assessing and reassessing needs and conditions as well as program monitoring much more dynamically. Nevertheless, the main risks associated with big data and the methods needed to extract insights from them, such as machine learning and artificial intelligence (AI), are yet to be fully understood, making it difficult to appropriately craft sustainable solutions. Self-reported data, administrative records, and more recent, novel data sources may be combined or connected through a unique identifier to complement each other, thereby using their respective strengths to offset their respective weaknesses. Criteria such as breadth, depth, accuracy, and timeliness allow for an assessment of trade-offs of different data sources. DELIVERY CHAIN Building on the Social Protection Delivery Systems Framework,16 the Playbook illustrates the interactions among DSPDS component systems at each stage of the delivery process. Outreach is the process by which people are informed about social protection programs through varying strategies, according to the local context and characteristics of the intended population. As such, the data contained in DSPDS’ underlying component systems can be leveraged to prioritize communication with households and individuals through technology- enabled applications. Intake and registration is the process by which data and documentation are collected and stored to register intended populations for consideration of potential eligibility. This stage is the first “touchpoint” where data are collected and updated through different sources, in many instances (but not always) through social registries. Direct approaches for data intake comprise in-person and remote modalities relying on digitally enabled means or, sometimes, on paper. Indirect approaches leverage data exchange and interoperability mechanisms to pull administrative records from different sources. Whether the intake process satisfies the principle of dynamic inclusion depends on whether the approach taken is on-demand or administrator-driven. Administrator-driven approaches tend to be periodic (every three to five years, sometimes more) and do not typically capture the entire population. On-demand approaches allow people to take the initiative to apply at a time of their own choosing and are better suited for the progressive realization of universal social protection. They also align with good governance and data protection principles by engaging individuals and households—the “data subjects”—and giving them added control over their data, thus growing their individual agency. While the administrator-driven and on-demand approaches are two distinct models, they can complement each other and be used strategically to ensure inclusion. Similarly, combining remote digital solutions with in-person modalities helps limit the exclusion, particularly of the most vulnerable groups with limited connectivity. 16. Developed by Lindert et al. (2020). xiv Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability Assessing needs and conditions involves systematic processes for analyzing data from registered individuals or households to determine potential eligibility for specific programs. Once they are completed, verified, and validated, data from intake and registration is a key input to assessing needs and conditions. These data are processed and analyzed through various instruments and techniques to describe the needs and conditions of applicants or registrants, and to prioritize and determine their potential eligibility for specific benefits or services. Countries with social registries leverage these systems to produce back-office analyses that compute outcome variables for each registrant based on one or multiple predefined assessment methodologies following program eligibility criteria. Common assessment approaches to assess potential eligibility include welfare assessment methodologies that rely on different data sources and methods to estimate income, consumption, vulnerability, food security, or assets, as well as categorical methods that rely on “easy-to-observe” geographic or demographic characteristics (assuming that needs are relatively homogenous within the group) and other methods, such as community-based targeting, public lottery, or self-declaration. Updating information to reassess needs and conditions is necessary for dynamic inclusion; it allows for better planning and also meets good governance and data protection requirements. By keeping data up-to-date, administrators can reassess needs and conditions of applicants to determine eligibility as their situations change and manage beneficiary operations effectively by supporting the implementation of exit decisions. Up-to-date data are also crucial for designing effective social policies, allocating resources efficiently, emergency preparedness, and policy evaluation and monitoring. The periodicity of updating depends on the type of information contained and is influenced by the sources of information for each variable, whether from self-reported information or data exchange with other information systems. Interoperability of systems is necessary to ensure that the underlying component systems of DSPDS communicate with each other, with other administrative systems, and potentially with non-traditional data sources. Interorganizational data exchange protocols are key for dynamic inclusion, data quality, efficiency, and integrity. These protocols are typically based on an interoperability framework defined at the country or broader regional level. While the specifics vary, registration processes should include applying quality controls to the data and consolidating and storing the revised dataset. Countries with social registries can leverage them to recommend potential eligibility, but each program makes its own determinations about eligibility and enrollment. Eligibility refers to determining which applicants meet the necessary criteria to qualify for a program. Programs applying welfare criteria to determine eligibility use welfare estimates as an input and compare them to a given threshold. Geographic quotas and demographic and socioeconomic characteristics are also frequently employed for eligibility determination. Once a registrant is deemed eligible, program administrators decide whether the individual or household is enrolled or wait-listed for a program, considering constraints such as budget and operational capacity. Programs must also decide what kind of benefits and services beneficiaries will receive. Benefits and services can be uniform or vary based on the specific characteristics of households or individuals. These decisions and functionalities are usually made and performed by each program and supported by the program’s BOMS. The next step along the social protection delivery chain consists of delivering benefits and services to households and individuals enrolled in the program. Given the varying characteristics of benefits and services in social protection, the Guidance Note briefly discusses the systems-based processes emerging from monetary benefits.17 Monetary benefits are distributed to people through different coexisting modalities, with payments systems having been digitalized to varying degrees. Based on the package and level of benefits previously 17. For a more detailed discussion on social protection payments, see the ISPA Payments tool available here: https://socialprotection.org/connect/stakeholders/ ispa-inter-agency-social-protection-assessments. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability xv EXECUTIVE SUMMARY determined for enrolled beneficiaries, BOMS generate the payroll administration for monetary benefits, which is then transferred to payment provisioning platforms to distribute benefits. All payment modalities require authentication of the identity of the person claiming to be the rightful beneficiary to disburse payments. The next step consists of ensuring that funds are received accurately and on schedule through a payment reconciliation process. Following this, BOMS can share program and period-specific beneficiary registries to the IBR, which consolidates beneficiary registries from all programs. IBRs can be used by governments to detect beneficiary redundancies, complementarities, or coverage gaps across multiple programs, thereby supporting governments in monitoring and reporting for increased transparency and accountability. Based on a set of predefined rules, programs can regularly update, revise, and verify beneficiaries’ data and keep track of their progress to determine their program status and make operational decisions. Beneficiary operations involve day-to-day decisions such as permanence in the program, delivery logistics, monitoring of conditionalities, potential adjustments in level of benefits or services, and grievance redress. This stage is traditionally supported by the program BOMS; however, when systems are interoperable, some of these tasks can be facilitated by other systems.18 Grievance redress mechanisms (GRM)—sometimes referred to as complaint and appeals mechanisms—give people a voice to express their feedback on the management and implementation of social protection policies and interventions. These mechanisms are a key part of good data governance and include requesting corrections to service-related data, requesting information, making suggestions, and filing complaints and appeals at any stage of the delivery process. A well-designed GRM is available not only to program beneficiaries but also to all social protection information systems users, including registrants, non-eligible and non-enrolled applicants, and all social protection stakeholders. Although many countries have developed program-specific GRM information systems, there are several advantages to a centralized GRM platform which can be facilitated by the interoperability of social protection information systems. TECHNOLOGY DSPDS are envisaged as interoperable service platforms that support the efficient delivery of various social protection programs by facilitating seamless data sharing. Through the implementation of DSPDS, governments can streamline their social protection program management processes, facilitate data-driven policy making, and perform better expenditure planning, while also simplifying the human experience of applying to and receiving benefits for applicants and beneficiaries. The DSPDS architecture enables the development of services that are generic in nature and can be used by a plethora of social programs. Clearly articulated design principles form the basis of DSPDS technological architecture to support key business processes and objectives. The DSPDS framework is based on key design principles such as human-centered design (HCD), where people are considered the “first mile”19 of social programs with a focus on simplifying their service-delivery experience by, for instance, establishing easily accessible touch points for households to manage their socioeconomic data, and safeguarding people from inclusion or exclusion risks and harms. the creation of a verified data source on socioeconomic attributes for individuals and households by linking multiple sources of information through master data management, as well as enabling open and standards-based data exchange for interoperability among different component systems of DSPDS are also important to consider. Other principles 18. For a more detailed discussion on beneficiary operations management, refer to the Sourcebook (Lindert et al. 2020). 19. When systems are not designed with the perspective of reaching the poor and vulnerable first—the “first mile”—it perpetuates the exclusion of those in most need of social protection, who are usually left until last. xvi Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability include developing loosely coupled application units and microservices that support architectural reuse and refactorability, avoiding vendor-lock-in of front- and back-office technology, and ensuring strong data protection and user privacy measures. The DSPDS architecture should be designed keeping in mind the security and privacy of an individual’s personal data from conception “by-design” and “by-default.” Data protection by design and by default means that security and privacy are not afterthoughts but rather fundamental aspects of designing built-in controls for all key functions, workflows, and processes of DSPDS components, from conception through implementation. Secure and private design approaches are built around good international data protection and governance practices, such as clearly articulating program purpose to guide and govern data collection, limiting the collection of individual personal data to the absolute minimum that is required for that articulated service delivery purpose (unless further communication is made and revised consent from the beneficiary obtained), and ensuring that individual personal data are always secure, including application endpoints (such as mobile devices, tablets, and computers) in use, in transit, and in storage. Ensuring the security and privacy of personal data to prevent unauthorized access and providing adequate cybersecurity measures are cross-cutting principles for DSPDS components. These principles are based on internationally accepted norms and good practices, ones that ought to be reinforced through domestic data protection regulations and guidelines. Data interfaces include various channels for intake of data and output provisioning of data flowing inside and outside of the DSPDS data ecosystem. The software applications layer of the overall DSPDS architecture supports the functions of implementing social protection benefits and services all along the delivery chain. Front-office software applications provide a visual interface for individuals, families, and households, as well as frontline administrators who may operate the applications on behalf of registrants. With the rapid penetration of mobile devices and mobile coverage, mobile applications are being used for intake and registration, cross-checks, and assessment. Back-office software applications enable program administrators to manage applicant data for potential eligibility assessment. Back-office software applications also provide institutional administrators with the capabilities required for core data processing and master-data management of beneficiaries and their various linked social programs. The structure of data management varies, depending on the most appropriate data integration and interoperability framework to each context—there is no single or “right” model. Data exchange and interoperability frameworks require robust legal, organizational, semantic, and technical underpinnings. DSPDS platform applications and services favor open standards to ensure interoperability between the various DSPDS components and external systems. As a vendor-agnostic model, the DSPDS platform design uses open application programming interfaces (APIs) as a primary method for data exchange among various components within DSPDS and across external systems, although other options exist. dSRs with a greater degree of interoperability have developed sophisticated methods of data exchange. For instance, a virtualized data management model has the advantage of agility of data exchange and a high degree of interoperability. Data from various administrative sources are not physically transferred to the agency that administrates the dSR, thereby enhancing security and privacy. Instead, data are virtualized for the purpose of assessing needs and conditions, temporarily processed, but they are not archived. This approach, among others, intends to safeguard against the risk of data hoarding, data grabs, and data breaches, relying on audit trails, timestamps, and other quality assurance methods to mitigate risks of data integrity loss. In these and in other cases where there is a greater use of interoperable data, protocols must be in place to address issues arising from data conflicts between a dSR and other systems. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability xvii EXECUTIVE SUMMARY Over time, DSPDS platforms will likely undergo several changes due to evolving legal and regulatory requirements and modifications in government processes, constant technological evolution, and developments in computing and storage technologies.20 Quantum computing, new developments in AI such as large language model (LLM), and advances in data storage and infrastructure are context-specific, and have far-from clear implications; nevertheless, it is useful and important to keep them—and others—in mind when designing DSPDS. Also, a shared data center approach helps to manage the time and cost of procurement, investment, operations, and economies of scale.21 GOVERNANCE Robust legal and institutional frameworks provide the guardrails for sound governance and management of DSPDS. These measures are solidly based in the law, institutionally anchored, and supported through cohesive regulatory instruments. They are evidenced through the existence of well-defined, comprehensive documentation of key roles and responsibilities, with relevant processes being well understood by front- and back-office DSPDS administrators. In such instances, institutions operate in a predictable and responsible manner, are human-centric, and capable of adapting to beneficiary needs and interests with concrete safeguards in place. At a most basic level, imposed limits and directions might be abstract—for instance, notions of doing no (digital) harm.22 Attention ought to be given by all involved in DSPDS design and implementation that each person is treated equally and that their dignity is constantly preserved, a matter of particular concern in dealing with society’s most disadvantaged groups, such as the poor and vulnerable. Legal and institutional frameworks are elaborated through a series of stages. Strategic or “high-level” governance—what might be referred to as directional “chart-setting”—is typically done through policy instruments. These instruments provide strategic governance for the entire DSPDS framework, including a vision for the design and implementation of the elements needed to safeguard and enable interoperability among DSPDS components. Through those policy instruments, objectives, priorities, and goals for DSPDS are set, and the corresponding resources and necessary political commitment are secured. Multistakeholder consultations and participatory involvement are critical to getting buy-in and ensuring the viability and accountability of the larger governance ecosystem. In order to be enduring and reliable, the vision laid out in policy instruments needs to be structurally realized through legislative text(s)—ideally, on one(s) that build upon rights drawn from already-existing constitutional bases—and then duly elaborated through regulation. Beyond grounding the legal foundations for DSPDS in law, it is usually advisable that there be an explicit connection between the state’s legal obligations to provide such services and other fundamental rights.23 Although there are a number of implicated areas, the nature of DSPDS and the rich and vast amount of data concerned means that it is particularly important to elaborate a robust data protection and privacy regime, one built on international good practices and ensuring participatory data stewardship and data agency. Private entities constitute another crucial aspect of institutional governance, from the perspective of service provision—both cash (payment service providers) or in-kind (non-governmental organizations, private social service facilities, and others)—but also from the perspective of data provision, implying additional responsibilities for sector governance, such as quality assurance frameworks. 20. See, for example, synthetic data storage on DNA (Tabatabaei et al. 2020). See also https://www.ebi.ac.uk/research/goldman/dna-storage/. 21. For example, the Republic of Korea built a Government Integrated Data Center in 2005 for whole of government with more than 20,000 pieces of hardware equipment and a 30 percent reduction in data center costs. 22. See, for example, the “Cybercrime Toolkit” (World Bank and United Nations 2024). 23. See concerns raised by the UN OHCHR about the emergence of the “digital welfare state,” saying that all too often the real motives behind such programs are to slash welfare spending, set up intrusive government surveillance systems, and generate profits for private corporate interests (United Nations 2019). xviii Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability The process of institutionalization—in many ways, the heart of governance—is needed to realize effective DSPDS, with the administrative or “back-office” elements forming a key part therein. Institutions are needed for strategic planning, rule- and standard-setting, compliance and enforcement, and evidence-based learning; they undertake much of the “back-office” work that makes systems function (World Bank 2021, Chapter 8). No single blueprint describes what those frameworks should look like, and due consideration is needed for the diversity of factors in order to determine what is appropriate for each country and context. Nevertheless, there are certain elements and international good practices to be considered. Part of that context is the very diverse nature of social protection policies and programs. Social protection programs implicate, directly or indirectly, a multitude of actors, all of which must be aligned—or interfaced with—to achieve systems interoperability. Identifying an entity in the DSPDS governance ecosystem is a particularly nuanced and context-specific governance matter, as that entity is to serve as a steward of secure data flows among people and multiple institutions and levels of government, as well as with the private sector. There are two fundamental options: either to create a (new) separate administrative authority, or to establish the role as an office or unit within an existing one. Regardless of the approach taken, the essential is, first, that a clear mandate is given, and second, that clear operating lines and responsibilities are set down. Erecting robust legal and institutional frameworks does not operate in a silo: doing so should also result in the strengthening of surrounding and related institutions, including, for instance, national data protection and cybersecurity authorities. Good governance of DSPDS requires creating localized points of interaction for people, thereby facilitating access to social protection benefits and services. What is known as the “front-office”—that is, the interface between delivery systems, wider government structures, and people—is a point of contact for individuals and households. There is no one point of interaction: rather, as people have many and divergent needs, they will necessarily interact with DSPDS and the programs they support at several—and varying—points in the delivery chain. A multichannel gateway designed with the perspective that “people are the first mile for social programs” improves user experience, intermediates in cases where technology becomes a barrier rather than an enabler, mitigates the risk of exclusion by throwing “all doors open” for people to interact with the state, and ensures dynamic inclusion. In addition to creating efficiency gains for government, a consolidated gateway with many doors, providing access to multiple programs, optimizes resources—including those of time, financial (both actual as well as opportunity costs), and number of visits—that people need to employ to access social protection. A multichannel approach can also help governments to ensure that all groups are included. The front-office interface to people is managed and coordinated by DSPDS front-office administrators but may require shifting some degree of implementation responsibility to other actors, including local governments, with greater proximity to people, particularly the poor and vulnerable. PERFORMANCE Efficient and effective DSPDS enable well-performing delivery systems, informing social protection policy, increasing transparency and accountability, and ensuring that the intended beneficiaries are reached when in need. An effective system is not only one that reaches, registers, and provides benefits and services to most of the intended population, but it is also a system that is inclusive because it accommodates the specific needs of vulnerable populations and those who face access barriers (Lindert et al. 2020). Moreover, an efficient system exploits synergies within government and stakeholders to minimize costs for administrators, programs, and people. By increasing efficiency and effectiveness in the delivery of social protection, DSPDS help alleviate the Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability xix EXECUTIVE SUMMARY dual challenge of coordination and inclusion in order to maximize the impacts of social policy. Measuring the performance of DSPDS is critical to identifying areas for improvement and optimizing the use of resources to achieve social protection objectives. Regular monitoring of performance indicators can help detect bottlenecks and assess data and systems integrity challenges early on to course-correct to avert systemic challenges. DSPDS enable social programs to deliver results from governments to people more effectively, ultimately resulting in impacts on households. While DSPDS can contribute to the improvement of social outcomes, it is important to acknowledge that they are not the only factors at play. The political economy, social policy, financial and human resources, capacity, cultural norms, and individual behaviors also play crucial roles in shaping social outcomes. Indeed, technology and data support programs and people throughout the delivery chain to ensure more efficient and effective social protection delivery. Along with processes and institutions, these are the key building blocks of DSPDS. Beyond supporting delivery, systems interoperability and data exchange enhances the performance of social protection policy by informing strategic decisions and supporting monitoring and evaluation objectives through data analytics. Data analytics leveraged by DSPDS can be used to measure the effectiveness of the broader set of social protection systems, identify areas where policies are falling short, and track the progress of social protection policy implementation over time. For instance, inclusion and exclusion errors are commonly used metrics that the analytical platforms of DSPDS can shed light on to determine whether programs are well targeted and to improve their accountability. This analysis is facilitated by exchanging data between the integrated beneficiary registry and the social registry. Dynamic inclusion and interoperability can enable opportunities for countries to mobilize existing resources and delivery systems, to make coverage flexible in response to changes in needs and conditions in response to shocks. To this end, the Playbook’s modular DSPDS approach offers a holistic approach to data management, analytics, and decision support to enable the delivery of social programs to vulnerable and poor people. xx Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability “WHAT MATTERS” GUIDANCE NOTE I. Introduction 1. MOTIVATION “Dynamic Inclusion, Interoperability and Scaling up Social Protection in a time of Expanding Crises.” Our present times are defined by a polycrisis and long-term global challenges—pandemics, climate change, conflict, food insecurity, inflationary pressures, and weak governance—that portend setbacks to human capital and a reversal of declines in poverty, with consequences for productivity and economic growth.24 Irrespective of these covariate shocks, ordinary life cycle events like health emergencies, a pregnancy, or a work injury can pose equally significant idiosyncratic shocks to individuals and households by compromising their ability to generate income (Figure 1). Evidence suggests that there could be divestment from human capital at critical moments of the life cycle: setbacks in learning because of children being out of school, compromises on nutrition, increases in morbidity and mortality, reductions in access to and quality of essential health services, and job losses, notably among informal workers including a large share of women.25 Despite these trials, this is also a time of great possibility to do things differently and for social protection programs to adapt and shift gears. Accelerating growth in technology presents us with a unique opportunity. The COVID-19 crisis is estimated to have cast about 97 million people into poverty in 2020, the greatest reversal in the fight against global extreme poverty since 1998.26 To slow down the increase of extreme poverty and to protect the livelihoods of the most vulnerable, more than 220 countries deployed over 3,300 social protection measures, 58 percent of them being social assistance (Gentilini et al. 2021). In light of significant gaps in social protection delivery systems, many governments responded to the crisis triggered by the COVID-19 pandemic by building dynamism and interoperability into static, self-contained, or sometimes absent delivery systems. Some 24. For instance, new research shows that climate change risks pushing 130 million people into poverty by 2030 (Jafino et al. 2020). 25. See, for instance, WFP (2022). 26. Mahler et at. (2021); World Bank 2020b. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 3 INTRODUCTION Limited FIGURE 1 Access to Finance Crime & Our present Violence times are Demographic Unemployment, defined by Change Informal Jobs a polycrisis Remoteness and long- term global Low Income challenges POVERTY Inadequate VULNERABILITY Housing Natural Low Skills Disasters & Education Health Shocks Malnutrition Displacements & Food Insecurity SOURCE: Lindert, George, and Leite (2018) adapted for this publication. expanded social protection coverage by pulling data from existing administrative systems, including program waiting lists, through data-sharing arrangements and cross-checks.27 Other countries put in place online and offline on-demand modalities for intake and registration to reach people who were not in any existing database.28 And some governments used artificial intelligence (AI) and “big data” to prioritize social assistance in data scarce environments.29 The pandemic thus also served as an important reminder that social protection systems can best be leveraged for crisis response if countries build strong, comprehensive, and dynamic systems before the onset of a crisis. Co-variate and idiosyncratic shocks highlight the foundational role of technology and data platforms in building social protection delivery systems to support people when in need. During the pandemic some countries were able to use social registries to prioritize and scale-up safety nets when they contained up-to-date and accurate 27. Brazil and Indonesia expanded their reach quickly by adding all those households already in their databases of potential beneficiaries. Sri Lanka included all those households on waiting lists before the pandemic. Argentina and Peru cross-referenced social registry and social insurance databases. In Pakistan, where social insurance coverage is very low, the filters included having a public sector worker in the household, vehicle and property ownership, and the amount spent on telephone bills. Ecuador supplemented its incomplete social registry with geographic targeting using census data and mobile phone usage data. Social registries, where information is pulled from different databases that tend to be updated more frequently, as in the case of Türkiye, proved more agile in this regard (Gentilini et al. 2021). 28. Thailand approved 23 million applications from informal sector workers and farmers—more than half of the working-age population. More than 6 million online benefit applications were validated in South Africa. Brazil registered about 27 million households in a matter of weeks through its online process. Indonesia also used village officials to collect new data. Cambodia expanded its social registry during the crisis, with commune officials collecting new data. 29. Governments explored predictive models to locate high-priority clusters of vulnerability (Togo, Ecuador) using high-frequency surveys, census data, mobile phone metadata (call detail records), satellite imagery, and machine learning algorithms. 4 Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability data for large parts of the population. Many governments found that they had a core set of beneficiaries in their social programs, but they sought to reach newly affected and uncovered households. Many also realized that they were operating with mostly static social registries that no longer contained the up-to-date data needed to expand social programs: families vulnerable today may not have been in the social registry 3 to 5 years ago. For instance, the Philippines realized during the pandemic that although coverage was high in their social registry, data had not been refreshed in more than five years, and as a result it could not be used to effectively expand cash transfers.30 Unique identification systems and payments platforms were also crucial in enabling the rapid scale-up and expansion of safety nets and programs. On the other hand, countries that cover large parts of the population through categorical life cycle benefits or social insurance schemes protect the population against life cycle risks both in normal times as well as in the event of a shock, with the social protection system acting as an automatic stabilizer. Coordination and inclusion were identified as two critical and perennial challenges of social protection systems in low- and middle-income countries in the Sourcebook on the Foundations of Social Protection Delivery Systems.31 Social protection programs focus on multiple population groups with divergent needs and vulnerabilities throughout the lifecycle, some prioritizing maternity or early childhood while others supporting youth, the disabled or the elderly. This requires multiple actors to deliver a wide variety of services and benefits such as nutrition supplements, childbirth allowances, trainings and skills, disability benefits or social pensions (Figure 2), often resulting in fragmentation in the provision of social protection. Without coordination, the efficiency and effectiveness of social protection systems is affected. This can result in duplication of processes and coverage, missed opportunities to offer bundles of benefits and services to tackle the different dimensions of poverty and vulnerability, and increased costs for people as they navigate a complicated bureaucracy (for example, travel costs to separate offices, lack of information on certain programs, among others). Likewise, outdated or missing social protection information systems have prevented many countries from scaling-up programs, reaching “first-mile” populations,32 and ensuring dynamic inclusion of anyone in need of social protection, particularly when responding to shocks. When systems are not designed with the perspective of reaching the poor and vulnerable first—the “first mile”—this perpetuates the exclusion of those in most need of social protection, who are usually left until last. The concepts of dynamic inclusion33 and interoperability across various delivery systems have become more important than ever for governments to prepare and respond to shocks, both covariate and idiosyncratic. Safety nets need to be able to catch people when they fall. Technology, data, and innovations can serve governments to rapidly scale-up and coordinate the delivery of safety nets in times of need. When systems are dynamic, inclusive, and facilitate the coordination of various actors, they help place vulnerable people at the heart of the design and delivery of social programs. In delivering social protection and human development programs more broadly, understanding people’s contexts and their journey is fundamental to their design. In recent years, systems supporting social protection programs have taken a more defined form, transitioning beyond standalone static systems toward a more comprehensive network of dynamic, open, and interoperable platforms spanning several stages of the social protection delivery chain. These advances have emerged against the backdrop of accelerating technology innovations in data science, machine learning, cloud computing, biometrics, remote sensing, and mobility. 30. G2Px Initiative (World Bank 2020d). 31. Also referred to as the Sourcebook (Lindert et al. 2020). 32. From a human-centered design approach to delivering social protection, poor and vulnerable people are the first mile and not the last mile. See presentation “The ‘First Mile’ of Delivering SPJ: Human-Centered Design” (George et al. 2018). 33. Dynamic inclusion implies that anyone can apply for social programs at any time through open and continuous intake and registration. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 5 INTRODUCTION FIGURE 2 Social protection benefits and services Cash Transfers (CCTs or UCTs) Unemployment Birth, Child Allowances Benefits Maternity School Feeding, Supplies, Disability Social Food Stamps Public Works Benefits Transport benefits Pensions Emergency Nutrition Wage Care-Giver Contributory Scholarships Assistance Supplements subsidies Allowance pensions Health Benefits Households Maternity Children Youth Labor Disabilities Old Age Intermediation, Referral, Counseling, Psycho-Social Support Services Family Parenting Services Disability Active aging Services services services Child care services Trainings and skills Emergency Services ECD & nutrition Microcredits Legal Services Child protective services Financial and productive inclusion SOURCE: Original for this publication. Delivering social protection programs in a progressively digital world calls for a big picture, systems-thinking approach to building shared infrastructure that functions in a whole-of-government way, even when starting points come from fragmented initiatives. This is by no means a new concept.34 The digital public infrastructure (DPI) approach outlined by the G2035 offers a modern continuum to that whole-of-government conceptualization. Social protection programs at large would benefit from tapping into the shared systems-thinking approach while still operating within their specific contextual realities and constraints of working with people in need. Whereas digital delivery systems are presented here in the context of social protection, it should not be construed as serving narrow sectoral interests. Sectors have a critical role in creating national DPI and digital public goods (DPG) upon which other structures (public and private) should be able to build further. Such a vision is necessary from a social protection delivery perspective but also comes from the nature of data exchanges across organizational and political structures, and the aspiration of providing adequate, comprehensive, and sustainable social protection for all members of society. 34. See, for example, Heeks (2001), Fountain (2004), Dunleavy et al. (2010), Margetts and Dunleavy (2013), and Dunleavy and Margetts (2015). 35. See Hong (2023). 6 Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 2. SETTING THE SCENE: SOCIAL PROTECTION, PEOPLE, AND TECHNOLOGY Social protection delivery systems are the operating environment for implementing social protection benefits and services, and for bridging people and institutions all along the delivery chain. That operating environment is anchored in core implementation phases along the delivery chain.36 These phases are common to most programs and include outreach, intake and registration, assessment of needs and conditions, contribution collection in the case of contributory schemes, decisions on eligibility and enrollment, provision of benefit payments and services, beneficiary operations management, reassessment, and exit decisions. People and institutions interact all along the delivery chain. Those interactions are facilitated by technology and data to help to transform the management of social protection programs, enabling the flow of information as well as the automation of many processes. Designing digital delivery systems for scaling-up social programs encompasses the policies, data, processes, governance, technology, and performance criteria required to deliver social protection benefits and services digitally. To this end, so-called “digital social protection delivery systems” (DSPDS) personify a digital public infrastructure (DPI) approach for social programs with intertwined investments in multiple public service platforms,37 including unique identification systems, dynamic social registries (dSR), beneficiary operations management systems (BOMS), multi-program–multi-provider payments, and integrated beneficiary registries (IBR), all designed to be interoperable with each other from conception. DSPDS also use geospatial, case management, grievance redress and complaint and appeals systems, and a host of multi-sectoral administrative and big data sources. DSPDS embody the notion of “invisible engines”38 that empower programs to deliver results from governments to people, impacting households in multiple ways. DSPDS help governments to answer several fundamental questions: (i) Who is who? (ii) Who is in need? (iii) Where are they? (iv) How will they be paid or reached? and (v) Who has received some form of assistance? DSPDS build upon a gamut of DPG,39 function in low-tech environments, recognize the digital divide, are context-specific, and are deployable in a culturally appropriate manner. DSPDS enable the articulated delivery of social protection benefits and services, leveraging complementarities and reducing redundancies among different programs. Coordinating and articulating social protection measures within governments becomes paramount to maximizing their impact. As such, DSPDS supports the articulated delivery of social protection measures by collecting and processing data to assess the needs and conditions of the population, including the poorest and most vulnerable, in addition to managing information on people and the benefits and services provided to them. Increasingly, this broad coalition of component information systems stresses the importance of building a concerted and human-centered approach to designing social protection delivery systems that include and protect people. During the pandemic, countries with close to universal coverage of unique identification systems and up-to-date social registries, interoperable with other information systems, were better prepared to deliver social assistance to those in most need.40 As a result, the COVID-19 crisis increased the demand for dynamic and interoperable systems for decision support for shock-responsive social programs. An 36. Based on the Social Protection Delivery Systems Framework developed by Lindert et al. (2020). 37. ‘Two-sided platforms’ or ‘multi-sided platforms’ in economics refers to the mediating role of service platforms between two or more groups of agents (Evans, Schmalensee, and Hagiu 2008; Rochet and Tirole 2003). Platforms are defined ‘as building blocks (products, technologies, or services) that act as a foundation upon which an array of firms (a business ecosystem) develop complementary products, technologies, or services’ (Gawer 2009). 38. “Software platforms are the invisible engines that have created, touched, or transformed nearly every major industry for the past quarter century. They power everything from mobile phones and automobile navigation systems to search engines and web portals” (Evans, Schmalensee, and Hagiu 2008). 39. Examples of existing DPG that DSPDS could leverage include, but are not limited to, MOSIP, OpenG2P, OpenSPP, and OpenCRVS, among others. 40. For instance, Egypt, Türkiye, Peru, and Argentina proved agile with interoperable systems, pulling administrative data from different databases that tend to be updated more frequently (Gentilini et al. 2021). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 7 INTRODUCTION evolution from static social registries—rudimentarily coupled with a few BOMS, if at all—to dSR and interoperable systems is presently underway. DSPDS brings new capabilities as well as new risks and responsibilities with profound implications for the relationship of trust between governments and people. The introduction of new technologies in the delivery of social protection programs offers opportunities for efficiency and effectiveness but also poses challenges and risks that require careful management.41 Governments provide a myriad of social protection programs, such as cash transfers, subsidies, childcare, training, or labor services, for which delivery is usually fragmented and unarticulated. The simplification and optimization of siloed processes through innovations in delivery systems put people and families at the center; diffuse complexity; improve inclusion, reach, and coverage; and contribute to the efficiency and transparency of governments. These benefits, in turn, help to streamline and automate complex eligibility determination processes, facilitate regular feedback on the provision of services to improve their quality, and ultimately contribute to building a relationship of trust between the state and its people. Nonetheless, the introduction of new technologies without addressing risks—of data security and privacy, surveillance, exclusionary effects, or discrimination, among others—can compromise even hard-won gains. Disproportionate or illegitimate so-called “data grabs” must be safeguarded against, while the intent, objectivity, and neutrality of the agencies housing such systems as “honest brokers” or “trusted intermediaries” should be considered when assessing the institutional and normative architecture that supports them (Daly et al. forthcoming). Data are the throughput of DSPDS; they are collected from multiple sources, curated, and analyzed to make policy decisions through a systematic, whole-of-government approach. DSPDS consume many types of data from many different sources and process them by applying various techniques to generate actionable policy insights. The most commonly used data by DSPDS include unique identifiers, self-reported socioeconomic information, beneficiary registries, administrative records, and spatial data.42 How those data are collected, generated, integrated, or made interoperable can vary and have important implications for the optimal delivery of social protection programs. Keeping data within DSPDS up-to-date and accurate presents major operational and technical challenges and, to a large extent, determines the quality of analytical outputs used for social protection policy making and associated expenditures. There are also important legal and moral obligations of which to be aware as discussed later. 3. SCOPE Like other ISPA tools, the Playbook on Digital Social Protection Delivery Systems is composed of a Guidance Note and an Assessment Tool designed for social protection policy makers and practitioners working in low- and middle-income countries. The Guidance Note provides a conceptual framework along five pillars: data, delivery chain, technology, governance, and performance, together with a tailored glossary and key definitions. One key characteristic of the Guidance Note is that it is not compartmentalized into stand-alone service platforms but instead presents a holistic approach that looks at how stand-alone platforms interact and complement each other within DSPDS. The Guidance Note acts as a forward-looking framework to help to guide the future state— 41. Although none doubt that technology significantly impacts development, discussions on dynamic social registries, identification, and payment systems tend to swing from one extreme to another. Portrayals range from dystopian depictions where technologies further disadvantage the disadvantaged and punish the poor, to overly optimistic—and often simplistic—utopias where technology results in inclusion and presents infinite possibilities. As countries catch up, few have robust safeguards in place. Data protection and data governance play a vital role in growing capacity, accountability, and trust. Daly et al. (forthcoming) provide concrete pointers on how social protection actors might integrate those principles into the delivery of social protection programs. 42. See section 5.2 of Johnson and Walker (2022) for a discussion on types of data used for adaptive social protection. 8 Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability the “to be.” Reaching this state requires a series of multiple efforts, sometimes small, that add up to long-term progress. On the other hand, The Assessment Tool provides a systematic way to gather information and assess the strengths and weaknesses of the current state of social protection systems—the “as is”—with an emphasis on dynamic inclusion and interoperability. The conceptual framework in the Guidance Note and the Assessment Tool are not meant to be interpreted as exhaustive in and of themselves. The Playbook is not intended to be prescriptive or restrictive, but rather to have sufficient flexibility to adapt and shape to fit different country contexts. Also, the scope of the Playbook is mostly focused on non-contributory programs. As countries transition toward universal social protection, it is crucial to prioritize support to the poorest and vulnerable, with social assistance playing a central role. However, it is worth noting that information systems used in contributory schemes are essential components of DSPDS and a key data source for dSR. Moreover, many core tenets of this report can be extrapolated to contributory schemes. Different sections of the Playbook are meant to be used by multiple audiences. Parts 1, 2, 3, 5, and 6 of the Guidance Note are mostly geared toward practitioners and technical staff within social protection agencies, while part 4 is tailored toward technology experts. The Playbook serves as a resource for anyone interested in learning about DSPDS, functioning as both a knowledge global product and a tool to assess a country’s progress in the design and implementation of DSPDS. When assessing DSPDS and its components through the Assessment Tool, the first step is to take stock of the existing systems. The information collected forms the basis for a country report that overviews the existing structures, processes, rules, technology, and performance metrics, and identifies gaps and areas for possible improvement.43 The data collection framework has been designed to collect the information needed to carry out an assessment of DSPDS and its components. It consists of two steps employing a combination of qualitative and quantitative techniques. The first step helps embed the analysis of DSPDS within the broader context of the country and its social protection landscape, while the second step helps assess the current status of DSPDS using four ranking criteria—absent, nascent, emerging, and advanced. The absent level refers to the absence of any effort or progress in the area being assessed, while the advanced level represents a benchmark aligned with the Playbook’s Guidance Note. The levels in between seek to record signs of progress toward building effective and efficient DSPDS. In line with ISPA frameworks, social protection is defined as “the set of policies and programs aimed at preventing or protecting all people against poverty, vulnerability, and social exclusion throughout their life cycles, placing a particular emphasis on vulnerable groups.”44 Social protection can be provided in cash or in-kind, providing universal, categorical, or poverty-targeted benefits such as social assistance, contributory schemes such as social insurance, and by building human capital, productive assets, and access to jobs.45 While the Guidance Note sets up the framework of the broader DSPDS, certain elements receive greater attention and constitute the focus of the Assessment Tool, notably, dynamic inclusion and interoperability. When implemented as standalone systems, social registries support the process of the intake and registration of information on people and enable information processing to assess their needs and conditions. The Playbook does not dive deep into other key components, such as identification and payments platforms. Those are covered under separate ISPA tools. Also, the Playbook does not cover in depth the methodology for welfare assessments, including using machine learning and newer geospatial, mobile, and other big data sources, 43. Please note that the overview of findings is context-specific and thus does not allow for comparison across countries. 44. Social Protection Interagency Coordination Board (SPIAC-B). https://socialprotection.org/connect/stakeholders/social-protection-inter-agency-cooperation- board-spiac-b#:~:text=What%20is%20Social%20Protection%20for,particular%20emphasis%20on%20vulnerable%20groups. 45. Social protection programs can be broadly categorized into three groups: social assistance, social insurance, and labor. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 9 INTRODUCTION which could be covered in future works. Where possible, the Core Diagnostic Instrument (CODI), Identification, and Payments ISPA tools may be used in concert with the Playbook to construct a more comprehensive assessment. The Playbook is anchored in recent work on delivery systems, the targeting of social assistance, adaptive social protection, data governance, and existing ISPA tools. The Sourcebook on the Foundations of Social Protection Delivery Systems46 formalizes the delivery systems framework through the social protection delivery chain, thus motivating the most relevant business processes of Digital Social Protection Delivery Systems (DSPDS). Likewise, the recent publication on Revisiting Targeting in Social Assistance47 captures current thinking on why and how to target social assistance programs, providing an overview of the targeting methods that make use of DSPDS data. The Playbook builds upon many concepts from On-Demand and Up-to-Date? Dynamic Inclusion and Data Updating for Social Assistance48 and Good Practices for Ensuring Data Protection and Privacy in Social Protection Systems.49 It draws from Adaptive Social Protection: Building Resilience to Shocks,50 which provides a conceptual framework for making social protection systems adaptive and shock-responsive and is in line with one of the strategic priorities highlighted in Charting a Course Toward Universal Social Protection51 regarding the leveraging of whole- of-government delivery systems, including unique identification systems, social registries, payment platforms, and others. Finally, the Playbook complements existing ISPA tools, including The Core Diagnostic Instrument (CODI), Identification Systems for Social Protection, and Social Protection Payment Delivery Mechanisms,52 as well as the process of setting interoperability standards undertaken by the Digital Convergence Initiative (DCI).53 Against the backdrop of this rich body of analytical work, the Playbook provides an in-depth perspective of the information systems that underpin the delivery of social protection with a focus on the data, processes, technologies, and governance involved in the design of such systems. 46. Also referred to as the Sourcebook, see Lindert et al. (2020). 47. Grosh et al. (2022). 48. Barca and Hebbar (2020). 49. Wagner, Ferro, and Stein-Kaempfe (2022). 50. Bowen et al. (2020). 51. World Bank (2022a). 52. See: https://socialprotection.org/connect/stakeholders/ispa-inter-agency-social-protection-assessments/publications. 53. See: https://spdci.org/standards/vision/. 10 Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability II. Conceptual Framework Part 1 ASSESSMENT Core Characteristics The DSPDS conceptual framework builds upon the three fundamental levels of social protection—that is, the policies, programs, and delivery systems. Expanding on these three foundational elements, the Playbook delves into the data, delivery chain processes, technologies, governance, and performance of DSPDS as shown in Figure 3 (each facet will be addressed in the following sections). An overview of the three fundamental levels of social protection is presented below together with an ontology for DSPDS. A. LEVELS OF SOCIAL PROTECTION (i) Social protection policy National policies have been adopted by an increasing number of governments to set the strategic medium- and long-term goals of social protection programs. These national policies typically present an overarching vision and establish the foundations needed to operate social protection programs. For instance, since the early 2010s an increasing number of African countries have adopted such national social protection policies (UNDP 2019), strengthening and articulating existing social protection programs or launching new ones. As detailed in the Core Diagnostic Instrument (CODI) tool (ISPA 2014), the basic features of such policies include the legal framework, strategy, and national objectives, as well as the institutional arrangements and financing. Ideally, national social protection policies define key policy objectives that are aligned with the social protection needs of the population, such as poverty or vulnerability reduction, reducing inequality, human capital formation, or economic inclusion, as well as the targets and metrics necessary to achieve and monitor them. These frameworks also provide intermediary outcomes of improved efficiency, effectiveness, accountability, and transparency that directly affect the type of delivery systems they design and implement. As such, national social protection policies provide the Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 11 CONCEPTUAL FRAMEWORK FIGURE 3 Core characteristics of DSPDS Social policy Programs Delivery systems DATA DELIVERY CHAIN TECHNOLOGY GOVERNANCE PERFORMANCE Data Assess Architecture Strategic Results chain Processing Enroll Applications Administrative DSPDS metrics Provide Database Operational SP system performance Manage Data exchange and interoperability Infrastructure SOURCE: Original for this publication. underlying policy framework to guarantee a social protection floor enabled by social protection programs and their associated delivery systems, including DSPDS. Digital social protection delivery systems cannot operate in a policy vacuum: these information systems are a means to an end, not the end itself. Delivery systems—so-called little “s” which address the how-to’s—are merely an operating environment so programs can reach the objectives mandated by social protection policies based on a social protection diagnostic that identifies the needs of the population, the benefits and services currently provided, and the resulting gaps. It can be tempting for governments, agencies, or other stakeholders to create highly sophisticated delivery systems that leverage the latest technologies available, believing that a more powerful “machinery” for social protection delivery is an end unto itself. Nonetheless, delivery systems need to be firmly anchored within a social protection policy framework—so-called “big S”—that informs their design and provides the necessary guardrails to ensure they are effectively used for their intended purposes. This consideration is of 12 “WHAT MATTERS” GUIDANCE NOTE relevance for DSPDS due to the sensitive nature and significant volume of the personal data they consolidate from a plethora of interoperable information systems. Social protection policy frameworks underpin the legal and institutional architecture of social protection programs and their enabling delivery systems, as shown in Figure 4. Based on an appropriate social protection diagnostic, the strategic objectives defined at the policy level inform the interventions and eligibility criteria of social protection programs. In turn, the eligibility criteria defined by social protection programs determine the key indicators to be consolidated by dynamic social registries (such as poverty, vulnerability, food insecurity, demographic attributes, or others) in order to assess eligibility. The data requirements to prioritize social protection programs have profound implications for the data generation processes at the delivery systems level. Under a whole-of-government social protection framework, dynamic inclusion and interoperability are powerful tools to reduce fragmentation and improve coordination across programs. However, when each program has different definitions for key indicators relevant to assessing needs and conditions, such as different measurements of poverty or vulnerability, redundancy of benefits is likely as well as challenges in measuring the impacts of social protection policy. National social protection policies and their legal frameworks typically define these key indicators, which form the basis for the prioritization of social protection benefits. (ii) Programs Catching the vulnerable before they fall into poverty, while also protecting the poor by investing in their human capital, generating resilience to cope with shocks, improving productivity, and facilitating access to jobs requires a harmonized systems-oriented approach for social protection programs (World Bank 2012). Moving toward inclusive social protection systems is critical to ensure that the poorest of the poor have access to social protection programs, such as safety nets. Managing life cycle risks and building resilience against covariate shocks is important for all members of society. While those with contributory capacity will be able to use social insurance schemes, poor and vulnerable populations will need to rely on tax-financed benefits. Shock-responsiveness is therefore a key attribute of social protection systems, particularly adaptive ones, so they can effectively respond to crises in a timely manner and increase resilience among the hardest hit. Finally, while guaranteeing basic consumption levels for the poor and vulnerable, social protection programs should also enhance the productivity of workers by generating human capital, developing relevant skills, and creating linkages to profitable markets, among other things. Social assistance, social insurance, and labor market programs are the three main pillars of social protection programs. Social assistance programs—also broadly known as “safety nets”—can provide conditional or unconditional cash transfers, food and in-kind transfers or social pensions, among others. These programs are meant to guarantee a minimum level of consumption and are usually targeted toward the poorest and most vulnerable households and individuals such as older persons, pregnant women and young mothers, children, or people with disabilities. Social insurance programs consist of contributory pensions schemes for old age, survivors, or disabilities as well as subsidized health insurance and other benefits. These programs may or may not be targeted toward the poorest households, but they are usually tied to the formal labor market, particularly contributory pensions. Finally, labor market programs include vocational trainings, employment intermediation, or unemployment benefits, among others. These programs aim to reduce entry barriers into the labor markets so that the human capital investments of social assistance and insurance can be leveraged productively. The allocation of resources devoted to these three broad types of social protection programs varies depending on country context and the priorities of each administration. However, the articulated design and delivery of social protection programs is crucial to avoid fragmentation and redundancies that reduce their cost-effectiveness. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 13 CONCEPTUAL FRAMEWORK Key design choices for social protection programs include eligibility criteria, type of intervention, benefit levels and structure, duration, and exit criteria. The design choices of social protection programs are usually based on the objectives established in the social protection policies as well as the resources allocated to such programs. While specific program design choices are beyond the Playbook’s scope, they are nonetheless critical inputs to ensure that delivery systems—and their underlying information systems—appropriately respond to the needs of the programs. For instance, there is a key linkage between the policy objectives (for instance, guaranteeing a minimum consumption floor), program eligibility criteria (for example, consumption threshold), and data requirements for dynamic social registries (for example, consumption proxies) that supports the assess phase of the delivery chain as a component part of the DSPDS (Figure 4). FIGURE 4 Social protection policies, programs, and delivery systems SOCIAL PROTECTION DIAGNOSTIC What are the main binding constraints hindering development? How are poverty and vulnerability defined and measured? POLICY SOCIAL PROTECTION NATIONAL POLICY What are the strategic objectives? E.g., establishing a consumption floor, human capital formation, labor market insertion, resilience to shocks INFORMS SOCIAL PROTECTION LEGAL AND INSTITUTIONAL ARCHITECTURE Functional allocation: who does what to achieve the strategic policy objectives? ESTABLISHES MANDATES PROGRAM A (Productive Cash Transfers) PROGRAM B (Universal Healthcare) PROGRAM C (Scholarships) PROGRAMS Objective minimum consumption floor Objective improve health outcomes Objective educational attainment Intervention Intervention Intervention monetary transfer + trainings provision of subsidized health care services scholarships Eligibility criteria Eligibility criteria Eligibility criteria consumption threshold + rural informal workers students Prioritization data requirements Prioritization data requirements Prioritization data requirements consumption proxies + location employment status school assistance + age DELIVER fID dynamic Social Registry BOMS Payments IBR GRM DELIVERY ASSESS ENROLL PROVIDE MANAGE SYSTEMS DIGITAL SOCIAL PROTECTION DELIVERY SYSTEMS SOURCE: Original for this publication. 14 “WHAT MATTERS” GUIDANCE NOTE (iii) Delivery systems DSPDS are the information systems that support social protection delivery systems. Delivery systems constitute the operating environment for implementing benefits and services, enabling social protection systems that seek to build equity, opportunity, and resilience for people. Most countries provide support through a wide range of benefits and services that redistribute income to reduce poverty and inequality, support investments in human capital, and help to ensure against shocks and various risks, including loss of earnings from old age, economic crisis, natural disaster, climate change, conflict, or forced displacement. Fragmentation of social protection programs often results in the proliferation of siloed information systems for each program. This fragmentation creates inefficiencies and poses an administrative burden for the end-users of these systems, including applicants, beneficiaries, administrators, and caseworkers, as well as the policy makers who work on finance and planning. Fragmentation implies a duplication of functions and in investments in software applications, databases, and other technology infrastructure across and within government agencies. When each program conducts intake and registration separately, users must provide the same type of information repeatedly to apply to more than one program. Likewise, when each program develops its own payment provision system, this results in fragmented and uncoordinated methods of payment delivery to beneficiaries. Similarly, separate case management of programs impedes effective intermediation and referrals for service provision as caseworkers lack information on available services and what other programs the beneficiary is receiving concurrently or for which they might be eligible. Consolidating delivery functions across multiple programs reduces fragmentation, improves coordination, and promotes harmonization across social protection programs and beyond, generating much-needed fiscal efficiencies. A seamless flow of information from the moment people express interest in or have the need for a program until the moment they receive a benefit or service is realized through the interoperability or integration of systems to support the various functions and processes along the delivery chain. This structured information flow means that household needs are met in a timely manner and can make benefits more accessible. Foundational technology platforms support a whole-of-government framework for social protection and beyond. DSPDS draws on these various platforms, particularly on foundational identification systems since a universal and unique identifier enables interoperability, articulating data sets from multiple sources while also reducing the information burden on individuals. A systematic, process-oriented approach has been slow to take root in many countries, particularly those grappling with poverty and vulnerability. The applications and models used for managing and administering social programs tend to be limited in scope, fragmented, or nonexistent. Social protection agencies that prioritize interventions to poor and vulnerable households collect socioeconomic data, most commonly through enumerators, captured either via paper or portable electronic devices, storing and managing them as “lists.” Databases collected through time-bound and infrequent census-survey sweep approaches are stored on local drives in various formats, such as csv, txt, xlsx, sas, dta, rdata, or others. Those data are then imported and loaded onto desktop programming platforms such as Excel, Matlab, Python, R, Eviews, Stata, SAS, or other to analyze them, develop algorithms, and create statistical, mathematical, and econometric models to characterize poor or vulnerable individuals, families, and households. In recent times, data from other administrative systems or big data sources such as call detail records (CDR) from telecom operators or remote sensing data have also lent themselves to being read and analyzed through such software applications. Software applications that automate key functions and processes (such as cross-checks, validation, and verification, administration of Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 15 CONCEPTUAL FRAMEWORK payments, beneficiary operations management, or even grievance redress) still require semi-manual or manual operation. In resource- and capacity-constrained contexts, building systems by pulling together databases in the form of a spreadsheet or even a small-scale database management system may well have been a worthy short-term approach in the pre-pandemic era. However, as countries prepare to build adaptive and shock- responsive systems over the medium-to-long term, a process-oriented approach to building data pipelines for intake, registration, assessment, provision, and monitoring of benefits is preferable, as it allows for a more systematic and technology architecture-based approach. Building DSPDS calls for an open and interoperable systems architecture and data “pipelines” to produce actionable analytical insights. A delivery chain mapping approach to building interoperable systems assures that social programs’ processes are streamlined end-to-end and high-quality data can be generated, stored, managed, and analyzed. This approach involves developing comprehensive process maps of the delivery chain, with clarity on roles and accountabilities of various actors and institutions—that is, who does what and when. The approach also includes conceptualizing a dynamic and interoperable systems architecture with a human-centered design focus that is implemented hand-in-hand with legislative, governance, and public administration reforms. The policy agenda when building fully-fledged information systems for social protection programs is then not limited to that of incrementalism, but that of learning from the experiences of other countries and leapfrogging. Clever technology options should be utilized where appropriate, especially where countries have the capacity and the ability to quickly develop “good-enough” business processes and systems designs (Box 1). Governments develop interoperable systems as part of their overall BOX 1 agenda to build trust with people through their day-to-day interactions and delivery of benefits and services to them. Examples of countries that scaled beyond social registries and beneficiary operations management systems to create interoperable or integrated systems include Chile and Türkiye. Chile’s Sistema Integrado de Información Social (SIIS) combines a social registry (Registro Social de Hogares, RSH-Chile), an integrated beneficiary registry (Registro Integrado de Beneficiarios, RIB), an integrated inventory of social programs (Banco Integrado de Programas Sociales, BIPS), and a geographic information system. The RSH serves as a gateway for determining potential eligibility for 114 programs from numerous agencies, while the RIB links information on beneficiaries across these programs. The BIPS serves as a planning tool to monitor current and planned social benefits, services, and infrastructure across the country. At the same time, the geographic information system is exploited to geo-reference individuals and households in the RSH and RIB and social programs in the BIPS. It can also link to other territorial information to support disaster response and management. The overall SIIS and its components link to 28 administrative systems with interoperability capabilities for data exchange, which facilitates efficiency, authentication, information quality, and accuracy. On the other hand, Türkiye’s Bütünleşik (Integrated Social Assistance Information System, ISAS) combines a social registry, a payments platform, and a grievance redressal platform to serve over 50 social protection programs in the country. In response to the COVID-19 emergency, Türkiye’s ISAS allowed the country to quickly deploy a social support program consisting of a one-time cash benefit for individuals in eligible occupations following a back-end process to determine eligibility using administrative data. 16 “WHAT MATTERS” GUIDANCE NOTE DSPDS can act as powerful analytical tools for social protection policy makers, helping governments respond to people’s needs, particularly in times of crisis (Silva Villalobos et al. 2015). Social registries can serve as a measure of the “demand” for social programs, particularly when they allow for dynamic intake and registration, as in the case of Chile’s RSH. Integrated beneficiary registries can serve as a measure of the “supply” of social programs, as is the case for Chile’s RIB. By putting these together, they allow for sophisticated and rich policy insights including (a) assessing the specific needs and conditions of various population groups (demand-side analysis via the social registry); (b) coordination of the “supply” across programs, including detecting of intended or unintended overlaps (via the integrated beneficiary registry); (c) analysis of potential “gaps” in coverage of key bundles of benefits and services that could be tailored to the specific needs of poor and vulnerable groups (combining the demand- and supply-side analytics of the social registry and integrated beneficiary registry)—this gap analysis could allow for simulations of fiscal resources needed to extend key benefits and services to underserved groups, with clear identification of the potential additional beneficiaries that could be added; and (d) estimation of exclusion and inclusion errors so that social protection programs can tangibly address them and the redistributive impact of the allocated fiscal resources is maximized (see Part 6—Performance). A whole-of-government DSPDS architecture relies on data integration and interoperability frameworks to facilitate data exchange from other administrative information systems, as well as the front-offices and intermediators who can work directly with people. For instance, social registries can be linked to administrative systems such as unique identification, civil registration, land or property cadasters, vehicle registration, tax, social insurance contributions, pensions payments, labor and unemployment, or education and health, to create assessment profiles of individuals, families, and households, underpinned by a network of front-office interfaces close to people. Practically and technically, there must be a commitment to share data responsibly, endorsed by political decisions and having a legal basis. Participating organizations should have commonly held views and objectives. Legally, they must comply with safeguards and laws governing information such as personal data protection, digital signatures, cybersecurity, access to information, and strategic procurement of systems that are not vendor locked in. Semantically, the framework must be based on a shared understanding among different organizations of the meaning of the data being exchanged. This entails building common standards, data dictionaries (with standard definitions of variables, reference units, and time reference periods), metadata, thesaurus, taxonomies, ontologies, and service registers. Technically, the framework complies with service-oriented information technology (IT) architecture standards, and interoperability requires that some sort of unique identifier can be referenced by information systems such that data on individuals can be matched up when appropriate, consented, and authorized. Given the complexity of social protection programs involving large flows of data and transactions, data protection and privacy are paramount. Social protection agencies must devote specific attention and resources to ensure that their IT systems and data repositories are properly governed and secure, and that they support social protection programs in achieving their core mandates. The data gathered and used in DSPDS can be highly sensitive, including personally identifiable information (PII) or personal data,54 sensitive personal data, socioeconomic information, information on employment or unemployment, information on disability status, and highly confidential information on various social risks to the individual and family, among others. While DSPDS require that certain data be shared proportionally and legitimately across actors, data protection safeguards must be in place to ensure that the confidentiality, integrity, and availability of data—and especially of personal data—and systems is ensured. 54. Similar and related terms, “personal information” is any information relating directly or indirectly to a (natural) person, while “personally identifiable information” (or PII), a narrower range, is any information that can be used to identify a person. The Playbook generally uses the term personal data. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 17 CONCEPTUAL FRAMEWORK B. ONTOLOGY OF DSPDS This section proposes an ontology of common component systems of DSPDS to bring clarity and specificity to frequently used terms. When referring to information systems, these are understood as interdependent groups of elements—including data, software, and hardware—that function together to accomplish some predefined goal by collecting, storing, processing, creating, and distributing information. Information systems comprise the largest super-set in this ontology.55 Data sourced into information systems are housed in both relational and non- relational database management software (RDBMS or NoSQL) designed to define, manipulate, retrieve, manage, and store data. Notably, as different technologies exist, the architecture of such software often varies across, even and within, countries, often leading to data fragmentation and incompatibility if unintegrated and not designed from the onset to be interoperable. DSPDS refers to a set of social protection information systems capable—by design—of efficiently communicating and exchanging data with each other, and across other systems, facilitating social protection policy decision- making, program delivery, and monitoring and evaluation. Governments across the world are increasingly relying on dynamic and interoperable systems for social protection delivery to serve multiple programs that support people and institutions along the delivery chain rather than building standalone, program-specific information systems. The architecture and supporting infrastructure of DSPDS seek to consolidate social protection delivery processes through comprehensive data pipelines to achieve greater functionality, produce richer analytical outputs, and optimize costs. DSPDS help governments to render a more holistic and comprehensive view of who needs social protection and who receives what. Just as different gears in an engine must mesh to transfer power and make the engine work, different DSPDS component systems must work together seamlessly to ensure data flows are smooth, reliable, and secure (Figure 5). In this case, the different “gears” in the engine represent various DSPDS information systems, which can be complemented with other systems beyond DSPDS (represented by the gray boxes at the bottom of the figure). Each of these component systems is unique and has its own specific functions, but when they are made interoperable they become greater than the sum of their parts, delivering social protection benefits and services more effectively and efficiently to individuals and households. Core components of DSPDS include dynamic social registries (dSR), beneficiary operations management systems (BOMS), multi-program-multi-provider payments, integrated beneficiary registries (IBR), and unique identification systems, all designed to be interoperable with each other from conception.56, 57, 58 However, there is no single blueprint for determining which specific component systems are needed in a given context. Other information systems can also be made interoperable to improve the efficiency and effectiveness of social protection delivery, such as program inventories,59 data analytics,60 data exchange platforms,61 case management systems, grievance redress mechanisms (GRM) also known as complaints and appeals information systems,62 and 55. See Annex 4: Glossary for a cheat sheet on information systems terminology used in this Playbook. 56. See Turkiye’s Bütünleşik https://www.aile.gov.tr/btgmd/duyurular/butunlesik-sistemi-erisim/. 57. See India’s Aadhaar https://uidai.gov.in/en/; Direct Benefits Transfer https://dbtbharat.gov.in/; and Unified Payments Interface https://www.npci.org.in/what- we-do/upi/product-overview. 58. See Brazil’s social registry Cadastro Único https://www.gov.br/mds/pt-br/acoes-e-programas/cadastro-unico. 59. See United Kingdom’s simplified menu of benefit and services programs http://gov.uk. 60. See Korea’s social security information system “haengbok-e-eum” https://www.ssis.or.kr/eng/lay1/S6T37C38/contents.do. 61. See Estonia’s X-Road for data exchange https://e-estonia.com/solutions/interoperability-services/x-road/. 62. See Indonesia’s Lapor! For grievance redress https://www.lapor.go.id/. 18 “WHAT MATTERS” GUIDANCE NOTE FIGURE 5 DSPDS: common component systems and their functions Beneficiary data management and grievance redress DSPDS BENEFICIARY OPERATIONS MANAGEMENT Enrollment decisions and determination of benefit levels DIGITAL SOCIAL SYSTEMS Cash Transfers and/or service package PROTECTION Payments administration and reconciliation DELIVERY Education Health Compliance with conditionalities or accompanying measures SYSTEMS Humanitarian Program’s performance measurement and monitoring Disability CIVIL Social Dynamically intake data on the benefits Intake REGISTRATION Insurance delivered to individuals and households Unique gateway biographic and AND VITAL to apply to one or STATISTICS Assess coverage of social protection programs biometric data PROGRAM more programs of individuals Establish a INVENTORIES on-demand person’s Identify complementary or redundant benefit Determine the existence and allocations Dynamic data unicity of record vital intake from individuals and events INTEGRATED multiple sources Enable governments to make authenticate CRVS BENEFICIARY REGISTRY payments to people and them viceversa Continuous data updates through UNIQUE interoperability IDENTIFICATION Interoperate with other and self-updating MULTI-PROGRAM systems to ensure third GEOGRAPHIC MULTI-PROVIDER parties' acceptance of digital functionalities INFORMATION PAYMENTS transactions SYSTEM Assess the needs GIS and conditions of Payments provision and applicants reconciliation DATA Reach people in ANALYTICS GRIEVANCE REDRESS need of support DATA MECHANISM SYSTEM and quickly scale EXCHANGE up social assistance for DYNAMIC SOCIAL CASE REGISTRY MANAGEMENT shock-response CM INFORMATION GRM SYSTEM DATA PROTECTION AND PRIVACY LAYER ASSESS ENROLL PROVIDE MANAGE Land / Property Financial / Banking Telecommunications Education Health Road Density DATA Utilities Vehicles Taxes Farmer’s Registry Satellite Imagery Disaster Risk EXCHANGE CONCEPTUAL FRAMEWORK geographic information systems (GIS).63 The core functionalities of such information systems and the mandates of the institutions housing them are to be considered when designing DSPDS. Ideally, DSPDS components are conceived and operated as cohesive and dynamic systems, with feedback loops based on a microservice architecture comprising multiple modules focusing on different processes or functions. When describing DSPDS, it is essential to differentiate between “integration” and “interoperability” as they are often conflated. Integration is the process of linking independently designed applications to work together as one system so that the data contained in each becomes part of a larger, more comprehensive system. Integration also enables access to data and functionality from such independent applications through a single interface or service. Interoperability, by contrast, is the ability of systems to interact and communicate with each other by exchanging data using common syntactic and semantic data standards but to do so without losing their individuality. That said, in practice, integration and interoperability lie along a spectrum and can impact different aspects of information systems, such as data, processes, applications, and others. The appropriate degree of interoperability and integration depends on the specific needs, assets, and objectives of a particular DSPDS implementation. The following subsections intend to help disentangle the full range of functionalities of common system components DSPDS by providing an overview of the most common information systems used by social protection programs. (i) Dynamic social registries (dSR) As outlined by the Sourcebook, social registries support the “Assess” stage of the delivery chain, including the phases of outreach, intake and registration, and assessment of needs and conditions. Latin American countries were among early pioneers using social registries64 to assess vulnerability and poverty to support decisions on enrollment of intended populations in social programs. Social registries help to prioritize service delivery to the poor by stemming leakages and minimizing inclusion and exclusion errors to maximize the redistributive impact of social benefits in reducing poverty and allocating equitable budgets. Over the past 20 years, social registries have shown considerable diversity in their trajectories: from static survey sweeps for data collection to dynamic data intake; and from supporting one social program toward supporting multiple programs, even interventions that tend to be universal in nature, such as subsidized health insurance,65 thus improving coordination of programs and creating savings (Leite et al. 2017). A recent stock-take of 38 countries shows an increasing trend toward dynamic data collection through on-demand registration to programs, sometimes in combination of administrator-driven approaches and/or interoperability capabilities, while some countries still rely on purely administrator-driven census sweeps for data collection (Figure 6). When social registries are dynamic, they become more inclusive and better able to rapidly respond to the needs of households, families, and individuals across their lifecycle, particularly during crises. The principle of dynamic inclusion is aligned with the progressive realization of universal social protection, whereby anyone in need can access programs due to them at any time. In practice, it means that registration for social protection 63. See Chile Solidario on use of geospatial systems with social registries for shock response https://www.ips.gob.cl/fichas/chile-solidario. 64. While Brazil’s Bolsa Familia program and social registry, Cadastro Unico, is well-known trailblazer, Chile’s Registro Social de Hogares (RSH-Chile) or household social registry started as a census sweep in the early 1980s, with periodic national waves of registration and updates. RSH-Chile is now dynamic, with on-demand registration and updates via municipal offices and a citizen online platform for applications and updates since 2010. Colombia’s SISBEN was first launched in 1995 and, to date, it has had four rounds of data collection via the survey sweep approach in geographically targeted areas. In 2023, Colombia’s Household Social Registry (RSH-Colombia) was launched and introduced data exchange functionalities coupled with self-reported questionnaires for dynamic inclusion. 65. Analysis by Leite et al. (2017) of social registries in 20 countries (Azerbaijan, Brazil, Chile, China, Colombia, the Dominican Republic, Djibouti, Georgia, Indonesia, Macedonia, Mali, Mauritius, Mexico, Montenegro, Pakistan, the Philippines, Senegal, Sierra Leone, Türkiye, and Yemen) reveals considerable diversity in the typologies and trajectories of these systems with respect to their (a) institutional arrangements (central and local); (b) use as inclusion systems (coverage, single or multi- program use, static or dynamic intake and registration); and (c) structure as information systems (structure of data management; degree and use of interoperability with other systems). 20 “WHAT MATTERS” GUIDANCE NOTE Pakistan NSER FIGURE 6 Dominican Republic SIUBEN Phillipines Listahanan Coverage and Chile RSH Colombia SISBEN data collection Turkey ISAS methods for Mexico SIFODE Brazil Cadastro Unio social registries Indonesia UDB around the Georgia TSA registry Montenegro SWIS world Senegal RNU Yemen Rep. SWF registry Djibuti RSU North Macedonia CBMIS China RPHR Mauritius SRM Azerbajan VEMTAS Sierra Leone SPRINT Mali RSU 0 10 20 30 40 50 60 70 80 90 100 Coverage (% total population) Primarily on-demand Administrator-driven systems Use both registration systems SOURCE: World Bank’s Social Protection Delivery Systems Global Solutions Group “Global Social Registry Database.” Data as of June 2023. programs is open and continuous for all households, families, and individuals, allowing them to register when needed and update their information as it changes. Dynamic social registries (dSR) have five core characteristics. First, they provide a unique gateway for households, families, and individuals to apply to one or more programs on an on-demand basis (although this does not guarantee that support will be granted if the applicant is not eligible). Second, they intake data dynamically from multiple sources to validate and verify self-reported information, facilitated by an interoperability framework with data security and privacy protocols based on legal provisions and people’s consent. Third, they ensure that the data of already-registered households and individuals is kept up to date on a continuous basis. Fourth, they can intake new registrants that might have fallen into poverty or might have become newly eligible during crises to quickly scale up shock-responsive programs. Fifth, they allow administrators to dynamically assess applicants’ needs and conditions to determine potential eligibility based on program-specific criteria. Despite the advantages of dSR, many developing countries still operate with static social registries, typically fed through sporadic en masse registration waves that are difficult to sustain, leading to eventually outdated or missing information (Leite et al. 2017). Without a system for dynamic inclusion, the risks for both inclusion and exclusion errors increase over time, and the ability to implement adaptive and shock- responsive systems decreases. As the dynamism of social registries—captured by these five core characteristics—is still considered to be aspirational (since most social registries lie closer to the static end of a static-to-dynamic continuum), the Playbook highlights dynamic social registries as “dSR.” dSR contain biographic, socioeconomic, and occasionally additional specialized data to support programs in determining eligibility and making enrollment decisions.66 The interface between people and dSR usually requires a permanent point of contact for on-demand applications, be it in-person or remotely. The coverage of social 66. In some instances, the data from social registries are supplemented with program-specific information and assessments. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 21 CONCEPTUAL FRAMEWORK registries varies across countries, with some operating on a near-universal range (like Egypt, Colombia, Argentina, Chile, Lesotho, Costa Rica, Mongolia, and Türkiye with over 70 percent of the total population covered) and others on a relatively medium scale (like the Dominican Republic, Malawi, Saudi Arabia, Indonesia, Tajikistan, Jordan, Djibouti, Brazil, and Ecuador with 40 to 55 percent of the total population covered) (Figure 6). dSR consolidate data from people through direct intake modalities, such as digital service windows, community service centers or local offices, mobile teams, and field surveys, whereby people self-report their information to the dSR. Data may also be pulled through indirect intake modalities—with people’s informed consent—from government administrative systems or non-traditional data sources, through interoperability mechanisms (Figure 7). dSR that support numerous programs generate efficiencies for program administrators and for people. dSR allow efficiency gains for program administrators who do not have to collect the same information from the same people repeatedly, and for individuals and households who do not have to provide the same information to multiple programs separately thus reducing their information burden. During intake and registration, by providing their data through the dSR’s front office, people can apply to one or many programs, check their application status, and update their information on an ongoing basis. At the back office, administrators can validate and verify FIGURE 7 Dynamic social registry (dSR) PLATFORM LAYERS Lorem ipsum LAYER 1 LAYER 2 LAYER 3 FRONT OFFICE BACK OFFICE BACK OFFICE APPLICATIONS APPLICATIONS APPLICATIONS (PEOPLE) (ADMINISTRATION) (DATABASES) PEOPLE DIRECT INTAKE SELF-SERVICE CHEC KS Digital service window TA MS TU RA S OG O PR FA TO PP Community service center View and LIC LY manage Update applicant APP data ATI data ON Exchange data: Mobile teams, Push to DATA Assess facilitators & agents beneficiary needs and systems/ conditions pull from other systems DATA ASSISTED UPD Manage Outreach Home visits, census sweeps and notify TA access INDIRECT INTAKE applicants AT controls DA E FY IN O RI RM F AT VE ND Admin data sources IO A N TE VA L I DA Non-traditional data sources SOURCE: Original for this publication. 22 “WHAT MATTERS” GUIDANCE NOTE applicants’ data, as well as update and rectify them based on information gathered by programs. An applicant’s data can also be supplemented by other systems, including program-specific BOMS, administrative records, and non-traditional data sources. dSR supports the assessment of needs and conditions by determining potential eligibility to user programs based on defined criteria. While social registries have a strong social policy orientation, they are increasingly supporting interventions beyond social protection. From Guinea to Chile, Türkiye, Pakistan, and Indonesia, social registries help to connect people to a range of public services—including social protection, health, and education—thereby expanding coverage and prioritizing the poorest people (Georgieva 2018). However, governments are further expanding their use to other sectors. Social registries have become crucial for countries implementing a whole-of-government approach as they integrate all information required for assessment and eligibility functions for a variety of benefits and services into a single platform. This approach is conducive to improved coordination and efficiency gains. Beyond social protection, programs utilizing social registries include housing benefits, utility subsidies, education and training programs (such as need-based scholarships or training vouchers), subsidized health insurance, productive and financial inclusion programs, and legal services (such as court waivers or pro bono legal support). (ii) Unique identification Unique identification systems establish an individual’s uniqueness (that is, “you are who you say you are”) based on a minimal set of biographic and biometric attributes (Figure 8).67 As the objective is ensuring uniqueness, these unique identification systems provide government-recognized credentials to all persons in a country, regardless of their legal status. Public and private sector entities can subsequently rely on the unique identifier for transactions and service delivery. Unique identification systems are complementary to civil registration and vital statistics (CRVS) systems68 and interoperate with sectoral information systems (for example, social protection, health, education, financial services, population, and travel). For instance, India’s Aadhaar provides a 12-digit unique and random identification number to over 1.4 billion residents (near universal coverage) that can be verified by third parties for public and private service delivery. It uses minimal biographic attributes such as name, sex, date of birth, address, and contact phone number or email address, without collecting data on nationality, caste, or religion. CRVS systems play a key role in creating and attributing legal identity. CRVS are foundational systems for establishing a person’s existence and recording the occurrence and characteristics of vital events (for example, live births, deaths, fetal deaths, marriages, and divorces) on a continuous, permanent, compulsory, and universal manner. However, in many low- and middle-income countries accessing them is typically administratively burdensome, limiting their coverage. CRVS may not have the same level of interoperability with various government services and agencies or have the capacity to authenticate an individual’s identity in real-time, which are key advantages of complementary unique identification systems. Well-functioning CRVS systems that interoperate with unique identification systems enable a continuous feedback loop of data births and deaths, enabling sustained and dynamic inclusion for social programs. Unique identification systems are crucial for social protection delivery systems in four ways: • Ensuring the uniqueness of the individual. This is crucial to avoid duplications in program delivery (that is, the individual is registered and receives the benefits or services from a program only once). 67. Robust unique identification systems assign a random and unintelligible unique identifier or unique identification number to each individual. They are also underpinned by robust legal and institutional frameworks. 68. Although civil registration and vital statistics are not necessarily or technically a single “system,” the Playbook refers to CRVS in such a way for the sake of convenience and ease of understanding. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 23 CONCEPTUAL FRAMEWORK FIGURE 8 Unique identification PLATFORM LAYERS LAYER 1 LAYER 2 LAYER 3 FRONT OFFICE BACK OFFICE BACK OFFICE APPLICATIONS APPLICATIONS APPLICATIONS (PEOPLE) (ADMINISTRATOR) (DATABASES) PEOPLE Provide their biometric UP and biographic data DA ER T IST ED REG AT A DATA Manage Determine unique ID uniquenes system Collect their digital or paper credential DATA Authenticate individuals VER Y IF Y ID E N TIT Authenticate to access services CRVS SOURCE: Original for this publication. • Supporting Know Your Customer (KYC) and Customer Due Diligence (CDD) requirements set by financial services regulators and payment service providers. Authentication of identity credentials at the time of account opening minimizes anti-money laundering and counter-financing of terrorism risks (Lindert et al. 2020). • Authenticating the identity of a recipient during a payment transaction, benefit, or service provision. • Fostering interoperability across different DSPDS component systems. Through the unique identifier the DSPDS can appropriately exchange information and articulate data from different sources, thereby improving the overall performance of benefit and service delivery. Indeed, when everyone has access to a government-recognized proof of unique identity, social registries can more easily reach universal coverage and reliably assess eligibility for social protection and other benefits and services. In the absence of a system that establishes uniqueness, there could be repeated identity proofing, benefit duplication or misallocation, or multiple credential issuance for each functional system. Such duplication could in turn lead to the proliferation of functional identification credentials and biometric capture by various programs, and an escalation of administrative costs due to repeated cycles of identity proofing, credential issuance, and management. 24 “WHAT MATTERS” GUIDANCE NOTE (iii) Beneficiary operations management systems (BOMS) and integrated beneficiary registries (IBR) BOMS—generically referred to as program Management Information Systems (program MIS)—automate functional processes along the delivery chain, focusing on the enroll, provide, and manage stages of the delivery chain (Figure 9). BOMS are program-specific information systems that contain information on program beneficiaries and support day-to-day program operations, including: • Decision processes on enrollment. Through enrollment, eligible applicants become beneficiaries based on eligibility criteria established by each program. Some eligible applicants may not be enrolled in the program due to resource limitations. In such cases, non-enrolled eligible applicants can be waitlisted. BOMS support the generation of a list of beneficiaries, as well as beneficiary cards and waitlists. • Determination of benefit levels and/or service packages. BOMS support the decision on benefit levels and/ or service packages according to program rules. Beneficiary operations management systems (BOMS) and FIGURE 9 integrated beneficiary registry (IBR) PLATFORM LAYERS LAYER 1 LAYER 2 LAYER 3 FRONT OFFICE BACK OFFICE BACK OFFICE APPLICATIONS APPLICATIONS APPLICATIONS (PEOPLE) (ADMINISTRATION) (DATABASES) Social Insurance S AND SERVICES EFIT ST Education N AT BE Identify redundancies & L EM complementarities CIA EN SO T Monitoring Make and enrollment Cash compliance decisions Exchange Transfers data: A Push to DAT Assess Manage Notify dSR/pull beneficiaries coverage from beneficiaries of SP BOMS programs Determine Payment and benefit reconciliation & service Health package DATA Humanitarian IBR Disability SOURCE: Original for this publication. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 25 CONCEPTUAL FRAMEWORK • Payments administration processes, including reconciliation. BOMS generate lists of beneficiaries to be paid with their respective benefit amount and payment coordinates. After a payment session is finalized, the system supports the reconciliation process by receiving data on actual payments made and amounts disbursed. • Notifications. BOMS support programs in the process of notifying enrollment decisions and providing other key information related to the provision of benefits and/or services. • Beneficiary data management. This includes updating and rectifying the beneficiary registry, monitoring the delivery of benefits and services, managing grievances, and exit decisions. • Compliance with conditionalities or participation in accompanying measures. If the program includes conditionalities (usually related to health and education), BOMS store data on compliance with those conditionalities. BOMS also support the processes related to the consequences of lack of compliance, which could result in the household receiving a notification or warning, or in the reduction or termination of benefits received. If the program includes accompanying measures (for example, sessions on nutrition and early childhood development, household visits, or others), the system will store data on participation in these sessions. • Performance measurement and monitoring. BOMS can also generate, aggregate, and analyze data useful for the overall monitoring of a program, general policy analysis, and strategic vision support for social programs. These systems can generate a dashboard with basic monitoring program indicators. The underlying data of BOMS—also referred to as “beneficiary registries”—can be consolidated into an integrated beneficiary registry (IBR) that supports coordination across programs. Beneficiary registries contain information pertaining to a single program by recording “who receives what and when.” The integration of two or more beneficiary registries from multiple programs can result in an IBR. The IBR is a valuable “back-office” tool for coordination, monitoring, planning, analytics, and efficiency of benefits administration. It allows pinpointing duplications, gaps, redundancies, and complementarities across social programs through the dynamic intake of data on the benefits and services delivered to households, families, and individuals (Figure 9). Since IBRs link information on beneficiaries of social programs, they can signal the “supply” of social programs (George and Leite 2019) and assess the coverage of social protection programs. An IBR operates as a data warehouse that supports the coordination of benefits administration and can provide valuable information on the characteristics of delivered benefits, expenditure on social programs, and the performance of programs such as the frequency of payments or transfers, and speed or cycle- time of key processes (see Part 6—Performance). IBRs are not only helpful to governments but also to beneficiaries; by delivering consolidated social benefits and service statements69 they increase the transparency of social protection programs and empower households to understand and track their benefit and service status. (iv) Multi-program multi-provider payments platforms Governments are gravitating toward digital mechanisms for government-to-person (G2P) and person-to- government transfers over traditional approaches, as well as multi-program and multi-provider payments over program-specific arrangements. The shift to digital payment systems has led to a rapid increase in the need for financial and technological solutions to support payment administration and payments service provision. While payments platforms support payments for single programs in most countries, an increasing number of governments are leaning toward building a multiprogram model to improve coordination and efficiency in payment delivery. On top of that, the new generation of payment systems allows people to choose where they open their accounts and how they access their payments by leveraging an interoperability approach.70 The 69. Such as Mexico’s Cartilla Social. 70. A thorough review of payment systems can be found in Lindert et al. (2020). 26 “WHAT MATTERS” GUIDANCE NOTE FIGURE 10 Multi-program multi-provider payments PLATFORM LAYERS LAYER 1 LAYER 2 LAYER 3 FRONT OFFICE BACK OFFICE BACK OFFICE APPLICATIONS APPLICATIONS APPLICATIONS (PEOPLE) (ADMINISTRATION) (DATABASES) PEOPLE VIRTUAL PROVISION Digital wallets PEOPLE Exchange data: Pull and push data to BOMS Mobile money DATA CO N TRIB UT E Disburse payments IN-PERSON Bank account PROVISION DATA Reconcile BE payments NE IT F Electronically assisted, in-person S ITY NT V ERIFY I DE Cash, in-person SOURCE: Original for this publication. information systems supporting these processes are known as multi-program multi-provider payments.71 These platforms enable governments to make payments to people and vice versa (for example, social insurance and pensions). These systems automate back-end payments administration to increase the efficiency of public financial management, to prevent leakages, and to reduce operational costs (Figure 10). They can also allow for virtualizing payments provision to people at the front-end and interoperating with other systems to ensure third parties’ acceptance of digital transactions, thus potentially leading to increased financial inclusion72 and empowerment of “first mile populations.” Payment administration processes are often integrated with BOMS in the back end. BOMS support payment administration processes by managing the lists of beneficiaries to be paid with their respective benefit amount, account information, and other relevant data. This information is transferred to payments platforms to disburse 71. Payment platforms are covered in detail in the respective ISPA tool available at https://ispatools.org/payments/. 72. Social protection interventions have also been delivered in stablecoin-backed closed payment systems in Vanuatu as well as in Jordan, as well as in e-voucher systems. In remote contexts where either because of lack of connectivity or lack of payment service provider (PSP) infrastructure (no ATM, no POS), payments are difficult or impossible to complete and may require cash delivery, in-kind, e-vouchers, or the aforementioned closed crypto systems. A human-centered design approach is helpful to make adaptations to the provisioning of payments to beneficiaries. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 27 CONCEPTUAL FRAMEWORK the benefits in an automated way to the registered financial address or beneficiary account. Integrated financial management information systems (IFMIS), account accreditation systems (for example, banks’ internal transferring systems or mobile financial services transferring systems), and service contracts or agreements are all instrumental to payment administration processes. Once delivered, by receiving data from the payments platforms on actual payments and amounts disbursed, the BOMS supports the reconciliation process. The outcome of these processes is the actual level of benefits administered to the right beneficiary, at the right time, through an established payment service provision channel. In countries that have adopted the treasury single account (TSA) model, the nation’s treasury is responsible for authorizing payments out of government accounts. When the payment process is outsourced, the treasury transfers money to the payment service providers (PSP) responsible for the “first mile” account credits and withdrawals. For direct benefit payment schemes, the treasury directly makes the batch payment to beneficiaries’ accounts (provided that all beneficiaries have a bank account). Interoperable payment switches enable the transfer of funds in a single transaction, from the account of the specific government program or treasury to the account or wallet of the social protection program recipient. For instance, Bangladesh is developing an interoperable payments architecture with an HCD perspective that will allow any government program to channel payments through a central platform to accounts managed by multiple service providers. This platform will improve the beneficiary experience by enabling them to choose their preferred financial service provider and access point and will also give them the flexibility to switch providers and accounts as convenient. An interoperability approach to payments increases positive network externalities to beneficiaries and effectively, the size of the access channel network. A payment switch connects various institutions allowing interchange of payment transactions through routing authorization and authentication-related messages between participating institutions, and generation and distribution of clearing and settlement files. Payment switches include internet transactions, mobile devices, and smart payment cards, and can also host e-money platforms. Furthermore, interoperability with peer-to-peer platforms holds the promise of exercising agency and financial inclusion through so-called “open loop” transactions: social protection payment beneficiaries can use their digital wallets or mobile money accounts to transact directly with other individuals, as well as with merchants or service providers to buy food, pay for school fees, make health visits, or perform other small-value payments. Nevertheless, the persistence of “closed loop” systems impedes everyday cashless transactions based on beneficiaries’ choice and convenience, hindering financial inclusion and women’s economic empowerment (Lindert et al. 2020). (v) Data exchange Data exchange platforms act as trusted intermediaries and facilitate the seamless flow of information between diverse entities and components of DSPDS. By establishing standardized protocols and secure channels for data exchange between unique identification systems, dSR, BOMS, payment systems, and IBR (among others), they enable real-time sharing of information to populate and validate biographic, socioeconomic, and benefit management data. In data-poor environments where accurate and comprehensive data can be challenging to obtain from a single system, data exchange platforms can help break down silos, reduce duplication of efforts, and enhance the overall coordination of social protection programs. A data exchange platform can improve the accuracy of beneficiary information, expedite the identification of eligible recipients, and enable a more targeted and responsive approach to social protection. A clear example of these platforms is illustrated by Estonia’s X-Road which has been replicated in other countries, although it is not the only approach available. 28 “WHAT MATTERS” GUIDANCE NOTE (vi) Grievance redress mechanisms (GRM) information systems Robust GRM rely on well-designed information systems to input, track, and monitor grievances and resolutions. Also known as complaints and appeals mechanisms, GRM refers to a system by which queries, complaints, suggestions, and positive and negative feedback—at all stages of the delivery chain—are confidentially received and responded to, addressing implementation incidents efficiently and effectively. GRM information systems support the management of grievances across all its related processes, including uptake, sorting, processing, acknowledging, following up, verifying, investigating, acting, monitoring, evaluating, and providing feedback (Lindert et al. 2020). GRM information systems can be designed as a GRM module within the BOMS (as in Egypt, Jordan, and the West Bank and Gaza) or as an independent system that interoperates with the BOMS (as in the Philippines). GRM information systems can be specific to a program, support many programs, or be part of a broader grievance handling system for the whole government. Common features of effective GRM information systems include the following (Kumagai 2013; Lindert et al. 2020): • Real-time data collection. Grievance data are collected in real-time from various uptake channels, such as mail, email, call centers, websites, social media platforms, complaint forms, face-to-face interaction with program administrators, text messaging, and complaint boxes. • Automated responses. Where applicable, an automated response is issued to acknowledge the receipt of a grievance, generate a case number, and notify of a stipulated resolution time and follow-up methods. Such processes should be differentiated from automated processing of personal data, which, as a rule, should be disallowed, as should any purely automated decisions—that is, those made without human input—on the receipt or eligibility of benefits or services.73 • Consolidated data repository. Collected data are securely stored, including data collected through informal grievance channels. • Internal interface dashboard. Allows for real-time case tracking and monitoring of resolution status per case, reviewing assigned officer information, monitoring grievance status, issuing automated reminders to the supervisor(s) when deadline(s) approach and near, and accessing real-time data for evidence-based policy and program decision-making with data visualization and geotagging features. • External interface dashboard. Allows for real-time case tracking (usually via a case number) and exploring aggregated grievance resolution data and regular reports (such as annual reports). • Rapid custom reporting. Facilitates timely program information and various reporting outputs (for example, charts, maps, and tables) for decision-makers and other stakeholders. • Language. Allows back-end and front-end users to choose from interfacing in multiple languages. • Security. Contains features to safeguard the grievance process itself, as well as any other personal data collected, including encryption, firewall, and other tools for ensuring the confidentiality, integrity, and availability of data and systems. (vii) Case management information systems (CMIS) CMIS support caseworkers and beneficiaries across all phases of case management interventions. Integrated case management approaches involve identifying the needs of individuals, families, or households to provide an appropriate and sequenced bundle of benefits and services. It also involves intensive follow-up, monitoring, 73. World Bank and United Nations (2024), at Dimension 4.B Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 29 CONCEPTUAL FRAMEWORK and evaluation. A CMIS is a “software that supports all phases of case management interventions, that is, those processes that require repeated interaction between social workers and beneficiaries of social service”74 by providing a virtual setting for service delivery. These systems are particularly important for social workers in coordinating the delivery of accompanying measures to social assistance to individuals, families, and households. For a more detailed coverage of CMIS, we recommend referring to the Case Compass Toolkit.75 (viii) Data analytics platforms Data analytics platforms inform policy analysis and strategic decision-making for social protection programs, as well as improving transparency. Data analytics platforms allow the transformation, generation, aggregation, analysis, and visualization of data into meaningful and useful information with two primary purposes: (a) support decision-making, planning, and coordination of social protection systems (back-end processes), and (b) contribute to transparency and accountability of social programs and delivery systems (front-end processes). These platforms encompass various techniques, such as data visualization, data mining, reporting, time series analysis (including predictive techniques), online analytical processing (OLAP), statistical analysis, standardized reporting, ad hoc analysis, query and reporting, unstructured analytics, and text analytics, among others. Data analytics platforms can generate monitoring indicators at different levels (national, regional, provincial, or local) and include other characteristics of interest (for example, sex, age, disability, or employment status) to improve the effectiveness and efficiency of the social protection policy and programs. (ix) Geographic information systems (GIS) GIS create, manage, spatialize, and visualize all sorts of data based on location and descriptive attributes. GIS links data to maps to facilitate geospatial analyses to understand patterns, relationships, and geographic contexts. Geospatial data have vast implications for social policy. They can promote shock-responsive and adaptive social protection systems, reveal geographic patterns to identify locations with more prominent issues, forecast key outcomes and indicators such as population density, monitor change over time, and help to take stock of infrastructure to support development objectives, to name a few. Because of this, GIS systems layered within DSPDS and can also support data analytics at other stages in the delivery chain. Data sources can be georeferenced and stored in GIS, while machine-generated data can also feed into GIS systems. (x) Program inventories Program inventories systematize information on social protection programs and entitlements for service mapping. They contain key information on public and private programs, including their characteristics, objectives, intended population, linkages to higher-order strategies, coverage, and budget, among others. Program inventories help social, planning, and financial agencies to orient social protection policies across a country taking a whole- of-government approach. They allow for a systematic stocktaking of the supply of social protection programs and can be used for high-level planning. For instance, they facilitate finding programmatic gaps for specific groups or needs, as well as identifying redundant programs at different government levels or between public and private service providers. 74. Case Compass Toolkit. https://www.case-compass.org/. 75. Case Compass Toolkit. https://www.case-compass.org/. 30 “WHAT MATTERS” GUIDANCE NOTE SPOTLIGHT 1 UNDERSTANDING DIFFERENT STARTING POINTS OF DSPDS Countries undergo a continuous evolution when building DSPDS, and their starting points play a crucial role in shaping that trajectory. Often, this evolutionary process is nonlinear, as systems may encounter challenges and require new investments or corrections to progress—from incremental improvements to transformative leaps or complete overhauls; in other cases, capacity needs to be rebuilt due to fragility, conflict, regime change or disasters (Lindert et al. 2020). Even when system implementation proceeds smoothly, changes in policies, programs, context, financial resources, and technology may require transformations. The following examples highlight the diversity of starting points and the evolution of DSPDS over time in Türkiye, Colombia, Pakistan, and Mauritania, with a focus on the trajectory of social registries in these countries. CONSOLIDATING. Building on existing technological and operational infrastructures, Türkiye has, over the past two decades, consolidated its digital delivery systems for social protection and beyond to make them dynamic and interoperable. Historically, applications to programs were entirely paper-based and program-specific. This constellation of systems imposed a significant collective burden on people, who were required to collect some 17 documents to prove eligibility for social assistance programs. In 2005, following a prime ministerial decree on minimizing the administrative burden of applying, one-stop shops were leveraged to streamline this process for people. However, the outcome effectively shifted much of the burden to public servants, resulting in a 15-to-20-day consolidation period of documents from the various government agencies (MoFSP and World Bank 2017; Demiroz and Dansuk 2022). To address this problem and to further advance their systems, Türkiye launched in 2009, and finalized in 2015, its Integrated Social Assistance System (ISAS), which built upon foundational investments in a unique identification system (1990s–2000), a national addressing system (2006),76 and the Social Assistance Information System (2009), and which allowed for collecting administrative documents online. ISAS was developed in-house by the Ministry of Family and Social Policy (MoFSP) and the Turkish Scientific and Technological Research Institution (TÜBİTAK) using a modular approach, which begins with an online application and data management modules for the conditional cash transfer program. The development of each module follows four steps: design, development, testing, and implementation (World Bank, 2016c). To date, ISAS integrates data from 28 administrative data sources, offers 120 web-based services accessible through a single online portal, and people can apply to more than 50 programs by only providing their unique identification number (Demiroz and Dansuk 2022). ISAS relies on centralized and decentralized processes: data collection and payment delivery are managed centrally, while eligibility and enrollment decisions, grievance redressal, and house and community visits for data verification are handled by 1,003 autonomous Social Assistance and Solidarity Foundations (SASFs) deployed in each 76. The Address Based Population Registration System (ABPRS) was established between 2006 and 2007 to (i) define an address standard and prevent different descriptions of an address; (ii) obtain a standardized numbering and sign-boarding for all the country; (iii) set up a central address database including all of the addresses in the country; (iv) obtain information on population size and characteristics of the population; and (v) record population movements in the country (Beyazit 2020). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 31 CONCEPTUAL FRAMEWORK district and established since 1986 through Law no 3294 on the Promotion of Social Assistance and Solidarity (Ortakaya et al. 2022). TRANSFORMING. Colombia is on a path toward transitioning from a static social registry to a dSR, leveraging administrative data sources and universal coverage of identification systems, including for migrants. Launched in 1995, its System for the Identification of Potential Beneficiaries of Social Programs (SISBEN) was designed to rank people based on their socioeconomic conditions for the delivery of social benefits and services. The first three iterations of SISBEN (1995–2020) relied on data collected through a paper-based questionnaire administered by Colombia’s 1,003 municipalities and centralized by the Department of National Planning (DNP) to assess needs and conditions. Following a similar approach where data continued to be collected by municipalities, SISBEN IV (2021–2023) introduced two significant changes. First, data were collected through mobile devices via house visits, allowing the verification of people’s identity by scanning the identity credential’s QR code, collecting GPS coordinates of households to support program delivery and geographical analysis, and transferring data from municipalities to DNP on a daily instead of monthly basis. Second, SISBEN IV’s methodology was revised to ensure closer alignment with official multidimensional poverty measurements. Despite these improvements, SISBEN IV had some challenges, including limited mechanisms to verify data, creating incentives to misreport information, high data collection costs, and outdated information. Through decree no 812 of 2020, the Household Social Registry (RSH-Colombia) was created and effectively launched in 2023. RSH-Colombia is structured around four data sets: identification, household conditions, access to social programs, and income verification (for example, bank systems, social security, and taxes). RSH-Colombia takes as its basis the unique identification system which allows, on the one hand, reaching universal coverage and, on the other hand, exchanging data with 28 administrative data sources at the national level, including SISBEN IV, and with 1,832 local administrative data sources. A process of continuous improvement led by the DNP ensures the quality of the administrative data to enable its usability for the RSH-Colombia. When data are not available in administrative records, it will be collected through self-reported questionnaires (Briceño Villalobos 2023). TRANSFORMING. Three component systems are shaping Pakistan’s digital transformation journey: the National Socioeconomic Registry (NSER), the National Database and Registration Authority’s civil registry (as a unique identification platform) and its technology-enabled payment systems (Guven et al. 2024). Before the introduction of the Benazir Income Support Program (BISP) in 2008, Pakistan had a long tradition of fragmented social assistance initiatives, limited coverage, and poor targeting, relying on parliamentarian nominations to select beneficiaries. Built from scratch to support the BISP at the Assess stage, the NSER has evolved over the years to serve other programs and to move from static to dynamic data collection. Between 2010 and 2019, NSER implemented a score-card approach based on 23 variables, with data collected through a paper-based census sweep conducted in 2010–15 (surveying 27 million households). Then, in 2019–22, a digital census survey with 43 variables was administered to update existing data (surveying 35 million households). Since April 2023, 36.5 million households have been reached by the 647 dynamic NSER centers set up nationwide. Through these centers, people can register on demand, update their information, and comply with recertification procedures every three years. With a large coverage (97 percent of the adult population), the civil registry has played a crucial 32 “WHAT MATTERS” GUIDANCE NOTE role in ensuring robust real-time identification of beneficiaries and implementation of an e-payments system. Indeed, payments in Pakistan have significantly evolved—from Pak Post Money Order in 2008, to Benazir smart card and mobile banking in 2010, to Benazir debit card in 2012, to a biometric verification system handled by agents in 2016 to date (agent-centric model). Beneficiary-centric accounts are currently being piloted, whereby beneficiaries will be able to choose from five different banks initially and use their accounts as regular bank clients (Akbar 2023). BUILDING. Building its social registry from scratch, Mauritania has made significant progress in coverage. With the introduction of the 2013 National Social Protection Strategy, Mauritania’s social spending shifted from primarily crisis response spending to institutionalized and targeted mechanisms to reduce chronic poverty and improve vulnerable households’ resilience. Mauritania’s social registry was launched in 2016 to provide a foundation for targeting social programs and to support the expansion of the flagship safety nets program, Tekavoul, for extremely poor households. The first iteration of the social registry employed geographical targeting and a community process to select poor and vulnerable households. Data for selected households was collected through a questionnaire and verified through exclusionary filters and data analysis. A total of 225,855 households across 8,199 localities were registered under this approach. In 2023, the second iteration of the social registry was launched with the primary objective of increasing its coverage to the bottom 40 percent of households and updating the targeting methodology to mitigate potential inclusion and exclusion errors. The new targeting methodology consists of five steps: (i) geographical targeting with quotas at the commune level as per estimated poverty rates; (ii) poverty and vulnerability scoring based on a short questionnaire administered to all households within a locality. An equivalent of up to 80 percent of the quota by locality of households with the lowest score are pre-selected; (iii) community selection via general assemblies where the list of pre-selected households is restituted. Communities can replace up to 20 percent of that list and add the remaining 20 percent of the quota; (iv) administration of an extended questionnaire for final selection households; and (v) verification with sampled spot checks. Discussions are underway to develop mechanisms to ensure dynamic data updates (Saidi et al. 2023). The new iteration of Mauritania’s social registry will seek to include households in refugee camps building on the methodology developed in 2018 by UNHCR and the WFP, with households profiled under six categories: deprived, precarious, unstable, fragile, emerging, and catalyst. Households assessed in the first three will be included in the social registry (World Bank 2020c). Furthermore, user programs are responsible for determining eligibility criteria on top of the poverty and vulnerability score, making enrollment decisions, and managing beneficiary operations. Importantly, with limited civil registry coverage of the extremely poor and vulnerable, possessing a national identity number is not a condition for entry into the social registry. The system automatically assigns a functional identification number to households, only usable for the social registry (Taazour 2020). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 33 Part 2 Data A. DATA Data are values or a set of values representing a specific concept or concepts (World Bank 2016b). Data becomes information when processed, analyzed, and possibly combined with other data in order to extract meaning, provide context and support decision-making processes. Due to data’s non-rivalrous nature, this process might be done repeatedly (World Bank 2021). As such, data are a core input and output of DSPDS pipelines77 at different stages of the social protection delivery chain. DSPDS thus plays an important role in enabling and automating those processes: recording, transferring, transforming, deleting, and exploiting data to inform policy decisions and to support program design, implementation, and monitoring. Data consumed and analyzed by DSPDS are meant to represent an underlying socioeconomic condition, such as poverty or food insecurity, a demographic attribute (such as being a child or a pregnant mother), or record a transaction (such as receiving a benefit through a mobile phone). Under a fragmented approach, different programs may have separate information systems to manage the data required to determine who is who, who is in need, where they are, how they will be paid or serviced, and who has already received some form of assistance. However, those systems have many commonalities in terms of data management, therein motivating articulated data pipelines for DSPDS. Social protection information systems need to collect data during intake and registration, pre-process and complement it with additional data, analyze it to assess the needs and conditions of potentially eligible beneficiaries, and ultimately record the delivery of interventions and management of complaints for monitoring purposes. Yet, all data representations have limitations since they will simplify the phenomenon at hand, reducing complexities and, at times, inadvertently introducing biases. Furthermore, socioeconomic phenomena like poverty or vulnerability are not static and can change abruptly due to shocks such as the COVID-19 pandemic, financial crises, or natural disasters related to climate change. Dynamic phenomena thus necessitate dynamic data generation processes such that DSPDS data are kept up-to-date and so the policy interventions supported remain pertinent and effective under changing circumstances (Figure 11). 77. Data pipelines can be understood as a series of data processing stages linked and articulated to achieve a particular outcome, usually intaking raw data, applying various data transformation techniques and porting it into a data store before it is exploited or shared with other systems. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 35 CONCEPTUAL FRAMEWORK FIGURE 11 From data generation to intervention delivery Dynamic Data Dynamic Pre- Needs & Conditions Decision- Intervention Phenomenon Generation Data processing Assessment making SOURCE: Original for this publication. A DSPDS framework enables data interoperability from different sources, arranging them into biographic, socioeconomic, and benefit management data sets. Data can be structured (such as survey data or administrative records), unstructured (such as social worker assessment notes or images), or semi-structured (such as emails).78 However, to exploit and extract meaning from different data sources, DSPDS can use multiple processes to organize and harmonize data along key data sets. Since people are the central entity around which DSPDS are built and operated, a master data set is needed to integrate all other data sets—that is a biographic data set that contains the basic and mostly static attributes of an individual (such as names, gender, date of birth) together with a unique identifier (whether functional or foundational) that uniquely references that individual. However, a biographic data set on its own is not enough to know if that person is poor, vulnerable, or food insecure, thus a socioeconomic data set is required to assess the needs and conditions of individuals and households and to determine potential eligibility for targeted programs. Socioeconomic data sets support the core functions of dSRs, as described previously. Finally, benefit management data sets are necessary to enroll or exit beneficiaries,79 deliver and monitor benefits, and manage any associated conditionalities. Benefit management data sets are used to support the core functionalities of BOMS, payments platforms, case management systems, and IBR. When dSR, BOMS, payments systems, and IBR operate in a fragmented and siloed manner, each of them necessarily replicates biographic data sets and identifiers that may or may not coincide, leading to potential errors or misallocations. As independent systems, it is hard or inviable to jointly exploit the socioeconomic and benefit management data sets in order to identify potential inclusion/exclusion errors as well as to analyze potential gaps in the coverage of benefit packages tailored to the needs of specific population groups. Taking a DSPDS approach, however, these three data sets interact and coexist simultaneously, enabling more accurate and richer analytical outputs for policy decision-making. The data sets outlined so far are not meant to be exhaustive nor restrictive of other data sets that might be useful for a DSPDS approach depending on the country context. In the following sections, we describe the contents of the DSPDS data sets, discuss how data can be directly or indirectly collected, some of the most commonly used data sources, and propose criteria to assess their relative strengths and weaknesses. 78. See https://www.ibm.com/blog/structured-vs-unstructured-data/. 79. See section on exit decisions of Part 3 Delivery Chain for further details. 36 “WHAT MATTERS” GUIDANCE NOTE (i) DSPDS data sets DSPDS data sets are organized collections of related information and data records duly grouped as they have similar functions along the social protection delivery chain. As such, DSPDS data sets can be understood as placeholders or structures that are populated with data from different sources. Data sets group together multiple data fields and help to define the data models of DSPDS component systems. To better illustrate the contents of the main DSPDS data sets, their most commonly used data fields are presented below. These data fields and resulting structures should not be interpreted as exhaustive or prescriptive but rather illustrative of the basic data models relevant for DSPDS. Biographic data set: Contains basic biographic attributes of each individual, as well as an associated unique identifier. These data sets need to be part of all systems underlying the DSPDS, as they are necessary for interoperability. The biographic data set typically includes “static” and/or the slowest-changing attributes of individuals, such as: • Unique identifier—foundational and/or functional • Names (first, last, given, surname) • Date of birth • Sex • Place of birth • Contact information Ideally, the unique identifier and at least some of the associated attributes should be verified80 through an interoperability protocol between the unique identifier and all underlying DSPDS systems. Also, when CRVS systems are available and functional they can provide critical information on births and deaths of household members, which can impact the household composition. However, in the absence of a foundational unique identifier—one that has been attributed to everyone and that is truly unique—the best available functional identification system might be used as a pragmatic alternative. When existing functional identifiers do not have enough coverage or are not reliably unique, each system may need to create their own internal functional identifier. Doing so, however, is a suboptimal option from a whole-of-government systems perspective because it leads to repeated cycles of identity proofing, credential issuance, and management. It also creates matching errors where a number of individuals may end up with incomplete information. In all cases, the biographic data set should serve as a master data entity that ensures uniqueness and provides a “backbone” for all of the other DSPDS data sets. This approach implies that the data fields of the biographic data set are generally static and rarely change over time (with some exceptions such as the contact details). Furthermore, if the biographic data set is harmonized with a foundational unique identifier or a widely used functional identifier, it can play a critical role in facilitating interoperability with education, health, contributory, fiscal, and other administrative information systems for pan-governmental data sharing. 80. Data are verified against a source system to ensure that the data are accurate, consistent, and reflect their intended purpose. Verification is not to be confused with data validation, which is the process of determining whether the values of a particular data point fall within specific parameters, ensuring its syntaxic and semantic validity. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 37 CONCEPTUAL FRAMEWORK Socioeconomic data sets: These dynamic data sets are critical components of dSR as they contain the fields required to assess the needs and conditions of households and to determine potential eligibility according to the eligibility criteria of user programs. Such data sets typically include: • Household composition and household relationships • Dwelling characteristics such as the number of rooms, building materials, and access to electricity, water, and sewage • Education such as literacy, highest degrees attained, school assistance, or access to education services • Health such as illnesses, disabilities, or access to health services • Employment status and occupation • Income, expenditures, and/or consumption • Assets such as household durables, vehicles, livestock, and land • Food security • Exposure to natural disasters • Location such as address and coordinates • Other information depending on the requirements of the user programs (such as indigenous status, remittances, and others) • Household unique identifier An important characteristic of the socioeconomic data sets of dSR is that some data points are at the individual level (for example, the highest educational degree attained), whereas others are at the household level (for example, dwelling characteristics). The grouping of individuals into household structures requires predefined criteria of what constitutes a household in order to generate a unique household identifier (HIN). These criteria are usually context-specific and must be coupled with operational rules to update the composition of households according to their dynamics (see Table 3 in Part 3 for a few examples of household definitions across the world). Also, socioeconomic data sets can be complemented, verified, and/or cross-checked against other sources, for example, administrative data such as tax records, social security contributions, or asset ownership records,81 or novel data sources such as satellite imagery and call detail records.82 Finally, the socioeconomic data sets of dSR need to be closely aligned with the policy objectives of the government agencies utilizing the system. For example, if the user programs are meant to reduce extreme poverty, the socioeconomic data sets need to capture the relevant data points required to assess or approximate extreme poverty according to its prevailing definition. If the policy objective is to address vulnerability or food insecurity, the associated socioeconomic data sets might need to capture different data points and attributes. Hence, the particular contents of the socioeconomic data sets of dSR are country and context specific, requiring careful consideration by taking into account the policy objectives, the key metrics that programs act upon, and the methods needed to assess such metrics. Benefit management data sets: These transactional data sets are critical for the BOMS used by programs to manage benefits and services as well as for payments systems, IBR, GRM, and case management components of DSPDS. They contain program-specific fields to allocate and monitor the delivery of benefits and services to beneficiaries. This can include data on: 81. See, for example, a case study of Türkiye’s ISAS (Ortakaya 2022). 82. See, for example, Togo’s Novissi program (Lawson et al. 2023). 38 “WHAT MATTERS” GUIDANCE NOTE • Enrolled program beneficiaries at the individual or household level • Benefits to be delivered, including the schedule of payments or payrolls • Reconciliated benefits including level, type, program, date, and location of delivery • Monitoring of compliance with conditionalities or participation in accompanying measures • Social insurance contributions • Household visits, cases, appeals, grievances • Channel through which benefits and services are delivered • Audit traceability Benefit management data sets are mostly used to determine “who receives what” benefits and services, and can be useful to identify intended complementarities or unintended redundancies across programs. As such, they usually contain transactional data that is dependent on the delivery cycles of each program (monthly, quarterly, and so forth). BOMS usually maintain the list of enrolled beneficiaries and produce the schedule of payments to be used by payments systems. Once benefits have been delivered and reconciliated they can be integrated by an IBR. Beyond the specific contents of the data sets, modularity and minimalism are key attributes needed to dynamically update the DSPDS, particularly for the dSR. In many instances, such as in Mexico before 2010, when multiple programs independently did the intake and registration and the assessment of needs and conditions, they relied on multiple socioeconomic questionnaires of varying length. Each questionnaire was meant to include the necessary variables required to determine the eligibility of potential beneficiaries for the associated program. This resulted in multiple data sets incompatible with each other, but that often shared some commonalities, thus creating important data management redundancies. When social registries are introduced as whole-of- government platforms, there is a need to harmonize socioeconomic questionnaires separately used up to that point. The consolidation of multiple socioeconomic questionnaires into a single harmonized questionnaire presupposes many efficiencies in terms of how data are collected since households only have to answer one questionnaire instead of many, thus simplifying the social registry’s data management and reducing the information burden on households. The resulting harmonized questionnaire is often robust yet lengthy, since it serves the needs of many programs at once. In the Mexican case, 17 distinct questionnaires were consolidated into the Cuestionario Único de Información Socioeconómica (CUIS),83 resulting in a monolithic data set of over 120 variables that would take anywhere from 80 to 120 minutes to collect depending on the household composition. Many other countries have similar harmonized questionnaires, as shown in Figure 12. Questionnaire length can also result in respondent fatigue which may introduce certain biases and undermine the quality of the data collected,84 thus further motivating modularity and minimalism in the design of social registry questionnaires. While the consolidation of socioeconomic questionnaires does simplify data collection, the length of a harmonized questionnaire directly impacts the cost and logistics of administering it to large numbers of households. The costs and logistics needed to deploy massive door-to-door sweeps imply that the monolithic data sets of harmonized questionnaires are not easy to update, especially in countries where statistical institutes have low capacity. This is one of the driving factors behind the fact that large social registries that heavily rely on administrator-driven data have only been updated every 4 to 8 years. Examples include the Philippines’ Listahanan in 2011, 2015, and 2019; Pakistan’s National Socioeconomic Registry in 2011 and 2019 (although they have since migrated to on-demand intake and registration); and Colombia’s Sistema de Identificación de 83. PowerPoint presentation Cuestionario Único de Información Socioeconómica (CUIS), Dirección General de Geoestadística y Padrones de Beneficiarios (SEDESOL 2011a). 84. See Jeong et al. (2023), which documents that an additional hour of survey time increases the probability of item non-response by 10–64 percent in an experiment in Liberia and Malawi. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 39 CONCEPTUAL FRAMEWORK FIGURE 12 Benchmark of harmonized socioeconomic questionnaires Question count of harmonized questionnaire Minutes per questionnaire (estimate) Niger Niger Mexico Mexico Brazil Brazil Turkey Turkey Average Average Burkina Faso Burkina Faso Senegal Senegal Bangladesh Bangladesh Togo Togo 0 20 40 60 80 100 120 140 160 0 20 40 60 80 100 Household questions Individual questions SOURCE: Original for this publication. Potenciales Beneficiarios de Programas Sociales in 2005, 2011, and 2017.85 In order to address this issue, harmonized socioeconomic questionnaires can be broken up into modular data sets that act as “data Lego blocks” (Figure 13), allowing social registries to intake as much data as needed for each program and thereby increasing the cost- efficiency of data management. As such, modular data sets can be divided into core data modules, that should be populated for all individuals and households due to their high re-usability across programs, and complementary data modules, that can be populated as needed depending on the specific requirements of each program served by the platform (Brazil’s Cadastro Único and Mauritania’s social registry follow this approach to some extent). The specific contents of core and complementary modules are context-specific and should respond to the priorities of the programs and entities using the dynamic social registry. While modular, these data sets must remain harmonized and hence should be compatible by design by drawing from a common data dictionary. FIGURE 13 Modular data sets (illustrative) Biographic Socioeconomic Benefit Management Data Set Data Set Data Set HH Location UNI Biographics HIN +Composition Welfare Proxies Health Education Labor Program A Program B Ind.1 H1 yit x1it ... ... xnit Ind.2 H1 Ind.3 H1 Ind.4 H1 Ind.6 H2 Ind.7 H2 Ind.8 H2 Frequency: Lowest Frequency: Low Frequency: Medium to high Frequency: Medium to high Frequency: High SOURCE: Original for this publication. 85. See Barca and Hebbar (2020) for other documented examples of census sweep frequency, usually happening every 5 to 8 years instead of the typical stated goal of every 2 to 3 years. 40 “WHAT MATTERS” GUIDANCE NOTE (ii) Data generation and sources DSPDS data sets lie within the static-dynamic spectrum, depending on their nature and context. Data can be slow changing (that is, they remain mostly unchanged over time or change predictably), or they can be dynamic (that is, they change unpredictably and at different frequencies). Biographic data sets contain both types of features. Slow- changing features include unique identifiers (should not change), sex (rarely changes), or age (changes predictably), whereas an individual’s contact information such as telephone numbers or emails can change unpredictably. Socioeconomic data sets tend to be more dynamic but at different rates of change. For instance, household composition tends to change occasionally whereas welfare proxies, such as housing conditions or durable assets, usually change less frequently than employment status, income, or the consumption of certain items. Furthermore, the variability of socioeconomic data sets may behave differently in rural, urban, or semi-urban contexts. Benefit management data sets are highly dynamic and transactional as they reflect the day-to-day operations of social protection programs. That said, the fields of benefit management data sets are usually directly observable to program administrators, in contrast to socioeconomic attributes which are not always directly observable and often rely on proxies to approximate the welfare of households. Due to the changing circumstances of poverty and vulnerability, the socioeconomic data used to represent such phenomena have a latent half-life, depreciating or losing currency as time passes. According to some estimates, approximately 2 percent of records within a customer database become obsolete every month.86 This implies that a given database with static records would have a half-life of two years (that is, within two years, nearly half of the database becomes obsolete), and after 4.2 years, the entire database is outdated.87 It is difficult to reliably determine and establish the pace at which data become obsolete. Moreover, the recent so-called “big data” revolution has undoubtedly exacerbated this issue, underscoring the necessity for dynamic data generation processes. Beyond a uniform or constant half-life, it is more likely that different elements of the dSR data have context-specific—yet hard to observe—half-lives. Thus, the latent half-lives of socioeconomic data have important implications for data intake and exchange across DSPDS component systems. To gather socioeconomic information and keep it up to date, the dSR can directly collect self-reported data from households. Self-reported data are directly collected by administering household or individual questionnaires specifically designed for the social registry. This approach is considered directly collected data because the subject being interviewed, the potential recipient of social protection benefits, is actively providing socioeconomic data to the social registry which will be used to determine program eligibility. As discussed by Sen (1995),88 this can lead to informational and incentive distortions since the potential recipients of social protection benefits may intentionally bias self-reported information by over- or under-reporting particular aspects of their socioeconomic conditions such as income, asset ownership, and others. Unintentional bias can also affect the respondent’s self-reported answers when questions are hard to recall, confusingly stated, or simply misunderstood. Whether intentional or not, under- and over-reporting can, in turn, lead to inclusion and exclusion errors, reducing the effectiveness of social protection programs and the resources allocated to them. However, these potential biases are context- specific and hard to identify and quantify. That said, such biases can be mitigated by verification and cross-checking mechanisms like in Chile (see the Assessment of needs and conditions section of Part 3). 86. See Fan, Geerts, and Wijsen (2012). Also, a commercial email validation service noted that in 2023 nearly 23 percent of emails had decayed within one year, which is consistent with a 2 percent monthly decay rate: https://www.zerobounce.net/email-list-decay/. 87. Using a constant rate of change for all variables in a given database is a simplification only meant for illustrative purposes. Social registries containing rich sets of socioeconomic attributes likely go through a more complex and uneven outdating process. 88. See Sen (1995) for a detailed discussion on direct and indirect societal costs of targeting. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 41 CONCEPTUAL FRAMEWORK At the same time, the dSR can pull administrative records indirectly generated by other entities. Administrative records are usually the result of a transaction (for example, paying income taxes or purchasing a car), the use of a service (for example, attending school or making a call through a mobile phone), the delivery of a benefit (for example, the reception of social assistance), or the recording of a life event (for example, birth or marriage).89 For the purposes of DSPDS, this is considered indirect data generation because administrative records are a byproduct of a transaction, service, benefit, or administrative event that originates them. That is to say, the subject is not actively answering a question for the social registry, but rather, in making a transaction or using a service, a parallel and independent process results in the creation of an administrative record. However, in order for those administrative records to be fully exploited, the individual should be aware of these parallel processes and, as personally identifiable information is involved, consent to as much (as detailed in Part 5—Governance). Two key properties of administrative records are that they are usually cheaper to produce and tend to have a higher production frequency relative to self-reported data, potentially making them more cost-efficient than self-reported data collected through questionnaires. As an example, Chile and Türkiye’s social registries leverage administrative data by periodically integrating then from different ministries and using it to verify or complement self-reported data. Relevant trade-offs between direct and indirect data generation processes should be considered when populating the dSR data sets. Data directly collected through questionnaires designed to assess needs and conditions of social protection programs result in tailored data sets that can be used to produce detailed and meaningful insights about the wellbeing of households. However, data indirectly pulled from existing administrative records may be fragmented and contain more limited data sets that require some degree of pre-processing and harmonization in order to be integrated and exploited by the dSR. Also, direct data collection exercises are usually designed to identify a specific population group, such as the poor and vulnerable in a particular geographic area, thus increasing the likelihood of covering the whole population group of interest. Indirect data generation is usually tied to existing administrative systems, such as contributory pensions or tax records, that may or may not cover an intended population, like informal workers. Another example of indirect data is call detail records (CDR) or mobile phone metadata, which rely on mobile phone coverage that may not be available in rural areas where the poorest households usually live, and mobile phone ownership that is also less prevalent amongst poorer households. As such, the most salient trade-offs between direct and indirect data are the coverage, cost in time, and resources to generate them, and the accuracy and degree of subjectivity embedded in them. Table 1 summarizes a non-exhaustive set of advantages and disadvantages of direct and indirect data: TABLE 1 ADVANTAGES DISADVANTAGES • Tailored to specific assessment of • Self-reported and subject to intentional or needs and conditions unintentional biases Trade-offs DIRECTLY • Does not require high technical • Limited updating frequency COLLECTED between capacity to administer and process • Costly if based on in-person data DATA • Can have complete coverage of collection directly and target population indirectly • Lower cost • Fragmented and sometimes unstructured • More objective data may require high technical capacity collected INDIRECTLY • More frequently updated to migrate, harmonize, and integrate data COLLECTED • May have incomplete coverage of target DATA population • Potential privacy and data protection risks SOURCE: Original for this publication. 89. See Barca et al. (2023) for a comprehensive overview on the use of administrative data in social protection. 42 “WHAT MATTERS” GUIDANCE NOTE BOX 2 Traditional versus novel data sources While many programs rely on “traditional” data sources to assess needs and conditions, an increasing number are considering novel data sources, including the use of “big data” to overcome their limitations. Traditional data typically come from self-reported household surveys or administrative records from other governmental systems. These usually gather socioeconomic and demographic information, such as income, assets, consumption, employment status, education, migration background, and disabilities, in order to assess welfare. When data are collected directly from individuals or households, the instruments allow for a significant level of detail; however, this approach entails some limitations. First, data may be constrained by the scope of a predefined methodology for assessing needs and conditions (that is, the survey may exclusively address the data needs to calculate a specific outcome variable, such as consumption). Second, data are confined to a particular sample, leading to potential sample errors and biases. Third, data are infrequently updated, as doing so is usually costly. And fourth, data are prone to response bias due to self-reporting. Although administrative data are often more accurate and updated with relatively greater frequency relative to other traditional sources, the underlying administrative data collection procedures may also lead to measurement errors. For example, in more informal economies, administrative data are likely to exclude the poorest and more vulnerable groups. Administrative data such as fiscal records can also have limited quality due to underreporting (for example, to avoid tax collection), especially in countries with limited state capacity. Interoperability and integration across different information systems can help to tackle the issue. Due to these limitations, program implementers are turning to hybrid approaches and incorporating novel data sources, such as big data, to assess the needs and conditions of registrants. “Big data” may be helpful for assessing and reassessing needs and conditions much more dynamically. Big data—which typically refers to data sets that are too large or complex to deal with through traditional data processing approaches— are generated by governments or commercial firms for a variety of purposes and not necessarily for welfare assessment. Big data are produced continuously and are often available in real-time, allowing not only rapid program rollout but also more frequent reassessments as conditions change. Examples of big data include remote sensing data (satellite imagery, climate data, GPS coordinates, and so forth), mobile phone metadata (call detail records or CDR), phone-based location, social media data, and financial transactions. The COVID-19 pandemic served as a catalyzer for the use of some of these novel data sources for the delivery social protection programs (Aiken and Ohlenburg 2023). Through algorithms based on machine learning, big data such as CDR can be transformed into proxies for welfare and used for targeting emergency cash transfers, as was the case of Novissi in Togo (Lawson et al. 2023). The main challenges of big data are still to be fully understood and solutions crafted. Such challenges include prediction biases, accuracy, ownership, and data protection and privacy. Using big data for assessing needs and conditions may raise socio-cultural and human rights concerns if, on the one hand, data protection and privacy safeguards are not in place (Box 5), and if, on the other hand, people do not fully understand how and why data about their personal actions and consent-based mechanisms are not integrated (Box 6). In addition, when data are owned by private sector agents, these may not be accessible to governments. Moreover, machine learning algorithms can actually encode bias if not managed and carefully monitored. If survey data are unavailable or lack quality, big data machine learning algorithms are likely to be unintentionally biased or not developed. An additional challenge that remains to be understood is the uncertainty around the possible household and individual behavioral changes once they become more aware of how big data—generated by their usage of digital services—is used to determine their potential eligibility for social benefits. In developing DSPDS that incorporates big data, careful attention needs to be given to ensuring equality of treatment and dignity. Especially in the collection and use of big data, social assistance needs to be set up in a way that does not expose every detail of beneficiaries. That risk is especially heightened when engaging with the poor and vulnerable—and should be actively guarded against in the development of DSPDS governance—as asymmetries of power could be at play. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 43 CONCEPTUAL FRAMEWORK Beyond how data are structured and generated, it is also important to keep in mind the concrete sources of data that can be used to populate the dSR and IBR. The availability of different data sources can vary greatly among countries depending on the maturity of their data ecosystem. As such, data directly collected through self-reported surveys have been the original and most commonly relied upon data source for social registries. As social registries evolve and become more dynamic, they interoperate with other information systems that can provide administrative data, such as tax systems, vehicle registries, disability registries, health management systems, education management systems and others. For instance, when Chile transitioned from the Ficha de Protección Social (FPS) to the Registro Social de Hogares (RSH) in 2016 (Spotlight 2), the government decided to maximize the use of available information allowing to pre-populate the data sets of RSH with data contained in the FPS and available administrative records (MSDF and World Bank 2018). Figure 14 below shows some of the most commonly used data sources for dSR and IBR although it does not pretend to be exhaustive.90 (iii) Data attributes Self-reported data, administrative records, and other data sources can complement each other, using their respective strengths to offset their weaknesses. To assess the strengths and weaknesses of the different data types available for DSPDS, four attributes might be used:91 • Breadth: What is the potential coverage of the data type (that is, for how many households or individuals can the data be collected from or generated)? Self-reported socioeconomic data can be collected in person or remotely, through online or phone-based applications. While in-person data collection efforts are considered time-consuming and expensive to replicate frequently, they allow for more exhaustive and focused data collection. Examples include census-sweeps such as Pakistan’s National Socio-Economic Register FIGURE 14 dSR and IBR data sources dSR and IBR Dynamic Social Registry (with interoperability) Integrated Beneficiary Registry Data from other Non-Traditional Self-Reported Information Administrative Data from BOMS Administrative Systems Data Family Composition Taxes Call Detail Records Cash Transfers Disability Registry Financial/Banking Housing Conditions Satellite Imagery Subsidies Scholarships Utilities Education Road Density Social Insurance Social Services Health Insurance Health Weather Educational Status Unemployment Income Support Benefits Programs Occupation Population Land/Property Ownership Pensions Etc. Income Nightlights Vehicle Ownership Public Transport Farmer’s Registry SOURCE: Author’s elaboration based on Silva Villalobos (2016), and Lindert, George, and Leite (2018). 90. See section 5.2 of Johnson and Walker (2022) for a detailed discussion. 91. Description of the four attributes is adapted from Barca and Beazley (2019). 44 “WHAT MATTERS” GUIDANCE NOTE or Bangladesh’s National Household Database. In contrast, remote data collection efforts are usually more limited in scope (shorter questionnaires) and may lead to some people being excluded in contexts with low digital readiness. Administrative records such as tax records can only be generated from tax-paying formal workers, which in many contexts represent a minority of the labor force and usually do not include the poorest and most vulnerable, particularly in developing countries. Likewise, mobile phone metadata such as CDR can only be collected from mobile phone users, thus requiring a high mobile phone penetration rate to be used effectively. • Depth: What welfare dimensions can be captured by the data source relative to the assessment of needs and conditions and eligibility determination? As discussed later, there are many ways to assess needs and conditions and to determine eligibility of potential beneficiaries of social protection programs. The complexity of such processes will shape the socioeconomic data sets of the dSR and the welfare dimensions that need to be captured by it. For example, and on the one hand, some programs may prioritize their interventions categorically, only using a few demographic variables to determine eligibility, like “universal” social pensions based solely on age. On the other hand, many poverty-targeted programs in developing countries rely on Proxy Means Tests (PMT) based on self-reported questionnaires to estimate the monetary income or consumption of households through a set of proxies such as educational attainment, asset ownership, whether taxable income, electricity consumption, vehicle ownership, or other. Yet other programs or agencies may utilize multidimensional poverty metrics combining income/consumption estimates together with access to services such as health, electricity, and others (such as Mexico’s SIFODE or Colombia’s SISBEN). In this instance, both self-reported information from socioeconomic questionnaires and administrative records might be of use. Any particular source of administrative records, however, tends to capture a single welfare dimension. • Accuracy: How accurate or potentially biased is the data type/source? Both self-reported data and administrative records can be subject to different sources of bias that diminish their accuracy, thus potentially negatively impacting the policy decisions based on such information. Self-reported data are prone to reporting bias as respondents might have an incentive to intentionally misreport aspects that are not directly observable to become eligible for social protection programs. At the same time, administrative records are more readily observable because they are derived from the recording of a specific act such as a transaction or the use of a service in which the subject is not actively being asked to provide information and thus has less incentive to alter their behavior. • Timeliness: How fast does the data type become outdated? The different variables of the DSPDS socioeconomic data set depreciate over time at different rates due to different factors. Stable data sets, such as biographic data, do not usually change over time, while dynamic data sets—for instance, those relating to employment, consumption, or household composition—may vary substantially. Understanding the half-lives of data sets is necessary to properly determine the frequency at which they should be updated. Directly and indirectly collected data may be combined to extend the half-life of dSR socioeconomic data sets. A baseline socioeconomic data set could be collected through self-reported questionnaires, allowing for on-demand remote and periodic or continuous data updates. Figure 15 provides an illustrative example of how the half- lives of a static and a dynamic social registry could behave hypothetically. The records of a static social registry, that relies solely on self-reported questionnaires collected door-to-door, continuously depreciate over time with a half-life of two years, at which point half of its records are out of date. After four years most of the static social registry records are out-of-date, triggering a costly administrator-driven full update. By contrast, a dynamic social registry relies upon on-demand data collection of self-reported questionnaires complemented by administrative records from other systems. In doing so, the dSR is capable of partially updating its records every year and hence extending its half-life. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 45 CONCEPTUAL FRAMEWORK FIGURE 15 Half-life of data in static and dynamic social registries (illustrative) 100% 90% 80% UP-TO-DATE RECORDS Natural 70% Decay 60% Static 50% Social Registry 40% 30% Dynamic Social 20% Registry 10% 0% TIME SOURCE: Original for this publication. B. PROCESSING As the throughput of DSPDS, data are transformed into information by multiple processes, including harmonization, cleaning, deduplication, integration, exploitation, and deletion, among others. Depending on the architecture of the DSPDS as well as how data are generated and structured, specific data processes might be required at different stages or by different component systems and modules of the DSPDS. However, the results of such data processes will inherently be limited by the initial quality of the raw data, as the popular expression “garbage in, garbage out” rightly illustrates. The degree of automation of these data processes, as well as whether they happen online or offline, will also depend heavily on the underlying technologies of DSPDS, which are discussed in greater detail in Chapter 4. Some of the main data processes include the following: • Data harmonization is key to ensure syntactic and semantic interoperability between the different component systems of the DSPDS, as well as with external information systems. Harmonization is the process of standardizing data sets to make sure that data from different sources can be merged, pooled, or integrated in a cohesive manner. This is of particular importance for data exchanges between multiple program-level BOMS and the IBR. • Data cleaning is necessary to improve the quality of raw data according to predefined quality criteria, triggers, and rules to correct inconsistencies in the data. It can be done at any stage and at different degrees of intervention onto the raw data. 46 “WHAT MATTERS” GUIDANCE NOTE • Data deduplication is the process by which redundancies and duplicates are detected and addressed. It is necessary when a preexisting unique identifier is not available or when it is not reliable. Establishing unicity is the main responsibility of the foundational unique identification system, but if such a system is not available, the DSPDS might have to resort to creating its own internal functional identifier. • Data integration is the process of joining multiple data sources together through a common identifier in order to provide a unified view. This technique allows the verification of a particular attribute by integrating and contrasting different data sources, such as income self-reported in a socioeconomic questionnaire versus income obtained from tax records. • Data exploitation relies on analytical methods that derive meaning from the data that have been harmonized, cleaned, deduplicated, and integrated. It consists of synthesizing and analyzing data to produce analytical insights for decision-making. • Data deletion/destruction involves identifying data that need to be removed, which can be done through manual or automated means. Once the data to be deleted is determined, they undergo a secure deletion process, which may include overwriting these data with random patterns or using cryptographic techniques to render them irrecoverable. Records of data deletion activities should be kept for compliance purposes and to demonstrate adherence to data protection regulations. As such, DSPDS data pipelines can be understood as a series of processes applied unto multiple data sets by different systems at various stages of the social protection delivery chain. The pipelines (Figure 16) start with the intake of socioeconomic information, which is used by a dSR to assess the needs and conditions of registrants and determine the eligible populations of programs. Enrollment decisions taken by the BOMS of each FIGURE 16 DSPDS data pipelines Determination Assessment of Benefits of Needs and and Service Conditions Package Integration Registrant Beneficiary Reconciliated Updated Eligible Enrolled socioeconomic rosters and payment beneficiary population beneficiaries information payrolls reports registry Intake & Enrollment Provision of Registration Decisions Benefits and/or Services SOURCE: Original for this publication. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 47 CONCEPTUAL FRAMEWORK program determine the subset of enrolled beneficiaries that will be allocated benefits and services. The BOMS produces the beneficiary rosters and payrolls which are used by the corresponding provisioning platform, such as a payments platform for cash transfers, to deliver the benefits and services to its intended beneficiaries. Once reconciliated, actually delivered benefits and services are integrated by the IBR as updated beneficiary registries. These interactions are described in greater detail below (Part 3—Delivery Chain) and are understood as DSPDS data flows (Part 4—Technology). The data processes highlighted above contribute to DSPDS data governance and help to ensure high data quality, integrity, security, and proper management throughout the data lifecycle. As discussed below (Part 5— Governance), effective governance—over data but also over the whole of DSPDS—is crucial for the successful delivery of social protection programs. Among other things, governance involves clearly defining roles and responsibilities for data management, establishing data standards, ensuring data privacy and security, and implementing mechanisms for data quality control. Robust DSPDS governance facilitates seamless-but-legitimate data sharing and interoperability among different DSPDS components, enhances the accuracy of the data flowing through its pipeline, reduces the risk of errors or fraud, and ultimately contributes to more efficient and targeted benefits and services to those in need. Setting up good governance as an upfront and by-design priority also creates a basis and means for ensuring that all DSPDS actors—be they designers, implementors, administrators, or other partners or participants—remain attentive to ensuring equality of treatment and preserving beneficiary dignity, a point of particular concern when implementing data-rich and data-reliant DSPDS, and even more so in dealing with society’s poor and vulnerable. 48 “WHAT MATTERS” GUIDANCE NOTE Part 3 Delivery Chain The Social Protection Delivery Systems Framework92 elaborates on the key elements of the operating environment for implementing social protection benefits and services. The framework is anchored in core implementation phases along a delivery chain. These phases are common to most social protection programs and include assessment, enrollment, provision of benefits and services, and beneficiary operations management.93 As shown in Figure 17, people and institutions interact throughout that delivery chain, and those interactions are facilitated by factors such as technology and data. People’s status changes as they move through the delivery chain from “intended population” to “applicants” or “registrants” to “beneficiaries” once eligibility is confirmed and they are enrolled in a program. Building on that framework, this chapter illustrates the interaction of DSPDS’s component systems at each stage of the delivery chain. A. ASSESS (i) Outreach RECURRING 1 2 3 4 5 6 7 CYCLE 8 9 1 Outreach 92. Developed in the Sourcebook on the Foundations of Social Protection Delivery Systems by Lindert et al. (2020). 93. Because the scope of this Playbook is on non-contributory schemes, this section does not discuss contributory collection in the case of contributory schemes. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 49 CONCEPTUAL FRAMEWORK Social protection delivery systems are facilitated by interactions between people FIGURE 17 and institutions Eligibility Determination Provision of Beneficiaries Exit Decisions, Assessment and of Benefits Notification Benefits Compliance, Notifications Intake & of Needs and Enrollment and Service and and/or Updating and and Case Outreach Registration Conditions Decisions Package Onboarding Services Grievances Outcomes 1 2 3 4 5 6 7 8 9 INTENDED REGISTRANTS REGISTERED ELIGIBLE ENROLLED ENROLLED POPULATION POPULATION POPULATION ELIGIBLE BENEFICIARIES THAT IS APPLICANTS ASSESSED (in) FOR NEEDS & CONDITIONS NON-ENROLLED ELIGIBLE APPLICANTS (waitlist) NON-ELIGIBLE APPLICANTS (out) Key actors (People and Institutions) intermediating along the delivery chain— facilitated by technology, data, and communications among other factors. SOURCE: Author’s adaptation from Lindert et al. (2020). 50 “WHAT MATTERS” GUIDANCE NOTE Outreach is the phase by which people are informed about social protection programs and delivery systems. Through outreach, intended populations become aware of social protection programs and learn about their objectives, rights and obligations, and delivery processes. Outreach is critical for DSPDS because it facilitates understanding, awareness, and access to delivery systems. It can also help foster behavioral changes to correct misinformation or biases affecting the acceptance, rollout, and implementation of social protection programs. Outreach is a stepping-stone leading onto the delivery chain, as it engages people to provide information that will feed the next phase: intake and registration. It also supports other stages in the delivery chain, even if not directly leading to those stages. An outreach strategy defines who to communicate with, what to say, how to say it, and why to say it.94 There are six key elements to developing a communication strategy for DSPDS. First, a situational analysis will provide elements to understand the environment and the internal and external factors that can influence communication, such as sources of support and opposition, risks, public mindset, communication gaps, resources, media landscape, and so forth A situational analysis relies on diagnostics, social assessments or anthropological studies, and stakeholder consultations (Figure 18). The second element of an outreach strategy consists of profiling the audience to ensure relevance and effectiveness in messaging and communication efforts. Outreach strategies vary according to the local context and characteristics of the intended population. As some groups may face specific barriers, tailored and HCD approaches will ensure that the intended population is reached and that the information is adequately conveyed. dSRs can support tailoring outreach strategies based on the profile of registrants. Commonly intended populations can be segmented as follows:95 • Demographic characteristics, for example, children, youth, older people, women. • Socioeconomic status, for example, people living under the poverty line; homeless; people living in isolated and remote areas; pastoralist, nomadic, and semi-nomadic groups; indigenous groups; refugees, stateless, immigrants, internally displaced populations (IDPs); people living in areas affected by fragility, conflict, and violence; ethnic, religious, linguistic, and visible minorities; people prone to economic, climate, and other types of economic shocks. • Labor and work conditions, for example, unemployed, discouraged, or inactive workers; informal workers; forced or child laborers. • Disability status, for example, vision impairment, deaf or hard of hearing, mental health conditions, intellectual disability, physical disability. • Vulnerable individuals facing social risks, for example, children-at-risk, youth-at-risk, adults-at-risk, LGBTQIA+. A clear understanding of the context and the audience will help determine the objectives of outreach for DSPDS, the third key element of an outreach strategy. The main objectives of an outreach strategy for DSPDS and component systems often include the following: • Informing and educating about processes: o How and where can people apply or register for a social protection program, including information about the process, the documents or data needed, and the different registration modalities? o What are the user programs’ eligibility criteria, and how are enrollment decisions made, including the fact that not all people covered by the dSR are necessarily eligible for social protection programs? 94. An outreach plan is a complementary document with detailed and operational guidance on the actions, tasks and resources required to implement the communication strategy. It specifies when, where, and how to communicate with target audiences, what resources and tools to use, and who will be responsible for each activity. 95. See Lindert et al. (2020) for a description of some of the most common challenges for outreach to these groups. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 51 CONCEPTUAL FRAMEWORK o How and when will they be notified of eligibility and enrollment decisions? o How can they verify their application status? o If enrolled, how can they collect their benefits or use services? o How and in what situations can applicants update their information for dynamic inclusion? o How can they unsubscribe? o What are their rights and responsibilities, including the procedures for fraud handling? o How can they file and follow up on a grievance or complaint? How can they appeal the resolution? • Awareness-raising and encouraging participation: o What are the benefits/advantages of registering and using DSPDS component systems such as unique identification systems, dSR, or payments platforms? o As a service provider/stakeholder, what are the benefits/advantages of partnering and collaborating with DSPDS component systems such as unique identification systems, dSR, or payments platforms? • Easing fears and concerns: o What will be the nature of the use of the information collected, and any other relevant data protection considerations? o How accurate or not are some local beliefs about DSPDS component systems? • Crisis management, due to systematic refusal of registration because of technological problems, cases of gender-based violence (GBV) in the field, security issues, road accidents, data security breaches, and so forth. Defining key messages—the fourth element of an outreach strategy—consists of determining the information and ideas that are essential to convey to support outreach objectives. Key messages should be clear, concise, consistent, compelling, culturally sensitive, available in local languages, and politically neutral. They serve as the basis for any communication on the subject: interviews, statements, articles, posters, brochures, and so forth. For instance, India’s Aadhaar sought to present it as an “opportunity not to be missed” as opposed to a “duty that must be done” and as “easy to obtain” and “easy to use” (World Bank 2022b). The fifth element of an outreach strategy consists of choosing appropriate communication channels, taking into account the level of literacy of the audience and their media preferences. An integral outreach strategy is multi-channel, using a mix of modalities, tools, and tactics to deliver key messages to different segments of the audience. The communication mix should take into account the strengths and weaknesses of each channel, the preferences and habits of each segment, and the cost and availability of each tool. Outreach modalities include the following (Figure 18):96 • Direct from program administrators to people through home or community visits, at their premises, or remotely. For example, Tekopora te Acompaña was a digital campaign implemented in Paraguay to push WhatsApp messages to mitigate the effects of COVID-19 and to maintain close contact with beneficiaries and share training material using different formats (for example, text, audio clips, images, and short videos). Local program staff (known as family guides) sent the texts to boost participation and build trust (De Miranda, Heisecke, and Royg 2021). • Via engaged community members, such as community leaders, who pass on the information within their communities. Traditional leaders, typically enjoying great trust and respect, are key allies in sharing information 96. Lindert et al. (2020). 52 “WHAT MATTERS” GUIDANCE NOTE FIGURE 18 Outreach for DSPDS PEOPLE Individuals Families INFORMING Households Com COM ple mu M peo nit UN : to ym I CT tors em T a in E Y- ers t dm DIR r BA o p ist b SE eop D: le TIC sa ASS SO OS ES em EDUCATING S CI MEN Syst GN AL TS DIA OUTREACH S T A SUL CON FI N C E S KE T LE O IE D H AT LD E AU RO Com IO R P NS ple AWARENESS- EASING r p Y: mu RAISING CONCERNS he AR eo IN cati ni D o ot DI IR ns CT E M E to : T ER to pe I N s ce op le ervi S ENCOURAGING PARTICIPATION CRISIS MANAGEMENT SOURCE: Original for this publication. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 53 CONCEPTUAL FRAMEWORK with their community members through village meetings and established structures (for example, farmers’ groups, women’s groups, religious groups) in the local language. • Via intermediaries like program operators, NGOs, health or school workers, and other actors with field presence. • Indirect, including mass communication campaigns and technology-enabled solutions. For example, Brazil’s Notifica gov.br and United Kingdom’s GOV.UK Notify are centralized platforms supporting public agencies that wish to send notifications to users of public services through various channels such as SMS, email, or mobile applications. The final element of an outreach strategy consists of defining a monitoring and evaluation framework to measure the performance of outreach activities and course correct as needed. While Part 6 and Annex 2 of the Playbook provide more elements regarding this aspect, metadata provided by DSPDS component systems (for example, coverage demographics, GRM data, and so forth) can provide valuable input to inform ongoing outreach efforts. Performance metrics should be aligned with outreach objectives and be conducted on a regular and systematic basis. Social protection stakeholders can leverage the information contained in dSR and other component systems of DSPDS to prioritize communication with households and individuals through technology-enabled applications. For example, Togo’s emergency cash transfer program, Novissi, used an Unstructured Supplementary Service Data (USSD) platform to inform pre-identified individuals about their eligibility for the program and the steps to register. Automated phone calling systems can also be used to remind program beneficiaries of key aspects such as how to set up a complaint or how to use their benefits. (ii) Intake and registration RECURRING 1 2 3 4 5 6 7 CYCLE 8 9 2 Intake & Registration Intake and registration is the process by which data and documentation are collected to register intended populations for consideration of potential eligibility. At this stage, data are collected, stored, and updated to subsequently assess needs and conditions and determine program eligibility. In many countries, this stage is supported by social registries. Other countries, however, do not employ social registries at this stage. At its most basic, a social registry provides eligibility information to social programs for enrollment decisions, resulting in the construction of beneficiary registries. Some countries do not record information on all registrants but only on eligible applicants. However, this approach does not allow for assessing the needs and conditions to serve multiple programs with different or evolving eligibility criteria or thresholds. It also limits transparency and social accountability by not keeping track of the decision-making process to support eventual appeals or grievances. In other cases, social registries are developed as modules within BOMS but do not necessarily serve other programs. In contexts where eligibility determination is mainly based on categorical criteria or means testing estimations, social registries may not exist, and their assessment functions can be performed by other information systems. 54 “WHAT MATTERS” GUIDANCE NOTE This is typically the case in high-income countries that heavily rely on administrative data sources for social protection delivery, including central population registries capturing sociodemographic information and, at times, employment status. The advantages of having a social registry are multifold, provided that a robust legal and institutional framework protects the information it contains. Social registries serve as a repository of a wide range of socioeconomic information pertaining to individuals and households. In contrast, administrative data sources often lack the breadth and depth of data that a social registry can provide. This comprehensive approach ensures that the government has a complete and accurate understanding of an individual or household’s needs and conditions, enabling more precise targeting of social benefits and services. By consolidating information into a single, cohesive system, social registries significantly reduce the administrative burden placed on both applicants and government agencies. Furthermore, social registries can contribute to identifying complementarities of benefits and services for registrants who are still out of the social protection system. Administrative data sources often operate in isolation, making it challenging to detect these as such. Regardless of what information system is utilized for the assess stage, complete and accurate understanding of an individual’s or household’s needs and conditions may still require a social worker. Thus, the intake and registration stage involves several functionalities that can be supported by a dSR as follows: With dSR, people can: • Apply to one or more programs on demand by providing the requested information and documents through various intake modalities. • Update data as needs and conditions change over time. • Confirm the status of their application to learn whether it has been received, reviewed, deemed eligible or non-eligible, and more. With dSR, administrators and programs can: • Intake data from multiple sources facilitated by interoperability at different time intervals. • Push data to BOMS for eligibility decisions. • Update data through data exchange protocols. • Validate and verify data as appropriate. • View and manage applicant data. Assistance unit and dynamism A fundamental building block of a dSR is a harmonized data dictionary with a definition of assistance unit and code books for household members and relationships. Who is in the assistance unit—is it an individual or a household? How are individuals related to each other in the household? Where are they located? The codification in the data dictionary defines the logic for creating an assistance unit (Table 2). The basic observation unit of a dSR is an individual who is clustered into a household. dSRs gather information on all persons regardless of their potential program eligibility. Depending on their definition of an assistance unit, some programs can utilize the information from the dSR to prioritize benefits and services at the individual level (for example, scholarships, vaccinations), while others do it at the household level (for example, safety nets, subsidized health regimes). This requires linking an individual to a household, whereby one or many individuals’ Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 55 CONCEPTUAL FRAMEWORK Sample code book for Sample code book TABLE 2 household members for relationships 1—Head of Family 1—Married Sample 2—Spouse 2—Polygamous 3—Mother 3—Married Polygamous codebooks 4—Father 4—Never Married for household 5—Son 5—Living together 6—Daughter 6—Divorced or Separated members and 7—Brother relationships 8—Sister 9—Domestic help SOURCE: Author’s elaboration. unique identifiers are assigned to a household’s unique identifier to obtain up-to-date information on household composition and its needs and conditions. How a “household” is defined is a matter of careful attention since it has vast implications for program delivery. For instance, a household can be a family or a non-family household, and household size is typically a key criterion for eligibility determination and benefit level decisions. Many unique individuals can be a part of one unique household, but they cannot be a part of many households to prevent duplication of benefits. Table 3 presents examples of household definitions in selected countries and the treatment given to specific household arrangements. Where appropriate, recognizing a female “designated recipient” who may or may not be the head of household could support pathways to closing gender gaps in inclusion. To create dynamism in a social registry, incentives need to be developed to capture changes in household composition. While there may be built-in incentives for households to add new members, for example, by birth or marriage, there may be few equivalent incentives (or penalties) for (not) providing proof of life or (not) updating data on members leaving a household voluntarily or in the event of death. In some countries, when existing TABLE 3 Household definitions across the world Country Definition of household Chile 1 A household is a person or group of persons, whether or not linked by a family relationship, who share a common food budget. One or more households may exist at a given address. However, a household cannot occupy more than one dwelling. Türkiye2 A household is a person living alone or a group of persons living at the same address, with or without any kind of kinship. Mexico3 A household is a group of people living together in the same dwelling, whether or not they are related, who share living expenses and prepare food in the same kitchen. India4 A group of persons who normally live together and take their meals from a common kitchen/ common cooking unless the exigencies of work prevent any of them from doing so. • The persons in a household may be related or unrelated or a mix of both. • Migrant workers, expected to come back within six months from date of enumeration, are included as members of the household. • If any female member of a normal household decides or desires to declare herself as a separate household, she is treated as a separate household. Mauritania5 A person or group of persons, whether related or not, living together in the same dwelling and pooling their means to satisfy their essential economic and social needs, food in particular. They generally recognize the authority of one of the members as head of the household. SOURCES: (1) Registro social de hogares (RSH); (2) Turkstat; (3) Cuestionario único de información socioeconómica (CUIS); (4) Socio Economic and Caste Census (SECC); (5) Office National de la Statistique 56 “WHAT MATTERS” GUIDANCE NOTE members die, payments are stopped if there are no withdrawals from the bank account by the beneficiary. However, these cross-checks may not work if the bank account is operated by other household members. Other countries, like Georgia, rely on self-reported information and periodically signed declarations to inform about changes in household composition. Türkiye uses the national addressing and unique household codes system combined with centralized data on vital events, unique identification, and household visits to verify household composition data. The Republic of Korea has developed an integrated social welfare management network with links to the civil registry to track individual ties to families and life events (births, deaths, marriages, divorces, and so forth). In India, Aadhaar manages data on unique identification of individuals, however, the systems to manage data on households, composition, and addressing show significant subnational variation. Intake modalities Intake modalities significantly shape the degree to which the social registry is dynamized. dSRs gather information on individuals and households to populate the data sets that support its core functionalities. The dSR data sets provide “placeholders” that must be “filled” with data from multiple sources and updated at different time intervals. Intaking data from multiple but relevant sources is a key functionality of a dSR to ensure that the information pulled from those sources remains relevant and valid over time, particularly when responding to shocks. To become dynamic, a social registry needs to pull data that have been directly or indirectly collected. Directly collected data refers to modalities whereby households and individuals purposefully provide and upload their information or documents. These modalities can be triggered by either on-demand or administrator-driven initiatives. On-demand approaches allow the assistance unit to take the initiative to apply at a time of their own choosing. By contrast, administrator-driven approaches rely on financing constraints and the capacity of the structure in charge of the dSR to initiate registration, often in groups. On-demand approaches can be used for all types of social protection programs, for one or many programs at a time, and in situations of idiosyncratic or covariate shocks. Administrator-driven approaches are more common for poverty-targeted programs and in response to covariate shocks where everyone in the group intended to be registered faces the same shock. They also tend to be used in fragility and conflict contexts where on-demand approaches are not feasible due to lack of infrastructure. Direct data collection lies along the self-administered to fully assisted spectrum and can be done in-person or remotely, on paper or electronically (Figure 19). People can provide their information remotely, without assistance, through digital service windows, including mobile functionalities (for example, USSD, SMS, computer-assisted telephone interviewing) and technological applications such as websites accessible on tablets, mobile phones, or personal computers. In-person modalities can include permanent or temporary community service centers or local offices, roving agents or mobile teams, household survey sweeps, or in-person interviews in different locations, whereby people provide their information directly to dSR administrators or intermediaries such as program operators, community members, or external partners using paper or electronic application forms. Many existing social registries still rely on door-to-door registration campaigns to gather data on intended populations. Field teams typically go door to door with registration questionnaires for all or most households in a specific region. For instance, in some countries all households in selected regions, provinces, and villages are interviewed and registered (as in Burkina Faso). In other countries, communities prioritize which households are surveyed and registered, with registration quotas sometimes being used (as in Mauritania). In addition to reporting data, people can also upload or provide documentation to support their applications. Nevertheless, excessive documentation requests can increase registration costs and lead to exclusion. Identification plays a crucial role in determining Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 57 CONCEPTUAL FRAMEWORK FIGURE 19 Lorem ipsum dSR zoom-in: data intake PEOPLE modalities DIRECT INTAKE SELF-SERVICE CHEC Digital service window S RAM OG PR TO Community service center View and LY manage Update applicant APP data data Exchange data: Mobile teams, Push to facilitators & agents beneficiary systems/ pull from other systems ASSISTED UPD Manage Outreac Home visits, census sweeps and noti access INDIRECT INTAKE applican AT controls E IN O RM F Admin data sources AT IO N A VALID Non-traditional data sources SOURCE: Original for this publication. the unicity of registrants when they provide their information, be it in-person or remotely, although, pathways to register into a dSR should be provided for individuals without proof of identification (see, for example, the case of Mauritania in Spotlight 1). Whether the intake process satisfies the principle of dynamic inclusion depends on whether the approach is on-demand or administrator-driven. The timetable for intake matters. Can people apply at any time (on demand) according to their own situation? Or do people have to wait several years for the next mass registration wave, as is the case with administrator-driven approaches? On-demand approaches facilitate dynamic inclusion to keep the social registry as updated as possible, while administrator-driven approaches tend to lead to many people not being able to apply at a time of need and having to wait for the next registration drive. With the administrator- driven approach, the doors for inclusion are opened only on a periodic basis (usually every three to five years) rather 58 “WHAT MATTERS” GUIDANCE NOTE than allowing for continuous and dynamic inclusion. The decision to conduct registration less frequently tends to be driven by limited resources for program budgets to finance benefits and services using the information gathered during registration. It can also reflect capacity constraints for carrying out the registration waves, especially the existence of adequate structures or institutional capacity at the local levels to carry out more frequent recurrent processes. However, even opening the doors for all at specific points in time can pose important challenges: while Pakistan and the Philippines covered more than 90 percent of their respective populations through an en masse registration wave, those data became outdated over time and proved difficult to rely upon, particularly during the COVID-19 shock. While the administrator-driven and on-demand approaches are two distinct models, they can coexist and be used strategically to ensure the inclusion of all. Some countries have a fully on-demand approach, such as Türkiye and Chile, and others have a fully administrator-driven approach, such as Burkina Faso, Malawi, and Tanzania. Other cases, however, take a hybrid approach, primarily using administrator-driven approaches with some on-demand elements (for example, Brazil’s Cadastro Único, Pakistan’s National Socioeconomic Registry (NSER), the Republic of Congo’s Social Registry, and Sierra Leone’s SPRINT). Since each approach has its own strengths and shortcomings regarding reach, risks, and budget, complementary approaches are likely to work better to suit people’s varying contexts and state capacity.97 Countries starting to build their own dSR could, for example, administer en masse registration drives or census sweeps and then update data through on-demand approaches (see, for example, the case of Colombia in Spotlight 1). Furthermore, roving agents or temporary registration desks can be rolled out in remote locations at relatively frequent intervals to complement other available on-demand modalities and include populations that would otherwise be excluded in the dSR due to lack of access to digital solutions or fixed community service centers. Digital applications have increasingly become more common after the COVID-19 pandemic. Some steps in the intake process may be facilitated by technology, such as applying online (either initial or full applications), interviewing by phone, scheduling in-person appointments, or answering simple queries via chatbots or USSD service. During the COVID-19 pandemic, countries like Thailand, South Africa, and Brazil leveraged online applications to expand social assistance (Gentilini et al. 2021) and promoted the approach as an alternative to in-person registration processes. For instance, in Chile, the ratio of in-person to digital applications to the RSH-Chile changed from 70/30 before the COVID-19 pandemic to 10/90 in August 2020 (MDSF 2022). However, the extent to which people adopt technology varies across countries. For instance, online applications for job placement services in OECD countries ranged from 2.1 percent of applicants in Slovenia to 24.8 percent in Estonia, 37.5 percent in New Zealand, 95 percent in the Netherlands, 98.5 percent in Canada, and 100 percent in Italy (OECD 2020). Some countries have also introduced initial online self-service applications for social programs, sometimes with simulators to help people decide whether or not to fill out a complete application by determining whether they are likely to be eligible for benefits. Even though they do not involve humans, digital self-service windows can be the “face” of the agency or program for the public. Importantly, digital service windows can be accessible to more narrow audiences based on digital literacy, connectivity, and infrastructure availability, particularly in low- and low-middle-income countries. Regardless of how direct data are collected, they share the commonality that they are questionnaire-based. Information from registrants is collected through questionnaires that gather all necessary information to establish prospective program eligibility. The content of these questionnaires is determined on the basis of social protection 97. A summary of the opportunities, challenges, and prerequisites of different intake modalities is provided in Annex 2 of Barca and Hebbar (2020). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 59 CONCEPTUAL FRAMEWORK policy, which determines the user programs’ eligibility criteria. Questionnaires can have a modular structure whereby depending on the program or people’s responses, an additional set of questions is applicable. As discussed in the next stage of the delivery chain, programs’ eligibility criteria can be a metric (for example, vulnerability, poverty) or based on a set of characteristics that must be considered in the questionnaire design. Notably, the questionnaire design must follow human-centered principles to ensure clarity in the questions, mitigate response biases, and avoid respondent fatigue. People’s informed consent on the use of their personal data are imperative prior to any data collection effort (see the section on Consent in Part 5—Governance). An important aspect of the people interface is the “user experience” and if the point of contact and associated processes are people-centered and service-oriented. People should be able to register for consideration of potential eligibility for social protection programs when in need (particularly after or during a shock or over a longer-term crisis) by updating information on their conditions if their situations change substantially. The people interface is particularly important when developing adaptive social protection systems (Leite et al. 2017). Online systems must be user-friendly. Difficulty navigating the online process may deter people from applying—even if they are potentially eligible. In the United States, for example, a large share of eligible families in some states do not apply for food stamps. One review of low take-up rates in California found that bureaucratic hurdles—including a complicated and confusing online interface—deterred people from applying.98 When data are collected in person, effective interviewing tactics, cultural sensitivity, managing expectations, and technology-assisted interview approaches must be considered as part of the training of enumerators. With on-demand application methods, there is a certain degree of “self-selection” in social registries. Some individuals and families may not take the time to register if they perceive that they are out of range of eligibility for the program(s) that use the social registry. The population share covered by social registries operating with on-demand schemes may be somewhat lower than those that adopt a supply-driven census sweep approach when comparing social registries with nationwide coverage. Self-selection also depends on the narrowness of eligibility criteria for programs using the social registry. Azerbaijan’s VEMTAS only covers 10 percent of the population because it only serves one program with fairly tight eligibility criteria. In contrast, Chile’s RSH has higher coverage, largely because it serves 114 programs, including some that are near-universal. A study in Indonesia showed that on-demand methods resulted in some degree of self-selection by the non-poor, who make up the bulk of the population. Many non-poor opted not to apply, presumably perceiving the time costs of registering were not worth it. The study also found that the on-demand method improved the prioritization outcomes of the program, with a higher likelihood of the poor being registered (Alatas et al. 2016). Furthermore, data can also be collected indirectly without households and individuals providing them directly to the dSR through a purposefully designed questionnaire. dSR can connect to government administrative systems and non-traditional data sources to collect data on households and individuals through interoperability mechanisms with people’s informed consent. Data can be pulled from administrative systems such as tax records, property registries, and farmer registries,99 among others, to pre-fill application forms, supplement self-reported information provided by registrants, or for verification purposes. Similarly, data can be pulled from other non-traditional sources produced by commercial firms or governments for different purposes than welfare determination. Hybrid approaches, whereby directly and indirectly collected data are combined, can decrease the overall costs of keeping a dSR up to date and lead to a more accurate and fairer prioritization of policies. 98. Presentation to World Bank on Human Centered Design (Solomon 2017). 99. See Barca et al. (2023) for a detailed discussion on the data contained in these systems and how they can contribute to social protection. 60 “WHAT MATTERS” GUIDANCE NOTE However, integrating multiple sources of information requires robust unique identification platforms that enable interoperability between systems and ensure universal coverage, as well as data harmonization across sources. Dynamism through data updates Up-to-date information is necessary for dynamic inclusion and better planning. Outdated or static information on socioeconomic status can lead to inaccuracies in eligibility determination and calculation of benefit levels. The sociodemographic and socioeconomic conditions of individuals and households can change in many ways in terms of their household size and composition (births, deaths, marriages, divorces), address and location (moving residence, internal or external migration, displacement), economic situation due to changes in income (lost wages, illness or disability, promotions, changes in pension or other benefits, changes in unearned income), in employment status (job loss, newly employed, changes in employment, seasonal work), education (new degree or professional certification, school enrollment), health events, expenses, housing, assets, and other shocks. By keeping data updated, administrators can reassess needs and conditions100 of applicants to determine eligibility as their situations change and manage beneficiary operations effectively by supporting the implementation of exit decisions. Current data are also crucial for designing effective social policies, allocating resources efficiently, emergency preparedness, and policy evaluation and monitoring. The frequency of updating depends on the type of information contained in a dSR. How quickly data from social registries become outdated has vast implications for prioritizing benefits and services. The rate of decay of the validity of data can be influenced by multiple factors, including labor market dynamics, trends in growth and poverty, and environmental factors (Gelders 2021). Not all information requires updating—some variables remain mostly constant over time (for example, date or place of birth, name), barring corrections to the initial data. However, simulations in Bangladesh estimate that 15 percent of households change their composition within the first year of data collection, 36 percent by the end of year three, and 49 percent by the end of year five (Gelders 2021). The same study finds that 8 percent of households moved along the welfare distribution within the first year, 15 percent moved by year three, and 35 percent moved by year five. The frequency of updates is also impacted by where the information for each variable comes from, whether it is self-reported or obtained through data exchange with other administrative systems (Leite et al. 2017). In on-demand systems, households may be required to update their information as it changes to avoid penalties (for example, United States, Australia) or to be reassessed for eligibility based on a pre-determined expiration period (for example, Brazil, Türkiye, United States). Importantly, people need to know what is expected of them in terms of the frequency of updates, data and documentation required, the consequences of not updating their information, and how and where to do it (see the Outreach section above). Administrator-driven systems that rely on periodic “census sweeps” for updates face important limitations due to the lack of incentives and easiness for households to report changes in the interim years. Data updates through administrative systems and non-traditional sources can have varying periodicity for updates depending on the periodicity with which external information systems are updated and interoperability capabilities. Information on employment status or receipt of benefits typically changes monthly, payments of utility bills sometimes change bi-monthly, social security contributions usually change quarterly, tax information typically changes once a year, and property ownership changes sporadically. Capabilities for interoperability and data exchange are discussed below and in more detail in Part 4. 100. The literature and common practice distinguish between “updating” of demographic information and “recertification” of socioeconomic information. We focus on the different frequencies, periodicity, and sources of updating for different types of variables and on the “reassessment” of needs and conditions by the social registry without getting into certifying enrollment decisions, which can depend on other factors and is the prerogative of user programs (as discussed below). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 61 CONCEPTUAL FRAMEWORK Dynamism through data exchange Interoperability allows for a dSR to communicate and exchange data with other administrative systems and non-traditional data sources. The applicant needs to be uniquely identified across systems to enable data to be linked and technology, data, and process standards must be set to ensure interoperability. For instance, addressing issues from data conflicts between information systems requires predefined protocols. In some countries, the software application will display red flags or warning messages signaling the need for verification, updating, or rectification. These messages are then cross-checked with individuals in-person when they contact the social worker, mobile teams, service center, or other frontline staff, or remotely when they login to their dSR session or through mobile phone applications (for example, USSD). For example, Pakistan has piloted in-person verification mechanisms. In Türkiye, the system alerts administrators when there are data conflicts using a task list with action items. Chile has defined an order of priority to the different data sources that can be used to compute household’s socioeconomic score. A dSR may interoperate with standalone systems that manage benefits delivery for a social program (BOMS) and/or databases integrating data from various benefits delivery programs (IBR) for further program-specific eligibility determination. Program eligibility decisions can be a function of enrollment into other programs: either as an exclusionary filter (to avoid duplication) or as an eligibility criterion (for intervention packages). In Malawi, the Social Cash Transfer Program (SCTP) and the Public Works Program (PWP) access data in the social registry (called UBR) on households and their PMT scores to create potential beneficiary lists, which are then validated through community meetings, following which a final set of beneficiaries are enrolled in the program. A whole-of-government approach for permissioned data sharing across authorities and programs allows for dynamic inclusion, enhanced data quality, improved efficiency, and greater integrity, as well as heightened and harmonized data protection and privacy. Such an approach requires a robust data exchange protocol that can facilitate cross-agency sharing of the most current information updates captured from people through frontline agencies, such as health facilities, schools, and service centers for registering property, land, vehicles, and businesses. Real-time interoperability between dSR and other administrative systems can help to detect data with the most current timestamp. Dynamic data have a time dimension, or a numerical value, and refers to one or more reference data objects.101 They change as a result of an event (or a transaction), and therefore the individual or the household’s needs and conditions change (for example, life events such as birth, marriage, and death, health conditions, or employment status). However, it may not always be feasible to develop real-time connections between a dSR and other administrative systems due to issues of performance and latency. Some data are static or fixed and rarely change after they are recorded, while other kinds of data change infrequently and do not need to be updated using real-time interoperability protocols. Accordingly, institutions may agree on a periodic schedule for data exchange, where data are sourced through a batch data transfer. Some kinds of changes in data may be unanticipated, such as purchase of property, vehicles, or other assets, and these will need to be recorded as soon as the event occurs. Other kinds of changes in data may be anticipated on a regular schedule, such as utility bills, school attendance, or the like. In these cases, agencies may agree on a regular schedule of data exchange such as a nightly, a fortnightly, or a monthly batch exchange (see Part 4). 101. In the context of data management, reference data are a list of permissible values used by master data or transactions data. They are often defined by standards organizations such as ISO. For example, units of measure, country codes, and so forth are a single source of common business data that are agreed on and shared across an organization, and are used across multiple systems, applications and processes. For social programs, examples of master data include data on people (individuals, families, households), social programs (cash transfers, food), and so forth. 62 “WHAT MATTERS” GUIDANCE NOTE Interorganizational data exchange protocols are typically based on an interoperability framework defined at the country or broader regional level. Estonia designed a data exchange layer for whole-of-government through X-Road (Republic of Estonia 2011). The objective is to allow people, businesses, and government entities to securely exchange data and access information maintained in various agencies’ databases, based on the principle that “The State shall not request from citizens and businesses any data that are already in its possession.” For example, applying for a categorical parental benefit is an e-Service that does not require submitting supporting documents. The different certificates and documents required are generated automatically by the e-Service (a distributed software) using various agencies’ databases to collect information about the applicant (Kalja, Reitsakas, and Saard 2005). Nonetheless, data exchange protocols do not negate the need for self-reported information from people registering for social benefits and services, at least in the form of an application or claim to express need. Even in Estonia, the minimum income guarantee benefit requires submission of an application, documentation of property and movable assets, and demonstration that, after paying housing expenses, households or individuals would not be able to cover basic subsistence needs. Data validation and verification While the specifics vary, registration processes must include applying quality controls to the data and consolidating and storing the revised dataset. Quality controls may include validating data to ensure that the information is complete and consistent and verifying data to confirm that they match those provided by other government agencies or programs (this step may involve cross-checking the applicant’s information with other data sources, documents, community validation, audits, supervisor reviews, and/or spot checks). Data are consolidated and stored, often with further steps to improve quality, such as deduplication of records facilitated by unique identifiers. (iii) Assessment of needs and conditions RECURRING 1 2 3 4 5 6 7 CYCLE 8 9 3 Assessment of Needs and Conditions Assessing needs and conditions involves systematic processes for analyzing data of registered individuals or households to determine potential eligibility for specific programs. Once they are complete, verified, and validated, data from intake and registration are used to assess needs and conditions. These data are processed and analyzed through various instruments and techniques to profile the needs and conditions of registrants to later prioritize among them and determine their potential eligibility for specific benefits or services. This task can be undertaken by the dSR through a back-office analytical functionality that produces a set of outcome variables for each registrant based on one or multiple predefined assessment methodologies. Outcome variables can be an index, a category, a score, or any other type of indicator that allows for assessing the needs and conditions of each applicant. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 63 CONCEPTUAL FRAMEWORK Categorical These methods rely on “easy to observe” characteristics and assume that needs are relatively TABLE 4 methods homogeneous among the group. The most common approaches are: • Geographic. Programs select their potentially eligible population based on a set of Common geographic characteristics and/or spatial analysis indicators. approaches • Demographic.* Programs select their potentially eligible population based on their demographic characteristics (sex, age, civil status, ethnicity, and so forth). to assessing Welfare These methods estimate welfare using income, consumption, vulnerability, and/or asset data. needs and assessment The most common approaches are: conditions methodologies • Means-testing (MT). An applicant’s welfare is calculated and/or verified through administrative data sources. • Hybrid means testing (HMT). Part of an applicant’s welfare is calculated and/or verified through administrative data sources, and the rest is imputed or predicted. • Proxy-means testing (PMT). An applicant’s welfare is predicted based on observable socioeconomic characteristics, usually collected through direct intake modalities. • Multidimensional poverty measurement. This method pinpoints overlapping deprivations across multiple dimensions of wellbeing to complement purely monetary measures. • Community-based targeting (CBT).* Community leaders or members use information known to them from day-to-day living in the community to guide or choose who should be in or out of the program. • Poverty scorecards.* A small set of indicators highly correlated with the likelihood of being poor are selected based on a logit regression. The coefficients are then transformed into points in a scorecard which is filled in by field agents. Other methods • Public lottery.* An over-subscribed program randomly rations spaces among eligible applicants. • Self-declared.* Programs have explicit design features to promote differential take-up across the population (for example, public works programs paying low wages for short periods). * These methods are not data, inference, and systems-intensive and thus will not be further discussed in this section. Source: Author’s elaboration, adapted from Grosh et al. 2022 A dSR can use one or multiple methods to assess needs and conditions at the applicant level through its analytical tools. The most common assessment approaches to assess potential eligibility include categorical methods and welfare assessment methodologies. Table 4 presents a non-exhaustive summary of some of the main approaches to assess needs and conditions. The choice of welfare assessments methods for a dSR must respond to the objectives set ex ante at the policy level and to the needs of its user programs.102 Also, the welfare assessment methods discussed below are not mutually exclusive and can be combined. While these methods are commonly used across countries, this section provides a snapshot of data, inference, and systems-intensive methods and discusses how the information is processed and transformed within a dSR. It also brings forward some considerations over traditional data sources and big data in the context of the assessment of needs and conditions. This subsection is heavily based on Grosh et al. (2022). Geographic targeting methods Geographic targeting methods cluster households based on characteristics of their location. Unlike other methods, geographic targeting by itself is not disaggregated at the household or individual levels. In its purest form, geographic targeting selects areas where the program will distribute benefits or services. This approach can be 102. Policy makers usually take into consideration factors such as high-level objectives, desired outcomes, patterns of gaps in those outcomes across the population, resources, and the political economy to determine the population of focus for a given social program. Each targeting mechanism has its strengths and limitations. A thorough review of targeting approaches can be found in Grosh et al. (2022). 64 “WHAT MATTERS” GUIDANCE NOTE highly pertinent to respond to natural disasters or shocks specific to a location. For instance, countries like Kenya and the Dominican Republic have incorporated hazard risk data into their social registries for preventive shock response (see Annex 1 on potential synergies between DSPDS and disaster risk information systems). Other variants of geographic targeting use spatial analyses to match areas to welfare outcomes and potential risks.103 Poverty maps have been widely used in social protection to identify poverty clusters in highly disaggregated geographical units. Many of these analyses have relied on traditional data sources such as census and survey data to map patterns of poverty and inequality within countries. Typically, poverty maps combine detailed information from a household survey to measure welfare with national census data (or another sizeable national survey). For instance, Bedi and Coudouel (2007) compute household consumption using multiple regression analysis and census data and extrapolate those estimates to produce small-area poverty estimates. However, in the absence of comprehensive, accurate, and up-to-date data in most low-income countries, recent work has revealed how non-traditional data sources can produce highly accurate and granular poverty and spatial estimations of wealth. Although the risks of using big data in social protection remain to be studied in depth (Box 2), a recent—and growing—body of research has examined the potential of big data to generate poverty estimates, particularly in contexts with outdated or limited data. These approaches commonly use machine learning algorithms to estimate welfare at the local level. Recent studies have examined how trained algorithms can create highly accurate village- and year-specific wealth estimates for various African countries using survey data combined with daytime and nighttime images (Jean et al. 2016; Yeh et al. 2020). Other studies have analyzed social media data for poverty-based targeting. Fatehkia et al. (2020) evaluated the value-added of combining publicly accessible, anonymous advertising data from Facebook with satellite imagery to create poverty maps. They found that social media data improved socioeconomic mapping in urban locations within the Philippines. Kashyap et al. (2020) used aggregate data from Google and Facebook’s advertising platforms to measure gender inequality. More recently, Chi et al. (2021) used geospatial satellite, connectivity, demographic, and geographic data to predict asset-based wealth for 135 low- and middle-income countries. Big data can also improve early warning systems (EWS) for more responsive social protection systems. Although this stream is still underdeveloped in the field of social protection, earlier work on human mobility using aggregate mobile phone data has assisted in modeling the geographic spread of epidemics (Bengtsson et al. 2015; Tizzoni et al. 2014). Moreover, water flow forecasts in Bangladesh have been used to predict the onset of an extreme flood event and trigger transfers to households a few days before the flooding (Pople et al. 2021). Spatial analyses can be embedded within DSPDS to automatically produce poverty-based geographic assessments. While the underlying models are usually highly sophisticated and require strong technical capacities, data analytics platforms and GIS within DSPDS can reproduce predefined algorithms and associate spatial outcomes to each applicant based on their location. They could also produce high-resolution poverty maps to facilitate critical policy decisions and monitor the evolution of wealth and poverty. Welfare assessment methodologies Many programs employ one or multiple welfare criteria to assess needs and conditions and to prioritize vulnerable and poor populations for benefits and services. Registrants falling below a welfare threshold are potentially eligible to receive a program’s benefits. With the information gathered during intake and registration, 103. In addition to applications to targeting, spatial analysis can also help plan, monitor, and evaluate programs. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 65 CONCEPTUAL FRAMEWORK indicators of aggregate welfare are calculated by automated algorithms built into dSR. These algorithms typically assess income, consumption, assets, or food insecurity to generate an aggregate welfare index or estimate at the individual or household level. In those instances where artificial intelligence (AI) tools are relied upon, careful attention is needed—as part of good governance—to make sure that regulatory guardrails are implemented; such is especially true where risks are particularly high. Data can be verifiable against independent sources, self-reported, imputed, or obtained within the community. A non-exhaustive list of welfare assessment methodologies commonly used include means-testing (MT), hybrid means-testing (HMT), proxy means-testing (PMT), multidimensional poverty measures, community-based targeting (CBT), and poverty scorecards, among others (Table 4). Below, the underlying estimation methods, data needs, and limitations of the first four approaches which are data, inference, and systems-intensive are discussed. Means-testing (MT) methods Means-testing (MT) measures welfare through observable and verifiable administrative records on incomes and assets. This method is commonly used in highly formalized economies and can achieve relatively high accuracy by pulling data largely from existing administrative systems. Welfare can be measured as the sum of incomes and assets of the assistance unit members. In some cases, data are self-reported by the registrant during intake and registration and verified against administrative records. In other cases, data are directly pulled from public services information systems. Typically, data on income include formal wages, pensions, income from social protection programs, and not-earned income (such as rents, dividends, court-ordered alimony, or child support). Assets, in turn, can be used to measure the wealth of an assistance unit (wealth index approach) or as grounds for declaring a household ineligible (asset filter approach). The subset of incomes and assets should be informed by empirical analysis. Small, unrecorded, or irregular incomes, as well as household production for own consumption, are usually excluded from a program’s definition of income. Such sources of income are generally difficult to estimate and verify and often vary depending on the moment of measurement. Accounting for them may raise administrative costs and transaction costs for applicants without necessarily producing reliable gains. An empirical analysis may elucidate whether these informal income sources are too large, meaning that other methods to assess needs and conditions may be more appropriate. It could alternatively help to determine if the share of hard-to-verify income is relatively small and grows monotonically with formal income so that ranking based on a verifiable income provides a good approximation and MT is appropriate. Moreover, assets can effectively improve the focus on poverty and reduce inclusion errors. However, if not well calibrated, this approach can lead to exclusion errors, reducing the program’s effectiveness. Representative survey data can provide valuable information about household income and asset ownership and value in order to set adequate criteria. An advantage of MT is that it detects changes in welfare reasonably quickly, better protecting those vulnerable after a shock and adjusting benefit levels accordingly. MT must be designed considering the many sources of welfare volatility. When administrative data sources are updated at frequent intervals, MT methods can rapidly ascertain changes in welfare (see the Intake and registration section). This allows households and individuals to apply for benefits and services any time their income falls or their stock of assets shrinks. Shorter recall periods allow families and individuals to become eligible for public support more swiftly after a shock like unemployment, loss of housing, or reduction of productive assets. This feature can also enable frequent reassessments of needs and conditions in order to minimize targeting errors and maintain a program’s adaptability. It can also support programs operating large arrays of benefit formulae to differentiate the benefit level given an applicant’s evolving needs and conditions. 66 “WHAT MATTERS” GUIDANCE NOTE Several factors are crucial for the success of MT. MT requires significant investments for data management and a high degree of interoperability and integration between the various information systems involved to allow for welfare verification. Notably (from Grosh et al. 2022): • The existing databases provide complete information on the income and assets of the target group and have coverage for the entire population to ensure that MT reaches the bottom income deciles. As administrative records have large coverage, and no underreporting or biases, MT will tend to have little to no inclusion or exclusion error. • A unique identifier is available in all information systems for cross-verification, interoperability, and integration. Alternatively, an algorithm to match individual characteristics such as name, age, sex, address, or GPS coordinates must be implemented; however, in this case, the match will likely have some error. • All information systems can communicate, which entails the harmonization of technology, language, and coding. • Regulatory frameworks and protocols for data sharing and privacy and confidentiality of information are in place. • Intake and registration automatically trigger the assessment of needs and conditions. With improvements in technology, digitization, and e-governance, MT has become increasingly feasible—to different extents—in many highly informal economies. In highly informal economies, MT is likely to exclude the poorest, who tend to be more involved in informal, untraceable activities. However, MT can be employed in these contexts to rule out the wealthiest—who are more likely to appear on formal records. As technology improves and systems become more interoperable, more countries are meeting the minimum conditions to transition to MT prioritization, at least partially and in combination with other welfare assessment methods. An example is Chile, where the launch of the Social Household Registry (Registro Social de Hogares, RSH) marked a shift from PMT targeting to MT (Spotlight 2). Chile’s RSH integrates data from 48 programs and interoperates with the civil registry and 399 information systems from other ministries and municipalities, facilitating data collection on informal income, occupation, housing, education, health, and family composition. Similarly, Brazil implements MT using self-reported income data that are cross-checked against administrative records. Hybrid means-testing (HMT) methods Hybrid means-testing (HMT) assesses registrants’ welfare by predicting informal income based on verifiable or representative information. When only part of an applicant’s income and assets can be observed and verified against independent sources, programs can impute the remainder using HMT. This assessment tool is relevant for countries with moderate informality and well-developed information on formal incomes. HMT takes advantage of administrative records available from the formal sector and imputes informal income through different techniques. The context of each country largely determines the imputation method and values imputed, which could also vary within regions to account for the local context. Under predefined specific rules, the predicted values of informal income can be calculated using administrative data sources, household surveys, labor force surveys, individual interviews, or qualitative research. Given that total welfare is not observable or verifiable, HMT can estimate it with some modeling error. HMT has been mainly implemented in Europe and Central Asia, where most informal employment occurs in the agricultural and construction sectors. Acknowledging that these incomes are challenging to measure, practical approaches were developed to estimate them based on asset ownership, predicted returns, or average earnings. When the assessment relies on asset ownership, land, and livestock, administrative records are usually employed Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 67 CONCEPTUAL FRAMEWORK for verification, while potential returns and average earnings are predicted with survey data. For example, Albania imputes agricultural income using revenue coefficients that vary according to the type of land, livestock, and geographical zone. Similarly, the Kyrgyz Republic predicts agricultural income using revenue coefficients that vary by location and type of land. At the same time, the possession of livestock (when it exceeds a predefined program threshold) works as an exclusionary filter. Instead of estimating current agricultural income, Romania calculates the potential returns to land and livestock using agricultural registries and small farm holdings survey data. With these data, the country defines a set of coefficients to estimate gross annual margins for different types of harvests or livestock. Hard-to-verify income from seasonal work in Albania, Romania, and Uzbekistan is imputed for a given number of days per month during the agricultural season at local market wages. Other sources of informal income can be predicted using average earnings observed for an occupation, sector, region, gender, or age group. When setting up these imputation rules, program procedures must allow adjustments in case of unexpected events or calibration errors (see MT discussion, above). The accuracy of HMT to assess needs and conditions depends on three key features. First, data from verifiable sources, such as asset information and formal income, are updated on a frequent and timely basis and, have high quality, and interoperate with other key information systems, such as payment systems or tax records, under robust data protection and privacy frameworks. Second, a vast majority of households earn easy-to-verify income, at least in part. In other words, only a small share of households earns exclusively hard-to-verify income. When this is not the case, other targeting methods, such as PMT, may be more appropriate. Third, most informal sources of income are concentrated in a few economic sectors with relatively low variation in earnings per worker. Proxy-means testing (PMT) methods Proxy means-testing (PMT) uses statistical methods to predict welfare. PMT is a widespread targeting mechanism used in countries with large shares of informality and where MT or HMT are not feasible because income or consumption are difficult to measure or observe. This approach estimates welfare—income, poverty, consumption, or other metrics—through predictive parametric or non-parametric statistical models. PMT exploits observable data such as household, community, and regional characteristics (explanatory variables or covariates) that are not verifiable against existing administrative records. This information has been traditionally retrieved from surveys (household surveys, census sweeps), social registries, and, more recently, from “big data” sources. The models allow estimating a weight or a coefficient for each determinant of welfare. These predicted estimates are then applied to the information provided by the applicant at the intake and registration stage to determine their welfare level. PMT is purely an inference-based method. Due to this, PMT is prone to statistical errors and is considered more complex and less transparent than other welfare assessment methods. Ensuring that PMT adequately predicts welfare depends mainly on the model specification. A good PMT model is characterized by having good predictive power—above explanatory power—especially for groups of applicants that are of particular interest to social protection policy. Both the choice of the model and the set of explanatory variables are key to achieving such predictive power. Using too many covariates can result in over-fitting, meaning that the model can predict the survey data well but not do so with new data. Meanwhile, too few covariates may result in an underspecified model, thus producing biased estimates. Finding the right combination of covariates requires exploratory data analysis and considering pre-existing knowledge, such as official poverty assessments, previous studies, and even local observation. Moreover, many countries develop multiple regional models to account for regional variations. The statistical methods employed in PMT are multifold. Traditional approaches to PMT include principal components analysis, logit and probit regression models, ordinary least squares, generalized 68 “WHAT MATTERS” GUIDANCE NOTE least squares, quantile regression models, and variations of these (for example, fixed effects, weighted least squares, truncated regressions). More recently, some programs have incorporated machine learning algorithms into PMT assessment. Such optimization algorithms use parametric or non-parametric models (for example, robust models, penalized regressions, non-linear models, tree-based models) applied to both traditional survey data and big data sources. Another factor impacting the accuracy of PMT targeting is the ability to update the model in a timely manner. Assessing the targeting performance and revisiting the PMT model periodically will allow accounting for changes in welfare distribution and welfare determinants and correcting modeling errors due to past modeling limitations. However, these potential adaptations are likely to have significant implications for program delivery and the political economy. Namely, the new model may require modifications to the intake questionnaire and data collection logistics, while the updated PMT weights may lead to some current beneficiaries losing their benefits while others may need to be included. PMT’s two main pitfalls are data restrictions and a limited ability to predict vulnerability to shocks. On the one hand, good PMT assessments rely on periodic, unbiased data. Nevertheless, many developing countries have significant gaps in-between household surveys, affecting the quality of PMT models as poverty predictors are likely to have changed. Small sample sizes and sampling design deficits also affect the model’s accuracy due to limited variability to capture within-cluster and between populations differences. Machine learning models could benefit from the dynamic nature of social registries and may improve the performance of PMT by incorporating new information. On the other hand, the chronic poor are often more vulnerable to shocks and less able to cope with them. PMT models are usually not designed to identify households after they suffer a shock; however, historical data on shocks, such as climate events, could be used to predict at-risk households. PMT assessments using big data are paving the way for social delivery in countries lacking recent and comprehensive data on household income and wealth. In response to the COVID-19 crisis, the government of Togo launched an emergency cash assistance program (Novissi) to support nearly 920,000 informal workers (Lawson et al. 2023). After identifying the poorest villages and neighborhoods using satellite imagery and nationally representative household consumption data, trained algorithms prioritized aid to the poorest mobile subscribers based on CDR. Relative to the geographic targeting options the government of Togo considered at the time, the machine learning algorithm using big data reduced the exclusion error by 4 to 21 percent (Aiken et al. 2021). With this approach, the government was able to quickly address the shock in the absence of up-to-date data. However, as previously discussed, more research is still needed to deal with the caveats associated with big data and machine learning algorithms. Multidimensional poverty measures Multidimensional measures of poverty can also be applied to prioritize social benefits and services. Multidimensional poverty indexes (MPI) recognize the existence of non-monetary dimensions associated with applicants’ living conditions, beyond purely monetary measures obtained through MT, HMT, or PMT. MPI identify “deprivations” of basic rights and/or essential needs (dimensions), typically covering education, health, food security, and housing conditions, among others. Each dimension is measured through a set of highly context- specific indicators. Latin America has been a pioneer in the implementation of MPI to measure national poverty, prioritize social assistance, and evaluate public policies, most notably Mexico, which was the first country to legally adopt MPI in 2004 (Figure 20). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 69 CONCEPTUAL FRAMEWORK FIGURE 20 Methodology for the measurement of multidimensional poverty in Mexico SOCIAL DEPRIVATION (DIMENSIONS) SOCIAL PUBLIC FOOD EDUCATION HEALTH SECURITY HOUSING SERVICES SECURITY Vulnerable due Not to social poor or deprivations vulnerable Aged 3 to 21 Not Not affiliated The floor Water is obtained Is moderately and not in registered to the material is from a well, river, or severely POVERTY compulsory for public contributory earthen, or the lake, stream, or food insecure, LINE education or medical social security roof is made pipe, or running or has not attending services, system or 65 of cardboard water is obtained limited food a formal including years of age or garbage, or by carrying it from consumption Moderately educational health or older and the walls are another dwelling, according poor institution, coverage, not receiving made of mud, or from a public to the WFP Vulnerable or aged 22 or private a contributory reed, bamboo, tap or standpipe; method. EXTREME due to or older medical or non- palm, metal, or there is no POVERTY income and has not services. contributory asbestos, drainage service LINE Extreme completed pension. cardboard or or the drainage the current garbage, or the is connected to a poor compulsory ratio of people pipe that empties education per room into a river, lake, (currently (overcrowding) sea, ravine or 6 5 4 3 2 1 0 high school). is greater than crevice; or there 2.5 is no electricity, or the fuel used for cooking or heating SOCIAL DEPRIVATION food is wood or coal, without a chimney INDICATORS OF VULNERABILITY SOURCE: Authors, adapted from CONEVAL (2022). 70 “WHAT MATTERS” GUIDANCE NOTE SPOTLIGHT 2 EVOLUTION OF WELFARE ASSESSMENT IN CHILE Since the 1980s, Chile has implemented various targeting instruments to prioritize social benefits and services. The Ficha CAS (Social Assistance Committee) was in force until 1990, then came the Ficha CAS2 until 2007, the Ficha de Protección Social (FPS) until 2015, and the Registro Social de Hogares (RSH) as of January 2016. The Ficha CAS classified households along five levels using an unsatisfied basic needs approach along the dimensions of education, housing, and income. The instrument was administered to household heads or spouses in a municipal office that kept manual records and issued a certification of the index assigned to each household. Although the Ficha CAS2 maintained the same methodological approach as its predecessor, it incorporated relevant improvements, including (i) a more comprehensive questionnaire; (ii) administration of the questionnaire at home, thus allowing the verification of housing conditions; (iii) assignment of a specific score to each family, even when they shared a house; and (iv) establishment of a two-year validity of the score. Each municipality managed a database with all surveyed households’ data. This information was transferred annually to the central administrator (that is, the Ministry of Planning) to be consolidated in a single national database. The FPS responded to the need to update targeting parameters, given persistent complaints about the performance of the Ficha CAS2 both from people and user programs and in order to prioritize households that were more likely to be affected by income risks. Thus, the FPS changed the methodological approach from unsatisfied basic needs to vulnerability. An Income Generating Capacity (IGC) score was calculated for each household to reflect its socioeconomic vulnerability. It considered variables such as education, occupation, gender, ethnicity, geographic location, disability, and household composition. The information was self-reported to municipality workers who could request documentation to corroborate data. The score was updated every time data were modified—be it through self-reporting, supervision, or administrative data. The FPS information system was able to exchange data with some administrative systems. For example, it eliminated duplicates by allowing only one record per individual based on the national identity number (RUN) validated online against civil registry records. Moreover, the FPS included cross-checks with contributory and non-contributory pensions data to verify these types of income. Before its end, the FPS registered over 12 million people and served 80 user programs. The FPS was a self-declaration instrument with no control over the information provided, creating significant incentives to misreport or falsify data in order to be, or continue being, eligible for programs. Although the regulation considered sanctions for reporting wrong information, its enforcement was limited or null (Álvarez and Aillañir 2018). As a response, in 2010, an expert commission developed a series of recommendations that would ultimately lead to the creation of the RSH to privilege the use of administrative data in order to reduce the burden on people and improve the quality and accuracy of the information. (Continued next page) Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 71 CONCEPTUAL FRAMEWORK Spotlight 2 (continued) The RSH introduced a socioeconomic score (CSE) to assess the needs and conditions of registrants. The CSE infers income and assigns households to one of seven vulnerability brackets. The first bracket groups households that fall within the 40 percent most socioeconomically vulnerable, while the other six correspond to the top 60 percent, divided into groups of 10 percent each. The thresholds of each bracket are defined using data from the latest available national household survey (Casen). The ranking is a function of the sum of household income (using the last 12 months as the period of reference), corrected by a needs index that recognizes the ability of households to generate economies of scale and/ or greater spending needs due to household members’ age or disability. Income data come mainly from administrative records, but the household’s self-reported income is considered if no records are found (for example, informal workers). An additional adjustment is applied to review the coherence between the observed income and the socioeconomic level inferred from access to specific goods or services, including vehicles, real estate, school tuition, and private health insurance. Through a web application, people can access the “Cartola Hogar” which summarizes the information used to estimate the CSE. As shown in the figure below, the document contains the household address, household member information including their identity number, name, relationship to household head and level of dependency, monthly household income, CSE bracket, and any complementary information influencing the household’s classification. Household head’s name Household head’s unique iden�fica�on number Household’s socioeconomic scoring (bracket) Address Household roster including unique iden�fica�on number for each member, name, and rela�onship to household head Characteris�cs of household members (under 18 years old, 60 years old or more, and dependency or disability) Household income range, including labor income, pension income, and capital income in the last 12 months Supplementary informa�on that may influence household’s Reminder that keeping socioeconomic scoring informa�on up to date is the responsibility of the household and that data can be updated online or at the municipality office Grievance redress (complaints and appeals) intake channels SOURCES: Ministerio de Desarrollo Social and World Bank (2018) and Registro Social de Hogares. 72 “WHAT MATTERS” GUIDANCE NOTE B. ENROLL (iv) Eligibility and enrollment decisions RECURRING 1 2 3 4 5 6 7 CYCLE 8 9 4 Eligibility and Enrollment Decisions Determine eligibility Eligibility refers to determining which applicants qualify for a program. Eligibility determination involves comparing a registrant’s needs and conditions to eligibility criteria from a specific program. Based on a program’s operating rules or manuals, eligibility criteria are specified by each program and can be recorded in a program inventory. Eligibility criteria are cross-referenced against applicant’s profiles to verify whether they meet the program’s qualification requirements. This cross-check can be done by the dSR. The primary inputs for this process derive from the assessment of needs and conditions and program eligibility criteria. The output from the eligibility determination process consists of the potential beneficiary universe of a program, which is transferred to program administrators to make enrollment decisions. Social programs usually establish formal eligibility rules based on geographic, demographic, or welfare benchmarks. These rules have a direct influence on the information that needs to be collected at the intake and registration stage. Most programs use a combination of such rules to determine eligibility and apply what is also known as multi-stage targeting. For example, Brazil combines geographic targeting to determine caseload quotas by municipality with MT. Senegal implements a three-stage approach by first setting up geographic quotas, then identifying potential beneficiaries through CBT, and finally applying PMT to those pre-selected by the community. Programs using welfare criteria to determine eligibility use as an input the welfare estimates issued at the assessment of needs and conditions and compare them to a given threshold. Some programs opt to establish different entry and exit thresholds, considering that social benefits and services may have directly impacted welfare but would not necessarily imply higher autonomous incomes. In other cases, differentiated thresholds can be applied to determine differentiated benefit package levels or account for regional variations. Thresholds can be absolute, relative, or filters: • Absolute thresholds. A registrant is eligible if their welfare falls below a certain level. Absolute thresholds can be set as a specific level of income, as an income range, or as an absolute cutoff. The eligibility status of an applicant is independent of the status of other applicants. • Relative thresholds. In contrast to absolute thresholds, a registrant’s eligibility is determined as a function of the eligibility of others. Applicants are ranked from poorest to wealthiest. Only a pre-determined percentage of them are deemed eligible. This type of arrangement is incompatible with on-demand approaches given that if an applicant is not registered at a specific time, they cannot be part of the program because the quota has been filled. Relative thresholds are also prone to exclusion errors if poor households are inadvertently excluded during the initial registration wave. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 73 CONCEPTUAL FRAMEWORK • Exclusionary filters. Filters are used to exclude households based on their apparent wealth. Most often, asset filters are applied to exclude applicants from eligibility regardless of other criteria. Asset filters may consider ownership of vehicles, secondary homes, luxury durable goods, among others. While filters can effectively improve the focus on poverty and reduce inclusion errors, they can, if not well-calibrated, lead to exclusion errors, reducing the program’s effectiveness. Representative survey data can provide valuable information about household welfare and asset ownership and value in order to set adequate filters. Geographic quotas, and demographic and socioeconomic characteristics are also frequently employed for eligibility determination. Some programs define benefit quotas for each area based on geospatial analysis indicators related to the program’s objective (for example, poverty, drought, malnutrition, child mortality). Then, specific households or individuals are selected within those areas using complementary criteria. In other cases, demographic characteristics are used as a filter, for example, age in the case of childcare programs or non- contributory pensions for the elderly or disability status for disability assistance benefits. Other socioeconomic criteria such as occupational status, school attainment, insurance benefits, and contributions are also used for eligibility determination. Enrollment decisions Once a registrant is deemed eligible, program administrators decide whether the individual or household is enrolled or wait-listed for a program, considering criteria such as budget and operational capacity. Through enrollment, eligible applicants become beneficiaries. The universe of potential beneficiaries of a program, issued at the eligibility determination process, is delivered to program administrators who then decide who gets enrolled in their program. Within DSPDS, the list of potential beneficiaries is pushed from the dSR to each user program’s BOMS. Ideally, needs assessments, costing, setting of eligibility criteria, and allocation of budget are aligned so that all eligible beneficiaries are enrolled. In practice, the enrollment decision is made either at the central or local level, considering resource constraints and policy objectives, and not everyone who is deemed eligible ends up being enrolled. To manage demand under resource constraints, programs may use various methods such as waiting lists, random assignment among eligible applicants, enrollment based on registration order, and caseworker discretion (Lindert et al. 2020). However, these methods involve a clear and direct error of exclusion, revealing a disconnect between eligibility criteria and budget (Grosh et al. 2022). (v) Determination of benefits and service package RECURRING 1 2 3 4 5 6 7 CYCLE 8 9 5 Determination of Benefits and Service Package Programs must also decide what benefits and services beneficiaries will receive. Based on their needs and conditions, governments can match beneficiaries with appropriate levels of benefits and services within a single program or to a bundled package provided by several programs. To inform this decision, inputs such as the scoring from the assessment of needs and conditions, the roster of eligible beneficiaries, the offer of benefits and services, and program rules are necessary. 74 “WHAT MATTERS” GUIDANCE NOTE Benefits and services can be flat or vary based on specific characteristics of households or individuals. Some programs offer the same level of benefits and services to their beneficiaries, while others differentiate them based on household size and composition, attributes of individual family members, socioeconomic status, or other criteria to ensure that the neediest beneficiaries receive more support. From a human-centered perspective, such variations can be better to attend people’s needs, however, they can be complex to implement. First, information requirements can vary depending on the type of benefit with direct implications on data collected at intake and registration. Second, additional efforts may be needed to communicate and justify the differentiation in benefit and service levels. Third, complex benefit formulas can affect the payments process in terms of processing, cashing out, reconciliation, and audit. Fourth, beneficiary operations management can be more complicated, for example, to update benefit amounts due to small changes in the beneficiary’s situation or possible increases in grievances. While determining the appropriate package of benefits and services may be informed by the dSR’s assessment of needs and conditions, the programs are responsible for making the ultimate decision. In some countries, access to a benefit or service can grant access to another. For instance, benefiting from a cash transfer program can entitle beneficiaries to health insurance and/or school fee waivers. The set of rules to determine the package of benefits and services is typically specified within program inventories, along with eligibility criteria. Using a logical syntax, the dSR can cross-reference the applicant’s profile against program rules to verify if they meet the qualification requirements and compute the appropriate level or package of benefits and services when applicable. This information is transferred to program administrators to verify the information, for example, through community-based checks, and to make enrollment decisions. The final output is an updated beneficiary roster with the results from the enrollment decision and the package of benefits and services each beneficiary will receive. This roster then feeds into either the payroll (for cash benefits) or the listing of beneficiaries and their assigned services. Program administrators make enrollment decisions and record them in their own BOMS, however, data analytics platforms can provide inputs for decision-making at this stage. Incorporating program-specific resource information on budget and operational capacity into the data analytics platforms can potentially help program administrators plan for beneficiary quotas by region or period. (vi) Notification and onboarding RECURRING 1 2 3 4 5 6 7 CYCLE 8 9 6 Notification and Onboarding Notification is the process by which people learn about the enrollment decision and other program-specific information. The main principle is that all applicants should be notified of their enrollment status, whether they are eligible and become beneficiaries, are wait-listed, or are ineligible. The content of notifications can include information on the basis for rejection or wait-listing, instructions to file grievances, and how to claim or use the benefits or services, among other details. This process can occur in person or by using technology-enabled solutions (for example, USSD, SMS, email, automated calls) that can be facilitated by BOMS or centralized outreach and notification platforms (see the Outreach section above). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 75 CONCEPTUAL FRAMEWORK After notification, beneficiaries receive an orientation about the program. Typically, this involves collecting additional information needed for program operations, including updated contact information, preferred payment method information, conditions and instructions to obtain their entitlement, and how to file a complaint, among others. Updated information can be captured within a program’s BOMS and could ultimately be pushed to the dSR to support other processes along the delivery chain (see the Intake and registration section above). C. PROVIDE (vii) Provision of benefits and/or services RECURRING 1 2 3 4 5 6 7 CYCLE 8 9 Provision of Benefits and/or Services 7 The next step along the social protection delivery chain consists of delivering benefits and services to households and individuals enrolled in the program. Programs can offer monetary payments, in-kind benefits, and online or in-person services to support in-need households and individuals. Depending on the type of assistance provided by programs, information systems at this stage are supported, on the one hand, by BOMS, and, on the other hand, by auxiliary systems that can be broadly assorted into two groups: payments platforms and service administration platforms (for example, employment services’ websites, timesheets for public works programs, or attendance lists for childcare services). The front-end and back-end functionalities of SAPs are determined based on the specificities of the delivered service on a case-by-case basis. Given the varying characteristics of service administration platforms, this section focuses on the systems-based processes emerging from monetary benefits, although we recommend consulting the ISPA (2017) Social Protection Payments tool for a more detailed discussion on payments. Payments made for social assistance have been digitalized to varying degrees. Changes in technology, infrastructure, and even shocks such as COVID-19 have helped countries to move from more traditional payment approaches to the virtual provision of transfers, not only creating significant efficiencies for governments but also substantially improving financial inclusion for recipients. Nonetheless, even as countries transition toward e-payment systems, there may still be a subset of beneficiaries who continue to receive payments in cash or checks due to challenges related to vulnerabilities, access, and remoteness.104 Lindert et al. (2020) document the typologies of digitization of G2P payments (Figure 21). Digitization of payments extends backward to automate administrative processes and forward so recipients can use their payments for everyday transactions. Few countries continue to rely on end-to-end “manual” payments (G2P 1.0), whereby benefits are directly distributed, usually in cash, from a single program to people through the intermediation of a single provider (outsourced or a line ministry). However, the vast majority of countries have automated, to different extents, payment administration 104. While digitizing G2P payments can bring about important efficiency gains, the extent to which the local context allows for cashing out benefits and making e-payments remains an important challenge. For a discussion of some of these challenges and examples, we recommend Klapper and Singer (2017), Koechlein and Jaluka (2022), and Gelb, Mukherjee, and Webster (2022). 76 “WHAT MATTERS” GUIDANCE NOTE FIGURE 21 Evolution of government to person payments for social protection G2P 1.0 Single Program to Single Provider (In person) KEY FEATURES • One program managed by one provider. Cash • The provider can be outsourced Transfer (e.g. post office) or managed within a social ministry. • Beneficiaries queue in person to PROGRAM PROVIDER receive a payment in cash. G2P 1.5 Single Program to Single Provider (In person, electronically asisted) • One program managed by one provider. • The provider is outsourced (e.g. Cash commercial banks, or mobile Transfer network operators/ATMS). • Beneficiaries queue in person to PROGRAM PROVIDER “cash-out” (if possible) at agent, kiosk, etc. G2P 2.0 Single Program to Single Provider (Virtual provision) • One program managed by one provider. • The provider is outsourced (e.g. Cash commercial banks, or mobile Transfer network operators/ATMS). • Provision is virtual, and transfers are deposited into a Bank account PROGRAM PROVIDER or a mobile money account. G2P 3.0 Single Program to Many Providers (virtual provision) • One program BUT through many providers. Cash • Beneficiaries can choose Transfer provider of choice and transfers are virtual, deposited into a bank account or a mobile PROGRAM money account. PROVIDERS G2P 4.0 Many Programs to Many Providers Disability • Many programs under one platform that can connect to Cash the provider of choice. Transfer • Beneficiaries can choose provider for each program, and transfers are virtual, deposited into a bank account or a mobile money account. Elderly PROGRAMS PROVIDERS SOURCE: Lindert et al. (2020). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 77 CONCEPTUAL FRAMEWORK processes. Sometimes, payment administration is electronically assisted by software applications, but provision continues to be in person (G2P 1.5). Others have automated the back-end payments administration processes between programs and payments service providers so that benefits are disbursed directly into recipients’ bank or mobile money accounts (virtual provision). In some models, a single program interacts directly with a single payments service provider (G2P 2.0), while in others, it links to multiple providers (G2P 3.0), allowing recipients to choose the most convenient provider. More developed models connect multiple programs with multiple payment service providers through interoperability (G2P 4.0).105 In the Playbook, we provide a high-level description of some of the functionalities of program-specific BOMS and multi-program multi-provider payments platforms for the provision and administration of e-payments (G2P 4.0 model). This corresponds to the complexity of this stage in the delivery chain and the numerous dedicated sources available for consultation. Delivering payments involves three generic processes: (1) payroll generation, (2) distribution of benefits, and (3) payment reconciliation. Payroll generation Based on the package and level of benefits previously determined for enrolled beneficiaries, the BOMS generates a payroll. In some cases, preparing the payroll involves verifying compliance with program conditionalities, which can result in temporary or permanent financial penalties (see the section Monitoring compliance with conditionalities below). This information is typically stored in a compliance module within each program’s BOMS, which, together with the BOMS payment administration module, allows the latter to calculate benefits and create a payroll. The payroll is a list that typically contains information on who needs to be paid (biographic data, such as name and unique identifier), how much needs to be paid, when it needs to be paid (payments schedule or calendar), and how it needs to be paid (for example, agency, account number). This information is pushed to the multi- program multi-provider payments platform. This process is accompanied by a directive to the treasury, central bank, or an equivalent entity to transfer the corresponding funds to the payments service providers, in advance or after the payments have been distributed, as per the local regulatory framework and preexisting agreements. Distribution of benefits Once data have been pushed by BOMS and pulled by the multi-program multi-provider payments platform, benefits are distributed to people through different coexisting modalities. In its most basic form, payments are made in person in cash, checks, or physical vouchers on a predetermined date and location. The process can be outsourced to a payments service provider in charge of the logistics, including the transportation of funds, or be done in-house. Although less sophisticated, this modality remains relevant in locations with limited or non- existent financial infrastructure; however, it entails higher administrative costs and increases the risks of error, fraud and corruption, leakage, and opacity in contrast to the virtual provision of payments. The COVID-19 pandemic has accelerated the adoption of virtual payment modalities (Gentilini et al. 2021). These include mobile money, deposits to bank accounts, and digital wallets. In choosing payment delivery mechanisms, three criteria need to be considered: payments mechanisms need to be accessible to beneficiaries in terms of cost, reliability, and rights and dignity; robust to predictably and securely deliver transfers; and integrated into the social protection system 105. Countries with more developed financial ecosystems are adopting a Treasury Single Account (TSA) model to ensure effective budgetary management. A TSA model allows for the direct transfer of resources from the treasury or the Central Bank to beneficiaries’ accounts. Once the sender has processed the payment order, the single treasury account is debited, and the beneficiary’s account is credited. The benefits of consolidating cash resources through a TSA arrangement are multifold. It minimizes borrowing costs, improves the efficiency of payments, and facilitates the reconciliation of payments, among others. 78 “WHAT MATTERS” GUIDANCE NOTE FIGURE 22 Payments zoom-in: provision modalities PEOPLE VIRTUAL PROVISION Digital wallets Exchange da push data Mobile money CO N T RIB U TE IN-PERSON Bank account PROVISION Reconcile BE payments NE IT F Electronically assisted, in-person S VER Cash, in-person SOURCE: Original for this publication. to take advantage of economies of scale and ensure the inclusion of beneficiaries into the financial system (ISPA 2017). Multiple payment modalities can coexist in order to deliver to all beneficiaries taking into consideration their local context and overall situation. All payment modalities require authentication of the identity of the person claiming to be the rightful beneficiary before disbursing payments. In in-person provision modalities, authentication occurs at the payment point and is typically implemented through community verification or manual verification of an identity credential. When payments are distributed virtually, beneficiaries’ authentication can be through one- or two-factor authentication methods (for example, PIN, password, biometrics) to verify the recipient’s identity. This verification typically Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 79 CONCEPTUAL FRAMEWORK comes after KYC procedures have been implemented by the payments service provider to verify the identity of recipients for account opening. Once the recipient’s identity is confirmed, payments service providers proceed to the authorization and disbursement of payments. This can be followed by a notification to the recipient indicating their transfer has been disbursed. Payment reconciliation The next step consists of ensuring funds are distributed accurately and on schedule. Also known as payment reconciliation, this part of the process compares instructed transfers to those actually disbursed. Payments service providers transmit periodic payments reports (typically including proof of payment) to program administrators through the multi-program multi-provider payments platform to confirm that the level of benefits planned matches the amount transferred. When systems are fully interoperable—facilitated by unique identification systems and enabling data exchange protocols—these reports can be produced in real-time. The information on whether or not funds were correctly disbursed and collected is pushed by multi-program multi-provider payments platforms and pulled by BOMS for record-keeping and to take action depending on program criteria.106 Payment reconciliation procedures can improve the performance of programs through data quality control to reduce failed payments. Moreover, multi-program multi-provider payments platforms can also work backward to allow P2G payments, that is, households and individuals can utilize the services provided by payments service providers to pay contributions to the government. This information is reconciled and pushed to the corresponding government system. Once the system recognizes the payment, people are notified whether their transaction was successful or not. The output of this process is a beneficiary registry (beneficiaries who actually received their benefit), which can be then integrated with beneficiary registries from other programs in order to generate an IBR. D. MANAGE (viii) Beneficiary operations management RECURRING 1 2 3 4 5 6 7 CYCLE 8 9 Beneficiaries Compliance, Exit Decisions, 8 9 Updating and Grievances Notifications and Case Outcomes Beneficiary operations management refers to the stage in which programs collect and process information to make decisions throughout their implementation. Based on a set of predefined protocols and operating rules, programs can regularly and simultaneously update, revise, and verify beneficiaries’ data and keep track of their progress to determine their status in the program and make operational decisions, including permanence in the program, delivery logistics, and level of benefits or services. Primary functions of beneficiary operations management include beneficiary data management, monitoring of conditionalities, and implementation of GRM (Lindert et al. 2020). This stage is traditionally supported by BOMS; however, interoperability of social protection 106. Determining how to address the issue of unused benefits requires establishing clear procedures, such as considering whether the government will reclaim the unutilized funds after a reasonable period. However, a comprehensive examination of this aspect falls outside the scope of this report. 80 “WHAT MATTERS” GUIDANCE NOTE information systems allows for some tasks to be supported by other systems, including the dSR, centralized GRM platforms, and case management platforms. Note that some of these interactions have been documented in interoperability standards by the DCI. Beneficiary data management Beneficiary operations management involves a series of actions to ensure that households’ and individuals’ information is up-to-date and accurate. Having precise and updated information enables program administrators to make ongoing decisions on the current beneficiary roster and supports good governance (Part 5—Governance). Life events, such as births and deaths or changes in the socioeconomic conditions of households and individuals, can affect program eligibility, benefit, or service packages after program enrollment as well as delivery logistics. For many programs, particularly those that are not a one-time-off intervention, keeping information actual and accurate is a beneficiary obligation. If not fulfilled, it can result in sanctions such as the loss or suspension of benefits. Typically, programs collect and update beneficiary information via case workers or through built-in mechanisms to incentivize self-reporting. However, within a DSPDS framework, data updates captured via component systems, such as dSR, CRVS, and other sources can be used by programs to inform their operations, and vice versa, programs can help update critical information. Processes for updating and correcting beneficiary data can be potentially integrated with the dSR front-office. Beneficiaries can use direct modalities, such as digital service windows, community service centers, or local offices, to record any changes in their conditions or correct their data at any moment. Information can also be updated or corrected by case workers or program field agents trained and authorized to enter, validate, and approve changes to the beneficiary’s information. Updating and correcting information requires clear protocols establishing who and how changes in information are approved, as well as what type of information can be self-reported or needs to be cross-checked against another source. It is also an essential part to auditing and establishing good governance procedures. Moreover, cross-checks and data updates through administrative systems, facilitated by interoperability, or via field validations can also support this stage. For instance, Türkiye’s ISAS and Chile’s RSH extract data from various government administrative databases every 45 and 30 days, respectively, to update beneficiary’s information such as formal earnings, vehicle values, or death incidents. In some contexts, field validations like home visits or in situ questionnaires can be administered to validate beneficiaries’ information. Monitoring compliance with conditionalities or co-responsibilities Some programs apply conditions or co-responsibilities to receiving benefits or services to nudge certain behaviors among beneficiaries. Conditionalities or co-responsibilities can be in the form of medical check-ups, school attendance, seeking employment opportunities, or others. Conditionality or co-responsibility monitoring involves considerable efforts in terms of institutional arrangements, coordination with service providers,107 and logistics planning to ensure that the delivery of benefits and services is not delayed due to this activity. In many contexts, conditionality or co-responsibility monitoring remains largely paper-based, with data entry occurring later in the process. This can increase bottlenecks and errors, thus affecting the delivery of social protection. Nevertheless, programs can harness the potential of DSPDS to automate and expedite the entire compliance verification process through the interoperability of systems. 107. Many safety net programs rely on different institutional arrangements for conditionality or co-responsibility monitoring, including deconcentrated agents at subnational levels, vertical collaboration with autonomous subnational and local government units, or outsourcing to third parties (Lindert et al. 2020). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 81 CONCEPTUAL FRAMEWORK When information systems are fully interoperable, countries can apply the “once only” principle to monitor conditionality compliance. Through DSPDS enabling environment, BOMS can pull data from relevant information systems to determine compliance or not with program conditionalities or co-responsibilities. A noteworthy example is Türkiye’s ISAS, which pulls data from the information systems of the ministries of health and education to verify compliance among conditional cash transfer (CCT) beneficiaries. The result of the compliance monitoring process, which is recorded in the program BOMS, entails program-specific follow-up actions. These can range from monitoring or counseling, to administering subsequent services or benefits in programs with progressive steps to beneficiaries, to revisions to payroll calculations and processing in the next payment cycle, as described in the payments section, to sanctions or penalties. Grievance redress GRMs—also referred to as complaint and appeal mechanisms—give people a voice to express their feedback on the management and implementation of social protection policies and interventions. This includes requesting corrections to service-related data, seeking information, making suggestions, and filing complaints and appeals at any stage of the delivery process (from Assess to Manage stages).108 These mechanisms can also give a voice to the population to ensure that they can effectively realize their rights in the case of rights-based entitlements and to support GBV incidence monitoring and case management.109 GRMs refer to a system by which queries, concerns, and recommendations are addressed, problems with implementation are resolved, and complaints are handled in order to improve service delivery, transparency, and accountability (Lindert et al. 2020). A well-designed GRM is available not only to program beneficiaries but also to all dSR registrants, non-eligible and non-enrolled applicants, and all social protection stakeholders, including the general public and program implementors. Although many countries have developed program-specific GRM information systems, there are several advantages to having a centralized and interoperable GRM platform. First, it improves the user experience due to the simplicity of a single front-office interface for uptake, tracking, and feedback. Second, it is more cost-effective than fragmented GRM systems. Third, it allows for effective and strategic monitoring and evaluation of grievances and complaints to improve social protection delivery. GRMs are usually organized into six steps, some of which can be centralized, while others are handled at the program or appropriate unit level (from Lindert et al. 2020): 1. Uptake consists of the process by which grievances are collected and logged on the GRM platform. Uptake channels can include letters, call centers, digital service windows, social media, complaint boxes, face-to-face interactions with program agents or social workers, reports on visits to project offices or sites, among other channels. Grievances can be filed directly by the affected party or through local intermediaries to facilitate the submission. 2. Sorting and processing refers to the stage where grievances are categorized, prioritized, and assigned to the relevant entity. This entails predefining rules and procedures standards, as well as establishing roles for key agencies and officials both at the central and entity levels. Grievances can be broadly classified into (i) information requests or queries, (ii) complaints, (iii) beneficiary information updates, (iv) suggestions, and (v) other feedback. When complaints concern a specific program, the report can be pushed from the GRM platform to the program’s GRM module within BOMS through predefined workflow au`tomation protocols. In the program-specific GRM module, programs can track and follow up on the grievance status and push this information back to the GRM platform to continue the resolution cycle. Alternatively, each agency or program can have role-based access to the GRM platform to record progress. 108. See Lindert et al. (2020) for a detailed list of potential grievances at each stage of the delivery chain. 109. For example, Primero is an open-source information system which includes a GBV incidence monitoring module and case management. More information can be found here: https://www.gbvims.com/primero/. 82 “WHAT MATTERS” GUIDANCE NOTE 3. Acknowledging and following up consists of acknowledging receipt of a grievance by communicating to the complainant an automatically generated case number, and by providing information about the timeline for resolution and how they will be made aware of progress. 4. Verifying, investigating, and acting to resolve a grievance. This step is handled by the relevant entity in charge of resolving the grievance. It can involve gathering more information, comments, or documentation to determine the grievance’s validity and take the steps needed to address it. It may also entail elevating the case to a higher level for additional investigation and actions. 5. Monitoring and evaluation consist of the process by which data analytics are produced by the GRM platform to support social protection delivery. Monitoring allows following-up on and keeping track of complaints and resolutions. It may also involve spot checks to verify the grievance’s resolution and collect indicators concerning tracking and resolution of complaints. Evaluation refers to examining grievance data to find trends and adjust procedures at a higher decision-making level to minimize similar grievances in the future. 6. Providing feedback consists of notifying complainants and the general public in an effective and timely manner about the results of investigations and actions taken. This process can lead to filing an appeal if the resolution is unsatisfactory. Exit decisions A critical resolution for social protection programs are exit decisions. Effective beneficiary rosters are dynamic as they continuously incorporate new beneficiaries and cease those who have completed their path or no longer meet the eligibility criteria to remain in the program. There are several reasons for program exit predefined by programs according to its rules and terms. These include: • Completion of program path (“graduation”): Some programs predetermine a set of activities, interventions, or installments—which, upon completion lead to automatic exit from the program. • Profile change: When beneficiary conditions change, they may no longer be eligible to continue in the program. Examples of changes that can affect program permanence include significant improvements in socioeconomic conditions or relocation to an uncovered geographic location. • Life cycle: When beneficiaries reach a certain age threshold for which the program is not intended to or become deceased. • Noncompliance with conditionalities: When beneficiaries do not comply with program conditions. From the systems perspective, exit decisions can be triggered by two processes. On the one hand, when beneficiary data are updated at the dSR level it activates an automated process to reassess needs and conditions based on program(s) exit criteria. As with enrollment decisions, the results from this process are transferred through a predefined protocol to program administrators to make exit decisions. That is, program administrators validate the criteria leading to program exit and make an exit decision, which is recorded in the program’s BOMS. This process also applies to life cycle events such as aging or death. On the other hand, when BOMS register noncompliance with conditionalities, exit triggers are automatically validated by programs conducing to an exit decision, which is recorded in the BOMS. The process is only completed after programs notify beneficiaries about the exit decision and the reasons leading to it so that, in case of error, they can file a complaint (see the Notification and onboarding section above). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 83 Part 4 Technology A. ARCHITECTURE Delivering social protection programs in a progressively digital world calls for a big picture, systems-thinking approach to building shared infrastructure that functions for whole-of-government, even when starting points come from fragmented initiatives. This section provides an overview of the design and implementation of DSPDS, with a focus on the integration of various components to serve people effectively through trusted data sharing and interoperability. Social protection programs at large would benefit from tapping into the shared systems- thinking approach while still operating within their specific contextual realities and constraints of working with people in need. DSPDS are envisioned as interoperable platforms across government that support the delivery of various social protection programs by facilitating seamless data sharing. These include unique identification systems, dSR (although not always), multi-program multi-provider payments, and beneficiary registries, all designed (ideally from conception) to be interoperable with each other, exchange information seamlessly with consent, to facilitate dynamic inclusion of people and coordination of social programs. DSPDS also use geospatial, case management, GRM, and a host of multi-sectoral administrative and big data sources. DSPDS help governments to answer several fundamental questions: (i) who is who? (ii) who is in need? (iii) where are they? (iv) how they will be paid or reached? and (v) who has received some form of assistance?  DSPDS build upon a gamut of digital public goods, function in low-tech environments, recognize the digital divide, are context-specific, and are deployable in a culturally appropriate manner. They bring new capabilities as well as new risks and responsibilities with profound implications for the relationship of trust between governments and people. They enable governments to streamline their social protection program management processes, to facilitate data-driven policy making and better expenditure planning, and to simplify benefits delivery experience Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 85 CONCEPTUAL FRAMEWORK for beneficiaries. DSPDS architecture enables the development of services that are generic in nature and can be used by various social programs. Recent examples of digital public goods developed for DSPDS include OpenIMIS, CoreMIS, CaseCompass, and MOSIP, among others. DSPDS also enable the establishment of context-specific good governance procedures, and this same system-thinking approach allows for data protection and privacy to be done by-design and by-default across the entirety of the DSPSD framework (Part 5—Governance). People are central to the design and delivery of social programs, and DSPDS’s goal is to provide a holistic experience by enabling efficient interactions between individuals and programs. The DSPDS architecture framework aims to enhance the efficiency and effectiveness of social programs by seamlessly integrating various components, data sources, and stakeholders. At the heart of interoperable systems is the seamless exchange of data between different components. The data exchange is not only critical for program enrollment but also for providing a holistic experience to applicants and registrants. Data flows ensure that the right individuals are identified, eligible for programs, and receive timely support. To enable effective data exchange, various architectural components and standards must be considered. Data exchange and interoperability require a solid foundation of open standards, ensuring that systems can communicate effectively regardless of their origin or technology stack. These open standards encompass political, legal, and organizational contexts necessary for harmonizing data exchange. Designing interoperable systems involves adhering to these standards, enabling seamless data sharing and enhancing compatibility between different components. Clearly articulated design principles form the basis of DSPDS architecture, and these include:110 • Human-Centered Design (HCD): simplifying the service-delivery experience, by establishing common touch points for individuals and households to manage their data across various social programs. • Verified data: creating the foundation for a trusted system, to support an architecture that enables easy verification of data on socioeconomic attributes for individuals and households by linking multiple sources of information through master data management. • Interoperability: leveraging open specifications when available alongside the use of open and standards- based designs, such as the Digital Convergence Initiative (DCI) standards for interoperability across social protection delivery systems,111 to establish interoperability and interchange among different components of DSPDS. • Modularity: developing loosely coupled application units using techniques like microservices that supports architectural reuse, ease of extensibility, and refactorability. • Data security: establishing strong data protection and user privacy measures, ensuring the confidentiality, integrity, and availability of data, be they in transit or at rest, to safeguard an individual’s personal data and grow their trust in the overall architecture and actors. • Vendor neutrality: encouraging the use of open standards during implementation to avoid vendor-lock in of front- and back-office applications. DSPDS architecture is designed based on the key principle of a “human-centered design,” such that the platform is easy-to-use and accessible for all stakeholders. Since, as applicants and beneficiaries of social protection programs, individual users are the most important stakeholder of the DSPDS platform, it is paramount to prioritize their needs around overall usability and user experience as design principles for DSPDS implementation and successful adoption. Doing so involves leveraging user stories in DSPDS component design to ensure alignment 110. See also the Principles for Digital Development in Social Protection, available at: https://spdci.org/news/digital-principles/. 111. See https://standards.spdci.org/standards. 86 “WHAT MATTERS” GUIDANCE NOTE with their expected experiences. A user-centric or human-centered systems architecture also means ensuring that the components and services of the DSPDS platform are universally accessible and available to all stakeholders (such as online/offline system availability). To enable the creation of verified registries, the DSPDS architecture adopts the principles of master data management in its design and support “dynamic data updates” across the DSPDS framework. Doing so ensures that the beneficiary data in DSPDS are always up-to-date and that data inconsistencies across various BOMS are avoided and obviated. By providing a verified source of beneficiary’s socioeconomic data, the DSPDS framework thus helps in making informed policy decisions through rich data analytics and trends that could then be used to develop tailored strategies in the delivery chain processes. An architectural framework for DSPDS provides shared services based on state-of-the-art modular, component- based architectures, such as microservices, that can be used across the various participating social protection programs and business functions. Such shared services can help facilitate seamless data sharing that is consent- based within the different programs supported by the DSPDS. Modular software components can also provide common services for beneficiary search, alert/notification capabilities, and other functions. Using open standards- based data exchange mechanisms, DSPDS can provide a common interoperability layer that will help governments avoid the need for building individual point-to-point data interfaces, thereby reducing costs and simplifying operations. Crucially, DSPDS architecture is designed in such a manner that it does not interfere with the operational and implementation aspects of the various social protection programs themselves. Instead, DSPDS offers common shared services to support specific program operations for registration, eligibility determination, data updates of beneficiaries, among other things, that aid the decision-making processes of the social protection schemes. To this end, the architecture of the DSPDS platform has a service catalogue comprising a collection of services for different components supporting the delivery chain processes of program agencies yet at the same allow the agencies to control over their functioning. A service-oriented architecture enhances the ease of extending the functionality of the DSPDS; if, for instance, a new business functionality is required, a separate service module can be implemented and added to the service catalogue. Following the interoperability paradigm, all services will ideally be able to leverage existing business functionality within other services. DSPDS architecture is designed keeping in mind the need for ensuring the security and privacy of an individual’s personal data from day one and at each stop along the delivery chain. Security and privacy-by-design—which has evolved into data protection-by-design and by-default—are not afterthoughts, but they are fundamental to designing built-in controls for all the key functions/workflows/processes within the DSPDS framework (World Bank and UN 2024).112 These involve key design considerations such as: limiting the collection of individual personal data to the absolute bare minimum that is required for the purpose of delivering the proffered service or benefit and nothing more; ensuring that the individual personal data are always kept secure—meaning that confidentiality, integrity, and availability are ensured—including application endpoints, in use, in transit, and in store. Thus, safeguarding the privacy and security of personal data to prevent unauthorized access and providing adequate cybersecurity is a cross-cutting principle adopted across all the design elements of the DSPDS framework, and also involves adopting internationally accepted norms and best-practices in cyber-security and information security, as well as conforming to the national data protection regulations and guidelines. These aspects are further developed below (see Part 5—Governance). 112. See also Cronk (2021) for resources on the foundational principles of privacy by design. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 87 CONCEPTUAL FRAMEWORK The architecture of front- and back-office applications are agnostic to one vendor or the other and are based on open standards to avoid vendor-lock-in. Interoperability necessitates a vendor-neutral approach. This approach means utilizing open application programming interfaces (APIs) in order to allow different systems to communicate with each other without being tightly bound or restricted to any specific vendor’s technology. Open APIs facilitate the secure and standardized exchange of data, enabling diverse systems to collaborate seamlessly while remaining BOX 3 Perils of vendor lock-in Proprietary software solutions may hide the source code from the buyer. This means that governments could become beholden to the vendor in terms of control and ownership of the core software solution. Furthermore, a lack of attention to contractual clauses and fine-print during the procurement process could lead the purchaser or user down a road where they find themselves required to work within the walls of one given vendor’s products or forego access to the data, a situation known as “vendor lock- in.” Vendor lock-in situations could occur on account of capacity limitations, lack of good governance, and political economy considerations. In such instances, ownership and control over mission-critical software program code remains with the vendor, which makes it difficult, if not impossible for the user to subsequently switch over to another vendor for support, even if the solution no longer meets their needs or if the cost of support has become unsustainable. Moreover, stored data may be subject to the whims of the vendor or subject to being lost if the vendor goes out of business. In such instances, transitioning support services to another vendor would be risky, hence the term “vendor lock-in” on account of the steep learning curve for any other vendor that might be contracted to support the system as per a service-level agreement. The challenge of vendor lock-in has become a commonplace refrain in the public sector, particularly when proprietary software solutions are used. Inevitably, public sector agencies tend to customize these solutions to their specific needs, by appending new code on top of the source code. This is not to say that such a situation could not be envisaged even if an open-source software (OSS) solution were used; however, as an OSS solution makes the source code available, third-party service providers and other vendors compete to develop useful enhancements and to provide critical support services to the core solution. Moreover, skilled personnel within government are motivated to build internal technical capacity to maintain the OSS solution. To solve issues of vendor lock-in, several low- and middle-income countries have utilized highly competitive procurements to negotiate favorable terms and conditions of contracting and licensing with technology vendors, while also building in-house IT capacity and seeking continuous access to technical experts and software architects experienced in open standards and in implementing open- source software solutions. Those aspects must be considered both for operations and for maintenance of government technology and data. Developing (open) technical standards, guidelines, and interoperability frameworks for interoperable, secure, and robust systems helps to impede vendor lock-in and to ensure that the systems developed by vendors, technology service providers, and government service providers are all interoperable. SOURCE: George et al. (2019). 88 “WHAT MATTERS” GUIDANCE NOTE flexible in adapting to changing requirements. The use of open standards, Open APIs, and open-source software (wherever possible) may be explored along with open and competitive procurement processes for the selection of firms that will implement the applications using best-in-class technologies to meet the architecture and design requirements of DSPDS platforms. Such an architecture provides the flexibility to replace technology components, when required, through plug-and-play mechanisms and using protocol-based interoperability methods. These go a long way toward ensuring seamless interoperability between various components of the DSPDS platform and other third-party systems for delivering social benefits and services to beneficiaries effectively. Data are exchanged across DSPDS and among its various component parts. Data are collected from multiple sources with a defined purpose, curated, and exchanged with the informed consent of the concerned individuals or their representatives (for minors, households, and so forth), and analyzed to make policy decisions through a whole-of-government effort (Figure 23). Some of the most common data exchanges between the components of DSPDS include the following: • Unique identification and social registries: Social registries make use of a unique identifier as a “primary key” for an individual. Utilizing the unique identifier, the social registry builds a household unique identity number (HIN) for a grouping of individuals. All individuals in this group attest that they belong to that household (see Table 3 with examples of household definitions in selected countries) and that none of those individuals belong to more than one household. The social registry relies upon the unique identification system to authenticate individuals using the unique identifier when socioeconomic attributes of the individual or the household are updated. The unique identification system should not have data on the HIN for data protection and privacy purposes; this security measure has the added benefit of improving overall DSPSD functioning and efficiency. • Social registries and BOMS: The social registry determines potentially eligible beneficiaries, according to program eligibility criteria, and transmits this information to the BOMS. • BOMS and multi-program multi-provider payments: The payments administration modules typically reside within the BOMS, where enrollment decisions are made and recorded. The BOMS generates the payroll instruction files and transmits them to payments service providers through a single or a multi-program multi- provider payments platform. Once the payments platform delivers the transfer and performs the reconciliation of delivered benefits, it sends data on the reconciliated benefits back to the BOMS. • BOMS, multi-program multi-provider payments, and unique identification: The BOMS uses the authentication service layer of the unique identification system to enable payments provisioning at the point of delivery. • BOMS and in-kind delivery platform: The BOMS makes and records the enrollment decision, generates a list of recipients, and transmits the list to the in-kind delivery platform (for example, food distribution). • BOMS and IBR: The BOMS creates a beneficiary registry for the program based on the reconciliated benefits. It sends the beneficiary data for the program to the IBR to determine gaps and overlaps in benefits delivery across assistance units (individuals, families, and households). • IBR and social registry: The IBR sends data on delivered benefits back to the social registry so that the social registry can estimate inclusion/exclusion errors. • GRM and unique identification: The GRM authenticates individuals using their unique identifier to register and resolve complaints. • CMIS and unique identification: The CMIS authenticates individuals using their unique identifier when case workers and agents create and follow up on cases. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 89 FIGURE 23 An architectural framework for DSPDS, data flow, and interoperability DSPDS, DATA FLOW AND INTEROPERABILITY Community Digital service service IBR FRONT PAYMENTS GRIEVANCE window center OFFICE FRONT OFFICE PLATFORM FRONT OFFICE DATA EXCHANGE Social benefits and Receive Contribute Verify PEOPLE Mobile services statement benefits benefits identity File a Check Manage teams, resolution Home visits, facilitators complaint Cases census sweeps status CASH PAYMENTS & agents SERVICES UNIQUE IDENTIFICATION FRONT OFFICE dSR FRONT OFFICE Manage complaints and grievances Exchange data: Exchange data: Check Validate Update Verify Apply to Update Push to dSR/pull Pull and push data Register data identity programs status of information and verify from BOMS to BOMS GRIEVANCE application data PLATFORM Identify redundancies Disburse payments BACK OFFICE & complementarities Assess coverage of SP programs Reconcile payments Exchange View and Manage Assess Outreach Manage unique ID Determine Authenticate data: manage Update needs and and notify access IBR BACK PAYMENTS system uniquenes individuals Push to applicant data conditions applicants controls OFFICE BACK OFFICE beneficiary data Grievance Civil Registry systems/ Redressal pull from Land / Property other UNIQUE IDENTIFICATION BACK OFFICE dSR BACK OFFICE systems Financial / Banking Determine benefit & service package Vehicles Make enrollment Multiple BOMS Education decisions Notify Systems to Farmer’s Registry beneficiaries Payment deliver All validated Systems in-kind Disaster Risk applicants with Payment and services verified reconciliation GIS Dynamic information & Social Registry eligibility criteria Manage BOMS BOMS Utilities Unique Database beneficiaries Cash Education Identifiers CT Transfers Beneficiary data Telecommunications Monitoring and Data from Data from existing compliance Taxes National & Local beneficiary BOMS BOMS Disability Admin Systems systems BOMS BACK Humanitarian Disability Beneficiary data Health OFFICE Satellite Imagery Beneficiary In-kind data updates BOMS BOMS Beneficiary data sent to Social Health Road Density Registry to Integrated X validation and verification Beneficiary Local Gov Systems Registry TRUSTED DATA Y TRUSTED DATA Y B. APPLICATIONS People are the focus of design and delivery of social programs. People’s interactions with systems occur through various channels, such as digital service windows, community service centers, home visits, mobile vans, facilitators, and agents. These interactions often involve the use of unique identifiers to authenticate individuals’ identities. Once individuals have registered their unique identifiers and have verified their identities, front-office processes are put in place to enable applications for programs, to check application status, to update information, and to verify data. At the back end, administrators manage applications by individuals and households and handle tasks such as viewing applicant data, assessing needs and conditions, notifying applicants of outcomes, and managing access controls. DSPDS has a layer of front- and back-office software applications that support various functions for delivering social protection benefits and services along the delivery chain. The DSPDS software applications layer adopts enterprise-grade design principles that allow for robustness, adaptability, ease of maintenance, and cost effectiveness. Following industry good practices, software applications adhere to a modular architecture, with each module composed of discrete delivery chain service offerings and a service exchange framework that allows for seamless interoperability of each process function along the delivery chain. Such an architecture is achieved by unbundling the delivery chain functions and processes into independent application modules which can be recombined and layered to execute specific transactions. A modular design philosophy also enables the DSPDS to imbibe key software architectural principles such as refactorability, resilience, and manageability. One advantage of developing DSPDS software applications as modular components and microservices is that they are highly re-usable and can be combined to various functionalities and services. Such software components and microservices can thus be bundled, unbundled, and rebundled to configure various scenarios and functions for social protection programs. The architecture of microservices is minimalistic, and independently replaceable and extensible for future evolution or backward compatibility, with features such as audit trails, data retention policies, and data protection and privacy controls for compliance purposes, among others. (i) Front-office software application components Data interfaces include various channels involved in intake and output provisioning of data into and out of DSPDS. Data interfaces allow people to apply for assistance and update their data at any point in time, and particularly as crises unfold. The architecture of such interfaces is crucial to the design of DSPDS. These include direct intake channels that provide self-service modes for individuals to apply for social programs through digital service windows such as online web portals, mobile apps, and USSD interfaces. Similarly, direct intake channels also include assisted modes of registration involving community service centers, field agents, facilitators, or mobile field agents and home visits for the elderly and disabled by social workers. On the output side, the provision channels provide mechanisms to view DSPDS data using open government data portals and other transparency and reporting systems in the government. Front-office software applications of DSPDS provide a visual interface for people (individuals and households) and frontline social workers who may operate the application on behalf of people. The functions or operations provided by the front office applications can be organized along the phases of the delivery chain: Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 91 CONCEPTUAL FRAMEWORK • Assess: (a) registering to be considered for potential eligibility for one or many programs through digital application forms or questionnaires, (b) updating information, and (c) tracking and monitoring application status. • Enroll: (a) providing additional intervention specific information not already in a potential beneficiary database, (b) receiving notifications on status of applications, and (c) tracking status of benefits and services. • Provide: (a) initiating and tracking payments and (b) making contribution payments to the government. • Manage: (a) filing and tracking grievances and (b) requesting for voluntary exits from one or more programs. With the rapid penetration of mobile devices and mobile coverage, mobile applications are being used for intake and registration, cross-checks, and eligibility assessment. In several countries, front-office software applications are available to case workers at their offices (or in tablets/mobile devices) or to data entry operators to input data into the system. However, case workers may still end up using paper forms when they are face-to- face with applicants in the office or in the field, which requires inputting data into software applications at a later stage or scanning paper forms. Such scenarios suggest that software applications for data collection can greatly benefit from HCD principles so as not to impose an undue administrative burden on people or case workers. The core technical capabilities provided by the various front office applications for people and program administrators are described below: (a) Unique identification—Front-Office Front-office software applications enable people to register to obtain a unique identity, as well as update their personal information if they have been previously registered. These applications enable administrators to issue unique identity credentials to individuals. Such credentials serve the key purpose of ensuring that the registered person is a single, unique individual. Depending upon a country’s particular legal regime, those same credentials may also establish legal identity. The functions of generating a unique identifier along with the credential issuing system (such as printing devices) itself are performed by back-office applications for unique identification. The application also provides the ability for front-line administrators to authenticate individual beneficiaries using their unique identifier by comparing the data of the presenting person against a stored identity profile that has already been verified (UNCITRAL 2023). The design of front-office software components for unique identification leverages a variety of technology frameworks to develop intuitive, accessible, and responsive user interfaces across devices and browsers. These frameworks rely on internet-based protocols to enable standardized communication between front-office and back-office applications. The applications are designed to work seamlessly with other components and systems that rely on unique identifiers, with careful consideration for trusted data sharing, interoperability protocols, and APIs. (b) dSR—Front-Office The front office applications for dSR enable people to register for one or more social protection programs. They can apply to programs through a digital service window and other intake channels described above. Individuals can also use dSR front-office applications to track and monitor the status of their applications, as well as to update their personal and household information. For program administrators, dSR front-office applications provide the ability to validate and verify applicant data through cross-checks with other administrative systems and resolve any conflicts in the information provided. These applications also provide capabilities for managing outreach to the intended populations of social protection programs. 92 “WHAT MATTERS” GUIDANCE NOTE dSR front-office applications are designed at scale to handle frequently changing data, with capabilities for storage, processing, and retrieval of data in real-time, and with features for data validation and error checking. dSR front-office applications are also able to handle a large volume of requests from users and other DSPDS components to scale horizontally and vertically, allowing them to handle increasing loads as the number of users and transactions grow. Ideally, the system is built as a multi-tenant software application to cater to the possibility of deploying multiple instances that leverage shared technological resources. As the dSR deals with personal data, much of which might be classed as sensitive, it requires robust security measures that consist of features such as encryption, access control, and secure communication channels. As is recommended for every other application in DSPDS framework, the dSR interoperates seamlessly with other components and other systems that rely on the social registry data, using open and trusted data sharing and interoperability mechanisms and protocols.113 These could also include the utilization of novel data sources and administrative information systems through interoperability protocols, as well as big data sources from private information providers. (c) IBR/BOMS—Front Office IBR/BOMS front-office applications enable the direct interaction of program administrators with beneficiaries. These applications provide capabilities for tracking the status of social benefits and services, providing notifications on the status of applications, publicizing anonymized versions of beneficiary registries for transparency purposes, and generating statements and reports on social benefits and services delivered to program beneficiaries. IBR/BOMS front-office applications are designed to handle complex and sensitive beneficiary data with the ability to store, process, and retrieve data in real-time, while including undertaking data validation and error checking. The applications enable the management of user access, roles, and permissions to ensure that only authorized personnel have access to beneficiary data. The applications also support workflows involved in front office operations while providing real-time updates on the status of beneficiary requests and transactions. The applications are designed with a focus on user experience with easy-to-use interfaces, intuitive workflows, and responsive web-based design. As multiple programs will benefit from the shared resources of the IBR/BOMS, it will benefit from a multi-tenant architecture, which will create a semblance of separation among the various programs that share the technological resources of the system. (d) Multi-program multi-provider payments—Front-Office A multi-program multi-provider payments front-office application enables program administrators to deliver social protection program benefits to people and to receive contributions from individuals toward social insurance programs. The front office provides administrators with the ability to verify and authenticate the beneficiaries before initiating payments provision and to track and monitor payments delivered. Beyond the front-office payment modules that are directly managed by the program administrators, payment functions are provided mainly by stakeholders within the ecosystem but not directly part of social protection programs. Central banks and other licensed organizations provide the interfaces that program payment modules can leverage to initiate and track payments provisioning to beneficiaries. A multi-program multi-provider payments front-office application is designed with appropriate user access and control permissions to ensure that only authorized program administrators have access to payment data and beneficiary information. The application integrates with other systems and databases that hold beneficiary 113. See Annex 2 for a template of functional requirements of a dSR, which should not be considered as prescriptive or exhaustive. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 93 CONCEPTUAL FRAMEWORK and payment data, such as financial systems (some operated by non-government players), unique identification systems, and other government databases. As beneficiary and payment data are personal data, often of a sensitive nature, and thus requiring robust security measures, the application needs to be designed with security in mind, including features such as encryption, access control, and secure communication channels. (e) GRM—Front-Office Individuals can use the GRM front-office application to file complaints or grievances regarding their program applications, and to check the status of resolution of their complaints. Program administrators use the front office of GRMs for case management and tracking of complaints and grievances. GRM front-office applications are designed with intuitive and user-friendly interfaces that enable users to easily register complaints and track their status. The application provides visibility on the entire life cycle of a complaint, including registration, tracking, resolution, and closure. It can handle multiple channels for grievance/ complaint registration, including email, web forms, mobile app forms, phone calls, and social media. The application also allows for managing the workflow of a complaint, including assigning complaints to the appropriate agencies or individuals, escalating complaints, and notifying complainants of updates to their grievances/complaints. From an accessibility perspective, the GRM front-office is designed to be accessible to users with disabilities, including support for screen readers, keyboard navigation, and other features such as support for multiple languages to enable complainants to register complaints in their preferred language, and to safeguard against risks of exclusion and inclusion for vulnerable populations. (f) Data analytics—Front-Office Program administrators and decision makers of social protection programs use front office applications for data analytics such as spatial/visual analytics, dashboards, and reports on application status, updates, grievances, and appeals. Such applications enable the visualization of spatial and visual data related to social protection programs in an intuitive and interactive way, using features such as zoom in/out maps, charts, graphs, dashboards, and reports using data filters or specific data points for more detailed analysis. As spatial/visual data analytics are likely to contain large volumes of data, the good functioning and performance of the front- office application is crucial for a good user experience. Design elements, such as client-side caching, server-side caching, lazy loading of data, and some level of client-side processing are essential. From a usability standpoint, the application is designed with simple and intuitive user interfaces, and the ability to customize views based on user preferences. (ii) Back-office software application components Back-office software applications for programs and system administrators provide multiple functionalities along the delivery chain for core data processing and master-data management of applicants and beneficiaries. These include: • Assess: (a) intake and visualization of applicant data, (b) dynamic updating, rectifying, or validating data, (c) executing assessments and reassessments of needs and conditions and visualizing outcomes, and (d) updating and validating data. 94 “WHAT MATTERS” GUIDANCE NOTE • Enroll: (a) determine eligibility using policy criteria, (c) taking and reporting on enrollment decisions, (c) determination of benefits and service package, and (d) sending notifications to beneficiaries. • Provide: (a) generation of payroll, (b) sending payment instructions to payments service providers, (c) receiving contributions from people, and (d) reconciliation of benefits delivered. • Manage: (a) reporting on benefits and services delivered, (b) case management, (c) grievance redress management and reporting, (d) monitor compliance of conditionalities, (e) track and follow-up on grievances, and (f) report exit decisions. The core technical capabilities provided by the various back-office applications for program administrators are described below: (i) Unique identification—Back Office The back-office functions of unique identification systems include the determination of uniqueness based on an individual’s biographic and biometric data collected during the registration. Upon determining the uniqueness, the back-office application generates a unique identifier or unique identity number and corresponding unique identity credential for issuance by the front office. The back-office application responds to identity authentication requests by various front-office application components. The back-office application maintains a database of unique identifiers from data collected at registration, and then verified and the person deduplicated before inscription by the identity authority. It is also responsible for the protection and privacy of personal data at rest (in storage), based on data protection and governance requirements (Part 5—Governance). (ii) dSR—Back Office Back-office applications of dSR provide program administrators with capabilities to view and manage applicant data, to update and rectify data, and to perform assessments of needs and conditions. One key function performed by the back office is that of dynamically exchanging data by pushing information to the BOMS back office as well as pulling in data from other social protection programs. Back-office applications of dSR are designed to securely store and manage large volumes of data related to individuals and households, such as demographic information, socioeconomic status, and beneficiary information. These applications enable the validation and cleaning of data received from various sources to ensure its accuracy, consistency, and completeness. For dynamic data updates, these applications are designed to process data in real-time or near real-time to make updates to existing data based on the most recent information or to flag errors or discrepancies. dSR back-office applications are designed to support interoperability with all other components of DSPDS to ensure proper data sharing and security, and to avoid duplication of data. (iii) IBR/BOMS—Back Office BOMS back-office applications enables program administrators to determine eligibility, make and record enrollment decisions, determine the benefits and service package for beneficiaries, notify beneficiaries regarding their enrollment decisions, and perform overall beneficiary life cycle and operations management. The applications provide the functions of payment administration and reconciliation, by exchanging information with the payment systems. Finally, they provide the capabilities of monitoring and compliance of the social protection programs. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 95 CONCEPTUAL FRAMEWORK IBR/BOMS back-office applications are designed to securely store and manage large volumes of data related to programs and beneficiaries, such as information on program criteria, beneficiary demographic information, payment history, and other relevant data. The BOMS architecture supports the concurrent implementation of multiple social protection programs. As such, the application design includes a configurable rules engine for administrators to configure and apply program-specific rules and policies, such as income thresholds, program eligibility criteria, and benefit type and duration. Applications are designed to process benefits and initiate payments to beneficiaries in a timely and accurate manner, ensuring that payments are made according to the program parameters. They provide the capability of generating various reports and analytics using data analytics to help decision-makers and program administrators make informed policy decisions, identify trends, and evaluate the effectiveness of social programs. The applications are designed to support interoperability with other DSPDS components, to ensure data sharing and to avoid data duplication. IBR/BOMS back-office applications perform data exchange functions. They pull beneficiary data from the dSR and push relevant information to the dSR. They also help program administrators and decision-makers to assess the coverage of social protection programs and to identify redundancies and complementarities of various social benefits and services across those programs. (iv) Multi-program multi-provider payments—Back Office Multi-program multi-provider payments back-office applications pull data from the BOMS, authorize payments, disburse payments, and reconcile payment information. All payments-related information processed by back- office applications is stored in the payments system database. The payments administration components are managed by program staff through the BOMS, while the payments provisioning aspects are managed by other government actors and/or private sector stakeholders. The back-office payments administration module is usually an extended business function within BOMS and is responsible for generating payrolls based on data from the program beneficiary module and taking into account program rules and policies, as well as beneficiary eligibility for the specific benefit. The payment module generates and initiates payment instructions to be provisioned by financial sector payment systems. Once payments are delivered, the application is responsible for managing payment reconciliation at the program level. Back-office payments administration applications effectively process payment instructions and ensure that payment of benefits is carried out securely and actually received by the intended beneficiary. These systems are usually managed by central banks or licensed financial sector players, such as payment switch providers or commercial banks. These systems would normally provide secure API endpoints to be leveraged by third-party systems like the payments administration modules of BOMS. Back-office payments administration applications are designed to securely process large volumes of payment transactions, including payment authorization, validation, and processing and are capable of handling multiple payment channels, such as direct bank transfers and mobile money. These applications enable the reconciliation of payment transactions, ensuring that payments are made accurately and on time, and that payment records are consistent with the payment channels used. Finally, the application is designed to comply with all government regulations, as well as international standards, such as PCI DSS or ISO 27001. 96 “WHAT MATTERS” GUIDANCE NOTE (v) GRM—Back Office GRM back-office applications manage grievances and complaints received from front-office applications. The application provides capabilities for managing all functions required to automate the grievance/complaint management life cycle for program administrators. This includes functions related to managing compliant tickets and managing feedback including issue resolution and escalation. GRM back-office applications provide the capability to manage cases from the moment they are registered until their resolution, and to track case status, history, and all case-related communications. These applications automate the workflow for handling grievance cases, ensuring they are handled in a timely and efficient manner, with proper escalation procedures in place and with proper notification to beneficiaries. The applications incorporate appropriate security features for data validation, secure communication, and encryption of sensitive data, while ensuring compliance with relevant data security and privacy regulations (Part 5—Governance). (vi) Data Analytics—Back Office Data analytics back-office applications provide capabilities for data mining and analysis of information required to inform social policy analysis, portfolio planning, and decision making. This includes providing reporting and analytical capabilities for portfolio monitoring. These insights support fair and transparent evaluation of the impact of social protection programs, and support efforts to proactively make policy changes in the design of social protection programs. The analytics component provides capabilities that enable administrators to define and measure indicators for each program along with tracking metrics and data points, to perform trend analysis, to generate simplified insights from complex data, and to monitor these outputs on a regular basis to assess the efficiency and effectiveness of social protection programs. Data analytics back-office applications support the intake of spatial and visual data from various sources, including databases, file systems, and APIs, and are capable of manipulating various data formats, including shapefiles, GeoJSON, and image files. They provide tools for cleaning, transforming, and enriching spatial and visual data, as well as tools for processing spatial and visual data, such as geospatial analysis, image processing, and object detection. For data analysis, the applications include tools for analyzing spatial and visual data, such as statistical analysis, data visualization, and machine learning, as well as support for various data analysis tools, such as R, Python, and SQL. They offer the ability to integrate with other databases that hold spatial and visual information relevant to the data being analyzed, such as GIS and other remote sensing data sources. C. DATABASE Information sourced from people are housed and managed in database management systems. The DSPDS database layer operates within the broader context of data integration, interoperability, and coordination with other administrative systems at the central and local level to enable sophisticated business intelligence and analytics. The architecture for data management varies significantly across countries, and there is no single model. Information systems are developed over time using different database management technologies and approaches and may be owned by different parts of an organization. As a result, data are fragmented across several hardware, Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 97 CONCEPTUAL FRAMEWORK software, organizational, and geographic boundaries. Several kinds of architectural models are possible for managing data to improve the performance of the system. (1) Countries at an early stage of developing their information systems capabilities for a whole-of-government approach may initially build a “self-contained” database to manage data for a social registry. Many such countries that have a nascent interoperability framework for data exchange operate a self-contained database management system without links to other administrative systems across government agencies or levels of government. The system is programmed to answer requests from client computers connected to a database server. Self-contained or static social registries rely largely on self-reported information from people, sourced through en masse census survey sweeps or through intake and registration forms. Self-contained databases may also store additional data and updates sourced through point-to-point integration among agencies. (2) For other countries that have whole-of-government interoperability frameworks, the social registry operates in a dynamic manner, utilizing data sourced from various agencies. Data may be sourced from other systems, replicated, and stored locally. Alternatively, data exchange protocols are built to exchange data with other systems that store data in incompatible database management systems or storage models, and that may have been developed at different points in time by different entities. The system culls data from multiple sources as if it were a single entity. The goal is to be able to view and access data in a unified way without needing to copy and duplicate it in several databases or manually combine the results from many queries. DSPDS that are connected to a “whole-of-government” architecture rely on data integration and interoperability frameworks. They facilitate the exchange of data from other administrative information systems to complement “self-reported” information from people. Examples include linking to administrative information systems, such as unique identification systems, civil registries, land or property cadasters, vehicle and driver’s license registries, tax system, social security contributions system, pensions payments system, labor and unemployment, education, and health. There is considerable variation in the database architecture of DSPDS and dSRs. The context and starting points matter, in terms of systems and institutional capacities, and the broader digital governance context. Moreover, these systems evolve over time, sometimes with small iterative improvements or adaptations, in other cases with “big bang” systems overhauls (Spotlight 1). As such, there is no single blueprint for how DSPDS databases should be structured or managed. This diversity spans many aspects. Table 5 summarizes the typology according to the structure of data management, and the degree and use of interoperability. The structure of data management varies significantly across countries, depending on the choice of data integration and the interoperability framework for whole-of-government. Initial approaches start with the building of a data warehouse that stores information from various administrative information systems sources, including various BOMS. Such systems are based on traditional data warehouse methods, and they use an “extract, transform, load” (ETL) approach to extract, transform and load bulk data from administrative information systems of the various agencies at regular intervals to provide analytics, and to answer the requests for data coming from the authorities and from research institutions more effectively, quickly, and cheaply. Changes in data are uploaded periodically (daily, weekly, monthly, and so forth), based on an agreed-upon schedule with various agencies. Changes are not constantly updated in real time, as this would affect performance and latency. Such data warehouses work well in countries that have mature information systems for tax, education, health, and the like. These approaches tend to be more intensive in terms of time, cost, and effort, as data need to be constantly kept 98 “WHAT MATTERS” GUIDANCE NOTE up to date with source data, with the added burden of securing the data that has been collected and operative systems to ensure confidentiality, integrity, and availability. Data virtualization technologies are used by countries that require agility, and where centralized data management models are not feasible for various reasons such as regulatory, time, total cost of ownership, and challenges with collecting and keeping up-to-date bulk data from other government agencies. D. DATA EXCHANGE AND INTEROPERABILITY Data exchange mechanisms play a vital role in orchestrating the flow of information between various components. These mechanisms define how data are pulled, pushed, or synchronized between systems. Depending on the context, data exchange can involve chatty or transactional data, bulk data, or hybrid approaches that combine both. The choice of mechanism depends on factors such as data volume, latency requirements, and system complexity. DSPDS are designed to serve people by facilitating trusted data sharing between various components. Data are exchanged by pulling specific pieces of information with informed consent. Keeping the social registry current is critical for a shock-responsive system, as outdated data would hinder the ability to respond promptly to emerging needs. dSR retrieve data from various systems to maintain up-to-date and dynamic records of socioeconomic data. Data exchange between IBR and social registries is critical for managing program enrollment and providing a holistic experience for individuals. This process also includes interactions with payment systems and GRM. Data exchange and interoperability frameworks require action at the political, legal, organizational, semantic, and technical levels; and in order to function and get traction, each must be underpinned by political buy-in. Participating organizations must have a common view and objective. Legally, they must comply with laws governing information, such as personal data protection, identification and trust services, e-transactions, e-commerce, digital signatures, information security, public information, and public procurement, among others. Semantically, the framework must be based on different organizations understanding the meaning of information similarly. This entails building of common data dictionaries114 (with common definitions of variables, reference units, and time reference periods), metadata, thesaurus, taxonomies, ontologies, and service registers, among others. Technically, the framework must comply with service-oriented IT architecture standards. Interoperability also requires that some sort of unique identifier(s) be included in all information systems, such that data on individuals can be properly matched up across systems (for example, via a unique identification platforms). DSPDS platform applications and services are designed using open standards to ensure interoperability between the various components and external systems. The appropriate and adequate design of the interoperability will include adopting various national and international standards and government interoperability frameworks for defining data vocabularies, metadata, data exchange formats, and messaging protocols. In this aspect, the design of DSPDS architecture and interoperability framework should also prioritize the use of open-source technologies and widely accepted data exchange standards (for example, HTTP) as much as possible, to ensure vendor neutrality and to avoid of any form of technology lock-in. 114. A data dictionary is a repository that contains descriptions of all data objects consumed or produced by the software. An organized listing of all data elements that are pertinent to the system, with precise, rigorous definitions so that both user and system analyst will have a common understanding of inputs, outputs, components of stores, and (even) intermediate calculations. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 99 CONCEPTUAL FRAMEWORK To achieve vendor neutrality, DSPDS design is based on the use of open APIs as a primary method for data exchange and interchange among the various components within and across external systems. The use of open APIs also enables the realization of one of the key architectural principles of the modular DSPDS, namely, the design of a palette of microservices, through which various social protection delivery chain functions are delivered. Accordingly, all interfaces between DSPDS front-office and back-office applications are handled through a standards-based information exchange layer based on open APIs and microservices and utilizing well-known transport protocols like HTTP. This involves the need for developing a set of mutually agreed messaging formats and data vocabularies for data exchanges between DSPDS and other external programs and systems. The technical considerations for the data exchange mechanisms include identifying the data sourcing and extraction methods, such as push/pull methods between DSPDS and relevant external systems/databases; the frequency and nature of information exchange—periodic (asynchronous) or real-time (synchronous)—and the types of data exchange formats, such as open APIs, JSON, XML, and CSV. An information exchange and interoperability mechanism might be implemented through several approaches. For instance, some countries use an enterprise service bus (ESB) architecture, while others use API gateway architectures that will manage the various microservices and enable API-based collaboration between DSPDS components and other external systems. The architecture of data integration and data management varies depending on context (Table 5). For years, integration between different systems was often point-to-point, picking up specific data from specific agencies. This approach cost considerable time and money, resulting in a spaghetti-like mess of connections between institutions. Service-oriented architecture (SOA) makes coupling between institutions loose, meaning that connections are not hardwired to the databases of other agencies. With the advent of SOA, a number of countries turned their connections or points into private APIs with public-facing endpoints to be consumed. To facilitate secure data exchange between government institutions, communication is directed via a virtual private network (VPN). Beyond data exchange, services or delivery chain processes are shared among institutions using SOA. However, this approach did not solve the problem of transforming the “spaghetti” into a unified data integration approach. To address this issue, some countries build their social registries as a data warehouse, which ingests data from multiple agencies. The integration model for such an approach depends on the volume of data and frequency of data updates, and can be summarized as follows (World Bank 2016a): DSPDS and dSR architectural models for data management TABLE 5 and data integration Data Volume of data Frequency of Integration Data security Model management update data update approach approach Self-contained Database Bulk data Infrequent None Firewall social registry Data warehouse Chatty or Frequent ESB Firewall or VPN transactional data Data warehouse Bulk data Infrequent ETL WLAN, VPN, whitelisting, SSL handshake, and so forth dSR + DSPDS Data warehouse Bulk + transactional Both ETL with VPN, whitelisting, SSL data flush & refill handshake, and so forth Data virtualization Bulk + transactional Both DV Firewall, VPN, WLAN, SSL data handshake or whitelisting, and so forth SOURCE: Authors elaboration building on Leite et al. (2017). 100 “WHAT MATTERS” GUIDANCE NOTE 1. For “chatty” or transactional data—An ESB may be used for real-time and asynchronous communication. The ESB approach allows data to be routed and orchestrated between multiple agencies, based on a queuing system for data exchange requests. An example is a credit card payment over the internet, or an individual registering for benefits. In terms of data security, this model uses a firewall or a VPN to protect the data. 2. For bulk data—Take for instance a bulk transfer of data on 10 million households. An ETL approach is used to extract bulk data from data marts of different agencies, to transform and load them up into a centralized data warehouse. This doesn’t have a “drip-drip” approach, where changes in data are constantly updated. In terms of data security, this model uses a WLAN, VPN, or other trusted connections. It tends to be a more involved and centralized approach, with the added burden of having to protect the security and confidentiality of the data that has been collected. Some countries will do an ETL for bulk data once, and then a “drip-drip” method for data that changes frequently. A “flush and refill” needs to be done periodically to ensure data are kept up to date for a dSR. 3. For bulk and transactional—Take the case of data required for computations from various sources while protecting the data. Through a data virtualization (DV) approach, data are pulled together virtually in real-time from different agencies and databases, without consolidating them in a centralized data warehouse managed by one agency. This approach also allows sensitive data from agencies to be masked. In terms of data security, agencies could use a firewall, VPN, WLAN, SSL handshake, or whitelisting. This is a more agile approach when a more centralized approach is not feasible for various reasons, such as time, total cost of ownership, challenges with collecting and centralizing bulk data from other government agencies, and so forth. 4. For a hybrid approach—Complement a centralized data warehouse with data virtualization, to include additional data, and extend the existing investment in a centralized data warehouse. Centralized data warehouses are useful for physically consolidating and transforming large volumes of data from various sources. When they are outpaced by the frequency of data updates, it proves challenging to keep large and centralized data warehouses current. In such instances, a hybrid approach may be useful. dSR that have considerable interoperability have developed sophisticated methods of data integration, such as using ETL for bulk data transfer on a periodic basis, with real-time links to transactional data updates as well as a “flush and refill” to capture most current data updates from other administrative systems at the national and local level. There may also be some private APIs and database links to connect point-to-point with some agencies. Agencies with added capacity use an ESB to exchange transactional data that changes frequently. These data integration approaches are usually seen in countries that have invested in in-house capacity, have strengthened their ability to support the implementation of more sophisticated information systems, and have developed an interoperability framework for government agencies. Often, these social registries operate within DSPDS, with active links to beneficiary registries, and within numerous other administrative systems. Examples include Chile’s Social Registry of Households, which operates within the Integrated System for Social Information (SIIS), and Türkiye’s Integrated Social Assistance System (ISAS). • Türkiye ISAS has a considerable degree of interoperability with other systems. ISAS is integrated with 24 institutions online via web services, and also uses a data warehouse for bulk transfer of data through ETL. The unique identifier and a PIN provide two-factor authentication and the key for linking across these systems. Examples of information systems that are linked to ISAS include beneficiary registries of various programs, population and citizenship registry, household registry, social security, revenues administration, vehicles, land registry, farmer registration, health control information, education (school attendance, grade transition, and so forth), and the employment agency, among others. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 101 CONCEPTUAL FRAMEWORK • Chile RSH also has a considerable degree of interoperability with other systems. The flow of administrative data to the RSH is done through batch processes, on a monthly or annual basis depending on the source of the data. These exchanges are carried out using the Secure File Transfer Protocol (SFTP) or through a VPN. The flow of data from the RSH to other public services occurs through different mechanisms, depending on the needs and technological capabilities of each one. The options available for these exchanges are web service, batch processes, or one-to-one consultation through a web interface. Public services can use all the mechanisms they require. • Colombia RSH utilizes several approaches to exchange data with national and territorial systems, including VPN site-to-site, web services, Xroad, FTP, and in batches. A virtualized data management model provides the advantage of agility for data integration and a high degree of interoperability. Centralized and intensive data integration methods prove tortuous when there are a huge number of data sources as well as attributes that must be sourced, and frequent updates need to be managed near real-time, to improve the quality of data and therefore eligibility determination. This approach is seen in countries that have strong in-house capacity, the ability to support sophisticated information systems implementations, and well-developed integration and interoperability frameworks. In a virtualized data management model, data from various administrative sources are not physically moved to the agency that is the custodian of the dSR; instead, data are virtualized for the purpose of assessment of needs and conditions. This approach is helpful in countries where institutions are unwilling to participate in creating a large, centralized store of data. Such unwillingness may be related to governance concerns, for example in the case of a large, federated form of government or island states with a large geographic spread. Other concerns may relate to data protection and security, the risk of data becoming quickly outdated when it is replicated in a centralized data store, or concerns with scalability. The data virtualization approach offers considerable improvements in updates and cross-checks to validate and verify data, with real-time and dynamic decision support. Protocols must be in place to address issues arising from data conflicts between dSR and its interoperability with other DSPDS systems. In some countries, the software application will display red flags or warning messages signaling the need for verification, updating, or rectification, which are then cross-checked with the individual or designated representative of the household orally when they meet the social worker, mobile teams, the service center, or other frontline staff. In countries such as Chile, there are protocols for data updates and rectification. The data point with the most recent timestamp is given precedence and is then cross-checked with the individual or household to verify orally at the point of intake and registration, or when they meet the frontline staff. In Türkiye, the system alerts administrators when there are data conflicts, using a task-list with action items. Data sharing protocols, legal agreements, and memoranda of understanding (MoUs) are developed between social programs and custodians of data in dSR and DSPDS. A core principle governing these agreements is that systems share only specific information needed for the agreed purposes with legitimate social programs to protect data privacy and confidentiality (that is, just the agreed minimum set of variables needed for user programs to take their decisions). Data sharing agreements should be clear on the agreed and specific use of the information to be shared, exact types of information to be shared (specific variables, time periods, and so forth), specification of confidentiality and security principles and safeguards, specification on specific users and their access levels, and so forth (Part 5—Governance). 102 “WHAT MATTERS” GUIDANCE NOTE E. INFRASTRUCTURE Over time, DSPDS component systems will likely undergo several changes on account of legal and regulatory frameworks, modifications in governmental processes, and the constant evolution and developments in computing and storage technologies. Ensuring the resilience and reliability of the DSPDS platform, including the information and communication technology (ICT) infrastructure, is thus extremely crucial. It is also essential to allow for ease in the manageability of these changes. The digital infrastructure must be designed for resilience against hardware and software failures and avoidance of any single point of failure with minimal human interventions. The infrastructure should also support the continuous monitoring of components and services within the DSPDS platform to ensure adequate integrity of data and uninterrupted availability of business processes. While the technology infrastructure layer is not illustrated in Figure 23, as it is highly context specific, it is important to keep in mind when designing DSPDS. Technology infrastructure refers to composite hardware, software, network resources, and services required for the existence, operation, and management of an organization’s IT environment. It can be as simple as setting up IT equipment (servers, network, storage, power supply, and cooling) in a room onsite, or as complex as commissioning a data center in a warehouse-style building. Typically, a data center to support sophisticated operations includes the following components of ICT infrastructure: • Facilities—including electrical power utility grids, UPS (uninterrupted power supply), back-up generators, power distribution units, automatic transfer switches, cooling equipment, and emergency response equipment for events such as a fire or floods. • Server equipment—including servers mounted on racks and cabinets (physical and virtualized). • Networking equipment—including routers, ports, switches, load balancers and link technologies (copper/fiber cabling). • Storage equipment—arrays mounted on racks and cabinets. • Security—including physical monitoring and controls for onsite access such as keycards, locks, hardware security modules, biometric verification such as retina scanners, motion sensors, closed-circuit television (CCTV), and virtual controls to secure access to networks, servers, and applications, and ensure the securing and protecting of data by making sure they are kept confidential, integral, and available, notably against cyber- threats, including hacking, unauthorized monitoring data modification, intrusion prevention, and targeted threat detection (World Bank and United Nations 2024). Several governments are moving toward a shared data center approach to manage the time and cost of procurement, investment, and operations and to achieve economies of scale for government as a whole. Fragmentation of programs has resulted in duplicate investments in software applications, databases, and technology and communications infrastructure across and within government agencies. Some governments opt for a cloud-based approach (Infrastructure-as-a-Service, or IaaS), to minimize procurement, investment, and operations costs, and to take advantage of potentially unlimited computing power, considering that this approach also entails a loss of control as well as additional security concerns. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 103 CONCEPTUAL FRAMEWORK SPOTLIGHT 3 INDICATIVE FUNCTIONAL OVERVIEW AND REQUIREMENTS FOR dSR A key feature of social registries is the degree to which they support dynamic inclusion. By means of a dSR, which supports the principle of dynamic inclusion, anyone can register or update their information at any time, without a priori guarantee of eligibility for specific benefits. The window for registration is open and continuous, usually with on-demand applications, and ideally with simple “user friendly” intake, registration, and data updating procedures, underscoring the salience of taking a human-centered design approach in maintaining dynamic data flows that are demand-driven, consent-based, and shock- responsive. dSRs are relevant for the human rights agenda and the progressive realization of universality: anyone who needs social protection can access it at any time. The dSR acts as a central repository and service platform for household socioeconomic data, intermediating between people (applicants/registrants) on the one hand, and programs and service providers, on the other hand, facilitating the efficient management and distribution of social benefits. It integrates various components, such as user registration interfaces, assessment modules, and data exchange protocols, and interoperates with many more. The system is designed to interact seamlessly with other government databases and social programs, ensuring accurate and timely data processing, while also following data protection-by design and by-default procedures. This Spotlight provides a detailed and structured approach to designing a dSR, emphasizing flexibility, data integrity, user-friendliness, and integration with existing social programs and data providers. This approach is aligned with the need for effective and efficient social program administration, ensuring timeliness and transparency. Pre-requisites to building the dSR: • The dSR is overseen by an “Authority” with a diversity of institutional models for operations and management seen across different countries. Some are managed and operated by a central social agency, such as the Ministry of Social Development (Azerbaijan, Chile, Djibouti, Georgia, Indonesia, Macedonia, Mauritius, the Philippines, Senegal, Sierra Leone, Türkiye). Some are managed by a central social agency but are operated by a separate operating agent (Brazil, Mali, Montenegro). Others are managed by some other central agency with transversal appeal or an autonomous authority (Colombia, Dominican Republic, Morocco, Togo). Some are managed and operated by a specific social program (Pakistan).115 • Data in the dSR are linked to the assistance unit—individuals and/or households. Individuals within the system are assigned a unique identifier, serving as their personal identifier through a unique identification system. For households, a household identifier (HIN) is used, linking each household with its socioeconomic data. 115. See Karippacheril and Leite (2019), presentation on “Integrated Social Information Systems and Social Registries.” 104 “WHAT MATTERS” GUIDANCE NOTE • Welfare assessment methodologies are developed collaboratively to reflect the socioeconomic status of the assistance units. The definition of a household and the criteria for its registration and assessment are determined by the country’s specific policies and programs’ needs, which may require every household member to have a unique identifier for registration in the dSR. The system is inclusive, with provisions for polygamous households through specific coding structures. By focusing on the term of “household” as opposed to that of “family”, many otherwise potential legal issues might be mooted. • Comprehensive registration data needs to be collected, encompassing geographical, personal, socioeconomic, and sociodemographic information. The “Declarant”, typically the household head or an authorized adult, plays a key role in the registration process. Households have the flexibility to register, update, or unsubscribe from the dSR at any time, although this does not automatically ensure eligibility for social programs. A crucial aspect of the system is the obligation placed on households to maintain the accuracy of their data. Households are required to affirm the accuracy of their data, with this information subject to verification and cross-checks to uphold the integrity of the system. • The dSR allows for one or multiple types of welfare assessments including: “declarative” based on initially reported data, and “verified” derived from corrected and validated data. The methodologies also establish the assessment’s validity, update mechanisms, and the parameters involved, ensuring a standardized and equitable assessment process. This regulatory oversight is crucial for the integrity of the system, accurately mirroring each household’s socioeconomic status. • The welfare assessment methodologies utilize several variables of the socioeconomic data sets of dSR: ‘Geographical Code’ relates to the household’s location in administrative divisions; ‘Household Characteristics’ include demographics like gender, age, and education; ‘Household Demographics’ examine the household’s size and age composition; ‘Dwelling Conditions’ detail the housing type and amenities; ‘Accessibility to Basic Services’ assesses the availability of essentials like water and electricity; ‘Household Expenses’ include utility and communication costs; and ‘Possession of Goods’ assesses ownership of durable items and vehicles. These variables (non-exhaustive) collectively provide a comprehensive picture of a household’s socioeconomic standing in the dSR system. Functional Overview of dSR: The dSR system has specific services and functions designed to support social programs and handle data effectively. The system provides lists of households that meet certain eligibility criteria to social programs. It also ensures that decisions about who is eligible are shared correctly and efficiently through a specific portal meant for individuals and households. Key functions include: 1. Individual or Household Registration: Individuals and households register in the dSR by providing necessary personal, socioeconomic, and demographic information. The registration process includes steps for data entry, validation, and the assignment of a HIN. Codes for polygamous marriages, household composition, and data updates are integral parts of this process. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 105 CONCEPTUAL FRAMEWORK 2. Assessment of Needs and Conditions: The dSR assesses the needs and conditions of each household or individual based on one or multiple predefined methodologies (see section A.iii of Part 3). This process involves assessing the welfare of registrants based on various variables such as demographics, geographical location, household composition, education attainment, dwelling characteristics, assets, and access to basic services. The welfare assessment methodologies may include both declarative and verified data and must respond to the policy objectives and program needs of the particular country or context. 3. Eligibility Determination and Criteria Management: Eligibility for social programs is determined based on the assessment of needs and conditions and other eligibility criteria set by the respective programs. The dSR manages these criteria, updates eligibility statuses, and ensures accurate targeting of beneficiaries. 4. Data Exchange with Social Programs: The dSR facilitates data exchange with various social programs, providing them with lists of eligible households based on set thresholds. It supports real-time information sharing and manages incompatibilities and technical rejections effectively. 5. Data Updates, Un-subscriptions, and Complaints: The dSR includes mechanisms for regular data updates, household un-subscription processes, and handling of complaints and grievances. These processes ensure the accuracy and currency of data, as well as transparency and accountability in the registry operations. The dSR includes a user-friendly interface for households (front office) as well as interfaces for managing the system’s operations (back office). It allows for easy sharing of data and works well with other applications. The system manages important tasks like user registrations, updating data, and checking eligibility. Additionally, the dSR can handle many users at once, manage workflows, and is set up to integrate with future applications. It ensures that data are handled correctly and according to regulatory standards and a data protection-by-design and by-default approach. The dSR is designed to be easy to use, provides up-to-date information, and includes tools for analyzing data. It also supports efficient management of documents and has different environments for development, testing, and production. Functional Requirements of dSR: 1. Repository Management: This involves the establishment and maintenance of administrative parameters critical to the system’s operation. It includes comprehensive user management for account creation, modification, and deletion. Profile management allows for customized access and functionalities for different user roles. Authorization management ensures secure access control. Log management is essential for tracking system activity, while connection monitoring and update audits are integral for maintaining system security and ensuring the accuracy and efficacy of system updates. 106 “WHAT MATTERS” GUIDANCE NOTE 2. Registration: i) Pre-Registration on the Portal: In this process, household declarants initiate registration by entering their unique identity number in the dSR portal. The system verifies the unique identifier’s authenticity and format. The declarant then fills out an online form, designed for user convenience with options to save and resume later. An optional step allows for uploading supporting documents. Once the form is completed, the system reviews it for accuracy and schedules an appointment for manual submission of the application and physical completion of the registration process. ii) Manual Registration at dSR Counter with Pre-Registration: Here, declarants who have pre- registered online present their forms and documents at the dSR counter. Counter agents verify the declarant’s unique identifier before frontline administrators enter the data into the system and scan the supporting documents, issuing a receipt to the declarant. Back-office administrators then conduct a detailed review of the data, including Electronic Know Your Customer (eKYC) compliance and household uniqueness checks. Applications with discrepancies are rejected with clear explanations, while successful ones result in the assignment of a unique HIN and the creation of a corresponding account on the dSR portal. iii) Manual Registration at dSR Counter without Pre-Registration: For declarants without pre-registration, the process involves directly submitting a manually completed form with supporting documents at the dSR counter. The counter staff verify the identity document of the household declarant. A frontline administrator then enters the household information into the system, performs verification, scans, and uploads the supporting documents, issuing a receipt upon completion. Back-office administrators conduct checks for data accuracy, including data consistency and eKYC verification. Applications that fail these checks are rejected with reasons provided, while successful applications lead to the assignment of an HIN and the establishment of a dSR portal account for the household. iv) Online Registration at dSR Portal: This fully online process allows the declarant to access the dSR portal, enter their unique identifier, and undergo an authentication process. The declarant then fills out the dSR form with comprehensive household member information. The system performs checks on the data for each member. A receipt is issued upon submission. Back-office administrators review the application for data consistency and uniqueness of the identifiers of registered household members, relying upon authentication services undertaken by the unique identification system. Applications with errors are rejected with detailed explanations, while successful ones result in HIN assignment and the creation of a personalized space on the portal for tracking the application’s progress. 3. Data Exchange, Assessment, and Notification Process: The dSR system initiates data exchange by requesting information from data providers like telecom, water, electricity, and motor vehicle authorities. Received data are used to verify or validate household-reported information. These Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 107 CONCEPTUAL FRAMEWORK requests are sent to local dSR units in administrative divisions for verification, sometimes involving field investigations. The local dSR unit head inputs investigation outcomes, correcting data as needed. 4. Data Exchange with Social Programs: Each social program has a specific exchange protocol with the dSR covering application frequency, management of incompatibilities, and technical rejection conditions. The dSR provides real-time information on households meeting eligibility thresholds, considering updates and opt-outs. Social programs are notified of changes in household eligibility, with households having recourse against eligibility status changes. Social program managers can request statistical data and lists of households meeting specific criteria from the dSR. i) Process for Data Exchange with Social Programs: Social program managers request lists of eligible households from the dSR, specifying eligibility thresholds and criteria. The dSR compiles and sends these lists, which are then reviewed by program managers for additional criteria compliance. The dSR receives final lists of eligible households from social programs, including eligibility expiry dates, and can convey updates as per each program’s policy. 5. Managing Eligibility Requests: The dSR incorporates eligible households into its system, allowing social programs to verify member eligibility for benefits and services. A secure gateway interfaces with social programs for verification services. This gateway is a “trusted service provider” that connects directly to the dSR, handling authentication and eligibility verification requests with social programs. i) Process for Managing Eligibility Requests: Social programs send verification requests to the gateway, which forwards these to the unique identification system for authentication. The unique identification system processes and returns the response, after which the dSR verifies eligibility and communicates back via the gateway. 6. Managing Data Updates: i) On Demand by Households: Households can request updates to their data, triggering different processes based on the type of data. Identity data updates are redirected to the unique identification system, where an exchange protocol with predefined frequency allows the dSR to retrieve updated demographic and contact data. For socioeconomic data updates, households have options for manual or online processes. ii) Manual Submission of Update Requests: Households submit update requests at the dSR counter with supporting documents. The dSR agent verifies the identity of the household declarant, checks the request’s completeness, and updates the data in the system. If the update influences the welfare assessment, it is processed as a new request; otherwise, the dSR makes the update directly. iii) Online Application of Update Requests: Declarants can submit updates through the dSR portal using their unique identifier login. After filling in the online update form and uploading documents, the system validates the request. dSR agents review online requests and may 108 “WHAT MATTERS” GUIDANCE NOTE require declarants to visit in person for additional information. Updates impacting the welfare assessment are treated as new requests. iv) Updating the Composition of the Household: For changes in household composition, declarants visit the dSR counter with relevant documents. The dSR system performs checks like eKYC and verifies the new member’s details. Members are added or removed based on the rationale provided, influencing the household’s welfare assessment recalculations. Households and social programs are notified of these changes. v) Periodic Automatic Updates: The dSR periodically sends requests to data providers for updates. Updated data may lead to recalculations of the welfare assessment and notifications to both households and social programs. If a social program requires a new eligibility list, the dSR recalculates the welfare assessment and provides updated lists. vi) Update Following Expiration of Welfare Assessment: Before the welfare assessment expires, households are notified to renew their registration in the dSR. A new welfare assessment is applied, and social programs decide on the continued eligibility of households that have not renewed data. 7. Managing Un-subscription from dSR: i) Online by Household Declarant: Household declarants can unsubscribe online via the dSR portal. The process involves data entry, document uploads, and a review by dSR agents. Un- subscription of minors may involve field investigations. Validated requests lead to recalculations of the welfare assessment and notifications to social programs. ii) Online by Any Adult Member of Household: Adult household members can unsubscribe online, following a similar process of authentication, data entry, and document uploads. The dSR recalculates the welfare assessment and informs social programs upon validating the request. iii) Paper by Declarant of Household: Declarants can also unsubscribe at the dSR counter. The process includes identity authentication, data entry, document uploads, and a review by dSR agents. Field verification for un-subscription of minors may be conducted by social workers or agents. Once validated, the dSR updates the welfare assessment and informs social programs. 8. Complaints Management Process: i) Online: Households can file complaints within a set period either online or at dSR counters. Technical complaints are handled by the portal and CRM solution. For complaints about eligibility decisions or welfare assessments, declarants upload supporting documents online, and dSR agents review and address these complaints. ii) In Person: For paper-based complaints, declarants present their claims at dSR counters. Similar to online, the process involves data entry and document upload, with dSR supervisors reviewing and addressing the complaints. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 109 CONCEPTUAL FRAMEWORK 9. Fraud Handling Process: Machine learning models segment risk profiles and detect fraud, which dSR managers handle. The system analyses data for fraud exposure, categorizes detected cases, and decides on appropriate actions. Fraud recovery may involve field surveys or document rectification. The dSR updates relevant parties on these changes and continually refines the fraud handling process. 10. Components of the dSR: i) Front end (dSR Portal): Features a CRM module for filing and tracking applications, personalized information spaces, online service (for filing of applications, resuming data entry, monitoring the processing of requests, consulting and updating data, filing and monitoring complaints, making appointments for submission of paper files), content management module, chatbot agent, and SMS/ USSD notification engines. ii) Back office (dSR Administrator Module): Includes profile management, request processing areas, review and validation spaces, scoring areas, claims management, un-subscription management, and tools for automatic updates and exchange monitoring. iii) Assessment Module: Functions independently, assessing needs and conditions and managing their history. It is designed to be open and configurable. iv) Additional components include customer relationship management (CRM), business intelligence/ analytics, electronic exchange platforms, fraud detection tools, and document management systems. Technical Requirements of dSR: The dSR system is architected with a set of comprehensive technical requirements to ensure optimal functionality and user experience. These requirements include: • System Performance: The system is designed for high performance and reliability, ensuring smooth and efficient operation. • Security and Privacy: Robust security measures including data encryption and secure access protocols to safeguard sensitive information adhering to data protection regulations and with data protection-by-design and by-default throughout. • Scalability: The system is built with scalability in mind, ready to accommodate future growth and adapt to evolving needs. • Multi-language Support: To cater to a diverse user base, the system includes support for multiple languages, including various local languages. • Mobile Accessibility: Special emphasis is placed on mobile accessibility, particularly for users in remote and rural areas, to ensure broad reach and convenience. • User Interface: User interfaces are thoughtfully developed to be human-centric and optimized, featuring both personalized and public information displays for ease of use. 110 “WHAT MATTERS” GUIDANCE NOTE Part 5 Governance Robust legal and institutional frameworks are needed to ensure interoperability across DSPDS, as well as to make sure that processed data are well governed, managed, and generally kept secure. Those frameworks— which themselves underpin social protection policy frameworks (Part 1—Core Characteristics), need to be solidly rooted in law, institutionally anchored, and then further detailed and developed through appropriate regulatory instruments. Depending on the country—and, notably, whether it has a unitary or federal system of government— those arrangements may require a varied mix of legal and institutional elements, and possibly implementation by or the implication of different authorities. For instance, some countries—such as Chile, Türkiye, and the United Kingdom,116 which are unitary states—rely on centralized regimes that retain responsibility for core fiscal, institutional, and legal measures, even as they decentralize or devolve many responsibilities and activities, to varying degrees. In other countries—such as Brazil, India, and the United States, all of which have federal systems of government—individual states are largely responsible for delivering social protection programs. In such instances, there might be significant degrees of variability, both in approach and in performance. The distinction between unitary and federal may not always been clear cut: for instance, South Africa’s system of co-operative governance has led it to be considered a quasi-federal state, with its unitary structure taking on federal tendencies (OECD 2016). A strong legal framework is a necessary, but not sufficient, condition for a comprehensive, rights-based, effective, and well-governed social protection system; regardless of the country’s constitutional makeup or system of government, legal frameworks supporting DSPDS ought to be made malleable, which might require certain innovations. Legal frameworks need to support and enable the creation of dynamic systems capable of processing data from divergent sources and from various levels of government. They need to do so with the appropriate degree of sensitivity and security, creating sufficient oversight and safeguards. Ideally, the underlying constitutional and solid legal framework protecting, among other things, social protection rights and regulating 116. The United Kingdom is renowned for not having a single, written constitution codifying the laws and rules that, among other things, create the institutions of the state. While the United Kingdom is composed of four nations—England, Northern Ireland, Scotland, and Wales, each of which has received an increased degree of autonomous devolved power—power has been delegated by the Parliament of the United Kingdom, which might unilaterally enact laws altering or even abolishing said devolution. See, for example, Torrance and Horswell (2003). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 111 CONCEPTUAL FRAMEWORK the implementation of social protection schemes would be ensured at the national level. Such might not, however, be entirely possible for all pieces of the DSPDS framework, and much will depend upon the particular component and need, potentially leading various pieces of the DSPDS framework to take on different aspects or appearances, depending on the country’s system of government and context. For instance, as already discussed, a key element of the DSPDS framework is a unique identification system. In federated states, creating such a single foundational system might not be directly possible, but might yet be assured by relying on provincial sources as the base resource and creating a central means of interconnecting them. For instance, Argentina, having no single, unified repository of civil registration records, and with each civil registry instead being maintained by an office in the municipal district, ensures a foundational unique identification system upon which social protection programs might rely by creating a central authority, the National Registry of Persons (Registro Nacional de las Personas, or RENAPER). RENAPER has exclusive responsibility for the National Identity Document (Documento Nacional de Identidad, or DNI) and passport, but otherwise relies upon the civil registries for its robustness. It connects provincial civil registries through a secure platform that allows for the sharing of certificates using digital signatures that ensure the security and authenticity of documents (World Bank 2020a). This central registry has allowed for the emergence of nationally supported programs, including shock-responsive ones, such as the Emergency Family Income (Ingreso Familiar de Emergencia, or IFE), a non-contributory benefit of an exceptional nature launched in 2020 to compensate and protect individuals whose income had been severely reduced or lost due to the COVID-19 pandemic (Republic of Argentina 2020). While the vast majority of the social protection programs now rely upon the DNI, provincial programs had traditionally relied upon the civil registries for identification purposes. As a result of this and other factors, Argentina is very largely a success case when it comes to social protection coverage, even as the nature of that coverage is in many cases fragmented, and with numerous provincial laws and regimes further complicating the overall framework. Strong institutional arrangements and coordinating mechanisms are essential to good DSPDS social protection governance, and institutional players implementing DSPDS ought to support whole-of-government vision, while also being whole-of-society looking. Responsible institutions should operate predictably and responsibly, while also being people-centric and capable of adapting to community needs and interests. Sufficient space should also be given to ensuring that collaboration and coordination extend beyond governmental stakeholders to include the private sector, civil society, academia, and others. Doing so will improve performance, ensure legitimacy, grow trust, and, as a result, increase the viability of DSPDS’s dynamic and interoperable framework. From a practical perspective, these efforts should be countenanced early in the process of elaborating the legal and institutional frameworks. Such an outlook and approach are important to have, regardless of whether the instrument in question is to have national, provincial, or sectoral arrangements, as all will have varying implications. System interoperability paired with good data governance and management reduces costs and improves efficiency, value, and delivery, boosting effectiveness and beneficiary wellbeing. Interoperable DSPDS allows for coordinated yet decentralized social protection delivery. While varying configurations exist, attention— regardless of where inspiration is drawn from—should always be given to the specific context at hand. That attention might be periodically attuned through comprehensive and continuous (or at least periodic) consultation with stakeholders (at all levels, including beneficiaries), effective and transparent policy implementation, and demonstrated accountability. Doing so allows for better and more tailored delivery, increased efficiency, and enhanced efficacy, thus making for greater program success and improved beneficiary wellbeing. Where the legal and institutional framework implicates many actors, be they public or private, consideration ought to be given to make the whole of the legal fabric increasingly coherent and less fragmented. Such concerns are particularly 112 “WHAT MATTERS” GUIDANCE NOTE important in federated states, but also in those countries that rely upon the private sector (typically done through incentive schemes) to deliver social protection. If the technological promises offered by DSPDS are to be realized, and for people and programs to optimally benefit, then real-world engagement with multiple stakeholders—in each given context—is needed in the collecting, exchanging, and wider processing of data. There are at least two elements to keep in mind in this regard. First, the solution is not purely one of technical design, neither from an IT, nor a legal perspective. As such, the connection and interface with the particular context—and with each individual person—is no less important than the “construct” and “design.” Even the “perfect” technical solution will have only limited success if insufficient attention is given to the person, an objective sought to be achieved by taking an HCD approach (Daly and Karippacheril, forthcoming). Second, these systems rely on data. While a number of different aspects require attention in order to ensure that the wider DSPDS framework is well governed, one particularly important realm is that of data governance, as DSPDS run, in many ways, “on” data.117 As discussed, data are values or a set of values representing a specific concept or concepts (Part 2—Data).118 Because data are representative, they are by nature non-rivalrous goods that—if safeguards and enablers are properly established—might be repeatedly used and repurposed. That repurposing increases marginal returns and generates welfare-enhancing economies of scope (World Bank 2021, Chapter 6). Such a vision and approach helps to “grow the pie” for all. Data must be accurate—and must be kept accurate—in order for them to be optimally beneficial; otherwise put, and as frequently quipped, the result of not doing so is “garbage in, garbage out.” Both the overall DSPDS framework and each of its component systems must be able to be genuinely dynamic and regularly updated, preferably through automated (though overseen) channels. Ensuring data accuracy is typically a requirement set down in law; so, too, is the right of beneficiaries to be able to update their information. Such obligations are typically only understood to be met when beneficiaries are able to (easily) access and update their information, a matter facilitated, again, by taking a HCD approach. As a backstop, GRM might function as an additional channel for raising data-related concerns, including issues relating to the updating information; however, GRM ought only to be understood as a backstop, not as the core, constitutive solution to the issue. As with other data protection requirements, failure to rectify inaccurate data is not only a violation of an institution’s legal obligation but can also have very real and important consequences for beneficiaries, including denial(s) of eligibility and all that might entail. Relatedly, beneficiaries should not be subject to a decision based solely on automated processing: where automation is introduced, it is essential that, first, the beneficiary is aware that such tools are being used, and that no final decision will be made by those automated tools. There are also important anti-fraud and security reasons for not entirely allowing an entirely automated process (World Bank 2024). Technological developments, notably artificial intelligence (AI), have made data accuracy even more essential, as assessments and learning—even if not automated—are made on the basis data. Beyond accuracy, missing or sparse data—particularly for the poor and vulnerable—may lead to algorithmic exclusion, undermining the governance and performance of DSPDS. Algorithmic exclusion can be understood as the risk of excluding people from algorithmic predictions that may benefit them because of lack of data (Tucker, 2023). Missing or sparse data on a particular population group can be the result of the same factors that lead to societal inequality. Disadvantaged groups, such as the poor and vulnerable, the disabled, or the internally displaced, among others, are less likely to be represented in the data used by public and private entities that may want to 117. While data may be a key driver of the digital economy, there are significant limits to the analogy of data as the “new oil”, which phrases such as “running on data” might be seen as implying. See, for example, Viljoen (2020a, 2020b). For more on the non-rivalrous nature of data and its potential to be processed and re-processed, see, for example, World Bank (2021). 118. See also World Bank (2016b). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 113 CONCEPTUAL FRAMEWORK offer services to them. As such, from the DSPDS perspective, dynamic inclusion is fundamental to mitigate the risk of algorithmic exclusion. This means ensuring that unique identification systems and dSR have near-universal coverage among disadvantaged groups so they are “visible” to the welfare assessment algorithms that will be used to channel benefits and services to them. Achieving such ends can be supported by reducing both legal barriers (for example, nationality or residency requirements for registration) and procedural barriers (for example, requirements to present certain documents, such as a birth certificate, or the need to present several documents). It bears noting that supporting universal-coverage in both unique identification systems and dSR ought generally not to be considered as problematic, as inscription does not amount to either rights-accrual or to the accordance of benefits: unique identification systems, on the one hand, serve simply to ensure an individual’s uniqueness, and dSR, on the other hand, supports eligibility decisions but does not itself guarantee the according of services and benefits by social protection delivery programs. How well different population groups are represented in DSPDS and how data are distributed amongst them is thus an important concern to keep in mind when thinking of the governance and performance of DSPDS. Awareness raising—both of the nature of the programs and systems, but also of the rights and responsibilities set out under the law—are essential to rendering DSPDS component systems genuinely dynamic. In order for inclusive measures—and notably legalistic barrier-lowering efforts—to be effective, they must also be accompanied by awareness raising. For instance, in Côte d’Ivoire, successive legislative initiatives to open up the civil registry to exceptionally allow those not born in the territory of the country to register, and thereby to make it a more inclusive and robust unique identification platform, fell short, with criticism being directed, among other things, at the nature of the community sensitization that was undertaken. It is incumbent upon the authorities to sensitize their populations not only to the programs but also to more generic, non-program, specific matters. These include the importance of data accuracy, including its potential implications, and the need to make transparent the means through which certain program aspects, such as assessment of needs and conditions, are conducted. Such are key aspects to ensuring that DSPDS and component systems retain dynamism, as so much of the process relies not only upon the initial institutionalization and set up but also on user engagement. Awareness raising will also help to grow digital literacy and capacity. DSPDS component systems must be accessible in order to grow engagement and ensure their good governance. Accessibility implies a number of things depending upon the audience and individual. “Ease of access” implies many things, including whether the systems are available (for example, rights might be realized through a number of pathways, including website, phone, front-office), comprehensible (for example, intuitive in their layout and functioning), and useable (for example, not requiring overly specialized knowledge or devices). In this regard, additional governance lessons might be learned from the disability-inclusive development agenda. For instance, incorporating technologies directed to ease the burdens of those having certain limitations or disabilities (for example, visual impairments, hardness of hearing) not only increases inclusion but also tends to significantly benefit those who do not have such limitations or disabilities. Taking a HCD approach will help to ensure that there is understanding both on the side of the administrators and on the beneficiaries of incumbent rights and responsibilities, while also facilitating access to the services and benefits. A particular application of the design-thinking approach, HCD is an exercise of trying to walk in the footsteps of the users of the systems (Annex 3).119 The multi-disciplinary HCD approach works to solve the needs and problems of the end user—that is, the individual person. It passes the design process through a series of steps in order to improve the chances of arriving at a better solution. As it incorporates the development of “personas” 119. See also the HCD Toolkit (Daly and Karippacheril, forthcoming). 114 “WHAT MATTERS” GUIDANCE NOTE (that is, composite characters representing a distinct group according to their attitudes, frustrations, needs, and aspirations) of those likely to rely upon the services, the HCD approach can help to ensure that interventions are better adapted to the specific needs and constraints at hand. The proposed interventions and processes might then be tested with these diverse groups (Lindert et al. 2020). In this global and digital age, DSPSD have a heightened role to play in maintaining—and even mending—the social fabric, particularly in ensuring the equitable application of the social contract on data. Due to both the nature and the sheer amount of data that they help to manage and manipulate, DSPSD play an important and growing role in ensuring the equitable application and measured enhancement of the social contract around data in economic growth. which, in turn, will grow coherence and foster trust—trust in the individual actors (be they public or private), trust in the wider DSPSD framework and ecosystem, and trust in the ever-growing digital economy as whole.120 The notion that societies engage in social contracts is widely accepted.121 Legal systems, and governance regimes more generally, serve as vital instruments for establishing, facilitating, and enforcing those social contracts; and addressing information asymmetries and ensuring transparency is a particular point of concern. Poor data and/or system governance risks aggravate inequities and present enormous reputational and trust consequences. DSPSD operate in the back-end manipulation and management of data, but they also are often the frontline points of interaction between larger policies and schemes with individuals and communities. Therefore, governance failures risk endangering lives and compromising the entire framework, and more. This Part of the Playbook aims to offer an overview of core governance functions, as well as to present the means by which the various stakeholders involved in the DSPDS governance ecosystem participate and contribute. Recognizing that there is no one-size-fits-all solution, this Part is neither prescriptive nor exhaustive, and attempts to focus on data governance particularly as it applies to the DSPDS context. It begins with (A) an examination of the core elements of strategic, “high-level” governance matters needed to safeguard and enable trustworthy data exchange and processing, with special attention given to the legal underpinnings. It then proceeds to (B) a consideration of the institutional arrangements needed to interface with people, programs, and databases so as to streamline access, coverage, and take-up of social protection and to promote inclusion, with the HCD approach as a guiding design principle. Finally, in (C), the operational dimension is addressed, with the nature of interactions among people, programs, administrators, and the underpinning technology of DSPDS being explored. A. STRATEGIC (“HIGH-LEVEL”) This section on strategic governance for DSPDS begins with two general parts: (i) policy-setting and orientation and (ii) establishing basic legal foundations. Given their particular applicability, separate attention is paid to the matters of (iii) data protection and privacy and (iv) consent. (i) Orientation and policy-setting Strategic—or “high-level”—governance refers to mapping out the basic legal texts and institutional structures needed to create sustainable, synergistic, and interoperable DSPDS. Such “chart-setting” is typically done through policy instruments that provide a vision for DSPDS design and implementation, as well as the place for setting of objectives, priorities, and goals. The processes for engaging with the wider governance ecosystem— 120. The Playbook builds on the position announced in the World Development Report 2021: Data for Better Lives, namely in its call “for a new social contract for data—one that enables the use and reuse of data to create economic and social value, promotes equitable opportunities to benefit from data, and fosters citizens’ trust that they will not be harmed by misuse of the data they provide” (World Bank 2021). 121. Thomas Hobbes, John Locke, Jean-Jacques Rousseau, and other moral and political philosophers have written extensively on the idea or theory. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 115 CONCEPTUAL FRAMEWORK understood as referring to the arrangements, structures, and standards that enable the secure and timely collection, processing, sharing, use, updating, and destruction/deletion of data across a variety of institutions— ought to be detailed here. With that backdrop, determinations of underlying policy decisions are made, as well as institutional arrangements (including assigning roles to existing and/or new entities) and other oversight and feedback mechanisms considered. The policy instruments elaborated at this point often play a key role in securing political commitment and high-level buy-in needed to align the DSPDS with social protection policy; as such, they typically detail safeguards and enablers, as well as corresponding resource allocation.122,123 In order to achieve these aims, it is important to entrust responsibility for policy orientation with an authority, policy that will be duly and progressively refined, ideally through consultative processes that implicate the wider community of stakeholders. Central governments typically take the lead in policy-setting and finding the financing needed to develop DSPDS and might do so in a variety of manners. On the one hand, they may opt to assign this function to either a specialized agency (whether repurposed or newly created) or to a dedicated unit embedded in an existing structure, regardless of whether that entity has an explicit social protection vocation (for example, Ministry of Social Protection, Ministry of Digital Economy, Ministry of Planning, Statistics Office, Prime Minister’s Office, Presidency). Alternatively, a group of institutions might be organized in the form of a board, council, steering committee, coalition, working group, or some other institutional mechanism through which participants together share strategic governance responsibilities; in such cases, facilitation is typically undertaken by a focal point reporting to the highest level of government, such as the Prime Minister’s Office or the Presidency. Although there is a great diversity of options, it is essential that, first, that a clear, time-bound mandate be given and, second, that clear operating lines, responsibilities, and outcomes be set down. Successful orienting and policy-setting requires wide and inclusive multistakeholder engagement, across government and beyond. It is important to note that this initial grant of authority is for serving in a (policy) coordinating role and not (necessarily) in the subsequent and more granular implementing role (discussed below). In selecting an institutional voice at this stage, the assigned task is to help to give voice and shape to the vision of DSPDS—that of serving and delivering social protection ends, and beyond—and not per se to define the “home” or longer-term institutional anchorage. As such, taking a wide multistakeholder approach at this stage is highly advisable. Irrespective of the institutional arrangements, strategic planning entails, on the one hand, identifying, consulting, and otherwise involving stakeholders from across government, and, on the other hand, gathering representation from across the regions, civil society, academia, and the private sector—understood broadly to include that part of the national economy not under direct government control. A whole-of-government approach helps to ensure that all sectors align and “push together” to realize a coherent effect. A whole-of-society approach, by contrast, encourages wider societal collaboration and helps to ensure that people are protected, their wellbeing is prioritized, and accountability is grown, thereby enriching and further strengthening the social fabric. It is important that the orienting and policy-setting process take—and be seen and perceived as taking—a whole-of-government approach and to be broadening out to a whole-of-society engagement. Participatory involvement—especially from practitioners and on-the-ground players—is critical to getting buy- in, bringing along critics, and ensuring the viability and accountability of the larger governance ecosystem. Social protection practitioners in particular and stakeholders more generally and diversely ought to be informed and 122. The budget for DSPDS, and dSR in particular, raises questions on the financing, especially because they serve multiple programs and may operate through existing infrastructures outside the domain of the systems administrators to reach people. Balancing the financial allocations for DSPDS requires careful consideration of the diverse stakeholders and the potential strain on existing infrastructures. 123. See also Grosh et al. (2022) for an in-depth discussion of the financing of targeted social assistance programs. 116 “WHAT MATTERS” GUIDANCE NOTE given the space to co-create and engage in the design, implementation, and monitoring of DSPDS at all stages.124 Techniques such as incorporating design-thinking—an iterative, non-linear process that focuses on a collaboration between designers and users—can help to identify innovative solutions and engage stakeholders.125 In the social protection context, doing means knowing your audience, setting a holistic vision, taking an “all-doors-open” approach, being techno-sceptic rather than techno-solutionist, and focusing on economic and social inclusion.126 Undertaking stakeholder “net-mapping” exercises is often a valuable tool, helping, for instance, to clarify needs and interests, as well as for aligning roles and responsibilities.127 Participatory involvement also helps to account for political economy considerations and vested or conflicting interests: not everyone may be interested in improved coordination and exchange of data/information across schemes and systems. Beyond institutional inertia and resistance to change, other motives—reasonable or otherwise—might exist for why certain stakeholders do not favor digitalization of delivery systems. Such concerns underscore the need for both strong leadership and careful consideration of the lead authority in charge of the agenda, as well as for providing the right incentives for all stakeholders. Such early consideration and attention will help to mitigate the risk of conflicting interests. The process of elaborating DSPDS governance mechanisms ought to not be construed as linear and static: feedback mechanisms ought to be developed to connect front- and back- end offices, and to ensure regular system updates. Such arrangements support a dynamic “to-ing” and “fro-ing” within a regular and reliable political and institutional framework, helping to create a reliable environment which in turn engenders trust. Institutional dynamism is particularly important, because political economy considerations and other interests naturally evolve over time, and they often are both institution-specific and person-particular. Good governance requires evidence-based decision-making, which is supported by incorporating process improvement strategies to enable and facilitate layered learning. Leveraging both technological developments— such as AI—and the data-rich nature of the DSPSD ecosystem can make those strategies more effective. A culture of learning needs to be instilled. Three types of learning loops ought to be countenanced.128 Most foundationally is action-focused single-loop learning, which is the process of evaluating successes and failures in order to render different outcomes, and is typically manifested as progressive tweaking and adapting that results in incremental and (hopefully) sustaining change. As single-loop learning only examines one specific scenario at a time, harnessing machine learning and looking to generative AI can make the process more efficient and reliable. Double-loop learning goes deeper, looking to practices, norms, and policies. It tries to use new data to answer old questions— such as effectiveness—and is a learning technique that allows for the evaluation of assumptions and actions. Double-loop learning creates a means for helping to understand the effects of actions and what other factors might cause results or decisions, making it particularly useful for those looking to understand how more macro factors—including policies and skills—influence results. Finally, triple-loop learning—which might be characterized as learning how to learn by reflecting on our learning frameworks and strategies—addresses more fundamental matters, including organizational rationale and context, causing challenging of paradigms and understandings of truth, including (established) theories of change. It presents a means of talking about social contracts issues and questioning assumptions. As AI has the capability to translate natural-language feedback into model- learning, it might significantly amplify triple-loop learning, especially when the great variety of DSPSD resources and perspectives are brought together, thereby nurturing a culture of learning. At the border between learning 124. See, for example, Arnstein (1969) and Organizing Engagement (2024). 125. As Herbert Simon noted, “To design is to devise courses of action aimed at changing existing situations into preferred ones” (Simon 1969). 126. For a particular application, see Daly and Karippacheril (forthcoming). 127. See, for example, Schiffer (2007), “Net-Map Toolbox: Influence Mapping of Social Networks.” https://netmap.wordpress.com/about/. 128. See, for example, Argyris (1977); Cabaj (2019). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 117 CONCEPTUAL FRAMEWORK and accountability, process improvement strategies help to put humans and societies—especially vulnerable communities—in focus and at scale. As this process is largely contingent on access to data—something that an interoperable DSPDS ecosystem is uniquely poised to do—it is important to embed a fit-for-purpose approach throughout, especially as so much of those data are not only rich but sensitive. Such layered learning can help to move data beyond information and knowledge to providing genuine insights—and perhaps even deeper wisdoms. Effective learning requires structure, as well as institutional and organizational support. As any given program progresses and the goal moves from proving to improving, it becomes progressively less of a matter of “knowing” what works and more one of regular testing and recalibrating. Acceptance of failure is a key part to allow further testing, for which institutional (and often even societal) change is frequently required. The spirit of experimentation—and the acceptance of (appropriate) risk taking—needs to be instilled in the team, as well as a framework for progressive assessing and evaluation. However—and to lean on Albert Einstein’s theory of relativity— because that which appears to be happening depends on the observer, a whole new world of scalable evaluation is required. Digital tools, including global services on data such as cloud analytics, interactive dashboards, and creative e-books, might not only support work to be undertaken at the regional, national, and local levels, but also help to create an integrated DSPDS vision. While these tools and other technological developments might facilitate the move toward continuous evaluation, it is critical that attention also be given to both people and culture. As such, it is important to not only embrace multistakeholderism (notably at the conception and design stage) but to also take a multidisciplinary vision, embedding technical experts, data scientists, lawyers, and others alongside social protection practitioners and program implementors. Knowledge brokers having sufficient digital and AI literacy may also be needed, particularly those conversant across practice areas and capable of undertaking policy-framing exercises. Embedding diversity in teams across the DSPSD ecosystem will help to keep actors abreast of not just their own immediate roles and responsibilities, but also of the potential promises and perils. Attention must also be given to socializing and sensitizing on the various DSPSD systems, both internally and externally, so as to help in the constant process of retooling, especially as new people—policy makers, practitioners, and participants, among others—come in. Intentional inclusion happens neither by default, nor even by design, but is something that must be consciously— and constantly—undertaken. Doing so means keeping humans in the loop, keeping them informed and educated, and making them key operational pieces, even as digital tools and automated processes might play an increasingly essential role. Inculcation of a culture of learning supports such an approach. While such an approach typically comes at a cost in terms of speed, it can greatly reduce risk, grow capacity, and increase trust. Moreover—and especially when paired with a HCD approach—that wider structure and intentionality will not only encourage effective layered learning and feedback but also help to combat “technosolutionism” and associated concerns.129 (ii) Establishing legal foundations It is essential that the legal foundation upon which the frameworks governing DSPDS are built are themselves robust. Where a country’s executive authority (be it a ministry or an inter-institutional body) takes the lead (and sometimes even where the legislature takes on that role), the vision is usually set out in overarching policy instruments (as already discussed). However, if that vision is to be robust and enduring, then it needs to be structurally realized on the basis of legislative text(s)—ideally, on one(s) that build upon rights drawn from already- existing constitutional bases—and then duly elaborated through regulation. It is important to establish such 129. Warnings have rightly been raised over “humankind mov[ing], perhaps inexorably, toward the digital welfare future it needs to alter course significantly and rapidly to avoid stumbling zombie-like into a digital welfare dystopia” (United Nations 2019). 118 “WHAT MATTERS” GUIDANCE NOTE clear foundations with progressive reinforcement and explicit application, as doing so gives a sounder footing, unambiguously sets out roles and responsibilities, and provides clearer rights of action. Each of those elements is important, as they grow the base and make for further “corrective” opportunities—at the administrative level, to be sure, but also, if needed, for individuals and civil society organizations (CSOs) taking action before the courts. An extended network of instruments provides the place for transitioning from exploratory DSPDS vision- shaping to longer-term institutional anchorage. Setting out explicit, deliberate, and predictable institutional arrangements with built-in corrective measures (for example, feedback loops and layered learning) is essential to fixing the right incentives for inclusive data collection and exchange. Relatedly, a key part of securing data is ensuring, first, that procedures delineate appropriate and permissioned access, and second, that they direct those data flows toward socially relevant and appropriate ends only. In the case of federated states, it will likely also be advisable to speak to the devolution of authority, as well as to which jurisdiction is empowered to act—and responsible for doing so. The particular value of such elaborations comes to stark relief when external arbiters (including the judiciary) are obliged to get involved, but they are equally relevant at the level of the GRM and elsewhere. Beyond legal grants of authority allowing and directing the state to provide social protection—and which therefore implicate the use of data—certain safeguards and enablers ought to be explicitly laid down in law to ensure the protection of data. In addition to textually and specifically grounding the legal foundations for DSPDS in a legislative instrument, it is usually advisable that the law explicitly connect those bases to the state’s legal obligations to provide such services, as well as its to other fundamental rights, including those of privacy and access to information. Other key laws include those on data protection, e-identification, e-communications, e-transactions, access to information, and cybercrime.130 Multiple institutions—both public and private—participate in setting regulations and standards and in compliance verification, efforts that ought to be encouraged and duly integrated by government. On the discussed legal foundations, executing agencies, regulators, and others produce protocols, guidelines, and standards with the aim of ensuring people’s wellbeing, safety, and security. Other nongovernmental institutions might offer additional support in monitoring compliance, including watchdogs, CSOs, and nongovernmental organizations (NGOs), by dialoguing directly with the government as well as engaging through other avenues, including the courts. In the humanitarian sector, private sector involvement is complemented by stakeholder representation from across the whole governance ecosystem—for instance, the United Nations Office for the Coordination of Humanitarian Affairs (OCHA) and academic institutions. Government should encourage those efforts and duly integrate them into their own operations, with particular attention being paid to ensuring that those norms are representative of the entire ecosystem and that relevant coordination or advocacy mandates are actively encouraged. At the same time, attention ought to be paid to making sure that regulations, norms, and standards extend, as appropriate, across the entire private sector. Attention to this part of the data governance ecosystem is equally—and, arguably, increasingly—important, especially as digital economy trends over the past 20 years indicate that private platforms often hold vast amounts of data on large numbers of people, often across borders, and that such is true even in competitive commercial markets where people change providers with relative ease. Moreover, given that so much of the relevant elements and infrastructure are in the hands of the private sector and that cyberspace has infiltrated and affects virtually every domain of life—including social protection service delivery—governments cannot act independently. Public–private collaboration is essential not just to secure the infrastructure creating cyberspace but also to allow society—and the internet—to continue to develop and evolve for the benefit of all.131 130. See, for example, World Bank (2017). 131. See, for example World Bank and United Nations (2024) at Dimension 5.A. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 119 CONCEPTUAL FRAMEWORK (iii) Data protection and privacy132 Data are powerful tools that help to grow understanding and improve delivery. Data protection and privacy principles have been long emerging and evolving133 but have risen to particular prominence and importance in recent years due largely to emerging technologies.134 In light of the increased recognition of the value of data and the increased need to manipulate and process it, there has been a steady evolution in global understandings of what good practices for protecting data and individuals should look like (Box 4). New technologies—including AI—will undoubtedly result in further developments, iterations, and additions.135 Effective delivery of social protection necessarily requires the processing of personal data. Both legal and technical mechanisms must be set up to protect people and secure data. Data protection and privacy risks can arise from any activity where personal data are collected, stored, shared, manipulated, or otherwise processed. Even BOX 4 Situating data protection and privacy To understand the rights and responsibilities implicating digital social protection delivery systems (DSPDS), it is important to understand a few notions: The right to privacy—sometimes conceived as the right to respect for private and family life—has been understood in different ways, with varying cultural nuances. While there is no universally applicable theoretical or legal umbrella conceit, it can be understood as an aggregate of rights aimed at protecting individuals from unwarranted intrusion, whether emanating from the state or private sector. Data privacy, which finds its roots in the fundamental right to privacy, is more of a process and legal matter, and can be understood as the appropriate and permissioned use and governance of personal data  a in cyberspace through the setting of access conditions. The differentiation is noteworthy as the personal data collected in DSPDI is meant to be collected and used toward certain ends (for instance, to assess needs and conditions and determine eligibility). However, in the interim space—that is, when that data are not being accessed by authorized users for those permissioned ends—the data should be kept private and protected, wherein the notion of data privacy emerges. Data protection speaks to the broader regulatory regime created out of the legal, technical, and logical tools for the generation, collection, and processing of data (and notably personal data), especially data held in electronic form. Data protection is fundamental to ensuring data privacy, and has, in some jurisdictions, been itself articulated as a fundamental right unto itself. b It is important to understand data protection as not being unidirectional, but as contingent upon the notion of participatory data stewardship and of data agency of the data subject. a. Similar and related terms, “personal information” is any information relating directly or indirectly to a (natural) person, while “personally identifiable information” (or PII), a narrower range, is any information that can be used to identify a person. The Playbook generally uses the term “personal data.” b. The EU Treaties and the EU Charter of Fundamental Rights contain the two rights, with the Charter containing an explicit right to the protection of personal data (Article 8). 132. This section is based on Daly et al. (2019). 133. Consider, for instance, the French “Declaration of the Rights of Man and of the Citizen,” adopted in 1789. 134. See, for example, KS Puttaswamy v. Union of India. WP(C) 494/2012, 24 Aug 2017. 135. Consider, for instance, the EU Artificial Intelligence Act. 120 “WHAT MATTERS” GUIDANCE NOTE where personally identifiable information (PII) is masked or removed from data sets—such as through techniques of pseudonymization or anonymization—risks of re-identification persist.136 Associated risks include exposure of personal data, data theft and identity fraud, discrimination or persecution, exclusion, unjust treatment, surveillance, and even kidnapping. However, and notwithstanding their potentially very great benefits, the constructing of DSPDS has potentially very significant implications not only for the individual but for all of society.137 In order to truly enable DSPDS to be of service, they must be deployed in a conscientious manner with the appropriate safeguards.138 Not only are the data processed by DSPDS often of a personal nature, but they are also often connected across systems, thereby heightening their sensitivity, even where PII is stripped out.139 Furthermore, social protection assessments for potential eligibility of benefits and services often involve collecting data on a great variety of personal circumstances, with potential loss of individual privacy. The use of “big data” to overcome the limitations of “traditional” data sources in order to assess needs and conditions requires particular attention (Box 2). Some of these concerns can be addressed through access controls, compartmentalization of datasets, data sharing techniques, and use of tools such as pseudonymization. However, those on the frontlines of DSPDS—the designers, implementors, and administrators, among others—need to be attentive to ensuring equality of treatment and preserving beneficiary dignity. Concern over asymmetries of power and the possibility of corruption and money politics is especially heightened in such circumstances.140 Moreover, the process might equally involve substantial administrative, personal, and social costs, both in the form of resource expenditures and bureaucratic delays. Safeguards are often the best enablers, and in that spirit the national data protection authority (DPA) plays a particularly important role, both as enforcer and, equally important, as educator. While any player engaging with DSPDS—from the frontline practitioner to the highest government representative—has the obligation to act legally, including with regard to data protection and privacy laws and principles, the DPA has a particularly consecrated role herein. At the same time, the creation and operationalization of the DPA ought not be construed purely along regulatory and enforcement or compliance lines, but also along capacity-building ones. That perception might be structurally asserted in the design stages of the legal and institutional framework by including specific provisions that speak to these capacity-building and awareness-raising roles. Additional, more concrete support for that advisory role might be given through the use of what is termed “asymmetric regulation,” meaning that players are not treated equally. For instance, the regulator may be allowed to systematically favor new entrants or reduce the compliance burden on small-to medium-sized business (SMEs) as opposed to large and very large enterprises.141 When performing its basic duties the DPA serves, among other things, as an advocate for digitalization. On the one hand, it demystifies, edifies, and contributes toward building individual and societal understanding and capacity. On the other hand, its very engagement and activity in the area helps to engender trust and to indicate that there is a regulatory authority present to ensure that rights and responsibilities are respected. 136. See, for example, Rocher, Hendrickx, and de Montjoye (2019) and Kolata (2019). For a further application, see World Bank (2024). 137. Amartya Sen (1995) observed the following: “In general, there is no way of targeting specific deprivations without a corresponding informational invasion. The problem here is not just the necessity of disclosure and the related loss of privacy but also the social costs of the associated programs of investigation and policing.” 138. See United Nations (2019). 139. See, for example, Rocher, Hendrickx, and de Montjoye (2019). 140. Rocher, Hendrickx, and de Montjoye (2019) elaborate: “There are, furthermore, social costs of asymmetric power. Minor potentates can enjoy great authority over the suppliant applicants. There are plenty of actual examples of the exercise of official authoritarianism that frequently accompanies informational investigations. The possibility of corruption is, of course, also present whenever some officials have significant control over the process of dispensing favors in the form of targeted benefits.” 141. Competitive markets function well when operators are in symmetrical relationships—that is, when there are no structural obstacles to prevent one actor from outperforming others purely on the basis of its own merits (known as “competition by merits”). For instance, consider the EU Digital Services Act (DSA), which differentiates between small and big players, setting asymmetric due diligence obligations on different types of online players to match their role, size, and impact in the online ecosystem. DSA Regulation 2022 (EU) 2022/2065. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 121 CONCEPTUAL FRAMEWORK Various legal instruments combine to support data protection and privacy rights and obligations, including international conventions, constitutional obligations, laws, policy measures, protocols, and regulatory instruments. The basic right to privacy is often guaranteed in the constitutional or other foundational texts and international agreements to which the state is party, but it is also frequently further developed in concrete laws that specifically seek to ensure the protection of data. On the one hand, these obligations create legal obligations to which data controllers and processors are accountable, and failure to comply may have significant consequences. Additional—and often heightened—compliance requirements be sector specific, such as where health data are concerned. On the other hand, such measures help to support the implementation of protective measures that are critical to the good-functioning, credibility, and overall governance of the framework, as well as to the protection, wellbeing, and trust of people in those systems—and, indeed, to their trust in cyberspace more generally. Without trust—in the systems, in the administrators, in the institutions (supervisory and participatory)—people will be reluctant to either engage or provide the information necessary to make them function. And where there is a lack of trust, it often extends well beyond the DSPDS and related, often implicating or affecting those on the frontlines and at points-of-service, and both public (for example, unique identification authorities) and private (for example, telecommunication companies). As such, the development of DSPDS component systems should be articulated around the concept of digital governance, including cybersecurity, data protection and privacy, access to information, and participatory data stewardship.142 These concepts require the setting of granular standards— typically coming from dedicated institutional actors—in order to ensure their full and proper application. Robust data protection requires participatory data stewardship and data agency, a notion which is itself contingent upon transparency and accountability. Participatory data stewardship and data agency seeks to encourage the rejection of opaque and manipulative data collection, storage, sharing, and other processing practices. The notion builds upon earlier espousals, notably the so-called “TAP” principles—namely, those of transparency, accountability, and participation.143 Nurturing the TAP principles increases government efficiency and responsiveness and builds civic trust; the principles have also been identified as key enablers of development more widely speaking, including achievement of SDG16+ and the 2030 Agenda. That participation can manifest itself in a number of ways—for instance, in the seeking rectification of data, pursing the right to be forgotten, and in grievance redress.144 A key enabler of these principles is ensuring the right of access to information, a central tenet to the “rule of law”—that is, the notion that all actors, including government, are subject to the law.145 Accessing public information is not only a right of every person but also necessary to making informed decisions and to living an autonomous life. Fundamental rule-of-law principles—notably those of legality, necessity, and proportionality— feature in this debate and in creating “trust” environments. Similarly, the concept of “due process of law”—closely related to the broader concept of the rule of law—is recognized as fundamental across legal systems. In commercial contexts, the debate appears somewhat differently. For instance, in discussions of “negative option marketing” (or “dark patterns”), consumers’ silence is understood as implicit consent (for instance, for subscription renewals and free trials that will automatically begin billing after expiration of the trial). Nevertheless, the same core notions are still involved. Internationally, an interwoven series of good practice data protection and privacy principles have emerged. Elaborated in many other sources and somewhat varying in their formulations,146 those principles might be 142. Ada Lovelace Institute. https://www.adalovelaceinstitute.org/report/participatory-data-stewardship/. 143. See, for example, TAP Network. https://tapnetwork2030.org/. See also World Bank (2009: 7). 144. See, for example, Eisen et al. (2020). 145. World Bank (2024) at Dimension 4A. 146. These principles constitute a synthesis of evolving good practices, drawn from several instruments, including ICRC Rules on Personal Data Protection (2020), International Social Security Association (ISSA) Guidelines on Good Governance (2019), Council of Europe Convention 108+ (2018) (not in force), UN Personal Data Protection and Privacy Principles (2018), EU General Data Protection Regulation (2016), OECD Privacy Framework (2013), and US Fair Information Practice Principles (FIPPs), a set of eight principles rooted in the tenets of the US Privacy Act of 1974, 5 USC § 552a, as amended. International sectoral efforts supporting data protection and privacy have also been undertaken. See, for example, Wagner, Ferro, and Stein-Kaempfe (2022). For further discussion, see, for example, World Bank (2021). 122 “WHAT MATTERS” GUIDANCE NOTE summarized as including the purpose specification principle; data minimization principle; lawfulness, fairness, and transparency principle; accuracy principle; retention limitation principle; security principle; and accountability principle (Box 5). However, these principles are packaged or presented—and regardless of the number—it is important to understand that they are interwoven and integral to each other, creating a collective whole. To be fully functional and realized, they require engagement and participation of the data subject—a matter that, in turn, requires capacity building. Good international practice espouses an integrative, life cycle vision of data protection and privacy and of all of the principles supporting that vision. Data protection and privacy principles interrelate and should not be understood as functioning either individually or in isolation but rather in a synergistic, supportive, and coherent fashion (Figure 24). No matter how these principles are parsed or presented—or the means by which they are enumerated—they ought to be understood as a whole or a set, wherein the failure to respect any of them undermines the entire construct. Collectively, they espouse an integrative, life cycle vision of data protection and privacy, one that is as much realized by the manner in which data controllers and processors comport themselves, as in the engagement, involvement, and participation of the person or data subject. BOX 5 Principles for protecting personal data Fundamental data protection principles constitute a synthesis of evolving and interwoven good international practices, that might be formulated or presented in a number of ways: 1. Making sure that data collection, sharing, and any other processing is done for a clearly defined and specified purpose(s) only, thereby limiting accretion (sometimes referred to as “function” or “mission creep”) 2. Ensuring that only the minimum data—as determined and proportional to the need—are collected and processed, meaning that they are relevant, limited, and adequate to what is necessary for the specified purpose(s) 3. Collecting, storing, processing, creating, manipulating, and otherwise processing data in a lawful, fair, and transparent manner that takes into account the person’s consent and best interests, as well as larger legal bases, and with due regard for confidentiality 4. Keeping data accurate and up-to-date—including by giving the person easy access to see their data and, as appropriate, either make or request data corrections—in order to fulfill the specified purposes 5. Ensuring that the period of data retention is limited for the time necessary for the specified purpose(s), with due consideration for the balancing of relevant rights, freedoms, and interests 6. Securing data by implementing appropriate security safeguards (organizational, administrative, physical, technical) and procedures, including against or from unauthorized or accidental access, damage, loss, or other risks presented by data processing, and by also making sure that the appropriate security measures exist with third parties whenever determined legitimate to share or transfer data 7. Processing data in an accountable manner, with adequate policies and mechanisms in place to adhere to these principles Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 123 CONCEPTUAL FRAMEWORK FIGURE 24 PURPOSE Data SPECIFICATION protection and privacy DATA principles ACCOUNTABILITY MINIMIZATION DATA PROTECTION AND PRIVACY LAWFULNESS, SECURITY PRINCIPLES FAIRNESS, AND TRANSPARENCY RETENTION ACCURACY LIMITATION SOURCE: Original for this publication. Taking a principles-based approach allows for a potentially great breadth of application. One important aspect in the nature of data protection principles is that they are, in fact, principles—that is, they provide general good practice guidance. While ideally they would complement and build upon existing legal instruments and norms, they might, as principles, still be employed even where a robust data protection regime is lacking. As such, social protection practitioners, program managers, and DSPDS administrators more widely—that is, those responsible for setting up, managing, maintain, deploying, and otherwise using DSPDS—should, where needed, consider integrating these principles into each level or part of the particular systems for which they are responsible. There are many ways in which integrating these principles might be accomplished, including through the use of internal protocols, guidance, and memoranda, but ideally with a mind to spread and share these principles more broadly. In addition to being good international practice, implementing these principles is also important from a wider governance perspective, as their implementation helps to increase trust, thereby contributing toward the success of the social protection system. A new era of data protection and privacy standards was ushered in with the European Union (EU) General Data Protection Regulation (GDPR), creating what some have called the new “gold standard” in data protection. While more of an evolution than a revolution, and with the underlying precepts remaining the same, the GDPR—which 124 “WHAT MATTERS” GUIDANCE NOTE is hard law—is considerably more comprehensive and far-reaching than earlier instruments. It preserves many of the basic principles while progressively implementing stricter and more extensive rules, as well as establishing consequences for non-compliance. Its path from preparation to promulgation was also accompanied by significant awareness-raising activities, which brought increased attention to both rights and responsibilities, and to the overall importance of data protection and privacy. The GDPR provides practical—and, depending on the context, possibly binding—guidance for those building DSPDS (Box 6). Shifting away from a checklist approach of “do’s” and “don’ts,” the GDPR looks to place data subjects at the center by giving them control and knowledge of how their data are being used. While there are many reasons to look to and speak of GDPR, one particular reason is that it sets obligations squarely upon those collecting and processing data. BOX 6 Data and the “GDPR era” Not all data merits the same level or type of protection. “Personal data” refers to “any information relating to an identified or identifiable natural person,” an “identifiable natural person” (or “data subject”) being defined as a natural person (that is, a human being, as opposed to a moral entity, such as a company) “who can be identified, directly or indirectly, in particular by reference to an identifier, such as a name, an identification number, location data, an online identifier, or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person” (GDPR Article 4(1)). Included are not only physical addresses but also possibly, for example, email addresses where a single person is determinable on its face. Data affirming a person’s physical presence at a location, including closed-circuit television (CCTV) footage, is personal. By contrast, a person’s name by itself is not always personal data, as there might be many individuals with that same name. However, once that name is combined with other information (such as an address, a place of work, or a telephone number), it then will usually be sufficient to clearly identify one individual, therein becoming personal data. At the same time, a person might be identified even without knowing a person’s name. Sensitive personal data or (“special categories”) refers to personal data that, by their nature, are “particularly sensitive in relation to fundamental rights and freedoms and merit specific protection as the context of their processing could create significant risks to a person’s fundamental rights and freedoms” (GDPR Recital 51). Data in this special category include those consisting of information on a person’s racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic, biometric, health, life, or sexual orientation (GDPR Articles 4(13)–(15), 9). Sensitive personal data should be held separately from other personal data. Environment matters in understanding the import of legal regimes. Importantly, the GDPR does not exist in a vacuum. It functions in no small part because of the larger, more comprehensive architecture and infrastructure of the European Union: politically, legally, and technically, EU member states have agreed to cooperate, support the interoperability of systems, and allow restrictions on their sovereignty. The reality—and support—of that wider ecosystem requires recalling even as other countries draw inspiration from the GDPR. Relatedly, laws should not be merely copied-and-pasted—or directly “transplanted”—from one jurisdiction to another without being appropriately nuanced and contextualized. a a. See, for example, Pérez-Perdomo and Merryman (2018). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 125 CONCEPTUAL FRAMEWORK Despite the critical and growing place of such protective measures, little has been written about the significant data protection and privacy risks that need to be accounted for when building DSPDS. International good practices are increasingly raising the bar. At the same time, increasingly sophisticated technology and systems integration brings not only greater rewards but also heightened risks. Correspondingly, recognition continues to grow of the importance of ensuring the right to privacy in general and to data protection and privacy more particularly, as well as the role of participatory data stewardship and the right to agency. Technology has so significantly changed the landscape and reality that national courts have come to recognize the right to privacy as fundamental even where not explicit in their constitutional instruments.147 Many other jurisdictions have significantly expanded their data protection regimes through law, of which the GDPR is perhaps the most notable and consequential example. Well-governed DSPDS benefit from adhering to good governance principles, including on data protection and privacy, at all levels, using them to guide system design, implementation, and interoperability. Adopting good governance principles can help to mitigate some risks inherent to introducing new technologies to deliver social protection and ensure the sustainability of investments in data and technology. Governments and institutions have adopted different approaches to protecting data transactions.148 Regardless of the approach taken, there should be consistency and transparency, with the application of the principles (and other data protection and privacy instruments) to “raise the bar” on standards and on what is acceptable, as well as to render DSPDS more secure and more inclusive. (iv) Consent framework and consent architecture Ensuring that data-sharing protocols are put in place from legal and technical perspectives is essential to guaranteeing the privacy and protection of people and their personal data. It is a common misconception that, for the GDPR, consent underpins everything; there are, however, several bases: (i) consent, (ii) contract, (iii) legal obligation, (iv) vital interests, (v) public task, and (vi) legitimate interests.149 Although consent is only one of several legal bases upon which data might be processed, and while it may not even be the most appropriate of them in the administration of social protection delivery, it is nonetheless a consideration, particularly in the given context.150 Application of data protection and privacy principles helps to ensure robustness—from a legal, institutional, and systems perspective. Consent is about so much more than ensuring legality. Broadly speaking, social protection is about empowering the disempowered—the poor, vulnerable, and all of those who need society’s protection. This raison d’être needs to be carried into the technology space that DSPDS creates. In a similar vein, consent itself is at the heart of putting power in people and over their personal data, data that has been collected and, to many, might seem to have been taken from them. Seen from such a perspective, it should come as no surprise that data protection matters to most people, including to the poor and vulnerable, although they might not be in a position to insist upon it—and yet data of the most vulnerable people are often the least protected. 147. For instance, in 2017, the Indian Supreme Court—in a unanimous, nine-judge en banc decision—ruled that Indian citizens have a fundamental right to privacy— including informational privacy—guaranteed primarily under Article 21 of the Indian Constitution. See Justice K.S. Puttaswamy (Retd) vs. Union of India & Ors, (2017) 10 SCC 1, AIR 2017 SC 4161. 148. Data transactions are interactions with the potential to create value and comprise the collection, use, transfer, or processing of data between businesses, people, and governments (World Bank 2021). 149. GDPR, Article 6. 150. In addition to consent, data may typically be processed for the following reasons: contractual obligations entered into by the data subject, in compliance with the legal obligations of the data controller, vital interests of the data subject, in the public interest or exercise of authority vested in the data controller, and legitimate interests pursued by the data controller. Art. 6(1) GDPR. See also Box 4.14 in Lindert et al. (2020). 126 “WHAT MATTERS” GUIDANCE NOTE Meaningful consent is given on the basis of trust, and data duly entrusted for use toward permissioned and appropriate ends. Personal data collected belongs to the individual—the “data subject,” as the GDPR puts it—while those collecting, storing, and otherwise manipulating or processing those data are “mere” custodians.151 Good international practice not only looks to ensure strong data protection guarantees but also to put control of use of collected data back into the hands of the individual. Consent is key to the notion of data privacy: it conditions the collection of personal data exclusively for particular purposes that are usually bound to a given/specific timeframe. When the data are not being used for those permissioned ends, they are to be kept safe, secure, and unused. Generally speaking, when consent is the legal basis upon which data have been collected and are being processed, this means that those data ought not to be shared, even if the purposes might otherwise be deemed as legitimate. As such, people should be informed in a timely, adequate, and clear manner of the project and its purposes, thereby allowing them to provide educated and informed consent to data collection for those ends and at the initial moment of registration. They should similarly be informed about any change in purpose when either renewing or updating their consent. Data protection-by-design and -by-default are particularly important where there are multiple service providers but only one data collector, and thus particularly important for DSPDS. Consent mechanisms should also be adapted to local contexts: having a person sign a form indicating consent is not always either sufficient or desirable, and attention must be paid to asymmetries of power, particularly when dealing with vulnerable populations (Box 7). BOX 7 The elements of consent Consent requires certain specific elements to be valid. While consent is critical point of concern in data processing, obtaining meaningful consent for data to be used in the administration of a social protection benefit or service presents specific difficulties, especially when a household is poor and where survival significantly (or seemingly) depends upon receiving that support. Consent must be given by a clear, affirmative act showing that it was (i) freely given, (ii) specific, (iii) informed, and (iv) an unambiguous agreement to the processing of personal data. (i) “Freely given” consent implies not only that it is provided voluntarily but that it is a genuine choice made by the individual. As such, any inappropriate pressure or influence that could affect the outcome of that choice renders the consent invalid. This standard is the same used in the medical community. In doing so, efforts are made to limit concerns for power imbalances between the collector and controller of the data and the individual. It is due to concern around this element that consent is necessarily always the best single legal basis for social protection delivery. It bears noting that the performance of a contract may not be conditioned upon the consent to process further personal data that is not necessary for implementation. (Continued next page) 151. Data ownership can be understood as having legal rights—including creating, editing, modifying, sharing, and controlling access—over data. Although argumentations of data as “property” that can be “owned” are frequently unhelpful, in the relationship between the data controller and processor, on the one hand, and the individual data subject, on the other hand, reverting to that dichotomous analogy has certain benefits. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 127 CONCEPTUAL FRAMEWORK Box 7 (continued) (ii) “Specific” aims to limit accretion (sometimes referred to as “function” or “mission creep”), meaning that all activities and processing to be carried out shall be identified. Where the processing has multiple purposes, consent should be given explicitly for each end. Relatedly, any use of automated decision- making (which should not be final decisions pertaining, for instance, to the receipt or eligibility of benefits or services a) should be per-determined, identified, and shared with the data subject. (iii) “Informed” means that the individual has been notified at least about (a) the identity of the controller (and ideally the data processor(s)), (b) the kind(s) of data to be processed, and (c) the purpose(s) for processing the data. (iv) “Unambiguous” means that consent is clearly and affirmatively given through an active declaration of opting-in (for example, statement, website checkbox, choice of technical settings, clear and contextualized conduct). Consent may be withdrawn or modified at any time, and the means for doing so should make it as easy as initially giving it. a. World Bank (2024), at Dimension 4.B. B. ADMINISTRATIVE (“BACK OFFICE”) The process of institutionalization—in many ways, the heart of governance—is needed to realize effective DSPDS. As the American inventor, Thomas Edison, said, “Vision without execution is hallucination”—and execution requires actors, which, in the governance context, generally means institutions. Fundamentally, institutions are needed for strategic planning, rule- and standard-setting, compliance and enforcement, evidence-based learning, capacity building, and sensitization and outreach, as appropriate. Institutions are also functional means for ensuring that much of the “back-office” work that makes systems function.152 While there is no blueprint for what those frameworks should look like, and although due consideration is needed for the diversity of contextual factors to determine what is appropriate for each country, certain elements and international good practices should be considered. Part of that context is the very diverse nature of social protection policies and programs. Social protection programs implicate, directly or indirectly, a multitude of actors, all of which must be aligned to achieve systems interoperability. In general, such alignment is usually only brought about where there are political champions. That alignment is a particularly complex undertaking in the social protection space, as those programs strive to offer various benefits and services that improve not only individual wellbeing but also overall societal welfare, with particular attention to the poorest and most vulnerable individuals and households. Due to the diversity of action areas, different actors and institutions provide these benefits and services, often in varying sectors and administrative levels. Thus, each program is structured according to the exigencies of its own delivery system and institutional arrangements. Diversity brings great richness, but, in the absence of appropriate 152. See World Bank (2021), Chapter 8. 128 “WHAT MATTERS” GUIDANCE NOTE coordination through good governance, it can also result in significant, potentially conflictual issues. With multiple programs and players, coordination is often complex. However, the costs of fragmentation—in terms of lost value, inefficiency, and more—can be high(er) for all involved. Identifying a coordinating entity in the DSPDS governance ecosystem to serve as administrator is a particularly nuanced-yet critical governance matter, as that entity is to serve as a steward of secure data flows among people and multiple institutions, often at multiple levels of government, as well as across the private sector. There are two fundamental options: either to create a separate administrative authority or to establish the role as an office or unit within an existing authority (be it a ministry, independent agency, or otherwise). The first option requires more upfront effort, typically requiring heavier procedural movement and possibly involving cooperation between executive and legislative leaders. If there is already an abundance of independent authorities, this option risks further encumbering the country’s political and administrative systems. However, the advantage is that the authority will have increased visibility, thereby augmenting the likelihood of independence and its (direct) accountability, which will contribute toward DSPDS viability. By contrast, the second option requires fewer procedural steps but will likely reduce the appearance of independence and thus potentially make it less likely to be spurred to action. An intermediate option would be to repurpose an existing institution. Often, one decision might be made, and, in due course, it be deemed advisable to make a shift to another form, although such shifting has its own associated costs and concerns. Which option is the most viable requires case-by-case analysis and strong contextual awareness. Regardless of the chosen approach, two essential elements are needed: first, that institution must be conferred with a clearly defined mandate and responsibilities, and second, that it be sufficiently well resourced. Another point of consideration (particularly in the social protection context) is that—regardless of the specific choice of institutional anchorage—the administrator is seen as transversal in nature and as serving neither single nor sectoral interests. As such, the administrator must operate with a certain degree of independence and autonomy from all of the multiple actors either operating or controlling social protection programs. While digital delivery systems are presented here in the context of social protection, they should not be construed as uniquely serving narrow sectoral interests. Rather, sectors have a critical role in building national digital public infrastructure and digital public goods, upon which other structures (both public and private) should be able to build. Keeping such potentialities open is best met by ensuring multi-stakeholder co-ideation from the earliest possible stage. Such a vision is necessary from a delivery perspective but also comes from an understanding of the non-rivalrous nature of data and the need for DSPDS to be as wide-ranging and to cover as much of the population as possible.153 Data sharing requires a significant degree of credibility and trust, qualities that cannot be had without the development of effective information security and responsible interoperability protocols. Novel approaches to data intermediation and collaboration arrangements that could be explored include data pools, data commons, data clubs, data cooperatives, or data trusts.154 There is limited knowledge of the extent to which such arrangements are being utilized in the context of social protection delivery systems. The administrator is ultimately responsible for implementing accurate, reliable, accountable, and transparent systems, minimizing errors, fraud, and mismanagement. These responsibilities may be structured by the law setting up DSPDS, but also under data protection laws. Sufficient resources must be placed at the disposal of the administrator in order for it to meet these responsibilities and the associated demands. Those resources are both 153. World Bank (2021), at chapter 6. 154. See World Bank (2021), at chapter 8 for an overview of these arrangements. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 129 CONCEPTUAL FRAMEWORK human and financial, including providing sufficient financing and appropriate resourcing (ideally with a dedicated line in the national budget and with needed equipment), nurturing institutional capacity (notably through adequate staff with the right skill set and training), and creating effective enforcement mechanisms (including monitoring and compliance, and fining and sanctioning regimes). Doing so will result in the provision of high-quality services, thereby building the trust and confidence of people in the system and its administration. Trust and confidence are grown through, notably, the following: • Transparency: involves clearly conveying and making available information on mandates, roles, and responsibilities, as well as evaluation criteria (both of potential participants and of programs), and the processes and rules by which the authority operates, as complemented through regular reporting. • Accountability: helps authorities to be kept responsive to their stakeholders and to the standards, aims, and objectives that they were established to meet, notably through grievance redressal and appeals processes, but also through feedback and layered learning mechanisms; doing so helps to limit accretion (sometimes referred to as “function” or “mission creep”). • Participation: nurtured on the basis of transparency and accountability (thereby allowing for a better knowing and understanding of what people care about). Participation involves that opportunities are offered to stakeholders to engage in DSPDS design and planning, and opportunities are offered to beneficiaries to engage with the implemented systems (for instance, where the GRM is engaged because it is both accessible and seen, through its outputs, to actually produce fair and equitable results). • Data Protection: data are safely and securely held, meaning that systems are secured, and data are collected, stored, shared, and otherwise processed in a manner that ensures data privacy, meaning that personal data are only used for appropriate and permissioned ends (Box 4). • Integration and interoperability: the ability of a system to share information with other systems using common standards and to integrate business processes and systems while respecting legal safeguards. The administrator has functions that extend to sustaining and growing systems operations. Those activities include, among others, the following: executing the DSPDS strategy; building, populating, and maintaining DSPDS front-office and back-office interfaces; developing data sharing protocols; coordinating data flows; developing common data standards; securely storing hosted data; defining and guarding the principles for the use of data; and building capacity across DSPDS users including individuals, households, and program officials. The roles of an administrator will vary depending on country context and the needs at hand, a matter to be raised, if not determined, at the earliest stages of the ideation process. Administrators can outsource specific functions depending on local context, existing infrastructure, and resources. There is much room for public–private cooperation in this space. For instance, in the absence of in- house resources, a private-sector firm or a technology-oriented public institution might be recruited for systems building or maintenance. Where such outsourcing is done, it should be undertaken such that it ensures that the administrators’ capacity is grown and nurtured, which should be stipulated in the contractual instruments. Once the systems have been developed, administrators might also shift certain data intake responsibilities to local government (provincial, municipal, and so forth), nongovernmental service providers, or the private sector based on their proximity to individuals and households, as described in the Operations section (below). In such cases, the administrators play a managerial role, setting the rules for DSPDS strategy and coordinating and overseeing the effective and adequate implementation of outsourced functions. 130 “WHAT MATTERS” GUIDANCE NOTE The administrator is also responsible for the information management processes for service delivery for programs and administrative users. Managing back-end processes requires significant coordination between the administrator and user programs to ensure that data exchange is a two-way process: going from programs to DSPDS and also from DSPDS to programs. Users of back-office functionalities include programs that can be implemented by national, local, or municipal governments, as well as by development partners, including NGOs or cooperation agencies. Coordination is enabled by both political commitments and legal instruments that formalize collaboration. Highlighting the efficiency gains of DSPDS and fostering a shared understanding of common objectives can help to ensure buy-in from user programs. Moreover, instruments such as memoranda of understanding, terms of reference, or other legal agreements—typically subscribed to between the administrator and user programs or entities individually—are essential coordination tools. Use of such instruments not only helps to increase trust, improve cooperation, and grow partnership, but also helps in internal conflict resolution, thereby mitigating contention. These instruments usually contain a clear definition of the roles and responsibilities of each party, as well as the protocols for data exchange in a way that facilitates transparency, accountability, and monitoring. Many of the above-discussed aims, legal concerns, and risks can be managed by taking a data protection-by- design and -by-default approach. Fundamentally, data (at rest or in motion) should be protected by-design and by-default. This approach goes beyond a “checklist vision” that is based on legal risk (alone).155 More holistically, the approach espouses an integrative, life cycle vision of data protection and privacy, with attention given to concerns from the moment of conception and there on out. It does this by taking the data protection principles (Box 5) and applying them at all stages of the data life cycle, with the implementation of complementary controls at each stage of data processing, and by looking to do so by looking through a “HCD lens.” The data protection- by-design and -by-default approach takes an integrative view moving data protection, going beyond concerns for what measures are technically or legally applicable to data processing and shifting attention to each stage of the data life cycle. It also takes account of the TAP principles, keeping a particular eye on how individuals are engaged. The data protection-by-design and -by-default approach conceives of data protection issues as an essential part of the conception and implementation of systems, as well as the services, products, and business practices that will engage and interact with those systems. In that understanding, data protection is construed as an essential component of the core functionality of processing systems and services, emphasizing implementing preventative and prophylactic measures and anticipating privacy-invasive events before they (might) happen. This is realized through several practical actions. Technical measures are integrated up front to ensure data security at all stages. In the spirit of transparency, “plain language” is used in policy documents to ensure accessibility and comprehensibility, and data subjects are provided with the identity and contact information of data processors, as well as with the means for determining how their personal data are being used, and user-friendly options, controls, and interfaces. Privacy-enhancing technologies are used throughout, and reliable, vetted vendors are relied upon for services. By shifting the perspective away from matters to be retrofitted or addressed after an incident, data protection-by-design and -by-default reduces scrambling and reactivity, increasing security and effectiveness while also growing transparency, accountability, and, as a result, participation and inclusion. The institutional administrator plays a key role in ensuring the continuity of this approach. 155. Data protection-by-design and -by-default was instrumentalized in the GDPR, and build on earlier notions, notably that of privacy-by-design. See Cavoukian (2011). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 131 CONCEPTUAL FRAMEWORK C. OPERATIONAL (“FRONT OFFICE”) The “front office” constitutes the third governance layer, that is, the point of interface where the system, its structure, and wider government “meet” people as they access social protection benefits and services, especially first-mile populations. There is no “one” point of interaction: rather, as people have many and divergent needs, they will necessarily interact with DSPDS through programs at several—and varying—points in the delivery chain. Indeed, their interactions with DSPDS might appear limited punctual but, due to interconnectivity, have broader implications. Front offices play an important connective and sustaining role. Here, the interested learn about available benefits and services. They also get information on how to apply to applicable programs, as well as receiving details on how to track their application status, beginning with notification of enrollment and onboarding information to start receiving benefits and services (processes that, once a decision is made, might be automated). Front offices also serve as an enduring interface where beneficiaries might request subsequent information, update their data, and report grievances or make complaints, among other things. The front office interface facilitates a plenitude of interactions, reliably and predictably accompanying the individual or household’s journey, allowing for the individual to interact with the appropriate components of DSPDS (Figure 25). Responsiveness to people’s needs at the local level helps to avoid doing harm, as well as to prevent the misallocation of resources and under- or over-investing. Adequate governance ecosystems for frontline service delivery are as crucial as technology. Physical “single window services” or “one-stop shops” that serve as front offices provide both physical access and serve as places to facilitate access to “digital service windows.” Thus, these access points play an essential role in connecting programs with their intended beneficiaries. They might also be used to broaden the ambit of social protection programs by not only guiding on how to make and navigate online access but, where a choice is available, by also showcasing varying participating provider options (public and private), such as local convenience stores and trusted agents of financial institutions. Doing so helps to enable access to a whole range of public services and social protection programs, while also increasing coverage, integrating offerings, and generally reinforcing (and even expanding the contours of) the social fabric. In order to allow a means of “connecting back” to earlier parts of the governance ecosystem, those operating on the front line ought to have clear, well-defined, and comprehensive documentation of all relevant processes of the delivery chain, as well as at least basic understandings of key concepts, thereby fostering their effective implementation and enforcement. A wide range of supporting materials, training, and/or communications ought to be developed to ensure harmonized and uniform application, and smoother operations, and feedback mechanisms ought to be developed to connect front- and back-end offices, and to ensure regular systems’ updating. Within a DSPDS framework, a multi-channel people interface can improve the user experience by streamlining access. In addition to creating efficiency gains, a single gateway with a multi-channel, “many doors open” approach for multiple programs optimizes the resources—time, economic (including opportunity costs), and number of visits, among others—that people must expend to access social protection. A multichannel approach can help governments to guarantee the inclusion of all groups. While digital platforms may be preferred by some segments of the intended population, a share of people may choose face-to-face interactions. Many segments of the population will prefer to avail themselves of both options, depending on the need at hand. These channels can— and should—co-exist to better respond to people’s needs and interests. Appropriately designing these channels requires contextual understanding, sensitivity, and appropriateness to local conditions, including digital literacy and infrastructure. In addition to facilitating access and increasing inclusion, having multiple routes and channels 132 “WHAT MATTERS” GUIDANCE NOTE FIGURE 25 Frequent interactions between people and DSP FRONT OFFICE INTERFACE PEOPLE Learn about Apply to 1 or Receive notification Receive Manage benefits and services: request programs and more programs about enrollment benefits and information, comply procedures decision and services with conditionalities, onboarding file grievances ASSESS DECIDE PROVIDE MANAGE THE DELIVERY CHAIN SOURCE: Original for this publication. for accessing benefits and services increases system resilience, a matter of growing concern in an increasingly cyber-dependent world. The front-office interface to people is managed and coordinated by the administrator but may require shifting some degree of implementation responsibility to other actors with greater proximity to people. For instance, and irrespective of the efforts conducted by programs for their own purpose, some outreach and notification activities might be delegated to local government (provincial, municipal, and so forth), nongovernmental service providers, and even community members. Arrangements will likely vary significantly when data need to be collected or updated, and will be highly dependent upon intake modalities. Front offices can play a helpful role herein, especially where those other actors belong to the private sector. With on-demand data collection methods, program applications and data updates are received through local offices or digital service windows, whereas administrator-driven methods typically rely on contracted field teams. Local offices or on-demand windows can have varying jurisdictions. Some can be deconcentrated offices of the DSPDS administrator, such as in the case of Türkiye. In other instances, local government offices working under a formalized partnership collaboration agreement might be relied upon. For example, in Brazil, the people interface functions of the Cadastro Unico are implemented at the local level via autonomous municipalities according to specific “terms of adhesion” agreements, performance monitoring, and performance incentives for administrative cost-sharing subsidies from the federal government.156 In still other cases, as in Mexico, social programs can serve as the “window” for people to apply via any of the “user programs” (that is, social programs administering a standard application form), and their data are then duly transmitted to the dSR to allow for individuals and households to be considered for a range of benefits and services. Digital service windows allow for electronic applications via personal devices (computers, tablets, mobile phones) or e-government kiosks 156. See Lindert et al. (2020) and Mostafa and Sátyro (2014). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 133 CONCEPTUAL FRAMEWORK or offices, such as in Azerbaijan, Chile, and Türkiye (initial application). En masse registration waves are typically outsourced to external firms, programs, statistics agencies, or NGOs, and, at times, responsibilities may be shared with communities (engagement, validation, and so forth). *** Formed of three parts—the strategic (or “high-level” including the policy and legal foundations), the administrative (or “back office,” including the institutionalization), and the operational (or “front office”)—good governance of DSPDS is no less critical to success than is the technological design. The groundwork for that good governance is set through the establishment of robust legal and institutional frameworks that ensure safe, secure, and legitimate interoperability across the whole of DSPDS. That process begins with policy-framing and -setting, but also requires grounding in principle-based legislation—for instance, in the incorporation of data protection principles—as concretized through regulatory instruments. Both (eco)system design and implementation should take a HCD approach, while also encouraging a symbiotic and synergistic relationship with beneficiaries through, among other things, the use of the TAP principles of transparency, accountability, and participation. DSPDS administrators and frontline social protection practitioners alike have the responsibility of not only ensuring access to social protection programs, but of humanizing the process and systems. Additional efforts—such as “one-stop shops”—should be undertaken to make sure that the “front office” actually comes to the fore and front of engagement with the beneficiaries, well before they struggle to access or understand benefits or services. DSPDS designers, implementors, and administrators alike, and regardless of the stage, need to be attentive to ensuring equality of treatment and preserving beneficiary dignity. However—and beyond or before all else—the human element is the most fundamental part of DSPDS. Data are representative—of values or of sets of values—and thus, and by extension, of people. DSPDS, by contrast, are about the use or application of those data in a social protection context, which is about empowering the disempowered. That application means that the process of using data must be a humanizing one, as much for the policymaker and practitioner as for the beneficiary. Good DSPDS governance seeks to set out an underlying framework for systems, functions, and automation that is supportive and safeguarding by design and by default. Nevertheless, the intentional inclusion that is the beating heart of DSPDS needs to be recalled not just through form and function, but also through active application—by human and machine—of the humane. 134 “WHAT MATTERS” GUIDANCE NOTE Part 6 Performance DSPDS are an “invisible engine”157 that empowers programs to deliver results from governments to people, impacting households in multiple ways. The direct interactions and touchpoints between people and delivery systems have many implications on the interventions being delivered: time, costs, visits, notifications, payments, conditionalities, grievances, among others. As such, the performance of these delivery systems directly impacts the efficiency and effectiveness of social protection programs and policies. However, as emphasized in Chapter 9 of the Sourcebook on the Foundations of Social Protection Delivery Systems, “the focus of conventional theories of change tends to be on the causal chain linking activities of the program, such as cash transfers or job training, to high-level outcomes, such as the graduation of vulnerable populations from extreme poverty, or their enhanced resilience to shocks. Such theories of change are rarely explicit about how delivery systems contribute to effective and efficient social protection programs” (Lindert et al. 2020). Bearing this in mind, this chapter proposes a framework to assess the performance of DSPDS, and how these systems can address the challenges of inclusion and coordination to the improve the impact of social protection interventions through better delivery and better prioritization for more socially progressive outcomes. The chapter is structured by first proposing a conceptual results chain, followed by an indicative set of metrics to measure the performance of DSPDS (small “s” systems). Finally, the chapter provides two examples of how the overall performance of the social protection system (big “S” system) can be monitored and improved by leveraging data from DSPDS. A. RESULTS CHAIN How can DSPDS contribute to improving social outcomes and the impact of social protection programs? Information systems support programs and people throughout the delivery chain to ensure more efficient and effective social protection delivery with the ultimate goal of improving social outcomes and the impact of programs. As described in previous chapters, data, technology, processes, and institutions are the key building blocks of 157. Evans, Schmalensee, and Hagiu (2008). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 135 CONCEPTUAL FRAMEWORK DSPDS. Well-performing DSPDS lead to more efficient and effective delivery processes by integrating operations common to various programs such as intake and registration, the assessment of needs and conditions, or the provision of cash benefits. Moreover, through better—and not just bigger—data, DSPDS informs social protection policy, increases transparency and accountability, and ensures that the intended beneficiaries are reached when in need. Layered learning might also be progressively used to help take data beyond information and knowledge, distilling it down to genuine insights and even deeper wisdom. By increasing efficiency and effectiveness in the delivery of social protection, DSPDS contributes to alleviating the dual challenge of coordination and dynamic inclusion in order to maximize the impacts of social protection policy.158 As such, the linkages of DSPDS to early, intermediate, and long-term outcomes are shown in Figure 26. The performance of DSPDS depends on political, institutional, and cultural aspects. As with any other transformational undertaking, sustained political will and leadership are necessary conditions to ensure ownership and the commitment of actors for the sustainability of investments. Providing the right incentives for all stakeholders can generate genuine political will. In practice, political will can help secure adequate resources and legislative support required at technological projects’ birth, expansion, and maturity phases (Kwame Senyo, Liu, and Effah 2019). Similarly, institutional factors such as clarity in roles and responsibilities and an authorizing environment for systems administrators supported by a robust legal framework and sufficient financial and human resources are key enabling factors of well-performing DSPDS. Organizational culture factors also play an essential role in enabling dynamism and interoperability. States functioning under a whole-of-government approach, with the “once-only” principle for minimum data collection, consent-based sharing, and authorized data access as pillars, tend to adopt DSPDS more naturally as it is embedded in their organizational culture. Estimating the cost-efficiency of DSPDS and component systems is not straightforward, but there are significant indications as such. On the cost side, there are multiple types of outlays. These include the private cost for people in terms of time and money to gather documents and information, access service points, participate in intake and registration, and others. They also include administrative costs for both front- and back-office operations such as staffing and systems building and maintenance (Grosh et al. 2022; Leite et al. 2017). In addition, DSPDS are prone to continuous improvements due to changes in technology or capabilities, requiring frequent investments to adapt. Measuring the efficiency of DSPDS is also challenging given the multifaceted nature of outcomes. However, available results show promising indications of enhanced efficiency. For instance, using biometric authentication in India led to faster and more predictable payments among beneficiaries of employment and pension programs, while reducing the leakage of funds (Muralidharan, Niehaus, and Sukhtankar 2016). It also increased attendance of public health workers, which was associated with a reduction in low-birth weight babies (Dhaliwal and Hanna 2017). Investments in Türkiye’s ISAS allowed it to identify duplications of about 10 percent of social assistance benefits, reduce paper and staff time, and reduce the time of application to enrollment decisions by approximately 20 percent for social assistance programs and from 1.5 years to 1 month for disability and old-age pension programs (Grosh et al. 2022). Due to the interoperability and cross-verification processes of Brazil’s Cadastro Unico, about 1.3 million people were removed from the Bolsa Familia program because they did not meet the requirements to remain in the program, generating savings of about US$350 million (Grosh et al. 2022). 158. While DSPDS can contribute to the improvement of social outcomes, it is important to acknowledge that they are not the only factors at play. Other factors such as politics, social policy, financial and human resources, capacity, cultural norms, and individual behaviors also play a crucial role in shaping social outcomes as a whole. 136 “WHAT MATTERS” GUIDANCE NOTE FIGURE 26 Results chain for DSPDS ACTIVITIES DATA OUTPUTS • Define data sets and fields INTERMEDIATE • Develop and implement OUTCOMES protocols for direct and indirect data collection and updates, including DSPDS questionnaires, identifying sources, periodicity, Data are OUTCOMES generated, harmonizing data, creating kept up-to date data dictionaries, etc. and processed • Develop and implement protocols for secure securely IMPACTS to support data sharing and quality- decision- assurance Better making all along the collection, delivery chain analysis, and TECHNOLOGY use of data to inform social • Build and maintain the Interoperability protection technology to allow for the and data policies and interoperability of systems exchange programs and data exchange mechanisms • Create back- and front- to strengthen office interfaces Increased social Improved • Ensure sufficient ICT transparency protection Increased social infrastructure and delivery coordination outcomes accountability in the and impact DELIVERY CHAIN in the delivery provision through Accessible and of social of SP better • Set up a human-centered user-friendly protection and service-oriented front- and back- delivery and programs front-office interface office interfaces targeting through Dynamic for outreach, intake and allowing of social improved data inclusion of registration, grievance people to protection sharing and people in redress, and beneficiary easily navigate programs collaboration need operations the social • Agree on key definitions protection (assistance unit, system and Intended household, eligibility access the beneficiaries criteria, targeting services they have access to methodology) need and benefits and • Develop and implement supporting services and protocols to support information programs can user programs across management reach them all delivery stages. processes Establish clear roles and for service responsibilities. delivery for Integration of programs and delivery chain administrative processes GOVERNANCE users • Establish inter-agency cooperation and Automation coordination mechanisms, of social including capacity building program’s • Establish regulations processes governing data production, access, and usage to ensure secure data transactions SOURCE: Original for this publication. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 137 CONCEPTUAL FRAMEWORK B. DSPDS PERFORMANCE METRICS Effective and efficient DSPDS enable well-performing delivery systems. To be effective, DSPDS must be inclusive enough to accommodate the specific needs of the most vulnerable populations and address the access barriers they might face so social protection programs can reach, register, and provide benefits and services to their intended populations. Moreover, efficient DSPDS exploits synergies within government (within and between programs, sectors, levels of government, and others) and stakeholders (for example, private sector firms, NGOs, and others) to optimize financial and non-financial costs for people, social programs, and their administrators. Understanding how and to what extent digital delivery systems contribute to more efficient and effective processes is essential for institutional learning, transparency, and accountability. Monitoring the performance of DSPDS is critical to identify areas for improvement and optimize the use of resources to achieve social protection objectives. Regular measurement of performance indicators for DSPDS (small “s” systems) can help detect bottlenecks and assess data and systems integrity challenges early on to course-correct and prevent systemic challenges. When paired with other evaluative techniques (for example, process evaluations, audits, information systems reviews, and impact evaluations), performance indicator frameworks can help identify alternatives for more effective and efficient DSPDS, thus leading to more inclusive and coordinated social protection delivery. Measuring the performance of DSPDS can also serve as a mechanism for ensuring that component systems operate within established standards, regulations, and guidelines, thus improving public trust and credibility in the state. This chapter proposes several metrics for continuous measurement of the performance of DSPDS along four dimensions: data, processes, technology, and institutions. Annex 2 presents a non-exhaustive list of indicators to help measure the performance of DSPDS. However, it does not intend to suggest that governments should adopt the entire framework. Instead, it seeks to provide a starting point that can be adapted to the specific context to ensure that selected indicators accurately reflect the performance of the systems. • The data dimension assesses the strengths and weaknesses of the different types of data sources and whether they provide the necessary inputs to effectively and efficiently deliver social protection benefits and services. Four criteria can serve as a framework for measuring the performance of the data dimension of DSPDS (see Part 2). First, breadth refers to the extent to which the intended population is captured and covered through diverse data sources. Second, depth refers to the diversity of data sources and the completeness of data necessary to facilitate eligibility decisions and beneficiary operations management. Third, accuracy refers to the extent to which data represent reality and are correct, unique, and consistent. Fourth, timeliness refers to the half-life or dynamism of the data, that is, the extent to which data are up-to-date and available within an acceptable timeframe and duration. • The delivery chain or processes dimension utilizes effectiveness and efficiency as the guiding criteria to assess the contribution of DSPDS to delivery processes (see Part 3). Effectiveness metrics measure the system’s ability to provide quality services and benefits to the target population, while efficiency indicators measure the cost-benefit of the delivery process. • The technology dimension assesses the system’s integrity and whether it performs its intended functions unimpaired and securely (see Part 4). Six criteria can serve as a framework for measuring the performance of the technology dimension of DSPDS. First, the extent to which the system is conceived and executed using a human-centered design, ensuring its accessibility to all users. Second, the system’s efficiency in terms of 138 “WHAT MATTERS” GUIDANCE NOTE being available to users continuously and uninterruptedly. Third, the application of data security and privacy considerations to ensure that the system protects and secures user data and sensitive personal information. Fourth, the scalability of the system to ensure that it is able to expand and adapt to increasing demands and changing needs. Fifth, the ability of the system to exchange data with other systems or platforms. And sixth, the cost-benefit of the systems. • The governance or institutions dimension assesses how the institutional and legal arrangements of DSPDS enable the secure and timely collection, processing, sharing, use, and destruction of data. The three criteria used as a framework for measuring the governance dimension’s performance follow the governance levels identified in Part 5. Strategic performance metrics measure the system’s alignment with the government’s mission and vision and how it supports the implementation of DSPDS. Administrative metrics measure the effectiveness and efficiency of back-office operations in ensuring adequate internal management and decision-making processes. Operations metrics measure the effectiveness, efficiency, and quality of field operations for data collection and front-office support processes. C. SOCIAL PROTECTION SYSTEM PERFORMANCE Beyond supporting the operational delivery of social protection programs, DSPDS can enhance the performance of the overall social protection system (big “S”) through data analytics for monitoring and evaluation. As mentioned before, the throughput of DSPDS are data integrated from different sources. Hence there is a direct relationship between the quality of DSPDS data and the accuracy and pertinence of the analyses that can be done with them. These data can be used to measure the effectiveness of social protection policies, identify areas where they are falling short, and track their implementation progress over time. Two concrete examples of how data analytics from DSPDS can support in improving the efficiency and effectiveness of the overall social protection system are provided below. (i) Identifying redundancies and complementarities through integrated beneficiary registries (IBR) Once benefits—whether monetary, services, or in-kind—have been delivered to the intended beneficiaries and reconciled, each program BOMS generates a beneficiary registry of the corresponding benefit period. Each program may generate beneficiary registries with different periodicities according to their operating procedures, such as monthly, bi-monthly, quarterly, or other. The main fields contained in the beneficiary registries are determined by the benefit management data sets described earlier but mainly consist of the biographic details and unique identifier of the beneficiary, benefits delivered, as well as the date and place of delivery. Thus, individual programs can use the beneficiary registries generated by their BOMS to keep track of who their beneficiaries have been and the benefits that have been delivered to them. However, when individual beneficiary registries are maintained in siloed BOMS, the efficiency across multiple programs is hard to gauge. Within a DSPDS framework, it is important to compile data on multiple programs in order to capture the overall dynamics of the social protection system of a given country, and not just of individual programs. As such, IBR centralize the beneficiary registries of multiple programs by pulling them from the individual program BOMS and integrating them periodically. Depending on the level of automation and interoperability of DSPDS, data exchange between program BOMS and the IBR can happen in the back end of those platforms. Regardless of Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 139 CONCEPTUAL FRAMEWORK how the beneficiary registries are actually transmitted, the exchanges must comply with predefined data sets to guarantee syntactic and semantic interoperability between the BOMS of individual programs and the IBR. Likewise, the periodicity of the exchanges is set by the operating procedures of each program, as highlighted earlier. The terms and conditions of the beneficiary registry exchanges also need to be supported by a written agreement (MoU or other) between the individual programs and the entity managing the relevant systems. Pulling together data from beneficiary registries of multiple programs through an IBR is key to detecting potential redundancies and complementarities across programs. When social protection systems are fragmented—as is commonly the case—it is hard to assess the performance of the overall system. IBRs can be used by policy makers to do such a systemic assessment by analyzing the benefits that are concurrently delivered by different programs to the same beneficiaries. Depending on the objectives of the programs and the type of benefits they deliver, benefit concurrences may be considered redundant or complementary. For instance, in federal regimes, different levels of government may provide similar benefits to the same beneficiaries, such as non-contributory old-age pensions, that require duplicate investments in program infrastructure from federal and state-level governments. Such redundancies are easily spotted once beneficiary registries from a wide range of programs are integrated into an IBR. In Mexico, the IBR (Padrón Único de Beneficiarios, PUB) was used to detect potential redundancies in the school-supplies benefits concurrently provided by a federal- and a state-level program. By cross-referencing the registries of both programs, the IBR was able to identify nearly 100,000 poor student beneficiaries who were receiving both a cash transfer meant to be used for school supplies and the in-kind school supplies themselves.159 The results of the redundancy analysis were provided to both programs, which in turn used them to ensure their respective coverages do not overlap, thus better leveraging their resources and maximizing their combined reach. On the other hand, potential complementarities across programs can also be detected. An intervention that improves the health of low-income households, such as deworming pills, can be highly complementary to an education intervention, such as a fee waiver; when combined, these interventions can have a greater impact on school attendance. As such, IBRs can also be used to support the referrals and effective intermediation of case management systems in order to leverage program complementarities. (ii) Tracking inclusion and exclusion errors with DSPDS Inclusion and exclusion errors are commonly used metrics to determine the likely targeting performance of programs. Conceptually, inclusion and exclusion errors are derived from confusion matrices whereby the predicted and actual status of a household as poor or not poor are compared and contrasted. This is relevant for programs that cannot directly observe welfare and that use methods such as PMT (discussed in Part 3, section (iii) Assessment of needs and conditions) to estimate the welfare of potential recipients. Because welfare estimation is the output of a statistical model, it will inevitably have prediction errors. The main motivation for analyzing these errors is to calibrate and tweak the model to optimize its performance during the design phase of the program. The prediction errors quantify the share of people that will likely be correctly or incorrectly classified out-of-sample as poor and non-poor at different levels of potential coverage when the program is rolled out. As such, this confusion matrix’s true/false positives and negatives are computed by comparing the welfare model predictions against the “ground truth” values obtained from the representative household survey used to calibrate the model. 159. PowerPoint presentation, “Sistema de Información Social Integral” (SEDESOL 2011b). 140 “WHAT MATTERS” GUIDANCE NOTE Yet, prediction inclusion and exclusion errors do not identify which households have actually been covered correctly or incorrectly during the enrollment of the program. This is because prediction inclusion and exclusion errors can only be identified on the sample of households that is used to train the welfare model, before actual program enrollment. In order to assess the effectiveness of a program’s coverage, within a DSPDS framework, data from the dSR and the IBR can be cross-checked to estimate coverage inclusion and exclusion errors. By integrating these two data sources through a common unique identifier—ideally provided by a unique identification platform— it is possible to determine who was deemed eligible at the assessment of needs and conditions stage and who was actually enrolled and benefited during the provision stage. This analysis allows for precisely determining the households and individuals who were incorrectly intervened (coverage inclusion errors) or incorrectly not intervened (coverage exclusion errors). In this instance, the confusion matrix is computed according to the predicted welfare and eligibility status provided by the dSR and the actual enrollment status and benefits delivered according to the IBR. Prediction and coverage inclusion/exclusion errors have different sources. The prediction inclusion/exclusion errors are inherently tied to the limitations of the welfare estimation process. Factors include the sophistication of the statistical model, the size of the sample used to train the model, the estimated program coverage, and the welfare distribution of the country or region for which the model is being specified. On the other hand, coverage inclusion/exclusion errors can result from multiple types of constraints. Lack of fiscal space is usually an important source of coverage exclusion errors, as well as the lack of capacity for delivery systems to scale, particularly when there are competing policy priorities. As for coverage inclusion errors, elite capture, fraud and corruption, and electoral processes can all play a role in incorrectly enrolling non-eligible households as beneficiaries. While prediction and coverage inclusion/exclusion errors have different sources, it is useful to understand how they interact during program implementation (see Figure 27). Prediction and coverage inclusion/exclusion errors can be integrated into the “social protection delivery confusion cube.” The confusion matrix of prediction inclusion/exclusion errors contrasts “ground-truth” welfare versus predicted welfare, whereas the confusion matrix of coverage inclusion/exclusion errors contrasts predicted welfare versus program coverage. Since both matrices share the predicted welfare dimension, they can be combined into a cube that integrates all three dimensions, as pictured in Figure 27. By combining the poor/non- poor with the included/excluded states, we obtain 8 combinations depicted as the octants of the social protection delivery confusion cube. Conceptually, programs should aim to maximize octant 1 of the confusion cube, whereby poor households are correctly characterized and included (true positive and true coverage), and octant 8, whereby non-poor households are correctly characterized and excluded (true negative and true coverage). Likewise, octant 3—correctly characterized poor households that are excluded—which captures true under-coverage, and octant 6—correctly characterized non-poor households that are included—which captures true leakage should be minimized. However, it must be noted that the social protection delivery confusion cube is a construct that is not easily computed since ground truth welfare data are not usually available for the complete set of registrants and beneficiaries. If such data exists, then there would be no need to estimate welfare, and the confusion matrix of coverage inclusion/exclusion errors would contrast actual welfare versus program coverage. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 141 CONCEPTUAL FRAMEWORK FIGURE 27 Social protection delivery confusion cube PREDICTION GROUND TRUTH COVERAGE Poor Poor Included 1 True Positive True Coverage Not Poor Poor Included 2 False Negative False Leakage Poor Poor Excluded 3 True Positive True Under-Coverage Not Poor Poor Excluded 4 False Negative False Coverage Poor Not Poor Included 5 False Positive False Coverage Not Poor Not Poor Included 6 True Negative True Leakage Poor Not Poor Excluded 7 False Positive False Under-Coverage Not Poor Not Poor Excluded 8 True Negative True Coverage SOURCE: Original for this publication. 142 “WHAT MATTERS” GUIDANCE NOTE ASSESSMENT TOOL III. Assessment Tool Diagnosing the current state of DSPDS is critical for identifying areas of strength and weakness and informing strategies for improvement. The Assessment Tool on DSPDS aims to provide a comprehensive framework for governments to assess the maturity of the existing social protection digital delivery systems and the gap to achieving more inclusive and efficient systems. The Assessment Tool is not intended for cross-country comparisons. It is designed for use by government agencies, development partners, and other stakeholders involved in social protection programming to identify areas for improvement, make informed decisions, and ensure that DSPDS are functioning optimally to reach those in need, all while embracing the importance of human-centered design, which prioritizes the needs, experiences, and perspectives of individuals. The Assessment Tool employs a combination of qualitative and quantitative techniques to diagnose the existing DSPDS by conducting a comprehensive review of key components, including institutions, technology, data, processes, and performance measurement. The Assessment Tool is designed for use by a multidisciplinary team of experts in social protection, technology, and data protection and privacy. Members of the assessment team should possess a range of skills and expertise required to conduct a comprehensive evaluation of DSPDS, with a specific focus on interoperability and social registries. The team should include individuals with technical expertise in areas such as data management, system architecture, and software development; social protection experts with a deep understanding of the needs, capacities, opportunities, and challenges facing vulnerable populations and programs, as well as an in-depth understanding of the different life cycle risks; and legal advisors with expertise on relevant regulations and ethical standards regarding data protection and privacy. The team must possess an in-depth understanding of the public administration in the country, the role of the different institutions, their relationships, interactions, and current data-sharing arrangements. The team should work together to collect and analyze data using both qualitative and quantitative methods and use their collective knowledge and experience to identify strengths and weaknesses in the current state of DSPDS. Based on this analysis, the team should propose actionable recommendations for Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 145 ASSESSMENT TOOL improving the functionality and effectiveness of these systems. The assessment team could draw from existing materials and/or produce some of them (if not available) to complete the assessment. The main deliverable is a Country Report presenting findings, highlighting strengths and weaknesses of existing DSPDS, and providing recommendations to fill in the gaps toward becoming more dynamic and interoperable. Administering the Assessment Tool involves a range of activities, including conducting interviews with relevant stakeholders from different backgrounds, as well as desk work to gather and analyze data. To begin, the assessment team should identify and engage with key stakeholders from across government, social protection program operators, civil society, program beneficiaries, and other relevant actors to ensure that as many perspectives as possible are considered in the evaluation process. This may involve conducting interviews and focus groups with program managers, IT professionals, and other individuals involved in social protection system design and implementation, as well as beneficiaries and other stakeholders impacted by these systems. Complementary methods such as incognito visits and observation may also be used for this assessment. Additionally, desk work should be conducted to collect and analyze information from a variety of sources, including program reports, system documentation, evaluations, and other relevant materials. Process mapping and journey maps can support the administration of the Tool (Annex 3). Ultimately, a rigorous and systematic approach to administering this tool is critical to ensuring that the assessment is comprehensive, accurate, and actionable, and that the resulting recommendations can help guide efforts to strengthen DSPDS and improve outcomes for those who rely on them. While this tool attempts to capture different scenarios, the assessment team can make adjustments to ensure it is relevant to the local context. It can be used at any government level, in centralized and decentralized states. The Assessment Tool is implemented in two steps. The first step will help embed the analysis of DSPDS within the broader context of the country and its social protection landscape. It will help gather context to understand the current state of social protection and digital delivery systems, as well as the stakeholders involved, in order to determine the objectives and scope of the assessment. This information will help in planning the approach and implementation of the subsequent step, ensuring that it is tailored to the specific needs and circumstances of the systems being assessed, as well as identifying key stakeholders and informants. The second step will help assess the current status of DSPDS with a major focus on social registries and interoperability. Other component systems of DSPDS, such as identification systems and payments platforms, are assessed in depth by dedicated ISPA tools. Four ranking criteria—absent, nascent, emerging, and advanced— are used to assess the level of maturity or progress in a given area within policy and governance, delivery, data, technology, and performance dimensions. The absent level refers to the absence of any effort or progress in the area being assessed. It indicates a complete lack of implementation, planning, or awareness of the topic in question. At the nascent level, there might be some initial steps taken, but they are not yet integrated, established, or coherent enough. It may involve limited planning, initial discussions or research, or small-scale pilot programs. The emerging level denotes a growing or maturing stage of development or implementation, where efforts are starting to show signs of progress and becoming more established. However, some gaps or inconsistencies still need to be addressed. Finally, the advanced level implies a comprehensive and effective approach that is continuously reviewed and improved, with clear goals, processes, and outcomes. The advanced level represents a benchmark aligned with the Playbook’s Guidance Note. As even relatively small movements and achievements have the potential to translate into important long-term progress, the levels in between seek to record signs of progress toward building effective and efficient DSPDS. Each question is accompanied by a set of exploratory questions that will allow a better understanding of the current situation of the systems under a more qualitative approach. 146 ASSESSMENT TOOL STEP 1. COUNTRY AND SOCIAL PROTECTION CONTEXT Country at a glance In the following table, where data are not available, enter “—” in the value column; revisit and update these items when and as possible. Note data sources in the source column for each indicator. Note any applicable data limitations and disaggregate indicators for different population groups of interest where possible. TABLE A Country at a glance Indicator  Value  Year  Source Economic indicators  Gross domestic product (GDP) per capita in current $        GDP per capita in PPP        Consumer Price Index (CPI)        Demographic indicators  Total population        % female        % of population age 0–14        % of population age 15–64        % of population age 65+        % of population with disabilities (specify definition according to local context) Life expectancy (at birth)        Literacy rate        Internally displaced people (IDPs)/refugees        Labor market indicators  Currently active population (labor force)       Labor force participation       Total unemployment        Youth (age 15–24) unemployment        Informal employment rate       Minimum wage (differentiate by sector, if necessary)        Average monthly/annual wage       Median monthly/annual wage       Gender wage gap       Social indicators  Poverty headcount according to national poverty line(s)        Poverty headcount according to international poverty line        National poverty line(s) (by rural/urban if applicable)        Poverty gap        Multidimensional poverty index        Income inequality (Gini coefficient)        IPC Integrated Food Security Phase Classification       Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 147 ASSESSMENT TOOL Indicator  Value  Year  Source Food Consumption Score Human development index (HDI)        HDI rank out of ___       Social spending as % of GDP        Social protection coverage (total)       Social protection coverage (poorest quintile)       Share of population with cash income support       Share of population above statutory retirement age (___ years old) benefiting       from an old-age pension Share of population contributing to a pension scheme       Public health expenditure as % of GDP       Health insurance coverage       Programs, systems, and stakeholder mapping Program and information systems mapping is critical to assessing the current state of DSPDS. This process involves mapping out key social protection programs, associated information systems, and main actors within a given jurisdiction (for example, central government, subnational governments, and so forth) in order to determine the scope of the assessment. The Assessment Tool can be applied to the entire social protection system within a country or subnational level or focus on key programs and/or information systems, as informed by the following set of questions, based on Part 1 of the Guidance Note. 1. For each key social protection program in the country or territory, fill in the information in the following table (to be adapted to the local context and how the social protection system is organized). This section can be informed by operations manuals, reports, existing program inventories such as the ASPIRE compilation,160 the World Social Protection Database,161 or interviews with key informants. Note that the set of key social protection programs to be mapped should be jointly defined between the requesters of the assessment and the assessment team to ensure a balance in effort in mapping and its value on the assessment of the DSPDS framework. TABLE B Program mapping Program name   Implementing agency   Year of creation   Related legislation (if any) Annual budget and source of funding   Total expenditure (latest year available) Contributory or non-contributory If contributory: voluntary or mandatory Description of benefits or services delivered   Association to social protection (SP) main pillars (social assistance, social insurance,   labor market, humanitarian, …): 160. https://www.worldbank.org/en/data/datatopics/aspire/indicator-glance. 161. International Labour Organization (ILO), World Social Protection Dashboards. https://www.social-protection.org/gimi/WSPDB.action?id=32 . 148 ASSESSMENT TOOL Assistance unit (for example, individual, household)   Geographic scope (for example, national, rural, regional)   Eligibility criteria   Size of the intended population (A)   Number of beneficiaries (female/male) (B)   Program coverage (B/A)   Are there any conditionalities or co-responsibilities associated with the program?   Which ones? For cash transfer programs, what are the current payment modalities? What share of beneficiaries falls under each payment modality? Does the program have processes documented in manuals, operating rules, or other   documents? Does the program have a data protection policy or mechanism for informed consent when collecting data? How does the program verify the identity of individuals? Does the program use a social registry to support the assess stage (outreach, intake and registration, assessment of needs and conditions)? If YES, is it program- specific? Who is responsible for it? If NO, how does the program intake data, register beneficiaries, and assess needs and conditions? Who is responsible for it? Does the program use a BOMS or program MIS to support the management of beneficiary operations? If YES, who is responsible for it? If NO, how does the program manage and keep track of beneficiary operations? Is there another information system(s) used to support the provision stage of   the program (for example, payments platform)? If YES, is it program-specific? Who is responsible for it? If NO, what system(s) does the program use to support the provision of benefits and services? Who is responsible for it? Is there a grievance redress mechanism platform in place? If YES, is it program- specific? Is it a separate information system? If NO, how does the program keep track of grievances? Does the program exchange data with other agencies or platforms? If YES, describe how and what information is shared 2. Respond the following cross-cutting questions: TABLE C Cross-cutting systems Is there an e-government strategy or a national digitalization strategy? If YES, what is its name? What government institution is responsible for it? Is there a unique identification system(s) in place? If YES, what is its name? What agency is responsible for it? What is the share of population covered, of which women? Is there a social registry serving two or more programs in place? If YES, what is its   name? What agency is responsible for it? Is there an integrated beneficiary registry (IBR) in place? If YES, what is its name?   What agency is responsible for it? How many programs are integrated in the IBR? Is there a payments platform serving two or more programs in place? If YES, what is its name? What agency is responsible for it? Is there a grievance redress mechanism (GRM) platform serving two or more programs in place? If YES, what is its name? What agency is responsible for it? Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 149 ASSESSMENT TOOL Is there a case management information system in place? If YES, what is its name? What agency is responsible for it? Is there a data analytics platform in place? If YES, what is its name? What agency is responsible for it? Is there a geographic information system in place? If YES, what is its name? What agency is responsible for it? Is there a program inventory in place? If YES, what is its name? What agency is responsible for it? Is there a data exchange platform in place? If so, what is its name? What agency is responsible for it? 150 ASSESSMENT TOOL ASSESSMENT TOOL STEP 2. SYSTEMS ASSESSMENT (i) Policy and governance No. Question Absent (0) Nascent (1) Emerging (2) Advanced (3) Exploratory questions 1.1 Is there a national social No national SP A national SP A national SP policy, A national SP policy, - What are the key policy pieces and laws regulating SP protection (SP) policy, plan, policy, plan, or policy, plan, or plan, or strategy exists plan, or strategy exists policies and their financing and implementation? or strategy outlining the SP strategy exists, strategy exists or or is in development. and has been adopted. - What are the country’s SP objectives? strategic objectives of the nor is it in is in development. The policy, plan, or It contains a clear - Year of adoption and period of validity country? If YES, does it mention development. There is no strategy describes and comprehensive the role of data and technology mention or plan the importance of description of the role of - What population groups are explicitly identified in the SP for SP? Does it detail to integrate the data and technology data and technology for strategy as a priority? measurable, and achievable role of data or for SP. Measurable SP. It outlines a detailed - What types of SP programs/schemes do the strategy goals and milestones toward technology for SP and achievable goals plan with measurable, cover? the use of data and information in the document. and milestones for and achievable goals - Which government bodies/agencies are responsible for SP systems for SP? the use of data and and milestones for policy making, implementation, and oversight? [Part 1.A] information systems the use of data and - Did the policy-making process require the participation for SP are not outlined. information systems of relevant stakeholders outside the national government? for SP. Which ones? 1.2 Are the legal and regulatory No documentation Initial Frameworks governing Comprehensive and - What are the objectives, priorities and goals established frameworks that govern and or awareness documentation of and guiding DSPDS well-documented in the frameworks’ governing DSPDS? guide DSPDS in place? * If of frameworks frameworks has are documented and frameworks are in - What are the institutional arrangements at the strategic, YES, do they clearly state the governing DSPDS. significant gaps clearly articulate the place with clearly administrative, and operational levels and how do they objectives, priorities, goals, Lack of clarity on objectives, objectives, priorities, defined and coherent interrelate? institutional arrangements, on objectives, priorities, goals, goals, institutional objectives, priorities, - What are the rights and obligations of actors—designers, financing, and rights and priorities, goals, institutional arrangements, goals, institutional implementors, administrators, and so forth—as outlined in obligations for people? Are they institutional arrangements, financing, and rights arrangements, financing, the frameworks’ governing DSPDS? supported by a robust legal arrangements, financing, and and obligations, and rights and foundation (including policy financing, and rights and with only some gaps obligations for people. - Are the frameworks continuously reviewed and improved? instruments, law, and regulatory rights and obligations. or inconsistencies. The frameworks are - Are there feedback mechanisms for guiding review and measures)? obligations for Limited or no Frameworks are supported by robust improvement and capturing insights from actors at all [Part 5.A] DSPDS. policy or legal supported by key legal legal foundation, levels? foundation, foundational pieces, extending beyond - To what extent are these frameworks integrated and * This question can be adapted with ongoing though they are still the policy level, with coherent within the overall social protection strategy (Q.1.1)? to the country context to inquire discussions or under development. concrete legal and - Are there any gaps or inconsistencies in the current about key existing DSPDS initial steps. regulatory elements documentation or implementation of these frameworks? components such as unique in place and clear - What are the legal foundations—including policy pieces, identification systems, social articulations and laws, and regulatory instruments—supporting these registries, payments platforms, understandings of rights frameworks? or interoperability of systems. and responsibilities for actors to abide by and - Has a multistakeholder approach been taken to develop implement. and elaborate the approach? - What measures are taken to help to ensure equality of treatment and to preserve beneficiary dignity? Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 151 ASSESSMENT TOOL No. Question Absent (0) Nascent (1) Emerging (2) Advanced (3) Exploratory questions 1.3 Are there documented No documented Some processes All relevant processes All relevant processes - What processes and key concepts are documented? What standards, guidelines, and standards, and key concepts and key concepts and key concepts concepts are incomplete or not documented? protocols supporting the guidelines, are documented, are documented are documented and - Have these standards, guidelines, and protocols been operation of DSPDS? * If YES, or protocols but they are not and are well-defined are well-defined and officially adopted and integrated into the operational are key concepts, such as supporting the comprehensive and comprehensive. comprehensive, thus procedures? intended population, assistance operation of the and may be Relevant processes fostering their effective - How are these standards, guidelines, and protocols unit, eligibility criteria, and system(s), causing incomplete. Front- are communicated implementation communicated to front-office and back-office users? Is the targeting criteria, clearly confusion and and back-office to front-and back- and enforcement. communication process effective and well-understood by defined? Are the relevant inconsistencies users have some office users, but there Relevant processes all stakeholders? processes and concepts in the notions about may be some gaps are fully available and communicated effectively to implementation. the most relevant or inconsistencies in well-understood by - Are there any discrepancies or variations in the front- and back-office users? processes but still their implementation. front- and back-office interpretation of processes or key terms among different Are these standards and require significant Users are somewhat users through a wide stakeholders? How are these variations addressed? guidelines updated to reflect assistance to familiar with key range of supporting - Are there training programs or resources available to changes in conditions? carry out basic concepts, causing materials, training, and/ ensure that front- and back-office users are adequately [Part 1.B, 3.A, 5.B, and 5.C] procedures. limited inconsistencies or communications. informed about these standards and guidelines? Users may not be in the implementation. Users are well-familiar - To what extent are these standards, guidelines, and * This question can be adapted familiar with key Processes are with key concepts protocols tailored to the specific needs and context of the to the country context to inquire concepts causing sometimes updated leading to a consistent social protection programs in question? about key existing DSPDS inconsistencies to reflect changes implementation - Are there mechanisms in place to gather feedback from components such as unique in the in conditions. Processes are frequently users regarding the practicality and effectiveness of these identification systems, social implementation. These changes are updated to reflect standards and guidelines? registries, payments platforms, Processes are communicated changes in conditions. - How often are the documented standards, guidelines, or interoperability of systems. rarely updated to to users in an These changes are and protocols reviewed and updated to reflect changes in reflect changes in unstructured way. communicated to users operational conditions, technological advancements, or conditions. on time, on a structured shifts in social protection policies? way. - Are changes and updates to the standards and guidelines effectively communicated to all relevant stakeholders? - Is there a dedicated team or authority responsible for managing and updating these standards, guidelines, and protocols? - How do these standards and guidelines address data protection and privacy concerns, especially when it comes to handling sensitive personal information within the DSPDS? 152 ASSESSMENT TOOL ASSESSMENT TOOL No. Question Absent (0) Nascent (1) Emerging (2) Advanced (3) Exploratory questions 1.4 Is there a coordinated and There is no Some cross- There is a coordinated There is a well- - What Is the structure and membership of the institutionalized mechanism mechanism sectoral and/or and institutionalized coordinated and coordination body? Does it involve the participation of for cross-sectoral and inter- fostering cross- inter-ministerial mechanism for highly institutionalized stakeholders beyond the national government? ministerial collaboration sectoral and/or coordination for SP cross-sectoral and mechanism for cross- - What are the main responsibilities of the coordination for SP activities, programs, inter-ministerial exists, but it is not inter-ministerial sectoral and inter- body? or policies? If YES, is there a coordination for institutionalized. collaboration in SP. ministerial collaboration - What enforcement mechanisms are in place? coordination body (working SP. Government Government There is an operational in SP. There is a highly groups, committee, council, and entities entities coordination body that functional coordination - If there is ad hoc coordination (no coordination body in so forth) focusing on improving responsible responsible for SP focuses on improving body that focuses on place), how does it work? coordination and collaboration for SP operate coordinate on an efficiency and improving coordination of various SP actors more independently. ad hoc basis. collaboration among and collaboration of broadly? Does the coordination some SP actors. It all relevant SP actors. It body have the capacity to operates under a clear operates under a clear enforce agreements? mandate, but it does mandate and has the [Part 5] not have the capacity capacity to enforce to enforce agreements. agreements. 1.5 Are there any collaboration No collaboration No formal Some collaboration Strong commitment - What types of activities are coordinated (outreach, intake agreements for bi-directional agreements collaboration agreements have to bi-directional data and registration, targeting, financial management, delivery data sharing, cost-sharing, in place for agreements been developed sharing, cost-sharing, of benefits, monitoring and evaluation, grievance redress, operational support, or data sharing, exist, but some and formalized. operational support, complementarities and redundancy of benefits, and so integration of delivery chain cost-sharing, programs or Clear recognition and integration. forth)? functions for SP programs? operational institutions of the benefits of - Who are the key stakeholders or entities involved in these Have these agreements been support, or collaborate bi-directional data Agreements encompass collaboration agreements, and what roles do they play? operationalized at the front- integration of willingly for sharing, cost-sharing, a wide range of - How are potential data privacy and security concerns and the back-end? delivery chain data sharing, operational support, functions within the addressed within these collaboration agreements? [Part 5.B] functions. cost-sharing, and integration delivery chain. operational of delivery chain - Have there been any challenges or obstacles encountered support, or functions, but there Collaboration in the process of developing or operationalizing these integration of are important avenues agreements are fully collaboration agreements? some delivery for further integration operationalized at - Are there mechanisms in place to regularly review and chain functions. and collaboration. both the front- and the update these collaboration agreements to ensure their back-end, leading to relevance and effectiveness over time? seamless integration and cooperation. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 153 ASSESSMENT TOOL No. Question Absent (0) Nascent (1) Emerging (2) Advanced (3) Exploratory questions 1.6 How effectively do (i) human (i) No dedicated (i) Limited number (i) Human resource (i) Robust and skilled - How well are human resource capacities and financial resource capacities and (ii) human resources of personnel with capacities are in human resource resources aligned with the operational needs and strategic financial resources, support to operate DSPDS. a state of growth partial skills related capacities are in goals of DSPDS? the operation of DSPDS?* to DSPDS. and maturation. place to effectively - How comprehensive and structured are the training [Part 5.B] (ii) No financial Noticeable expansion support the operation programs provided to staff responsible for managing and resources allocated (ii) Limited funding in the number of of DSPDS. Personnel operating DSPDS? * This question can be adapted to support the or financial individuals with possess advanced - How are financial resources allocated to support the to the country context to inquire operation of commitment, relevant knowledge, skills, continuously operation, maintenance, and improvement of DSPDS? about key existing DSPDS DSPDS. not sufficient for but there may still be improving and adapting components such as unique effective operation. areas where additional to technological - Provide an overview of the funding sources and budget identification systems, social skill development is and operational allocation for different aspects of the system’s functionality, registries, payments platforms, needed. advancements. including field operations, staffing costs, hardware, or interoperability of systems. Comprehensive training software, training, and ongoing maintenance. (ii) Adequate financial programs and capacity- - Are there mechanisms in place to ensure transparency resources allocated, building initiatives and accountability in the management and utilization of allowing for effective ensure a high level financial resources for the systems? functioning. of expertise across relevant domains. (ii) Stable and substantial financial resources support ongoing operations and continuous improvements. 1.7 Is there a data protection No data protection A basic data A comprehensive data A comprehensive and - What are the key laws and acts regulating data protection regime in place including a regime is currently protection regime protection regime granular data protection and privacy? data protection regulation in place. SP exists but is not exists and is somehow regime exists, and it is - What is the structure of the data protection authority? and an operational data operators do not fully operational. operational. Regulation effectively implemented - Describe specific measures, policies, or procedures protection authority? If YES, adhere to any of Regulation is not is comprehensive and enforced to fully implemented to ensure that personal data collected, to what extent is it consistent the fundamental comprehensive or but there are gaps protect data and ensure stored, and processed within DSPDS adhere to the with the fundamental principles principles for granular enough to or inconsistencies in data privacy pertaining principles of data protection and privacy. for protecting and processing protecting and fully protect data its implementation to SP operations. Data personal data (purpose processing privacy or ensure or enforcement that protection authority is - How are individuals’ rights with regards to their personal specification, data minimization, personal data. data protection may leave room for fully operational. The data addressed within DSPDS? What mechanisms are in lawfulness, fairness, and pertaining to potential breaches data protection regime place to empower individuals to access, rectify, or request transparency, accuracy, SP information in data protection or is consistent with the the removal of their data, and how effectively are these retention limitation, security, systems. privacy (for example, fundamental principles mechanisms communicated and operationalized? and accountability)? If NO, do SP data protection for protecting personal - How are individuals sensitized about their rights? operators (programs/systems In countries authority is not data. administrators) integrate these without a data operational). principles? protection regime [Part 5.A] in place, one or In countries without a more SP operators robust national data adhere to some of protection regime, all the fundamental SP operators adhere principles for to the fundamental protecting principles for protecting personal data in an and processing ad hoc way. personal data. 154 ASSESSMENT TOOL ASSESSMENT TOOL No. Question Absent (0) Nascent (1) Emerging (2) Advanced (3) Exploratory questions 1.8 Is there a consent mechanism There is no Initial steps have A consent mechanism A comprehensive - How are individuals informed about the purposes for in place for intaking and consent been taken toward is in place, meeting consent mechanism which their data will be processed, and to what extent is sharing personal data into mechanism in implementing some of the is being implemented this information clear, concise, and transparent? DSPDS?* If YES, is it (i) freely place. a consent fundamental criteria, that fully addresses - How is the consent mechanism designed to given, (ii) specific, (iii) informed, mechanism, but improvements the four elements accommodate potential changes in the purpose of data and (iv) an unambiguous but it is not are needed for full of consent. The processing, and what processes are in place to inform agreement to collecting, fully integrated compliance. Efforts mechanism ensures that individuals and seek their renewed consent when such storing, processing, creating, or established. are made to inform consent is given freely, changes occur? manipulating and other Consent processes individuals about the is specific, informed, - Are mechanisms in place to ensure that the consent processing of personal data? may lack clarity, processing of their and unambiguous process is specific, meaning that individuals can grant or Are there mechanisms in specificity, or data and their rights and that it is obtained withhold consent for distinct processing activities? place to ensure that when adherence to regarding consent, through an active the purpose(s) change(s), key principles. including when the declaration of opting-in. - How is it ensured that individuals are adequately that people are informed and There is limited purpose changes. The mechanism allows informed about their rights related to data protection and requested/given the ability to understanding of Efforts are made to for the withdrawal of how their data will be processed within DSPDS? renew their consent? consent among educate on the nature consent at any time - Describe the steps taken to obtain unambiguous consent, [Part 5.A] administrators and of data and to increase and with the same ensuring that individuals fully understand the implications beneficiaries. There digital literacy among ease with which it was of their agreement to data processing. * This question can be adapted is no updating beneficiaries and given. Additionally, the - What are the mechanisms for individuals to easily to the country context to inquire mechanism in across society. mechanism prioritizes withdraw or modify their consent to data processing at any about key existing DSPDS place. data protection point after providing initial consent? components such as unique and privacy of the - What efforts are being taken to educate and to sensitize identification systems, social beneficiary’s personal beneficiaries and across society about the nature of data registries, payments platforms, data and ensures that and to increase digital literacy? or interoperability of systems. control over the use of personal data is given back to the individual. There are clear and operational updating mechanisms. Robust efforts are made to educate on the nature of data and to increase digital literacy among beneficiaries and across society. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 155 ASSESSMENT TOOL (ii) Delivery NO. Question Absent (0) Nascent (1) Emerging (2) Advanced (3) Exploratory questions 2.1 How effective is the No outreach There is a basic There is a documented The outreach strategy for - How has the outreach strategy been designed outreach strategy for strategy is outreach strategy outreach strategy for DSPDS is well documented and to target and engage the intended population, DSPDS?* To what extent is documented documented for DSPDS that includes some includes detailed planning, and what mechanisms are in place to ensure the outreach strategy being or planned for DSPDS, but it lacks planning, differentiation, differentiation, consideration that it is effectively reaching the intended implemented? How effective DSPDS. There is specificity, planning, consideration of the cultural of the cultural context, and population? is it in reaching the intended no evidence of differentiation, context, and/or monitoring monitoring procedures that - How are people informed about programs population? Is the intended the effectiveness consideration of the procedures, but it could be are regularly evaluated and and delivery systems, in particular DSPDS? population informed of isolated cultural context, and/or more comprehensive. The updated based on feedback - Describe examples of specific outreach about their rights and outreach monitoring procedures. outreach strategy is being and data analysis. The channels, methods, or campaigns that have responsibilities (for example, efforts (if any) Some initial steps have implemented in some areas, outreach strategy is being been employed to promote awareness and that registration does not in reaching been taken toward but not consistently or consistently and effectively engagement with DSPDS. guarantee enrollment in SP the intended implementing the effectively across all target implemented across all target programs or awarding of population. outreach strategy, but populations and geographic populations and geographic - How is the implementation of the outreach benefits, how the intake and it has not yet been locations. There is some locations. There is evidence strategy monitored and evaluated? registration process works, fully operationalized. evidence of its effectiveness of success in reaching the - What are the key messages communicated program’s eligibility criteria, There is little to no in reaching the intended intended population, backed through the outreach strategy? how enrollment decisions are information available population, but it is not with systematic tracking - What mechanisms are in place to address made, and so forth)? on its effectiveness in systematically tracked or and evaluation. There is language barriers, literacy levels, cultural [Part 3.A] reaching the intended evaluated. There is some high awareness among the considerations, accessibility barriers, and so population or whether understanding among the intended population on their forth, that might affect the effectiveness of * This question can be they are informed intended population on their rights and responsibilities the outreach strategy in conveying important adapted to the country about their rights and rights and responsibilities toward DSPDS. information to diverse segments of the context to inquire about responsibilities toward toward DSPDS. population? key existing DSPDS such as DSPDS. unique identification systems, social registries, or payments platforms. 2.2 How effectively do DSPDS There is no front- There is a front-office There is a front-office There is a well-established - What modalities are provided for people to provide a front-office office interface interface, but it is not interface, widely available or and efficient front-office access the front-office interface? interface for people to provided by widely available or accessible to most people interface, widely available and - Provide an overview of the specific processes interact with programs DSPDS. People accessible. Only a few through various points of accessible to all households and services that beneficiaries can access along the delivery chain?* interact with selected procedures contact/ channels. Not all and individuals though various through the front-office interface (for example, [Part 3.A and 5.C] SP programs along the delivery procedures where people points of contact/channels. application to programs, updating data, status exclusively in chain are available need to interact with SP The front-office interface of benefits, grievance redress, and so forth). * This question can be person. to people, while the programs along the delivery consolidates all of the - What are the main barriers to accessing the adapted to the country rest need to be sorted chain are available through procedures where people need front-office interface or the services provided? context to inquire about out in person. The this interface. Moreover, to interact with SP programs. What is the coverage of such services? key existing DSPDS such as services provided there may be some The services provided are unique identification systems, may be considered limitations or barriers to streamlined, and there are - How efficient are the services provided? social registries, or payments inefficient or slow or accessing it and the services minimal barriers or limitations (for example, time, costs, and visits, journey platforms. exclude some people provided may not be fully to accessing them. There mapping, processing times, and so forth) (for example, people efficient or may exclude are no apparent sources of - Is feedback from people integrated to without an ID, IDP, some people (for example, exclusion for any group. improve the functioning of the front-office migrants, refugees, and people without an ID, IDP, interface? How? so forth). migrants, refugees, and so forth). 156 ASSESSMENT TOOL ASSESSMENT TOOL NO. Question Absent (0) Nascent (1) Emerging (2) Advanced (3) Exploratory questions 2.3 Is there a single window or Each program There is some level of There exists a unique There exists a well-established - Describe intake and registration processes of gateway (for example, social operates coordination among gateway for intake and and widely used gateway key programs registry if available) for separately, and programs in terms of registration. However, there for intake and registration. - What are the information systems supporting intake and registration to SP there is no data collection, but are still some programs All programs use the same intake and registration across key programs? programs? If YES, how many coordinated most of them still operating in isolation at process, and households, and - If there is a unique gateway for intake and programs are users of this effort to collect operate in isolation intake and registration. individuals have a clear and registration, how many programs are using it? unique gateway? data and during intake and consistent way to apply to one Why are some not using it? [Part 3.A] register people registration. Applicants or multiple SP programs. for multiple need to apply to one or - How is the unique gateway made accessible programs. more programs using to people, ensuring equitable access across different channels. diverse segments of the population? 2.4 Are there mechanisms There is no There is no on-demand There is an on-demand There is a well-established - What modalities are the available for people in place for on-demand on-demand registration process registration process, but it and widely available on- to apply to programs? application to programs?* registration in place. Applicants is not consistently available demand registration process - For administrator-driven approaches, how is Can anyone register to key process in place. can only register to or advertised to all potential that allows for applicants to the frequency of registration determined? programs at any time (on- Applicants can programs during applicants. register at any time. - If on-demand registration is available, how demand)? Or is the entry only only register to specific periods is the process structured to ensure that possible periodically? programs during throughout the year beneficiaries can easily and efficiently register [Part 3.A] specific periods and are not able to when needed? spanned over apply at any other * This question can be several years time. adapted to the country and are not able context to inquire about key to apply at any existing SP programs. other time. 2.5 Does the social registry The social The social registry can The social registry can push The social registry can push - What are the purposes of the data exchange? exchange data with registry does not push data to programs AND pull data to/from AND pull data to/from - Are there clear protocols in place for data programs?* If YES, what are exchange data through limited program systems (either via program systems (either via sharing and interoperability? the purposes of the data with programs. electronic means program BOMS or the IBR). program BOMS or the IBR) - What share of the intended population is exchange? Are there clear (for example, Excel While exchanges may not seamlessly, facilitated by captured by data from programs? protocols in place for data spreadsheets, Stata, yet be fully automated, there interoperability. Data from the sharing and interoperability and so forth) to make are established protocols social registry informs program - What programs exchange data with the social with SP program systems? enrollment decisions for data sharing. Data from operations beyond enrollment registry? [Part 3.A] (for example, send list the social registry is used decisions, for example, by - How is the quality of the data from program of potential eligibility). by programs exclusively to providing information to systems assured? * For countries without a Programs do not feed make enrollment decisions. make exit decisions or to social registry, this question information back to Data from programs is monitor compliance with can be adapted to inquire the social registry. only used to inform future conditionalities. Data provided about key SP programs and eligibility decisions. by programs is used to actively the information systems used track inclusion and exclusion to support the assess stage of errors. the delivery chain. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 157 ASSESSMENT TOOL NO. Question Absent (0) Nascent (1) Emerging (2) Advanced (3) Exploratory questions 2.6 Does the social registry The social The social registry The social registry can The social registry can - What are the purposes of the data exchange? exchange data with registry does pulls data from a pull data from some pull data from several - Are there clear protocols in place for data administrative sources?* If not exchange few administrative administrative systems. administrative systems sharing and interoperability with administrative YES, what are the purposes data with systems through While exchanges may not seamlessly facilitated by data sources? of the data exchange? administrative limited electronic yet be fully automated, there interoperability. Data are - What share of the intended population is What share of the intended data sources. means (for example, are established protocols exchanged frequently to pre- captured by data from administrative data population is captured by Excel spreadsheets, for data sharing. Data are populate the social registry sources? administrative data sources? 2.6.1 No data Stata, and so forth) used to pre-populate the (intake), update and verify [Part 3.A] exchange with for data verification social registry (intake), applicants’ data, and help - What administrative data sources are used administrative purposes and/or to update and verify applicants’ programs monitor compliance within the social registry? 2.6.1 If applicable, is systems. apply exclusionary data, and/or help programs with conditionalities. A - How is the quality of the data from administrative data used to filters. A small share monitor compliance with large share of the intended administrative data sources assured? update applicant’s data? 2.6.2 No data of the intended conditionalities. Only part of population is captured by exchange with population is captured the intended population is administrative data sources 2.6.2 If applicable, is there administrative by administrative data captured by administrative (more than 50%). a mechanism for feeding systems. sources (25% or less). data sources (25-50%). back verified data to 2.6.1 Data exchange with administrative systems (for 2.6.1 Data exchanged 2.6.1 Data exchange with administrative systems allows example, informing the civil with administrative administrative systems for automatic and frequent registry when a beneficiary systems is not used to allows for some updates of (sometimes in real-time) was reported as deceased)? update applicant data. information, however, these updates of information are infrequent or not timely. through interoperability. * For countries without a 2.6.2 No mechanism social registry, this question is in place for 2.6.2 There is a mechanism 2.6.2 There is a mechanism in can be adapted to inquire feeding back data to in place for feeding back place for feeding back data to about key SP programs and administrative systems. data to administrative administrative systems that is the information systems used systems but it is not fully automated. to support the assess stage of automated. the delivery chain. 2.7 What mechanisms are There is no Applicants and/or Applicants and/or programs Applicants and programs - Who is responsible for updating the data? in place for people and option for programs can update can update information are able to easily update - How is data updated? programs to regularly applicants information via through front-office information through multiple - What share of data has been updated directly update data? Can applicants or programs front-office channels. channels. The process is not front-office channels. The by people and what share by programs or field and programs update to update The process is not fully efficient. Some nudges process is fully efficient. There staff? information? How efficient information. well-established or are in place for applicants to are well-established protocols is the process? Are there any efficient. There are no keep their data updated, but for updating information, with - What nudges are in place to incentivize nudges in place for applicants nudges in place for they are not implemented clear guidelines and incentives people in keeping data up to date? to keep their data updated? applicants to keep systematically. to keep data updated. - Is there a regulatory framework in place with What share of records has their data updated. The guidelines regarding data updates? been updated in the past process relies entirely year? on the applicants’ will [Part 3.A] to actively update their information. 158 ASSESSMENT TOOL ASSESSMENT TOOL NO. Question Absent (0) Nascent (1) Emerging (2) Advanced (3) Exploratory questions 2.8 To what extent is self- There is no Data verification is Data verification is Robust data verification - How is the accuracy and reliability of the reported data in the social formal process performed through conducted through a processes are in place, data assured, especially when new beneficiary registry verified?* for data basic cross-checking combination of cross- including continuous analysis information is collected? [Part 3.A] verification in or applicant self- checking and third-party of data over time, independent - How frequently (or under what circumstances) place. certification. verification, such as home verification through audits, does the system initiate data verification * For countries without a visits or spot checks. and the use of administrative processes? social registry, this question data sources. - What external sources are used for data can be adapted to inquire verification? about key SP programs and the information systems used - Is there a feedback loop between data to support the assess stage of verification and data collection, where the delivery chain. discrepancies or challenges observed during verification lead to improvements in the data collection processes? 2.9 Is there an established There is no There is a process There is an established There is a standardized and - For countries with a social registry serving two process for assessing needs formal process for assessing needs process for assessing fully automated process or more programs, is the process of assessment and conditions?* What is for assessing and conditions, but needs and conditions, but for assessing needs and of needs and conditions shared across user the method used to assess the needs and it is inefficient and it is not fully automated. A conditions. All applicants are programs or are there variations? the needs and conditions? conditions of infrequent. A large large share of applicants is assessed against eligibility - To what extent is the process documented How efficient is the process? applicants. share of applicants is assessed against eligibility criteria. The assessment and communicated to stakeholders, including Are all applicants assessed not assessed against criteria. The assessment of needs and conditions applicants? against eligibility criteria? eligibility criteria. of needs and conditions is is updated frequently and - Are all applicants subjected to a Are needs and conditions The assessment of updated periodically. is accessed and used by comprehensive needs and conditions reassessed? needs and conditions programs to make exit assessment against the established eligibility [Part 3.A] is seldom or never decisions. criteria, or are there specific cases or updated. circumstances where this assessment might * This question can be not be applied? adapted to the country context to inquire about the assessment of needs and conditions pertaining key existing SP programs. 2.10 To what extent do programs Programs do Programs consider Programs consistently Programs fully and - How is data from the social registry utilize data from the not use data data from the social use data from the comprehensively use data incorporated into the process of making social registry to inform from the social registry to inform social registry to inform from the social registry to enrollment decisions for social protection enrollment decisions? * registry to inform enrollment decisions, enrollment decisions. inform enrollment decisions. programs? How is data transferred to [Part 3.B] enrollment but the ultimate Only in some exceptional Exceptional cases are dealt programs? decisions. decision is based cases, enrollment decisions with in coordination with the - In cases where programs do not (fully) utilize * For countries without a on other sources are based on external social registry. data from the social registry for enrollment social registry, this question of information, not information. decisions, what external sources are being used can be adapted to inquire allowing to replicate and why? about key SP programs and the decision. - Are there specific mechanisms for the information systems used communication and coordination between to support the assess stage of programs and the social registry to address the delivery chain. exceptional cases? Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 159 ASSESSMENT TOOL NO. Question Absent (0) Nascent (1) Emerging (2) Advanced (3) Exploratory questions 2.11 Are applicants notified Applicants are Only enrolled All applicants are notified All applicants are notified - How and when are applicants notified about about the status of their not notified or do beneficiaries are about the status of their about the status of their the status of their application? application?* not have access notified about application, regardless of the application through front- [Part 3.B] to information on the status of their result. office channels, regardless of the status of their application. Non- the result. Applicants have * This question can be application. eligible and non- access to information on the adapted to the country enrolled applicants reasons behind the decision. context to inquire about key do not have access existing SP programs. to information on the status of their applications. 2.12 For cash transfer programs, Payroll Basic digital systems The BOMS utilizes moderate Payroll generation is highly - Does payroll generation involve a previous to what extent does the generation relies are employed for levels of technology for automated and advanced step of compliance verification? In that case, BOMS (or program MIS) primarily on certain aspects of payroll generation involving technologically within the how is it carried out? leverage technology in manual methods, payroll generation a reasonable degree of BOMS. Payroll transfer to - What information is contained in the payroll? the process of generating with minimal within the BOMS. automation. While the payments platforms occurs What information is transferred to PSPs? the payrolls?* Are payroll use of digital Payroll instructions process is technologically in real-time, ensuring prompt - How is the payroll transferred to the PSPs? instructions transferred systems. Payroll are transferred to the enhanced, the transfer and accurate disbursements. How often? seamlessly for distribution instructions are PSP through limited of payroll to payments of benefits? Is the BOMS transferred to electronic means platforms occurs in - How are funds transferred to the PSPs for interoperable with available the PSP in a non- (for example, Excel scheduled and frequent benefit distribution? payments platforms for systematic way. spreadsheets, Stata, intervals, improving - How long does it take from the time the payment instructions? emails, and so forth) in efficiency compared to payment instruction is given to the PSP and the [Part 3.C] batches. manual methods. beneficiary receives the transfer? - What are the existing payment modalities? * This question can be adapted to the country context to inquire about key existing SP programs. 2.13 Is there a mechanism There is no A basic mechanism is A functional monitoring A real-time monitoring - For cash transfer programs, describe in place to monitor the mechanism in in place to monitor the mechanism is in place that mechanism is in place that and assess the maturity of the payment delivery of benefits? If YES, place to monitor delivery of benefits. allows for some benefit allows for full traceability reconciliation procedures can it ensure the traceability the delivery Beneficiary registries delivery traceability. of benefit delivery. The - For other in-kind or service-based programs, of benefits in a timely, certain of benefits. are generated ad Beneficiary registries are reconciliation process describe and assess the mechanism for and automated manner? Is Beneficiary hoc through manual periodically generated, and between the program and monitoring the delivery of benefits and the monitoring mechanism registries are reconciliation the reconciliation process payment agency is frictionless. services. systematically used to keep non-existent or processes and are is partially automated. Beneficiary registries are - If the program has a BOMS, does it have the beneficiary registry not consistently rarely updated. Duplicates and/or phantom periodically kept up to date a module dedicated to monitoring benefit up to date? Is the benefit generated based Duplicates and/or beneficiaries are not by the program and audited delivery and/or reconciliation of payments? reconciliation process well on accurate phantom beneficiaries pervasive. regularly. defined and instrumented? benefit delivery are a common issue. - Are there spot-checks to verify that benefits [Part 3.C] data. Benefit are delivered consistently to the right reconciliation individuals and households? How often are * This question can be processes are they implemented? adapted to the country non-existent or context to inquire about key very primitive. existing SP programs. 160 ASSESSMENT TOOL ASSESSMENT TOOL NO. Question Absent (0) Nascent (1) Emerging (2) Advanced (3) Exploratory questions 2.14 Is there a GRM for people There is no Some initial steps have Efforts are underway to A comprehensive GRM is - What avenues are available for grievance to request corrections, established GRM been taken to establish establish a comprehensive in place, offering various uptake related to DSPDS? make suggestions, and file for people to a GRM, but available GRM that offers diverse accessible channels for - How are individuals informed about the complaints and appeals on address issues channels are limited. channels for people to raise people to raise concerns. progress of their complaints, suggestions, or matters related to DSPDS related to DSPDS. Processes for concerns. The mechanism includes appeals within the grievance redress process? (for example, to appeal monitoring the status Processes for monitoring well-established methods - How quickly does the GRM respond to when they feel they have of grievance resolution the status of grievance for individuals to monitor the inquiries, corrections, complaints, or appeals? been unfairly excluded are not developed resolution are available but progress of their grievance from the social registry or and require significant not easily accessible. resolutions in real time. - How is the GRM used to improve the programs, to claim undue effort from people operation of SP information systems? transfer amounts, to make given that information corrections or update is scattered. biometric data, and so forth)? [Part 3.D] * This question can be adapted to the country context to inquire about key existing DSPDS such as unique identification systems, social registries, or payments platforms. 2.15 To what extent is the No emergency Some emergency A well-defined emergency A comprehensive emergency - Is there an emergency response plan or social registry prepared plan or protocols plans or protocols are plan and protocols have plan and protocols have been shock-response protocols? operationally for scale-up?* are in place. in place, but they are been tested and updated successfully tested and are [Annex 1] The system not fully developed regularly. The system is fully operational. The system does not have or tested. The system operationally capable of is completely operationally * For countries without a the operational has limited to no supporting rapid expansion capable of supporting the social registry, this question capability to operational capability (horizontal or vertical) of rapid expansion (horizontal can be adapted to inquire support rapid to support rapid SP programs in response or vertical) of SP programs in about key SP programs and expansion expansion (horizontal to shocks, but with some response to shocks, with clear the information systems used (horizontal or or vertical) of SP limitations. procedures and resources in to support the assess stage of vertical) of SP programs in response place. the delivery chain. programs in to shocks. response to shocks. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 161 ASSESSMENT TOOL (iii) Data NO. Question Absent (0) Nascent (1) Emerging (2) Advanced (3) Exploratory questions 3.1 To what extent is the Coverage is low Coverage is moderate Coverage is high (50-80%) The is almost full coverage - Coverage indicators disaggregated by intended population (less than 20%), (20-50%) and/or there are and there are moderate (80-100%) with limited to population group (sex, age group, and captured in the social and/or there are large differences in coverage differences in coverage no significant differences in so forth), income levels, and geographic registry?* Is there unequal large differences across population groups, across population groups, coverage across population location. coverage across population in coverage across income levels, and/or income levels, and/or groups, income levels, and/ - Definition of the intended population. groups or geographic population groups, locations. locations. or locations. locations? (Breadth) income levels, and/or [Part 2.A] locations. Note: Responding to this question will require cross-checks and calculations using * For countries without a available surveys, census data, and other social registry, this question sources. can be adapted to inquire about key SP programs and the information systems used to support the assess stage of the delivery chain. 3.2 To what extent does the The social registry The social registry captures The social registry The social registry uses - Are the data fields aligned with the social registry capture captures only a few some characteristics of captures comprehensive modular data sets. Multiple specific criteria used to determine eligibility the necessary data sets characteristics of applicants along the multiple information for multiple data sources are used to for various social protection programs? to assess the needs and applicants along data sets. A moderate share data sets. A low share of capture comprehensive What share of collected data is not used by conditions and determine monolithic data of records is incomplete. records is incomplete. information for the modular programs or SP information systems? eligibility for SP programs?* sets. A large share of The social registry lacks key The fields captured by the data sets and beyond (for - Share of observations with missing or null Are data complete (that is, no records is incomplete. information necessary for a social registry align with example, disaster risks). values. What variables are more prone to missing or null values)? Is the Data cannot be used comprehensive assessment the data model to assess Only a few records are incomplete data? length of the questionnaire for comprehensive of needs and conditions. needs and conditions. The incomplete. The fields - How long is the questionnaire/form (for reasonable? (Depth) assessments The questionnaire/ administration/response captured by the social example, number of questions, application [Part 2.A] of needs and application form provides time of the questionnaire/ registry align with the data time, and so forth) conditions. There are minimal information that application form is lengthy model to assess needs * For countries without a unnecessary data is not complemented by and inefficient since some and conditions. The length - Was the questionnaire piloted to ensure a social registry, this question fields that few or no other sources. Its average information could be of the questionnaire/ user-friendly and understandable design? can be adapted to inquire programs use. response time is lengthy and pulled from administrative application form is about key SP programs and inefficient. Many variables sources or there are some reasonable, with a low the information systems used collected are not used by variables with little use. average response time. to support the assess stage of programs. the delivery chain. 162 ASSESSMENT TOOL ASSESSMENT TOOL NO. Question Absent (0) Nascent (1) Emerging (2) Advanced (3) Exploratory questions 3.3 To what extent is data Data are not Data accuracy is being Data accuracy is good Data accuracy is high and - How are data inaccuracies addressed? in the social registry accurate. There is recognized as an issue, and improving. The the share of unusable data - What are the main concerns of data users accurate?* Are data reliability a significant gap and initial steps have share of unusable data due to quality problems concerning the accuracy of the data? What measures in place? How is between the data been taken to address it. due to quality problems or biases is minimal. Data measures have been implemented to data quality perceived? Are in the social registry Some data are unusable or biases is low. Data reliability measures are address those concerns? data validation procedures and “ground truth” due to quality problems reliability measures well-established and have - What data validations protocols are in followed in the collection of (for example, based or biases. Data reliability are being developed been shown to be effective place? data for the social registry on surveys, data measures are just beginning and implemented, but in improving data quality to ensure data validity? verification attempts, to be implemented, and their effectiveness in over time. The perceived - Are fraud prevention measures in place? (Accuracy) and so forth). A there is limited evidence improving data quality is quality of data is high. Describe them. Are these measures [Part 2.A] large share of data of their effectiveness in yet to be determined. The Data validation procedures enforced? is unusable due to improving data quality. The perceived quality of data are fully automated, and * For countries without a quality problems perceived quality of data is improving, but there are comprehensive checks social registry, this question and biases. The is low, but it is showing still some concerns about for validity are in place, can be adapted to inquire perceived quality signs of improvement. Data accuracy. Data validation including checks for about key SP programs and of data is very low. validation procedures are in procedures are partially completeness, correctness, the information systems used There are no data place but are not automated automated, and some consistency, and relevance. to support the assess stage of validation procedures and rely on manual checks, basic checks for validity The effectiveness of the the delivery chain. in place, and data are which are prone to errors are in place, but they are validation procedures is collected without any and inconsistencies. not comprehensive and regularly monitored and checks for validity. may miss certain errors or evaluated, and adjustments inconsistencies. are made as needed. 3.4 To what extent is data Data are significantly Data are updated Data are updated regularly Data are consistently up- - Describe data update schedules and up-to-date and available outdated and cannot sporadically and is not and is available within to-date and available within limitations. in the social registry within be relied upon for always available within an acceptable timeline an acceptable timeline or an acceptable time frame, decision-making an acceptable timeline or or duration. There is a duration. There is a well- timeline, and duration?* purposes. duration. There is little to general schedule for data established schedule for (Timeliness) no schedule or plan for data updates, and data may data updates, and data [Part 2.A] updates, and data may be be missing for shorter are rarely missing for any missing for certain periods. periods. period. * For countries without a social registry, this question can be adapted to inquire about key SP programs and the information systems used to support the assess stage of the delivery chain. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 163 ASSESSMENT TOOL NO. Question Absent (0) Nascent (1) Emerging (2) Advanced (3) Exploratory questions 3.5 Is there a standardized data No data A data management manual A standardized data The standardized data - How frequently is the framework management framework management manual and data dictionary exist management framework management framework reviewed and updated to align with best (that is, data management or data dictionary but are not standardized, exists, including a data is fully operational and practices and emerging standards? manual, data dictionary) exists. harmonized, or aligned with management manual, effective, ensuring data in place to ensure data inter-agency data standards. data dictionary, and active integrity, confidentiality, and integrity, confidentiality, data dictionary. There interoperability across social and interoperability within are inter-agency data protection information DSPDS?* standards in place. systems. Technical [Part 2.B] standards and protocols used in implementing the * This question can be interoperability framework adapted to the country are regularly reviewed context to inquire about and updated to ensure key existing DSPDS such as continued effectiveness. unique identification systems, social registries, payments platforms, or interoperability of systems. 3.6 To what extent are data No data processing Basic data processing Comprehensive data Advanced data processing - Are there clear guidelines for handling processes, including protocols are in protocols are in place. processing protocols are protocols. High degree data discrepancies, inconsistencies, and harmonization, cleaning, place. Automation of data in place. Automation of of automation of data data quality improvement? deduplication, integration, processing protocols is data processing protocols processing protocols. - Are there feedback loops that allow and exploitation, effectively limited. is moderate. stakeholders to provide insights into data carried out for DSPDS?* quality and suggest refinements to data [Part 2.B] processing protocols? * This question can be adapted to the country context to inquire about key existing DSPDS such as unique identification systems, social registries, payments platforms, or interoperability of systems. 164 ASSESSMENT TOOL ASSESSMENT TOOL (iv) Technology NO. Question Absent (0) Nascent (1) Emerging (2) Advanced (3) Exploratory questions 4.1 To what extent are DSPDS DSPDS are only available DSPDS are accessible DSPDS are accessible to DSPDS are accessible to - To what extent do DSPDS ensure designed using human- to system administrators. only to some users applicants, programs, applicants, programs, accessibility for a diverse range centered principles?* Is DSPDS There is no consideration beyond system and other users. Some and other users. DSPDS of users, including people with accessible to people, programs, for designing it using administrators. There is elements of the system are designed using disabilities, different levels of digital and other users beyond system human-centered principles. limited consideration for were designed using comprehensive human- literacy, and varying language administrators? In countries DSPDS are not available designing it using human- human-centered principles, centered principles across preferences? with connectivity issues, are offline. Users report centered principles (for but there are some gaps all functions (for example, - Do DSPDS account for the systems available offline? extremely low levels of example, only available in (for example, only available available in various different needs and constraints Are users satisfied with the satisfaction with DSPDS one language, difficult to in one language, some languages, ease of use, and of vulnerable and marginalized system’s design and usability? design and usability. User use, and so forth). DSPDS functions are difficult to so forth). DSPDS are fully groups of the population? Are grievances related to feedback is not responded are not fully available use, and so forth). DSPDS available offline with rare - For systems available offline, accessibility issues addressed? to or acted upon, and user offline. Users report low are available offline with glitches. Users report high how does the system handle data [Part 4.A] errors or mistakes are levels of satisfaction some glitches. Users levels of satisfaction with synchronization and updates once frequent and severe. with the system’s design report medium to high the system’s design and connectivity is restored? * This question can be adapted and usability. Grievances levels of satisfaction with usability. There are only a - Have user experience to the country context to inquire related to accessibility the system’s design and few grievances related to assessments or surveys been about key existing DSPDS such issues are relatively usability. Grievances related accessibility issues, and all conducted to gather feedback as unique identification systems, high. User feedback is to accessibility issues are user feedback is responded on DSPDS interface, navigation, social registries, payments inconsistently responded mostly addressed, but to and acted upon in a and overall usability? How is this platforms, or interoperability of to and acted upon, and user feedback is acted timely manner. User errors feedback incorporated? systems. user errors or mistakes upon unsystematically. or mistakes are extremely are infrequent but may User errors or mistakes are infrequent and not severe. still be severe. infrequent and not severe. 4.2 To what extent do DSPDS DSPDS are frequently DSPDS experience DSPDS are available to users DSPDS are available to - How frequently do DSPDS exhibit system efficiency?* Are unavailable to users due occasional downtime for the majority of the time, users at all times, with no experience downtime or technical the measures in place able to to frequent and extended and wait times for the with only occasional and significant downtime. Users disruptions? address system downtime and periods of downtime. system to respond to brief periods of downtime. experience minimal wait - Are there established protocols technical issues efficiently and Users experience long user requests are longer Users experience times for the system to and procedures to promptly effectively? wait times for DSPDS to than optimal. Technical reasonable wait times for respond to their requests, identify, diagnose, and address [Part 4] respond to their requests, support responds to user the system to respond to and technical support is system downtime? and technical support is issues in a reasonable their requests, and technical highly responsive to user - Are there automated monitoring * This question can be adapted slow to respond to user amount of time, and a support is responsive to issues. All technical issues are tools in place to detect to the country context to inquire issues. A significant number majority of technical user issues. Most technical resolved in a timely manner, performance anomalies, system about key existing DSPDS such of technical issues remain issues are resolved in a issues are resolved in a and the system is able to errors, or potential vulnerabilities in as unique identification systems, unresolved, and the system timely manner. DSPDS timely manner, and the process a high volume of user real-time? social registries, payments is unable to process a are able to process a system is able to process a transactions. - Is there a robust data backup platforms, or interoperability of substantial number of user moderate number of user significant number of user and recovery strategy in place systems. transactions. transactions, but there is transactions. to safeguard against data loss in room for improvement. the event of system failures or unexpected incidents? Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 165 ASSESSMENT TOOL NO. Question Absent (0) Nascent (1) Emerging (2) Advanced (3) Exploratory questions 4.3 To what extent do DSPDS DSPDS do not provide DSPDS have basic data DSPDS have strong data DSPDS have state-of-the-art - What specific measures and ensure data security and any data security security measures in security measures in place data security measures in protocols are implemented to privacy?* What measures are measures. There are place, but they are not and they are enforced. place and they are regularly ensure the security and protection in place? How frequently do no access controls, no consistently enforced. Access controls are well- updated and tested. Access of sensitive data? security incidents occur? data encryption, and no Access controls are defined and user roles are controls are granular and - Does an incident’s response [Part 4.A] anonymization of data. limited, only some clearly defined, and a high strictly enforced, all data are plan exist? If yes, does it consider Security incidents are data are encrypted percentage of data are encrypted and anonymized, informing/involving people? * This question can be adapted frequent and user data are or anonymized, and encrypted and anonymized. and there have been no - How often do security incidents to the country context to inquire easily accessible. security incidents occur Security incidents are rare. security incidents in a or breaches occur? How are about key existing DSPDS such occasionally. significant period of time. the impacts of these incidents as unique identification systems, mitigated? social registries, payments platforms, or interoperability of systems. 4.4 To what extent is it The system cannot handle The system is able to The system is able to The system is able to handle - Is the system incorporating technologically possible to increasing user demands handle some increasing handle most increasing user all increasing user demands innovations to improve scale DSPDS?* Can it handle or data volumes, resulting user demands or data demands or data volumes or data volumes with minimal performance or functionality? How increasing user demands? in poor performance and volumes, but there with minimal delays in delays in performance and often? Is the number of users slow response times. The are noticeable delays performance and response response times. The number - Has the system been tested who can access the system number of users that in performance and times. The number of users of users that can access for peak loads, and can it ensure simultaneously adequate? can access the system response times. The that can access the system the system simultaneously a smooth experience for users Does the system have a simultaneously is very low, number of users that simultaneously is moderate, is high, and the system during periods of high activity? modular structure? and the system is unable can access the system and the system has has advanced capabilities [Part 4.A and 4.B] to serve users in different simultaneously is limited, capabilities to serve users to serve users in different geographic locations. but there are some in different geographic geographic locations. The * This question can be adapted The system has a limited capabilities to serve users locations. The system has system has a fully-fledged to the country context to inquire number of modules or in different geographic a number of modules or modular structure, making it about key existing DSPDS such components, which are locations. The system has components, which are easy to replace or upgrade as unique identification systems, highly interdependent, a moderate number of somewhat interdependent, modules as needed. social registries, payments making it difficult to modules or components, making it somewhat easy platforms, or interoperability of replace or upgrade them. which are moderately to replace or upgrade them. systems. interdependent, making it somewhat challenging to replace or upgrade them. 166 ASSESSMENT TOOL ASSESSMENT TOOL NO. Question Absent (0) Nascent (1) Emerging (2) Advanced (3) Exploratory questions 4.5 From a technology The system is not able to The system is able to The system is able to The system is able to - Describe the specific data perspective, to what extent exchange data with other exchange data with other exchange data with other exchange data with other exchange protocols to is the social registry able to systems or platforms. systems or platforms systems or platforms systems or platforms on a communicate with external exchange and share data with on an irregular basis. on a regular basis. Data regular and automated basis. systems or platforms? other systems or platforms? Data exchange activities exchange activities Data exchange activities - How do these protocols ensure How well does it adhere to between the system and between the system and between the system and secure and accurate data sharing? service-oriented IT architecture other organizations or other organizations or other organizations or - Does the system use open standards (for example, use platforms are infrequent, platforms are frequent, platforms are frequent, standards and protocols for data of web services, APIs, and and the volume of data and the volume of data and the volume of data exchange? other standard protocols to exchanged is low. Time exchanged is moderate. exchanged is high. Time to - To what extent does the system’s enable different systems to to exchange information Time to exchange exchange information is data sharing capabilities extend communicate and share data is slow and the system information is reasonable fast and the system fully beyond the social protection seamlessly)? does not adhere to and the system partially adheres to service-oriented sector to collaborate with systems [Part 4.D] service-oriented IT adheres to service-oriented IT architecture standards. in other sectors, such as health, architecture standards. IT architecture standards. education, or finance? * For countries without a social registry, this question can be adapted to inquire about key SP programs and the information systems used to support the assess stage of the delivery chain. 4.6 Is there sufficient physical There is insufficient There is some The infrastructure The infrastructure supporting - Describe the disaster recovery infrastructure for DSPDS?* infrastructure to support infrastructure in place to supporting the operation the operation and system in place for DSPDS? How Is there a disaster recovery the operation and support the operation and management of the management of the systems does it ensure the continuity of system in place? management of the and management of the systems is functioning and is fully functional, reliable, operations in case of unexpected [Part 4.E] systems. There is no systems, but it is not yet reliable. There are areas and well-equipped to handle events or system failures? disaster recovery system fully functional and may for improvement in terms the demands of the system, - Describe the regular maintenance * This question can be adapted in place. have limited capacity of scalability, security, or including disaster recovery and upgrades performed on to the country context to inquire or reliability. A disaster disaster recovery. measures, access control, and physical infrastructure. about key existing DSPDS such recovery system has data backups. as unique identification systems, been planned but is not social registries, payments fully operational. platforms, or interoperability of systems. 4.7 If data are available, to what DSPDS have high operating DSPDS have higher DSPDS provide a good DSPDS are highly cost- - Cost review. extent do DSPDS provide a and maintenance costs, operating and balance between cost effective, with low operating - Benchmarking. good balance between cost and the cost per user is maintenance costs and performance, with and maintenance costs. The and performance compared significantly higher than compared to previous or moderate operating and system provides significant to previous or alternative the previous or alternative alternative approaches maintenance costs. There cost savings or efficiencies approaches (or available approaches (or available (or available benchmarks), are significant cost savings compared to previous or benchmarks)? benchmarks). There are but there are some cost or efficiencies compared alternative approaches (or no significant cost savings savings or efficiencies. to previous or alternative available benchmarks), and or efficiencies compared approaches (or available there are ongoing efforts to to previous or alternative benchmarks). improve cost efficiency. approaches. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 167 ASSESSMENT TOOL (v) Performance162 NO. Question Absent (0) Nascent (1) Emerging (2) Advanced (3) Exploratory questions 5.1 Do DSPDS have a performance There is no There is a performance There is a performance There is a comprehensive - Describe the performance monitoring system or strategy performance monitoring system or monitoring system or performance monitoring monitoring system or strategy. in place?* Is it comprehensive? monitoring system or strategy in place, but it is not strategy in place, and it is system or strategy in - Has system monitoring To what extent does it foster the strategy in place for comprehensive. Monitoring somewhat comprehensive. place. Monitoring results improved fraud and error improvement of the systems? DSPDS. results are not considered for Monitoring results are are systematically detection? How? Are anonymized data available to the systems improvement. considered for the systems considered for the system’s external evaluators? Anonymized data are not improvement, but not improvement. Anonymized [Part 6.B] readily available to external systematically. Anonymized data are available to evaluators. data are not readily available external evaluators. * This question can be adapted to external evaluators. to the country context to inquire about key existing DSPDS such as unique identification systems, social registries, payments platforms, or interoperability of systems. 5.2 To what extent have technology There is no evidence There are some limited There are some notable The social protection system - Examples of how technology and data enhanced the that data analytics capabilities for data analytics capabilities for data analytics has robust capabilities and data are used to improve the performance of social protection are used to inform within the social protection within the social protection for data analytics, which performance of social protection policy by informing strategic strategic decisions or system, but they are not system, and they are utilized are fully utilized to inform systems. decisions and supporting support monitoring utilized to their full potential to some extent to inform strategic decisions and monitoring and evaluation and evaluation to inform strategic decisions strategic decisions and support monitoring and objectives through data objectives within or support monitoring and support monitoring and evaluation objectives. analytics? the social protection evaluation objectives. evaluation objectives. [Part 6] system. 162. The performance of DSPDS might be impacted by enabling factors such as financing, country context (for example, conflict, institutional fragility, and so forth), trust in institutions, level of engagement and leadership, among others, not assessed by this tool. 168 ASSESSMENT TOOL Bibliography Aiken, E.L., S. Bellue, D. Karlan, C.R. Udry, and J.E. Blumenstock. 2021. “Machine Learning and Mobile Phone Data Can Improve the Targeting of Humanitarian Assistance.” NBER Working Paper No. 29070. National Bureau of Economic Research. doi:10.3386/w29070. Aiken, E.L., and T. Ohlenburg. 2023. Novel Digital Data Sources for Social Protection: Opportunities and Challenges. Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH. Akbar, N. 2023. Digital Transformation in Social Protection: Pakistan’s Journey and Innovations toward Adaptive Social Protection. Social Protection & Jobs Seminar Series. World Bank, Washington, DC. Alatas, V., A. Banerjee, R. Hanna, B. A. Olken, R. Purnamasari, and M. Wai-Poi. 2016. “Self-Targeting: Evidence from a Field Experiment in Indonesia.” Journal of Political Economy 124(2): 371–427. https://doi.org/10.1086/685299. Argyris, C. 1977. “Double Loop Learning in Organisations.” Harvard Business Review 55: 115–125. Arnstein, Sherry. 1969. “A Ladder of Citizen Participation.” Journal of the American Planning Association 35(4): 216–224. For more, see, for example, Organizing Engagement, “Ladder of Citizen Participation”. https:// organizingengagement.org/models/ladder-of-citizen-participation/. Barca, V. and R. Beazley. 2019. Building on Government Systems for Shock Preparedness and Response: The Role of Social Assistance Data and Information Systems. Canberra: Commonwealth of Australia, Department of Foreign Affairs and Trade. https://www.unisdr.org/preventionweb/files/63843_buildinggovernmentsystemsforshockpr.pdf. Barca, V., and M. Hebbar. 2020. On-Demand and Up-to-Date? Dynamic Inclusion and Data Updating for Social Assistance. Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH. https://socialprotection. org/sites/default/files/publications_files/GIZ_DataUpdatingForSocialAssistance_3.pdf. Barca, V., M. Hebbar, A. Grinspun, and A. Mittal. 2023. “Farmer Registries and Social Protection Information Systems: Harnessing Interoperability to Improve Outcomes for Rural Populations.” FAO and GIZ, Rome and Bonn. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 169 BIBLIOGRAPHY Barca, V., M. Hebbar, C. Knox-Vydmanov, and I. Brzezinska. 2023. “We Have the Data, Let’s Use it Better: Pushing the Boundaries of Social Protection Administrative Data Analysis and Use.” Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH. https://socialprotection.org/sites/default/files/publications_files/GIZ-%20Use%20 Admin%20Data%20Social%20Protection.pdf. Bedi, T., and A. Coudouel. 2007. More Than a Pretty Picture: Using Poverty Maps to Design Better Policies and Interventions. World Bank Publications. https://elibrary.worldbank.org/doi/abs/10.1596/978-0-8213-6931-9. Bengtsson, L., J. Gaudart, X. Lu, S. Moore, E. Wetter, K. Sallah, S. Rebaudet, and R. Piarroux. 2015. “Using Mobile Phone Data to Predict the Spatial Spread of Cholera.” Scientific Reports 5: 8923. 10.1038/srep08923. Beyazit, I. 2020. “Vital Statistics in Turkey.” Slide show. Demographic Statistics Department, Turkish Statistical Institute, Ankara. https://www.unescap.org/sites/default/files/Session5_Vital_Statistics_in_Turkey-Workshop_ SDG_PHC_CRVS.pdf. Briceño Villalobos, G.D. 2023. “Colombia: Social Household Registry.” In Talking Interoperability: In Focus Columbia. Digital Covergence Initiative. https://spdci.org/wp-content/uploads/2023/07/Talking-Interoperability-12- Colombia.pdf. Bowen, T, C. del Ninno, C. Andrews, S. Coll-Black, U. Gentilini, K. Johnson, Y. Kawasoe, A. Kryeziu, B. Maher, and A. Williams. 2020. Adaptive Social Protection: Building Resilience to Shocks. International Development in Focus. Washington, DC: World Bank. © World Bank. https://openknowledge.worldbank.org/handle/10986/33785 License: CC BY 3.0 IGO. Cavoukian, A. 2011. “Privacy by Design. The 7 Foundational Principles.” Information and Privacy Commissioner of Ontario. https://www.ipc.on.ca/wp-content/uploads/2018/01/pbd.pdf. Chi, G., H. Fang, S. Chatterjee, and J.E. Blumenstock. 2021. “Micro-Estimates of Wealth for All Low- and Middle-Income Countries.” arXiv (curated research-sharing platform), https://arxiv.org/abs/2104.07761. Consejo Nacional de Evaluación de la Política de Desarrollo Social (CONEVAL). (2022). “Medición multidimensional de la pobreza en México.” CONEVAL. https://www.coneval.org.mx/InformesPublicaciones/FolletosInstitucionales/ Documents/Medicion-multidimensional-de-la-pobreza-en-Mexico.pdf. Cronk, R. Jason. 2021. Strategic Privacy by Design. International Association of Privacy Professionals. https://iapp. org/resources/article/oipc-privacy-by-design-resources/. Daly, C., and T. G. Karippacheril. Forthcoming. Pathways to Identification for Social Protection & Beyond: A Human- Centered Design Approach for West Africa (“HCD Toolkit”). Washington, DC: World Bank. Delgation Generale a la Solidarite Sociale et a la Lutte contre l’Exclusion (Taazour). 2020. Manuel opérationnel du Registre Social. Republique Islamique de Mauritanie. http://www.rs.gov.mr/documents/ De Miranda, C., C. Heisecke, and M. Royg. 2021. Social Protection Goes Digital: Lessons From an Innovative, WhatsApp- Driven Outreach Campaign in Paraguay. Guest article, February 24. Next Billion. https://nextbillion.net/social- protection-digital-innovative-whatsapp-paraguay/. Demiroz, A., and E. Dansuk. 2022. “Social Assistance System of Turkey: Integrated Social Assistance Information System (ISAIS).” In Talking Interoperability: In Focus Turkey. Digital Covergence Initiative. https://spdci.org/wp- content/uploads/2022/11/Talking-Interoperability-Turkey.pdf. Dhaliwal, I., and R. Hanna. 2017. “The Devil Is in the Details: The Successes and Limitations of Bureaucratic Reform in India.” Journal of Development Economics 124: 1–21. https://doi.org/10.1016/j.jdeveco.2016.08.008. Dunleavy, P., H. Margetts, S. Bastow, and J. Tinkler. 2008. Digital Era Governance: IT Corporations, the State and e-Government. Revised Edition. Oxford: Oxford University Press. 170 “WHAT MATTERS” GUIDANCE NOTE Dunleavy, P., and H. Margetts. 2015 “Design Principles for Essentially Digital Governance. Paper to the 111th Annual Meeting of the American Political Science Association, San Francisco, September 3–6, 2015. http://eprints.lse. ac.uk/64125/1/Essentially%20Digital%20Governance.pdf. Eisen, N., D. Kaufmann, N. Heller, J. Whitt, M. Picón, V. Bassetti, and J. Hudaket. 2020. “The TAP-Plus Approach to Anti-Corruption in the Natural Resource Value Chain.” Leveraging Transparency to Reduce Corruption Project. Brookings Institution, Washington, DC. www.brookings.edu/wp-content/uploads/2020/06/LTRC_Corruption_ vfinal_x2screenreader4.pdf. European Union. General Data Protection Regulation (GDPR)—Official Legal Text. (2022, September 27). https:// gdpr-info.eu/. Evans, D. S., R. Schmalensee, and A. Hagiu. 2008. Invisible Engines: How Software Platforms Drive Innovation and Transform Industries. MIT Press. Fan, W., F. Geerts, and J. Wijsen. 2012. “Determining the Currency of Data.” ACM Transactions on Database Systems 37(4): 1–46. https://doi.org/10.1145/2389241.2389244. Fatehkia, M., B. Coles, F. Ofli, and I. Weber. 2020. “The Relative Value of Facebook Advertising Data for Poverty Mapping.” Proceedings of the International AAAI Conference on Web and Social Media 14(1): 934–38. https://ojs. aaai.org/index.php/ICWSM/article/view/7361. France. 1789. “Declaration of the Rights of Man and of the Citizen.” elysee.fr. https://www.elysee.fr/en/french- presidency/the-declaration-of-the-rights-of-man-and-of-the-citizen. Gelb, A., A. Mukherjee, and B. Webster. 2022. “Can Digital G2P Transfers Drive Financial Inclusion and Digital Payments? Evidence from India.” Center for Global Development, Washington, DC. https://www.cgdev.org/sites/ default/files/can-digital-g2p-transfers-drive-financial-inclusion-and-digital-payments-evidence-india.pdf. Gelders, B. 2021. “Half-life Assessment of the National Household Database in Bangladesh.” Background paper. World Bank, Washington, DC. Gentilini, U., M. Almenfi, I. Orton, and P. Dale. 2021. “Social Protection and Jobs Responses to COVID-19: A Real-Time Review of Country Measures.” COVID-19 Living Paper, December 2020 and May 2021 versions. World Bank, Washington, DC. © World Bank. https://openknowledge.worldbank.org/handle/10986/33635. License: CC BY 3.0 IGO. George, T., and P. Leite. 2019. “Integrated Social Information Systems and Social Registries.” Presentation. World Bank, Washington, DC. https://thedocs.worldbank.org/en/doc/575621575490523237-0160022019/original/ SPJCC19SSND4S1GeorgeLeiteSocialRegistriesandIntInformationSystems.pdf. Georgieva, K. 2018. “Technology Works for Getting Poor People’s Problems Fixed—We Just Have to Get It Right.” Blog post, published June 27, 2018. World Bank, Washington, DC. https://blogs.worldbank.org/voices/technology- works-for-getting-poor-people-s-problems-fixed-we-just-have-to-get-it-right. Grosh, M., P. Leite, M. Wai-Poi, and E. Tesliuc. 2022. Revisiting Targeting in Social Assistance: A New Look at Old Dilemmas. Human Development Perspectives. Washington, DC: World Bank. © World Bank. https://openknowledge. worldbank.org/handle/10986/37228 License: CC BY 3.0 IGO. Guven, M., Z. Majoka, and G. Najam Jamy. 2024. “The Evolution of Benazir Income Support Programme’s Delivery Systems: Leveraging Digital Technology for Adaptive Social Protection in Pakistan.” World Bank, Washington, DC. https://documents1.worldbank.org/curated/en/099022924085074880/pdf/ P17986812db6c301f1afee12f2ecbee7a73.pdf. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 171 BIBLIOGRAPHY Heeks, R. 2001. “Understanding e-Governance for Development.” iGovernment Working Paper no. 11, February 18. Available at SSRN: https://ssrn.com/abstract=3540058 or http://dx.doi.org/10.2139/ssrn.3540058. Hong, T. 2023. “Why Digital Public Infrastructure Matters.” Bill & Melinda Gates Foundation, August 16, 2023. https:// www.gatesfoundation.org/ideas/articles/what-is-digital-public-infrastructure. Inter Agency Social Protection Assessments (ISPA). 2014. “Core Diagnostic Instrument (CODI).” © 2014 Inter Agency Social Protection Assessments Partnership. https://socialprotection.org/discover/publications/core-diagnostic- instrument-codi. Inter Agency Social Protection Assessments (ISPA). 2017. “Social Protection Payment Delivery Mechanisms.” © 2017 Inter Agency Social Protection Assessments Partnership. https://socialprotection.org/discover/publications/ social-protection-payment-delivery-mechanisms. Inter Agency Social Protection Assessments (ISPA). 2020. “Identification Systems for Social Protection.” © 2016 Inter Agency Social Protection Assessments Partnership. https://socialprotection.org/discover/publications/ identification-systems-social-protection. Jafino, B. A., B. K. Walsh, J. Rozenberg, and S. Hallegatte. 2020. “Revised Estimates of the Impact of Climate Change on Extreme Poverty by 2030.” Policy Research Working Paper 9417. World Bank, Washington, DC. https://doi. org/10.1596/1813-9450-9417. Jean, N., M. Burke, M. E. Xie, W. M. Davis, D. B. Lobell, and S. Ermon. 2016. “Combining Satellite Imagery and Machine Learning to Predict Poverty.” Science 353(6301): 790–94. https://doi.org/10.1126/science.aaf7894. Jeong, D., S. Aggarwal, J. Robinson, N. Kumar, A. Spearot, and D. Sungho. 2023. “Exhaustive or Exhausting? Evidence on Respondent Fatigue in Long Surveys.” Journal of Development Economics 161 (March 2023), 102992. https:// doi.org/10.1016/j.jdeveco.2022.102992. Johnson, K., and T. Walker (eds). 2022. Responsive by Design: Building Adaptive Social Protection Systems in South Asia. Washington, DC: World Bank. George,T., with K. Lindert, V. Anandan, J. Qamruddin, and J. Solomon. 2018.“The ‘First Mile’ of Delivering SPJ: Human-Centered Design.” Presentation. World Bank, Washington, DC. https://thedocs.worldbank.org/en/doc/657151528225821596- 0160022018/original/415PM30AprilTinaHCDCoreCourseSlidesTGKLSundayeveningSENTTOMANIZA.pdf. Kalja, A., A. Reitsakas, and N. Saard. 2005. “eGovernment in Estonia: Best Practices.” In T. Anderson, T. Daim, and D. Kocaoglu, D. Milosevic, and C. Weber, eds., Technology Management: A Unifying Discipline for Melting the Boundaries Technology Management, pp. 500–06. Portland, OR: PICMET. https://doi.org/10.1109/picmet.2005.1509730. Karippacheril, T. G., and P. Leite. 2019. “Integrated Social Information Systems and Social Registries.” Presentation. World Bank, Washington DC. https://thedocs.worldbank.org/en/doc/575621575490523237-0160022019/original/ SPJCC19SSND4S1GeorgeLeiteSocialRegistriesandIntInformationSystems.pdf. Kashyap, R., M. Fatehkia, R. A. Tamime, and I. Weber. 2020. “Monitoring Global Digital Gender Inequality Using the Online Populations of Facebook and Google.” Demographic Research 43: 779–816. https://www.jstor.org/ stable/26967824. Klapper, L., and D. Singer. 2017. “The Opportunities and Challenges of Digitizing Government-to-Person Payments.” The World Bank Research Observer 32(2): 211–26. https://doi.org/10.1093/wbro/lkx003. Koechlein, E., and T. Jaluka. 2022. “Beneficiary Experience of Digital Government-to-Person (G2P) Payments: Evidence from the Philippines, Colombia, and Bangladesh.” Financial Inclusion, Findings Brief. Innovations for Poverty Action (IPA). https://poverty-action.org/sites/default/files/publications/G2P-and-Financial-Inclusion- Updated.pdf. 172 “WHAT MATTERS” GUIDANCE NOTE Kolata, G. 2019. “Your Data Were ‘Anonymized’? These Scientists Can Still Identify You.” New York Times, 23 Jul 2019. https://www.nytimes.com/2019/07/23/health/data-privacy-protection.html. Kumagai, S. 2013. “Platforms for Grievance Management.” Presentation, Social Development Grievance Redress Mechanism Working Group Meeting. World Bank, Washington, DC. Kwame Senyo, P., K. Liu, and J. Effah. 2019. “Unpacking the Role of Political-Will in Digital Business Ecosystem Development for Socioeconomic Benefits.” Research paper for the Twenty-Seventh European Conference on Information Systems (ECIS2019), Stockholm-Uppsala, Sweden. https://eprints.soton.ac.uk/437820/1/SENYO_2019_ cright_ECISconf_Unpacking_the_role_of_political_will_in_digital_business_ecosystem_development_for_ socioeconomic_benefits.pdf. Lawson, C., M. Koudeka, A.L. Cárdenas Martínez, L.I. Alberro Encinas, and T.G. Karippacheril. 2023. “Novissi Togo: Harnessing Artificial Intelligence to Deliver Shock-Responsive Social Protection.” Social Protection & Jobs Discussion Paper 2306. World Bank, Washington, DC. Leite, P., T. George, C. Sun, T. Jones, and K. Lindert. 2017. “Social Registries for Social Assistance and Beyond: A Guidance Note and Assessment Tool.” Social Protection & Labor Discussion Paper No. 1704. World Bank, Washington, DC. © World Bank. https://openknowledge.worldbank.org/handle/10986/28284. License: CC BY 3.0 IGO. Lindert, K., T. George, and P. Leite. 2018. “Social Registries, Beneficiary Registries, and Integrated Social Information Systems: Social Safety Nets & Delivery Systems Core Course.” World Bank, Washington, DC. https://thedocs. worldbank.org/en/doc/633701528816274932-0160022018/original/SSNDay59amSocialRegistriesTina.pdf. Lindert, K., T.G. Karippacheril, I. Rodriguez Caillava, and K. Nishikawa Chavez. 2020. Sourcebook on the Foundations of Social Protection Delivery Systems (1st ed.). Washington, DC: World Bank. http://hdl.handle.net/10986/34044 License: CC BY 3.0 IGO. Margetts, H., and P. Dunleavy. 2013. “The Second Wave of Digital-Era Governance: A Quasi-Paradigm for Government on the Web.” Philosophical Transactions of the Royal Society A: Mathematical, Physical and Engineering Sciences 371(1987): 20120382. https://doi.org/10.1098/rsta.2012.0382. Ministerio de Desarrollo Social and World Bank. 2018. Registro Social de Hogares de Chile. Santiago de Chile. https:// www.desarrollosocialyfamilia.gob.cl/storage/docs/RSH_paper_2.pdf. Ministry of Family and Social Policy (MoFSP) and World Bank. (2017). “Turkey’s Integrated Social Assistance System.” Government of the Republic of Turkey & The World Bank joint publication, Ankara. https://www.aile.gov.tr/SYGM/ PDF/Turkeys_integrated_social_assistance_system.pdf. Mostafa, J., and N. Sátyro. 2014. “Cadastro Único: A Registry Supported by a National Public Bank.” Working Paper No. 126. International Policy Centre for Inclusive Growth (IPC-IG), Brasilia. https://www.econstor.eu/ handle/10419/119811. Muralidharan, K., P., Niehaus, and S. Sukhtankar. 2016. “Building State Capacity: Evidence from Biometric Smartcards in India.” American Economic Review 106(10): 2895–2929. https://doi.org/10.1257/aer.20141346. Organisation for Economic Co-operation and Development (OECD). 2016. “South Africa: Quasi-Federal Country.” Joint study of United Cities and local Governments (UCLG) and OECD. OECD, Paris. https://www.oecd.org/ regional/regional-policy/profile-South-Africa.pdf. Organizing Engagement. 2024. “Ladder of Citizen Participation.” Blog post. https://organizingengagement.org/ models/ladder-of-citizen-participation/. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 173 BIBLIOGRAPHY Ortakaya, A. F., O. Alper, M. Varghese, and C. Meier. 2022. “Deep Dive into the Ecosystem for the Delivery of Social Assistance Payments: Türkiye Case Study.” World Bank, Washington, DC. https://documents.worldbank.org/en/publication/ documents-reports/documentdetail/099010011072245762/p17316601c8b0401b0ab340214079f623b6. Pérez-Perdomo, R., and J. H. Merryman. 2018. The Civil Law Tradition: An Introduction to the Legal Systems of Europe and Latin America, Fourth Edition. Stanford University Press. Pople, A., R. Hill, S. Dercon, and B. Brunckhorst. 2021. “Anticipatory Cash Transfers in Climate Disaster Response.” CSAE Working Paper WPS/2021­ 07. Centre for the Study of African Economies (CSAE). Republic of Argentina. 2020. Decree No 310/2020: Emergency Family Income. Official Gazette, 23 March 2020. https:// www.boletinoficial.gob.ar/detalleAviso/primera/227113/20200324. Republic of Estonia. 2011. “Interoperability Framework of the State Information System.” Ministry of Economic Affairs and Communications, Republic of Estonia. https://www.stat.ee/sites/default/files/2022-11/Estonian%20IT%20 Interoperability%20Framework%20-%20Abridgement%20of%20Version%203.0.pdf. Rocher, L., J. Hendrickx, and Y-A de Montjoye. 2019. “Estimating the Success of Re-identifications in Incomplete Datasets Using Generative Models.” Nature Communications 10, 3069. https://www.nature.com/articles/s41467- 019-10933-3. Rochet, J.-C., and J. Tirole. 2003. “Platform Competition in Two-sided Markets.” Journal of the European Economic Association 1(4): 990–1029. http://www.jstor.org/stable/40005175. Saidi, M., A. Anglio, L.A. Billey, and H.C. Rabearivony Andrianjakanava. 2003. Sahel Adaptive Social Protection Program (SASPP): Annual Report—Fiscal Year 2023 (English). Washington, D.C.: World Bank Group. http://documents. worldbank.org/curated/en/099635009192317118/IDU03f4125650dae504bd00b97a05226295cde41. Salomon, J. 2017. “Human Centered Design.” Presentation. World Bank, Washington, DC. Secretaría de Desarrollo Social (SEDESOL). 2011a. “Cuestionario Único de Información Socioeconómica (CUIS).” PowerPoint presentation. Dirección General de Geoestadística y Padrones de Beneficiarios, SEDESOL, Mexico. Secretaría de Desarrollo Social (SEDESOL). 2011b. “Sistema de Información Social Integral.” PowerPoint presentation. Dirección General de Geoestadística y Padrones de Beneficiarios, SEDESOL, Mexico. Sen, A. 1995. “The Political Economy of Targeting.” In D. van de Walle and K. Nead, eds., Public Spending and the Poor. Washington, DC: World Bank. Schiffer, E. 2007. “How Net-Map Works.” Net-Map Toolbox: Influence Mapping of Social Networks. https://netmap. wordpress.com/about/. Silva Villalobos, V., et al. 2015. “Avanzando hacia sistemas de protección social y trabajo en América Latina y el Caribe.” Social Protection and Labor Global Practice. World Bank, Washington, DC. Silva Villalobos, V. 2016. “Integrating Social Protection Programs and Delivery Systems: Chile’s Evolving Trajectory. Presentation, October 4, 2016. World Bank, Washington DC. Simon, H. 1969. The Sciences of the Artificial (1st ed). Cambridge, MA: MIT Press. Tabatabaei, S.K., B. Wang, N. Athreya, B. Enghiad, A. Hernandez, C. Fields, J-P. Leburton, D. Soloveichik, H. Zhao, and O. Milenkovic. 2020. “DNA Punch Cards for Storing Data on Native DNA Sequences via Enzymatic Nicking.” Nature Communications 11: 1742. https://doi.org/10.1038/s41467-020-15588-z. Tizzoni, M., P. Bajardi, A. Decuyper, G. K. K. King, C. Schneider, V. D. Blondel, Z. Smoreda, M. C. González, and V. Colizza. 2014. “On the Use of Human Mobility Proxies for Modeling Epidemics.” PLOS Computational Biology 10(7): e1003716. https://doi.org/10.1371/journal.pcbi.100371. 174 “WHAT MATTERS” GUIDANCE NOTE Torrance, D., and S. Horswell. 2003. “Introduction to Devolution in the United Kingdom.” UK House of Commons Library, Research Briefing, No CBP 8599, 15 Nov 2023. https://researchbriefings.files.parliament.uk/documents/ CBP-8599/CBP-8599.pdf. Tucker, C. 2023. “Algorithmic Exclusion: The Fragility of Algorithms to Sparse and Missing Data.” The Brookings Institution, Washington, DC. https://www.brookings.edu/wp-content/uploads/2023/02/Algorithmic-exclusion- FINAL.pdf. United Nations (UN). 2019. Report of the Special Rapporteur on Extreme Poverty and Human Rights. Office of the High Commissioner for Human Rights. New York, NY: United Nations. https://www.ohchr.org/en/press- releases/2019/10/world-stumbling-zombie-digital-welfare-dystopia-warns-un-human-rights-expert. United Nations (UN). 2023. The Sustainable Development Goals Report 2023: Special Edition. Toward a Rescue Plan for People and Planet. New York, NY: United Nations. United Nations Development Programme (UNDP). 2019. The State of Social Assistance in Africa. New York, NY: UNDP. https://www.undp.org/africa/publications/state-social-assistance-africa-report. Viljoen, S. 2020a. “Data as Property?” Phenomenal World, 16 Oct 2020. https://phenomenalworld.org/analysis/ data-as-property. Viljoen, S. 2020b. “Democratic Data: A Relational Theory for Data Governance.” Yale Law Journal, November 11, 2020. http://dx.doi.org/10.2139/ssrn.3727562. Wagner, B., C. Ferro, and J. Stein-Kaempfe. 2022. Implementation Guide—Good Practices for Ensuring Data Protection and Privacy in Social Protection Systems: A Guide for Practitioners Working and Advising in Low and Middle-Income Countries. Social Protection Inter-Agency Cooperation Board (SPIAC-B). https://socialprotection.org/discover/ publications/implementation-guide-%E2%80%93-good-practices-ensuring-data-protection-and-privacy. Williams, A., and V. Moreira. 2020. “Making Social Protection Systems Adaptable.” World Bank, Washington, DC. https:// openknowledge.worldbank.org/server/api/core/bitstreams/88116421-92ba-5422-afe4-a4b521d6022a/content. World Bank. 2009. “Dealing with Governance and Corruption Risks in Project Lending Emerging Good Practices.” Operations Policy and Country Services. World Bank, Washington, DC. http://siteresources.worldbank.org/ EXTGOVANTICORR/Resources/3035863-1281627136986/EmergingGoodPracticesNote_8.11.09.pdf. World Bank. 2012. Resilience, Equity, and Opportunity: The World Bank’s Social Protection and Labor Strategy 2012–2022 (English). Washington, DC: World Bank Group. http://documents.worldbank.org/curated/en/443791468157506768/ Resilience-equity-and-opportunity-the-World-Banks-social-protection-and-labor-strategy-2012-2022. World Bank. 2016a. World Development Report 2016: Digital Dividends. Washington, DC: World Bank. doi:10.1596/978- 1-4648-0671-1. License: Creative Commons Attribution CC BY 3.0 IGO. World Bank. 2016b. “Turkey’s Integrated Social Assistance System.” Documents and Reports Internal. Washington, DC: World Bank Group. World Bank. 2017. ID Enabling Environment Assessment. Washington, DC: World Bank License: Creative Commons Attribution 3.0 IGO (CC BY 3.0 IGO). https://id4d.worldbank.org/legal-assessment. World Bank. n.d. The Atlas Of Social Protection: Indicators Of Resilience And Equity (ASPIRE). World Bank, Washington, DC. https://datacatalog.worldbank.org/int/search/dataset/0037942. World Bank. 2019. Open Source for Global Public Goods. Washington, DC: World Bank. License: Creative Commons Attribution 3.0 IGO (CC BY 3.0 IGO). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 175 BIBLIOGRAPHY World Bank. 2020a. “Argentina ID Case Study: The Evolution of Identification.” Washington, DC: World Bank. World Bank, Identification for Development (ID4D). https://documents1.worldbank.org/curated/en/318351582559995027/ pdf/Argentina-ID-Case-Study-The-Evolution-of-Identification.pdf. World Bank. 2020b. Poverty and Shared Prosperity 2020: Reversals of Fortune. Washington, DC: World Bank. © World Bank. https://openknowledge.worldbank.org/handle/10986/34496 License: CC BY 3.0 IGO. World Bank. 2020c. “Project Appraisal Document for the Social Safety Net System Project II (Report No. PAD3426).” Documents and Reports Internal. World Bank, Washington, DC. World Bank. 2020d. “Scaling Up Social Assistance Payments as Part of the COVID-19 Pandemic Response.” World Bank, Washington, DC. https://thedocs.worldbank.org/en/doc/655201595885830480-0090022020/original/ WBG2PxScalingupSocialAssistancePaymentsasPartoftheCovid19PandemicResponse.pdf. World Bank. 2021. World Development Report 2021: Data for Better Lives. Washington, DC: World Bank. © World Bank. https://openknowledge.worldbank.org/handle/10986/35218 License: CC BY 3.0 IGO. World Bank Group. 2022a. “Charting a Course Toward Universal Social Protection: Resilience, Equity, and Opportunity for All.” © World Bank Group, Washington, DC. http://hdl.handle.net/10986/38031 License: CC BY 3.0 IGO. World Bank. 2022b. “Strategic Communications for Identification Systems: Guidance Note.” Washington, DC: World Bank License: Creative Commons Attribution 3.0 IGO (CC BY 3.0 IGO). World Bank and United Nations. 2024. Combatting Cybercrime: Tools and Capacity Building for Emerging Economies. Washington, DC: World Bank, 2024 (hereinafter “Cybercrime Toolkit”). www.combattingcybercrime.org. World Food Programme (WFP). 2022. “A Global Food Crisis.” WFP, Rome. Accessed April 14, 2024. https://www.wfp. org/emergencies/global-food-crisis. Yeh, C., A. Perez, A. Driscoll, G. Azzari, Z. Tang, D. Lobell, S. Ermon, and M. Burke. 2020. “Using Publicly Available Satellite Imagery and Deep Learning to Understand Economic Well-Being in Africa.” Nature Communications 11, 2583. https://doi.org/10.1038/s41467-020-16185-w. 176 “WHAT MATTERS” GUIDANCE NOTE Annex ANNEX 1. EXEMPLAR OF SYNERGIES: INTEROPERABILITY BETWEEN DSPDS AND DISASTER RISK INFORMATION SYSTEMS DSPDS enable opportunities for countries to mobilize existing resources and delivery systems to make coverage flexible in response to changes in needs and conditions in response to shocks. Rather than developing new interventions from scratch, DSPDS are designed to be flexible enough to evolve and adapt the balance and scale of programs in light of changing social protection needs. Changes in social protection needs may arise from socioeconomic, sociodemographic, natural, or political developments. These may require short-term rapid responses or longer-term adjustments. These responses typically consist of vertical expansion (increasing the value or duration of benefits), horizontal expansion (increasing the number of beneficiaries), or design tweaks (relaxation of conditionalities, changes in eligibility criteria, and so forth), among others.163 These reactions, however, require a system that promptly identifies who the recipients should be, flexible delivery systems, and strong coordination among actors involved in shock response. Interoperability between DSPDS and disaster risk information systems (DRIS)164 can enhance decision-making and action before, during, and aftershocks, especially in the context of growing climate-related risks. The potential applications are multifold, including the following:165 Risk profiling: data from dSR combined with data from DRIS can inform household risk and vulnerability assessments to better understand disaster risks, household exposure, and household economic impacts. dSR containing georeferenced information can be paired with hazard data from DRIS, such as GIS, to produce more 163. See, for example, Gentilini et al. (2021) for a global review of social protection responses to the COVID-19 pandemic. 164. DRIS include GIS, early warning systems, and registries of disaster-affected households (Williams and Moreira 2020). 165. Based on Barca and Beazley (2019), Bowen et al. (2020), and Williams and Moreira (2020). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 177 ANNEX precise hazard maps to observe household exposure to shocks. Moreover, data from dSR can inform socioeconomic resilience models that estimate the potential effects of asset losses on income, consumption, and well-being at the household level. As Bowen et al. (2020) point out, additional data may need to be generated for dSR depending on the nature of common shocks affecting a country. For instance, in the case of countries affected by seasonal droughts, data on food insecurity and agricultural activities may need to be captured. • Risk reduction: based on their risk profile, households and individuals can be referred to specific benefits and services to reduce risk. • Planning: dSR and unique identification systems can assist in providing a preliminary estimate of the expected number of individuals or households affected by various types of shocks, especially when they are recurrent or predictable. This information can be used to simulate financial needs. Furthermore, by providing an overview of who receives what, IBR can help decision-makers plan for ad hoc packages of benefits and services. • Preparedness: data from dSR and early warning systems can support preparedness actions such as the evacuation of vulnerable groups (the elderly, the disabled, and so forth) or support communication campaigns on preparedness. • Emergency response: early warning systems have been increasingly used to trigger ex ante or ex post social protection response. The primary purpose of triggers is to activate the release of funds and early response measures once specific pre-set thresholds have been reached. Data from IBR can be used for rapid vertical expansion of benefits, while data from dSR can be used for horizontal expansion. • Post-disaster assessments: post-disaster household assessments are frequently utilized to gather data on the degree of damage and requirements of impacted households. dSR can inform such assessments. For nascent or emerging dSR, if properly planned, the information collected through post-disaster household assessments can be integrated into the system to facilitate its expansion and updating. FIGURE A1.1 Scalability in response to shocks SOURCE: Lawson et al. (2023), based on the author’s adaptation from Bowen et al. (2020). 178 ANNEX ANNEX 2. LIST OF POTENTIAL INDICATORS TO MONITOR THE PERFORMANCE OF DSPDS Criteria Example of indicators (non-exhaustive list) Data % of the intended population who actively provide, update, rectify, or complement information % of the intended population who is captured using administrative data sources % of the intended population who is captured using non-traditional data sources Number of registered individuals Breadth: the extent to which the intended Number of registered households population is % of the intended population registered in the dSR captured % of the intended population registered in the dSR, disaggregated by region % of the bottom x%/women/children/elderly/people with disabilities/migrants/IDPs registered in the dSR % of the total population with unique identifiers Number of data sources pushing data to the dSR Number of data sources used to verify income Number of data sources used to verify consumption or assets Depth: the extent to Number of data sources used to verify sources of vulnerability (disability, health issues, illiteracy, which the necessary and so forth) data are captured % of data that are complete, that is, without null data values or missing values % of fields captured in the dSR with respect to the data model to assess needs and conditions Questionnaire/forms average completion time Gap between data values and “ground truth” % of data that are unusable due to quality problems (for example, data entry problems) % of applicants that were not reached due to incorrect contact information (address, phone, SMS, USSD, email) Non-response bias Accuracy: the extent Sampling error to which data represent reality Perceived quality of data and correctness, are % of data found to be reliable through validity checks (consistency, logic) unique and consistent % of data found to be reliable through verification checks (cross-checks, audits, supervisions, community checks) % of data with discrepancies across sources % of duplicate records Number of information systems adhering to common data dictionaries Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 179 ANNEX Criteria Example of indicators (non-exhaustive list) Timeliness: the extent % of households that have updated their information in the past X years/months to which data are up Frequency of data exchange between the dSR and administrative data sources for data updates to date and available within an acceptable % of updates to household composition (births, deaths) facilitated by data exchanges with CRVS time frame, timeline, and duration Delivery chain % of the intended population who initiated their registration to the dSR % of applicants who completed their registration to the dSR, with respect to those who initiated the process % of the intended population covered by outreach campaigns, disaggregated by modality % of the intended population reached by technology-enabled solutions % of in-person service centers per total intended population by region/municipality Average distance to closest in-person service center by region/municipality % of online/digital applications to programs Number of requests to update or rectify information made by applicants Number of requests to update or rectify information made by programs or administrators % of applicants assessed against eligibility criteria Periodicity of poverty/vulnerability model computation Effectiveness: the Periodicity of the transmission of list of eligible applicants to user programs extent to which the system reaches, % of intended population enrolled in SP programs registers, and % of enrolled who are part of the poorest quintiles provides benefits and services to the % of applicants whose eligibility is determined according to program rules intended population % of applicants who are notified of the eligibility determination according to service standards and accommodates the specific needs % of (sampled) applicants whose classification in the dSR (for example, as moderately poor, of vulnerable extreme poor) is comparable to those in the same categories in household surveys (using populations and similar welfare measures) those who face % of recipients who receive benefits but do not meet eligibility criteria (inclusion error) access barriers % of intended population who do not receive benefits and meet eligibility criteria (exclusion errors) % of beneficiaries whose benefit and service packages are determined according to program parameters and benefit calculators % of beneficiaries who benefit from integrated packages of benefits and services % of beneficiaries whose benefit/service package is up to date in the BOMS % of grievances received that are related to assessment issues % of grievances related to discrimination/exclusion % of grievances due to the provision of benefits and services % of registered grievances that have been placed in the process of resolution according to service standards % of registered grievances resolved % of grievances for which the beneficiary is notified of status according to service standards 180 ANNEX Criteria Example of indicators (non-exhaustive list) % of eligibility and enrollment decisions processed electronically % of beneficiaries with redundant benefits % of duplicated beneficiaries % of ghost beneficiaries Administrative or program costs compared to inclusion/exclusion error Time, costs, and visits (TCV) for applicants, by intake modality Time to process application Time to assess needs and conditions Time from application to notification of eligibility and enrollment Time from the date of application to the date of notification and onboarding Efficiency: the extent Time from application to benefit or service package decision to which the system streamlines delivery TCV for beneficiaries to collect payments, by payment modality processes for people Time to reconcile payments and programs Time to transfer beneficiary registries to IBR Time for compliance verification Time between payroll generation and cashing out benefits Time to process grievances from uptake to feedback Frequency of updates to the IBR Volume of applications processed through the dSR per day/week/month Number of programs using information from dSR Number of payments platforms integrated with BOMS Number of data sources used for compliance verification Number of programs leveraging interoperability for compliance verification Technology % of users who report high levels of satisfaction with the system’s design and usability Human-centered Number of languages in which the system interfaces is available design: the extent to which the system % of grievances due to accessibility issues is accessible to all % of target users who use the system stakeholders online and offline % of user feedback received that is responded to and acted upon by the development team Frequency and severity of user errors or mistakes made while using the system (online/offline) % of time that the system is operational and available to users Frequency and duration of system outages or downtime periods System efficiency: the Average time it takes for the system to respond to user requests or transactions extent to which the Maximum time it takes for the system to respond to user requests or transactions system is available to users in a continuous Number of user transactions that the system is able to process within a given time period (per manner second, per minute, and so forth) Time it takes for technical support to respond to user requests or issues % of technical issues solved Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 181 ANNEX Criteria Example of indicators (non-exhaustive list) Data protection Number of security incidents that could have breached the privacy of the data and privacy: the Distribution of users according to access controls (administrator, standard user, read-only user, extent to which the and so forth) system protects and secures user data and % of data encrypted information % of anonymization Ability to handle increasing user demands or data volumes (stability in performance and response times under increasing user loads) Scalability: the Number of users that can access the system simultaneously extent to which the Ability of the system to serve users in different geographic locations system is able to expand and adapt Number of modules or components in the system to increasing user Degree of interdependence between modules demands or changing requirements Ease with which modules can be replaced or upgraded Rate to which the system incorporates innovations to improve performance or functionality (new and emerging technologies, new features or updates, and so forth) Frequency of data exchanged with other systems Data exchange: the Volume of data exchanged with other systems extent to which the system is able to Time to exchange information between systems exchange and share Number of information systems/organizations adhering to service-oriented IT architecture data with other standards systems or platforms Number of BOMS integrated to the IBR Cost-benefit: the Total cost of operating and maintaining the system extent to which the Average cost of providing the system to each user (programs and people) system provides a good balance Cost savings or efficiencies compared to previous systems or approaches between cost and performance Governance Number of strategic priorities identified and achieved within a given period Strategic: the extent Number of collaboration agreements signed with institutions/programs/municipalities to which strategic- level governance % of data that meets data privacy regulations facilitates the Number of policies and procedures that were reviewed or updated execution of DSPDS Compliance with data retention and disposal policies and procedures % of back-office staff with minimum knowledge of application process/eligibility/information Administrative: the system/targeting framework extent to which % of program staff trained to use key component systems of DSPDS (specify ___, for example, administrative- dSR) level (“back-office”) governance facilitates % of key positions filled the execution of Back-office staff turnover rate DSPDS Level of staff compliance with operational procedures and processing times 182 ANNEX Criteria Example of indicators (non-exhaustive list) % of front-office staff with minimum knowledge of application process/eligibility/information system/targeting framework % of front-office staff trained to use key component systems of DSPDS (specify ___, for example, dSR) Operations: the extent to which % of front-office staff trained on outreach to vulnerable populations or who speak the language operational-level of vulnerable populations or who have diversity and inclusion training (“front-office”) Size of case load (number of cases per staff) governance facilitates the execution of % of scheduled hours worked by front-office staff DSPDS Front-office staff turnover rate Frequency and extent of wage (and travel reimbursement) arrears for front-office staff Number of agreements with municipalities/NGOs/programs/communities to execute front- office operations SOURCE: Authors’ elaboration with inputs from the Sourcebook (Lindert et al. 2020). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 183 ANNEX ANNEX 3. BUSINESS PROCESS AND JOURNEY MAPS Business Process Mapping is a useful management tool for assessing institutional roles and sequencing of core business processes within the implementation phases along the delivery chain of social programs. This annex provides country examples of process maps. Here, the maps are ordered by the section of the delivery chain which each illustrates. Intake Outreach Delivery process mapAssessment & Registration chain of N&C for unemployment Enrollment assistance benefits and FIGURE A3.1 services in fictional country 2 Social registry cross- 5 6 Social information system Social registry checks eligibility and computes 7 checks information internally cross-checks information MoSA benefits for unemployment Enrollment & externally; flags any gaps internally & externally; if assistance; flags potential elegibility or irregularities; updates info complete, client Decision for programs in other agencies client status; Sends SMS text profile created (e.g.,health insurance subsidies, etc.) 4A Caseworker pulls up client’s file, Complex needs 4B Further Yes conducts interview, gathers info, SSO assesses profile, checks potential multi-dimensional eligibility, obtains consent form, explains assessments next steps, updates file in social registry ESO 1B In person: apply at an SSO kiosk 3 Client recieves 8 Unemployed SMS alert, status updated in online Individual with help if needed SMS, checks account. If approved, notification includes status, schedules explanation of benefits, and instructions for interview online; next steps for filing claims and service 1A Online:Provision Benefit use eligibility simulator, Service goes to SSOProvision for Monitoring Provision Benefitredress referrals. If not approved, grievance create account, apply online interview procedures 10 16C Monitoring of 18 BOMS authorizes payment compliance with 18. BOMS authorizes MoSA order. Bank processes payment orders IAP, updating of payment order. Bank credits and credits beneficiary accounts information in beneficiary accounts (separate (separate payment processing chart, social information payment processing chart, not not shown) system shown) 13B 16B Verify Service Complex appointment with and update IAP client depending activities and SSO needs on Individual services in Action Plan (for social informa- complex needs) tion system 13A 16A Verify job Create Close JobMatch.com search; Update to ESO account and profile; client status and Labor job search support; compliance info in Market referrals; training social information Repeat services, etc. system 15 Update 17 19 Unemployed 9 11 12 14 Individual Carry out info & File 1st benefit Receives 1st Go to ESO or job search or File 2nd Receives 2nd record job benefit payment claim online, with payment into SSO for other IAP search bank account info bank account service visit activities claim into bank online online account SOURCE: Lindert et al. (2020). 184 ANNEX Journey map for unemployment assistance benefits and services— FIGURE A3.2 fictional person’s experience Benefit Payment Job deposited in account Approval! “Feeling” Highs, lows, Loss Experiences: Negative to Positive 6 Open NTB JOB SEARCH Gather docs Submit Apply online Application Interview Account 4 Painpoints Relieved! Go to WCSC Relieved! Relieved!- File Claim Able to pay 2 rent on time JOB SEARCH 0 Hopeful -2 Worried about not Distraught Hopeful Worried about not being able to pay -4 rent making it through Frustrated by having to open month or being Another bank account -6 able to pay rent Create MyMonrovia Go to NTB to open Check status in Account, check bank account online account; Upload docs, elegibility, start Beneft payment submit “Doing” steps actions, application Go to WCSC Deposited! application Go to ESSO for online interview for service Touchpoints appointment Receive Approval Go to tech firm, Notification in Bank, MHLO File Claim Online account Notary Online 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Costs, and Visits Excessive Time, Number of Calendar Days Since Trigger Event 2 hrs 2+2 hrs 2 hrs 3 hrs 2 hours 1 hour 3 hours $6 bus fare $4 bus fare $4 bus fare $4 bus fare $6 notary fees 1 visit 1 trip 1 visit 2 trips SOURCE: Lindert et al. (2020). Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 185 ANNEX ANNEX 4. GLOSSARY: IT CHEAT SHEET Data. A value or set of values representing a specific concept or concepts. Data can become “information” when analyzed and possibly combined with other data in order to extract meaning and to provide context. The meaning of data can vary depending on its context and is often used interchangeably with information. • Dynamic data or transactional data. Data that change as a result of an event (a transaction). The data have a time dimension, a numerical value, and refer to one or more reference data objects such as orders, invoices, and payments. • Master data. A single source of common business data that are agreed upon and shared across the organization, and are used across multiple systems, applications, and processes. Examples include data about customers, products, employees, suppliers, materials, vendors, and so on. • Metadata. Data that describes other data. • Semi-structured data. A form of unstructured data that do not conform with the formal structure of data models but contain tags, metadata, or markers to separate semantic elements and to enforce hierarchies of records and fields within the data. Examples include XML (extensible markup language) data and JSON (JavaScript Object Notation). • Structured data. Information with a high degree of organization, such that it can be stored in a relational database and is readily searchable using algorithms or operations. An example is data in spreadsheets. • Unstructured data. Data that do not have a predefined data model and are not organized in a predefined format. Examples include text documents, video, audio, mobile activity, social media activity, and satellite imagery. • Big data. Big data is an umbrella term to refer to the immense volume of data that require more computing power to gather and analyze. Big data consists of structured, unstructured, and semi-structured data. It is characterized by its volume (massive scale and size), velocity (high speed at which they are generated), variety (broad assortment of data types and formats), veracity (quality and integrity of data), and value (ability to be turned into actionable insights). • Data dictionary. A repository that contains descriptions of all data objects consumed or produced by the software. It presents an organized listing of all data elements that are pertinent to the system, with precise, rigorous definitions so that both user and system analyst will have a common understanding of inputs, outputs, components of stores, and (even) intermediate calculations. Data analytics, business intelligence. Helps you find answers to a set of defined questions. It includes the generation, aggregation, analysis, and visualization of data to inform and facilitate business management and strategy. It also includes data mining, reporting, time series analysis (including predictive techniques), OLAP, and statistical analysis. • Data mining. Helps find answers you did not know you were looking for beforehand. An analytical process that attempts to find correlations or patterns in large data sets for the purpose of data or knowledge discovery. A famous legend from the retail industry was the discovery that men between ages 30 and 40 who purchased diapers on a Friday night would most likely also have beer in their cart, which led the retailer to move diapers and beer closer to each other. Data mining has now upgraded to “big data.” 186 ANNEX • Data scientists. Experts in statistics and computer science who know the tricks for finding the signals hidden in the noise of big data. • Online analytical processing (OLAP). A data structure that allows fast analytical processing from multiple perspectives, usually using star or snowflake schema, stored as metadata, from which one can pivot the data in many ways. Database. A large, organized collection of information that is accessed via software. • Database management system (DBMS). A software package designed to define, manipulate, retrieve, and manage data in a database. It has four components: an application programming interface (API), a query interface, an administrative interface, and an underlying set of data access programs and subroutines. Application programs never access the physical data store directly. They tell an appropriate DBMS interface what data they need to read and write, using names defined in the schema. • Data warehouse. A subject-oriented, nonvolatile, time-variant collection of data in support of management’s decisions. It typically draws its content from a large number of operational and external databases and uses a federated architecture approach for implementation. • Distributed database (DDB). An integrated collection of databases that is physically distributed across sites in a computer network. A distributed database management system (DDBMS) is the software system that manages a distributed database such that the distribution aspects are transparent to the users. • NoSQL. A class of database management systems (DBMS) that do not follow all of the rules of a relational DBMS and cannot use traditional SQL to query data. In the 21st century, NoSQL database management systems have evolved, where data are modeled in means other than tabular relations, which is particularly useful for real- time web applications and for big data. NoSQL-based systems are typically used in very large databases, which are particularly prone to performance problems caused by the limitations of SQL and the relational model of databases. Many think of NoSQL as the modern database of choice that scales with web requirements. Some notable implementations of NoSQL are Facebook’s Cassandra database, Google’s BigTable, and Amazon’s SimpleDB and Dynamo. • Relational database management system (RDBMS). First developed in the 1970s, it is a DBMS that organizes stored data into structures called tables, or relations. The common difference between DBMS and RDBMS is that DBMS just provide an environment where people can conveniently store and retrieve information with the presence of redundant data. On the other hand, RDBMS uses normalization to eliminate the data redundancy. Examples include MS SQL Server, IBM DB2, ORACLE, My-SQL, and Microsoft Access. • Virtual database. Information systems are developed over time using different DBMSs and may be owned by different parts of an organization. As a result, data are fragmented across a number of systems, organizational, and geographic boundaries. A virtual database is a type of database management system that serves as a container to transparently view and query several other databases through a uniform application programming interface (API) that culls from multiple sources as if they were a single entity. These databases are connected via a computer network and then accessed as if they are from a single database. The goal for a virtual database is to be able to view and access data in a unified way without needing to copy and duplicate it in several databases or manually combine the results from many queries. They are also known as federated databases. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 187 ANNEX Information systems. Interdependent groups of elements that function together to accomplish some predefined goal (or to solve an organizational problem) by collecting, organizing, storing, processing, creating, and distributing information. To accomplish that goal, an information system makes use of a variety of system elements, namely, the following: • Database. A large, organized collection of information that is accessed via software. • Documentation. Manuals, forms, and other descriptive information that portray the use and/or operation of the system. • Hardware. A comprehensive term for electronic and electromechanical devices that comprise the physical parts of a computer. The internal parts of a computer (CPU, hard drive, RAM) are referred to as components and the external parts (mouse, keyboard, printers, scanners) are referred to as peripherals. • People. Users or operators of elements of the system. • Procedures. The steps that define the specific use of each system element or the procedural context in which the system resides. • Software. Characterized by (1) a set of machine-readable instructions (lines of code) that when executed provide desired features, functions, and performance; (2) data structures that enable the instructions to manipulate information; and (3) descriptive information in both hard copy and virtual forms that describe the operation and use of the instructions. Application software are stand-alone programs that solve a specific business need. Such applications process business and technical data in a way that facilitates business operations or management/technical decision making. Integration and Interoperability • Application programming interface (API). A set of functions and procedures for integrating application components. APIs allow software applications to communicate with each other without having to know how they are implemented. • Data integration. Combines data from different sources and provides users with a unified view of these data for service integration. When services are provided by multiple suppliers, the service integration challenge is to seamlessly integrate them into end services that operate as a single IT service delivery model. Data integration involves the practice of applying architectural techniques and tools to provide access and delivery of data with varied data types and structures in order to meet the data needs of the applications and business processes within an organization. • Integration. Integration and interoperability are often conflated, but they mean two different things. Integration is the process of linking independently designed applications to work together as one system, so that the data contained in each becomes part of a larger, more comprehensive system that quickly and easily shares data when needed. Integration also enables access to data and functionality from such independent applications through a single interface or service. • Interoperability. The ability of organizations to interact toward mutually beneficial goals, involving the sharing of information and knowledge between organizations, through the business processes they support, by means of exchange of data with other systems using common standards. Interoperability also includes the ability of systems to provide and receive services from other systems and to use the services so interchanged to enable them to operate effectively together. 188 ANNEX • Interoperability framework. An agreed approach for interoperability for organizations that wish to work together toward the joint delivery of public services (without having to integrate all of their subsystems into one large system). Software. See also “Information systems” list, above. • Commercial off-the-shelf (COTS). Packaged, commercially available software solutions that are adapted to meet the requirements of the purchasing organization. • Custom, locally developed software (LDSW) or homegrown software or bespoke software. Software developed specifically for an organization or user. • Customization. Includes configuration, modification, and enhancements made to the software application. o Configuration. The process of selecting from an assortment of options, such as defining values of parameters in a software package, without writing specific code to meet requirements of the application. o Enhancement. The process of adding program code or program modules to provide additional functionality to software. It does not alter existing processes. It adds to them. o Modification. The process of changing program code to alter the existing form of processing. Modifications may be discouraged and unsupported by packaged software vendors, and in many cases the code may not be accessible. It can cause problems when the organization decides to install an upgraded version of the software. • Maintenance. Modification of software after delivery to correct faults, to improve performance or other attributes, or to adapt the application to a changed environment. • Mobile apps. The term “app” has evolved to specifically connote software that is designed to reside on a mobile platform such as a tablet or mobile phone. It encompasses a user interface that interoperates with web-based resources that provide access to a wide array of information that is relevant to the app and local processing capabilities that collect, analyze, and format information in a manner best suited to the mobile platform. Additionally, a mobile app provides persistent storage capabilities within the platform. Mobile apps are generally downloaded from application distribution platforms that are operated by the owner of the mobile operating system, such as the Apple App Store (iOS) or Google Play Store. • Open-source software. Software developed by informal collaborative networks of programmers and are usually free. Anyone is freely licensed to use, copy, study, distribute, and change the software in any way, and the source code is openly shared so that people are encouraged to voluntarily improve the design of the software. For more details and examples of open-source software, visit https://opensource.com/resources/ what-open-source. o Free and open source (FOSS). Refers to user’s freedom to copy and reuse the software. o Free/libre open source software (FLOSS). Emphasizes the value of libre (free), that is, with few or no restrictions. • Proprietary software. Software protected by intellectual property rights; generally requires purchase of a license to use by payment of a one-time fee or recurring fees, and the source code is typically hidden from users. • Turnkey system. A complete system solution, including software and hardware, that is sold to the purchasing organization as a complete product without the need for additional configuration and can be used immediately once installed or implemented. Playbook on Digital Social Protection Delivery Systems: Towards Dynamic Inclusion and Interoperability 189 ANNEX Systems architecture • Enterprise architecture. Can be considered as a superset of business, data, application, and technology architecture. See The Open Group Architecture Framework (TOGAF) for more detail. o Application architecture. A description of the structure and interaction of the applications as groups of capabilities that provide key business functions and manage the data assets. o Data architecture. A description of the structure and interaction of the enterprise’s major types and sources of data, logical data assets, physical data assets, and data management resources. o Technology architecture. A description of the structure and interaction of the technology services and technology components. • Microservice architecture. Or simply microservices, is a variant of service-oriented architecture that has grown in popularity in recent years. Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well- defined application programming interfaces (APIs). These services are owned by small, self-contained teams. Microservices architectures make applications easier to scale and faster to develop, enabling innovation and accelerating time-to-market for new features. It is a method of developing software applications as a suite of loosely coupled, independently deployable, modular services in which each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal. The opposite of this is the monolithic architectural style. For example, Amazon has migrated to microservice architecture. Amazon gets countless calls from a variety of applications—including applications that manage the web service API as well as the website itself—which would have been simply impossible for their old, two-tiered architecture to handle. In a microservice application, each service usually manages its unique database. See Werner Vogels video for more detail: https://nerdrabbit.com/blogs/2022/12/02/aws-reinvent-2022-werner-vogels/. • Monolithic architecture. Unlike microservices, a monolith application is always built as a single, autonomous unit. In a client-server model, the server-side application is a monolith that handles the HTTP requests, executes logic, and retrieves/updates the data in the underlying database. The problem with a monolithic architecture, though, is that all change cycles usually end up being tied to one another. A modification made to a small section of an application might require building and deploying an entirely new version. If you need to scale specific functions of an application, you may have to scale the entire application instead of just the desired components. Monolithic systems use a single logical database across different applications. • Service-oriented architecture (SOA). An architectural style based on the use of services to produce interoperable, modular systems that are easier to use and maintain. These services carry out a small function such as data validation that can be reused by software applications or combined with a number of other services to provide the functionality of a large software application. • Three-tier architecture. A client-server architecture that is made up of three layers: the data layer, business logic layer, and presentation layer. This is also known as model view controller (MVC) architecture. o Business logic layer. The layer that contains the programs (lines of code) that implement the logic of the application’s core functionality. o Data layer. The layer that contains the database in which information is stored and from which it is retrieved. Data in this layer is kept independent of business logic. o Presentation layer. The part that constitutes the front-end layer of the application and contains the user interface with which end users interact through a web-based application to access the information system. SOURCE: Lindert et al. (2020). 190 ANNEX