BSP Regulatory Sandbox Framework

BSP Regulatory Sandbox Framework

If you are building a fintech product in the Philippines and your idea depends on a regulatory question that cannot be answered by an existing licence or rule, the Bangko Sentral ng Pilipinas (BSP) Regulatory Sandbox is the official route to investigate. It is not a grants program, accelerator, or cash award. It is a controlled, time-bound, live testing framework in which the central bank and an eligible participant agree on test parameters, safeguards, monitoring, and an exit path.

The official framework is still available as an ongoing process. BSP Circular No. 1153, approved by the Monetary Board through Resolution No. 1217 and issued in 2022, institutionalized the framework. BSP Memorandum No. M-2024-002 later instructed regulatory sandbox applicants and proponents to send applications, inquiries, and other correspondence electronically to the Sandbox Oversight Team through [email protected]. Neither official document publishes a recurring annual closing date, so this page uses ongoing rather than inventing a deadline. Ongoing availability does not mean automatic approval: BSP evaluates each proposal on its own merits.

That distinction matters for planning.

A normal launch plan usually has one of two problems:

• build first and resolve compliance later, risking enforcement risk, or
• over-engineer early and lose speed, because you try to meet complete licensing requirements before proof of traction.

The sandbox exists between those two extremes. It is designed to reduce uncertainty for firms and regulators by introducing a shared test process:

• regulators observe a product in real use,
• risks are measured while scale is still limited,
• and the firm can improve the design and controls before a broader market roll-out.

The legal basis for the framework is BSP Circular No. 1153. The current application-routing instruction is BSP Memorandum No. M-2024-002. Read the circular for eligibility, documents, testing, consumer protection, reporting, and exit requirements; read the memorandum before sending any application or inquiry.

The rest of this guide translates what the circular says into a practical checklist: who should apply, what makes applications fail, how long things take in practice after filing, and what to prepare before you invest in this route.

At a Glance

What this sandbox really is (and is not)

The BSP sandbox is often misunderstood as a “permission to launch” path. It is not.

You are applying for structured permission to test a model in a supervised setting. The framework defines sandbox approval as limited to agreed terms; it is not a blanket waiver. You cannot treat sandbox status as freedom from Philippine banking, money-laundering, consumer protection, data privacy, and operational safety requirements. The framework is explicit that the sandbox is meant to operate inside a safe envelope, not outside the law.

In plain language:

• You get a controlled path to test where rules can be adjusted temporarily for testing purposes.
• You still carry accountability for customer safety, fraud prevention, and data handling.
• You must document risks and report progress at agreed intervals.
• The sandbox is not the end point. It is an assessment phase before broader scale.

This is why many teams get good value from it even without immediate launch.

Why teams use it

Teams should consider the sandbox when they can answer yes to several of the following:

• The product is truly innovative or uses new technology in a new way.
• The product solves a real market gap for financial inclusion, access, cost, speed, or risk management.
• You can run with a limited user base safely and learn quickly.
• The team is prepared to accept heavy documentation and iterative regulator interaction.

If your product already fits clearly within existing BSP registration pathways and you already have the required authorizations, the sandbox can still be useful but is usually not the fastest route. If your product sits in a regulatory gap, or if the team is still proving risk controls before broad commercialization, the sandbox can be the right fit.

The framework is broad enough to include:

• digital lending, payments, and other electronic finance products,
• AI-assisted credit or anti-fraud services where innovation is central,
• service models that rely on new architectures or third-party distribution.

A key point for non-specialists: the framework is not just for start-ups with empty balance sheets. BSP expects capability and control systems in place, because the pilot may involve real users and real money. New players can be within scope, but they still need to demonstrate that they can deploy the proposed solution safely and govern the experiment.

Who should apply

The circular lists standards rather than a “minimum checklist” brand image. A practical way to read them is:

1) Your solution is sufficiently innovative or solves a real gap

The solution should either:

• use a new or emerging technology in a meaningful way, or
• solve a delivery gap in financial services with a validated rationale.

This is not about fancy features alone. You need evidence that your technology or model changes outcomes for users and is not just repackaging existing products.

2) You can show a realistic roll-out approach

You must describe how the product can be implemented in a controlled roll-out and what the operational sequence looks like. A vague “we can scale” statement is insufficient.

