Written by Malik Abbas, CEO of CoinConnect
TL;DR
- The PVARA Custody license authorizes a company to safeguard, hold, control or administer customer virtual assets and private keys — and requires PKR 200 million (~$720,000) in minimum paid-up capital.
- It is the foundation under almost every exchange, broker and payments business that touches customer assets, and it cannot be substituted by "incidental" holding under another license.
- The strongest protection it gives customers is statutory: customer assets do not form part of the custodian's estate in insolvency.
- Core custody cannot be outsourced — you may use wallet-infrastructure providers only in a support role, and the custodian keeps ultimate control, daily reconciliation and proof of reserves.
- A custodian cannot use, lend, pledge or stake customer assets on the strength of the custody license alone — that requires the customer's explicit, prior, informed consent.
Table of Contents
- What is a PVARA Custody license?
- Capital and eligibility requirements
- When you are "providing custody" (the perimeter)
- Segregation and the insolvency shield
- Key management and wallet architecture
- Omnibus versus segregated wallets
- Reconciliation, shortfalls and proof of reserves
- The rule on using customer assets
- Customer statements, disclosures and agreements
- What you cannot outsource
- Choosing a wallet-infrastructure provider
- Incident management and independent assurance
- How custody fits with capital, reserves and liquidity
- A worked example: the exchange that also needs custody
- Common mistakes
- FAQ
What is a PVARA Custody license?
A PVARA Custody license authorizes a company to safeguard, hold, control or administer customer virtual assets — including custody of the private keys that allow those assets to be moved — on behalf of customers in Pakistan. Defined in Regulation 4(1)(d) of the Virtual Asset Services Regulations, 2026, it requires PKR 200 million in minimum paid-up capital and carries some of the strictest safeguarding obligations in the entire framework.
This is the deep dive on the custody category. For the full set of ten, see our PVARA license categories overview; for the big picture, the complete licensing guide.
Conversions use an indicative rate of PKR 278 = USD 1 (June 2026).
Capital and eligibility requirements
The custody license sits in the mid-tier of the Schedule I capital table: PKR 200 million (~$720,000) minimum paid-up capital, held "at all times" under Regulation 31(1). This is share capital inside your Pakistani company, not a fee — see the full capital breakdown.
On top of capital, custody applicants must satisfy the general eligibility bars: a Pakistani company (Regulation 5), a resident key individual with real authority (Regulation 10(4)), a resident compliance officer (Regulation 23), and fit-and-proper directors, controllers and a qualified CEO (Regulation 8, Schedule III). Because custody is the activity most directly exposed to customer loss, expect particularly close scrutiny of your technology, key-management and assurance arrangements during the application.
If PKR 200 million is more than you wish to commit before proving demand, a reduced-capital, limited-scope license under Regulation 7(5) may be available, with customer and product caps.
When you are "providing custody" (the perimeter)
Many businesses provide custody without realizing it. Under Custody Services Handbook section 3(2), you are providing custody where you hold, control, safeguard or administer customer virtual assets — including where you, or someone acting for you, "holds or can access the private keys, seed phrases, signing devices, authorization credentials or other means necessary to transfer or otherwise dispose of Client Virtual Assets."
The line is control. If you can move the customer's assets, you are a custodian. Pure self-custody software — where the customer keeps exclusive control of their own keys — is excluded under Regulation 4(1)(d). But an exchange with integrated wallets, a broker that briefly holds assets to settle, or a payments firm that warehouses balances is squarely inside the custody perimeter.
Critically, custody is not something you can bolt onto another license as a convenience. Handbook section 3(4) provides that a custody arrangement forming part of another activity "shall not be structured or operated in a manner that circumvents the requirements applicable to any other License Category." If the substance is ongoing custody, you need the custody authorization.
Segregation and the insolvency shield
The single most important protection a PVARA custodian gives its customers is legal, not technical. Under Handbook section 6, customer virtual assets "are not owned by the Custodian" and must be segregated from the custodian's own assets and from those of other persons — in wallet structures, account structures and internal ledgers alike.
The protection goes further in insolvency. Handbook section 7(1) states, in unusually direct terms:
"Notwithstanding anything to the contrary contained in any other law for the time being in force, Customer Assets held by a Licensee shall not form part of the Licensee's estate in the event of its insolvency or liquidation."
This is the assurance institutional clients care about most. If the custodian fails, customer assets are ring-fenced from the custodian's creditors and its insolvency estate, to the extent permitted by law. Where custody involves cross-border structures, section 7(4) requires the custodian to obtain legal opinions supporting that protection — a step foreign-linked custodians should plan for early.
Key management and wallet architecture
Custody is, in practice, key management. Handbook section 8 requires effective controls over private keys, seed phrases, signing devices and credentials, including segregation of duties, secure key generation and backup, and "multi-factor, multi-approval or multi-signature arrangements where appropriate."
Two requirements deserve emphasis. First, the cold-storage bias: section 8(7) requires a "risk-based wallet allocation framework" that limits the proportion of customer assets held in hot or online environments and "ensures that the majority of Client Assets are held in secure offline or equivalent environments where appropriate."
Second, the elimination of single points of failure. Section 9(6) requires key-management arrangements that, where appropriate to scale and risk, "incorporate multi-party computation, multi-signature or equivalent distributed control mechanisms," "ensure that no single individual or system can unilaterally transfer Client Assets," and apply "geographic, organizational and logical separation of key components." Key and seed backups must be stored separately from primary keys and protected to at least the same standard. This connects directly to the broader key and wallet rules in Regulation 61.
Omnibus versus segregated wallets
A practical design decision every custodian faces is whether to hold customer assets in pooled (omnibus) wallets or in segregated wallets tied to a single customer or clearly identified group. The Handbook recognizes both. A "Segregated Wallet" is defined in section 2 as a custody wallet designated for a single client or clearly identified client group, but one that "remains subject to the Custodian's control, governance, safeguarding, monitoring and compliance framework."
That last point matters. Section 8(4) makes clear that using segregated wallets "shall not, of itself, require or permit direct independent control of Client Virtual Assets by the Client unless otherwise expressly approved by the Authority." In other words, segregation improves traceability and insolvency comfort, but it does not turn the arrangement into self-custody — the custodian still controls the keys and remains fully responsible.
Whichever model you choose, the internal-ledger requirement is the same. Section 6(3) requires records that "clearly identify which wallets, addresses, accounts, sub-accounts or ledger designations contain Client Assets, including through internal ledger tagging where appropriate." Most institutional custodians run a hybrid: omnibus wallets for operational efficiency, robust internal ledgers for per-customer attribution, and segregated wallets for clients who require or pay for them. Your custody agreement must disclose which model applies, because section 14(2)(b) lists "use of Omnibus versus Segregated Wallets" as a mandatory disclosure.
Reconciliation, shortfalls and proof of reserves
A custodian must prove, continuously, that it holds what it owes. Handbook section 10(1) requires reconciliations of customer assets "at least daily, and more frequently where appropriate" — comparing customer ledger balances against on-chain balances and identifying any breaks, shortfalls or unexplained differences.
When a shortfall appears, the obligation is strict. Section 10(6) requires the custodian to "take immediate steps to make good the shortfall from its own resources," prohibits allocating losses to customers except where expressly permitted, and requires notifying the Authority and affected customers without delay. The custodian, not the customer, absorbs the gap.
On top of reconciliation, section 11 requires "proof-of-reserves or equivalent assurance procedures" sufficient to demonstrate, on an ongoing basis, that liabilities to customers are fully matched by safeguarded holdings — which may include third-party attestation and cryptographic verification. For an industry scarred by exchange collapses, this is the rule that rebuilds trust.
The rule on using customer assets
This is where many global models break against the Pakistani regime. A custody license does not let you do anything with customer assets except safeguard them. Handbook section 12(1) is explicit:
"A Custodian shall not use, sell, transfer, assign, pledge, loan, stake, rehypothecate, encumber or otherwise dispose of Client Assets solely by virtue of its Custody License."
Use is permitted only where it is lawful, the customer has given "explicit, prior, informed consent," the client agreement clearly discloses the activity and how rewards and losses are allocated, and the custodian "holds any additional License Category required for the substance of the relevant activity." In other words, staking or lending customer assets is not a custody activity — it requires consent plus the relevant separate license.
There is also a default in the customer's favor: under section 12(5), any rewards or benefits attributable to customer assets — airdrops, forks, staking rewards — "shall accrue to the Client unless otherwise agreed in advance" and clearly disclosed.
Customer statements, disclosures and agreements
Transparency to customers is codified. Under Handbook section 13, a custodian must provide periodic statements "not less frequently than monthly" (unless otherwise agreed with professional or institutional clients), showing transactions, dates, amounts and balances per asset.
The custody agreement must make ownership unambiguous. Section 14(3) requires the agreement to state clearly that "ownership of Client Assets remains with the Client," and section 14 requires disclosure of the custody model, hot-versus-cold and omnibus-versus-segregated wallet arrangements, insolvency treatment, any permitted use of assets, use of third-party custodians, and the cybersecurity and reimbursement framework. These feed the general client-agreement and disclosure duties in Regulations 52 and 54.
Beyond customer-facing disclosure, section 15 requires the custodian to publish on its website a description of material conflicts of interest arising from custody activities, its policies on data privacy, whistleblowing and complaints, and a statement of whether customer assets are held with third-party custodians, including their identity and jurisdiction where appropriate. These public disclosures must be kept current and reviewed whenever a material change occurs.
What you cannot outsource
This rule surprises foreign operators who plan to lean on an offshore custody partner. Handbook section 16(1) prohibits it:
"A Custodian shall not outsource or delegate the core custody activity for which it is licensed. The Custodian shall at all times retain effective control, governance, oversight, and responsibility in respect of Client Assets and custody operations."
Core custody includes ultimate responsibility for safeguarding, governance, wallet architecture, key management, reconciliation and control of access to assets. You may use wallet-infrastructure and technology providers, but only "in a limited support capacity" and without transferring effective control. Such providers must meet hard selection criteria under section 16(7), including institutional-scale capability, regulatory oversight in an acceptable jurisdiction, and "recognized independent security certifications, including SOC 2 Type II or equivalent." The license, and the responsibility, stay with you in Pakistan.
Choosing a wallet-infrastructure provider
Because you cannot outsource core custody but can use infrastructure support, the selection of that provider becomes a regulated decision in its own right. Section 16(7) sets documented selection criteria designed to ensure any appointed wallet-infrastructure provider has "the operational capability, security standards, governance arrangements, and regulatory standing appropriate to the protection of Client Assets." At a minimum, the provider must:
- demonstrate institutional-scale operational capability and experience in virtual asset custody or wallet infrastructure;
- operate under, or be subject to, regulatory oversight in a jurisdiction acceptable to the Authority;
- maintain recognized independent security certifications, including SOC 2 Type II or equivalent acceptable to the Authority;
- maintain segregation, operational resilience, business continuity and, where applicable, insurance arrangements consistent with the Handbook; and
- be capable of supporting the custodian's reconciliation, audit and supervisory reporting obligations.
The arrangement must also preserve the Authority's audit, inspection and information rights, and must not result in customer assets being held "in individually controlled wallets or structures outside the custody and control framework approved by the Custodian and the Authority" (section 16(13)). Practically, this means your vendor due diligence, contract and ongoing monitoring all need to be documented to a standard you can show a supervisor — and your contract must give PVARA, directly or indirectly, the access it needs.
Incident management and independent assurance
Custody carries enhanced incident and assurance duties. Under section 17, material custody incidents — loss of keys, cyber breaches, misallocation of assets or significant delays in returning assets — must be reported to the Authority as soon as practicable, and the custodian must keep an incident log recording "near misses as well as actual losses."
Independent oversight is built in. Section 4(6) requires the custodian to obtain independent assurance over its custody controls — safeguarding, reconciliation and key management — and to make those reports available to the Authority "on half yearly basis." Staking or yield activity from custody requires explicit prior written customer consent (section 18), and a special, tightly controlled regime applies to assets held for Sovereign Clients such as the Federal Government or the State Bank of Pakistan (section 19).
How custody fits with capital, reserves and liquidity
A common modeling error is to treat the PKR 200 million custody capital as the whole prudential picture. It is not. The custody figure is your minimum paid-up capital, but three further obligations sit alongside it.
First, liquid financial resources under Regulation 32 — a buffer, separate from share capital, sufficient to meet obligations as they fall due, including under stress. Second, risk-based add-ons under Regulation 35(4): because a custodian holds large volumes of customer assets, the Authority may require additional capital, liquidity, insurance or reserve assets "having regard to the size, scope, geographic exposure, complexity and nature" of the activity. Third, insurance under Regulation 36, where the Authority can specify minimum coverage — crime, cyber and professional indemnity are all relevant to a custody model.
The takeaway: budget the PKR 200 million as a floor, then layer a realistic liquidity buffer, an insurance program calibrated to your custody footprint, and headroom for add-ons. A custodian that capitalizes only to the bare Schedule I minimum will struggle to satisfy a supervisor that it can absorb a shortfall from its own resources under section 10(6).
A worked example: the exchange that also needs custody
Consider a foreign exchange entering Pakistan with integrated wallets, so customers can buy, hold and withdraw on the platform. The exchange license (PKR 1 billion) authorizes the trading venue — but the moment the platform holds or controls customer assets, the custody perimeter is crossed.
In practice this firm needs both categories. The Exchange Services Handbook itself points to this: its section 15 requires an exchange holding customer assets to comply with the safeguarding rules "and, where applicable, the Custody Services Handbook." Capital is set on a risk basis under Regulation 31(2) rather than by simply adding PKR 1 billion and PKR 200 million, but the firm must build genuine custody infrastructure — cold-storage ratios, multi-party key control, daily reconciliation, proof of reserves and half-yearly independent assurance — not just a database of balances.
The alternative is a non-custodial design, where customers retain exclusive control of their own keys and the platform never holds assets. That can keep a business outside the custody perimeter — but it is a fundamentally different product, and few retail exchanges adopt it. Decide this early, because it changes your license stack, your capital plan and your technology build.
Common mistakes
- Assuming "incidental" holding avoids the license. If the substance is ongoing custody, Handbook section 3(4) and Regulation 4 require the custody category — you cannot structure around it.
- Planning to outsource custody offshore. Core custody cannot be delegated; only limited support functions can.
- Staking or lending customer assets on the custody license alone. That needs explicit consent plus a separate license category.
- Under-building key management. Single points of failure, shared backups or weak cold-storage ratios will fail supervision.
- Treating proof of reserves and daily reconciliation as optional. They are continuous obligations, with shortfalls made good from the custodian's own resources.
- Capitalizing only to the bare minimum. Liquidity buffers, insurance and possible add-ons sit on top of the PKR 200 million floor.
Get the safeguarding architecture right from the start and the custody license is a genuine trust asset; treat it as a wallet feature and you will not pass review. To map the full requirement against your model, start with our PVARA licensing service or the foreign-entrant playbook.
Frequently asked questions
Here are some common questions about our company.
PKR 200 million (~$720,000) in minimum paid-up capital under Schedule I, held at all times. This is share capital inside your Pakistani company, not a fee. A reduced figure may be available under a restricted license (Regulation 7(5)).
Whenever it holds, controls or can access the keys needed to move a customer's virtual assets (Handbook section 3). Self-custody software where the customer keeps exclusive control of their keys is excluded, but integrated exchange wallets and warehoused balances are not.
Yes. Handbook section 7(1) provides that customer assets "shall not form part of the Licensee's estate in the event of its insolvency or liquidation," ring-fencing them from the custodian's creditors to the extent permitted by law.
Not on the custody license alone. Handbook section 12 prohibits using customer assets except with the customer's explicit, prior, informed consent, full disclosure, and the relevant additional license category for the activity.
No. Core custody cannot be outsourced (Handbook section 16). Wallet-infrastructure providers may be used only in a limited support role, must meet criteria such as SOC 2 Type II certification, and the custodian retains ultimate control and responsibility.
Reconciliation must be at least daily (Handbook section 10), and proof-of-reserves or equivalent assurance must be maintained on an ongoing basis (section 11), with independent assurance reports provided to the Authority half-yearly.
Omnibus wallets pool multiple customers' assets with per-customer attribution kept on internal ledgers; segregated wallets are designated for a single customer or clearly identified group. Both remain under the custodian's control — segregation does not give the customer independent control unless the Authority expressly approves it (Handbook section 8(4)).
If the exchange holds or controls customer assets, yes — it takes on custody obligations and, where applicable, the Custody Services Handbook. A purely non-custodial exchange, where customers keep exclusive control of their own keys, may stay outside the custody perimeter.
Under Regulation 36 the Authority may require insurance commensurate with the custody footprint, which can include crime, cyber and professional indemnity cover. Insurance is in addition to capital, not a substitute for it.
Building custody into your Pakistan operation? CoinConnect designs the safeguarding, key-management and assurance architecture PVARA expects — and assembles the custody-license application to match. Book a free 30-minute discovery call →
Last reviewed: June 2026. Based on the draft Pakistan Virtual Asset Services Regulations, 2026 and the Custody Services Handbook, 2026, published for public consultation. Provisions are subject to change pending finalization.
External sources: PVARA · SECP · State Bank of Pakistan