PVARA Sandbox: What Builders Should Know

The Pakistan Virtual Asset Regulatory Authority (PVARA) runs a regulatory sandbox as a structured entry point for virtual asset firms into the Pakistani market. It is attracting interest from domestic founders, regional exchanges, tokenisation platforms and banks exploring digital asset products. It is also widely misunderstood. The sandbox is not a light-touch licence, nor is it a way to operate for a period without serious controls. It is a supervised environment in which a firm operates a defined product, with real clients, under real rules, against a defined set of exit criteria.

This guide is for builders: founders, engineering leads and compliance officers preparing a sandbox application. It explains what the sandbox does and does not do, how the application process works in practice, the permitted activity envelope, the reporting cadence, the exit path, and what "sandbox-ready" infrastructure actually looks like.

The sandbox exists to let PVARA and applicants co-develop the regulatory treatment of products that are either genuinely new or that benefit from live operational data before full authorisation. Typical candidates include stablecoin issuers, tokenisation platforms for Pakistani assets, novel custody or transfer products, cross-border remittance products with a virtual asset leg, and firms integrating Raast with virtual asset flows.

Three things distinguish the sandbox from full authorisation. First, the activity perimeter is narrower: a specific product, a defined client cohort, and caps on transaction size, aggregate volume or client numbers. Second, the operating period is finite: firms enter for a defined term, typically a year, with the possibility of extension if clearly justified. Third, the exit criteria are explicit: successful sandbox operation is expected to produce a transition to full authorisation, not an indefinite sandbox existence.

The sandbox does not reduce consumer protection or AML obligations. Clients in the sandbox are real clients, their money is real, and a failure in the sandbox has the same consequences as a failure in a fully authorised firm. Anyone framing sandbox entry as a shortcut is setting up a difficult conversation with the supervisor.

A sandbox application is a condensed version of a full licence application, scoped to the proposed product. At minimum, PVARA expects a clear product description, a regulatory analysis explaining why the sandbox is the appropriate route rather than full authorisation or no authorisation, a defined client-eligibility and onboarding approach, a risk assessment with mitigations, a technology architecture covering wallets, signing, ledger and reporting, and a governance model with named senior individuals.

The application is assessed on four dimensions. Regulatory fit asks whether the product genuinely benefits from sandbox treatment, or whether it should go through full authorisation. Consumer-protection fit asks whether the planned client cohort is appropriate (sophisticated clients for novel products, stricter caps for retail) and whether disclosures are clear. Financial-crime fit asks whether AML, sanctions screening and Travel Rule controls are proportionate and operational on day one. Operational fit asks whether the technology and people can actually run the service at the proposed scale without breaking.

Realistic timelines run several months from pre-application engagement to in-sandbox go-live. Pre-application engagement matters. Applicants who walk in with a filed application and expect PVARA to work out the perimeter typically lose weeks correcting scoping issues. Applicants who engage early and iterate the perimeter with the supervisor before filing tend to move faster. For the broader authorisation picture, our PVARA licensing guide walks through the full-authorisation route.

A useful heuristic for the scoping conversation is to prepare, before engagement, a one-page description of the product, the client cohort, the activity perimeter requested, the caps the firm is willing to operate under, and the exit criteria the firm believes are appropriate. Walking into a pre-application meeting with this document in hand changes the conversation from "what do you want to do" to "this is what we propose; where does the supervisor disagree". The delta between the two is weeks of cycle time.

Applicants should also have a clear answer to two questions that PVARA consistently asks: why this product cannot be built under an existing licence or regulation, and why the sandbox is preferable to full authorisation for this specific product. Answers that boil down to "because we are not ready for full authorisation" tend to invite the follow-up "then come back when you are". Answers that identify a genuine regulatory novelty, a data-gathering need or a consumer-protection design that benefits from supervised iteration tend to land.

What a firm can do in the sandbox is defined on a firm-by-firm basis in the authorisation conditions. Some common patterns are worth understanding.

Activity scope is usually tight. A custody product in the sandbox is unlikely to also be authorised to run an exchange in parallel. A stablecoin issuance product is unlikely to be authorised to also run a tokenisation platform. PVARA's default posture is one coherent product per sandbox slot, with additional activities requiring their own authorisation (in or out of sandbox).

Client eligibility is often capped to professional or institutional clients for higher-risk products, with retail access allowed only where consumer-protection controls are clearly adequate. Firms targeting retail should expect lower per-client caps, clearer disclosures and more frequent reporting.

Volume and value caps are common. A sandbox authorisation may include a per-transaction ceiling, an aggregate monthly volume ceiling, a maximum number of clients and a maximum assets-under-custody figure. These caps are not punitive. They exist so that the operational risk in the sandbox is bounded while the firm builds operating history. Breaching a cap is a material incident.

Geographic scope is usually limited to Pakistan, with cross-border flows permitted only where the counterparty jurisdictions are specifically addressed in the application. Firms planning UAE to Pakistan remittance or UK to Pakistan remittance flows should scope those corridors explicitly in the sandbox application rather than adding them later.

