Stanbic IBTC: USSD Channel Re-Platforming
The *909# USSD channel is one of the most inclusive ways for Nigerians to bank: no smartphone, no data, no branch visit required. But the platform running it had been retired by its own vendor and was no longer supported. A live, unsupported channel handling banking transactions is not a maintenance problem. It is a security exposure. The channel was also unreliable: frequent downtime, high session-timeout rates, slow to ship anything new, and locked to a vendor that no longer existed in practice.
As Product and Delivery Lead, I led the full re-platforming of the channel from assessment through big-bang cutover: replacing the legacy menu manager with a Kafka-backed, event-driven microservices architecture that could handle real load, restore availability, and let the bank ship new USSD features at pace. Monthly session volume increased 500% in the period after go-live.
500%
Increase in monthly session volume in the period after go-live
99%
Channel availability restored after chronic downtime on the legacy platform
90%
Reduction in platform-side session response time (end-to-end latency bounded by telco)
60%
Increase in new-feature release velocity, subject to change-management cycles
The Problem
The *909# channel ran on a menu manager that had reached end-of-life and was no longer supported by its vendor. That single fact had a cascade of consequences: no security patches, no upgrade path, no support when things broke. It created a live security exposure sitting directly in the customer transaction path.
Operationally, the legacy architecture could not cope with peak load. The channel handled customer requests synchronously, so every tap waited on a response from core banking before the session could continue. When traffic spiked, sessions timed out and customers were dropped. Downtime was frequent. The failure rate was high. And because the menu logic was baked into the platform, shipping even a simple new menu option required a vendor-dependent deployment cycle that stretched timelines and made the channel slow to evolve.
The business case for re-platforming was not marginal. The channel needed to be rebuilt.
Architecture: How the Rebuild Works
Why the old stack failed at peak
USSD gives the bank a tight window (typically 3 to 5 seconds) to respond before the session times out and the customer is dropped. The legacy platform handled this synchronously: a customer tap triggered a direct call to core banking, and the response had to come back before the timeout. When traffic spiked or core banking slowed, sessions failed. The channel became unreliable precisely when it was most needed.
The architectural fix: decouple the tap path from downstream systems
The rebuilt architecture splits the problem in two. The session and menu engine, the layer that must respond to the customer within seconds, reads from a fast Redis-backed session store and responds immediately. The actual instruction (a funds transfer, a bill payment, a balance query) is published as a Kafka event and consumed by the relevant domain microservice, which executes against Finacle at its own pace. The customer sees speed. The core system never gets overwhelmed by direct synchronous load from the channel.
What Kafka adds beyond throughput
Kafka does more than absorb volume. Every event published to the channel is durable and replayable, so transient failures in a domain service become retryable events rather than dropped transactions. Audit, notification, and reconciliation consumers tap the same stream without touching the transaction path. And because the event backbone is decoupled from both the session layer and Finacle, each tier scales independently, so the channel handles more sessions without proportionally increasing load on core banking.
Configuration-driven menus: the release velocity story
The legacy menu manager required a platform deployment to change a menu option. The new architecture separates menu configuration from platform code. New USSD flows are defined in configuration and served by the menu engine at runtime with no deployment cycle and no vendor involvement. This is what drove the 60% increase in feature release velocity: the constraint was never engineering capacity, it was a rigid platform that made every change expensive.
What I Did
1. Legacy platform assessment and risk analysis
Started with a structured assessment of the existing *909# channel: mapping the as-is architecture, cataloguing the risks created by the vendor-retired menu manager, and translating the security exposure and operational fragility into a clear business case for re-platforming. This became the foundation for stakeholder alignment and the project risk register that guided delivery through to go-live.
2. Product vision and channel architecture design
Defined the product vision for the rebuilt channel: an event-driven, containerised microservices architecture with Kafka as the messaging backbone. The design principle was deliberate: keep the customer-facing tap path fast and synchronous, while decoupling it from downstream systems through the event layer. This meant new menu flows and functional scope could be shipped as configuration changes rather than platform deployments, directly addressing the velocity problem of the legacy stack.
3. Functional scope definition
Scoped and specified the full functional footprint of the revamped channel: basic account management across banking, pension, and mutual-fund products, account opening, and bills payment, all accessible over *909#. Each functional area required precise requirements across the session flow, Finacle integration touchpoints, error handling, and user-facing messaging within the USSD response constraints.
4. Stakeholder and vendor coordination
Coordinated a delivery team of 12 across engineering, operations, compliance, and security, including 5 external stakeholders covering the USSD aggregator and platform partners. I maintained clarity on roles, dependencies, and timelines across all workstreams, ran structured governance sessions, and managed the communication plan that kept alignment through a 6-month delivery cycle with real-world disruptions: a stakeholder communication gap, aggregator downtime mid-delivery, infrastructure provisioning delays, and an extended security and compliance review phase. All of these were pre-identified in the risk register and managed with proactive stakeholder communication.
5. Event-driven architecture and Kafka integration specification
Defined the integration contract between the session and menu layer, the Kafka event backbone, and the downstream domain microservices. The tap path from customer to channel response was kept synchronous and fast, reading from a Redis-backed session store. Kafka topics carried the commands and events for account queries, payments, and onboarding instructions to the Finacle integration layer. Retry logic, dead-letter handling, and idempotency requirements were specified to make transient failures recoverable rather than customer-visible.
6. Security, compliance, and regulatory enforcement
Security and compliance were treated as go-live gating conditions, not a final checklist. The unsupported legacy platform had created a live security exposure at the channel layer, and the revamp was an opportunity to close it properly. I coordinated the security review workstream in parallel with delivery, ensured all CBN channel and data security requirements were embedded in the architecture, and signed off the compliance posture as part of cutover readiness.
7. Big-bang cutover planning and execution
The migration was a big-bang cutover: a single, controlled switch from the legacy platform to the new stack with no parallel-run period. This required a detailed cutover runbook, rollback triggers, communication plans for internal and external stakeholders, and full operational readiness across support and monitoring before the cutover window opened. Zero customer disruption was achieved at go-live.
8. Post-go-live performance management
Defined the KPI framework for post-launch measurement covering availability, session success rate, response time, and feature release cycle time. Monitored performance in the weeks after go-live, where the 500% surge in monthly session volume validated the architectural decision to decouple the session layer from downstream throughput constraints.
Delivery Context
The team comprised 12 people in total, including 5 external stakeholders across the USSD aggregator and platform partners. The delivery was rebased over the course of the engagement to reflect real-world realities: a communication gap with certain stakeholders, unplanned aggregator downtime, infrastructure provisioning delays, and an extended security and compliance review phase all created pressure on the original timeline. None of them caused a miss. Each was pre-identified in the risk register, managed through structured stakeholder communication, and resolved without compromising the compliance posture of the go-live.
The migration was a big-bang cutover, a single controlled switch from the legacy platform to the new stack. The cutover was gated on full regulatory, security, and compliance sign-off. Zero customer disruption at go-live.
Technical Stack
Message Backbone
Apache Kafka (event streaming, command queuing, async fan-out)
Architecture Pattern
Event-Driven Microservices
Infrastructure
Containerised services
Session Management
Redis (in-memory session state across USSD taps)
Channel Access
USSD Aggregator (MNO gateway integration)
Core Banking
Finacle
Project Tracking
Jira + Confluence
Artefacts Delivered
The Outcome
The legacy menu manager was retired and its security exposure closed. The rebuilt *909# channel came live on a containerised, event-driven microservices architecture with Kafka handling the message backbone. Monthly session volume increased 500% in the period after go-live, a direct consequence of a channel that was now stable and fast enough to absorb demand rather than drop it.
Platform availability reached 99%. Platform-side session response time dropped by up to 90%, decoupled from the throughput constraints that had made the legacy architecture brittle under load. Feature release velocity increased by 60%, with new USSD flows now shippable through configuration rather than deployment cycles. The channel that had been defined by downtime became a reliable, scalable banking touchpoint.