Africa's Regulatory Failure Is Not a Law Problem

The Public Benefit Organizations Act passed by Kenya's National Assembly in 2013 is, by the standards of civil society legislation on the continent, a well-drafted instrument. Its policy framework is clear: public benefit organisations should be recognised, enabled, and held to a transparent accountability standard. Its drafters consulted widely with civil society practitioners. Its definitions are more precise than those of the legislation it replaced. Its regulatory architecture — an independent authority, a defined registration process, a set of obligations that are enforceable but not punitive by design — is what enabling civil society regulation should look like.

Registration rates did not meaningfully improve in the years following the Act's operationalisation.

This is the puzzle that this essay is about. And the puzzle is not unique to Kenya. Across East and West Africa, the past twenty years have produced a generation of civil society legislation that is substantially better-designed than what preceded it, and substantially less complied with than its architects anticipated.¹ The gap between the quality of the law and the compliance rates it achieves is consistent enough to require a systemic explanation.

The explanation is not the quality of the law. It is the absence of the translation layer.

The Translation Gap Defined

A regulatory framework has two components. The first is the normative component: what the law requires, what the penalties for non-compliance are, what the rights and obligations of regulated parties are. This is what legislators and lawyers produce. It is what gets debated in parliament, published in the Kenya Gazette, and argued about in courts.

The second component is the operational component: how a regulated party, sitting in an office or a community centre or a rural clinic, navigates from "I need to comply with this" to "I can demonstrate that I do." This is the translation layer — the set of tools, knowledge, advisory services, and institutions that make the normative framework navigable for the organisations it governs.

In well-resourced regulatory environments, the translation layer is dense. Tax compliance in most OECD countries is supported by software products that encode the tax code's requirements into a process that a non-specialist can navigate.² Employment law compliance is supported by HR software that flags violations before they occur. Environmental reporting is supported by platforms that automate the data collection and submission that regulatory compliance requires. The law is not simpler in these environments. But the translation layer is so well-developed that the effective complexity — the complexity experienced by an organisation trying to comply — is low.

In Kenya, and across most of Africa's regulatory landscape, the translation layer is thin. This is not a criticism of regulators, who are typically operating with limited resources and cannot themselves provide the advisory and support infrastructure that would make compliance accessible. It is a structural observation about where investment has and has not gone. Significant effort has gone into improving the normative component: better laws, clearer regulations, more enabling policy frameworks. Very little effort has gone into building the translation layer.

The Pattern Across Domains

This pattern repeats across regulatory domains in Kenya with enough consistency to be considered structural rather than sector-specific.

The Companies Act, No. 17 of 2015, modernised Kenya's company law framework substantially.³ Its reporting requirements for small and medium enterprises are more clearly specified than those of its predecessor. SME compliance rates with annual filing requirements have not improved at the rate the reforms anticipated.

The Kenya Revenue Authority's iTax system is a genuine improvement on the paper-based system it replaced — it encodes the income tax framework in a navigable digital interface, and it has demonstrably improved compliance rates among formally registered businesses.⁴ The improvement is, in significant part, a translation layer story: the normative framework did not change, but the interface through which businesses navigate it became substantially more accessible.

In the environmental sector, Kenya's Environmental Management and Co-ordination Act imposes specific reporting requirements on projects above certain environmental impact thresholds. Compliance among small and medium enterprises is low — not primarily attributable to ignorance of the law, but to the absence of systems that make the reporting process navigable without specialist environmental consultants.

The WASH sector provides the most direct evidence from our own work. Kenya's Water Act 2016 imposes data reporting obligations on licensed water service providers.⁵ The data that utilities are required to report on service delivery, water quality, and network performance is, in principle, available in their operational systems. In practice, many utilities are reporting it manually, using paper aggregation processes that introduce errors and delays that make the data unreliable as a regulatory signal. AccessWASH's deployment work has shown, repeatedly, that the constraint is not the willingness to report — it is the absence of the operational data infrastructure that would make compliant, accurate reporting feasible without significant manual effort.⁶

What Is Encodable and What Is Not

Not all compliance requirements are equally amenable to software encoding. Requirements that involve genuine legal judgment — determining whether an organisation's activities qualify as "public benefit" within the meaning of the Act, or whether a specific transaction constitutes a conflict of interest in a novel factual context — require human interpretation. These are genuinely hard cases, and I am not suggesting that software replaces the judgment they require.

But a significant proportion of regulatory compliance requirements are procedural rather than interpretive. They ask: is this provision present? Has this return been filed? Does this board composition satisfy this requirement? These are checkable. They are automatable. And they are scalable in ways that human advisory services are not.

The question of where to draw the line is not theoretical — it is a practical question that software builders working in specific regulatory domains have to answer by examining each requirement in detail. PBOMaster's experience building the constitution analyser is instructive: the vast majority of the PBO Act's constitutional requirements turned out to be procedural. The hard cases — the public benefit objectives determination being the clearest example — are a small fraction of the total compliance burden. The encodable fraction is large enough that software can close most of the compliance gap even without addressing the genuinely interpretive cases.

TurboTax as the Model

The argument I am making is not original. It has been made, in the tax domain, by the software products that encode tax law for individual and small business filers. TurboTax's commercial success is, in significant part, a translation layer story: it took a normative framework — the US Internal Revenue Code — that requires specialist knowledge to navigate unaided, and built the translation layer that makes it accessible to most taxpayers.⁷ The tax code did not simplify. The translation layer arrived. Compliance rates among software-using filers are higher than among paper filers because the software closes the capability gap.

The argument for building equivalent translation layer infrastructure in African regulatory contexts is precisely analogous. The laws are, in many cases, already good enough. The bottleneck is the translation layer that makes them navigable. The software required to build it is neither technically complex nor expensive relative to the regulatory capacity-building programmes that the development sector funds at much greater cost with much less consistent impact.

PBOMaster is one instance of this. The long-run vision is not one compliance tool per regulatory domain. It is a platform architecture that can encode any well-specified regulatory framework and expose it through a consistent compliance interface. The bottleneck is not the technology. It is the work of reading each regulatory framework carefully enough to identify which requirements are procedural and therefore encodable, and then doing the encoding with sufficient precision to be reliable.

That is the work. The five essays in this cluster have made the case for why it is worth doing. The essay that follows asks a different question: what does it mean, across all of Flux's products, for software to do the work entirely — not to assist a human through a process, but to be the process?