Government Payments Should Work Both Ways

Bill-first is only one direction of the relationship

A bill-first government-payment design solves an important public-finance problem. Before money moves, the system identifies the tax, license, customs charge, service fee, or other lawful obligation being discharged. The citizen or business can verify what is owed, and the treasury can reconcile the payment to its purpose and destination.

That is the inbound direction: person-to-government or business-to-government. A complete public payment capability must also serve the outbound direction, where government pays a salary, pension, social benefit, grant, scholarship, tax refund, supplier refund, emergency transfer, or other lawful entitlement.

The outbound flow should not be implemented as a negative bill or a reversed collection. The legal basis, initiating authority, risk, privacy exposure, liquidity model, exception handling, and recipient protections are different.

The two directions belong in one government-payment architecture because they can reuse trust, addressing, provider reach, treasury controls, status semantics, and evidence. They should remain distinct products because an obligation owed to government is not the same thing as an entitlement owed by government.

Operating principleOne public payment capability can support both directions without pretending they are the same transaction.

The idea in one minute

A ministry decides that a person is entitled to a payment. The citizen has already selected a bank account, mobile-money wallet, or other regulated transaction account. A shared government-payment service verifies the instruction, resolves the chosen destination, and sends the credit through the national payment system.

The receiving provider credits the citizen. A final status travels back to the government program and treasury so they can reconcile public money. If the account is invalid, closed, or unavailable, the payment enters a visible exception process instead of disappearing into a spreadsheet.

This is not one government wallet and it is not one provider receiving every public contract. It is shared infrastructure that lets many public programs pay through many regulated providers using one governed method.

Operating principleOne connection for government; many account choices for citizens; one traceable outcome for every payment.

What citizen-linked should mean

Citizen-linked payments should mean that an authorized public program can resolve the correct recipient and produce durable evidence that the intended person received the intended value. It should not mean that the payment switch stores a complete citizen profile or can browse a national identity database.

The identity system is authoritative for identity proofing and narrowly defined assertions. The program system is authoritative for eligibility and entitlement. The treasury is authoritative for release of public funds. The payment system is authoritative for routing, transaction status, finality, and settlement. The receiving provider is authoritative for the destination account and customer relationship.

Those authorities can cooperate through purpose-bound identifiers, tokens, signed assertions, or verified payment aliases. The payment instruction needs enough information to prevent misdirection, duplicates, and fraud; it does not need the recipient’s unrelated health, education, family, biometric, or social-history data.

A citizen link must also survive correction. Names change, accounts close, identifiers are mistyped, eligibility decisions are appealed, and people may lack documents. The design needs update, exception, and grievance paths rather than treating one database match as permanent truth.

Operating principleLink the payment to an accountable identity decision, not every system to every fact about the person.

• Verify a recipient for a declared payment purpose.
• Share the minimum attributes required for that purpose.
• Keep eligibility data outside the payment rail.
• Tokenize or sectorize identifiers where practical.
• Record which authority asserted what and when.
• Provide correction, appeal, and assisted-service routes.

The outbound object is an entitlement instruction

The G2P equivalent of a bill should be an explicit entitlement or disbursement instruction. It states which authorized program owes value, the legal or administrative basis, the recipient reference, amount, currency, allowed payment window, funding source, and permitted destination rules.

The instruction needs its own lifecycle: drafted, approved, funded, recipient-resolved, submitted, accepted, completed, failed, returned, suspended, or cancelled where cancellation remains legally possible. Bulk programs may group instructions into a payroll or benefit cycle, but each person’s outcome must remain independently traceable.

Eligibility and payment are separate decisions. A social-protection system may determine that a household is eligible, but treasury authorization is still required before public funds move. A completed payment proves delivery; it does not retroactively prove that the eligibility decision was correct.

Idempotency must exist at both levels. The program must not issue the same entitlement twice, and the payment rail must not move the same approved instruction twice when a request, callback, file, or status response is retried.