Product-variation rules are important. Sandbox authorisations typically specify the product and the controls in enough detail that a material change to either requires supervisory consent. A new client cohort, a new asset supported by a custody product, a new chain added to a transfer product, or a new UX flow that changes disclosure — each of these is a change that the sandbox team will expect to see notified, and in many cases pre-cleared, rather than announced after the fact. Firms should build an internal variation-management process on day one.

Sandbox reporting is more intensive than steady-state supervisory reporting, because the point of the sandbox is for PVARA to observe live operation. Firms should expect a mix of standing reports and event-driven notifications.

Standing reports typically include monthly operating metrics covering client onboarding, transaction volumes by product, failed transaction rates, incident logs and complaints, quarterly prudential returns covering capital, liquidity and client asset reconciliation, and periodic AML and sanctions-screening outputs including Travel Rule message flows and suspicious transaction reporting volumes. Firms should design reporting infrastructure to generate these outputs from system-of-record data rather than via manual spreadsheets. A firm whose reporting is manual will miss something material within the first quarter.

Event-driven notifications cover material incidents (security breaches, outages, key personnel changes, breach of activity caps, significant client complaints), material changes to the product, technology or governance, and any regulatory contact from another authority. Prompt notification is the rule. Late notification is treated harshly.

Reporting infrastructure is an area where Bridge's stack carries real weight. The custody platform, the ledger and settlement layer and identity services are designed to produce the evidence supervisors expect, with reconciled numbers and auditable timelines.

A practical reporting-design principle is that the source-of-truth for any figure given to the supervisor should be the system that produced the business event, not a downstream aggregation. If the ledger produces client balances, then the reported client balance figure should come from the ledger. If the wallet produces on-chain transfer events, then the reported transfer figure should come from the wallet. Layers of spreadsheet aggregation between source systems and the supervisor are where reconciliation breaks down, and when it does, the explanation to the supervisor is painful.

The sandbox has three exit paths.

Graduation to full authorisation is the intended outcome. A firm that has operated cleanly within its conditions, evidenced the controls in the application and produced the reporting on time will typically transition to full authorisation with the operational record as the core of the file. The capital, governance and technology expectations at that stage are the full-authorisation standard; the sandbox record helps demonstrate that those expectations are met in practice.

Extension is available where there is a clear reason that additional sandbox time will produce material new evidence. "We need more time to build" is not a strong reason. "A dependent regulation is expected in the next quarter and we want to operate under it before scaling" is a stronger one.

Cessation can be triggered by the firm or by PVARA. A firm that concludes the product is not viable should exit the sandbox cleanly, returning client assets, closing positions and filing a close-out report. PVARA can direct cessation if conditions are breached, if consumer harm is occurring or if the firm is not making credible progress toward full authorisation. Cessation triggered by PVARA is a public-record event with reputational consequences.

Firms should plan the exit path from day one. Onboarding clients without a credible plan for what happens at the end of the sandbox window is a governance failure.

The gap between a sandbox application that sounds credible and infrastructure that can run in-sandbox is the single most common reason for slipping timelines. Sandbox-ready infrastructure has five properties.

It is segregated. Client assets sit in clearly separated wallets or accounts, with reconciled records between the blockchain, the firm's ledger and client-facing balances. Segregation is not a spreadsheet; it is enforced by the wallet architecture and the ledger.

It is resilient. Wallet signing has tested recovery procedures. The ledger survives a node failure. Integrations for market data, screening and blockchain connectivity have failover. There is a documented runbook, and the runbook has been rehearsed.

It is observable. Every client-affecting event produces a log entry tied to a canonical transaction identifier, reconciled across blockchain, ledger and reporting. If a supervisor asks "what happened to transaction X at time T", the answer should take minutes, not days.

It is controlled. Production access is role-based, with separation of duties between initiation, approval and execution. Code paths that move client funds are subject to change-management controls. Keys are handled in HSM or MPC infrastructure, with clear policies on who can approve what.

It is extensible. The system can evolve as the activity perimeter widens from sandbox to full authorisation without a re-architecture. This matters because the sandbox-to-full transition is not the place to discover that the ledger only supports two client tiers.

Bridge's infrastructure is designed to this standard out of the box. For applicants who do not want to build this stack from scratch, there is a well-trodden integration path.

A useful lens on infrastructure readiness is to ask whether every supervisory question the firm will face in its first six months of operation has an answer that can be produced in minutes. How much of client asset X is in hot versus cold storage right now? What was the firm's largest transaction last week and who approved it? How many clients onboarded in the last thirty days, by tier and by source? How many sanctions hits were generated, and what was the disposition of each? How did the firm handle the most recent incident, and what is the root-cause timeline? A sandbox-ready stack produces these answers directly from the system of record. A stack that requires engineers to write a one-off query every time is not ready.

If you are preparing a PVARA sandbox application and want to pressure-test the infrastructure plan, or if you want a reference architecture for a sandbox-ready custody, settlement or tokenisation product in Pakistan, Bridge's team can help. Start with our Pakistan sandbox overview or contact Bridge to scope a session.