3) You can show a full risk map

The circular expects applicants to identify risks tied to:

• AML/CFT,
• cybersecurity,
• data integrity and privacy,
• consumer acceptance,
• and project execution.

You need to state safeguards and mitigation.

4) You have measurable success signals

A sandbox is not a marketing exercise. It is an evidence exercise.

You must define KPI-style milestones and acceptance criteria upfront so BSP and your own team can decide if your pilot is working.

5) You have an exit plan

Your proposal must include what happens after the testing period whether you succeed, fail, pause, or need to exit.

6) You can meet the applicant identity and governance expectations

The circular requires a Letter of Intent signed by the president or an officer of equivalent rank and a corporate secretary’s certificate showing board approval to apply. Foreign applicants use a local or regional management committee equivalent. The application form also asks for company organization, key personnel, financial standing, and BSP licences or registrations where applicable. In other words: no anonymous founders with informal sign-offs.

Practical decision test

If you cannot answer “yes” with confidence to each of the six points above, you will likely spend more time preparing than gaining signal. That is still useful preparation, but it is not yet ready for sandbox submission.

Who should avoid this route (for now)

• Teams with no functioning prototype or no real user feedback.
• Teams that are still deciding legal form, product model, or governance structure.
• Teams with unresolved AML/KYC and customer complaint handling plans.
• Teams that assume sandbox status removes data-privacy obligations.
• Teams who cannot budget time for the reporting burden after approval.

Application process

The framework sets out a clear four-stage structure.

Stage 1: Application and electronic submission

The circular requires a packet containing at minimum:

• Letter of Intent,
• corporate secretary’s certificate of board-level approval (or equivalent local/regional governance evidence if a foreign player),
• accomplished Regulatory Sandbox Application Form,
• Eligibility Self-assessment Checklist,
• Test Plan.

Additional documents may be requested during evaluation. Under the current BSP submission guidance, send the application and related correspondence electronically to [email protected]. Use the subject format RSBX_APPLICATION_<APPLICANT Name>-<application date (DDMMMYYYY)>. If you are asking a question instead of filing, use RSBX_INQUIRY_<ENTITY NAME>_<SHORT DESCRIPTION OF NATURE OF INQUIRY/CLARIFICATION>. For an ongoing application, use RSBX_<APPLICATION No.>-<SHORT DESCRIPTION OF SUBJECT MATTER>, with the application number supplied by the Sandbox Oversight Team.

The memorandum warns that an incorrect subject line can cause delivery failure. Applicants should expect an acknowledgement from the sandbox mailbox within the day; if no acknowledgement arrives, treat that as a delivery problem and follow up through the prescribed channel. Keep a copy of the sent message, attachments, and any automatic reply.

Stage 2: Evaluation

BSP reviews completeness, accuracy, and suitability.

Possible outcomes are approval to proceed, requests for clarifications, or rejection with reasons. Rejections can be followed by re-application after cooling-off timelines and corrected documentation.

Stage 3: Testing

This stage is split into design and implementation phases.

During design, you present:

• full overview of the innovation,
• service flow and launch assumptions,
• expected financial projections,
• risk controls,
• and rollout plan.

Once BSP approves the test design, you receive a Letter to Proceed and begin implementation with an approved testing period.

Stage 4: Exit

Your exit is documented in a final report and exit scenario, including outcomes and recommendations. This stage is tied to either completion of timeline/objectives or early termination if risks are too high.

After exit

A successful sandbox does not automatically mean immediate nationwide launch. It means your proposal is then considered for authority to operate under existing statutory pathways, and BSP may still impose additional requirements.

Important timing expectations and deadline status

This is not a grant call with a published opening and closing window. The current official materials provide an ongoing submission route through the Sandbox Oversight Team and do not announce a fixed deadline or a next cohort date. That is why the opportunity metadata says ongoing. It means a complete proposal can be submitted for BSP evaluation; it does not promise a response date, a testing slot, or approval.

The planning way to think about timing is:

• You should budget for substantial preparation before emailing the packet.
• BSP first checks completeness, correctness, and suitability against the eligibility standards.
• Eligible applicants move into testing design before implementation; an incomplete or unsuitable submission can be rejected.
• Test implementation is expected to be between 3 and 12 months depending on complexity.
• Reporting obligations can continue through testing and into final exit.

