OpenG2P

OpenG2P stands for open government to person payments, and provides the tools needed to digitize large scale cash transfers with open source building blocks.

Website: https://openg2p.org/

Type of Digital Public Good

  • Open content
  • Open data
  • ✅  Open software
  • Open standard
  • Open AI model

1. Is it relevant to one of the Sustainable Development Goals?

  • 1. No Poverty

    Evidence: OpenG2P helps advance a number of SDGs by ensuring that the low-income people receive their cash transfers (for livelihoods, for education, for women etc.) digitally, in ways that supports their access and usage at affordable rates, and thereby creating pathways for them to save and access a diverse range of financial services. OpenG2P by default leverages the entire ecosystem and therefore enables easy integration with identity and fintechs while keeping privacy and consent of users as key principles by design.

  • 2. Zero Hunger

    Evidence: OpenG2P helps advance a number of SDGs by ensuring that the low-income people receive their cash transfers (for livelihoods, for education, for women etc.) digitally, in ways that supports their access and usage at affordable rates, and thereby creating pathways for them to save and access a diverse range of financial services. OpenG2P by default leverages the entire ecosystem and therefore enables easy integration with identity and fintechs while keeping privacy and consent of users as key principles by design.

  • 3. Good Health and Well-being

    Evidence: OpenG2P helps advance a number of SDGs by ensuring that the low-income people receive their cash transfers (for livelihoods, for education, for women etc.) digitally, in ways that supports their access and usage at affordable rates, and thereby creating pathways for them to save and access a diverse range of financial services. OpenG2P by default leverages the entire ecosystem and therefore enables easy integration with identity and fintechs while keeping privacy and consent of users as key principles by design.

  • 4. Quality Education

    Evidence: OpenG2P helps advance a number of SDGs by ensuring that the low-income people receive their cash transfers (for livelihoods, for education, for women etc.) digitally, in ways that supports their access and usage at affordable rates, and thereby creating pathways for them to save and access a diverse range of financial services. OpenG2P by default leverages the entire ecosystem and therefore enables easy integration with identity and fintechs while keeping privacy and consent of users as key principles by design.

  • 5. Gender Equality

    Evidence: OpenG2P helps advance a number of SDGs by ensuring that the low-income people receive their cash transfers (for livelihoods, for education, for women etc.) digitally, in ways that supports their access and usage at affordable rates, and thereby creating pathways for them to save and access a diverse range of financial services. OpenG2P by default leverages the entire ecosystem and therefore enables easy integration with identity and fintechs while keeping privacy and consent of users as key principles by design.

  • 6. Clean Water and Sanitation

    Evidence: OpenG2P helps advance a number of SDGs by ensuring that the low-income people receive their cash transfers (for livelihoods, for education, for women etc.) digitally, in ways that supports their access and usage at affordable rates, and thereby creating pathways for them to save and access a diverse range of financial services. OpenG2P by default leverages the entire ecosystem and therefore enables easy integration with identity and fintechs while keeping privacy and consent of users as key principles by design.

  • 7. Affordable and Clean Energy

    Evidence: OpenG2P helps advance a number of SDGs by ensuring that the low-income people receive their cash transfers (for livelihoods, for education, for women etc.) digitally, in ways that supports their access and usage at affordable rates, and thereby creating pathways for them to save and access a diverse range of financial services. OpenG2P by default leverages the entire ecosystem and therefore enables easy integration with identity and fintechs while keeping privacy and consent of users as key principles by design.

  • 8. Decent Work and Economic Growth

    Evidence: OpenG2P helps advance a number of SDGs by ensuring that the low-income people receive their cash transfers (for livelihoods, for education, for women etc.) digitally, in ways that supports their access and usage at affordable rates, and thereby creating pathways for them to save and access a diverse range of financial services. OpenG2P by default leverages the entire ecosystem and therefore enables easy integration with identity and fintechs while keeping privacy and consent of users as key principles by design.

  • 10. Reduced Inequality

    Evidence: OpenG2P helps advance a number of SDGs by ensuring that the low-income people receive their cash transfers (for livelihoods, for education, for women etc.) digitally, in ways that supports their access and usage at affordable rates, and thereby creating pathways for them to save and access a diverse range of financial services. OpenG2P by default leverages the entire ecosystem and therefore enables easy integration with identity and fintechs while keeping privacy and consent of users as key principles by design.

  • 17. Partnerships to achieve the Goal

    Evidence: OpenG2P helps advance a number of SDGs by ensuring that the low-income people receive their cash transfers (for livelihoods, for education, for women etc.) digitally, in ways that supports their access and usage at affordable rates, and thereby creating pathways for them to save and access a diverse range of financial services. OpenG2P by default leverages the entire ecosystem and therefore enables easy integration with identity and fintechs while keeping privacy and consent of users as key principles by design.

2. Does it use an appropriate open license?

Yes, this project is licensed under the following license(s):

3. Is ownership clearly defined?

Is the ownership of the project and everything that the project produces clearly defined and documented?

Yes

If yes - please link to the relevant copyright, trademarks, or ownership documentation for the project.

