The specific security requirements of government payment platforms
Government-facing fintechs operate under a more complex compliance environment than pure commercial platforms. CBN licensing requirements apply for the payment processing function. NITDA security standards apply because government data is processed. Individual MDA contracts specify additional security requirements including audit log retention periods, data residency requirements (some MDAs require that government payment data be hosted on servers located in Nigeria), incident reporting timelines that are shorter than CBN's standard 24-hour window, and in some cases mandatory security assessments as a contract renewal condition.
The consequence of a security failure is also different in kind. A commercial fintech breach results in regulator notifications, fines, and customer churn. A government payment platform breach results in all of the above plus potential contract termination, debarment from future government contracts, and public scrutiny that goes beyond the financial services press. Government agencies that are victims of a breach in their payment platform may face their own audit consequences — creating a political dimension to the incident that pure commercial breaches do not have.
1. Remita payment reference and RRR validation
Remita uses a Remita Retrieval Reference (RRR) number to identify payment obligations. When a citizen or business generates an RRR to pay a government fee, the RRR encodes the paying entity, the amount, and the receiving agency. Platforms that accept Remita payment confirmation must validate the RRR against Remita's API to confirm: that the RRR was paid, the amount paid, and the agency that received the payment. We test whether the platform validates all three of these fields or only that the RRR shows a successful payment — a partial validation that allows an attacker to submit an RRR for a smaller payment or for a payment to a different agency and have it accepted as valid.
2. Revenue collection mandate manipulation
Revenue collection platforms issue payment mandates to taxpayers and fee-payers: pay this specific amount by this date to this account. We test the integrity of the mandate generation and validation process. Can a taxpayer modify the mandate amount before making payment? Can a successfully paid mandate be replayed to claim a second credit? Can a mandate generated for one tax obligation be used to satisfy a different obligation? Each of these failures represents either a revenue loss for the government agency or an incorrect compliance record for the payer.
3. Government employee salary data access control
Platforms that process government salary payments through Remita or GIFMIS hold complete employment and compensation records for civil servants. We test the authorization on salary data queries: can a government agency payroll administrator access salary records for a different agency? Can a lower-privileged user query salary data for employees above their grade level? Can salary disbursement history be accessed through the platform's API by an authenticated but unauthorized party?
4. GIFMIS integration authorization testing
The Government Integrated Financial Management Information System (GIFMIS) is used for federal budget management and supplier payment. Platforms that integrate with GIFMIS for supplier payment processing have access to federal budget line items, supplier payment schedules, and contract values. We test whether GIFMIS API credentials stored by the fintech platform are appropriately protected (encrypted, rotated regularly, access-logged), whether the integration scope is limited to the minimum necessary operations, and whether GIFMIS data returned through the integration is exposed only to authorized users within the platform.
5. E-receipt and payment confirmation forgery
Government payment platforms typically issue electronic receipts that citizens use as proof of payment for permits, licenses, tax clearance, and other compliance documents. We test whether these e-receipts can be forged — generated by a non-payment path through the system — and whether the receipt verification mechanism that government agencies use to validate submitted receipts is robust against forgery. A verifiable e-receipt system that can be bypassed allows citizens to present forged receipts for real government services without ever making the required payment.
Remita RRR validation checked payment status but not amount or agency
During a penetration test of a Nigerian state government revenue collection platform, we tested the payment confirmation flow. The platform verified submitted RRRs against Remita's API but only checked whether the RRR status was "paid" — it did not validate the payment amount or the receiving agency code against the expected values for the specific tax obligation being satisfied. We generated an RRR for a 1,500 naira levy (the minimum payable on the Remita test environment), submitted it as payment for a 750,000 naira business operating permit, and received a successful confirmation and e-receipt for the permit. The platform accepted any paid RRR for any obligation regardless of amount match. Fix priority: critical. Remediated by adding a three-field validation against Remita's API: status must be "paid", amount must match the mandate amount within the defined tolerance, and the agency code must match the receiving agency for the specific obligation being paid.
Operating a government payment, revenue collection, or Remita-integrated platform in Nigeria? Book a security assessment that satisfies government MDA contract security requirements.
Book a Government Fintech Security AuditFrequently asked questions
Do government-facing fintechs face different regulatory obligations than consumer fintechs?
Government-facing fintechs face overlapping obligations: CBN licensing requirements for payment processing, NITDA cybersecurity standards for platforms handling government data, FIRS requirements for platforms handling tax collection, and the security expectations of each government agency they serve. A data breach affecting government payment records triggers not just CBN and NDPC notification requirements, but also potential scrutiny from the relevant MDAs and potential contract termination.
What makes Remita integration a specific security target?
Remita is used by hundreds of Nigerian federal, state, and local government agencies for salary payment, revenue collection, and supplier payment. Remita integration APIs are accessed by a large number of merchant platforms and fintech applications. A Remita integration vulnerability in a merchant platform can expose government employee salary data, tax payment records, and government agency account balances to unauthorized parties.
What security certification do government-facing fintechs need in Nigeria?
Beyond CBN licensing, platforms handling government payments are expected to demonstrate compliance with NITDA's Nigerian Information Security Standard (NISS) and in many cases ISO 27001 certification. Some MDAs have their own vendor security questionnaires as part of the contract renewal process. We have supported platforms through NITDA NISS assessments and government vendor security questionnaire responses.
Related reading
Blog: Webhook security in payment platforms · CBN PSP licence requirements · Interswitch and GT Pay security
Services: Penetration testing · API security