PVARA Sandbox Form I Part A: Describing Your Innovation

Part A of Form I is the first thing a PVARA case officer reads in a sandbox application, and it is where an applicant either establishes that the product is genuinely novel or fails to. Five sections make up Part A, each with its own required content, format and attachment expectation, and each feeds directly into the evaluation criteria the Authority scores the application against.

This article works through all five sections of Part A in turn, with the format the Sandbox Guidelines 2026 specify for each.

What is Form I Part A, and what is it trying to establish?

Form I Part A is the section of the sandbox application headed “Innovation / Virtual Asset Service Provider Proposition”, and its purpose is to let PVARA judge whether the proposed product or service is genuinely new and how it is built. The Guidelines describe the overall intent of Form I as helping an applicant “prepare a strong, compliant, and viable application, especially with respect to virtual assets, blockchain, and cybersecurity risks, so the Authority can assess readiness, safety, consumer protection, and suitability for live testing.”

Part A has five numbered sections. Each carries its own format and length expectation, and every one of them requires a supporting attachment:

Section	What to describe	Format / length	Attachment
1. Service / innovation summary	Concise description of your innovation	~500–1,000 words	Yes
2. Blockchain / technology stack	DLT used, smart contract platform, wallet architecture, throughput, scalability	Bullet points / table	Yes
3. Cybersecurity strategy	Threat model, security controls, incident response, disaster recovery, privacy	Table + narrative	Yes
4. Regulatory / legal environment	Applicable laws, ML/TF/PF obligations, consumer protection, IP/data protection	Bullet points	Yes
5. Risk management	Financial, operational, cybersecurity, legal, market and reputational risk with mitigants	Table format	Yes

What must the innovation summary in section 1 cover?

Section 1 asks for a concise, self-contained description of the innovation, written to roughly 500 to 1,000 words with a supporting attachment. The Guidelines’ description is short — “Concise description of your innovation” — but that brevity is deliberate: this is the section a reviewer reads first, and the level of innovation it demonstrates is the first line of the Authority’s evaluation criteria.

In practice, this means the summary has to do work beyond describing the product mechanically. Annexure-A’s self-assessment checklist frames “Genuine Innovation” around whether the project “introduces something significantly new or different or is solving an existing problem in a novel way or efficiently”, and separately warns against submissions where “numerous similar models already exist in Pakistan” or where the change amounts only to “minor tweaks to an existing product/services or business model”. A section 1 summary that does not address why the product is not already available in the local market is answering a different, weaker question than the one the Authority is asking.

What technical detail does section 2 require on the blockchain and technology stack?

Section 2 asks for the distributed ledger technology used, the smart contract platform, wallet architecture, and the system’s throughput and scalability, presented as bullet points or a table. The Guidelines specify: “DLT used (public/permissioned), smart contract platform, wallet architecture, throughput, scalability.”

This section is where PVARA forms its first technical view of whether the underlying infrastructure can actually support the testing plan described elsewhere in the application. Public/permissioned status matters because it shapes who can validate transactions and see ledger data; throughput and scalability figures matter because Part B’s technical readiness section asks separately for evidence of internal testing and testnet results, and a mismatch between the architecture claimed here and the readiness evidence shown there is an obvious inconsistency for a reviewer to flag.

What must the cybersecurity strategy in section 3 include?

Section 3 requires a threat model plus a description of security controls, incident response arrangements, disaster recovery planning, and privacy and data protection measures, set out as a table with supporting narrative. The Guidelines list: “Threat model, security controls (encryption, key management, secure coding, audits), incident response, disaster recovery, privacy/data protection.”

Key management deserves particular attention here, since Annexure-A’s self-assessment checklist separately flags “lack of safeguards to ensure custody of consumer’s funds in case of cyber intrusions” as a negative indicator under Technology & Security, and independent third-party security testing is named as a positive indicator. A section 3 submission that describes controls in the abstract, without evidence of an audit having actually been carried out, is answering the checklist’s negative case rather than its positive one.

What regulatory and legal detail does section 4 require?

Section 4 asks the applicant to set out the laws and regulations that apply to its proposed activity, its money-laundering, terrorist-financing and proliferation-financing (ML/TF/PF) obligations, its consumer protection measures, and any intellectual property or data protection law it must comply with, presented as bullet points. The Guidelines describe this as: “Applicable laws/regulations, ML/TF/PF obligations, consumer protection, IP/data protection laws.”

This section overlaps deliberately with the eligibility criteria an applicant must already meet before applying — the Guidelines require applicants generally to “ensure compliance with applicable legal framework” and to confirm the product “is not designed for speculation, anonymity, or illicit activity.” Section 4 is where that general commitment is turned into specifics: which laws, which obligations, and how they are met. A generic statement of intent to comply is not the same submission as a list of the actual laws in scope and the control that addresses each one.

How does section 5’s risk management table differ from the cybersecurity risks in section 3?

Section 5 requires a broader risk table covering financial, operational, cybersecurity, legal/regulatory, market and reputational risk together with the mitigant for each, whereas section 3 is limited to technical and cybersecurity controls specifically. The Guidelines describe section 5 as: “Financial, operational, cybersecurity, legal/regulatory, market and reputational risks with mitigants,” in table format.

The distinction matters because a reviewer reading Part A in sequence will already have seen the technical detail in section 2 and the cybersecurity controls in section 3 by the time they reach section 5. A risk table that simply repeats section 3’s cybersecurity content, rather than adding the financial, market and reputational dimensions the Guidelines separately ask for, leaves gaps precisely where the eligibility criteria’s “comprehensive regulatory and risk assessment” — covering cybersecurity, data privacy, operational risk, market risk and systemic risk — expects to see coverage.

How does the evaluation criteria score what is written in Part A?

Form I’s own Evaluation Criteria section states that applications are assessed on, among other things, “Level of Innovation & Market Relevance”, “Strength of Technology and Cybersecurity Measures” and “Compliance with Regulatory & Legal Requirements” — each mapping directly onto Part A’s sections 1, 2 and 3, and 4 respectively. The submission checklist that follows repeats the same structure item by item: an innovation summary with virtual asset and blockchain detail, a blockchain/DLT architecture description, a cybersecurity plan, and a legal/regulatory compliance analysis.

Because Part A is scored against this checklist directly, the practical discipline is to write each of the five sections so it can be matched, item for item, against the evaluation criteria and submission checklist before filing. Applicants working with a regulatory and licensing adviser typically build this cross-check into the drafting process rather than leaving it to the Authority’s reviewer to make the connection unassisted. Part B of Form I, covering readiness for testing, builds on what Part A establishes here — see our separate walkthrough of Form I Part B for what comes next.

Related reading

• PVARA Exchange License: Capital, Rules & Obligations 2026
• PVARA Transfer & Settlement License: Crypto Payments 2026
• PVARA Licensing Process: NOC to Full Licence, Step by Step

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.