Uzima Health Microfinance: Post-Go-Live Failures in a Core Banking Migration
Uzima Health Microfinance migrated its core banking system over a weekend, covering 41 branches and 320,000 customers. The parallel run was cut from eight weeks to two to meet a board-imposed deadline. In the first month: 3,200 duplicate customer records were detected; 480 loan accounts have no mapped outstanding balance; the general ledger is out of balance by KES 7.3 million against the loan sub-ledger; twelve branches share a single login per branch; the IT administrator holds superuser rights and also approves his own change requests; the vendor retains unmonitored remote access. Nightly backups complete, but the last successful restore test was 14 months ago. A ransomware incident encrypted a test server three weeks ago. The recovery time objective is four hours; the last incident took three days to recover.
1. Assess the control gaps revealed by the migration and rank them by risk, distinguishing data integrity risk from access risk.
Read the worked answer
Data integrity failures (highest immediate risk - they corrupt every downstream report).
- 480 unmapped loan balances. The sub-ledger does not reconcile to the GL; customers' balances may be wrong. This is the most serious item because it is a direct financial and conduct risk: a customer may be pursued for a wrong amount, or write-offs may be overstated. It also makes regulatory returns unreliable.
- GL out of balance by KES 7.3 million against the loan sub-ledger. This is a symptom, not a cause - it is almost certainly the sum of the unmapped accounts plus duplicate postings plus opening-balance cut-over errors. Evidence of a missing reconciliation control, not a one-off.
- 3,200 duplicate customer records. Risk of duplicate lending, breach of single-borrower and connected-party limits, mis-stated customer counts, and failed KYC/AML screening. Duplicates also destroy the credit bureau reporting.
- Compressed parallel run (8 weeks to 2 weeks). Root cause. A two-week parallel run cannot surface month-end, quarter-end or interest-capitalisation behaviour. The deadline-driven decision removed the only control that would have caught all three data defects.
Access and change-management failures. 5. Twelve branches sharing one login. No attribution: no one can tell who posted a transaction or approved a loan. Destroys the audit trail and any fraud investigation. 6. Superuser who also approves his own changes. Combines the ability to change code or configuration with the ability to authorise it. In a core banking system this is an unlimited capability - it can alter balances, limits and interest rates. Severe. 7. Unmonitored vendor remote access. Third-party access that is not logged, not time-bound and not approved per session.
Resilience failures. 8. No restore test for 14 months, RTO 4 hours versus 3 days actual. The backup is an untested assumption. The ransomware event on a test server shows the threat is live and lateral movement reached a non-production environment.
Risk ranking: 1 (unmapped loans), 6 (superuser + self-approval), 8 (untested recovery), 2 (GL imbalance), 5 (shared logins), 3 (duplicates), 7 (vendor access), 4 (root cause).
2. Produce a 30-60-90 day remediation plan that addresses both the immediate exposures and the underlying cause.
Read the worked answer
Days 0–30: contain.
- Freeze and reconcile. Suspend automated write-offs, penalty postings and interest capitalisation on the 480 accounts; place them on a manual control list. Reconcile the loan sub-ledger to the GL account by account; identify the KES 7.3 million precisely rather than accepting the aggregate figure. Report the position to the board and, if material to capital, to the regulator.
- Fix access now. Disable the administrator's change-approval rights; split the roles. Enforce individual named accounts with unique credentials at all 41 branches within 14 days - the shared login is not a training issue, it is a policy breach.
- Vendor access. Revoke standing remote access; require session-by-session approval, time-boxed windows, full session recording and a named sponsor.
- Backup. Perform a full restore into an isolated environment this week and time it. Until a restore has succeeded, treat recovery capability as absent.
- Ransomware. Confirm the test server had no route to production; segment the network; patch; verify endpoint protection across all branches.
Days 31–60: correct.
- Duplicate clean-up. Match on national ID and phone where possible, merge with a documented and reversible rule, run AML screening again on merged records, and report the corrected customer count.
- Balance remediation. Produce a customer-by-customer statement for every affected loan; appoint a named officer to correct and communicate. Where balances are wrong, rectify and consider redress.
- Control rebuild. Implement automated daily sub-ledger-to-GL reconciliation with an exception report signed off by finance; add a hard system block on approvals that breach limits; add duplicate-detection at customer creation.
Days 61–90: prevent recurrence.
- Root-cause review of the cutover decision, with a written report to the audit committee on who waived the parallel-run standard and on what authority. Amend the change policy so a go-live cannot be approved by the project sponsor alone.
- Recovery objective. Redesign backup and DR to meet the 4-hour RTO, or formally re-set the RTO to what is actually achievable and disclose it. Test quarterly.
- Collateral remediation. The board minutes record the deadline-driven cutover; this was a management override of a key control and should be treated as such in the risk register, not as a project slippage.
3. The chief executive argues the KES 7.3 million imbalance is immaterial against a loan book of KES 2.4 billion. How would you respond?
Read the worked answer
The argument confuses size with consequence.
- 0.3% of the loan book is not the relevant measure. The relevant measure is whether the balance reported for any individual customer is correct. A KES 7.3 million aggregate can be made up of 480 accounts each wrong by KES 15,000 - immaterial in total, but each one a misstatement to a borrower and a potential conduct breach.
- Reconciliation differences do not behave additively. An imbalance is evidence that postings are failing, not that a fixed amount is missing. If the cause is unmapped balances, the difference will grow next month at the same rate. A steady KES 7.3 million next month would be a coincidence; a growing figure is the likely path.
- It contaminates other numbers. Interest income, provisioning, regulatory capital returns and the impairment charge are all derived from the same sub-ledger. A small GL difference can mask a large misclassification in the loan-loss charge.
- It is an audit and regulatory issue regardless of size. Itself it may be below materiality; but it demonstrates that a key reconciliation control is not operating, which is a control deficiency reportable to those charged with governance, and an inherent risk that the auditor must respond to in full.
- The ransomware event changes the risk appetite question. With an untested restore and a three-day actual recovery against a four-hour target, the firm cannot currently prove that KES 2.4 billion of loan records is intact. That is an operational resilience failure independent of materiality.
Response to the CEO. Accept the number may be small; reject the conclusion. Set a 30-day deadline to identify the composition of the difference and a 60-day deadline to clear it, and require the daily reconciliation to run as a standing control. Report both the deficiency and the remediation plan to the audit committee. If the CEO declines, escalate to the audit committee in writing - a chief executive who overrides a reconciliation control twice in one project is the risk itself.