Receiving a PVARA licence is not the end of the regulatory project. It is the point at which policies become measurable obligations.

The Pakistan Virtual Assets Regulatory Authority can now test whether customer due diligence works, Travel Rule data follows transfers, private keys are properly controlled, client assets reconcile, regulatory capital remains available and material incidents are reported promptly.

A policy that secured the licence but does not match live systems, staffing or transaction flows can become evidence of a compliance failure.

This guide explains the principal PVARA post-licensing requirements under the Virtual Assets Act, 2026, the Pakistan Virtual Asset Services Regulations, 2026 and applicable federal AML/CFT/CPF laws.

PVARA post-licence compliance 

  • AML risk assessment: At least annually and after material change
  • Travel Rule threshold: PKR equivalent of USD 1,000
  • Client-money and virtual-asset reconciliation: At least daily where movements occur daily
  • Proof of reserves: Independent validation every six months; report within 30 days after period-end
  • Operational audit: Annually, including verification of client-asset segregation | Records: AML statutory period or seven years, whichever is longer
  • Material events: Notify PVARA without delay
  • Periodic returns: Form, content and frequency prescribed by PVARA on a risk basis

The licence must remain true after approval

A PVARA licence authorises only the categories and activities stated on it, subject to its conditions. The VASP must therefore keep its operating model aligned with the application, business plan and approved controls.

Post-licence governance should detect changes involving:

  • products, tokens and customer segments;
  • ownership, Controllers, directors and Key Individuals;
  • custody, wallet or key-management models;
  • banks, liquidity providers and material outsourcing;
  • countries served and cross-border delivery;
  • regulatory capital, liquidity and insurance;
  • technology architecture and data location; and
  • licence conditions or regulatory directions.

Some changes require prior approval; others require notification without delay. The compliance function should maintain an obligations register that identifies the legal trigger, owner, approval path, deadline and evidence for each change.

AML/CFT/CPF: an operating system, not an onboarding check

Regulations 93–101 create a continuing financial-crime framework alongside the Anti-Money Laundering Act, 2010 and binding instruments issued under it.

MLRO authority and accountability

The VASP must appoint a fit-and-proper Money Laundering Reporting Officer with sufficient seniority, expertise and authority. The MLRO must have direct Board access and unfettered access to relevant records, systems and personnel. Continuing suitability must be reviewed at least annually.

The MLRO oversees:

  • AML/CFT/CPF policies and internal controls;
  • the enterprise-wide risk assessment;
  • customer and beneficial-owner due diligence;
  • transaction monitoring and sanctions screening;
  • suspicious transaction reporting and FMU liaison; and
  • periodic Board reporting on effectiveness, issues and remediation.

Tasks may be delegated, but accountability remains with the MLRO and legal responsibility with the VASP. A foreign group team or vendor cannot replace local oversight.

Enterprise-wide risk assessment

Regulation 97 requires an assessment covering customer types, products, delivery channels, transaction patterns, geographies and virtual-asset-specific risks, including anonymity-enhancing features.

It must be reviewed:

  • at least annually; and
  • promptly following a material change to the business, products, customers, geography or threat landscape.

The outcome must change actual controls. A higher-risk finding should affect onboarding evidence, enhanced due diligence, monitoring scenarios, approval limits, staffing or product availability.

Where privacy-enhancing assets prevent compliance with CDD, monitoring, sanctions, recordkeeping or Travel Rule duties, the VASP must not provide services involving those assets.

Customer due diligence and monitoring

Regulation 98 requires risk-based CDD, including identification and verification of customers and beneficial owners, understanding the purpose and intended nature of the relationship, source-of-funds information and ongoing monitoring.

Enhanced due diligence applies to higher-risk relationships, including politically exposed persons and cases where anonymity features materially increase risk. If required due diligence cannot be completed, the VASP must not establish or continue the relationship or execute the transaction, except where applicable law permits otherwise.

The customer file should remain current. Trigger reviews may arise from material transaction changes, new wallets, sanctions exposure, adverse information, ownership changes or inconsistencies with the expected profile.

Reliance on a third-party KYC provider does not transfer responsibility. The VASP needs access to underlying evidence, assurance over the methodology and controls for outages, false matches and incomplete data.

