Elsewhere, compliance may sit beside a technical design. In Africa, it often determines the design itself. When we built enza's first processing infrastructure, these requirements shaped the data model, logging architecture, and settlement flow from day one. This article examines what African banking compliance teams enforce and how those rules become engineering decisions.
The emphasis is on Nigeria and Ghana, where we have the deepest operational experience, with observations on wider sub-Saharan banking regulation.
Central Bank of Nigeria Rules
The CBN's Framework for Regulatory Sandbox Operations and wider card payment directives set infrastructure requirements that processors must address.
Data localization: Card transaction data from Nigerian banks must remain stored within Nigeria. This goes beyond a data protection recommendation. The CBN has enforced the requirement against processors keeping Nigerian transaction data only on international infrastructure. A payments API therefore needs Nigerian processing endpoints locally or a compliant data-mirroring setup with a locally licensed partner.
Domestic scheme support: Cards from CBN-licensed banks must support Verve alongside any international scheme. Nigerian customers cannot receive Visa-only cards. The Verve BIN must be co-badged or available as fallback. Infrastructure serving Nigerian bank card programs must therefore provide Verve connectivity as a baseline, not an option.
Transaction reporting: For anti-money laundering purposes, the CBN requires periodic transaction reports for the Nigerian Financial Intelligence Unit (NFIU). The format is prescribed. Providers processing for Nigerian banks must generate compliant reports or supply the data feeds their bank's AML team needs.
Step-up authentication: CBN consumer protection guidance requires step-up authentication on card-not-present transactions above specified value thresholds. Those thresholds change periodically. Infrastructure therefore needs configurable 3DS triggers that can be changed with regulatory thresholds, without a code deployment.
Bank of Ghana Rules
The BoG's Payment Systems and Services Act 2019 and later directives define Ghana's payment infrastructure framework. Infrastructure providers must address:
GhIPSS connectivity: Banks and payment service providers in Ghana must connect to the GhIPSS interbank switch for domestic transactions. Institutions settling through the Ghanaian banking system cannot opt out. Ghana-market infrastructure must support GhIPSS alongside international scheme connections.
Transaction monitoring requirements: BoG requires payment service providers to operate transaction monitoring and report suspicious activity under Anti-Money Laundering Act requirements. Controls cover velocity, geographic anomalies, and merchant-level transaction patterns. These controls substantially overlap with fraud detection rather than standing apart from it.
Settlement finality timelines: BoG sets maximum settlement periods by payment instrument. Most card payment categories through GhIPSS must settle within T+1. Infrastructure must complete reconciliation and settlement confirmation workflows within those limits.
PCI DSS Across African Banking
PCI DSS compliance, currently version 4.0, applies to entities storing, processing, or transmitting card data. It is a Visa and Mastercard scheme requirement, not an African central-bank rule, although many regulators cite PCI DSS adherence in payment infrastructure licensing conditions.
African banks and fintechs using a third-party processor such as enza need to establish which PCI DSS duties stay with the bank and which move to the processor. Proper tokenization can sharply reduce the bank's PCI scope. If the bank handles only tokens and authorization responses, not raw card data, its scope covers the API channel and token storage. The processor retains the card-data handling scope.
This matters because PCI DSS assessments are costly and demand substantial IT and documentation work. Banks using our API can give their QSA (Qualified Security Assessor) a reduced-scope attestation, shortening assessment and lowering compliance overhead.
AML Infrastructure Needs
Anti-money laundering compliance for African payment infrastructure providers requires:
- Transaction monitoring with configurable rules for velocity, amount, and geographic patterns
- Suspicious Activity Report (SAR) generation and reporting workflows to the relevant Financial Intelligence Unit
- Customer due diligence (CDD) data linkage: each transaction must be traceable back to a verified customer identity
- Sanctions screening for international transactions: cross-border payments must check counterparties against OFAC, UN, and applicable local sanctions lists
The core infrastructure requirement is a complete audit trail. Log every transaction event, including authorization, clearing, settlement, decline, reversal, and dispute, with timestamps and immutable records. Regulators check log completeness. Missing records for any transaction subset are a compliance finding, regardless of cause.
The Real Cost of Compliance
African banks and fintechs often underestimate the compliance workload when scoping a card infrastructure project. Teams without prior CBN examination or GhIPSS audit experience may miss required logging detail, report formats, and retention rules until they encounter them. Those omissions then require costly engineering retrofits, frequently under a compliance deadline.
Early-access discussions with engineering teams highlight recurring issues: logs missing scheme response codes and timing data needed for regulatory reports; reconciliation based only on amount, which breaks when refunds or reversals produce a net-zero entry; and sandboxes that omit compliance edge cases such as partial settlement, failed settlement, and disputed transactions found in production.
What enza's Infrastructure Supports
Nigerian and Ghanaian regulatory requirements were baseline inputs for our processing infrastructure. Its data residency design supports CBN-compliant transaction storage. The API supplies timestamped transaction event logs for AML reporting workflows. Settlement confirmation data contains the timestamps and reference numbers needed for regulatory transaction reporting.
enza does not remove your compliance duties. Your institution remains the licensed party accountable to its regulator. Our infrastructure lowers the engineering workload by providing CBN-audit-ready transaction log storage, reconciliation that handles GhIPSS settlement timing, and an AML transaction monitoring data feed without requiring each capability to be built from scratch.
African compliance rules continue to change. The CBN and BoG issue updated guidance periodically, while several other African banking regulators are developing comparable frameworks. Incorporating compliance into infrastructure from the outset costs materially less than retrofitting it later, so it was a required design principle for enza.