The CBN Regulatory Sandbox 2026: A Simple Practical Guide for Fintechs and Data-Enabled Financial Services Businesses

On August 12, 2026, the Central Bank of Nigeria (CBN) opened applications for Cohort 2 of its Regulatory Sandbox Programme. Applications close August 31, 2026 — a short window for what is relatively, a document-heavy application. This guide breaks down what the Sandbox is, what’s new in Cohort 2, and what your business needs to have in place before making the application.

1. What is the CBN Regulatory Sandbox?

The Regulatory Sandbox is a controlled environment in which innovators — fintechs, financial institutions, technology providers, including virtual asset businesses — can test new financial products, services, and business models with real users, under CBN supervision, prior to full commercial launch.

The essence of a Sandbox is to let both sides learn safely. The innovator gets to test a product that may not yet fit neatly into existing regulations, with defined boundaries around user numbers, transaction volumes, and testing duration. The CBN gets early visibility into how the product actually behaves, which then feeds into how it regulates that category going forward. Admission to this Sandbox is neither a product endorsement nor an operating license. It is a supervised trial run with a transition plan built in from inception.

2. What has changed in Cohort 2?

Cohort 2 introduces a dual-track structure. Whereas the pilot cohort was more general in scope, this cohort splits applicants into two dedicated lanes:

First track

The Virtual Asset Service Provider (VASP) Track — covers stablecoins, virtual asset payments, custody, wallets, tokenised products, and related infrastructure.

Second track

The Data-Enabled Financial Services Track (also referred to as the Non-VASP Track) — covers innovations built on permission-based data sharing, including Open Banking use cases, account aggregation, payment initiation, credit analytics, and fraud prevention.

This is a meaningful shift. Virtual assets are now being brought into a formal, supervised testing pathway for the first time by the CBN, instead of a continued existence in a regulatory grey zone. At the same time, data-enabled financial services now have their own dedicated lane, explicit eligible-activity categories, and a direct link to Nigeria’s Open Banking rollout.

3. Who can apply?

The CBN is currently accepting applications from a broad range of companies described below:

1. CBN-licensed institutions developing new financial or payments solutions.
2. Institutions licensed by other Nigerian regulators (SEC, NAICOM, PenCom, etc.), where the innovation touches payments, digital financial services, or data usage.
3. Foreign-regulated institutions, where the innovation can be adapted to the Nigerian market and meets Sandbox entry requirements.
4. VASPs, including stablecoin issuers, exchanges, custodians, and wallet providers.
5. Startups and technology companies with no existing financial licence at all — provided the product is genuinely built and ready for live testing.

That last category is significant for our growing ecosystem. It is not required for a company to hold an existing licence to apply to the Sandbox. What the company needs is a working product that has moved past the idea stage. The CBN has been explicit that pure concepts, pitch decks, or business plans without a working product will not qualify — your Company needs at minimum a functioning MVP that has already undergone some internal or external testing.

4. Which of the two tracks applies to your company?

The dividing line is reasonably clean:

• Go VASP Track if the company’s product involves virtual assets, stablecoins, tokenised instruments, digital wallets, custody, exchange services, or fiat on/off-ramp arrangements.
• Go Non-VASP / Data-Enabled Financial Services Track if the company’s product is about using customer-permissioned data — Open Banking data exchange, account aggregation, payment initiation, credit decisioning, affordability assessment, debt recovery analytics, or fraud/risk analytics — without touching virtual assets.

A handful of businesses will sit close to the division line — for example, a platform that does account aggregation but also offers a stablecoin-based savings wrap. In those cases, the more defensible approach is usually to lead with the track that reflects the core regulatory risk of the product, and to disclose the secondary functionality clearly in the application rather than let the CBN discover it during assessment.

5. What does the Data-Enabled Financial Services track actually cover?

The CBN has set out specific eligible activity categories for this track:

1. Open Banking data exchange — accessing bank or financial institution data via standardised APIs.
2. Account aggregation — pulling data across multiple accounts/institutions into a single view.
3. Payment initiation services — initiating payments on a customer’s behalf using their permissioned account data.
4. Fraud prevention and real-time risk analytics — using transaction and behavioural data to detect and prevent fraud.
5. Credit decisioning, affordability assessment, and recovery — using alternative data sources to assess creditworthiness or manage collections.

The regulatory emphasis across all of these is consistent: financial inclusion, alternative data-driven credit assessment, lower onboarding/transaction/compliance costs, and — critically — consumer trust, transparency, and control over their own data. If the company’s product doesn’t visibly advance at least one of these outcomes, the company’s application narrative needs work before submission.

6. What does “permission-based data sharing” mean in practice?

