A national sandbox framework for Namibia: one technical layer, three supervisors, every decision left with the regulator

The gap

The Bank of Namibia runs its FinTech Innovations Regulatory Framework with two programmes, Allow-and-See and the Regulatory Sandbox. NAMFISA runs a seven-stage guidance note for its cohorts. CRAN has published a direction for an ICT sandbox but no published policy, criteria or dates. Each process is paperwork and meetings. A firm still cannot show, at low cost and under supervision, what its product does when a payment times out, a consent expires or a duplicate request arrives.

Products also cross mandates. Mobile money and USSD touch payments and communications. A microlending service delivered over mobile touches NAMFISA and CRAN. Without shared infrastructure, a firm answers two sets of technical questions on two disconnected systems, and each supervisor pays to build the same capability.

What the framework proposes

The proposal has four working layers and one more which runs through them. The first layer is each supervisor’s own regulatory process, unchanged. The second is testing, which is shared: synthetic Namibian data, reference interfaces shaped on the open banking standards, simulated payment rails, isolated workspaces and named fault scenarios. The third is supervision, held separately in each supervisor’s own space. The fourth is policy analysis, optional for each supervisor, where findings need a named expert’s approval before anyone sees them. Assurance runs across all four: identity, tenant isolation, a tamper-evident audit trail, data lifecycle, resilience and control of third parties.

The strategy is stated in three sentences. Give each supervisor evidence-grade technical testing under its own process, built once and shared. Serve the financial and communications supervisors and the firms they admit. Run it as a shared, supervisor-tenanted service whose data is stored in Namibia.

The limits are the design

Eight boundaries are written to hold in every section. The supervisor decides admission, track, caps, suspension and exit. An exit record is evidence, not a licence, authorisation or designation, in its wording, its styling and its content. Only synthetic data enters, and a scan checks each seed. No live connection to any operator, rail or register exists. Process is configuration, so a supervisor changes its stages by changing data. Findings are advisory until a named expert approves them. Real data stays in Namibia, and enters only after a cut-over rule is met. Every component carries a plain label: live, seeded or planned, and every simulation is called a simulation.

A decision-rights table puts the point in one place. The platform records and enforces. It never assigns a track, never grants a licence or exemption, and never approves a policy finding. The custodian, proposed to be the ministry responsible for information and communication technology, holds the text, the version register and change control, and decides none of the cases.

Why synthetic data and why a model, not a mock

Synthetic data removes the chicken-and-egg problem. A firm cannot test against real customers before it is supervised, and a supervisor cannot supervise without evidence. A scan on every seed checks for patterns shaped like Namibian identity numbers, phone numbers and email addresses, so the claim of synthetic-only data is checked, not assumed.

The payment rails are modelled to fail where the real system fails. A bank accepts a payment and it is not yet final. An instant payment cannot be recalled. A clearing batch misses its cut-off. A mock accepts everything, which tells a supervisor nothing. A faithful model produces results which predict how a product behaves later against a real interface. Four invariants guard the model: accepted is not settled, irrevocable means irrevocable, every money movement leaves a reconciliation record, and time is real.

What would have to be true

The framework is candid about its own status. No charter is in force, no custodian is confirmed, and an independent review is still to be scheduled. It asks for two things: a conversation with each supervisor about how its process runs today, so the picture is corrected, and, afterward, one decision on whether to charter a bounded pilot.

What supervision looks like in the proposal

The third layer is where a case officer works, and the proposal describes it in concrete terms. Applications, assigned supervisors, review logs and requests for information sit in one case record. Each decision, such as assigning a track or admitting a firm, is stored as an append-only event naming the person who decided, the instrument relied on and the reason, and it requires strong authentication within a fresh time window. A service account never qualifies as the decider. Testing agreements record caps on consumers, value and volume, indicators, reporting cadence, disclosure and capital safeguards, and breach checks measure a firm against those caps and never against the platform’s opinion of risk.

The oversight view has two modes, kept visibly apart. Sandbox observation shows operational evidence: application state, cap use, incidents, technical traces and rail health. Policy analysis shows pre-official findings. The separation exists because a finding is not a breach. Reports draw on the records the test produced, so late reports show as late, and an exit record carries an onward path the supervisor chooses: apply for authorisation, extend, pivot and reapply, or wind down in order.

A financial crime workflow shows the same restraint. Names are screened against a list of invented names, hits become cases, and a reviewer approves each draft suspicious transaction report before a simulated submission. The reporting clocks of the Financial Intelligence Act regulations run from the moment suspicion arises and show a deadline on each draft. Nothing reaches the Financial Intelligence Centre. The workflow trains a process and produces evidence. It does not file anything.

The participant’s journey

The proposal describes seven steps from the firm’s side. Apply once, with a business plan, test plan, risk assessment, safeguards, consumer benefit case, complaints process and exit strategy, with required items configured per supervisor and track. Assigned supervisors review the same application through their own rubric, and the eligibility snapshot is labelled advisory. A testing agreement records caps, indicators, reporting cadence, disclosure requirements and the retention window for test data. A governed workspace opens with a development environment, synthetic data sets and the relevant reference interfaces, with named faults available as tests. The firm is then tested under observation, reports, and exits with an evidence record.

The firm sees its own supervised status, what its supervisors see, and nothing else. The proposal also spells out what happens when a test goes wrong. A firm exceeds a value cap and then misses its monthly report. The platform states the facts, and the supervisor decides what they mean. This design avoids two failures: a platform which quietly punishes firms, and one which hides breaches.

Consumers and inclusion inside a test

The sandbox itself holds only synthetic data, but the proposal looks ahead to supervised tests with real consumers under caps. In such a case, the consumer sees a plain-language disclosure naming the supervisor and the complaints route, sees the fee and status before confirming, sees accepted and settled as two separate states, and has a complaints route needing no smartphone: USSD, a call or a branch. A test feature is never presented as a fully licensed public service.

Inclusion is treated as a requirement with evidence. The proposal lists checks which each produce a recorded result: disclosure in plain language and local languages, USSD messages fitting length limits, interrupted sessions and low connectivity, privacy in agent-assisted transactions, accessible web screens, a low-bandwidth rural scenario, comprehension of fraud warnings, complaints without a smartphone, and clear labelling so test and live are never confused.

What this means for organisations in Namibia

A supervisor reading the proposal should check two things first: the decision-rights table, to see whether any action is wrongly allocated, and the list of boundaries, to see which it would add or remove.

A firm preparing for any of the three processes should keep its test evidence in a form a supervisor inspects: what was tested, on what data, with which faults, and what the product did.