A customer sending money through M-PESA sees a relatively simple action: enter a number, select a recipient, confirm and wait for the transaction to complete.
Behind that interaction sits a distributed financial system handling identity, APIs, compliance, fraud controls, ledgers, settlement and multiple other services. That complexity is central to how M-PESA approaches AI governance in financial services, according to Vinod Sharma, who used his WSO2Con Africa 2026 keynote to draw a firm architectural boundary around where AI can operate when money is involved.
Sharma, who has spent much of his career working on mission-critical financial infrastructure across markets, framed the issue through a simple question: where is AI allowed to touch the money? His answer was more specific than a general call for responsible AI. Models and agents can retrieve information, identify patterns, explain results and recommend actions, but the authority governing authorisation, settlement and other irreversible financial operations should remain deterministic, auditable and controllable.
That distinction gives his argument a practical foundation. Sharma’s presentation was built around systems operating at substantial scale, including more than 100 million financial lives, billions of dollars in daily transaction value and infrastructure designed to remain available around the clock. In that environment, an AI error is not simply an inaccurate answer displayed on a screen. Depending on where the model sits in the architecture, it can affect a customer’s money, a compliance decision, a financial-crime investigation or the institution’s ability to explain what happened.
The transaction customers never see
Sharma began further back than AI, with the human economic journey that financial infrastructure is supposed to support. His “Learn. Earn. Burn.” framework describes financial services from education and school fees through wages, remittances, credit and business activity, eventually extending to savings and funeral cover. The point was that financial technology becomes almost invisible when it works properly, because customers experience the outcome rather than the architecture underneath it.
He illustrated that with a story from Zimbabwe involving a woman named Blessings in Masvingo who needed to send money to deal with a death in her family. She did not know Sharma and did not ask him for help, but the situation could not wait for a future software release. The story sits behind his engineering philosophy: infrastructure exists to work when people need it, and the complexity required to make that possible should remain largely invisible to the customer.
The Zimbabwe operation he referenced grew from about two million to nine million active users between 2014 and 2018, while maintaining 99.99% core availability and processing roughly $70 billion in annual value. At that scale, reliability is inseparable from trust because a customer expects two basic things from a financial transaction: the money reaches the intended person and it arrives when expected.
That expectation explains why Sharma spent considerable time describing architecture before discussing AI. A simple wallet transaction can touch multiple backend systems, with an average transaction invoking roughly six to six and a half backend transactions in the environments he described. A purchase, for example, can involve the wallet, compliance, taxation, sanctions checks, credit or funding logic and other services before the customer receives a final response.
The visible transaction is therefore only the front end of a much larger system.
Why AI needs a boundary around money
Sharma described the operating model for such infrastructure through four responsibilities: Grow, Maintain, Protect, and Improve or Transform. Growth covers new markets, cross-border interoperability and greater transaction volumes; maintenance covers throughput, availability and operational continuity; protection covers zero trust, regulatory requirements, anti-money-laundering and sanctions controls; transformation covers replatforming, vendor changes and the introduction of new technology.
His warning was that organisations can be tempted to concentrate spending on transformation while underfunding the infrastructure that keeps existing services reliable and protected. The consequences can spread quickly because the four responsibilities are connected. If the underlying system becomes unreliable, customer experience suffers; if protection weakens, the institution’s regulatory position is affected; if both deteriorate, growth becomes harder to sustain.
That framework provides the context for his position on AI. Financial infrastructure cannot treat a language model, a fraud model and an autonomous agent as though they all carry the same consequences when they make a mistake.
Sharma illustrated the difference by comparing a conversational assistant with a financial-crime system. A wrong answer from a conversational assistant may result in a poor customer experience, while a wrong result from a financial-crime system can create a regulatory event. The engineering requirements therefore differ, particularly around hallucination tolerance, auditability, deployment environment and the ability to reconstruct a decision.
The distinction becomes more important as AI systems move from producing information to taking action.
Five kinds of AI, one authority question
One of Sharma’s clearest architectural points was that “AI” describes several different technologies with very different responsibilities. Deterministic rules can make decisions according to explicit conditions. Classical machine learning can score or classify. Large language models can explain and generate. Retrieval-augmented generation can retrieve relevant information, while agentic AI can take actions across systems.
Those capabilities can work together, but they should not automatically receive the same authority.
Sharma’s model places AI-assisted intelligence above a deterministic authority layer. Smaller sovereign models, agentic RAG, vector retrieval, CPU-based inference and drift detection can provide intelligence around the financial system. The authority layer beneath them remains responsible for authorisation, ledger operations, settlement and the specific rules or thresholds that determine whether an operation is permitted.
The phrase at the centre of his architecture was direct: AI assists. Deterministic rules decide.
That arrangement also changes how an institution should think about AI explainability. Instead of asking a probabilistic model to provide an answer that becomes the final financial verdict, the model can supply information or analysis to a system whose final decision can be reproduced according to a defined ruleset.
For Sharma, reproducibility is particularly important when regulators need to reconstruct a transaction years after it happened. His presentation described an audit and replay architecture in which matching processes and a tamper-evident audit ledger can reproduce the decision chain, allowing the institution to establish how a particular verdict was reached.
The underlying principle is familiar to anyone operating critical financial infrastructure: the system needs to know what happened, why it happened and whether the same evidence can produce the same result when the event is reviewed later.
When the model can advise but cannot decide
This is also where Sharma’s position connects with the wider financial-services discussion at WSO2Con Africa. AI is already being considered for credit assessment, fraud detection and productivity, but governance and accountability become more consequential once the technology is connected to customer data and financial processes.
Credit assessment offers a clear example. AI can help gather information, analyse documents, identify patterns or prepare an assessment, but the surrounding institution still needs to establish who is responsible for the final decision. That leaves the bank responsible for the decision and requires the workflow to specify where human approval remains necessary.
Fraud detection presents a different operating requirement because payment volumes make manual review of every transaction impractical. AI can identify suspicious patterns across large transaction flows, but the resulting system still needs controls around explainability, governance, implementation and review.
The common thread is authority. A bank can give an AI system access to customer information, expose an API that allows it to retrieve a transaction or use a model to score a potential fraud event without granting that system unrestricted control over the financial operation itself.
That distinction becomes more important as agents move deeper into enterprise systems. An agent that can retrieve records, call APIs, update databases or trigger workflows needs its own identity, permissions, delegation path and audit trail.
KYA gives agents a place in the control system
Sharma’s answer to that problem is what he calls KYA, or “Know Your Agent.” The concept extends the logic of identity and access control to software actors that can make decisions and perform tasks on behalf of people or organisations.
An agent should have an identity, a defined scope, the ability to be revoked and a record of its actions. Those controls become especially important when agents interact with other agents, because the organisation needs to preserve the chain of authority rather than simply recording that “AI” performed an operation.
Sharma took the argument further by describing an internal multi-agent system involving 27 agents operating under a 10-level governance hierarchy and using consensus voting for complex user intent. He also described task-specific agents for operational intelligence, with agents able to detect a system problem, suggest a fix and, where sufficient authority exists, apply it.
The important part is the separation of responsibilities. An agent designed to detect and resolve an infrastructure problem should not automatically have access to customer credit history simply because both functions happen to exist inside the same organisation.
That principle also answers one of Sharma’s objections to claims that AI is generating most of an organisation’s code. His concern is less about whether a model can produce software and more about whether engineers know what the agent produced, where it was introduced, what boundaries it operated within and how the resulting system can be reviewed and maintained.
The amount of code generated by AI is therefore a poor measure of engineering quality on its own. The more useful question is whether the organisation can understand, govern and operate what the agents have created.
The architecture underneath agentic AI
The infrastructure required to support this model resembles the wider architecture being discussed across WSO2Con Africa 2026.
APIs expose business capabilities. Integration layers connect modern applications to older systems. Identity establishes who can access those capabilities. Enterprise data and retrieval mechanisms give AI systems the context they need. Workflow systems preserve state when an operation has to wait for another system or human decision, while observability and audit mechanisms provide visibility into what the agents are doing.
That sequence matters because AI cannot simply bypass the complexity of the enterprise underneath it.
CRDB Bank’s digital transformation provides a useful regional example. The bank built an integration backbone between its digital channels, enterprise applications, partners and core banking systems, using that layer to support its migration to Temenos Transact while reducing dependencies between channels and underlying systems.
The same architectural logic appears in the discussions around enterprise AI. Existing APIs, enterprise data, MCP and RAG can expose organisational capabilities to agents while maintaining controlled access. The same integration problem is visible in Kenya’s public sector, where AI agents cannot coordinate services effectively if the systems underneath them remain disconnected.
For financial institutions, the consequence is that agentic AI becomes an architectural problem before it becomes a model-selection problem. The institution first needs a controlled environment in which an agent can reach the systems it needs, receive the information relevant to its task and operate within permissions that can be audited and revoked.
Only then does the question of which model to use become meaningful.
Why sovereign and specialised models matter
Sharma also pushed against the assumption that every enterprise AI application needs to rely on a large external model accessed through an API.
He described the use of smaller, open-source models that can be deployed locally and trained or adapted for narrowly defined tasks. A model with roughly three billion parameters, he noted, can operate within a relatively modest memory footprint, making smaller models a practical option for organisations that want more control over where inference occurs and what information reaches the system.
His argument was particularly relevant to financial services because a specialised model does not necessarily need access to the entire universe of customer information. A credit model can work with the information relevant to a customer’s repayment behaviour, while a wealth-personalisation system can focus on the information necessary for that particular task.
The same principle applies to RAG. Giving an agent access to every piece of enterprise information simply because it might be useful creates a larger governance problem. Restricting retrieval to the information required for a defined task creates a narrower operational boundary and reduces the amount of irrelevant context the model can act upon.
This approach fits the wider discussion around making enterprise data accessible to agents without giving them unrestricted access. The technical challenge is therefore as much about controlled exposure of enterprise capabilities as it is about model intelligence.
The production failure that changed the architecture
The strongest part of Sharma’s argument came from a production failure rather than a theoretical discussion about responsible AI.
He described a financial-crime screening system that had been subjected to real traffic, with engineering work focused on precision, throughput and the behaviour of the matching chain. After that experience, the architecture retained three things as essential: the matching chain, the audit ledger and a replay endpoint.
The resulting boundary became part of the product architecture. Sharma said the approach reduced infrastructure run rate by 18% while preserving auditability, and the system remains in production.
The lesson he drew was broader than financial-crime screening. Architecture changes when software encounters real traffic, real customers and real business consequences. A principle that looks sufficient in a design document may become inadequate once regulators, customers, operational teams and production workloads are involved.
That is why the determinism boundary in Sharma’s presentation carries more weight than a generic statement about ethical AI. It emerged from a system that had to operate under actual conditions, and it defines which components can be probabilistic and which components have to produce a reproducible financial outcome.
The financial system remains responsible
There is a second implication running through the keynote: outsourcing a decision to an AI system does not outsource responsibility for it.
If an agent incorrectly blocks a transaction, a financial institution still has to explain what happened. If a model produces an inappropriate credit recommendation, the bank remains accountable for the resulting process. If a financial-crime system generates a false positive, the institution needs enough evidence and audit information to investigate and correct the outcome.
The technical architecture therefore becomes part of the accountability model. Identity determines which actor performed an action. Authorisation defines what that actor was allowed to do. APIs and integration determine which capabilities it could reach. Data and retrieval determine what information informed the action. Deterministic controls determine which financial decisions can actually be executed. Audit and replay establish what happened afterwards.
Those components form a chain of responsibility.
What this means for African financial infrastructure
The argument matters beyond M-PESA because African financial systems are often built across a mixture of modern cloud infrastructure, established core platforms, mobile channels, partner systems and regulatory environments. Replacing everything at once is rarely practical, which is why integration becomes such a central architectural capability.
Sharma’s own approach is explicit: organisations should connect what they cannot immediately replace, establish an integration layer, and then modernise individual components behind stable interfaces. That approach mirrors the architecture presented by CRDB, where an integration backbone allowed the bank to decouple channels from its core systems while preparing for a major core banking migration.
It also explains why APIs, identity, integration and governance have appeared so prominently across WSO2Con Africa’s AI discussions. An agent cannot safely act across an enterprise simply because a model is capable of generating a response. It needs access to defined capabilities, a recognised identity, controlled permissions, relevant information and workflows that specify when it can act and when another authority has to take over.
There is also a physical cost to autonomy. Sharma invoked Landauer’s principle to make the point that computation consumes energy, meaning that agentic systems and large agent swarms carry infrastructure costs that should be considered alongside their claimed productivity gains.
The broader lesson is therefore architectural and economic at the same time. Giving agents more autonomy creates more computation, more system interactions, more permissions and more potential failure paths. The value of that autonomy depends on whether an organisation can keep those paths controlled.
For Sharma, that is the real engineering problem behind AI in financial infrastructure. The customer should be able to send money without thinking about the six or more backend transactions involved, the compliance checks running underneath the payment or the layers of middleware connecting different systems. The architecture has done its job when that complexity remains invisible while the institution can still reconstruct exactly what happened when something goes wrong.
That brings the keynote back to the story of Blessings in Masvingo. She never needed to know about the infrastructure behind the transaction, the matching algorithms, the APIs or the audit ledger. She needed the money to reach the person who needed it.
The engineering, Sharma argued, was built around protecting that outcome. AI can become part of the architecture, including through agents capable of reasoning and acting across systems, but the authority over the money still needs a boundary that the organisation can define, audit and enforce.
Real ESG impact doesn’t happen in panels alone, it happens in the rooms where financiers, operators, and policymakers actually align. Our GreenShift Forum 2026 cuts the noise, bringing together the people rewiring Africa’s sustainability and energy frameworks for one focused day in Nairobi. Secure your seat.
Go to TECHTRENDSKE.co.ke for more tech and business news from the African continent and across the world.
Follow us on WhatsApp, Telegram, Twitter, and Facebook, or subscribe to our weekly newsletter to ensure you don’t miss out on any future updates. Send tips to info@techtrendsmedia.co.ke