Blockchain analytics and suspicious activity

Regulation 96 requires monitoring and screening capable of detecting suspicious activity, sanctions exposure and other illicit-finance risk. Where distributed-ledger analytics are used, the VASP must document why the tool was selected, its known limitations, scenario and threshold governance and periodic effectiveness reviews.

Alerts require documented investigation, disposition, escalation and quality assurance. The system should address structuring, mixers, darknet exposure, scams, sanctions, rapid pass-through activity, chain-hopping and transactions inconsistent with the customer profile.

Under Regulation 99, suspicious transaction and other prescribed reports go to the Financial Monitoring Unit under the federal AML framework. PVARA must also be notified of material AML/CFT/CPF breaches, control failures or significant exposure events in the manner and timeframe it specifies. STR confidentiality must be preserved; reporting to PVARA does not authorise unlawful disclosure of protected STR information.

Travel Rule compliance

Regulation 100 implements section 47 of the Act, applicable federal wire-transfer requirements and FATF Recommendation 16.

For a virtual asset transfer meeting or exceeding the PKR equivalent of USD 1,000, the VASP must obtain, verify where required, and transmit or make available accurate originator and beneficiary information.

The minimum data includes:

  • originator’s full name;
  • originator account number, wallet address or unique transaction identifier;
  • additional legally required identifiers, potentially including address, national identification number, customer number or date and place of birth;
  • beneficiary’s name; and
  • beneficiary account number, wallet address or unique identifier.

An ordering VASP must hold the information before initiating the transfer. A beneficiary VASP must obtain it before making received assets available to the customer. Information must be producible to the FMU, PVARA and other competent authorities upon lawful request.

What about unhosted wallets?

Transfers involving self-hosted or unhosted wallets are not automatically prohibited. They require risk-based controls addressing ownership or control, incomplete counterparty information, sanctions and illicit-finance exposure, transaction purpose and patterns designed to evade the threshold.

Depending on risk, controls may include wallet-ownership evidence, cryptographic signing, test transfers, blockchain analysis, enhanced due diligence, limits or rejection.

Counterparty VASP due diligence

Before establishing a material transfer relationship with a foreign VASP, the Pakistan licensee must assess its AML and Travel Rule controls. Regulation 100 requires that review annually and when heightened-risk indicators arise.

The VASP should assess regulatory status, ownership, jurisdiction risk, sanctions controls, data quality, transmission security, response procedures and whether the counterparty permits unacceptable anonymous activity.

Travel Rule technology does not itself deliver compliance. The operating procedure must decide what happens when data are missing, conflicting, late or technically impossible to transmit—and preserve the decision trail.

Cybersecurity and technology resilience

Regulations 58–66 require continuing technology governance proportionate to the VASP’s systems, custody exposure, third-party dependencies and customer base.

Governance and policy

The VASP must designate a senior Information Security Officer; PVARA may require a dedicated CISO. The Board or a committee must approve the cybersecurity policy and review it at least annually, after material changes and following a significant incident.

The control framework should cover:

  • asset and data classification;
  • authentication, privileged access and segregation of duties;
  • secure configuration, patching and vulnerability management;
  • logging, monitoring and detection;
  • secure development and change management;
  • incident response, root-cause analysis and remediation;
  • backups, recovery and business continuity;
  • capacity and operational resilience;
  • third-party and group technology; and
  • controls for anomalous or high-risk virtual asset transactions.

Outsourcing cloud, custody or security operations does not outsource accountability. Contracts must support access, audit, incident notification, resilience, data protection and exit.

Wallet and private-key controls

Regulation 61 requires secure key generation, storage, use, backup and recovery; documented approvals; access segregation; auditable administrative records; prompt revocation after role changes; and procedures for actual or suspected compromise.

No person or single system should ordinarily be able to initiate and complete a material customer-asset transfer alone. The architecture should match the documented hot, warm and cold wallet model and cover sub-custodians and recovery arrangements.

Testing and assurance

Regulation 62 requires risk-based testing, including vulnerability assessment and penetration testing at appropriate intervals and after material changes. Security monitoring and control testing are ongoing, and high-risk findings must be remediated within reasonable timeframes and escalated where material.

