Protecting the Core While Unlocking Open Banking.

The conversation that needs to change

Walk into a CIO meeting at almost any large African bank and raise the topic of integration architecture. Within minutes, the conversation turns to the core banking system.

We cannot move fast because we are on T24. Finacle limits what we can do. Flexcube makes it impossible to expose data in real time. The core is the problem.

This is the wrong diagnosis. And it leads to the wrong solution.

T24, Finacle, and Flexcube are mature, enterprise-grade platforms. They have processed hundreds of billions of transactions across thousands of institutions. They are capable of exposing data, processing transactions, and supporting the operational requirements of large retail and commercial banks.

What they were not designed to be, and what they should not be asked to be, is the real-time API backend for a modern digital channel estate serving mobile, USSD, open banking, and AI-native consumers simultaneously.

That is an integration architecture responsibility. And confusing it with a core banking limitation is one of the most expensive mistakes an African banking leadership team can make.

The wrap strategy: what it looks like in practice

Wrapping a core banking system means placing a System API layer between the core and everything that consumes it. The System API abstracts the internal complexity of the core, including its data model, its call patterns and its version-specific behaviours, and exposes a clean, stable, versioned endpoint.

From the perspective of the mobile app, the USSD platform, or the AI agent, the core banking system looks like a well-designed API: consistent response format, predictable error handling, stable versioning, observable calls with full logging.

From the perspective of the core banking system, the API layer is just another consumer. It calls the standard interfaces the core has always exposed. Nothing in the core changes.

The bank gains the ability to move at digital pace on the channel side without requiring every change to propagate down to the core. When a new version of T24 is deployed, only the System API layer adapts. The channels above it see no change.

What the wrap strategy delivers immediately

• Channels can be launched and modified without changes to the core.
• Multiple channels can consume the same core capabilities without duplicate integration work.
• The core can be upgraded or migrated without disrupting the channel estate.
• Observability and logging can be introduced at the API layer without requiring core changes.
• Security policies can be enforced at the API gateway without core modification.

Open banking: the regulatory landscape African banks must navigate

The same System API layer that wraps the core for internal channel consumption becomes the foundation for open banking: the external exposure of bank capabilities to third-party developers, fintechs, mobile money operators, and aggregators.

African central banks are moving. The direction is clear. The timeline is accelerating.

Nigeria: CBN Open Banking Regulatory Framework

Nigeria's Central Bank published its Open Banking Regulatory Framework in February 2021, followed by Operational Guidelines in March 2023.^{1 2} The framework classifies participants into four tiers based on risk management maturity, determining permitted data categories and required internal controls. Banks are required to develop APIs that allow authorised third parties to access customer data with consent.

The technical requirements are specific: OAuth 2.0 and OpenID Connect for authorisation, mutual TLS for transport security, consent management infrastructure, rate limiting and throttling at the API gateway, and full audit lineage for every data access event.

Kenya: CBK Open Banking Framework

Kenya's Central Bank published a draft open banking framework in March 2024, setting out an implementation timeline and technical expectations for APIs, with full compliance anticipated by December 2026.³ The framework emphasises REST APIs, OAuth 2.0, and ISO 20022 message standards. Kenya's National Payments System Vision and Strategy 2021 to 2025 had already established the regulatory direction, committing the CBK to define API standards and mandate data portability.⁴

Note: the article originally referred to an “active regulatory sandbox” producing technical standards for a formal open banking framework. The CBK has indicated intent to establish a sandbox but had not, as of the time of writing, fully developed and clarified the procedures for its implementation.

Ghana, South Africa, and the broader continent

Ghana's Bank of Ghana published a draft Open Banking Directive in late 2024, introducing API standards, data protection rules, customer consent requirements, and a proposed Open Data Exchange platform.⁵ As of mid-2026, there are no live open banking APIs in Ghana and no firm implementation timeline, but the regulatory intent is clear.

South Africa's open finance framework remains in development, with the COFI Bill expected in Cabinet in 2026 and a multi-year transitional period to follow.

Across East Africa, the East African Community is developing regional frameworks for digital financial services interoperability. The direction of travel across the continent is consistent: bank capabilities will be exposed through governed, consented APIs to third parties.

What open banking requires from the integration layer

Open banking is not simply a matter of publishing APIs. The technical and governance requirements are specific, and they are all integration layer concerns, not core banking concerns.

Secure external exposure. Account, payment, and KYC capabilities need to be accessible to authorised third parties without exposing the core banking system directly. The Experience API layer, shaped for external consumption with scoped access controls, is the right boundary. Third parties call the Experience API. The Experience API calls the Process and System layers. The core is never directly accessible.

OAuth 2.0 consent and authorisation. Every open banking framework referenced above requires the bank to implement OAuth 2.0 and manage customer consent for data sharing. The customer must be able to grant and revoke consent for specific third parties to access specific data. This is an integration layer concern. Consent management needs to be enforced at the API gateway, not at the core.

Rate limiting and throttling. External developers are not internal teams. API traffic from a fintech partner is unpredictable and can spike dramatically. The integration layer needs to enforce rate limits at the API gateway level, protecting the core from overload and ensuring fair access across third parties.

Audit and lineage. Regulators will require banks to demonstrate who accessed what data, when, and on whose authority. Every API call in the open banking estate needs to be logged with full lineage, from the external consumer through the Experience and Process layers down to the System API and the core. This is observability infrastructure. It belongs in the integration layer.

One investment. Two problems solved.

The architectural insight that changes the economics of both core modernisation and open banking readiness is this: they require the same investment.

A System API layer that wraps the core provides the foundation for both internal channel acceleration and external open banking exposure. The governance, observability, and versioning infrastructure that makes the internal estate manageable is the same infrastructure that makes external API exposure safe and compliant.

A bank that waits until the open banking mandate arrives, and then attempts to bolt an API layer onto a point-to-point integration estate, will spend three times the effort achieving half the result.

Starting before the deadline

The most effective open banking strategy is not to respond to the regulatory mandate. It is to have the architecture in place before the mandate arrives.

This is not a matter of regulatory over-compliance. It is a matter of competitive timing. When the open banking mandate arrives and the API economy opens, the banks that are ready will capture the first-mover advantage. They will attract the fintech partners, the aggregators, and the corporate clients that need reliable, well-documented, well-governed APIs. The banks that start at the deadline will spend the first two years catching up.

The two-week integration assessment is the starting point. It produces an honest picture of the current integration estate, a prioritised roadmap for the System API layer, and a TCO model that makes the investment case for the CIO and CFO without ambiguity.

The race to open banking readiness has already begun. The banks that recognise it are building the foundation now.