Sandbox

Life Inside the PVARA Sandbox: Reporting and Extensions

What a PVARA sandbox participant must report during testing, how to request a delayed start, and the duty to flag anything that threatens the test.

Malik Abbas · · 6 min read

Approval into the sandbox is not the end of the paperwork. Once a participant is actually testing, the PVARA Sandbox Guidelines 2026 set out three distinct duties that run through the whole testing period: agreed periodic reporting, a narrow route to delay the start of testing, and a duty to speak up the moment something goes wrong. None of the three is defined by a fixed public template — each depends on what the participant and the Authority agree, or on the participant’s own judgement about when to notify.

This piece works through what the Testing/Experimentation section of the Guidelines actually requires, and how it differs from the incident-specific notification duties set out separately in the undertaking a participant signs.

What is a sandbox participant actually approved to do once testing begins?

Operate within the sandbox environment for the period the Authority approved, subject to the requirements in the Virtual Assets Ordinance, 2025. The Guidelines state that “the approved participant will be allowed to operate in the sandbox environment for the period as approved and in compliance with the requirement stated in the Ordinance.” The approved period, and the conditions attached to it, come from the Letter of Approval issued after assessment — the Guidelines do not publish a single standard testing duration that applies to every participant.

Who decides what reports a participant files during testing, and how often?

The participant and the Authority, agreed before testing starts. The Guidelines state that “the participant will provide reports to the Authority with contents, format and frequency as agreed mutually between the participant and the Authority prior to the commencement of testing stage.” There is no published standard reporting template or fixed frequency in the Guidelines themselves — the reporting regime is negotiated case by case and locked in before the clock on testing starts running. An applicant should not expect a generic reporting schedule; it should expect to agree one.

Can a participant delay the start of its testing period?

Yes, but only on a narrow ground and only if raised in time. The Guidelines provide that “in case, the participant encounters an unexpected technical or business difficulty beyond their control, the participant may submit a request, at least two weeks prior to the expiry of the time, for extension in time for commencement of testing period to the Authority.” Three conditions apply together: the difficulty must be unexpected, it must be beyond the participant’s control, and the request must reach the Authority at least two weeks before the existing deadline expires. A difficulty that was foreseeable, or a request filed with less than two weeks’ notice, falls outside what this clause describes.

What must a participant do if something threatens its ability to start or finish testing?

Tell the Authority promptly — the Guidelines do not leave this to the participant’s discretion. The text states that “the participant shall inform Authority promptly, if any unforeseen circumstances have impaired its ability to commence or complete the testing. The Authority shall advise the appropriate course of action accordingly.” This is a broader duty than the two-week extension request: it applies to any unforeseen circumstance affecting either the start or the completion of testing, and it hands the response back to the Authority rather than letting the participant unilaterally decide what happens next.

How does this duty differ from the extension-request rule?

They cover different moments and different remedies:

Duty When it applies What the participant does What follows
Extension request Difficulty specifically delaying the start of testing Submit a request at least two weeks before the deadline expires Authority considers the extension
Prompt notification Any unforeseen circumstance impairing ability to commence or complete testing Inform the Authority promptly, without a fixed deadline Authority advises the appropriate course of action

The extension-request rule is narrower and procedural, with a fixed lead time. The prompt-notification duty is broader and open-ended, covering the whole testing period and leaving the response to the Authority’s judgement rather than a pre-agreed process.

What ongoing record-keeping does a sandbox participant commit to, separate from these reports?

Full access and retention, set out in the undertaking the participant signs on approval. Annexure-B, the format of undertaking for sandbox applicants, requires the participant to agree that it “shall submit information and progress reports to the Authority signed by competent authority as designated by CEO and as per agreed format and timelines during the testing stage,” that it “shall allow complete access to the Authority to its core reporting/accounting/significant software,” that it “shall maintain proper records during testing period for reviews by Authority anytime,” and separately that it “shall retain all the transaction record and maintain proper book of account for a period of 7 years.” The agreed reporting cadence from the Testing/Experimentation section becomes, through this undertaking, a signed commitment with a named accountable signatory — not an informal understanding.

Does the participant control what happens after it reports an unforeseen circumstance?

No. Under the prompt-notification duty, the Authority — not the participant — decides the appropriate course of action once notified. This matters for how a participant should treat a developing problem: the Guidelines expect early notice, not a unilateral fix followed by a report once resolved. A participant that quietly works around a technical or business difficulty and only reports it after the fact has not met the “promptly” standard the text sets, since the point of prompt notice is to let the Authority direct the response while the issue is still live.

What should a sandbox participant build into its operating plan for the testing period?

  • Agree the reporting contents, format and frequency with the Authority before testing starts — do not assume a default template exists.
  • Identify, before testing begins, who internally is authorised to sign progress reports on the CEO’s behalf, since Annexure-B requires a designated signatory.
  • Build a two-week buffer into internal planning around the approved testing start date, so a genuine unexpected difficulty can still be raised within the extension-request window.
  • Treat “unforeseen circumstances” broadly — the prompt-notification duty is not limited to technical failures, and covers anything impairing the ability to commence or complete testing.
  • Keep core reporting, accounting and significant software genuinely open to Authority access throughout testing, not only at report submission dates.

About this analysis

This analysis was prepared by the CoinConnect research desk from the Testing/Experimentation section and Annexure-B of the PVARA Sandbox Guidelines 2026, read as published. Where the Guidelines do not specify a fixed reporting template, frequency or response timeline — leaving these to case-by-case agreement — that is stated in the text above.

Regulatory positions change and specific requirements should be verified against the current position published by the relevant authority before you act on them. This is information and analysis, not legal advice, and it does not create an advisory relationship. Take professional advice on your own circumstances.

Entering Pakistan's crypto market?

CoinConnect handles market entry, partnerships, PR and launch for exchanges and Web3 companies moving into Pakistan and South Asia.

Visit CoinConnect

More analysis