Pakistan’s Crypto Sandbox, Examined

9 mins read

Last Friday, Pakistan Virtual Assets Regulatory Authority, PVARA, announced the launch of a sandbox, i.e. a supervised testing environment where startups can trial tokenisation, stablecoins, remittances, and on- and off-ramp infrastructure before seeking a full license.

It’s a move more than 50 countries have made before. Fintech regulatory sandboxes have proliferated since the UK’s Financial Conduct Authority pioneered the model in 2015, and the logic is simple: fintech products can harm consumers, enable fraud, and move capital in ways that only become visible at scale. A sandbox creates a middle ground — limited exposure, supervised conditions, and a defined process for when things go wrong.

Pakistan ranked third globally on Chainalysis’s Crypto Adoption Index in 2025, with over $100 billion in transaction value in FY25 — most of it informal, outside any consumer protection framework. Crypto is not synonymous with virtual assets, which is the broader category PVARA regulates, but it is the most visible part of it and a reasonable indicator of the scale of activity the regulator is dealing with. We’ve covered that journey in detail here.

The big picture: sandboxes to rulebooks 

Regulators worldwide have spent the last decade figuring out how to govern virtual assets without killing them. The answer most have landed on: start with controlled testing, then build permanent rules around what you learn.

Dubai’s VARA is the clearest example of where this can end up — firms licensed by activity, obligations that grow with the risks they take, enforcement against anyone operating outside the perimeter. It’s a different context entirely, but the underlying logic applies: credibility requires clear permissions and real consequences.

PVARA’s sandbox has user caps, transaction limits, and mandatory custody controls baked into the testing conditions — a test window of up to 18 months, long enough to stress-test what actually matters: whether custody holds, how incidents get handled, whether AML controls work under live transaction flows.

The Process

Stage 1:

Applicants submit a business model description, early thinking on AML, cybersecurity, and Shariah compliance where relevant, and a non-refundable fee. PVARA decides whether the proposal is in scope, not prohibited, and worth a closer look.

The risk is subjectivity. “Innovation” and “scope” are judgment calls unless PVARA publishes what it’s actually looking for. Virtual asset products are also genuinely hard to categorize: a wallet can simultaneously look like payments, custody, brokerage, and exchange. Without clear definitions, clarification requests pile up, timelines stretch, and the process ends up selecting for compliance budgets rather than good ideas.

The fix is straightforward: publish a checklist, provide model templates, define what prohibited activity looks like for common product types, and offer pre-application guidance so teams know whether they qualify before spending money finding out.

Stage 2:

Stage 2 converts a screened application into an actual test permission. Applicants present to a committee covering technical functionality, risk mitigations, and consumer protection. If approved, they enter a Supervisory Agreement that sets the conditions for testing: user caps, transaction limits, approved providers only. The Supervisory Agreement is the key instrument — it converts promises into enforceable obligations.

It’s also where the process is most vulnerable to opacity. Committees without published reasoning breed suspicion even when decisions are fair. Fit and proper checks become a silent kill switch if the criteria aren’t clear upfront. And evaluating custody design, key management, and incident response properly requires specialist capacity that most emerging regulators are still building — without it, decisions drift toward who looks credible rather than who is actually safe. Caps set too tightly carry their own risk: a test starved of real usage may never surface real failure modes.

The credibility fixes are predictable: publish anonymized decision summaries, make fit and proper criteria explicit, require independent technical assessments for high-risk activities, and build in tiered limits that can scale if controls hold up.

Stage 3:

This is the single-most criticial phase: where the product meets real users for the first time. Approved firms operate live under the Supervisory Agreement: up to 500 users, transactions capped at $1,000 daily, a maximum of 18 months, and restricted to approved ramps and service providers. PVARA retains the ability to adjust limits or pull the plug. Firms get conditional no-action relief — which means tolerance for operating in a grey area, not a regulatory endorsement.

This is where sandboxes tend to quietly fail. Continuous monitoring sounds rigorous until you ask what it actually means — what data is being collected, how often, by whom, and what triggers a response. Without answers to those questions, it becomes periodic reporting, and periodic reporting is where risks hide. Long test windows compound the problem: pilots that neither graduate nor shut down are a common sandbox pathology, and 18 months is long enough for that to happen. The approved provider list carries its own risk — narrow it too much and the sandbox inadvertently creates a small group of gatekeepers, reshaping the market by forcing everyone through the same set of intermediaries.

For Stage 3 to mean anything, PVARA needs to define what supervision actually looks like: what data firms must log, incident reporting deadlines, severity thresholds, and milestone reviews with clear pass and fail criteria. The no-action relief also needs to be communicated carefully to users — tolerance for testing is not the same as approval.

Stage 4:

Stage 4 forces a decision. Firms submit a final report, the Steering Committee evaluates performance against agreed KPIs, and the Board reaches one of three outcomes: a full license, a time-capped extension of up to six months, or discontinuation.

The exit structure is one of the sandbox’s stronger design choices — a process that never ends is not supervision, it’s procrastination. But Stage 4 is also where credibility is most visibly won or lost. KPIs that weren’t defined precisely at the start become negotiable at the end. Commercial viability is a slippery criterion — a product can be profitable and still harmful, or genuinely useful but not yet profitable. If the sandbox quietly becomes a profit filter, it will reject things it shouldn’t.

Discontinuation is the real test. If it never happens, the sandbox looks permissive. If it happens without clear thresholds, it looks arbitrary. Either way, trust erodes. Publishing anonymized cohort outcomes — including failures — would do more for PVARA’s credibility than any number of approvals.

The bottom line

The design is credible enough. The harder question is whether PVARA has the capacity and the will to run it properly — to publish its reasoning, supervise what it says it’s supervising, and actually stop firms that shouldn’t continue.

Most of the activity PVARA is meant to govern happens outside any regulatory perimeter, and has for years. A sandbox that produces a handful of well-documented pilots, some of which fail, would be a meaningful start. One that produces delays, quiet extensions, and opaque decisions will just confirm what skeptics already suspect — that the regulatory apparatus exists alongside the market rather than governing it.

Hadi Hayat

Hadi Hayat is a Karachi based analyst at Data Darbar, with prior experience at Binance (Global P2P) and Habib Metropolitan Bank (corporate banking). He focuses on the frontier of digital finance across Pakistan and the region.

Leave a Reply

Your email address will not be published.

Follow Us