https://docs.openg2p.org/

4. Does the license of libraries/dependencies undermine the openess of the project?

Does this open project have mandatory dependencies (i.e. libraries, hardware) that create more restrictions than the original license?

No

If yes - are the open source components able to demonstrate independence from the closed component(s) and/or are there functional, open alternatives?

Not Applicable

If yes - please describe how the open source components are independent and/or list the open alternatives for the closed component:

Not Applicable

5. Is there documentation?

Does some documentation exist of the source code, use cases, and/or functional requirements. For software projects, this should be present as technical documentation that would allow a technical person unfamiliar with the project to launch and run the software. For datasets and data projects, this should be present as documentation that describes all the fields in the set, and provides context on how the data was collected and how it should be interpreted. For content collections, this should indicate any relevant compatible apps, software, hardware required to access the content and any instructions about how to use it.

Yes

If yes - please link to the relevant documentation:

6. Is non PII data and/or content accessible?

Does this project collect or use non-personally identifiable information (non-PII) data and/or content?

Yes

If yes - is there a mechanism for extracting or importing non-personally identifiable information (non-PII) from the system in a non-proprietary format?

Yes

If yes - describe the mechanism for extracting or importing non-personally identifiable information from the system in a non-proprietary format:

OpenG2P use depends on how government agencies store, share, and treat PII data. OpenG2P advocates for and brings an approach that confers additional privacy, security and consent in systems that have historically lacked such features. The importance of this topic is highlighted in our first White Paper on the subject of Privacy and Security Design(attached). In terms of extracting non-personally identifiable data, the building blocks are designed to export data only relevant for a specific purpose. For example we provide an CSV export functionality as part of the data views, with field level controls available to hide specific details.
In the context of OpenG2P, we consider 'stateless building blocks' as ones not storing beneficiary associated data beyond the life of a request-response cycle. Such components tend to be adapters with external systems. An example of a stateless brick is the OpenG2P Verification Engine which enables lookup against external identity and data sources and does not store data beyond the request-response cycle.
An OpenG2P user will evaluate its data requirement and assess how critical it is to store beneficiary PII. Preference is not storing data and in making solutions stateless, however, if not a viable approach we advocate the following approaches, that prioritizes storing PII at a central location rather than having them fragmented across several projects. In theory, this reduces attack vectors:
a. Having projects store data to a central location, e.g. an existing database, and retrieving data needed to complete a request on-demand from that central locations.
b. Saving tokens and references to the beneficiary records stored at a central location with business data, rather than the entire PII of the beneficiary. Additionally, we advise that such a token should be project-specific, reducing its viability as a correlation handle.
c. If none of the above approaches can be taken, e.g as in the case of the OpenG2P search service which needs to maintain indexes, care, and data security measures should be instituted to protect against data breaches.
OpenG2P creates a framework for components to work together. The systems required by governments to register, verify, enumerate beneficiaries, send funds, verify funds received, and so on are often lacking in one or more areas and OpenG2P provides a framework for bounded components to share necessary information via secure tokens. Protecting privacy and securing data are key themes in the design of OpenG2P.

7. Does the project adhere to privacy and other applicable international and domestic laws?

Has this project taken steps to ensure adherence with relevant privacy, domestic, and international laws? For example, the General Data Protection Regulation (GDPR) in the European Union or the Supplementary Act A/SA.1/01/10 on Personal Data Protection for the Economic Community of West African States (ECOWAS) (yes/no)

Yes

If yes, please list some of relevant laws that the project complies with:

  • - OpenG2P components are flexible to be used within country specific privacy laws.
  • - The OpenG2P framework confers privacy, security, and consent as an inalienable right of every person regardless of their gender and economic situation. A key concept in our privacy approach is the requirement to only use information for the intended purpose and to prevent transmission of data to systems that are non-compliant with policies.
  • - The OpenG2P framework is conceptualized as supportive of Government transfer systems, and the organization of such transfer programs are at the behest of governmental agencies. We take approaches that are protective of security and privacy while remaining consistent with governmental policies.

If yes, please describe the steps this project has taken to ensure adherence (include links to terms of service, privacy policy, or other relevant documentation):

  • For users needing to store PII, e.g. Beneficiary Database follow a minimum set of data-handling conventions and procedures as per the Guiding Principles of OpenG2P:
  • a. Data should be encrypted at rest, advisably with a regularly rotating key scheme and these keys kept safely off system.
  • c. All-access should via strong authentication mechanism and permissioned; this also includes access to other OpenG2P projects.
  • d. Datastore should not be on a internet-facing network.
  • e. Tamper resistant logging of system access should be implemented across all potential routes of attacks
  • OpenG2P blocks by default not on externally-accessible networks. This default can be relaxed for the following situations:
  • a. Needs to communicate with systems of external parties, in which case we advise the use of VPNs and other secure end-to-end/point-to-point secure communication strategies.
  • b. Needs to be accessed by a wide variety of users, e.g. admin systems, in which case just interfaces should adopt industry-standard authentication strategies.
  • c. User authentication, authorization, and roles; for interfaces that users log into, e.g. beneficiary administration system, we advocate the following the minimum.
  • d. A system of authentication that factors, password strength, password expiration and rotation, and brute force protection. We also advocate for Two-factor authentication procedures where possible.
  • e. System of roles and authorization that provides the exact amount of rights a user needs to perform their tasks and nothing more.
  • f. Audited access with sessions and CRUD logs.

