By Al-amin Ajao Olayiwola
August 1, 2025, was supposed to be the day. For a few months that spring, after the Central Bank of Nigeria announced a firm launch date, it looked as though the country would become the first in Africa to run a national open banking regime. The arrangement would let you tell your bank to share your account data with an app or a lender you trust, without surrendering your password to do it. The date arrived. Nothing switched on. The regulator let it pass and said, in effect, that the system was not yet safe enough to be true.
It would be easy to file that under the familiar heading of African infrastructure delay, and easy to be wrong. The delay was not administrative. By the time the August date slipped, the rules had been settled for years. The CBN published Africa’s first open banking framework in February 2021 and followed it in March 2023 with operational guidelines detailed enough to specify how customer consent must be confirmed and how the resulting access must be secured. What had not been settled, including what five industry workstreams were still finishing when they handed their deliverables to the regulator in September 2025, was the harder question underneath the policy. It was not whether Nigerians should be able to share their financial data, but whether the systems doing the sharing could be trusted to stop when told to.
Consider what a single grant of consent sets in motion. You open a budgeting app and allow it to read your bank transactions. You do not hand it your money or your login. Instead, the bank issues a token, a short digital credential that represents a specific permission: this app, your data, this purpose. The app presents that credential each time it wants to read something. The Nigerian guidelines are exacting about how that credential comes into being. The customer’s agreement has to be verified with two-factor authentication, and the token has to be encrypted and passed securely between the institution that holds the data and the one that wants it.
That part, the initial yes, is well understood and largely solved. The problem lives on the other side of the decision.Weeks later, you lose interest in the app, or you read something that unsettles you, and you withdraw the permission. The moment you do, the truth about your consent changes. The token does not. It is still sitting in the app’s records, and quite possibly cached in a service somewhere between the app and your bank that was told, not long ago, that this credential was valid.
Your bank’s own systems may also be holding their own copy of that decision, kept close for the sake of speed because rechecking every request against a central authority is expensive and slow. Revocation, the act of cancelling the credential, only means anything if the cancellation outruns all of those copies. The gap between the moment you say no and the moment every system actually honours it is not a technicality. It is a live window in which your data can still be read against your wishes. The whole moral claim of open banking depends on making that window as small as possible.
This is the part outsiders underestimate because it inverts the intuition. Granting access feels like the sensitive act; withdrawing it feels like housekeeping. In engineering, the reverse is often true. Authorisation is a handshake everyone is motivated to complete. Revocation is a message that downstream systems are not necessarily designed to receive quickly. It has to propagate through systems deliberately built to avoid asking for permission twice.
Every design choice that makes the ordinary case fast — long-lived tokens, cached approvals, trust extended and then remembered trust, can make withdrawal harder to enforce. A credential that lives for hours is cheap and convenient, but it can continue working long after it should be dead. A credential that lives for seconds dies almost immediately after revocation, but forces the network to repeatedly verify whether the permission still holds. The real engineering challenge is finding the right balance between those two extremes.
In a centralised design such as Nigeria’s, where a public registry operated by the Nigeria Inter-Bank Settlement System sits at the centre of the arrangement, that balance has a natural point of control. The registry and the shared standards around it can serve as an authority that participants check against rather than relying on local copies of an earlier decision.
That approach only works if the check is fast enough to make revocation meaningful and reliable enough that it never authorises a request after a customer has withdrawn permission. This is one of the fundamental conditions that has to be satisfied before open banking can operate at national scale.
The second challenge is subtler and, in a rollout this size, more treacherous because when it fails, it may do so without a sound. Open banking only works if every institution presents its data in the same agreed shape. The fields must be named consistently, carry consistent meanings, and follow the same structural rules. That allows an approved company to connect to multiple banks without building a separate integration for every institution. Engineers call that agreed structure a schema. The simpler word is contract.
The contract says that a transaction record will contain particular pieces of information, represented in particular ways, and that those fields will retain defined meanings. As long as everyone follows that contract, the wider system can function. A bank upgrades its systems, adds a field, renames another, or changes a definition that used to be interpreted more loosely. The moment it does, every company depending on the previous structure is exposed. The failure may not produce a dramatic crash, which would at least announce itself. Instead, the data can continue to arrive, remain valid enough to pass basic checks, and still be interpreted incorrectly.
A lender could score an application using a number that no longer means what it meant the previous week, while the underlying systems continue to report that everything is functioning normally. Guarding against this requires a discipline called versioning. In practice, versioning means refusing to make the past disappear the moment the future ships.
A provider can publish a new version of its data structure while keeping the previous version available for a defined transition period. Companies depending on the old structure can then migrate deliberately rather than being forced into an emergency change. In ordinary software development, this is good engineering practice. In a nationally mandated system, where hundreds of participants may connect within the same period and customer-facing services must continue operating while the underlying infrastructure changes, it becomes essential architecture.
A poorly managed version change does not affect one engineering team. It can travel through every service that depends on the previous contract. There is another reason this matters. In open banking, consent is not simply a yes or no decision. It is tied to the type of data being shared, the institution providing it, the organisation receiving it, and the purpose for which access has been granted.
If the structure or meaning of that data changes without corresponding controls around consent, the technical change can affect the practical scope of what a customer agreed to share. That makes schema management part of the consent architecture rather than a separate software maintenance concern. Put these two problems side by side and the delayed launch reads differently.
The framework itself was not the difficult part. Publishing rules establishes what should happen. The harder task is making those rules hold across dozens of independent systems, under real traffic, with real financial data moving between institutions, while ensuring that customers do not need to understand the underlying machinery. That is where distributed systems engineering becomes inseparable from regulatory compliance.
A regulator that prioritises being first at the expense of these controls would not simply risk a technical incident. It would risk the credibility of the entire open banking model. Once customers begin to believe that withdrawing consent does not actually stop access, or that the information they authorised can change meaning without their knowledge, rebuilding confidence becomes far harder than delaying a launch.
The questions that will ultimately determine whether Nigeria’s model works are therefore unlikely to be the most visible ones. They concern details such as how long a credential should remain valid, how quickly a revocation must propagate, how cached authorisation decisions should expire, which schema versions must remain supported, and how participants are expected to migrate between them.
These are small engineering decisions with consequences far beyond the codebase. They determine whether a customer’s decision remains enforceable after it has been made.For Nigeria’s open banking system, that is the real test. The technology does not merely need to make data sharing possible. It needs to make permission enforceable, revocation dependable, and changes to the data contract predictable.
For now, the people who will decide whether Nigeria’s version works are not the ones who wrote the guidelines. They are the ones arguing, well out of public view, over how many seconds a credential should live and how long an old data format deserves to survive after a new one appears – small, unglamorous questions on which a whole country’s trust in a new idea quietly rests.
Al-amin Ajao Olayiwola is a Senior Software Engineer