The API Security Gap African Banks Are Leaving Open — Level Up

Across the 30 largest banks in Africa, digital transformation programmes share a common architectural assumption: that security lives at the application layer. The mobile app is hardened. The web portal has MFA. The customer identity platform is compliant with local regulation. The audit report is clean.

The integration layer, the layer that connects the mobile app to the core, the web portal to the payment rail, the customer identity platform to the credit bureau, is treated as infrastructure. Trusted by default. Rarely audited.

It is also, in almost every case, where the security model actually breaks.

The problem open banking made visible

Open banking regulation across Africa, Nigeria's Open Banking Framework, South Africa's evolving API standards, and the Central Bank of Kenya's draft open banking framework, is doing something unintended: it is forcing African banks to document and expose their API estate. For many, it is the first time the integration layer has been mapped end to end.

What that mapping reveals is consistent. APIs built over five to fifteen years, under different teams, with different security assumptions. Some use OAuth 2.0. Some use API keys embedded in headers. Some use Basic Auth over HTTPS. A small number use mutual TLS. Many use a combination that was never designed as a coherent model. It accumulated.

What the data shows

The OWASP API Security Top 10 (2023) identifies Broken Authentication as the second most prevalent API vulnerability globally.¹ In financial services, where API connectivity between core banking, payment rails, and third-party services is dense, the integration layer is where Broken Authentication most commonly appears, because it is the layer with the most API connections and the least centralised enforcement.

The consequence is not primarily a compliance risk. It is a business risk. An unauthenticated or weakly authenticated internal API call can extract customer data, initiate transactions, or bypass controls that the application layer enforces correctly. The application is secure. The pipe behind it is not.

Why the integration layer is the right enforcement point

The integration layer receives every request from every channel and routes it to every downstream system. It is not a single API. It is the orchestration fabric. A well-governed integration layer is the most efficient place to enforce authentication for three reasons:

It sits between all consumers and all systems. Authentication enforced here covers every channel (mobile, web, USSD, ATM, agent terminal, third-party fintech) without changes to each downstream system.
It is centrally governed. API Manager policies apply consistently across the estate. There is no per-team authentication decision. There is one model, enforced everywhere.
It is the correct point for token validation. The integration layer validates the incoming token before any flow executes. The downstream System API receives a verified, authorised request.

This is the zero-trust principle applied to banking architecture: every request must present a verifiable identity, regardless of where it originates. Internal traffic is not trusted by default. A request from the mobile banking Process API to the core banking System API must authenticate the same way a request from an external fintech partner does, with a verifiable token, a short TTL, and validated scope.

The authentication model that holds up in production

There is no single authentication method that is correct for every API in a banking estate. The question is whether the model is coherent, whether the choices made at each layer were made deliberately, with the right method for the right context.

The pattern that works across African banking deployments comes down to three context-method pairings, plus one constraint that governs all of them.

Context	Method	Why it fits
External fintech and open banking partners	OAuth 2.0 (auth code + PKCE)	Delegated access with scoped permissions. Tokens expire. Access can be revoked.
Internal service-to-service (M2M)	OAuth 2.0 client credentials	Machine identity. Short token TTL. Centralised client registry in API Manager.
High-assurance systems (payment rails, core banking)	Mutual TLS (mTLS)	Certificate-based identity for both parties. Aligned with zero-trust and expected by regulators.

The critical constraint that breaks this model in practice is token TTL. Access tokens in many African banking environments are configured with TTLs of 24 hours or longer, a legacy of the assumption that token generation is expensive. It is not. Short TTLs (15 minutes to one hour) are the correct baseline. A leaked token with a 24-hour TTL is a 24-hour window. A leaked token with a 15-minute TTL is a 15-minute problem.

What goes wrong, and where

The failures in African banking API estates are not exotic. They are the same failures found in every market where integration layer security was treated as an afterthought. Five of them appear consistently:

Tokens are never validated at the gateway. The integration layer passes tokens downstream and lets the System API validate, or not. A token that should have expired is still accepted.
Internal traffic is not authenticated. Service-to-service calls between Mule applications use no authentication. The assumption is that internal means trusted. In a zero-trust model, it does not.
Object-level authorisation is missing. The API validates that the caller has a valid token. It does not validate that the caller has permission to access the specific resource. BOLA (Broken Object Level Authorisation) is the most prevalent API vulnerability in financial services.
Credentials appear in logs. Client secrets, access tokens, and API keys are included in structured log entries or error responses. Every observability platform becomes a credential store.
The security model was never designed. It accumulated. Each API was built by a different team with a different assumption. There is no governing model.

The regulatory dimension

Central Bank of Nigeria's Open Banking Regulatory Framework, the South African Reserve Bank's guidance on API security, and the Central Bank of Kenya's draft open banking framework all require documented API security controls.⁷ An integration estate where authentication is inconsistent is not only a security risk, it is an audit risk. The documentation that open banking requires often reveals the gap that was never visible before.

The architectural decision that costs nothing to make early

The integration layer in a modern African bank connects dozens of internal systems and an increasing number of external partners. The API surface is growing: open banking, embedded finance, mobile money interoperability, real-time payment rails. Every new connection is a new authentication decision.

The decision to treat the integration layer as the security enforcement point, not the application, not the edge router, not each individual System API, is architectural. It costs nothing to make at design time. It costs significantly to retrofit after APIs are in production, after partners have integrated, after the audit has identified the gaps.

“Senior expertise from day one means that question is on the table before the first API is built. The authentication model is in the design document, not the remediation backlog.”

The banks that are getting this right are not necessarily the largest or the most technically advanced. They are the ones that made the architectural decision early and governed it consistently. The integration layer is a security layer. Treating it as infrastructure is a choice, and the consequences of that choice are now more visible than they have ever been.