Getting G2P Payments Right: Where Every DPI Pillar Meets

Government-to-person (G2P) payments are how a state puts money into people's hands: social transfers, pensions, subsidies, emergency relief, stipends and public-sector wages. They are also the most demanding everyday use of digital public infrastructure. A single transfer has to find the right person, confirm they are eligible, move money cheaply and instantly, and end somewhere the recipient can actually use it.

When all of that works, a programme can pay millions of people in a day, with less leakage and more dignity than queues and cash envelopes. When it does not, the failure is rarely in one system. It is almost always at the joins between them.

One payment, every pillar

Follow a single transfer and you touch each pillar of DPI in turn:

1. The programme registry holds the list of intended beneficiaries and the rules for who qualifies.
2. Identity and data exchange confirm that each beneficiary is a real, unique person and still eligible, by checking the national ID and asking other registries directly, with consent, instead of asking people to bring paper.
3. The paying agency issues one bulk instruction and funds it.
4. The instant payment system routes each payment to the account the beneficiary chose, often addressed by phone number or ID rather than an account number.
5. Banks, mobile wallets and SACCOs credit the account, and agents turn it into cash where people still need cash.
6. Status flows back to the programme, so every payment is reconciled and every failure can be followed up.

Take any one of these away and the programme falls back to manual work: spreadsheets of account numbers, duplicate beneficiaries, and people travelling to collect money that was sent to the wrong place.

Design choices that decide the outcome

Pay into the account people choose

Many programmes start with a single contracted payment provider. It is simple to procure, but it locks every beneficiary into one bank or wallet, often one they would not have chosen and cannot use nearby. Paying over an interoperable instant payment system lets the recipient pick the institution, and lets providers compete on service instead of on the contract.

Address people, not accounts

Account numbers change, get mistyped, and exclude people who do not have one yet. An alias directory on the payment rail lets a programme pay to a verified phone number or ID, and the rail resolves it to the right account. The same alias keeps working if the person changes provider.

Make identity do the de-duplication

Duplicate and ghost beneficiaries are one of the biggest sources of leakage. A foundational ID system that de-duplicates people, and lets the programme verify them remotely, removes the problem at the root rather than in an annual audit.

Treat the last mile as part of the system

A payment that arrives in a wallet but cannot be cashed out, because the nearest agent has run out of liquidity, has not really arrived. Agent networks, their liquidity and their fees need to be planned with the payment schedule, not discovered after the first payment day.

Close the loop

Every payment should return a status: credited, failed, reversed. Without it, programmes cannot reconcile, cannot tell a family whether the money was sent, and cannot fix the failures before the next cycle. Grievance channels depend on this data too.

Screen without slowing down

Public money attracts fraud, and instant payments leave little time to catch it. Screening has to run in real time alongside the rail, flagging suspicious patterns such as many payments converging on one account, without holding up legitimate transfers to the people who depend on them.

Where programmes stumble

The most common failures we see discussed across the sector are not exotic:

• Closed loops. A single-provider contract that makes it hard to move beneficiaries later.
• Accounts that exist only on paper. Accounts opened in bulk for recipients who never activate or use them.
• No feedback. Payments sent into the void, with no status and no way for a beneficiary to complain.
• Last-mile surprises. Agents without cash on payment day, or fees that quietly eat the transfer.

Each of these is a design decision, not a technical accident. They can be avoided if the payment rail, identity, data exchange and the last mile are designed together, from the start.

How we think about it

At Jengacore we start from the payment rail, because that is where the money actually moves and where our experience is deepest. An inclusive instant payment system, built on open standards such as Mojaloop and ISO 20022, gives a G2P programme choice, alias-based addressing and real-time status. Real-time screening, such as our Mulisa platform, protects it without getting in the way. Identity and data exchange are designed to connect to it cleanly, so that the whole chain behaves as one system.

If you are designing or reforming a G2P programme, we would be glad to talk it through.