BPDS
Ministry of ICT & National Guidance
Pay the right beneficiary, the right amount, once, and prove it.
BPDS is a beneficiary payment distribution platform for MDAs: verified registration, a double-entry entitlement ledger, disbursement over mobile money and bank rails, reconciliation, AML screening, and a tamper-evident audit trail.
Read live from this prototype's database. The caseload is synthetic.
The problem
Distributing payments to beneficiaries by hand is slow, hard to audit, and easy to get wrong.
- Manual, spreadsheet-driven distribution makes it hard to prove who was paid, when, and how much.
- Duplicate and ghost beneficiaries slip through when there is no single verified register.
- Reconciliation gaps mean released funds are not reliably matched back to entitlements.
- No tamper-evident trail, so disbursements cannot be audited end to end.
The solution
BPDS turns distribution into a controlled, reconcilable pipeline from register to receipt.
- One verified register per district with NIN and full location hierarchy.
- A double-entry entitlement ledger that keeps every outstanding balance reconcilable.
- Idempotent, batched disbursement over mobile money and bank rails with AML gating.
- An append-only audit trail behind role-based access, so every shilling is traceable.
Key modules
Each stage of a payment is a distinct, auditable module, from first intake to closed reconciliation.
Intake & Registration
Beneficiaries are captured or imported per district with National ID (NIN), full location hierarchy, entitlement details, and a bank or mobile-money destination. Every record enters a verification queue before any money can move.
Entitlement & Ledger
Each record carries a double-entry entitlement ledger: unit price, amount claimed, previous payments, total paid, and outstanding balance. Balances are always reconcilable against what has actually been disbursed.
Disbursement Rails
Approved payments are routed over two rails: mobile money through the WENDY / PostBank integration, and direct bank transfer using stored account details. Payments are batched, approved, then released.
Reconciliation
A reconciliation service matches released payments back to the ledger, updates outstanding balances, and flags mismatches (partial pays, failed transfers, duplicates) before a batch is closed.
AML & Compliance
Before release, batches pass anti-money-laundering checks: identity and destination screening, duplicate-account detection, and value-threshold monitoring. Flagged items are held for manual clearance.
Tamper-Evident Audit
Every state change, approval, and payment is written to an append-only audit trail with actor, timestamp, and before/after values, so any disbursement can be traced end to end.
How it measures up
Relevance, security, interoperability, usability, innovation, and the team behind it.
Government Relevance
Built for beneficiary payment distribution across any MDA scheme, not one programme. The intake, entitlement, disbursement and reconciliation model adapts to cash transfers, agricultural inputs, compensation schemes and grants by configuration rather than rewrite.
Security
Role-based access control (system admin, district CAO, data-entry officer, beneficiary), encryption in transit, a tamper-evident audit trail, Data Protection Act (DPPA) alignment, a double-entry ledger, and idempotent disbursement so no beneficiary is ever paid twice. AML screening gates every batch.
Interoperability & Scale
Integrates with WENDY / PostBank mobile-money and bank-transfer rails, is designed for NIRA NIN verification, and exposes typed APIs. Stateless app tier over PostgreSQL scales horizontally from a single district pilot to national caseloads.
Usability
WCAG-minded interface with keyboard skip-links, light and dark themes, and clear status language. Low-bandwidth friendly server rendering so district offices on constrained connections stay productive.
Innovation
A self-validation portal lets beneficiaries confirm their own data and reduce ghost and duplicate risk at source, combined with a live reconciliation loop that surfaces payment mismatches before a batch closes rather than after funds leave.
Team
Delivered by iVille / Information Village Limited: full-stack engineering, government-systems delivery, and payment-integration experience, with a documented workflow, test credentials, and public documentation for evaluators.
Standards & interoperability
Interoperability follows the Uganda National Digital Architecture (UNDA): every integration is exposed through a RESTful API, so accounting officers track the same beneficiary across systems.
Alignment with the UNDA
Aligned with the Uganda National Digital Architecture (UNDA), so BPDS fits into the wider Government digital ecosystem rather than standing alone.
NIRA NIN, IFMS & Payments Hub
Each disbursement binds to a verified NIRA National Identification Number, and reconciliation runs against the Ministry of Finance IFMS and the National Payments Hub.
PostBank, mobile-money & bank rails
Funds move over PostBank, WENDY mobile-money operators and bank-wire rails, so a new rail can be added without disturbing the money-movement core.
Multi-channel delivery
Delivered across web, mobile and USSD. Beneficiaries and field officers confirm status and payments over feature phones via mobile-money USSD, so low-bandwidth and rural access is covered without a smartphone.
Multi-channel: web, mobile, USSD
Delivered across web, mobile and a live USSD channel: a beneficiary on a feature phone can verify a payment and lodge a grievance over the USSD and mobile-money menu.
Security & compliance
Public money moved with core-banking rigour and compliant with the Uganda Data Protection and Privacy Act, 2019 (DPPA).
DPPA 2019 compliance
Compliant with the Uganda Data Protection and Privacy Act, 2019 (DPPA) in how beneficiary personal and payment data is collected, stored and accessed.
Tamper-evident audit logs
Tamper-evident audit logs of every user action and data access event, with actor, timestamp and before/after values.
Role-based access control
RBAC across system admin, district CAO, data-entry officer and beneficiary roles, so each user acts only within their permissions.
Encryption & tokenised data
Encryption at rest and in transit, with tokenised payment data so sensitive account details are never held in the clear.
Double-entry, no double-pay
A strict double-entry ledger with idempotent execution that cannot double-pay a beneficiary on retry.
AML watch-listing
Anti-money-laundering screening gates every batch, holding flagged items for manual clearance before release.
See it working
Sign in with the evaluator credentials, or read the full documentation covering workflow, security controls, and the technology stack.