Updated
Digital banking for 13 countries: one set of rules for shared capacity
Summary
A traditionally offline, field-based lending model became a digital ecosystem: mobile apps for customers and loan officers, integrated with core banking, built for 13 countries. My job was to get it live, keep it stable, and keep every stakeholder looking at the same picture.
Key figures
- 13countries
- 2.5M+client's customers
- 12k+client's loan officers
- 9+vendors and integration partners
Context
The client is a microfinance group that lends through field-based loan officers. Its legacy lending system had to move to a new core banking system, and both loan officers and customers needed new mobile applications. The ecosystem also involved country-specific banking switches, payment processors, AML/KYC providers, identity systems, SMS providers, Google services and mobile platforms, on a cloud-native footing (Azure AKS, OpenShift and Kubernetes). The environment was regulated, and connectivity in many markets was limited.
Challenge
Three things shaped the program.
Scale
13 markets with different regulations, business units and local budgets.
Ecosystem
9+ vendors and integration partners whose work had to line up.
Capacity
At critical moments one pool of roughly 30 engineers was wanted by several markets at once.
Starting point
A legacy lending system and a field-based, largely offline way of working.
Loan officers met customers in person and used a legacy web application that needed a VPN connection during those meetings.
My role
I led the program end to end as Service Delivery Manager and Program Manager at CSHARK, the delivery partner: pre-sales and solution shaping, planning, governance, rollout and the move into managed services. I was the main point of contact for the client's executives, up to CEO, CTO, COO and Chief Security Officer level. Engineering, quality and infrastructure teams did the building. My job was to keep scope, sequencing, risk and expectations in one line of sight.
What I did
Understand the business before choosing the solution.
I started with workshops with the client's teams to understand how lending works in the field, and we then worked in an agile rhythm with their representatives. I also advised the client on building the support team that would run the platform after go-live.
Give competing markets one prioritization mechanism.
Four significant demands competed for the same pool of roughly 30 engineers: a loan-officer app release and migration in one market, change requests for a market already live, a customer app release, and integration testing for a third market. Stakeholders sat in three markets, with one overall sponsor in Europe. I made the trade-offs explicit and offered the sponsor two options: strict priority order, or a weighted split of capacity across priorities. The sponsor chose the weighted split. Once it was agreed, no one could override it by escalating, and because each market had its own budget, a market that wanted more capacity could fund it. People understood why their work had its priority and what they could do to accelerate it.
Run governance that shows the truth.
I set up RAID management, KPI reporting, readiness reviews, Steering Committees and executive reporting, so that the client's leadership and our own saw delivery risk early. Vendors worked from one shared plan and one risk log, and escalation was reserved for what exceeded a person's decision authority or affected several streams.
Design for operations from day one.
The platform was built for availability: a Kubernetes-based solution with centralized monitoring, country-specific policy management and regulatory compliance, plus high availability, autoscaling, disaster recovery, Prometheus and Grafana observability and 24/7 operational governance. After go-live, delivery moved from project mode into managed services: Build the Bank first, then Change the Bank and Run the Bank.
The Kubernetes platform did not depend on one cloud: it had centralized monitoring and alerting, one set of access and security policies (RBAC), room for local regulation, and many countries on a single Azure subscription.
Prove it in one market, build it for all of them.
I started with a pilot in Ghana, on Azure Kubernetes Service, and we built the solution for all 13 markets: two mobile applications (one for customers, one for loan officers), a web application and the backend behind them, integrated with the core banking system. The stack also used AWS and ReactJS.
Outcome and evidence
The platform went live in three countries, and the software is prepared for all 13 markets. Governance and executive visibility held through the delivery, and the client moved into long-term operational support.
| Measure | Value | Basis | Scope note |
|---|---|---|---|
| Countries | 13 (Africa and Asia) | Program scope | Markets in scope of the program |
| Countries live | 3 | Production rollout | The software is prepared for all 13 markets |
| Client customers | 2.5M+ | Scale of the client | The client's customers across its 13 markets, not users of the new apps |
| Client loan officers | 12k+ | Scale of the client | The client's loan officers across its 13 markets |
| Vendors and integration partners | 9+ | Program scope | Coordinated through one plan and one risk log |
| Duration | About five years | Program length | Within 2019 to 2026 |
What the figures do not show
These figures describe the scale of the program, not the client's business results. Adoption, loan-portfolio or revenue effects belong to the client and are not published here. I worked on the delivery-partner side, so I do not claim the client's internal decisions. The prioritization example is described in general terms, and dates, markets and budgets are intentionally left out.
Learnings
- A prioritization mechanism beats escalation. When everyone can see the rule and the legitimate way to change it, escalation stops being the default lever.
- One control plane for many countries. Centralized monitoring with country-specific policy is what keeps 13 regulatory contexts manageable.
- Show the risk early and in one place. One shared plan and one risk log across 9+ vendors made problems visible while they were still cheap to fix.
Want the next case study when it is out?
An occasional email about my work, such as new case studies and articles.
Check your inbox
I sent you a link to confirm your address. Nothing is added until you confirm. The link works for 7 days.
Running a multi-vendor or multi-country program?
Describe where it stands and what is getting in the way.