This is the operating principle underneath the entire Non-VASP track, and it’s worth being precise about it, because it’s a legal and compliance concept as much as a technical one.

In practice, it means:

• The customer must give explicit, informed consent before their financial data is shared with a third party.
• Consent should be time-bound, with a clear expiry, and the customer should be able to withdraw or opt out at any point.
• Data sharing happens through standardised, secure APIs — not scraping, screen-grabbing, or informal credential-sharing arrangements, which the CBN’s Open Banking framework treats as a risk to be phased out.
• The customer retains visibility and control over what is shared, with whom, and for how long.

For applicants, this means the consent architecture — not just the company’s product UX, but the actual legal and technical mechanics of how consent is captured, logged, renewed, and revoked — is something the CBN will want to see documented, not just as described in a pitch deck.

7. What should an applicant have ready before applying?

Before opening the application portal, you should be able to check off:

1. A legally incorporated company with identifiable shareholders and beneficial owners.
2. A working MVP or production-ready product, not a concept or a deck.
3. Market-ready technical infrastructure, including evidence it’s been tested (internally or externally).
4. AML/CFT/CPF controls appropriate to your business model.
5. Consumer protection measures — disclosures, complaints handling, and redress mechanisms.
6. A defined testing plan, including target user segments, expected volumes, and success metrics.
7. Identified management and compliance personnel — including someone accountable for AML/CFT oversight.
8. Cybersecurity and risk management controls, with supporting documentation.
9. The full set of supporting corporate and governance documents (see below).

Notably, your company doesn’t need live customers before applying — however there is a need to clearly articulate who your intended customers are, your expected volumes, and how testing will be structured.

8. What documents/information will CBN expect?

Expect the application to require documentation across eight broad categories:

1. Corporate and ownership information — incorporation documents, shareholding structure, beneficial ownership (anyone holding 5%+ must be disclosed), source of funds, and PEP status declarations.
2. Governance and management information — board composition, senior management, and designated accountability for compliance, risk, and technology functions.
3. Financial information — audited financial statements where available; management accounts and other evidence of financial resources and sustainability where audited accounts don’t yet exist. There’s no fixed minimum capital requirement, but you must show you can sustain the testing period.
4. Product and business model documentation — how the product works, target market, revenue model, and how it fits within the chosen track.
5. Technology and cybersecurity documentation — system architecture diagrams, evidence of security testing (including penetration testing where applicable), incident response procedures, and vulnerability management processes.
6. Risk management and compliance documentation — AML/CFT policies, risk assessments, transaction monitoring and sanctions screening frameworks, staff training programmes, and customer due diligence procedures.
7. Consumer protection and data privacy documentation — including designation of a Data Protection Officer where applicable, and how customer funds or data will be safeguarded and segregated.
8. Track-specific documentation — for VASPs, this extends to reserve management, attestations of reserves, redemption mechanisms, and wallet/custody architecture (hot, warm, cold allocations, key management).

If any part of your technology stack or compliance function is outsourced, you’re expected to disclose the third-party providers, their roles, associated risks, and how you’re overseeing them contractually.

9. How should the Sandbox testing plan be constructed?

Your testing plan is arguably the single most scrutinised part of the application, because it’s the mechanism through which the CBN manages its own risk exposure to your product. A strong testing plan typically addresses:

• Scope and boundaries — defined limits on user numbers, transaction volumes, geographic reach, and customer categories (e.g., excluding vulnerable customers or capping exposure per user).
• Duration of a proposed testing period with clear start and end points, and criteria for what “successful” testing looks like.
• Success metrics — quantifiable indicators tied back to the regulatory outcomes (inclusion, cost reduction, fraud reduction, consumer trust).
• Risk controls during testing — how the Company monitors for and respond to issues in real time.
• Reporting cadence — what the company reports to the CBN, and how often, during the testing window.
• Incident escalation — a clear protocol for material incidents (cyber incidents, fraud events, consumer harm), which must be reported promptly under Sandbox rules.
• Exit and wind-down plan — what happens to customer data, funds, and open positions if the Sandbox period ends without progression to full licensing, or if testing is terminated early.

Note: The testing plan should be treated as a live risk-management document, not a marketing document. Assessors are specifically evaluating “risk management capability” as one of the core admission criteria, and a testing plan that reads as commercial rather than operational is a common weak point.

10. What legal, compliance, consumer-protection and cybersecurity issues should applicants think through?

A few areas deserve early legal attention, before the application is drafted:

