How to build a multi‑tenant micro‑finance SaaS that meets Kenya’s data‑residency rules

Decision brief: options for a multi‑tenant micro‑finance SaaS under Kenyan data‑residency

You have three realistic ways to deliver a SaaS platform that lets multiple micro‑finance institutions (MFIs) share code but keep their data in Kenya.

1. Define the residency requirement up front

Kenya’s Data Protection Act 2019 mandates that personal data be stored in Kenya unless a cross‑border transfer is expressly permitted. Your first deliverable is a data‑location matrix that lists every data element (customer profile, loan ledger, audit log) and the approved storage location.

If you choose a public cloud, pick a region that is physically in Kenya (e.g., Microsoft Azure Kenya or a local data‑centre partner). If you go on‑prem, the hardware must be in a Kenyan facility and you need a documented run‑book for backup and disaster recovery that also stays in‑country.

2. Choose the tenant isolation model

The choice impacts the system‑orchestration effort: separate databases need automated provisioning scripts, while shared databases need robust row‑level security policies.

3. Map the integration points

Most MFIs already run a legacy core banking system, a mobile money gateway (e.g., M‑PESA) and a reporting tool. During the discovery session (step 03 in our process) we produce:

• a diagram of existing systems,
• a list of required data flows, and
• a gap analysis for APIs or batch extracts.

Typical integration patterns are:

• API façade, a thin Node.js service that translates the SaaS API to the legacy system’s protocol.
• Scheduled ETL, a Python script that pulls nightly loan data, transforms it and writes to the SaaS tenant’s schema.

4. Build the core platform

If you go the build‑from‑scratch route, we follow the two‑week sprint cadence described on our process page. The first sprint stands up the Docker‑based CI/CD pipeline, Pulumi‑defined infrastructure and a basic Keycloak realm. Subsequent sprints add tenant onboarding, loan‑origination flows and reporting dashboards.

When re‑using Keycloak, the proof‑of‑concept step (our technical validation phase) creates a single realm and a test client to prove that the federation with the M‑PESA API works before any contract is signed.

5. Harden for compliance and resilience

• Encryption at rest, enable PostgreSQL Transparent Data Encryption in the chosen Kenyan region.
• Audit logging, configure Keycloak and the application to write immutable logs to an append‑only bucket that lives in‑country.
• Monitoring, Grafana dashboards and Prometheus alerts are provisioned via the same Pulumi stack so you can see uptime, latency and any data‑location drift.

All of these are part of the system‑orchestration service we offer.

6. Handover and long‑term support

Our handover includes:

• full documentation of the architecture,
• run‑books for scaling the tenant database,
• a monitoring configuration that the client can own, and
• a support contract that keeps us on‑site for the life of the system (our “stay‑and‑run” model).

If you need capacity without a permanent hire, the team‑as‑a‑service offering can embed senior engineers into your team for any phase.

7. Quick checklist for the first 30 days

• Sign NDA (step 02) and schedule a discovery session.
• Produce a data‑location matrix and get approval from the data‑privacy officer.
• Choose tenant isolation model and document the decision.
• Validate a single integration (e.g., M‑PESA payment callback) with a proof‑of‑concept.
• Agree on the hosting region and obtain a hosting‑contract clause that guarantees Kenyan residency.

Related reading

• Designing multi tenant SaaS for Kenyan banking compliance
• SaaS multi tenant approaches using Keycloak
• Scalable IT infrastructure what IT actually takes to build systems that grow with your business

If you’re ready to turn these steps into a concrete plan, talk to our team about it.

Photo by Tima Miroshnichenko on Pexels.