In practical terms, do not treat the sandbox application as a fast, one-month process. Use the time needed to assemble a credible governance, risk, consumer-protection, and testing package. BSP may ask for further information, and the testing design must be approved before go-live.

A realistic internal sequence you can use:

• Preparation: finalize product scope and risk hypothesis; assemble executive signoff and the compliance map.
• Submission: complete the five minimum documents, apply the BSP subject-line format, and email the Sandbox Oversight Team.
• Evaluation: respond to BSP requests for clarification or additional documents.
• Testing design: present the innovation, operating flow, financial projections, test and roll-out plan, safeguards, and exit plan.
• After approval: receive a Letter to Proceed with Test Implementation, then begin the monitored test and agreed reporting schedule.

Again, this is planning guidance, not a published BSP processing schedule. The only fixed duration stated in the framework is the testing range of 3 to 12 months from go-live, depending on the solution’s complexity.

Required materials (practical checklist)

The circular specifies minimum documents. For execution readiness, also prepare these practical companion assets:

Core documents from the framework

• Letter of Intent (signed by top leadership),
• Board or equivalent governance approval,
• Completed application form and self-assessment checklist,
• Test plan with explicit timeline, budget, KPIs, customer acquisition, customer communication, safeguards, and exit.

Supporting information to prepare

• Company profile with legal and operational structure,
• current financial standing (audited or interim figures),
• BSP licences or registrations already held, if applicable,
• market research and documented problem statement,
• technical architecture and dependencies,
• data flow map and cybersecurity controls,
• consumer-facing disclosures, complaint handling process, and dispute channels,
• AML/CFT controls and fraud monitoring logic,
• internal ownership matrix for who decides what during incidents.

What to prepare around users and consumer protection

The framework is explicit on consumer transparency. Your communication to pilot users should be clear that:

• they are participating in a sandbox-tested solution,
• the product may carry specific risks,
• support and complaint channels are available,
• and what happens to their data.

If this part is weak, applications often stumble even when technical quality is strong.

At application stage, what people usually get wrong

1. Underestimating the governance burden

Teams often think sandbox is a product-level review only. It is not. BSP evaluates governance readiness: committee-level oversight, decision rights, incident response, and change control.

2. Submitting without measurable assumptions

“Good product” is not enough. You need measurable milestones and KPIs. Without this, a project can look like it is stalling even if user feedback is positive.

3. Ignoring customer risk disclosure

Even in a test, customer misunderstanding is a failure condition. Clarity of terms, complaint channels, and consent language must be explicit.

4. Treating data as internal-only

The framework requires controls over data sharing and explicit respect for consumer data rights. Unclear privacy notices and ambiguous consent are common rejection triggers.

5. Weak incident readiness

You need documented incident response steps before launch: who alerts whom, when to pause, and who communicates to customers and the regulator.

6. No cooling-off logic

If your rollout depends on assumptions that may fail, build predefined “pause” and “exit” points in advance. A clean exit plan is not optional.

Tips for increasing approval quality

Tip 1: Start from compliance, not marketing

Write your value proposition and only then map legal and operational constraints. The most polished product demos can still fail if risk mapping is weak.

Tip 2: Build a minimum data room from day one

Create a folderized submission pack before drafting. Use one folder for corporate/governance, one for compliance, one for technical architecture, one for consumer materials, one for financial projections.

Tip 3: Make your risk map specific

“General security controls” is too vague. Name risks and controls in concrete pairs:

• API outage -> failover and customer communication within X hours,
• complaint spike -> escalation path and resolution SLA,
• model drift -> recalibration and audit logs.

Tip 4: Prepare a pilot support model

The circular’s testing requirement includes frequent progress checks. Design a small support team for pilot users and keep a separate incident log.

Tip 5: Be realistic about scope

If you are doing a broad multi-feature launch, trim to one controlled use case. Sandbox committees evaluate clarity more favorably than breadth in early testing.

Tip 6: Use transparent assumptions

Project budgets, expected conversion assumptions, and fraud-loss projections are often over-optimistic. Conservative assumptions increase credibility and reduce future disappointment in evaluation.

Is this worth your time?

