Writing

Regulation as Code: The Capability African Fintech Diligence Keeps Missing

Lanre Ibraheem, Founder and Principal  ·  December 2025

A circular lands on a Friday afternoon. The central bank has changed a KYC threshold, adjusted a settlement window, or introduced a new data residency requirement, and it takes effect in thirty days. Somewhere in the company, that document has to become code running in production. How long that journey takes, and how safely it happens, is one of the most predictive facts about a fintech operating in an African market. It is also a fact most diligence never surfaces, because it lives in engineering, and diligence teams file regulation under legal.

I have built inside regulated financial infrastructure for a decade, in markets where the regulator moves often and sometimes without warning. What that decade left me convinced of is that regulatory responsiveness in these markets belongs to engineering as much as it does to compliance, and that it can be assessed the way any other technical capability can.

Where do the rules live?

The first question I ask an engineering team is where their compliance rules exist in the system. The answers sort companies quickly. The strongest platforms keep thresholds, limits, document requirements, and jurisdictional variations in configuration, owned in one place, versioned, and changeable without a deployment. At the other end of the scale, the same rule turns out to be hardcoded in seventeen services by engineers who have since left, and nobody can say with confidence where all the copies are.

The second kind of company can still be compliant today. What it cannot be is compliant quickly, and in a market where the rule will change again, the gap between those two states is where the risk sits.

Who owns the change?

The next question is organisational. When a directive arrives, whose job is it to translate the regulatory text into a technical specification, and whose job is it to ship it? Companies that handle this well have a named path: compliance interprets, engineering owns a defined intake, and the work is treated as a first class product priority rather than an interruption. The ones that handle it badly treat every circular as a fire drill, pulling in whoever happens to be free and rediscovering the affected code paths from scratch each time.

You can read this history in the commit log and the incident channel. How long did the last three regulatory changes take from circular to production? Was anything switched off in the interim? Did anything break downstream? Three data points make a trend, and the trend is what an investor is actually buying.

The window of exposure

Between the effective date of a rule and the deployment of the code that implements it, a company is in one of two states. Either it is operating out of compliance, or it has switched off the affected product line. Both are expensive. The first risks the licence that the entire enterprise value depends on. The second turns a regulatory change into a revenue event, and in payments businesses with thin margins, a fortnight of a disabled corridor is visible in the quarter.

This is why the speed question matters more in Lagos, Nairobi, or Cairo than it does in London. The rules simply change more often and with less notice, and the regulator’s patience is harder to predict. A platform built for a stable regime imports a fragility that no amount of code quality elsewhere offsets.

What good looks like

The strongest teams I have seen treat regulation the way they treat any other volatile dependency. They externalise rules into configuration with a clear owner, and they keep a test suite that encodes the current regulatory position, so a change arrives as a change to tests before it becomes a change to code. Jurisdiction specific behaviour sits behind feature flags, which lets a new rule be staged, verified, and switched over on its effective date instead of rushed into a release the night before. And the audit trail can show the regulator not only that the company complies, but when each version of each rule was in force.

None of this is beyond a Series A company. It is a set of decisions, and the companies that made them tend to have made other good decisions too, which is why this single capability reads as such a strong proxy for engineering quality overall.

For an investor, the practical takeaway fits in one line of a diligence agenda. Ask the engineering team, not the lawyers, to walk through the last regulatory change end to end. The answer will tell you more about the next five years of the company than the licence binder will.