← Back to Blog

Safeguards by Design in DPI Sandboxes

Safeguards by Design in DPI Sandboxes

Most national digital public infrastructure (DPI) sandboxes are designed to answer a single question: does a participant's system integrate correctly with the platform? Safeguards by Design in DPI Sandboxes, BrightCore Technical Framework No. 1, argues that this is necessary but not enough. Once a bank, fintech or agency is live on a national payment rail or data-exchange layer, fixing weak consent flows, poor error handling or exclusionary design becomes costly, and citizens bear part of that cost. The sandbox is where the rules of engagement are set, and because the testing environment, data and technical staff already exist, it is also the cheapest place to embed safeguards.

The framework organises testing into five domains: functional interoperability, data protection and consent, consumer protection and recourse, inclusion and resilience, and security. Each domain has a clear guiding question, a primary reviewer and an illustrative catalogue of tests with pass criteria and required evidence. Examples include checking that payee lookups reveal only the minimum personal data, that failed or timed-out payments are clearly communicated and resolved, that core journeys work on USSD and under poor connectivity, and that participant access follows least privilege with proper audit logging. Operators are encouraged to adapt the tests to their own specifications and legal frameworks, such as Rwanda's Law N° 058/2021 on the protection of personal data and privacy.

To ensure testing actually changes outcomes, the framework links it to four graduation gates: sandbox entry, conformance, controlled pilot and production. Participants declare their use case and the personal data they need at entry, must pass the interoperability and security domains in full before progressing, and move through a capped, monitored pilot before full go-live. Obligations are then written into participation agreements, with periodic re-testing after major changes.

The framework also calls for the sandbox to be governed and funded as a permanent shared service rather than a temporary project environment, with defined roles for the platform operator, central bank, data protection authority and sector ministries, and subsidised access for small participants, students and community finance institutions. It closes by showing how the same five domains can be tracked after go-live through indicators such as failed-transaction rates, complaint resolution times and channel usage. The framework draws on the author's experience supporting the design and implementation of Rwanda's national DPI sandbox, including a Mojaloop-based payment test environment, and is written to apply to any country operating instant payment, identity or data-exchange sandboxes.

More Information can be found on the file attached.

Attached Document

BrightCore_Framework_Safeguards_by_Design_in_DPI_Sandboxes.pdf