Data Residency Without a Forked Platform

Your regulator wants the data in-country. Your CFO wants one platform. Most lenders assume they have to pick.

The assumption is reasonable, because most lending platforms force the choice. When the application and its data are welded together, serving a second country means either moving data across borders, which the regulator may prohibit, or standing up a second copy of everything, which doubles cost and splits every future upgrade in two. Multiply by five markets and the platform strategy quietly becomes a fork-maintenance programme.

The way out is to separate the two questions that get conflated: what must stay in the country, and what merely runs the business.

What Segregates, What Shares

On the architecture underneath the Lending Labs LOS, each country operates its own isolated stores: a dedicated database instance, an event database for audit and compliance, document storage, country-specific master data and workflow configuration, and the local regulatory integrations, credit bureaus and KYC providers included.

What stays centralized is everything a regulator has no residency opinion about: application code and platform services, the integration hub and common API layer, authentication, analytics, AI services, and the test automation framework.

That split is the whole trick. The expensive things to duplicate are shared. The regulated things are segregated by default.

Two Deployment Models, One Governance Source

Regulatory regimes differ on a crucial detail: some require in-country storage, others require in-country processing. The platform supports both.

Model A: shared service layer, isolated data stores. A single deployment runs the service layer for all countries, while PII is held in jurisdiction-specific stores. This maximises reuse, keeps cost lowest, and onboards new markets fastest. It satisfies regimes where storage residency is the requirement.

Model B: fully separate per-country instances. Where the regime demands that runtime and data both stay in-jurisdiction, each country runs its own self-contained deployment: full service stack, configuration bucket, and PII store, with no cross-border runtime link. Audit evidence for residency gets simpler, incident blast radius gets smaller, and regulator sign-off gets easier.

The key property holds in both models: configuration is managed from one central source and deployed to each instance. Central governance survives full runtime isolation. A policy change, a new document template, an updated rule: defined once, versioned, and rolled out to every market it applies to, with automatic rollback if an activation fails.

Running in Production

This is not a whiteboard pattern. Baobab Group, Africa's leading microfinance platform serving about 1.6 million customers across seven markets, runs the Lending Labs LOS live in Nigeria and Senegal on a single rollout, in English and French, with per-country data isolation, and further markets in the pipeline on the same installation.

One platform, one configuration source, one team maintaining it. Separate databases, separate audit stores, separate documents, per country.

The Question to Ask Your Vendor

Does your regime require residency of storage, or residency of processing? Then ask how the platform handles whichever answer you got, without forking the codebase. If the response involves a second implementation project, you are not buying a multi-country platform. You are buying the first of several platforms.