• Program and legal basis.
• Recipient reference and resolution evidence.
• Benefit period or payroll cycle.
• Amount, currency, funding source, and treasury authority.
• Chosen or permitted payment destination.
• Independent payment, return, and reconciliation state.

A layered DPI architecture keeps authority visible

A sound architecture does not collapse the social registry, national identity service, treasury, government-payment platform, instant-payment rail, and provider ledger into one application. Each system holds a different public mandate and should expose only the capability the next layer needs.

The program or beneficiary-management system determines eligibility and creates a proposed entitlement. The identity service verifies the person or supplies a purpose-bound assertion. A government-payment orchestrator validates program authority, treasury funding, duplicates, and payment policy before creating a rail-ready instruction.

The national payment rail resolves an eligible destination, routes the instruction to the selected provider, and returns standardized status and finality. The provider credits the account or approved instrument and supports the recipient’s access, notifications, statements, and first-line recourse.

Evidence then travels back through the same institutional chain. Payment completion updates disbursement and treasury reconciliation, while personal transaction detail remains limited to authorized roles and retention periods.

Operating principleDPI works through composable authority, not one national database with every power.

• Program layer: eligibility, entitlement, and case management.
• Identity layer: proofing and minimum-purpose assertions.
• Treasury layer: appropriation, funding, approval, and accounting.
• Government-payment layer: orchestration, controls, lifecycle, and evidence.
• Payment rail: addressing, routing, finality, settlement, and status.
• Provider layer: account, value delivery, access, and customer service.

The citizen shares one thing: where to be paid

Before an entitlement can be paid, the citizen normally supplies a payment destination during program enrollment, through a secure self-service channel, or with an authorized case worker. Depending on the market, that destination may be a bank account, mobile-money wallet, regulated payment account, or a verified alias that the national rail can resolve.

The government program should collect only the routing information needed to deliver the payment. It should never ask for the citizen’s PIN, password, one-time code, card secret, or online-banking credentials. Those remain exclusively between the citizen and the regulated provider.

The destination should be validated before use. Basic validation confirms that the provider and account format exist; stronger validation confirms that the destination is active and belongs to—or is lawfully controlled by—the intended recipient. The response can be a match result or payment token rather than a copy of the provider’s customer record.

A shared account directory can map the program’s recipient identifier to the citizen’s preferred destination. This is a recognized building block in the World Bank’s modern G2P architecture: programs do not each need to maintain separate bank and wallet lists, and citizens can update one preferred account for multiple payment streams.

The directory should store an encrypted account coordinate or token together with the provider, verification method, verification time, consent or lawful basis, and program scope. It does not need the citizen’s balance, transaction history, credentials, or unrelated account information.

Operating principleThe citizen shares where public value should be delivered—not access to the account itself.

• Citizen chooses an eligible bank, wallet, or payment account.
• Program captures the account coordinate or resolvable alias.
• Provider or payment rail validates reachability and recipient match.
• Government stores the minimum encrypted coordinate or token.
• Every change is reverified, audited, and notified to the citizen.
• Old destinations are retired without erasing prior payment evidence.

What a national switch operator can actually deliver

This proposition is realistic for a national switch operator that already connects regulated providers and routes account-to-account payments. The new work is a governed G2P product around the rail, not a replacement of the rail and not a new social-protection database.

The operator can provide one secure gateway through which approved public programs submit payment instructions. It can operate or integrate an account directory, validate whether the chosen destination is reachable, route credits across connected providers, standardize status and return reasons, and give treasury and program teams a complete reconciliation trail.

It can also define the technical scheme: participant obligations, message profiles, timeouts, duplicate protection, return handling, service levels, certification cases, operational escalation, and reporting. That is how the same product can work across banks and mobile-money providers instead of becoming another set of bilateral integrations.

The operator cannot decide who deserves a benefit, certify a civil identity, approve public expenditure, or open and manage the recipient’s account. Those responsibilities remain with the program, identity authority, treasury, and regulated provider. Keeping those boundaries clear makes delivery more credible, not less ambitious.