Material smart contracts require independent security review before deployment or major upgrade and periodically thereafter. Evidence of tests, findings and remediation must be retained for PVARA.

Cyber incident reporting

Under Regulation 90, cybersecurity and data incidents that materially affect—or are reasonably likely to affect—compliance, financial soundness, operational resilience or customer-asset safety must be notified to PVARA without delay.

Do not wait for a perfect forensic report. The initial notice should state what is known, affected systems and customers, asset exposure, containment, service impact and responsible contacts. Supplemental updates should follow as facts develop.

Client money and client virtual assets

Client property must remain identifiable, segregated and unavailable for the VASP’s own obligations.

Client money

Under Regulations 103–107, client money must be held in designated Client Accounts with a bank licensed by the State Bank of Pakistan. The arrangements should prevent bank set-off against the VASP, and client money must generally be paid into the account immediately and no later than the next Business Day.

The VASP cannot use one customer’s money for another customer or maintain negative balances through impermissible netting.

Retail clients must receive statements at least monthly. Reconciliations must occur at a frequency proportionate to activity and at least daily where money moves daily. Shortfalls and discrepancies must be investigated promptly; an unresolved material discrepancy is notified to PVARA without delay.

Client virtual assets

Regulations 108–111 require client virtual assets to be protected and segregated from the VASP’s assets. Legal ownership, wallet designation, internal ledgers and control of private keys all matter.

The VASP must not use, pledge, lend, stake, encumber or rehypothecate client assets unless expressly permitted and supported by the customer’s prior explicit, informed consent. Records must prove the consent and permitted use.

Where virtual asset movements occur daily, reconciliation must be at least daily. It should compare client liabilities by asset with on-chain or equivalent control evidence and account for pending or unconfirmed transactions. Material unresolved discrepancies require prompt notification, root-cause analysis and remediation.

Proof of reserves

Regulation 112 requires liabilities for client virtual assets to be fully matched by reserve assets or equivalent safeguarding arrangements.

Independent validation is required every six months, or earlier if PVARA requires. The report must be filed within 30 days after the six-month period. Gross and net client liabilities are also reported six-monthly, subject to any enhanced frequency imposed by PVARA.

Proof of reserves does not replace segregation, legal ownership analysis, reconciliation or insolvency protection. A cryptographic snapshot may show assets while omitting liabilities, encumbrances or loss of effective control.

Prudential and regulatory reporting

Paid-up capital, net liquid assets and insurance are continuing requirements. A VASP must monitor them before—not after—a threshold is breached.

Regulation 88 allows PVARA to prescribe reporting templates and frequencies based on the licence and risk profile. Periodic returns may include:

  • financial statements and prudential calculations;
  • capital, liquidity and safeguarding information;
  • client-asset balances and reconciliations;
  • key risk and compliance indicators;
  • AML/CFT information permitted by law;
  • material control findings and remediation; and
  • activity-specific or supervisory information.

The framework should distinguish fixed regulatory requirements from deadlines contained in the licence, PVARA directions or future reporting templates. Do not invent one universal calendar where PVARA has reserved risk-based frequency.

Event-driven notifications

Regulation 90 requires notification without delay of matters materially affecting, or likely to affect:

  • regulatory compliance;
  • financial soundness or operational resilience;
  • client-asset safety; or
  • fitness, propriety or governance.

Examples include insolvency proceedings, material litigation or regulatory investigations, material legal breaches and cyber or data incidents. Prudential shortfalls, unresolved client-asset discrepancies, material AML failures and significant outsourcing disruptions may trigger separate notification duties.

A notification should not be delayed because every fact is unavailable. Submit the reasonably available information, identify uncertainties and provide updates.

Audit, records and Board oversight

Regulations 86–87 require complete, accurate and current records, retained for the AML statutory period or seven years—whichever is longer. Records must support supervision, investigations, disputes and reporting.

The external auditor audits financial statements, and the VASP’s operations must be audited annually, including verification of client-asset segregation. An independent internal audit function reports to the Board or audit committee under a risk-based plan.