8. Does the project adhere to standards and best practices?

Does this project support standards? (i.e. Web Content Accessibility Guidelines (WCAG) 2.1 or other standards such as those listed on W3C)

Yes

Which standards does this project support (please list)

  • w3c verifiable credentials and others under explorations especially around handling of PII

Can you point to evidence of your support? (i.e. please link to your validator, open test suite, etc.)

  • Work in progress especially around compliance to open standards around handling and security of PII

Was this project built and developed according to or in adherence with any design, technical and/or sector best practices or principles? i.e. the Principles for Digital Development?

Yes

Which principles and best practices does this project support (please list)

  • Principles for Digital Development; the Responsible Digital Payments Guidelines by the Better Than Cash Alliance

9. Does the project do no harm by design?

Has this project taken steps to anticipate, prevent and do no harm by design?

On the whole, does this project take steps to ensure that it anticipates, prevents and does no harm by design?

Yes

Is there any additional information you would like to share about the mechanisms, processes or policies that this project uses to avoid doing harm by design?

1. Beneficiaries should be aware of and consent to how their data are used for a program’s interaction with external systems.
2. Inbound and outbound data flow with external systems should be via secured authentication and transport mechanisms. Such secured authentication and data transport should follow best practices in keeping with international norms and standards. Where network latency creates challenges for encrypted channels, data encryption alone may suffice as long as vulnerabilities are limited on the endpoints.
3. OpenG2P components individually and collectively obfuscate (e.g. encrypt) the data such that if it is hacked or taken out it is as good as unusable.
4. An OpenG2P project should evaluate its data requirement and assess how critical it is to store beneficiary PII. Preference is not storing data, making solutions stateless, however, if not a viable approach we advocate the following approaches, that prioritizes storing PII at a central location rather than having them fragmented across several projects. In theory, this reduces attack vectors.
5. A project absolutely needing to store PII, e.g. Beneficiary Database should follow a minimum set of data-handling conventions and procedures.

9.a. Data Privacy & Security

Does this project collect or store personally identifiable information (PII) data and/or content?

Yes

If yes - please list the types of data and/or content collected and/or stored by the project:

  • This is information that when used alone or with other relevant information can identify an individual or family of individuals:
  • foundational or functional IDs
  • collection of information related to geographic location, race, gender, age, that allows for a person to be uniquely identified
  • genomic typing and biometric information.
  • Sensitive Personally Identifiable Information - A subset of PII is data that is, by its nature or use, intended to be secret. This may vary with context and culture, but examples may include personal medical records, detailed financial records, and biometric and genomic data

If yes - does this project share this data and/or content with third parties?

Yes

Please describe the circumstances with which this project shares data and/or content with third parties. Please add links as relevant.

  • External Interactions - Relates to how OpenG2P building blocks consumes data from external sources using the information provided by the beneficiary and how those building blocks share beneficiary data with external parties. Examples include OpenG2P verifications service looking at demographic information from an external source using identity credentials supplied by beneficiaries and OpenG2P disbursement engine sharing beneficiary KYC information with account systems and payment providers.

If yes - does the project ensure the privacy, security and integrity of this data and/or content collection and has it taken steps to prevent adverse impacts resulting from its collection, storage and distribution.

Yes

If yes - please describe the steps, and include a link to the privacy policy and/or terms of service:

Limited Use - A key concept in our privacy approach is the requirement to only use information for the intended purpose and to prevent transmission of data to systems that are non-compliant with policies. Data retention policies must be implemented that are aligned with such usage parameters.

9.b. Inappropriate & Illegal Content

Does this project collect, store or distribute content?

No

If yes - what kinds of content does this project, collect, store or distribute? (i.e. childrens books)

Not Applicable

If yes - does this project have policies that describe what is considered innappropriate content? (i.e. child sexual abuse materials)

Not Applicable

If yes - please link to the relevant policy/guidelines/documentation.

Not Applicable

If yes - does this project have policies and processes for detecting and moderating innappropriate/illegal content?

Not Applicable

If yes - please describe the policies and processes for detecting, reporting and removing innapropriate/illegal content (Please include the average response time for assessment and/or action. Link to any policies or descriptions of how inappropriate content is handled):

Not Applicable

9.c. Protection from harassment

Does this project facilitate interactions with or between users or contributors?

Yes

If yes - does the project take steps to address the safety and security of underage users?

Not Applicable

If yes - please describe the steps this project takes to address risk or prevent access by underage users:

Not Applicable

If yes - does the project help users and contributors protect themselves against grief, abuse, and harassment?

Yes

If yes - please describe the steps taken to help users protect themselves.

Not Applicable

Development & deployment countries

List of countries this project was developed in.

  • Sierra Leone

List of countries this project is actively deployed in.

  • Sierra Leone