Rebuilding a legacy USSD channel the vendor left behind

The *909# USSD channel is one of the most inclusive ways for Nigerians to bank: no smartphone, no data, no branch visit required. It serves customers across banking, pension, and mutual-fund products, and for many of them it is the primary interface to the bank.

As Product and Delivery Lead, I owned the full re-platforming of this channel from assessment through big-bang cutover: replacing the legacy menu manager with a message-broker-backed, event-driven microservices architecture that could handle real load, restore availability, and let the bank ship new USSD features at pace.

The platform running *909# 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 sitting directly in the customer transaction path: no security patches, no upgrade path, no support when things broke.

Operationally, the legacy architecture could not cope with peak load. The channel handled customer requests synchronously, so every tap waited on 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 menu logic was baked into the platform, shipping even a simple new option required a vendor-dependent deployment cycle.

The business case for re-platforming was not marginal. The channel needed to be rebuilt.

• The USSD time budgetUSSD gives the platform roughly 3 to 5 seconds to respond before the telco drops the session. Every design decision had to protect that window, and end-to-end latency beyond the platform is bounded by the mobile operators.
• Regulatory gatingCBN channel and data security requirements were go-live gating conditions. No cutover without full security and compliance sign-off.
• A live channel, no safety netThe channel could not be paused for the rebuild, and the legacy platform could not be extended safely. The migration had to land as a single controlled switch.
• Vendor realityThe incumbent platform vendor had exited in practice. Any option that depended on them was not an option.

The delivery team comprised 12 people, including 5 external stakeholders across the USSD aggregator and platform partners. Internally the work cut across engineering, operations, compliance, and security, with executive sponsorship inside a Tier 1 bank.

I maintained clarity on roles, dependencies, and timelines through a RACI and a structured communication plan, and ran the governance sessions that kept alignment across a 6-month delivery cycle with real-world disruptions: a stakeholder communication gap, aggregator downtime mid-delivery, infrastructure provisioning delays, and an extended security review phase.

The work started with a structured assessment of the existing 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. That assessment became the foundation for stakeholder alignment and the project risk register that guided delivery through to go-live.

Session analytics made the failure mode precise: the synchronous tap path collapsed exactly when demand peaked, which meant the channel was least reliable at the moments customers needed it most. That finding shaped the entire architectural strategy.

The strategy was to separate what must be fast from what must be careful. Keep the customer-facing tap path synchronous and instant, reading from an in-memory session store, and decouple everything downstream through an event backbone so core banking is never overwhelmed by direct channel load.

A second strategic goal was permanent independence: menu flows and functional scope shippable as configuration changes rather than platform deployments, ending the vendor-locked release cycle that had made the channel slow to evolve.

• option 01Extend the incumbent platformRuled out immediately: the vendor had retired the product. No patches, no support, and the security exposure would persist for every additional month of life.
• option 02Replace with another packaged menu managerViable on paper, but it would recreate the same structural problem: menu logic locked inside a vendor platform, release cycles gated on a third party, and another migration whenever that vendor moved on.
• option 03Rebuild in-house on event-driven microservicesThe chosen path. Highest initial delivery effort, but it closed the security exposure, took ownership of release velocity, and gave the channel an architecture that absorbs peak load instead of dropping it.

• Big-bang cutover over parallel runA parallel run would have meant operating the insecure legacy platform for longer and reconciling two live channels through the telco layer. We took the concentrated risk of a single switch and paid for it with a detailed runbook, rollback triggers, and full operational readiness before the window opened.
• Asynchronous depth over end-to-end simplicityIntroducing a message broker added moving parts: topics, retries, dead-letter handling, idempotency. The payoff is that transient downstream failures became recoverable instead of customer-visible, and the tap path stopped inheriting core banking latency.
• Build effort over packaged convenienceOwning the platform meant owning its operations: monitoring, capacity, and incident response moved in-house. That cost was accepted deliberately in exchange for release velocity and vendor independence.

1. 01. Scope and specificationScoped the full functional footprint: account management across banking, pension, and mutual funds, account opening, and bills payment, each specified across session flow, core banking touchpoints, error handling, and USSD response constraints.
2. 02. Integration contractDefined the contract between the session layer, the message broker backbone, and downstream domain microservices, including retry logic, dead-letter handling, and idempotency requirements.
3. 03. Security and compliance in parallelCoordinated the security review workstream alongside delivery rather than at the end, embedding CBN requirements in the architecture and signing off the compliance posture as part of cutover readiness.
4. 04. Risk-managed executionAggregator downtime, provisioning delays, and an extended security review were all pre-identified in the risk register and managed through proactive stakeholder communication. None caused a miss.
5. 05. CutoverA single controlled switch, gated on full regulatory, security, and compliance sign-off, executed against a detailed runbook with rollback triggers. Zero customer disruption at go-live.
6. 06. Post-go-live measurementA KPI framework covering availability, session success rate, response time, and release cycle time made the outcome legible from the first weeks.

The rebuilt architecture splits the problem in two. The session and menu engine, the layer that must respond within seconds, reads from a cache-backed session store and responds immediately. The actual instruction (a transfer, a bill payment, a balance query) is published as a message-broker event and consumed by the relevant domain microservice, which executes against the core banking platform at its own pace. The customer sees speed. The core never gets overwhelmed by direct synchronous load.

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 a message broker handling the backbone. Monthly session volume increased 200% 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%. Feature release velocity increased by 60%, with new USSD flows shippable through configuration rather than deployment cycles. The channel that had been defined by downtime became a reliable, scalable banking touchpoint.

• ›Risks that are named early are managed cheaply. Every disruption that hit the timeline was already in the risk register with an owner and a response, which is why none of them became a miss.
• ›Compliance works best as a design input. Running the security workstream in parallel with delivery, rather than as a final gate, is what made a big-bang cutover under regulatory scrutiny possible.
• ›The 200% volume surge validated the decoupling decision: demand was always there. The legacy platform had been suppressing it by dropping sessions at peak.