PVARA notified the full framework on 21 August. Regula’s catalogue reads it →
RegulaComply
Early access
All 11 modules live · 38 obligations · 6 instruments

The compliance operating system for Pakistan’s virtual asset economy.

One rule catalogue drives customer due diligence, sanctions screening, transaction monitoring, the Travel Rule, licence readiness. When PVARA moves a threshold, that is a catalogue edit, not a release.

Most tools stop at a flag. Regula pre-fills Form A6, the annual AML/CFT return, and the goAML report the FMU’s schema validates. Each cites its rule.

Join early accessSee the coverage proof

In the catalogue today

VA Act 2026 s.47(1)NOC Reg. 12FATF Recommendation 16NOC Reg. 11
Operations/Alerts
API connected

Alerts

Alert queue over HIGH and CRITICAL risk scores, with a real Form A7 Internal SAR draft: transaction facts, the rule that fired, and a narrative, generated on demand. Exports as a goAML STR-F filing, validated against the FMU's 5.0.2 schema before release.

TransactionRiskStatus
Today3 alerts
0x7a3f0c19e4b2d8a6f15c3e7b90d4a2c8e6f1b3d5a7c9e2f4b6d8a0c2e4f6c41dHighFiled

Form A7 Internal SAR · NOC Regulations 2025 Form A7

Export draft

Transaction 0x7a3f0c19e4b2d8a6f15c3e7b90d4a2c8e6f1b3d5a7c9e2f4b6d8a0c2e4f6c41d on ETHEREUM moved 1500.00 USD-equivalent of USDT from 0x9b21f6d04a77c3e8b5f2a19d6c4e7b0f3a8d5c2e to 0x4e8c2a71d9b5f306e1c7a2d8f4b9e5c3a6d0b7f2, recorded at 2026-09-17T09:31:00+00:00. The transaction was classified HIGH under NOC Reg. 11 (indirect_illicit_exposure_2hop 0.62 >= 0.5).

Why it fired · NOC Reg. 11

  • indirect_illicit_exposure_2hop 0.62 >= 0.5

goAML export

Validated against the FMU's goAML schema 5.0.2 before release. Upload it to the goAML portal under your own reporting-entity registration.

Download goAML XML

Triage

Filed by s.malik@vasp.example · 2-hop exposure confirmed · 1 Oct 2026, 14:36

0x2c8be1a4f7d09635c2e8b4a1f6d3c7e9b0a5d2f8c4e1b7a3d9f6c2e8b5a0d4f1HighDismissed
0xe19d4b7a2c6f8053a7d1e4b9c2f6a8d3e0b5c7f1a4d8e2b6c9f3a5d7e1b4c8f0CriticalDismissed
An illustrative walk through the RegulaComply console on a demonstration tenant. An officer opens the obligation catalogue of 38 provisions and selects VA Act 2026 s.47(1), whose condition reads a transfer's value and type. A transfer is scored HIGH by the heuristic classifier, which raises an alert. A Travel Rule assessment of the same transfer applies the threshold, builds an IVMS101 package, resolves the counterparty and finds the rule in force, then holds for review because no message channel exists yet. The alert's Form A7 draft is opened, its goAML XML downloaded, a filing proposed and approved by a second officer. The readiness report's Form A6 pre-fill counts the filed report and an assessment is recorded. The audit trail's signed checkpoint is proposed and approved, sealing the chain.

38

Obligations in force, in the catalogue

6

Months to build it

3,115

Automated backend tests

3rd

Pakistan's global crypto-adoption rank (Chainalysis 2025)

The problem

A licensing race with no compliance tooling built for it.

The Virtual Assets Act 2026 opened Pakistan’s VASP market. Its first entrants are already racing toward licensure, under a regime with no locally-calibrated compliance infrastructure.

The 2026 Regulations landed complete and in force: thresholds, IVMS101, screening, recordkeeping. Reading 178 pages is the easy part. Proving which version you complied with, on a given date is the part nobody has tooling for.

  1. 2018

    Pakistan placed on the FATF grey list

  2. 2022

    Exits the grey list after 34 action items

  3. 2025DEC

    First NOCs reported issued: Binance, HTX

  4. 2026MAR

    Virtual Assets Act opens the licensed market

  5. 2026AUG

    Full framework notified: S.R.O. 1419 and 1420