Operating principleThe switch operator owns reliable delivery across the market—not eligibility, identity, budget, or the citizen’s account.

• Shared G2P initiation API and controlled bulk-payment submission.
• Recipient-to-account directory or integration with an approved mapper.
• Account reachability and recipient-match validation.
• Routing to every certified bank and mobile-money participant.
• Idempotency, status, returns, exception queues, and replay-safe recovery.
• Treasury reconciliation, program reporting, audit, and operational dashboards.
• Participant rulebook, conformance testing, certification, and support.

Recipient choice is part of the architecture

A national G2P capability should route to an eligible account or wallet chosen by the recipient wherever regulation and program design permit. Government should not make access to a pension, wage, refund, or safety-net payment depend on becoming captive to one provider.

Provider-neutral delivery improves reach and resilience. Banks, mobile-money operators, regulated fintechs, cooperatives, and assisted cash-out channels can serve different communities while the public program uses one governed payment contract.

Choice must be practical rather than ceremonial. The system needs reliable account or alias validation, transparent charges, accessible cash-out, language support, protection for shared devices, and a safe way to register or change destinations.

Changing the destination is a high-risk event because an attacker or corrupt insider could redirect future benefits. The platform should require renewed verification, stronger authorization where proportionate, independent audit evidence, and immediate notification through an already trusted channel. A suspicious change can be held for review without cancelling the underlying entitlement.

Some recipients will not have a usable digital account or sufficient connectivity. Assisted enrollment, limited-purpose instruments, offline or agent-supported access, and controlled fallback delivery must exist without marking those citizens as failures.

Operating principleGovernment should know that value reached the right person; it should not choose the person’s financial provider for them.

Treasury control must precede payment speed

Instant rails can deliver a public payment quickly, but they cannot decide whether the expenditure is lawful. Budget authority, appropriation, program approval, segregation of duties, funding availability, and release controls remain treasury responsibilities.

A G2P orchestrator should bind every disbursement to an authorized funding source and approval context. High-risk or exceptional batches may require multiple approvals, while routine programs can use pre-authorized limits and policy controls.

The system must separate batch approval from transaction completion. A batch may be authorized while individual recipients fail resolution, reject credit, or receive funds later. Accounting cannot post the entire batch as delivered merely because a file was accepted.

Liquidity planning also changes when government uses an instant rail at scale. Operators and settlement institutions need controlled release windows, volume visibility, position monitoring, and a recovery plan that preserves the entitlement when a provider or rail is unavailable.

Status and reconciliation close the public-accountability loop

For inbound collections, reconciliation asks which obligation was discharged and where revenue was posted. For outbound payments, it asks which entitlement was authorized, which destination was resolved, whether value became final, and what happened to every failed or returned instruction.

Submitted is not paid. File accepted is not credited. Callback missing is not necessarily failed. The government-payment platform needs a status model that distinguishes transport, rail acceptance, provider acceptance, final credit, return, and unresolved outcomes.

Every transition should preserve transaction identity, entitlement identity, program, treasury authority, participant, time, reason, and correlation evidence. Aggregate totals are important, but they must reconcile back to person-level instructions under appropriate access control.

A returned or failed payment should reopen delivery work without silently reopening eligibility. Operations may need to correct a destination and resubmit the same authorized entitlement, while policy teams separately handle disputes about whether the person was entitled at all.

Operating principlePublic funds are accounted for only when every instruction has a financially and administratively explainable outcome.

Safeguards must cover exclusion as well as fraud

Government-payment security often begins with preventing ghost recipients, duplicate payroll, account substitution, insider manipulation, and fraudulent claims. Those controls are necessary, but a system can reduce one kind of leakage while creating another: lawful recipients excluded by missing documents, bad data, inaccessible authentication, distant agents, or an unavailable provider.

Identity verification should be proportionate to risk and supported by lawful alternatives. Biometrics can assist some journeys but should not become the only route to food support, emergency aid, pensions, or wages. Failed matching must lead to review rather than automatic deprivation.

