OpenG2P

Multiple Domains

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.

Beneficiary registry
G2P cash transfers
payment account mapper (SPAR)
disbursement bridge
program management
enrollment

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.

15 of 18 checks met

3 partially met

Layer 1

Recognised DPG

Layer 2

DPI Relevance

Layer 1 Recognised Digital Public Good

Listed in the DPG Registry.
VerifiedVerified DPG logo

Layer 2 DPI Relevance

Does it provide a foundational DPI function, reusable across sectors, at population scale?

Domain fit
Cross-sector reuse
Population scale
3/3

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.

Layer 3 DPI Architecture Alignment

How the solution's architecture reflects the principles that distinguish DPI from conventional digitisation.

A · Interoperability

3/3

Can other systems connect without modifying the core, using documented open standards?

External API docs
Open standards
Open data formats

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.

B · Minimalist & Reusable Design

3/3

Is it a modular building block that does one thing well, rather than a monolithic platform?

Modular architecture
Core/app separation
Config-driven adaptability

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.

C · Ecosystem Enablement

3/3

Can other public and private actors build on top of it?

Third-party buildability
External integrations
No vendor lock-in

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.

D · Federation Readiness

1/3

Can it run in distributed or federated deployments suited to national infrastructure?

Federated deployment · Partially meets
Data sovereignty
High availability · Partially meets

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.

E · Security & Privacy at Scale

2/3

Does it meet the security and privacy bar for population-scale infrastructure?

Infrastructure-grade security
Vulnerability disclosure · Partially meets
Privacy by design

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