Ask yourself:

• Is this a product where speed of deployment matters more than perfect certainty?
• Can your team manage ongoing reporting and regulator communication?
• Does your idea fit a clearly defined market gap?
• Is your team prepared for a controlled environment instead of immediate scale?

If most answers are yes, the sandbox is likely worth pursuing.

If your team is still pre-revenue, still iterating legal structure, and not ready for sustained compliance work, spending months on internal preparation before filing is the safer move.

Common mistakes and warning signs

For founders

• Treating the sandbox like a marketing certification rather than a control regime.
• Submitting without board-level approval artifacts.
• Assuming foreign founder teams can use local incorporations later; for now, show governance and local accountability upfront.
• Confusing “test” with “free pass” on consumer disclosures.

For operations teams

• Ignoring reporting cadence, then scrambling at the end of testing.
• Not separating sandbox incidents from production incidents in internal tracking.
• Not planning how user funds and data will be returned or handled at exit.

For early-stage teams with limited staff

• Overloading one person with both compliance and technical ownership.
• Underestimating the time to update test design after BSP feedback.

FAQ

Does this program provide grant funding?

The BSP framework and the current submission memorandum do not announce grant funding, a subsidy, or a cash award. Treat this as a supervised regulatory testing route, not a financing opportunity.

Is there a public application deadline?

No fixed closing date or annual cycle is published in the official materials reviewed for this page. The current BSP instruction says regulatory sandbox applications, inquiries, and other correspondence should be sent electronically to [email protected], using the required subject format. The process is therefore listed as ongoing, while every proposal remains subject to BSP evaluation.

Which kinds of entities can apply?

The framework covers BSP-supervised financial institutions, third-party service providers of BSFIs, other BSP-registered institutions, and new players intending to offer or use new or emerging technology for financial products or services within BSP’s regulatory purview. A solution that already falls clearly within existing regulations may instead be evaluated through the established registration or licensing regime.

Can foreigners apply?

Yes, where requirements are met, and governance is clearly documented through local or regional management structure as indicated in BSP submission requirements.

Are there temporary relaxations of rules?

Regulatory sandbox approval can include temporary/limited relaxations, but only within clearly defined test parameters approved by BSP. It is not a full exemption from applicable law.

How long does testing last?

Typical testing duration is between 3 and 12 months based on complexity, with possible controlled extension rules in the framework.

What can cause suspension or revocation?

Material deviations from approved scope, weak safeguards, AML/data security breaches, misleading filings, or serious unresolved incidents are explicitly listed as revocation triggers.

What happens after exit?

The participant submits an exit report and requests authority pathways for broader offering if the pilot is successful. BSP may still deny authority.

What happens if we fail the sandbox?

You can still learn from results and reapply if issues are addressed. The framework is designed to evaluate viability through testing, not only to reward only “winners” on first try.

What to do next

1. Download and annotate BSP Circular No. 1153.
2. Read BSP Memorandum No. M-2024-002 and save the mailbox and subject-line rules.
3. Create a one-page decision memo: problem statement, target users, risk hypothesis, and pilot boundaries.
4. Prepare corporate documents required for submission (signed intent, board approval, governance evidence).
5. Complete the application form, eligibility self-assessment, and test plan.
6. Define KPIs, customer communications, safeguards, reporting, and exit triggers.
7. Map data-sharing boundaries, privacy rights handling, complaint resolution, and AML/CFT controls.
8. Email the complete package to [email protected] using the required subject line, then retain the acknowledgement for your records.

If you want a less risky path, use the framework as a readiness check: if the same project cannot pass your internal simulation against these sections, pause before submitting. If it fits an existing BSP licensing or registration route, investigate that route instead of treating the sandbox as a shortcut.

Official links

• BSP Regulatory Sandbox Framework: https://www.bsp.gov.ph/Regulations/Issuances/2022/1153.pdf
• BSP Memorandum No. M-2024-002, submission guidance: https://www.bsp.gov.ph/Regulations/Issuances/2024/M-2024-002.pdf
• BSP home and further issuances index: https://www.bsp.gov.ph/

The official framework is the core reference for this opportunity, and the memorandum is the current routing instruction used in this guide. Before sending a final package, check BSP’s regulations page for any later amendment or replacement guidance.