Recipients need notice of the amount, program, timing, destination, charges, and status. They need a grievance route that can correct identity and payment data, trace missing value across institutions, and provide interim assistance where delay threatens essential needs.

Privacy controls must include purpose limitation, minimum necessary data, encryption, tokenization, role separation, query auditing, retention limits, breach response, and independent oversight. Transaction data must not quietly become a universal instrument for profiling citizens.

• No single credential, device, biometric, or provider as the only path.
• Accessible notification and assisted support.
• Clear responsibility across program, payment operator, and provider.
• Time-bound investigation and emergency fallback.
• Correction rights for identity, eligibility, and payment coordinates.
• Independent oversight of data use and complaints.

Why this is a high-value DPI use case for Africa

African instant-payment systems gain public value when they support more than person-to-person transfers. AfricaNenda’s 2025 research presents G2P as a major opportunity for inclusive instant-payment systems and models multiple public programs using a shared gateway to reach multiple providers.

The same provider-neutral rail can collect a verified public obligation and deliver a verified public entitlement. Governments avoid separate bilateral integrations for every bank, mobile-money operator, program, ministry, and aid partner, while citizens retain choice among regulated providers.

This is especially valuable where social transfers, humanitarian assistance, public payroll, pensions, agricultural support, scholarships, tax refunds, and emergency response must reach geographically dispersed populations. The architecture can scale across programs without placing every program’s sensitive data inside the payment system.

Regional learning matters, but each country must establish its own legal authority, identity coverage, data-protection safeguards, treasury model, payment participation rules, and fallback channels. DPI is reusable infrastructure, not a template that erases local institutions.

Operating principleThe opportunity is not merely to digitize government cash flow; it is to make public value reachable, explainable, and contestable.

A delivery path that can start small

The first release should not attempt every ministry, every benefit, and every exceptional case. A credible pilot starts with one lawful payment stream, one treasury funding path, a limited group of recipients who already have accounts, and a small set of certified providers that together represent meaningful reach.

Phase one proves the core loop: submit an approved instruction, validate the destination, prevent duplicates, route the credit, receive final status, reconcile the funding account, and resolve failures. Success is measured by completed payments, time to credit, failed and returned payments, reconciliation breaks, recipient cost, complaints, and time to resolution—not by API traffic alone.

Phase two adds the shared account directory, safe self-service account changes, more providers, assisted enrollment, and coordinated grievance handling. Phase three brings additional programs onto the same gateway and prepares controlled emergency scaling.

Before production, the institutions need an approved scheme rulebook, lawful data-sharing basis, treasury and settlement design, participant certification, consumer-protection ownership, security assessment, support model, and tested fallback procedures. Software alone cannot supply those agreements.

Operating principleDeliver the smallest complete public-payment promise, then scale the same governed contract.

• Pilot one payment stream with real treasury reconciliation.
• Certify a representative bank and mobile-money provider set.
• Prove account validation, final status, returns, and complaint handling.
• Add recipient choice and directory changes under strong controls.
• Expand program by program after operational evidence is stable.

The bidirectional public payment contract

The mature design is not a government super-wallet and not a national citizen ledger. It is a set of governed contracts through which authorized institutions can request identity assertions, create obligations or entitlements, move value through interoperable providers, and receive trustworthy evidence.

Inbound and outbound products can share participant connectivity, security, transaction identifiers, status semantics, notification patterns, reconciliation infrastructure, reporting, and operational oversight. They retain separate lifecycle rules, funding authority, liability, privacy constraints, and recourse.

That boundary connects bill-first collection principles to a wider DPI vision without asserting that both directions already exist in one implementation. A citizen should be able to see why government is requesting money, verify and discharge the obligation through a chosen provider, and later receive a lawful payment through an equally clear and accountable path.

When both directions work, government payments stop being isolated collection and payroll projects. They become a national capability for trustworthy economic interaction between the state and the people it serves.

Operating principleThe state–citizen payment relationship should be bidirectional, provider-neutral, purpose-bound, and accountable in every transaction.