PCI DSS v4.0 Is in Force. The Integration Layer Is Where African Banks Are Exposed.

PCI DSS v4.0.1 has been in full effect since 1 April 2025. For any African bank that processes, transmits, or stores Visa, Mastercard, or card-scheme payment data (which is most of them): that is not a future obligation. It is a current one.

The previous version of the standard, PCI DSS 3.2.1, was retired on 31 March 2024. Organisations still running assessments against it are not in compliance. The transition was not abrupt. The standard was published in 2022 and phased in over three years. But the number of African banking institutions that have completed a formal PCI DSS v4.0 gap assessment remains low relative to the exposure.

The most significant change in PCI DSS v4.0 for African banks is not the new requirements themselves. It is what the standard now explicitly addresses for the first time: APIs and integration controls. For a sector built on multi-system, multi-market connectivity, that addition changes the compliance picture significantly.

What changed in PCI DSS v4.0

PCI DSS v4.0 introduced a set of requirements that directly affect how the integration layer must be designed, documented, and governed. Five are of particular relevance to African banking institutions:

Why this matters for African banks specifically

An African bank operating across five markets may have five separate core banking environments, multiple payment switch connections, regional card scheme integrations, and hundreds of internal API calls that were never formally inventoried. PCI DSS v4.0 Requirement 6.3.2 requires that inventory to exist. The integration layer is where most of those undocumented connections live.

The Cardholder Data Environment and why the integration layer defines its boundary

PCI DSS compliance is scoped to the Cardholder Data Environment (CDE): every system, network segment, and integration that stores, processes, transmits, or affects the security of cardholder data. The scope of the CDE determines the scope of the compliance programme.

In a modern African bank, the integration layer defines the boundary of the CDE. It is the layer that receives payment transaction events from origination channels. It is the layer that routes those events to fraud engines, payment switches, core banking systems, and card scheme connections. Every API call in that orchestration chain that carries a Primary Account Number (PAN), a CVV, or any element of cardholder data is in scope.

The integration architecture determines how large that scope is. A poorly designed integration layer (one where cardholder data passes through multiple systems unnecessarily, where tokenisation happens late in the flow, or where the integration middleware stores data it should only be routing) expands the CDE and with it the compliance burden.

A well-designed integration layer does the opposite. It tokenises cardholder data as early in the flow as possible, so that downstream systems receive tokens rather than PANs. It routes data through the minimum number of systems. It uses the integration layer as the boundary at which PCI DSS controls are enforced, rather than requiring every downstream system to be independently compliant.

The four integration controls PCI DSS v4.0 requires

Four categories of control are required at the integration layer for PCI DSS v4.0 compliance. Each has a direct implementation pattern in a well-governed integration platform:

Strong authentication on every API connection. OAuth 2.0 with client credentials for machine-to-machine API calls. Mutual TLS (mTLS) for high-assurance connections to payment switches and card schemes. API keys are insufficient as a standalone control for any connection that carries cardholder data. Access tokens must be short-lived and rotated. Service accounts used by integration flows must be governed, not shared.

Encryption of cardholder data in transit. TLS 1.2 minimum on every API connection that touches the CDE. TLS 1.3 for new implementations. Encryption must be enforced at the integration layer, not assumed from the network. A payment event transmitted in plaintext across an internal API call is a PCI DSS violation, regardless of whether the network is considered trusted.

Tokenisation at the point of entry. PAN data should be tokenised by the integration layer at the earliest possible point in the flow, ideally at the channel API or payment gateway System API. Downstream Process APIs and System APIs should receive tokens, not PANs. This reduces the number of systems in CDE scope and limits the blast radius of any integration failure.

A complete and current API inventory. PCI DSS v4.0 Requirement 6.3.2 requires an inventory of all custom software and third-party components in the integration estate. For African banks, this means every API in the Anypoint, Boomi, or Workato environment must be documented: what data it carries, which systems it connects, and whether it is in CDE scope. An undocumented API that handles cardholder data is both a compliance gap and a security exposure.

The failure pattern that auditors find most often

Across PCI DSS assessments in financial services, one failure pattern appears more consistently than any other: the integration layer was designed for connectivity, not compliance. The APIs were built to move data. No one asked whether that data included cardholder information. No one mapped the CDE boundary through the integration estate. No one documented what the integration middleware stored in transit logs.

The result is an integration estate where cardholder data is present in more places than it should be, where encryption is applied inconsistently, where service accounts used by integration flows have not been rotated in years, and where the API inventory required by PCI DSS v4.0 Requirement 6.3.2 does not exist.

The scale of the exposure

60% of financial services organisations reported an API-related data breach in the previous two years, according to research cited by Salt Security (2024). In 2023, nearly 70% of financial services companies experienced deployment delays due to API security issues. For African banks that have not completed a PCI DSS v4.0 gap assessment, the probability that the integration layer carries compliance gaps is high.

The fix is architectural, not procedural. Adding security reviews to the release process does not resolve integration flows that were built without security controls. Documenting a service account policy does not rotate the credentials that have been static for three years. The remediation requires a structured review of the integration estate against the PCI DSS v4.0 requirements, followed by targeted remediation of the gaps.

What a compliant integration layer looks like

The architecture of a PCI DSS v4.0 compliant integration layer in an African bank has five consistent properties:

CDE boundary is defined at the integration layer. Every API that carries cardholder data is identified, documented, and scoped. APIs that do not carry cardholder data are explicitly excluded from CDE scope with documented evidence.

Tokenisation is applied at entry. PAN data is tokenised before it enters the Process API layer. Downstream systems receive tokens. The integration layer owns the tokenisation function and the vault connectivity.

All CDE API connections use TLS 1.2 minimum. Enforced at the API gateway layer, not assumed from the network. New connections use TLS 1.3. Cipher suite configurations are reviewed at each annual assessment.

Service accounts are governed. Every service account used by an integration flow is registered, has a defined owner, has credentials rotated on a schedule, and has access scoped to the minimum required. Shared service accounts are not used.

The API inventory is maintained. Every API in the integration estate is documented in a register: data classification, CDE scope determination, owner, last security review date, and third-party component versions. The register is updated as part of the change management process.

The window that is closing

PCI DSS v4.0.1 is in force. The transition period is over. African banks that have not completed a gap assessment against the new requirements are carrying compliance risk today, not in a future audit cycle.

The integration layer is where the most significant gaps are most likely to be. Not because African banks have been negligent. Because the integration layer was built to solve connectivity problems, and PCI DSS v4.0 is the first version of the standard to explicitly require that it also solve security problems.

The architectural decisions that bring the integration layer into compliance are the same decisions that make it more resilient, more observable, and easier to extend. A tokenisation capability built for PCI DSS compliance is also a tokenisation capability that protects against data breaches. An API inventory built for Requirement 6.3.2 is also the documentation that a development team needs to understand what they are building on.