OpenG2P is an open-source suite for government-to-person benefit delivery, covering beneficiary registries, programme management, enrolment and deduplication alongside payment components such as the account mapper (SPAR) and G2P Bridge. It spans the Registries and Payments domains, with the G2P Bridge explicitly designed as a standalone DPI building block.
All DPGs in the DPGs for DPI Collection are assessed by the DPGA Secretariat against the DPGs for DPI criteria v2.0. Assessments use publicly available documentation and link to their evidence below. Assessed September 2026.
3 partially met
Layer 1
Recognised DPG
Layer 2
DPI Relevance
Layer 3
DPI Architecture Alignment

Does it provide a foundational DPI function, reusable across sectors, at population scale?
It covers two DPI domains at once: beneficiary registries and management on the registries side, and SPAR and G2P Bridge on the payments side. The same transfer machinery serves social protection, agricultural subsidies, emergency relief and any other government payment, and it is built for national-scale delivery to millions of beneficiaries.
How the solution's architecture reflects the principles that distinguish DPI from conventional digitisation.
Can other systems connect without modifying the core, using documented open standards?
REST APIs are documented across the suite, including G2P Bridge, SPAR and the programme management interfaces. Interoperability follows the DCI standard and G2P Connect specifications, with JSON payloads and published schemas.
Is it a modular building block that does one thing well, rather than a monolithic platform?
PBMS, SPAR and G2P Bridge are independently deployable components, and the DPI pieces are clearly separated from the programme management layer. Countries configure the suite for their own social protection programmes without forking.
Can other public and private actors build on top of it?
The modular APIs, and G2P Bridge in particular, are designed for others to build on, and documented integrations include national ID systems such as MOSIP as well as banks and payment providers. The MPL-2.0 licence and a multi-contributor community mean it is not tied to one vendor.
Can it run in distributed or federated deployments suited to national infrastructure?
Deployments are self-hosted at national level, so beneficiary data stays in-country. Federation between country instances is not documented, and high-availability configurations are not prominently covered in the public documentation.
Does it meet the security and privacy bar for population-scale infrastructure?
The system handles sensitive beneficiary data with access controls and encryption, and is designed for privacy-sensitive handling of information about vulnerable populations. No clearly published vulnerability disclosure policy was found.
Criteria: DPGs for DPI Collection criteria v2.0 · Co-stewarded by CDPI, Co-Develop and the DPGA Secretariat.
Spot something out of date? Contact the DPGA