• AML/CFT/CPF architecture: this needs to be a functioning control environment, not a policy document sitting unused. Assessors will want to see transaction monitoring, sanctions screening, CDD procedures, and training in practice.
• Data protection compliance: under the Nigeria Data Protection Act, your data flows, lawful basis for processing, retention periods, and cross-border transfer arrangements (if any) all need to hold up independently of the Sandbox application.
• Consumer protection and disclosure: clear, accessible risk disclosures to test users, a functioning complaints-handling process, and a redress mechanism if something goes wrong.
• Cybersecurity governance: documented information security policies, access controls, vulnerability management, and evidence of testing (penetration testing where relevant to your risk profile).
• Safeguarding of customer funds/assets — how funds or digital assets are segregated and protected, particularly relevant for VASP track applicants handling custody.
• Third-party and outsourcing risk: contractual and oversight arrangements for any outsourced technology, compliance, or operational functions.
• Cross-border considerations: if your customers or operations span multiple jurisdictions, you’ll need to articulate the regulatory considerations and risk mitigation for each.

Given the CBN’s stated intention to coordinate Sandbox information with other authorities — including securities, financial intelligence, tax, national security, and data protection regulators, applicants should assume the information disclosed in the Sandbox application may be seen by, or shared with, agencies beyond the CBN itself. This is a reason to get the legal positioning right from the outset, not to retrofit it later.

11. How does the Sandbox interact with Nigeria’s Open Banking framework?

The Data-Enabled Financial Services track is, in effect, the supervised testing ground for products that will eventually operate within Nigeria’s Open Banking ecosystem. The regulatory backdrop:

• The CBN issued the Regulatory Framework for Open Banking in February 2021, followed by Operational Guidelines in March 2023, setting out consent rules, a tiered API access model, and the concept of an Open Banking Registry (OBR).
• Rollout was originally targeted for August 2025 but was deferred to allow for stronger automated data-protection and consumer-protection infrastructure; implementation is now being phased through 2026, with the Nigeria Inter-Bank Settlement System (NIBSS) designated to operate the Open Banking Registry.
• Under the framework, participants are categorised by role (API Provider, API Consumer, and others) and by tier, with access to more sensitive personal and transaction data reserved for entities that meet higher licensing and risk-maturity thresholds.

For applicants building on Open Banking rails, Sandbox participation is a practical way to test your company’s product against these evolving standards — API consent flows, data categorisation, registry participation — before the full Open Banking regime is live and enforced. It’s also a signal to the market and to future partners (banks, in particular) that the company’s data-handling practices have been through supervised scrutiny. Businesses should expect that Sandbox outcomes in this track will feed directly into eventual Open Banking Registry participation requirements.

12. What happens after admission?

Admission is the start of a supervised period, not the end of the regulatory process. Successful applicants should expect:

• Formal onboarding, including agreed testing parameters (user limits, volume caps, duration).
• Ongoing reporting obligations to the CBN throughout the testing period.
• Mandatory, prompt notification of material incidents, cyber events, fraud, or consumer harm.
• Cooperation with supervisory activity, including CBN engagement during the testing window.
• A structured pathway toward full compliance and licensing, where Sandbox outcomes inform, but do not guarantee, the applicant’s post-Sandbox regulatory treatment.

Importantly, admission does not amount to a licence or an approval to operate beyond the agreed testing parameters, and it does not substitute for approvals required from other regulators. If your business needs SEC registration, NDPC compliance clearance, or any other regulatory sign-off, Sandbox admission doesn’t remove that requirement — it runs alongside it.

13. Common mistakes applicants should avoid

Based on the CBN’s own stated grounds for rejection, the recurring failure points are:

1. Applying at the concept stage. A pitch deck or business plan without a working MVP will not qualify — CBN has been explicit on this point.
2. Incomplete or missing documentation, particularly around ownership, governance, and beneficial ownership disclosures.
3. AML/CFT controls that exist on paper only — assessors are testing for operational readiness, not policy drafting.
4. Vague or generic risk identification — risks that are acknowledged but not clearly mitigated.
5. Technical infrastructure that isn’t actually ready for live testing with real users.
6. Unclear governance or ownership structures, especially where corporate layering or nominee arrangements aren’t fully disclosed.
7. Misjudging which track to apply under, or attempting to straddle both without a clear primary framing.
8. Treating the testing plan as a commercial pitch rather than a risk-managed operational plan.
9. Underestimating the documentation timeline against a three-week application window — this is the most avoidable mistake, and the one that costs otherwise-qualified applicants a shot at this cohort.

14. A practical pre-submission readiness checklist

We’ve put together a one-page readiness checklist covering all eight documentation categories, the eligibility criteria, and the testing-plan essentials — so you can walk into the application with everything already assembled.

This guide is for general information purposes and does not constitute legal advice. If you’re preparing a Cohort 2 application download the checklist and if you have any questions on the process or the checklist you can reach out to us via the contact us form.