Do you own your payment system?
Five questions reveal which banks control their infrastructure and which only paid for it.
A few months ago, I sat in a steering committee meeting at a Pan-African commercial bank. The CTO was walking the board through the bank’s “owned” payment infrastructure. The slide deck was confident. Annual switching volumes. Channel uptimes. The names of the systems they had bought, deployed, and were now operating.
I asked one question. “If your principal switch vendor went insolvent tomorrow, how long until you couldn’t process a transaction?”
The room went quiet. The CTO answered honestly. “I don’t know.”
That moment is the reason I built the Infrastructure Sovereignty Assessment.
Most banks think they own their payment infrastructure. The reality is more complicated. Ownership shows up on the balance sheet. Sovereignty shows up in operational reality. A bank can have invested tens of millions in payment systems and still have no meaningful control over them. The infrastructure is on premise. The license is paid. The contracts are signed. And yet, when something breaks, the people who understand what to do are not on the bank’s payroll.
This issue introduces the framework I use to assess that gap. Five dimensions. Five questions. If your bank cannot answer them confidently, you are renting your payment infrastructure. You just have not been told.
Ownership shows up on the balance sheet. Sovereignty shows up in operational reality.
Ownership is not the same as control
The conversation about payment infrastructure in African banking is usually framed around procurement. Which vendor. Which platform. Which licensing model. These are the wrong questions to lead with.
Procurement is about acquiring software. Sovereignty is about the ability to operate, modify, and recover that software without external dependency. They are not the same thing, and the distinction is invisible to most boards.
Here is the test. A bank does not control its payment infrastructure unless it can answer five questions clearly, in writing, with current evidence, on a Tuesday afternoon. Most cannot. The banks that try to answer them honestly are usually surprised by what they find.
The five dimensions of infrastructure sovereignty
The Infrastructure Sovereignty Assessment evaluates five dimensions. Each is binary in practice. You either have sovereignty in that dimension or you do not. The grey zones in your answer are the gap.
Configuration sovereignty. Every transaction switch has a configuration that governs how it behaves. Authorization rules. Routing tables. Fee structures. Timeout values. Retry logic. Fraud thresholds. This configuration is where the system’s behavior lives. Not in the documentation. Not in the contract. In the configuration.
The question is not whether the configuration exists. It always exists. The question is whether your bank understands it, owns the documentation for it, and can audit changes to it without involving the vendor.
The honest answer for most African banks is no. The switch was deployed by a vendor team that flew in for the implementation, configured the system based on industry defaults and a few requirements documents, and flew out. The configuration sits on the production switch. The vendor knows what is in it. The bank, often, does not. Your system is doing what someone else decided it should do, and you have no real visibility into it.
Key person sovereignty. Every payment system has a small number of people who genuinely understand it. In African banks, this number is often shockingly small. Sometimes it is one engineer at the vendor. Sometimes it is a single internal architect who has been with the system since deployment. Sometimes it is a contractor who left two years ago.
The test for this dimension is brutal. Name the three people who, if they were unavailable for the next 60 days, would prevent your bank from making a non-trivial change to its payment infrastructure. Now look at how many of those people are on your payroll, with succession plans, and with documented knowledge transfer.
Most banks fail this question on the first read. The knowledge gap between what was built and who is now operating it is the silent systemic risk across the continent. We are running production payment systems on the goodwill of individuals who could leave, retire, or be hired by a competitor in the next 90 days, and the institution has no contingency.
Data sovereignty. Where does your transaction data live? The on-premise system has its production database. Fine. Where are the backups stored? Where does the vendor’s monitoring agent send telemetry? Where does the fraud screening engine send transactions for analysis? Where do the analytics dashboards pull from?
Most African banks do not have a clear answer to all of these questions. The data is physically present in the bank’s data centre. Copies of it, derivatives of it, and metadata about it are in places nobody at the bank can fully account for. This is becoming a regulatory issue. Data residency requirements are being written into payment regulations across the continent. Sovereignty over your data is now a compliance dimension, not only a security one.
Change velocity sovereignty. Suppose your bank wants to add support for a new card scheme, change a routing rule, or modify a settlement window. How long does that take? More importantly, how much of that timeline is your bank’s, and how much is your vendor’s?
Banks that have outsourced their change capability to a vendor have a fundamental sovereignty problem. They cannot move at the speed their market demands, because every change is bottle-necked by an external resource calendar. The vendor is not malicious. The vendor is running a business with finite capacity, and your project is one of many.
The banks that can act quickly are the ones that have built internal change capability. Engineers who can write the configuration changes, test them in a representative environment, and deploy them through the bank’s own change management process. This capability is rare. It is also why the banks that have it can release new payment products in months while their peers take years.
Recovery sovereignty. Disaster recovery is the dimension where sovereignty failures become catastrophic. A switch outage during a salary payment window costs more than money. It costs trust, regulatory attention, and sometimes the bank’s relationship with major corporate clients.
The question for this dimension is simple. If your primary site failed at 14:00 on a Friday with the next settlement window approaching, who would lead the recovery? If the answer is “we would call the vendor’s support line,” your recovery sovereignty is zero. If the answer is “our internal team would invoke the runbook and have failover complete within 30 minutes,” your recovery sovereignty is real.
A DR plan that has not been tested in 18 months is a document with an expiry date. A DR plan that depends on calling someone in another country at 02:00 their time is a hope, not a plan.
Why most banks fail this assessment
The pattern is consistent across the continent. Banks fail the Infrastructure Sovereignty Assessment for three reasons.
The first is that the original procurement decision optimised for speed-to-deploy rather than long-term operational ownership. The vendor offered a turnkey solution. The bank accepted. Knowledge transfer was a phase in the implementation plan, not a continuous discipline. By the time the project was signed off, the vendor knew the system better than the bank did, and that gap has compounded ever since.
The second is that internal payment engineering capability has been chronically underfunded. The engineers who could close the sovereignty gap are not on the team because the budget assumed the vendor would handle that work. The vendor does handle it. The bank pays for it. And every year, the bank’s internal capability gets thinner while the vendor’s leverage grows.
The third is that nobody at the executive level has framed sovereignty as a risk. It does not appear in the risk register. It is not discussed at board level. It is treated as a technical concern when it is a strategic dependency. A bank that does not control its payment infrastructure does not control its payment products, its pricing flexibility, or its operational risk profile.
What this means for your organization
If you are a digital transformation lead, an innovation head, or a treasury executive at a bank, the Infrastructure Sovereignty Assessment is a diagnostic you can begin in 90 days. You do not need a consulting engagement to start. You need the right questions and the courage to ask them.
For each of the five dimensions, ask your CTO or head of payments to provide a written, evidenced answer. Not a verbal reassurance. A document with current evidence.
Where the answer is weak, identify whether the gap is a knowledge gap, a documentation gap, a personnel gap, or a contractual gap. The remediation is different for each.
Identify which dimension represents your largest risk if it failed today. Address that one first. Sovereignty is built incrementally, not all at once.
Treat the assessment as an annual exercise. Sovereignty erodes. Vendors change. Engineers leave. Configurations drift. The gap that was small last year is bigger this year if nobody is actively managing it.
Make sovereignty a board-level metric. If the board cannot answer the three questions, how does money move, what happens when it fails, and who is responsible, then the bank has a governance problem masquerading as a technical one.
The banks across Africa that will lead the next decade of payment infrastructure are the ones that recognize sovereignty as a competitive advantage, not a procurement variable. The cost of building internal sovereignty is real. The cost of not having it is paid quietly, in vendor invoices, in lost agility, in the slow accumulation of technical debt that compounds until something breaks visibly.
Most banks think they own their payment infrastructure. The five questions tell the truth.
If you would like to run this assessment against your own bank’s payment infrastructure, I work with bank executive teams to scope and conduct the Infrastructure Sovereignty Assessment as a 90-day diagnostic engagement. Reply to this email or reach me at the contact details on the publication.
The next issue will go deeper on the first dimension, configuration sovereignty, and how a bank builds the internal capability to own its switch’s behavior end-to-end.
If you found this issue valuable, forward it to one person who needs to read it.
Paid subscribers get the full diagnostic checklist for each dimension as a downloadable workbook. Subscribe at
