CRDB Bank’s digital banking transformation was driven by a problem that sits underneath the mobile apps, internet banking platforms and other services customers see: the bank needed a better way to connect those channels to the systems running its operations.
At WSO2Con Africa 2026 in Nairobi, Dr. Mturi Matwiga, Portfolio Manager for IT & Digital Transformation Projects at CRDB Bank, explained how the bank used WSO2 to build an enterprise integration backbone that also supported its migration to Temenos Transact.
The project brought together several pressures that were becoming harder to manage independently. CRDB was dealing with fragmented middleware, duplicated point-to-point services and limited API standardisation while digital transaction volumes, channels and external partnerships were growing. At the same time, the bank was pursuing core banking modernisation, regional expansion and preparation for capabilities such as open banking. The response was to establish a common integration layer between customer-facing channels, enterprise applications, partners and the underlying banking systems.
CRDB had a fragmentation problem to solve
CRDB’s regional operations span Tanzania, Burundi, the Democratic Republic of the Congo and Dubai, while its banking services cover retail, MSME, corporate, treasury and premier banking customers. As more channels and services were added, integration became a larger operational concern because changes in one part of the technology environment could have consequences elsewhere.
Matwiga described the earlier environment as one involving multiple gateways and dependencies between systems. The bank’s objective was to remove those dependencies by creating a layer through which different parts of the digital enterprise could communicate using common standards. In practical terms, that meant a digital channel could change without requiring the underlying service provider to change at the same time, while the bank could replace core systems without rebuilding every channel connected to them.
That architectural decision gave integration a strategic role inside the transformation. Instead of treating middleware as infrastructure sitting behind the visible banking experience, CRDB began treating the integration layer as a capability that could affect how quickly the bank introduced services, changed systems and expanded into other markets. Matwiga said the integration platform had become an executive-level concern because of its relationship with innovation, growth and core banking modernisation.
The integration backbone sits between channels and the core
The architecture presented at WSO2Con places the integration backbone between CRDB’s experience layer and the systems providing banking services.
At the customer and enterprise side are mobile banking, internet banking, USSD, ATMs, agency banking, CRM, lending, payments, internal applications and partner services. The WSO2 layer then provides API management, integration and orchestration, identity and access controls, observability and the mechanisms needed to route and transform requests. Beneath that are Temenos Transact, internal enterprise services, payment and regulatory platforms and external services.
The distinction is important because the integration layer gives CRDB a consistent way of exposing and governing capabilities without requiring every channel to understand how each backend system works. The platform includes WSO2 API Management for exposing and governing services, Micro Integrator for orchestration and transformation, Identity Server for access control, analytics and monitoring for operational visibility, and a CI/CD and Kubernetes foundation for automated and resilient deployment.
Matwiga’s presentation described the architecture as a single enterprise integration backbone built around standardised APIs, reusable services, governed access and end-to-end visibility. His earlier explanation of the implementation also highlighted security, orchestration, transformation, monitoring and API lifecycle management as central functions of the platform.
The approach fits a broader theme running through WSO2Con Africa 2026. TechTrendsKE’s earlier reporting on APIs noted that enterprises already use APIs to expose capabilities from banking platforms, payment systems and other business infrastructure, while stronger governance and access controls become important when those interfaces are used by more sophisticated applications.
For CRDB, however, the immediate purpose was practical: establish a stable interface between its digital banking environment and the systems underneath it.
Decoupling made the Temenos Transact migration possible
The most significant consequence of the architecture was its role in CRDB’s core banking migration.
The presentation identifies Temenos Transact as the target core banking platform and shows WSO2 sitting between the core and integrations coming from channels, enterprise systems, external partners, regulatory services and the payments ecosystem. That arrangement allowed the bank to work on the core migration without carrying the full weight of its existing channel dependencies into the new environment.
Matwiga explained that CRDB previously had several gateways and that changes to one system could affect another. The integration backbone was designed to decouple those relationships, allowing channels to change independently while also making it possible to replace the core banking platform without creating the same level of disruption across the digital environment.
That is where the integration investment becomes more than a middleware modernisation project. Core banking systems underpin large portions of a bank’s operations, so migration can involve customer channels, payments, internal services, partners and regulatory connections at the same time. By putting a governed integration layer between those systems, CRDB created a common point through which the new core could connect to the rest of the bank.
He also describes the subsequent move from legacy systems toward the new core as easier because the channel-provider dependency had already been removed.
CRDB hardened the platform for production banking
Once the integration backbone was in place, the focus moved from architecture to operational reliability.
The presentation describes a programme of operational hardening covering core banking failover, platform tuning, database optimisation and automated health checks. CRDB also used Kibana dashboards, enhanced alerting and broader observability to give engineers better visibility into what was happening across the environment.
The operating model extended beyond monitoring. Automated CI/CD, Kubernetes orchestration, Grafana, Kibana, centralised logging, disaster recovery and high availability were presented as parts of the production platform. The objective was to make the integration environment something the bank could operate continuously, rather than a project that ended when the technology was deployed.
Matwiga said the first six months after the WSO2 platform went live involved work on failover, platform tuning, database optimisation and monitoring alongside WSO2 engineers. He also described automated API deployment, orchestration, scalability, centralised logs, disaster recovery and high availability as part of the operational model.
One practical example was the bank’s disaster-recovery process. Matwiga said the regulator requires an annual production-to-DR switch, a process that had previously been complex but became easier with the new platform’s governance, monitoring and recoverability capabilities.
That operational work matters because a banking integration platform sits inside transaction flows. Its value therefore depends on whether it remains available, observable and recoverable when systems fail, traffic changes or maintenance is required.
One architecture across multiple markets
CRDB also designed the platform around regional reuse.
The presentation identifies Tanzania, Burundi and the Democratic Republic of the Congo as the three-country digital banking model, with shared standards and governance providing a common foundation across the operations. The idea was to avoid rebuilding the integration model each time the bank introduced capabilities in another market.
He describes this as a move toward centralised governance and standardisation across subsidiaries. APIs and capabilities developed in one market could be reused in another, reducing the need to start from scratch when implementing services elsewhere.
That did not mean every market had to run an identical physical environment. The presentation also records executive discussions around whether the countries should share one WSO2 platform. The eventual consideration of country-level deployments reflected the importance of connectivity to financial institutions and the fact that regulatory requirements can require local implementation choices.
The result is a model that separates common governance and standards from the operational realities of individual markets. That gives CRDB a way to reuse architectural patterns while retaining room for country-specific requirements.
The platform is now part of CRDB’s digital strategy
The business impact presented by CRDB extends beyond integration delivery. The bank identifies faster delivery, reduced middleware complexity, improved digital services, greater resilience, reusable APIs, multi-country reach and support for core banking modernisation as outcomes of the programme.
Matwiga said the transformation also changed the experience of the teams working on the bank’s digital environment. Once the integration backbone was stable, teams spent less effort dealing with the problems created by the previous fragmented integration landscape. CRDB also reported that some critical performance indicators improved by more than 123% within a year of the backbone’s implementation, although the presentation does not identify the specific indicator or methodology behind that figure.
The next set of priorities shows where CRDB intends to take the architecture. Its presentation lists open banking, embedded finance, ecosystem partnerships, AI-powered services, digital innovation and regional expansion as future focus areas.
That direction also fits the wider infrastructure discussion at WSO2Con Africa. TechTrendsKE’s coverage of enterprise data and AI agents has examined how existing systems, APIs and integration layers can expose business capabilities to AI applications, while the conference’s broader programme has connected APIs, integration, identity and governance with enterprise AI.
For CRDB, those future possibilities sit on top of infrastructure that has already been built for conventional digital banking. The immediate achievement was creating a common integration layer capable of supporting a major core banking migration while keeping channels, services and partners connected.
That is why the bank’s transformation is ultimately an architecture story. The visible result is a more unified digital banking environment, but the strategic capability sits underneath it: a governed integration backbone that gives CRDB more room to change its core systems, reuse services across markets and build new digital products without recreating the same connections each time.
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