Getting this right isn’t a checkbox; it’s a condition of staying off the grey list again.

How it works

11 modules. One catalogue underneath.

Each module reads its rules from the same versioned catalogue: a revised threshold ships once and lands everywhere. Each one below runs against the real backend today; the one honest gap is PVARA’s sanctions list, which does not exist to screen against.

01 · Foundation

38 provisions live

Every obligation in force as a versioned rule: provision reference, severity, evidence and version history. 16 of 38 carry a machine-evaluable JSONLogic condition; the rest are proven by filed evidence, because governance and personnel duties are not observable in a transaction database. When PVARA revises one, the catalogue versions it and every module follows.

  • Seeded from the VA Act 2026 through to FATF Recommendation 16
  • Versioned: superseded, never overwritten
  • JSONLogic conditions, evaluated by one tested engine
  • Evidence requirements declared per rule, not per app
In the catalogue todayVA Act 2026 s.47(1)NOC Reg. 12

02 · Screening & scoring

Screening + scoring live

Wallet and transaction scoring against 5 independent sanctions sources (OFAC's SDN list, the UN Security Council Consolidated List, the EU consolidated list, the UK OFSI list and OpenSanctions) with a classifier that names the signals that fired instead of emitting a bare number.

  • Live sanctions screening: a hit overrides everything to CRITICAL
  • Two-hop indirect exposure computed from observed history
  • Every verdict ships with risk_class_reasons, never a bare number
Reads from the catalogueNOC Reg. 12NOC Reg. 11

03 · Licensing

Gap analysis live

Rule-by-rule gap analysis against PVARA's licensing checklist. Every obligation is marked satisfied, partial or missing, with the evidence still needed named for each one.

  • Satisfied / partial / missing per provision, prioritised by severity
  • Evidence uploads tracked against each obligation's requirements
  • Form A6 pre-filled from observed data; unknowns say so
Reads from the catalogueVA Act 2026 s.46; NOC Regulations 2025 Part 4NOC Regulations 2025 Form A6

04 · Transfers

Assessments live

Five stages for every in-scope transfer: threshold routing from the catalogue's s.47(1) rule, IVMS101 package, counterparty resolution, sunrise check, and a stored verdict for each.

  • Threshold routing reads s.47(1) straight from the catalogue
  • IVMS101 payloads hashed and stored as evidence
  • Sunrise gaps recorded; unresolved VASPs held for review
  • Advisory recommendations: your officer keeps the decision
Reads from the catalogueVA Act 2026 s.47(1)FATF Recommendation 16 (rev. June 2025)

05 · Reporting

Alert queue + Form A7 draft live

Alerts raise the moment a scored transaction crosses HIGH or CRITICAL, with a Form A7 Internal SAR draft built from stored facts, never invented, waiting on the reviewing officer.

  • Alert queue over HIGH and CRITICAL scores, raised automatically
  • Form A7 draft from the alert and the rule that fired
  • Review queue for what scores below the alert floor, cleared or escalated by a person
  • goAML XML filing, validated against the FMU's own 5.0.2 schema before release
Reads from the catalogueNOC Regulations 2025 Form A7NOC Reg. 11

06 · Customer due diligence

Customer records + screening live

The customer behind the transfer, held as a record rather than an address string: screened against the loaded sanctions lists the moment they arrive, with the natural persons who own or control them recorded alongside.

  • Onboarded by hand, or resolved automatically from a Travel Rule originator
  • Screened on arrival and on demand, with every screen kept
  • Beneficial owners recorded against an entity customer
  • A risk rating an officer assigns, and unrated says so rather than low
Reads from the catalogueS.R.O. 1419(I)/2026 Reg. 98VA Act 2026 s.47(1)

01 · The problem

The rules are written. That is the problem.

Two instruments, 178 pages, in force on the day they were notified. Chapter VIII alone runs from regulation 80 to 102: the compliance officer, the MLRO, risk reporting, customer due diligence, monitoring, sanctions, the Travel Rule, recordkeeping. None of it is a draft you can wait out.

02 · The approach

Regulation as data, not as code.

Every obligation is a versioned catalogue entry with a provision reference, an evidence contract and, wherever the duty is observable, a condition checked against your data. When PVARA changes a threshold, the catalogue changes. No code change. No redeploy.

03 · The posture

Regula recommends. Your compliance officer decides.

Advisory, not enforcing. Regula evaluates, flags and evidences; the block, hold or release decision stays with your compliance officer. That keeps Regula out of the “critical outsourcing” classification.

04 · The progress

Built in 6 months.

All 11 modules are live. One gap stays open and stated rather than quietly filled: PVARA publishes no sanctions feed to screen against.

3rdworldwide · Chainalysis’s 2025 Global Crypto Adoption Index

The difference

One parameter changes. Everything downstream follows.

Hard-coded compliance

  1. 1A threshold changes
  2. 2Find every hard-coded check across the codebase
  3. 3Update each one, hope none were missed
  4. 4Redeploy, and hope nothing else broke

Compliance-as-code

  1. 1A threshold changes
  2. 2Update one catalogue entry
  3. 3Every module reads the new version automatically
  4. 4No code change, no redeploy

The approach

Regulation as data, not as code.

Every obligation lives in the RegulaCatalogue as a versioned rule object, not logic buried in a transaction handler. Each entry keeps its own version history, so an auditor can reconstruct which rule applied on any date.

Reading the response

  • conditionEvery condition is JSONLogic, evaluated at runtime, not hand-coded in a handler.
  • version · superseded_atEvery rule is versioned: amendments supersede the old entry; nothing is deleted.
  • evidence_requiredEvery rule carries its own evidence contract: the fields an audit needs, spelled out.
GET /api/v1/catalogue/rules/{id}
200 OK
{
  "rule_id": "6f3b2c1a-8e4d-4a2b-9c7e-1f5a3d8b0e42",
  "provision_ref": "VA Act 2026 s.47(1)",
  "obligation_type": "THRESHOLD",
  "service_scope": ["EXCHANGE", "BROKER_DEALER", "CUSTODY"],
  "condition": {
    "and": [
      { ">=": [{ "var": "transfer_value_usd" }, 1000] },
      { "in": [{ "var": "transfer_type" }, ["withdrawal", "external_transfer"]] }
    ]
  },
  "evidence_required": ["ivms101_payload_hash", "counterparty_resolution_record"],
  "severity": "CRITICAL",
  "version": 1,
  "effective_date": "2026-07-01",
  "source_instrument": "VA Act 2026",
  "superseded_at": null
}

The exact shape of a real catalogue rule, not illustrative UI

Screening depth

A match you can close, not a queue you can’t.

Screen a common name against a real sanctions corpus and you get a list of near-matches. Screening that returns only a name and a score hands a compliance officer a queue with nothing in it to decide on, so every item is cleared by hand and the list gets longer than the day.

The lists have always published more than the name. Regula reads it, compares it against the customer record, and puts the comparison on the match: the second fact that closes the item, or the conflict that says this is a different person.

birth_dates
Dates of birth as the list published them, including the partial ones. A list that says only 1980 is less precise than a customer record, not different from it, and the comparison respects that.
nationalities · birth_places
Nationality and place of birth, carried through in the publisher's own words rather than mapped to codes we invented.
dob_conflict
Three answers, never two: the facts agree, the facts conflict, or no comparison was possible. The third is not the first, and collapsing them is how a reviewer dismisses a match nobody checked.

Across 5 sanctions sources: OFAC's SDN list, the UN Security Council Consolidated List, the EU consolidated list, the UK OFSI list and OpenSanctions.

The full picture

One engine. Every compliance workflow.

Rules, risk intelligence, licence readiness, Travel Rule operations and alerting all read the same versioned catalogue. Revise one obligation and every module downstream moves with it, with no release.

The foundation

RegulaCatalogue

Every regulatory obligation stored as a versioned, cited rule object that every other module reads from. Machine-evaluable where the duty is observable in data, evidence-gated where it is not.

Screening & scoring

Risk Intelligence

Wallet and transaction risk scoring with live sanctions screening against 5 sources (OFAC's SDN list, the UN Security Council Consolidated List, the EU consolidated list, the UK OFSI list and OpenSanctions) plus on-chain exposure analysis.

Licensing

Readiness

Rule-by-rule gap analysis against PVARA's licensing checklist, with Form A6 pre-filled from observed data.

Transfers

Travel Rule

Threshold routing, IVMS101 packaging, counterparty resolution, and the sunrise protocol for every in-scope transfer.

Reporting

Alerts

Raised automatically the moment a scored transaction crosses HIGH or CRITICAL, with a real Form A7 draft generated on demand.

Sanctions

Screening

Name screening against 5 sources (OFAC's SDN list, the UN Security Council Consolidated List, the EU consolidated list, the UK OFSI list and OpenSanctions), and wallet screening against every sanctioned address those sources publish, with every match reported as something to review rather than a verdict.

Roles & approvals

Governance

A capability ladder from auditor to admin, and a second, different person required to file a report or seal the audit chain, a control an administrator cannot bypass.

Trust & assurance

RegulaProof

An exhaustive proof of what this system can and cannot raise an alert on, with AI-drafted fixes checked against that same proof before they ship.

Why now

The market is large, and largely unaddressed.

Chainalysis ranks Pakistan 3rd worldwide for crypto adoption. Regulators here estimate 30–40 million users and over USD 300 billion traded a year. Those are regulatory estimates, not audited totals.

The licensing portal opened on 21 August 2026 and the framework commenced the same day. VASPs here are building compliance from a standing start, against obligations that are already in force.

3rd

Pakistan’s rank on Chainalysis’s 2025 Global Crypto Adoption Index

30–40M

estimated users

$300B+

estimated annual volume

Regulator estimates, not independently audited.

The road ahead

REGULA [ROADMAP]2026

One catalogue, 11 modules.

Built in 6 months. Every planned module is live, with a hash-chained audit trail and two-person approval on filings. One gap stays open and stated: PVARA publishes no sanctions feed to screen against.

See how it works →

One workspace

The catalogue, the gaps, the queue, and the receipt.

Four of the 11 modules, in the order a compliance officer actually meets them: what the law requires, where you stand against it, what needs working today, and the tamper-evident record of every answer given along the way.

The console

Every obligation in force, evaluated against your own data, and a record of every answer.

Regula

Catalogue

Every obligation in force, versioned and cited, with your position on each. Evaluated automatically where the duty shows up in your data, evidence-gated where it does not.

In force today
38Versioned rule objects across 6 instruments
Reg. 100(2)Critical

Originator and beneficiary information on qualifying Travel Rule transfers.

Questions

Answered directly, not dodged.

All 11 modules are live, built in 6 months. Risk intelligence, readiness, the Travel Rule engine, alerts and sanctions screening all run against the real backend, alongside a hash-chained audit trail and two-person approval on filings.

PVARA notified the Pakistan Virtual Asset Services Regulations, 2026 (S.R.O. 1419(I)/2026) and the Activity Specific Regulations (S.R.O. 1420(I)/2026), both in force on notification, and opened the licensing portal. Regula had carried the Travel Rule threshold as a placeholder pending PVARA's real figure; Reg. 100(2) set it at the PKR equivalent of USD 1,000, which is the number already in the catalogue. Updating the citation was a catalogue edit, not a redeploy.

No. Regula is an independent Final Year Project built against PVARA's public regulatory framework, not commissioned, endorsed, or reviewed by the regulator.

Acting directly would risk classifying Regula as an AML-critical outsourced function under NOC Regulation 14. Advisory keeps the decision with the compliance officer, and Regula out of the transaction path.

They already have, all of them. One thing stays gated on an outside party: PVARA publishes no sanctions list to screen against. The goAML export was the other, and is now built against the FMU's own 5.0.2 schema. Every report is validated against it before release, though no filing has gone through the live portal yet, which needs a licensed entity's own FMU registration.

Yes. The console is live and linked throughout this page. The catalogue, risk intelligence, readiness, Travel Rule and alerts all run against the real backend.

Built and shipped. Now looking for the people who have to file.

We’re onboarding a small number of design partners: VASPs, compliance teams and RegTech practitioners. Every module is live, so there is a working console to react to rather than a roadmap to take on trust.