Regulatory Playbook: Pakistan¶
| Field | Value |
|---|---|
| Market | Pakistan (PK) |
| Regulator | State Bank of Pakistan (SBP) |
| Status | Draft — requires local compliance review |
| Owner | Country Manager PK / CDO |
| Created | 2026-04-05 |
| Review | Semi-annually |
| Reference | Cross-Border Compliance Framework |
Purpose¶
This is the operational playbook for Simpaisa's Pakistan operations. The Cross-Border Compliance Framework defines what the law requires. This playbook defines what we actually do: who is responsible, what processes run, what reporting is due, and what happens when something goes wrong.
Pakistan is Simpaisa's largest market by transaction volume. Regulatory non-compliance here has the highest business impact.
Regulatory Landscape¶
| Dimension | Requirement | Source |
|---|---|---|
| Primary licence | PSO/PSP Licence under SBP Payment Systems Department | PS&EFT Act 2007 |
| AML/KYC | Full CDD for merchants, simplified CDD for low-value consumers | AML Act 2010, SBP AML/CFT Regulations |
| Data localisation | Transaction data must reside in Pakistan. Processing may occur offshore with SBP approval. | SBP Circular, PS&EFT Act |
| Encryption | Data at rest and in transit must be encrypted | SBP Technology Risk Management Framework 2025 |
| PII handling | Personal data requires consent for collection. Cross-border transfer restricted. | Prevention of Electronic Crimes Act (PECA) 2016 |
| Transaction limits | Per SBP tiers: Basic (PKR 50K/month), Enhanced (PKR 500K/month), Full (PKR 1M+/month) | EMI Regulations 2023 |
| Reporting | STR (Suspicious Transaction Reports) to FMU. Monthly transaction reporting to SBP. | AML Act 2010 |
| Audit | Annual external audit of payment systems. SBP may conduct ad-hoc inspections. | PSO/PSP Rules 2014 |
| Incident reporting | Security incidents affecting payment systems reported to SBP within 24 hours. | SBP Technology Risk Management Framework |
Current Compliance Status¶
| Requirement | Status | Gap | Risk |
|---|---|---|---|
| PSO/PSP Licence | Active | None | — |
| AML/KYC processes | Partially compliant | CDD processes undocumented. KYC workflow exists but not aligned to latest AML Act amendments. | HIGH |
| Data localisation | Partially compliant | Transaction data on AWS RDS (region unconfirmed). Cross-border data flow documentation missing. | HIGH |
| Encryption at rest | Non-compliant | PII stored in plain text (SECURITY-ARCHITECTURE.md, Finding R2). | CRITICAL |
| Encryption in transit | Compliant | TLS 1.2+ for all external communications. | — |
| Transaction monitoring | Partially compliant | Rule-based monitoring exists. No automated STR generation. | MEDIUM |
| Incident reporting to SBP | Unknown | No documented process for SBP notification within 24 hours. | HIGH |
| Annual audit | Unknown | Audit history not documented in Architecture repo. | MEDIUM |
| Request signing | Non-compliant | Pay-Ins has no request signing (SECURITY-ARCHITECTURE.md, Finding 1). | CRITICAL |
| Rate limiting | Non-compliant | No documented rate limiting (SECURITY-ARCHITECTURE.md, Finding 5). | HIGH |
Operational Processes¶
1. Merchant Onboarding (Pakistan)¶
MERCHANT ONBOARDING FLOW (PK)
─────────────────────────────────────────────────────
Application CDD/KYC Technical Go-Live
──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ Merchant │──▶│ Identity │──▶│ API Key │──▶│ Live │
│ applies │ │ verified │ │ Sandbox │ │ traffic │
│ │ │ Docs │ │ Testing │ │ │
└──────────┘ │ checked │ │ Webhook │ └──────────┘
└──────────┘ │ config │
└──────────┘
Owner: Commercial (PK) Compliance (PK) Engineering Operations (PK)
SLA: 2 business days 5 business days 3 business days 1 business day
Total: 11 business days target
Required documents for CDD (Pakistan): - National Tax Number (NTN) certificate - SECP/registrar company registration - CNIC (Computerised National Identity Card) of directors - Bank account verification letter - Business address verification - Beneficial ownership declaration (>25% shareholders)
Enhanced Due Diligence triggers: - Monthly volume > PKR 10M - High-risk merchant category (gambling, crypto, precious metals) - PEP (Politically Exposed Person) as beneficial owner - Adverse media screening hit
2. Transaction Monitoring¶
| Check | Frequency | Threshold | Action |
|---|---|---|---|
| Velocity check | Real-time | > 100 transactions/minute per merchant | Alert + temporary hold |
| Amount anomaly | Real-time | > 3x average daily volume | Alert + manual review |
| New merchant spike | Daily | > 10x first-day average within first 30 days | Manual review |
| Dormant reactivation | On event | No transactions > 90 days, then sudden high volume | Manual review + re-KYC |
| STR screening | Daily batch | Rule-based pattern matching against SBP typologies | STR filed with FMU within 3 business days if confirmed |
STR filing process: 1. Alert generated by monitoring system or flagged by operations staff. 2. Compliance Officer (PK) reviews within 24 hours. 3. If suspicious: STR prepared using FMU goAML portal format. 4. STR filed with Financial Monitoring Unit (FMU) within 3 business days. 5. Internal record retained for 5 years minimum. 6. No tipping-off: merchant not informed of STR filing.
3. Incident Response (Pakistan-Specific)¶
In addition to the global Incident Response Playbook (Standards/INCIDENT-RESPONSE-PLAYBOOK.md):
| Requirement | SLA | Owner |
|---|---|---|
| SBP notification for security incidents affecting payment systems | Within 24 hours of detection | Country Manager PK + CDO |
| SBP notification for data breaches involving customer PII | Within 72 hours of confirmation | Country Manager PK + CDO |
| SBP ad-hoc inspection response | Immediate cooperation | Country Manager PK |
SBP notification template:
TO: Payment Systems Department, SBP
FROM: Simpaisa (Pvt) Ltd — PSO/PSP Licence No: [XXXX]
DATE: [YYYY-MM-DD]
SUBJECT: Security Incident Notification — [Brief Description]
1. Nature of incident: [description]
2. Date/time detected: [timestamp]
3. Systems affected: [list]
4. Customer impact: [number affected, data exposed if any]
5. Containment actions taken: [list]
6. Root cause (preliminary): [if known]
7. Estimated resolution: [timeline]
8. Contact for follow-up: [name, phone, email]
4. Data Localisation¶
Current architecture (non-compliant): - Single AWS RDS instance. Region not documented as Pakistan-local. - Transaction data may traverse UAE or other regions.
Target architecture (per Data Architecture, DA-06): - Primary transaction data resides in-country (AWS ap-south-1 or local DC). - Only aggregated/anonymised data flows to UAE for group reporting. - Cross-border transfer requires SBP approval or anonymisation.
Action items: 1. Confirm current RDS region. If not Pakistan-local, initiate migration plan. 2. Document all cross-border data flows with data classification. 3. Implement column-level encryption for PII before any data leaves Pakistan.
5. Reporting Calendar¶
| Report | Frequency | Due Date | Recipient | Owner |
|---|---|---|---|---|
| Monthly transaction summary | Monthly | 10th of following month | SBP Payment Systems Dept | Operations PK |
| Suspicious Transaction Reports | As needed | Within 3 business days of confirmation | FMU via goAML | Compliance PK |
| Annual compliance report | Annually | Q1 of following year | SBP | Compliance PK + CDO |
| External audit report | Annually | Per SBP-specified timeline | SBP | Finance + CDO |
| Technology risk assessment | Annually | Per SBP framework timeline | SBP | CDO |
| AML/KYC programme review | Annually | Per AML Act requirements | Internal + SBP on request | Compliance PK |
6. Key Contacts¶
| Role | Responsibility | Name |
|---|---|---|
| Country Manager PK | Overall Pakistan operations, SBP relationship | TBD |
| Compliance Officer PK | AML/KYC, STR filing, regulatory reporting | TBD |
| Operations Lead PK | Transaction monitoring, merchant support | TBD |
| CDO | Technology, security, data architecture decisions | Daniel O'Reilly |
Remediation Priorities¶
Based on the compliance status assessment above:
| Priority | Item | Risk | Owner | Target |
|---|---|---|---|---|
| 1 | PII encryption at rest | CRITICAL | CDO | Q2 2026 |
| 2 | Pay-In request signing | CRITICAL | CDO | Q2 2026 |
| 3 | Data localisation documentation | HIGH | CDO + Country Mgr PK | Q2 2026 |
| 4 | SBP incident notification process | HIGH | Country Mgr PK | Q2 2026 |
| 5 | Rate limiting implementation | HIGH | CDO | Q3 2026 |
| 6 | CDD process documentation | HIGH | Compliance PK | Q2 2026 |
| 7 | Automated STR generation | MEDIUM | CDO + Compliance PK | Q3 2026 |
Connection to Strategy¶
This playbook directly supports: - SG1 (Operational Excellence): documented processes, incident response SLAs - SG4 (Market Expansion): Pakistan as the model for how a regulated market should operate. Other markets (BD, NP, IQ) will follow this template. - Foundational Support #5 (Standardised global network): Pakistan as the first fully documented market
Template for Other Markets¶
This playbook serves as the template for BD, NP, and IQ playbooks. Each market playbook follows the same structure: 1. Regulatory landscape 2. Current compliance status 3. Operational processes (onboarding, monitoring, incident response, data localisation) 4. Reporting calendar 5. Key contacts 6. Remediation priorities
Market-specific differences are captured in each playbook. The structure is identical.