Starks IT Consulting Logo
Starks ITConsulting
Start a Project
Core Banking API Platform Modernisation
CASE STUDY / FINANCIAL SERVICES
Financial Services · 2023

Core Banking API Platform Modernisation

Tier-1 Nigerian Bank

Duration
18 months
Team Size
14 engineers
Industry
Financial Services
87%
Reduction in API response latency (P99: 340ms → 44ms)
4.2M
Customer accounts served on the new platform
99.97%
System uptime in the 12 months post-launch
65%
Reduction in time-to-market for new banking features
₦1.8B
Estimated annual revenue protected from downtime prevention
Executive Summary

Rebuilt a legacy monolithic core banking integration layer into a modern, event-driven microservices architecture — enabling real-time transaction processing across 4.2 million accounts and dramatically reducing system downtime.

The Challenge

Our client — one of Nigeria's top-five commercial banks by total assets — had built its digital banking capabilities over 15 years of iterative development on top of a T24 core banking system. The result was a tightly coupled, monolithic integration layer connecting 23 internal systems and 14 third-party providers. Every product launch required changes to this central layer, making releases slow and risky. System downtime averaged 4.2 hours per month — unacceptable for a bank processing over 2 million transactions daily.

The specific trigger for the transformation programme was a major downtime incident during a public holiday that took the bank's mobile app offline for 6 hours. The cost was estimated at ₦4.2 billion in lost transaction revenue and an incalculable reputational impact.

Our Approach

We proposed a strangler fig approach — building a new microservices layer alongside the existing monolith, gradually routing traffic to the new services while maintaining the legacy system as a fallback. This avoided a "big bang" cutover that would have been prohibitively risky for a live banking system.

The architectural foundation was an Apache Kafka event streaming platform serving as the central nervous system — all services communicated via events rather than synchronous API calls. This eliminated the cascading failure problem that had caused the holiday outage: in a synchronous system, one slow service can block all others; in an event-driven system, services are decoupled.

We organised the microservices around banking domains: Account Management, Payments, Lending, Notifications, and Compliance. Each domain team owned their services end-to-end — from architecture to deployment to on-call. This was a significant organisational change as much as a technical one.

The engineering stack: Java 17 for core services, Kubernetes on AWS EKS for orchestration, Apache Kafka for event streaming, PostgreSQL for transactional data, Redis for caching, and a custom API gateway built on Kong.

Technology Stack

Apache KafkaKubernetesAWS EKSJava 17Kong API GatewayPostgreSQLRedisPrometheusGrafana
Have a similar challenge?

Let's talk about how we can deliver results for your organisation.

Start a Conversation
← Back to Case Studies