The Board should receive decision-useful information, including:

  • AML risk, alerts, STR governance and sanctions exposure;
  • Travel Rule exceptions and counterparty risk;
  • capital and liquidity buffers;
  • client-asset reconciliation breaks;
  • cyber incidents, vulnerabilities and overdue remediation;
  • complaints, fraud and market-conduct indicators;
  • outsourcing performance and concentration; and
  • regulatory filings, breaches and open commitments.

Board minutes should evidence challenge, decisions, deadlines and follow-up—not merely receipt of a dashboard.

A practical compliance calendar

Frequency or trigger
Core action

Continuous
CDD monitoring, sanctions screening, transaction monitoring, asset safeguarding and cyber detection
Daily where daily movements occurClient-money and client-virtual-asset reconciliations

Monthly
Retail client-money statements; internal prudential and liquidity oversight; regulatory returns where prescribed

Six-monthly
Gross/net client liabilities and independent proof-of-reserves validation; report within 30 days

Annually
AML risk assessment, MLRO suitability review, cybersecurity-policy review, operational audit and risk-based counterparty VASP reviews

After material change
Update AML risk assessment, technology controls, product risk and relevant policies

Without delay
Material incidents, breaches, unresolved discrepancies and other Regulation 90 events

As directed
PVARA returns, additional information, enhanced testing, assurance or remediation reporting

This is a baseline. The licence, activity-specific rules and written PVARA directions may impose additional or more frequent requirements.

Common post-licence failures

  1. Freezing the application policies. Live products change while controls remain unchanged.
  2. Treating KYC as AML. Onboarding works, but ongoing monitoring and escalation do not.
  3. Buying a Travel Rule tool without an exception process. Missing data accumulate without decisions.
  4. Outsourcing accountability. The VASP cannot access vendor evidence or challenge group controls.
  5. Reconciling only totals. Asset-by-asset shortages disappear inside an aggregate figure.
  6. Using proof of reserves as proof of solvency. Liabilities, ownership and encumbrances are incomplete.
  7. Waiting for certainty before reporting. A material event becomes a late notification.
  8. Operating at prudential minimums. Ordinary expenses create a capital or liquidity breach.
  9. Closing audit findings administratively. Evidence does not show that remediation works.
  10. Sending dashboards without Board challenge. Oversight exists on paper but not in decisions.

Final word

Post-licence compliance is the discipline of keeping the regulated institution true every day.

Customer risks change. Wallets move. Sanctions lists update. Vendors fail. Threat actors adapt. Capital is spent. A PVARA licensee must detect those changes, make defensible decisions, protect customer property and tell the regulator promptly when something material goes wrong.

The strongest framework is therefore not the longest manual. It is the system that connects transactions to alerts, alerts to accountable people, decisions to evidence, evidence to the Board and material facts to PVARA within the required time.

Legal disclaimer: This article provides general information as at 30 August 2026 and does not constitute legal, regulatory, cybersecurity, tax, financial or investment advice. Obligations depend on the licence categories, conditions, business model, federal AML/CFT/CPF laws and subsequent PVARA rules, templates and directions. Licensees should obtain professional advice and confirm current requirements directly with PVARA, the FMU, SBP and other competent authorities.

FAQs

1. What is the PVARA Travel Rule threshold?

The threshold is the PKR equivalent of USD 1,000. Transfers at or above it require the prescribed originator and beneficiary information, subject to federal AML/CFT requirements.

2. Are transfers to unhosted wallets prohibited?

No automatic prohibition is stated. They require risk-based controls addressing ownership, incomplete counterparty data, sanctions exposure, anonymity and evasion risk. A transfer may need restriction or rejection where risk cannot be managed.

3. How often must client assets be reconciled?

Frequency must be proportionate. Where client money or client virtual asset movements occur daily, reconciliation must be at least daily.

4. How often is proof of reserves required?

Independent validation is required six-monthly unless PVARA requires it earlier. The validation report is submitted within 30 days after the relevant six-month period.

5. When must a cyber incident be reported?

Notify PVARA without delay where the incident materially affects, or is reasonably likely to affect, compliance, financial soundness, operational resilience or client-asset safety. Follow with updates as information develops.

6. Does PVARA prescribe every reporting deadline?

No. Some deadlines are fixed in the regulations; Regulation 88 allows PVARA to specify other returns, forms and frequencies on a risk basis. The individual licence and written directions must also be checked.