Written by Malik Abbas, CEO of CoinConnect
TL;DR
- The PVARA Transfer & Settlement license authorizes moving virtual assets on behalf of customers — the category that underpins crypto remittance, cross-border payments and stablecoin settlement — at PKR 200 million (~$720,000) capital.
- It is far cheaper than the PKR 1 billion exchange license, and most payments and remittance firms belong here, not in the exchange tier.
- It applies whether you move value on-chain, off-chain, through internal ledgers or through banking rails — and it does not, by itself, authorize exchange, custody, lending or issuance.
- Fiat legs still answer to Pakistan's foreign-exchange, payments and banking laws and the State Bank of Pakistan — the license does not override them.
- You cannot operate as a "pass-through" front for an unlicensed offshore operator, and prefunding or buffering customer assets pulls in custody-grade safeguarding.
Table of Contents
- What is the PVARA Transfer & Settlement license?
- Capital and eligibility requirements
- The perimeter — what it covers and what it does not
- Why this is the remittance and payments license
- The fiat and foreign-exchange reality
- Integrity and accuracy of transfers
- Client instructions and authorization
- Responsibility for failed transfers
- Settlement finality
- Wallet controls, self-hosted wallets and the Travel Rule
- Client assets, prefunding and the custody interface
- AML/CFT, the Travel Rule and sanctions
- The "no pass-through" rule
- Disclosures, receipts and reporting
- A worked example: a stablecoin remittance corridor
- Common mistakes
- FAQ
What is the PVARA Transfer & Settlement license?
A PVARA Transfer & Settlement license authorizes a company to initiate, route, transmit, process or settle the movement of virtual assets on behalf of customers in Pakistan. Defined in Regulation 4(1)(e) of the Virtual Asset Services Regulations, 2026, it requires PKR 200 million in minimum paid-up capital and is the category that underpins crypto remittance, cross-border payments and stablecoin settlement businesses.
This is the deep dive on the transfer and settlement 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 transfer and settlement 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, 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 transfer and settlement is inherently cross-border and AML-sensitive, expect close scrutiny of your sanctions screening, Travel Rule capability and banking arrangements during the application.
If PKR 200 million is more than you wish to commit before proving a corridor works, a reduced-capital, limited-scope license under Regulation 7(5) may be available, with customer and volume caps — often the smartest way to test a remittance corridor first.
The perimeter — what it covers and what it does not
Under Transfer and Settlement Services Handbook section 3(2), you provide these services where, as a business for another person, you "initiate, route, transmit, process, settle or complete the movement of Virtual Assets or related obligations" between customers, between a customer and a third party, or as part of another virtual asset service. The Handbook is technology-neutral: section 2(3) confirms it applies "whether conducted on-chain, off-chain, through internal ledgers, through banking rails, or through hybrid arrangements."
What the license does not do is just as important. Section 3(3) provides that a transfer and settlement authorization does not, of itself, authorize you to operate an exchange, provide discretionary management, provide standalone custody, provide lending and borrowing, provide derivatives, or conduct issuance — beyond the transfer and settlement elements of those activities. If your model also issues a stablecoin or holds balances on an ongoing basis, you need the relevant additional category.
Why this is the remittance and payments license
For foreign payments and remittance companies eyeing Pakistan — one of the world's largest remittance-receiving markets — this is the category that matters, and the most common point of confusion in the entire framework.
Many such firms assume they need the PKR 1 billion exchange license. They usually do not. A business that moves stablecoins across borders, settles payments, or credits PKR-denominated balances is performing transfer and settlement, not operating a trading venue. That places it in the PKR 200 million tier — a fifth of the exchange capital. Getting this classification right is, in dollar terms, the single most valuable decision in the whole entry, and it is why we always start from the activity rather than the brand. The distinction between this and neighboring categories is set out in our PVARA license categories overview.
That said, real remittance products are rarely "pure" transfer. If you also convert currency, hold balances, or issue a token, you stack categories — covered below in the worked example.
The fiat and foreign-exchange reality
Here is the honest caveat a finance-savvy board will want addressed: a PVARA license does not switch off Pakistan's other financial laws. Handbook section 6(1) requires a transfer and settlement licensee to comply with "all applicable laws of Pakistan relevant to transfer, settlement, remittance, payments, foreign exchange, sanctions, AML/CFT/CPF, consumer protection and related matters."
This matters most on the fiat leg. Where a remittance product touches PKR or foreign exchange, it intersects with the State Bank of Pakistan's domain and the country's foreign-exchange and banking regime. Section 17(2) is explicit that settlement netting or offsetting must not be done "in a manner inconsistent with applicable foreign exchange, payment-system, or banking laws, including requirements relating to routing, reporting or settlement of fiat currency transactions through authorised channels."
In plain terms: the crypto leg is regulated by PVARA, but the rupee leg still runs through Pakistan's banking and FX rails. A credible application shows exactly how the fiat side settles lawfully — which is also why crypto banking access is a make-or-break dependency for this category.
Integrity and accuracy of transfers
Because a mistaken transfer can be irreversible, the Handbook front-loads accuracy controls. Section 7(1) requires pre-execution validation of instructions, "verification of destination details, including wallet addresses, account identifiers or equivalent routing details," reconciliation between internal records and on-chain or account balances, and error-prevention measures such as limits and validation checks.
The licensee must also stop, not guess. Section 7(3) prohibits processing a transfer where the available information "gives rise to a material concern that the destination is invalid, incomplete, inconsistent with the Client's instruction, or otherwise gives rise to a material risk of error, fraud, sanctions breach or loss, unless the issue is first resolved." And documented procedures must exist for failed, delayed, erroneous and disputed transfers, including identification, escalation, customer communication, remediation and, where appropriate, compensation (section 7(2)).
Client instructions and authorization
Every transfer must be properly authorized. Section 8(1) requires procedures ensuring that all services for a customer "are authorised by the relevant Client or other person lawfully entitled to give the relevant instruction," with the licensee acting in accordance with that instruction at all times. The licensee must authenticate the origin of instructions, prevent unauthorized execution, and detect anomalies and fraud indicators (section 8(3)).
Ambiguity triggers a stop. Under section 8(4), where the licensee receives "conflicting, ambiguous or incomplete instructions, it shall suspend execution until the issue is clarified or otherwise resolved." Combined with the destination-verification rules, this builds a culture of pausing rather than pushing a doubtful transfer through.
Responsibility for failed transfers
The Handbook allocates responsibility sensibly. A Sender Licensee is responsible for executing the instruction in line with the customer's instructions and disclosed conditions (section 9(1)), and where a transfer fails due to a failure "attributable to the Licensee," it must take prompt remedial action — "tracing, correction, reversal, restoration or compensation" (section 9(2)).
But it is not strict liability for everything. Section 9(3) provides that a licensee is not required to guarantee outcomes that depend "wholly on factors outside its control, including the functioning of public distributed ledger networks, third-party banking rails or recipient-side infrastructure" — provided it acted on the customer's instructions, took reasonable steps to trace and remediate, and communicated promptly. Importantly, section 9(5) preserves PVARA's power to require a licensee to "make a Client whole" where customer-protection considerations and the facts justify it.
Settlement finality
A transfer business must define when a transfer is done. Section 10(3) requires the licensee to "clearly disclose to Clients, and document in its internal procedures, the point at which a transfer or settlement is considered final and the conditions under which a transfer may be reversed or cancelled, if at all." Settlement arrangements must minimize operational, liquidity and counterparty risk (section 10(2)), be supported by reconciliations and exception management, and "not expose Clients or the market to undue and avoidable settlement risk" (section 10(4)).
Unlike the exchange category — which carries a hard 24-hour settlement rule — section 10(5) deliberately avoids "an inflexible universal settlement deadline," recognizing that transfer models and infrastructure dependencies differ. The duty is to design for timely, reliable settlement and to be transparent about finality, not to hit a single fixed clock.
Wallet controls, self-hosted wallets and the Travel Rule
Transfers to and from external wallets are where illicit-finance risk concentrates, so the controls are strict. Section 12(1) requires controls over external-wallet transfers including "wallet verification, sanctions screening, Travel Rule compliance, transaction monitoring, source and destination checks, and risk-based restrictions."
Self-hosted (unhosted) wallets get particular attention. Section 12(2) prohibits transfers of customer virtual assets to or from "self-hosted, unverified, or otherwise non-compliant wallet arrangements" except under controls or approvals specified by the Authority. And section 12(3) lets PVARA "restrict, prohibit, or impose conditions on transfers involving self-hosted wallets, privacy-enhancing technologies, anonymizing protocols, mixers, cross-chain bridge arrangements," or anything that materially impairs traceability. Build your model assuming mixers and anonymizing tools are off the table.
Client assets, prefunding and the custody interface
A transfer license is not a license to use customer money. Section 14(1) bars using, lending, pledging, converting or encumbering customer assets "except to the extent strictly necessary to execute the Client's instructions," and section 14(2) confirms the authorization does not permit rehypothecation, lending or deployment of customer assets "for yield, liquidity management, treasury or proprietary purposes."
Many transfer models require temporary holding, prefunding or buffering of assets to make corridors work. The Handbook permits this — but pulls in custody-grade controls. Section 14(3) requires such arrangements to comply with "the safeguarding, segregation, disclosure and record-keeping requirements under the Regulations and, where applicable, the Custody Services Handbook." If your buffering looks like ongoing holding, you are in custody territory and may need the Custody license too. And section 14(4) clarifies that consent for one settlement-related movement "shall not be treated as blanket consent for unrelated use of Client Assets."
AML/CFT, the Travel Rule and sanctions
AML is not an add-on to transfer and settlement — it is the spine. Section 15 requires the licensee to collect, transmit and receive originator and beneficiary information (the FATF Travel Rule), implement counterparty screening, and retain records for the required periods. It must manage sanctions risk, high-risk jurisdictions and illicit-finance typologies (section 15(3)).
Where required Travel Rule information "cannot be obtained, transmitted, received or verified," section 15(4) requires "risk-based escalation, restriction, rejection, suspension or reporting procedures." Practically, that means FMU goAML registration and a working Travel Rule solution before you launch — the mechanics are in our guide to FMU goAML and the FATF Travel Rule.
The "no pass-through" rule
This provision matters for any firm planning to "white-label" an offshore operator's rails. Section 16(1) requires the licensee to "maintain sufficient operational capability, systems, personnel, and control" to perform the activity "on a substantive and ongoing basis" and "shall not operate as a mere intermediary, booking entity, or pass-through arrangement for an unlicensed or third-party operator."
You can use third-party settlement arrangements and outsourcing, but you cannot outsource core operational responsibility in a way that impairs your oversight (section 16(2)), and you retain full responsibility for compliance and to customers (section 16(3)). Arrangements must give you — and PVARA — audit, access and information rights. The license has to sit on a real, locally controlled operation, not a thin Pakistani shell in front of an offshore engine.
Disclosures, receipts and reporting
Transparency is codified throughout. Section 11 requires clear disclosure of processing times and settlement cycles, fees, transfer risks (network congestion, chain reorganizations, finality risk, third-party dependencies), failure-handling procedures, the point of finality, and any restrictions such as sanctions or Travel Rule limits. Where the flow includes a currency conversion, section 11(2) requires disclosure of "applicable fees, rates, spreads and material execution assumptions."
For each transfer, section 13 requires an acknowledgement on receipt and a completion confirmation, with amounts, references, fees and timing. Public disclosures under section 19 include conflicts of interest, complaints and whistleblowing policies, use of third parties, and "a statement in terms of Travel Rule compliance." Record-keeping under section 18 must be detailed enough to reconstruct individual transfers and support investigations.
A worked example: a stablecoin remittance corridor
Consider a foreign company building a stablecoin-based remittance corridor into Pakistan: a sender abroad pays in, value moves as stablecoin, and the recipient is paid out in PKR.
The core activity — moving the value — is transfer and settlement (PKR 200 million), not an exchange. But the full product likely touches more than one category. If the company also converts currency as part of the flow, the conversion terms must be disclosed under section 11(2). If it holds customer balances between receipt and payout rather than passing them straight through, it crosses into custody and may need the Custody license. If it issues its own stablecoin rather than using a third party's, that is a separate PKR 1 billion issuance category with a 100% reserve. And the PKR payout leg must settle through lawful banking and FX channels under section 6 and section 17(2).
The lean path is clear: scope the activity precisely, enter on a restricted license to prove the corridor with capped volumes, secure banking early, and stack additional categories only as the product genuinely requires them. That is exactly the sequencing we map in the foreign-entrant playbook.
Common Mistakes
- Defaulting to the exchange license. Most payments and remittance models are transfer and settlement (PKR 200 million), not exchange (PKR 1 billion).
- Ignoring the fiat leg. The rupee side still answers to SBP, foreign-exchange and banking laws; the PVARA license does not override them.
- Treating buffered balances as outside custody. Ongoing holding or prefunding pulls in custody-grade safeguarding and possibly a custody license.
- Planning a pass-through shell. You cannot front an unlicensed offshore operator; the license needs a real, locally controlled operation.
- Underbuilding the Travel Rule. Without working originator/beneficiary transmission and sanctions screening, you cannot lawfully transfer.
- Allowing mixers or anonymizing tools. PVARA can restrict or prohibit transfers involving them; design them out.
Get the classification and the fiat-leg design right and the transfer and settlement license is the most cost-effective serious route into Pakistan's payments market; get them wrong and you either over-capitalize or build an unlawful corridor. To map your model to the right category and capital, start with our PVARA licensing service.
Frequently asked questions
PKR 200 million (~$720,000) in minimum paid-up capital under Schedule I, held at all times. It is a fifth of the exchange capital and is share capital inside your Pakistani company, not a fee. A reduced figure may be available under a restricted license (Regulation 7(5)).
Usually, yes. Moving value across borders, settling payments or crediting balances is transfer and settlement, not running an exchange. Firms often over-classify into the PKR 1 billion exchange tier when they belong in the PKR 200 million transfer and settlement tier.
No. The crypto leg is regulated by PVARA, but the rupee leg still answers to the State Bank of Pakistan and Pakistan's foreign-exchange and banking laws. Fiat must settle through authorized channels (Handbook sections 6 and 17).
Only to the extent strictly necessary to execute instructions. Prefunding or buffering must meet safeguarding and segregation rules and, where it amounts to ongoing holding, may require a separate custody license (Handbook section 14).
No. Section 16(1) prohibits operating as a "pass-through arrangement for an unlicensed or third-party operator." The license must sit on a substantive, locally controlled operation with real systems, personnel and oversight.
Only under controls or approvals specified by the Authority. PVARA can restrict or prohibit transfers involving self-hosted wallets, mixers, anonymizing protocols and cross-chain bridges where they impair traceability (Handbook section 12).
Full AML/CFT including the FATF Travel Rule — collecting and transmitting originator and beneficiary information, sanctions screening, and FMU goAML reporting. Where Travel Rule data cannot be verified, the transfer must be escalated, restricted, rejected or reported (Handbook section 15).
Building a crypto payments or remittance corridor into Pakistan? CoinConnect classifies your model to the right category, designs the lawful fiat-leg and Travel Rule architecture, and assembles the transfer and settlement application. Book a free 30-minute discovery call →
Last reviewed: June 2026. Based on the draft Pakistan Virtual Asset Services Regulations, 2026 and the Transfer and Settlement Services Handbook, 2026, published for public consultation. Provisions are subject to change pending finalization.
External sources: PVARA · SECP · State Bank of Pakistan · FATF – Pakistan