Choosing or Building a Core Banking Platform for Kenyan SACCOs

Decision framework for a SACCO core banking platform

Build vs buy

The first fork in the road is whether to buy an off‑the‑shelf core banking suite or to develop a custom platform.

A bought solution usually offers a ready‑made feature set and a vendor‑managed upgrade path, but it can lock the SACCO into licensing fees and may require extensive customisation to fit local processes.

A custom build gives you full control over data models, branding and integration points, and lets you embed the Kenya Data Protection Act 2019 compliance from day one. The trade‑off is higher upfront effort and the need for a partner who will stay on for the system’s operating life, which is exactly how we work at Afriq Silicon, we build the software institutions run on and we stay to keep it running How we work.

Use the checklist below to decide which path matches your constraints:

Regulatory compliance checklist

Kenyan SACCOs must satisfy several statutory requirements before a core banking system can go live:

• Kenya Data Protection Act 2019, enforce data minimisation, consent records and breach notification.
• Central Bank of Kenya (CBK) guidelines, include audit trails, role‑based access and segregation of duties.
• GDPR, applies when you process personal data of EU citizens; the same technical controls (encryption at rest and in transit, data subject rights) work for both regimes.

During the discovery session the engineering team maps the existing data flows and validates that the proposed architecture can produce the required logs, encryption keys and access controls. The resulting proposal lists the stack and explains why each component meets the regulatory points Strategic consultancy.

Architecture for low‑connectivity environments

Many SACCO branches operate on unstable power and limited bandwidth. Design the platform with these constraints in mind:

• Containerised services (Docker) packaged with the same image across all sites, so a branch can run the same code offline and sync when connectivity returns.
• CI/CD pipeline (GitHub Actions) that builds immutable images and pushes them to a private registry; the registry can be mirrored on a local server for branch use.
• Database replication, PostgreSQL with logical replication to a read‑only node at the branch; writes are queued and applied centrally when the link is up.
• Message queue, lightweight broker (e.g., NATS) that buffers transactions locally and guarantees at‑least‑once delivery.

These patterns are part of our system‑orchestration service System orchestration and have been used in projects like the banking reconciliation tool Joinery.

Integration strategy

A core banking system rarely lives in isolation. Typical integration points for a SACCO include:

• Mobile money APIs (M‑PESA, Airtel Money), use a payment callback contract that validates signatures before posting a transaction.
• Accounting packages (Xero, QuickBooks), expose CSV or PDF exports; the platform should generate them on demand and store them in a secure bucket.
• Government reporting, build a scheduled job that formats data to the CBK filing schema and pushes it via a secure SFTP.

During the technical validation phase we build a small proof‑of‑concept for each critical API. This keeps the timeline predictable and surfaces any third‑party limitations early How we work.

Implementation approach

Afriq Silicon follows a repeatable, two‑week sprint cadence that aligns well with procurement milestones:

1. First contact, capture high‑level goals and schedule the discovery session.
2. Confidentiality, NDA signed before any sensitive data is shared.
3. Discovery session, engineers produce a system map, agreed objectives and a technical fit assessment.
4. Proposal, written scope, architecture rationale, milestone timeline, cost breakdown, stack recommendation and post‑launch support plan.
5. Technical validation, proof of concept for any untested integration or data migration.
6. Scope and cost agreement, iterate until the plan fits the SACCO’s approval process.
7. Contract, the proposal becomes a binding contract.
8. Milestone mapping, two‑week increments with clear deliverable dates and payment triggers.
9. Kick‑off and environments, Docker packaging, Pulumi IaC and GitHub Actions are standing up the pipelines before the first feature lands.
10. Two‑week sprints, each ends with a demo, a retrospective and an updated backlog.

At the end of the last sprint the team hands over a fully documented, monitored system and a runbook that the SACCO can operate. Because we stay for the operating life, any future enhancements or incident responses are covered under the same engagement model.

Related reading

• Designing multi tenant SaaS for Kenyan banking compliance
• Choosing a migration workbench for legacy system modernisation in Africa
• What we ve learned connecting business systems in Africa a practical guide to enterprise system integration

Ready to turn the decision framework into a concrete plan? Talk to our team about it.

Photo by Christina Morillo on Pexels.