PVARA Sandbox Form I Part B: Proving You Are Ready to Test

Part A of Form I describes what a sandbox applicant wants to build. Part B answers a harder question: can you actually run it today. The Pakistan Virtual Asset Regulatory Authority (PVARA) does not evaluate readiness on ambition — it evaluates it on evidence, and Part B is the section of the Sandbox Guidelines 2026 built specifically to collect that evidence.

This matters because the Guidelines list “Feasibility and Exit Strategy” as one of the Key Evaluation Criteria applied after screening, and technical and operational readiness sits at the centre of that criterion. An applicant with a compelling Part A and a thin Part B is describing a product PVARA has no basis to believe is actually ready.

What is Form I Part B for?

Part B asks the applicant to show, not just describe, that it can begin live testing — covering technical development status, partnerships and integrations, financial and operational preparedness, and consumer safety measures. The Guidelines head this section:

“B. Readiness for Testing”

Unlike Part A, most of Part B’s sub-sections are marked “N” for attachments in the Guidelines’ table — the expected format is closer to a direct statement of fact than a supporting document, with one notable exception covered below. That does not lower the evidentiary bar; it changes its shape from documentary proof to specific, checkable claims.

What must the technical readiness sub-section show?

This sub-section requires a statement of development status — including whether smart contracts have been audited and infrastructure is ready — plus internal testing or testnet results and capacity, in a yes/no plus short-description format, without a required attachment. The Guidelines specify:

“1. Technical Readiness — Development status (smart contracts audited, infrastructure ready), internal testing/testnet results, capacity. Yes/No + short description. N”

The yes/no structure is deliberate: PVARA wants a direct answer on whether smart contracts have been audited and infrastructure is ready, followed by enough detail to substantiate that answer. A “yes” on smart contract audits that is not backed by an actual audit report elsewhere in the application — most naturally in Part A’s cybersecurity strategy attachment — creates an inconsistency between two sections of the same form that an evaluator is well placed to spot.

What partnership and integration information is required?

This sub-section asks for a list of partners — banks, exchanges, virtual asset service providers — and the integration points connecting them, such as application programming interfaces (APIs) and oracles, presented in table or bullet form, without a required attachment. The Guidelines describe it as:

“2. Integration / Partnerships — List of partners (banks, exchanges, VASPs), integration points (APIs, oracles). Table/bullets. N”

Banking relationships are worth particular attention here, given how often they are the practical bottleneck for virtual asset businesses in Pakistan regardless of licensing status. Our tax and banking service page covers this gap in more detail. A Part B submission that names a bank partner without a confirmed relationship in place is a claim PVARA can test simply by asking — better to list confirmed integrations only, and describe pipeline relationships separately as pending rather than presenting them as settled.

What operational and financial readiness must the applicant show?

This sub-section requires budget, funding commitments, operational structures, safeguards, and key performance and risk indicators (KPIs and KRIs), in bullets or table format, without a required attachment. The Guidelines list it as:

“3. Operational & Financial Readiness — Budget, funding commitments, operational structures, safeguards, KPIs/KRIs. Bullets/table. N”

This sub-section connects directly to the eligibility criteria applied before an application even reaches assessment. Section 2 of the Guidelines requires applicants to demonstrate “readiness for scalability (technical, financial, and human)” and to conduct “a comprehensive regulatory and risk assessment” covering cybersecurity, data privacy and operational risks. The KPIs and KRIs named here should be the same measures the applicant intends to report against once testing begins, since section 10 of the Guidelines requires participants to provide reports “with contents, format and frequency as agreed mutually between the participant and the Authority prior to the commencement of testing stage.” Defining KPIs and KRIs consistently at the application stage avoids renegotiating reporting metrics after approval.

What consumer and user safety measures does Part B require?

This sub-section requires protection measures — risk disclosure, loss recovery, customer support, dispute resolution — described in narrative form with key points, without a required attachment. The Guidelines specify:

“4. Consumer / User Safety — Protection measures (risk disclosure, loss recovery, customer support, dispute resolution). Narrative + key points. N”

This is where Part B connects most directly to the undertaking every approved participant later signs under Annexure-B, which commits the participant to ensure “the highest standard of protection, fairness, and transparency” for test users and to give them “the right to access, correct, or request deletion of their personal data at any time.” A Part B narrative that only describes protections in the abstract, without naming the actual dispute-resolution channel or loss-recovery mechanism a test user would use, is weaker evidence than one that names the specific process.

What is required for the virtual asset product sub-section?

Where applicable, Part B requires product details expressed in terms of virtual asset standards, in a combined narrative, table and key-points format — and this is the one sub-section in Part B that does require an attachment. The Guidelines list it as:

“Virtual Asset Product being offered, if applicable — The product details, in terms of Virtual Asset Standards. Narrative+ Table+ key points. Y”

The Guidelines do not further define “Virtual Asset Standards” within the Sandbox Guidelines text itself. Our reading is that this sub-section is meant to connect the product being tested to the Act’s own classification framework — including the distinctions between an Asset-Referenced Token and a Fiat-Referenced Token, both defined in section 3 of the Virtual Assets Act, 2026, and to the Schedule I service categories the product falls under. Where a product does not clearly map onto an existing defined term, the safer approach is to say so explicitly and explain the applicant’s own classification reasoning, rather than force-fit it into a term the Act does not use for that product.

How does Part B differ in evidentiary weight from Part A?

Part A is mostly documentary — four of its five sub-sections require attachments — while Part B is mostly a direct statement of readiness, with only the virtual asset product sub-section requiring one. This is not a lower bar; it reflects a different kind of evidence. Part A proves the innovation is well described and properly attached with supporting material. Part B proves the applicant can actually execute what Part A describes, right now, with the team, technology and partnerships already in place or credibly close to it.

	Part A	Part B
What it establishes	What the innovation is, and how it is secured and governed	Whether the applicant can actually begin testing it
Attachments required	5 of 5 sub-sections	1 of 5 sub-sections
Typical format	Narrative, tables, bullet points	Yes/No statements, bullets, tables
Risk of a weak submission	Reads as an undefined or poorly governed proposition	Reads as a proposition that is not actually ready to test

How should an applicant prepare Part B before submission?

Verify every claim in Part B against something concrete before writing it down — a signed partnership agreement rather than a term sheet, a completed audit rather than a scheduled one, a live dispute-resolution channel rather than a planned one. Since most of Part B carries no required attachment, PVARA is relying more heavily on the applicant’s own representations here than in Part A, and section 5 of the Guidelines allows the Authority to seek “any other information sought subsequently” during assessment — a mismatch between what Part B claims and what a follow-up question reveals is the kind of gap that undermines an otherwise strong application.

Cross-check Part B against the Annexure-A self-assessment checklist before submitting. Its Readiness question asks directly whether the applicant has “a clear business model, technology architecture, and compliance plan” and whether a “testing plan with objectives, success criteria, timelines, and risk controls is ready,” with “concept only on paper yet” listed as a negative indicator. If Part B cannot answer that question with confirmed facts rather than plans, the application is not yet ready to submit. Our regulatory and licensing service page covers how we help applicants close that gap before filing.

About this analysis

This analysis was prepared by the CoinConnect research desk from the Virtual Assets Act, 2026, the PVARA No Objection Certificate Regulations and the PVARA Sandbox Guidelines 2026, read as published. Where practice is not yet settled or guidance has not been issued, 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.