Simpaisa Group Operating Model¶

Sections 8, 9, and 10: Core Business Processes¶

Section 8: Product Operating Models¶

8.1 Product Portfolio Overview and Country Matrix¶

The diagram below summarises the deployment status of each product line across Simpaisa's key markets. Active products are live and generating revenue; In Development products are progressing through regulatory, technical, or commercial milestones; Planned products are on the 12-month horizon.

flowchart LR
    subgraph PKG["Pakistan"]
        direction TB
        PK_PI["Pay-Ins - Active"]
        PK_PO["Pay-Outs - Active"]
        PK_IR["Remittances - Active"]
        PK_CX["Crypto Off-Ramp - Active"]
        PK_WL["White-Label Wallets - Active"]
        PK_MT["Mobile Top-Ups - Active"]
        PK_SB["Subscriptions - Active"]
        PK_OT["OTC Cash - Active"]
        PK_DC["Domestic Cards - Active"]
        PK_IC["Intl Cards - Active"]
    end
    subgraph BDG["Bangladesh"]
        direction TB
        BD_PI["Pay-Ins - Active"]
        BD_PO["Pay-Outs - Active"]
        BD_IR["Remittances - Active"]
        BD_WL["White-Label - Dev"]
        BD_MT["Mobile Top-Ups - Active"]
        BD_SB["Subscriptions - Active"]
        BD_OT["OTC Cash - Active"]
        BD_DC["Domestic Cards - Active"]
        BD_IC["Intl Cards - Active"]
    end
    subgraph NPG["Nepal"]
        direction TB
        NP_PI["Pay-Ins - Active"]
        NP_PO["Pay-Outs - Active"]
        NP_IR["Remittances - Active"]
        NP_WL["White-Label - Planned"]
        NP_MT["Mobile Top-Ups - Active"]
    end
    subgraph UAE["UAE / MENA"]
        direction TB
        UAE_PI["Pay-Ins - Planned"]
        UAE_PO["Pay-Outs - Planned"]
        UAE_IR["Remittances - Dev"]
        UAE_WL["White-Label - Planned"]
        UAE_MT["Mobile Top-Ups - Planned"]
    end
    subgraph IQG["Iraq"]
        direction TB
        IQ_PI["Pay-Ins - Dev"]
        IQ_PO["Pay-Outs - Dev"]
        IQ_IC["Intl Cards - Dev"]
    end
    subgraph SAG["Saudi Arabia"]
        direction TB
        SA_PI["Pay-Ins - Planned"]
        SA_PO["Pay-Outs - Planned"]
        SA_IR["Remittances - Dev"]
        SA_WL["White-Label - Planned"]
    end

    classDef active fill:#22c55e,color:#fff,stroke:none
    classDef dev fill:#f59e0b,color:#fff,stroke:none
    classDef planned fill:#94a3b8,color:#fff,stroke:none

    class PK_PI,PK_PO,PK_IR,PK_CX,PK_WL,PK_MT,PK_SB,PK_OT,PK_DC,PK_IC active
    class BD_PI,BD_PO,BD_IR,BD_MT,BD_SB,BD_OT,BD_DC,BD_IC active
    class NP_PI,NP_PO,NP_IR,NP_MT active
    class BD_WL,UAE_IR,IQ_PI,IQ_PO,IQ_IC,SA_IR dev
    class NP_WL,UAE_PI,UAE_PO,UAE_WL,UAE_MT,SA_PI,SA_PO,SA_WL planned

The table below maps Simpaisa's active product lines against current operating jurisdictions. "Active" denotes a live, revenue-generating product with licensed infrastructure in place. "In Development" denotes a product line where regulatory approvals, technical integrations, or commercial agreements are underway but not yet fully operational. "Planned" denotes products scheduled for deployment within the 12-month planning horizon.

Product	Pakistan	Bangladesh	Nepal	Canada (Diaspora)	UAE / MENA	Iraq	Saudi Arabia	Central Asia
Pay-Ins (Collections)	Active	Active	Active	-	Planned	In Development	Planned	Planned
Pay-Outs (Disbursements)	Active	Active	Active	-	Planned	In Development	Planned	Planned
Inbound Remittances	Active	Active	Active	Active	In Development	Planned	In Development	Planned
Crypto Off-Ramping (USDT→PKR)	Active	-	-	-	-	-	-	-
White-Label Wallets	Active	In Development	Planned	-	Planned	-	Planned	Planned
Mobile Top-Ups	Active	Active	Active	-	Planned	Planned	Planned	Planned
Subscription / Recurring Billing	Active	Active	-	-	Planned	-	Planned	-
OTC Cash Collection	Active	Active	-	-	-	-	-	-
Domestic Card Processing	Active	Active	-	-	Planned	-	Planned	-
International Card Processing	Active	Active	-	-	Planned	In Development	Planned	Planned

Notes: - Canada operations are limited to outbound remittance origination under the Canadian MSB/FMSB licence, not domestic payments. - Bangladesh Active status for Pay-Ins and Pay-Outs reflects operations conducted through the aamarPay PSO entity. - Nepal Active status reflects PSP partnerships (Khalti, e-Sewa, IME Pay, Paywell) rather than a locally licensed entity; regulatory application is in progress. - UAE operations are subject to DFSA Cat 3D and EMI licence applications currently under review.

8.2 Pay-Ins (Collections) Operating Model¶

8.2.1 Product Description and Value Proposition¶

Pay-Ins is Simpaisa's core merchant-facing collections product, enabling global digital merchants to accept payments from consumers in Pakistan, Bangladesh, and Nepal using locally preferred payment instruments - mobile wallets, direct carrier billing, over-the-counter (OTC) cash, bank transfers, and domestic and international cards - through a single API integration. The product is designed to solve the fundamental problem facing global technology companies and digital content platforms: the structural inability to convert high-intent consumers in underbanked South Asian markets into paying customers, owing to the absence of internationally accepted payment credentials and the fragmentation of local payment rails.

The value proposition rests on three pillars. First, coverage depth: Simpaisa offers access to over 2,500 OTC touch-points in Pakistan, all major mobile wallet operators in each country (Easypaisa, JazzCash, HBL Konnect, and Alfa in Pakistan; bKash, Nagad, Rocket, Upay, Tap Pay, OK Wallet, M-Cash, myCash, Cellfin, Dmoney, and iPay in Bangladesh; Khalti, e-Sewa, IME Pay, and Paywell in Nepal), direct carrier billing across all four Pakistani mobile network operators (Mobilink, Telenor, Ufone, Zong), and IBFT rails including 1LINK/1Bill Push and Pull. Second, simplicity: a merchant integrates once via a well-documented REST API, and Simpaisa manages all downstream complexity - tokenisation, session management, operator-specific flows, fallback routing, and localised user experience. Third, speed to market: a new merchant can complete technical integration and go live within a commercially agreed onboarding window, with no requirement to establish local entities, obtain local licences, or negotiate individually with each payment operator.

Simpaisa charges merchants a Merchant Discount Rate (MDR) calculated as a percentage of gross transaction value, applied at the point of settlement. The MDR is differentiated by payment method, country, and volume tier, reflecting the varying underlying cost structures of different payment rails and the competitive dynamics of the merchant vertical. Merchants receive net settlement after MDR deduction, denominated in a hard currency (USD or EUR) or in a locally agreed settlement currency, according to the terms of the Master Payment Services Agreement (MPSA) and applicable Country Addendum.

8.2.2 End-to-End Process Flow¶

The diagram below traces the full Pay-In lifecycle across four parties: the Consumer initiating payment, the Merchant calling the Simpaisa API, Simpaisa's platform managing session, routing, reconciliation, and settlement, and the Operator (wallet, DCB, or acquiring bank) executing the underlying transaction.

flowchart TD
    subgraph Consumer["Consumer"]
        C1["Selects product\nat checkout"]
        C4["Authenticates\nOTP / biometric\nSMS PIN / 3DS"]
        C12["Confirms receipt\nof settlement"]
    end

    subgraph Merchant["Merchant"]
        M1["Calls Simpaisa\nPayment API"]
        M3["Receives hosted\npage / widget URL"]
        M8["Receives signed\nwebhook notification"]
        M12["Confirms settlement\nreceipt"]
    end

    subgraph Simpaisa["Simpaisa"]
        S2["Creates session\nStatus: INITIATED"]
        S3["Returns hosted page\nor widget"]
        S5["Transmits payment\ninstruction"]
        S7["Updates status\nCOMPLETED or FAILED"]
        S8["Fires signed webhook\nto merchant callback"]
        S9["Real-time dashboard\nupdate"]
        S10["Daily batch\nreconciliation\nMDR applied"]
        S11["Issues settlement\ninstruction\nT+1 to T+3\nSWIFT or local bank"]
    end

    subgraph Operator["Operator"]
        O6["Processes instruction\nWallet / DCB: 5-15s\nOTC: up to 30 min"]
    end

    C1 --> M1
    M1 --> S2
    S2 --> S3
    S3 --> M3
    M3 --> C4
    C4 --> S5
    S5 --> O6
    O6 --> S7
    S7 --> S8
    S8 --> M8
    S7 --> S9
    S9 --> S10
    S10 --> S11
    S11 --> M12
    M12 --> C12

Checkout initiation. The consumer selects a product on the merchant's platform and proceeds to payment checkout. The merchant's platform invokes the Simpaisa Payment API via a POST request, passing transaction parameters: merchant ID, amount, currency, consumer reference, callback URL, and optional metadata such as product category and session token.
Session creation and routing. Simpaisa's payment gateway creates a transaction session, generates a unique transaction reference, and applies routing logic to determine the appropriate downstream payment channel based on the consumer's selected payment method and the merchant's enabled methods. The session is assigned an initial status of INITIATED.
Payment method selection and consumer redirect. The gateway returns a hosted payment page URL or embeddable widget to the merchant. The consumer is presented with available payment options localised to their country - wallet, OTC, DCB, bank transfer, or card - and selects their preferred method.
Consumer authentication. Depending on the selected method, the consumer authenticates via their wallet application (OTP or biometric), enters a DCB MSISDN and confirms via SMS PIN, presents an OTC reference code at a retail agent, initiates an IBFT from their bank, or completes 3D Secure for card payments. Authentication credential handling is managed entirely within Simpaisa's PCI-DSS-compliant or operator-delegated environment.
Payment instruction transmission. Simpaisa transmits the payment instruction to the relevant operator API or acquiring bank in real time. For mobile wallets, this constitutes a debit request against the consumer's wallet balance. For DCB, a billing event is submitted to the mobile network operator's billing gateway. For OTC, a payment voucher is generated and the consumer is directed to present it at any affiliated retail outlet.
Operator processing and confirmation. The downstream operator processes the instruction and returns a success or failure response. For wallet and DCB channels, this typically occurs within 5–15 seconds of consumer action. For OTC, confirmation is received upon the agent scanning or entering the voucher code, typically within 30 minutes of consumer presentation.
Transaction status update. On receipt of operator confirmation, Simpaisa's gateway updates the transaction status to COMPLETED or, in the event of failure, to FAILED. Where a failure occurs and fallback routing has been enabled for the merchant, the gateway initiates a fallback attempt via the next eligible payment channel without requiring further consumer action.
Webhook notification to merchant. Simpaisa dispatches a signed webhook notification to the merchant's designated callback URL, carrying the final transaction status, unique transaction reference, operator reference, amount, and timestamp. The merchant's platform is expected to reconcile this notification against the original session and fulfil the consumer's order upon receipt of a COMPLETED status.
Real-time dashboard update. The transaction appears in the merchant-facing Simpaisa dashboard in near real time, with full status detail, operator response code, and consumer reference visible to authorised merchant users.
Daily batch reconciliation. At the close of each settlement day, Simpaisa's reconciliation engine aggregates all completed transactions for each merchant by payment channel, applies the relevant MDR, and produces a net settlement figure. A reconciliation report is generated and made available to the merchant via the dashboard and secure file transfer.
Settlement instruction. Simpaisa's treasury function raises a settlement instruction for each merchant according to the agreed settlement cycle (T+1 to T+3 depending on the channel and country). Funds are transferred to the merchant's designated bank account in the agreed settlement currency via SWIFT or local bank transfer, accompanied by a settlement advice note.
Post-settlement confirmation. Merchant confirms receipt of funds. Any discrepancies between the settlement advice and funds received are raised as settlement breaks and managed through the reconciliation break management process described in Section 10.2.

8.2.3 Payment Methods by Country¶

Pakistan¶

Payment Method	Category	Operator / Rail	Coverage
Easypaisa	Mobile Wallet	Telenor Microfinance Bank	Nationwide
JazzCash	Mobile Wallet	Mobilink Microfinance Bank	Nationwide
HBL Konnect	Mobile Wallet	HBL	Nationwide
Alfa	Mobile Wallet	Askari Bank	Nationwide
Mobilink (Jazz) DCB	Direct Carrier Billing	Mobilink / PMCL	Nationwide
Telenor DCB	Direct Carrier Billing	Telenor Pakistan	Nationwide
Ufone DCB	Direct Carrier Billing	PTCL / Ufone	Nationwide
Zong DCB	Direct Carrier Billing	China Mobile Pakistan	Nationwide
Push IBFT (1LINK/1Bill)	Bank Transfer	1LINK interbank network	All member banks
Pull IBFT	Bank Transfer	1LINK interbank network	All member banks
OTC Retail	Cash / Voucher	2,500+ retail agents	Nationwide
Domestic Card	Card	Visa, Mastercard (local issuing)	Nationwide
International Card	Card	Visa, Mastercard, UnionPay	Cross-border

Bangladesh¶

Payment Method	Category	Operator / Rail	Coverage
bKash	Mobile Wallet	BRAC Bank subsidiary	Nationwide
Nagad	Mobile Wallet	Bangladesh Post Office	Nationwide
Rocket	Mobile Wallet	Dutch-Bangla Bank	Nationwide
Upay	Mobile Wallet	UCB	Nationwide
Tap Pay	Mobile Wallet	Tap Pay Bangladesh	Urban centres
OK Wallet	Mobile Wallet	One Bank	Nationwide
M-Cash	Mobile Wallet	Islami Bank	Nationwide
myCash	Mobile Wallet	Mercantile Bank	Nationwide
Cellfin	Mobile Wallet	City Bank	Urban centres
Dmoney	Mobile Wallet	Dmoney Bangladesh	Nationwide
iPay	Mobile Wallet	iPay Systems	Urban centres
OTC Agent	Cash / Agent	Licensed agent network	Nationwide
Visa / Mastercard / Amex	Card	International card schemes	Nationwide
NPSB Transfer	Bank Transfer	Bangladesh Bank NPSB	All member banks
BEFTN Transfer	Bank Transfer	Bangladesh Bank BEFTN	All member banks
EMI (29+ banks)	Instalment	SCB, City, Eastern, BRAC, others	Nationwide

Nepal¶

Payment Method	Category	Operator / Rail	Coverage
Khalti	PSP / Wallet	Khalti Digital Wallet	Nationwide
e-Sewa	PSP / Wallet	eSewa Money Transfer	Nationwide
IME Pay	PSP / Wallet	IME Digital Solution	Nationwide
Paywell	PSP / Wallet	Paywell Nepal	Urban centres
Bank Transfer	Bank Transfer	NRB-regulated banks	Nationwide

8.2.4 Integration Architecture Overview¶

Simpaisa's integration architecture is built on an API-first, single-integration principle. A merchant connects once to Simpaisa's unified payment gateway and gains immediate access to all active payment methods across all countries for which their merchant agreement includes a Country Addendum.

API Layer. The primary integration point is Simpaisa's REST API, documented via OpenAPI specification and accessible via a dedicated developer portal. The API supports JSON request and response bodies over HTTPS with TLS 1.2 or higher. Authentication is via HMAC-SHA256 signed requests using merchant-specific API key pairs. Each API key pair is environment-scoped: sandbox keys connect to the Simpaisa staging environment, which mirrors production channel routing without triggering real operator transactions.

Hosted Payment Page and Embeddable Widget. Merchants that do not wish to build a fully custom payment UI can use Simpaisa's hosted payment page (a redirect-based model) or the embeddable JavaScript widget (an iframe-based model). Both options surface the full range of country-appropriate payment methods in the consumer's browser or application and handle all operator-specific authentication flows, including OTP challenges and DCB MSISDN entry, without requiring any merchant-side implementation.

Tokenisation. For wallet-based payment methods, Simpaisa implements tokenisation to enable returning consumers to complete payments without re-entering wallet credentials. The consumer's wallet identifier is stored as an encrypted token on Simpaisa's platform, scoped to the merchant. Recurring billing and subscription flows leverage this tokenisation layer. Raw wallet credentials are never transmitted to or stored by the merchant.

Webhooks. All transaction state changes generate outbound webhook events to the merchant's configured callback URL. Webhooks are signed with the merchant's signing secret using HMAC-SHA256, enabling the merchant to verify event authenticity. Simpaisa's webhook delivery system implements exponential backoff retry logic over a 24-hour window in the event of non-delivery.

Batch File Upload. For merchants requiring bulk disbursement or reconciliation file exchange, Simpaisa supports SFTP-based batch file upload in CSV or fixed-width formats, complementing the real-time API for high-volume, low-latency use cases.

Failure and Fallback Routing. The gateway incorporates a load balancer and fallback engine. Where a payment instruction to a primary downstream operator fails - owing to operator downtime, timeout, or capacity constraints - the engine automatically routes the transaction to the next eligible operator for the same payment method category, subject to merchant configuration and applicable regulatory constraints. Fallback events are logged and reported separately in the merchant dashboard to enable monitoring of channel health.

8.2.5 Pricing Model¶

Simpaisa's Pay-Ins pricing is based on a Merchant Discount Rate (MDR), expressed as a percentage of gross transaction value (GTV), deducted from each transaction at settlement.

MDR Structure. The applicable MDR for each transaction is determined by three variables: (i) the payment method used; (ii) the country in which the transaction is processed; and (iii) the merchant's contracted volume tier. The MDR reflects Simpaisa's cost of accessing the underlying payment rail (operator share, interchange, OTC agent commission) plus Simpaisa's margin.

Volume Tiers. MDR rates are structured across three tiers, reviewed annually or upon request:

Volume Tier	Monthly GTV Threshold	Indicative MDR Range
Standard	Up to USD 100,000	2.5% – 5.0% (method-dependent)
Growth	USD 100,001 – USD 1,000,000	2.0% – 4.0% (method-dependent)
Strategic	Above USD 1,000,000	Negotiated, typically 1.5% – 3.5%

Payment Method Differentiation. DCB carries a higher MDR than mobile wallets, reflecting the higher operator revenue share payable to mobile network operators. OTC carries a higher MDR than digital channels, reflecting agent commission costs. IBFT carries the lowest MDR of digital methods, reflecting lower underlying infrastructure costs. Card MDR is differentiated by card type (domestic vs. international) and scheme (Visa vs. Mastercard vs. Amex).

Currency and FX. Where a consumer pays in local currency (PKR, BDT, NPR) and the merchant settles in a hard currency (USD, EUR), Simpaisa applies an FX conversion at the prevailing mid-market rate plus a spread agreed in the MPSA. The FX spread is typically in the range of 0.5%–1.5% and is separate from the MDR.

Invoicing. Simpaisa produces a daily settlement statement and a monthly consolidated tax invoice for each merchant, detailing GTV by payment method and country, MDR deducted, FX conversion, and net settlement amount.

8.2.6 SLAs and Performance Metrics¶

Metric	Target	Measurement Method
API uptime	99.9% monthly	External synthetic monitoring, monthly calculation
Payment gateway response time (API)	< 500ms (p95)	Server-side timestamp logging
Wallet transaction success rate	≥ 95%	Completed / (Completed + Failed) excluding consumer-abandoned
DCB transaction success rate	≥ 90%	Completed / (Completed + Failed) excluding consumer-abandoned
OTC voucher issuance latency	< 3 seconds	Gateway timestamp to voucher generation
Card authorisation success rate	≥ 92%	Authorised / Total submitted (excluding declined due to insufficient funds)
Webhook delivery (first attempt)	≥ 98% within 30 seconds	Webhook delivery logs
Settlement timeliness	100% within agreed cycle	Treasury settlement log vs. MPSA terms
Reconciliation report availability	By 08:00 local time, T+1	Report generation timestamp
Fallback routing activation time	< 10 seconds post primary failure	Gateway event log
Chargeback rate (cards)	< 0.5% of card GTV	Monthly card scheme reporting
Dispute resolution SLA	95% within 10 business days	Case management system

8.2.7 Reconciliation and Settlement Process¶

Reconciliation Overview. Simpaisa operates a three-layer reconciliation process to ensure the integrity of merchant settlements:

Layer 1 - Internal ledger vs. operator confirmation files. Each day, Simpaisa's reconciliation engine compares its internal transaction ledger against operator-generated confirmation files received via SFTP or API. Any discrepancies - missing confirmations, amount mismatches, duplicate entries - are flagged as breaks and routed to the Payment Operations team for investigation.
Layer 2 - Operator confirmation files vs. operator financial statements. On a T+1 or T+2 basis (depending on the operator), Simpaisa matches operator confirmation files against the financial statements or settlement advices issued by each operator. Discrepancies at this layer typically indicate timing differences or operator-side processing errors.
Layer 3 - Internal ledger vs. merchant settlement. The net settlement amount calculated by the reconciliation engine is validated against the funds actually transferred to the merchant and receipted in the merchant's nominated bank account.

Settlement Cycles by Country and Method:

Country	Payment Method	Settlement Cycle	Settlement Currency
Pakistan	Mobile Wallets	T+1	USD (or PKR by agreement)
Pakistan	DCB	T+7 (MNO settlement lag)	USD
Pakistan	IBFT	T+1	USD
Pakistan	OTC	T+2	USD
Pakistan	Cards	T+2	USD
Bangladesh	Mobile Wallets	T+1	USD
Bangladesh	Cards	T+2	USD
Bangladesh	Bank Transfer	T+2	USD
Nepal	Wallets / PSPs	T+2	USD

Break Management. Reconciliation breaks are categorised by type and severity. Breaks above a defined threshold value are escalated to the Head of Payment Operations within four business hours. All breaks are assigned to an owner and tracked to resolution in the reconciliation management system. Root cause analysis is completed for all material breaks, and findings are used to improve upstream data quality and operator integration robustness.

8.2.8 Tier A Merchant Portfolio¶

Merchant	Industry	Primary Products Used	Active Countries
Google	Technology / App Stores	Wallets, DCB, Cards, IBFT	Pakistan, Bangladesh
Samsung	Consumer Electronics / App Stores	Wallets, Cards, IBFT	Pakistan, Bangladesh
Temu	E-commerce	Wallets, Cards, IBFT	Pakistan, Bangladesh
Tencent	Gaming / Social	Wallets, DCB, Cards	Pakistan, Bangladesh
Garena	Gaming	Wallets, DCB, Cards	Pakistan, Bangladesh
dLocal	Global Payment Aggregator	API aggregation, Cards, Wallets	Pakistan, Bangladesh
Coda	Gaming / Digital Content	Wallets, DCB, OTC	Pakistan, Bangladesh
Xsolla	Gaming / Developer Payments	Wallets, Cards, OTC	Pakistan, Bangladesh
InDrive	Ride-Hailing	Wallets, Cards	Pakistan, Bangladesh
Muzz	Islamic Finance / Social	Wallets, IBFT	Pakistan
Razer Gold	Gaming	Wallets, DCB, OTC	Pakistan, Bangladesh
PMMAX	Performance Marketing	Wallets, Cards	Pakistan, Bangladesh
Thunes	Global Payment Network	API aggregation, Wallets	Pakistan, Bangladesh, Nepal

8.3 Pay-Outs (Disbursements) Operating Model¶

8.3.1 Product Description and Value Proposition¶

Simpaisa's Pay-Outs product enables global merchants, platforms, and financial institutions to disburse funds to consumers and counterparties in Pakistan, Bangladesh, and Nepal at scale. The product serves a diverse set of disbursement use cases: merchant refunds, ride-hailing driver pay-outs, gig economy earnings, insurance claim payments, digital lending disbursements, employee salary disbursements, and partner-to-partner settlement flows. The unifying requirement across these use cases is the ability to push value reliably and quickly to recipients who may hold funds in mobile wallets, bank accounts, or mobile lines, through a single API call per transaction or a batch upload for bulk disbursements.

The core value proposition is reliability and coverage. Simpaisa's disbursement network reaches mobile wallet accounts at all major operators in each country, bank accounts via domestic interbank rails, and - in Pakistan - mobile lines via airtime top-up. Partners including dLocal, TerraPay, Cadana, GCC Remit, Uniteller, VOOO, and Muzz use Simpaisa's Pay-Out rails as downstream disbursement infrastructure for cross-border remittance last-mile delivery, leveraging Simpaisa's local licences and operator relationships to deliver funds to end-recipients without establishing their own in-country infrastructure.

The product architecture mirrors Pay-Ins in its API-first design: a single integration enables disbursement across all supported channels and countries. A purpose-built batch file upload capability supports high-volume disbursement programmes - payroll runs, mass refund campaigns, or insurance distributions - without requiring per-transaction API calls. Each disbursement is tracked in real time through the Simpaisa dashboard, with operator confirmation references and timestamps available for audit.

8.3.2 End-to-End Process Flow¶

Disbursement request submission. The merchant or partner submits a disbursement instruction via the Simpaisa Pay-Out API or batch file upload, specifying recipient identifier (wallet MSISDN, bank account number, or IBAN), amount, currency, payment method, and a unique merchant reference.
Pre-processing validation. Simpaisa's disbursement engine validates the instruction: format checks, duplicate reference detection, available balance check against the merchant's pre-funded account, and sanctions screening of the recipient identifier against applicable watchlists (OFAC, UN, EU, local regulatory lists).
Beneficiary verification (where applicable). For bank transfer disbursements, Simpaisa verifies the beneficiary account status via the interbank network where account verification services are available. For wallet disbursements, the engine confirms that the MSISDN is registered and active on the target operator.
Routing decision. The disbursement engine selects the optimal downstream channel based on the payment method specified, the recipient's operator, and current channel availability. In the event the primary channel is unavailable, fallback routing to an alternative channel is applied subject to merchant configuration.
Funds debit from merchant prefunded account. The disbursement amount plus applicable fee is debited from the merchant's pre-funded Simpaisa account. The transaction is assigned status PROCESSING.
Instruction transmission to operator. The payment instruction is transmitted to the relevant mobile wallet operator API, bank rail, or top-up gateway. For 1LINK IBFT disbursements, the instruction is submitted via the Push IBFT interface.
Operator processing. The operator processes the credit to the recipient's account. Processing times vary: mobile wallet credits are typically confirmed within 10–30 seconds; bank IBFT credits are confirmed within minutes for real-time-enabled banks; OTC disbursement vouchers are issued immediately but physical redemption is at the recipient's discretion.
Confirmation receipt. Simpaisa receives the operator's confirmation response, including the operator's own transaction reference. The transaction status is updated to COMPLETED. Where the operator returns a failure response, the transaction status is updated to FAILED and the debited amount is reversed to the merchant's prefunded account.
Webhook and dashboard notification. A signed webhook event is dispatched to the merchant's callback URL with the final transaction status, Simpaisa reference, operator reference, and timestamp. The transaction is visible in the merchant dashboard.
Daily reconciliation. All completed Pay-Out transactions are included in the daily reconciliation process, matched against operator confirmation files, and summarised in the merchant's daily disbursement report.
Monthly statement. Simpaisa produces a monthly consolidated statement for each disbursement client showing total disbursements by method and country, fees charged, and closing prefunded account balance.

8.3.3 Payment Methods by Country¶

Pakistan¶

Method	Rail	Recipient Identifier
Easypaisa Wallet	Telenor Microfinance Bank	MSISDN
JazzCash Wallet	Mobilink Microfinance Bank	MSISDN
HBL Konnect Wallet	HBL	MSISDN
Alfa Wallet	Askari Bank	MSISDN
Push IBFT	1LINK	Bank account / IBAN
Airtime Top-Up	Mobilink, Telenor, Ufone, Zong	MSISDN

Bangladesh¶

Method	Rail	Recipient Identifier
bKash Wallet	BRAC Bank subsidiary	MSISDN
Nagad Wallet	Bangladesh Post Office	MSISDN
Rocket Wallet	Dutch-Bangla Bank	MSISDN
NPSB Transfer	Bangladesh Bank NPSB	Bank account
BEFTN Transfer	Bangladesh Bank BEFTN	Bank account

Nepal¶

Method	Rail	Recipient Identifier
Khalti Wallet	Khalti Digital Wallet	MSISDN / Account
e-Sewa Wallet	eSewa Money Transfer	MSISDN / Account
IME Pay Wallet	IME Digital Solution	MSISDN
Bank Transfer	NRB-regulated rails	Bank account

8.3.4 Key Partners and Use Cases¶

Partner	Partner Type	Disbursement Use Case
dLocal	Global payment aggregator	Last-mile wallet and bank disbursements
TerraPay	Remittance / payment network	Cross-border remittance last-mile delivery
Cadana	Payroll / earned wage access	Gig and migrant worker payroll disbursements
GCC Remit	GCC-based remittance operator	Pakistan / Bangladesh inbound remittance last mile
Uniteller	Remittance operator	Americas-to-Pakistan / Bangladesh last-mile
VOOO	Digital platform	Platform earnings disbursements
Muzz	Islamic finance / social	Member disbursements and refunds

8.3.5 Pricing, SLAs, and Controls¶

Pricing. Pay-Outs are priced on a per-transaction fee basis, either as a flat fee or a percentage of disbursement value depending on the payment method and volume, as agreed in the MPSA and Country Addendum. Fees are deducted from the merchant's prefunded account at the time of instruction submission.

Prefunding Model. Pay-Outs operate on a fully prefunded basis: merchants must maintain a positive Simpaisa account balance sufficient to cover outstanding disbursements. Simpaisa does not extend credit for disbursement purposes. Low-balance alerts are triggered at configurable thresholds and communicated to designated merchant finance contacts.

SLAs:

Metric	Target
Wallet disbursement confirmation	< 60 seconds (95th percentile)
IBFT disbursement confirmation	< 5 minutes (95th percentile)
Batch file processing commencement	< 15 minutes of file receipt
Failed disbursement reversal	< 30 minutes of failure confirmation
Daily reconciliation report availability	By 08:00 local time, T+1

Controls. All disbursement instructions are subject to pre-transmission sanctions screening. Single-transaction and daily aggregate disbursement limits are enforced at the merchant account level, with breaches requiring authorisation from the Head of Payment Operations. Unusual disbursement patterns - high-velocity sequences to the same recipient, round-sum amounts, abnormal beneficiary distributions - trigger automated alerts reviewed by the Compliance team.

8.4 Remittances Operating Model¶

8.4.1 Product Description and Corridor Overview¶

Simpaisa's remittance product enables individual consumers and Money Transfer Operators (MTOs) to send funds from source markets - primarily Canada, the United Arab Emirates, and other GCC countries - to recipient households in Pakistan, Bangladesh, and Nepal. The product operates on two distinct models: a retail-facing white-label or co-branded corridor (where Simpaisa provides the full technology and settlement stack under a partner's brand), and a B2B wholesale rail model (where Simpaisa provides settlement and last-mile delivery to licensed MTOs and digital remittance platforms as a downstream infrastructure partner).

Active and in-development corridors are:

Source Market	Destination	Status	Regulatory Basis
Canada	Pakistan	Active	Canadian MSB/FMSB licence
Canada	Bangladesh	Active	Canadian MSB/FMSB licence
Canada	Nepal	Active	Canadian MSB/FMSB licence
UAE / GCC	Pakistan	In Development	DFSA licence application pending
UAE / GCC	Bangladesh	In Development	DFSA licence application pending
Saudi Arabia	Pakistan	In Development	SAMA regulatory review
UK	Pakistan	Planned	FCA registration review
USA	Pakistan	Planned	FinCEN MSB registration review

Remittance partners currently active or contracted include TangoPay (origination), Nium (FX and settlement infrastructure), and Taptap Send (corridor distribution and consumer acquisition). On the pay-out side, Simpaisa's own wallet and bank disbursement rails in Pakistan, Bangladesh, and Nepal provide last-mile delivery.

8.4.2 Regulatory Framework by Corridor¶

Canada → South Asia. Simpaisa Group holds a Canadian MSB (Money Services Business) licence and FMSB (Foreign Money Services Business) registration, issued by FINTRAC. These licences authorise Simpaisa to conduct foreign exchange dealing, money transfer, and remittance origination from Canada. Simpaisa is subject to FINTRAC's AML/ATF reporting obligations, including large cash transaction reports (LCTRs), electronic funds transfer reports (EFTRs), suspicious transaction reports (STRs), and client identification and KYC requirements under the Proceeds of Crime (Money Laundering) and Terrorist Financing Act (PCMLTFA).

Pakistan Receiving End. Inbound remittances to Pakistan are received and distributed under the State Bank of Pakistan (SBP) regulatory framework governing inward remittances. Simpaisa's domestic operations in Pakistan are conducted under an SBP Schedule H licence, which permits payment system operations including remittance pay-out. Inbound foreign currency is converted to PKR at the prevailing interbank rate, and disbursed to beneficiaries via wallet or IBFT rails.

Bangladesh Receiving End. Inward remittances to Bangladesh are subject to Bangladesh Bank regulations. The aamarPay PSO licence held by Simpaisa's Bangladesh entity provides the authorisation framework for domestic disbursement. Inward remittance receipts must be compliant with Bangladesh Bank's foreign exchange guidelines, including source of funds documentation for transactions above prescribed thresholds.

Nepal Receiving End. Nepal Rastra Bank (NRB) regulates inward remittances. Simpaisa currently operates through licensed PSP partners (e-Sewa, IME Pay, Khalti) for last-mile delivery pending receipt of its own NRB licence. Partner PSPs are contractually bound to comply with NRB remittance guidelines.

UAE / MENA. Subject to receipt of the DFSA Cat 3D licence (authorising remittance and money transfer from the DIFC), Simpaisa will originate UAE-source remittances under DFSA's regulatory framework. In parallel, Simpaisa is assessing a non-DIFC UAE CBUAE licence for onshore UAE operations.

8.4.3 End-to-End Remittance Process Flow¶

Sender initiation. The sender initiates a remittance instruction via the Simpaisa-powered or partner-branded application. The sender inputs the recipient's details (name, mobile number, bank account, or wallet identifier), selects the delivery method (wallet credit, bank transfer, or OTC cash pickup), and confirms the send amount.
Sender KYC verification. For new senders, full KYC is completed prior to transaction processing: identity document upload (passport, national ID, or driver's licence), liveness check, and proof of source of funds above applicable thresholds. For repeat senders with verified profiles, transaction-level checks apply based on amount and velocity rules.
Sanctions and compliance screening. The sender, recipient, and transaction details are screened in real time against OFAC, UN Security Council, EU, and applicable national sanctions lists, as well as PEP (Politically Exposed Persons) databases. A transaction that produces a match is placed in a HELD status and routed to the Compliance team for manual review before proceeding.
FX rate presentation and lock-in. The sender is presented with the applicable exchange rate (mid-market rate plus Simpaisa's FX spread), the fee, and the guaranteed recipient payout amount. The rate is locked for a defined window (typically 30 minutes) from the time the sender accepts. After the window expires, the transaction is repriced at the prevailing rate.
Payment collection from sender. The sender funds the remittance via their preferred source payment method in the originating country (bank transfer, debit card, or wallet). Funds are received into Simpaisa's designated client funds account in the source jurisdiction.
Settlement instruction to FX and correspondent. Simpaisa's treasury function raises a settlement instruction to its FX and settlement partner (Nium or TangoPay depending on the corridor). The foreign currency amount is converted to the destination currency at the locked rate.
Last-mile disbursement instruction. A disbursement instruction is generated and submitted via Simpaisa's Pay-Out engine to the recipient's designated delivery method - wallet credit, IBFT, or OTC voucher - in the destination country.
Recipient notification. The recipient is notified of the incoming transfer via SMS and/or push notification (where the delivery application is installed), with the expected value and any collection instructions.
Disbursement confirmation. On receipt of operator confirmation, the transaction is updated to COMPLETED. The sender receives a confirmation notification with the operator reference and disbursement timestamp.
Regulatory reporting. Completed transactions are included in FINTRAC EFTR reporting (for Canadian-originated transactions above CAD 10,000) and equivalent regulatory reports in applicable jurisdictions. AML monitoring logic processes each transaction for suspicious pattern detection and generates STR candidates for Compliance review.
Reconciliation. Remittance transactions are included in daily three-way reconciliation: internal ledger vs. FX/correspondent partner statement vs. destination operator confirmation files.

8.4.4 FX Management¶

Simpaisa's FX management approach is designed to balance the commercial imperative of offering competitive rates with the operational need to manage exchange rate risk on in-flight transactions.

Rate sourcing. Simpaisa sources live FX rates from its settlement partners (Nium, TangoPay) and cross-validates against publicly available benchmark rates. Rates are refreshed at defined intervals (minimum every 30 minutes during business hours) and displayed to consumers with the embedded spread.

Spread policy. The FX spread is the primary revenue lever on remittance transactions. Spreads are set by corridor, reflecting the liquidity depth, volatility, and competitive environment of each corridor. Spreads on the Canada–Pakistan corridor are benchmarked against major consumer remittance providers (Wise, Remitly, Western Union) to ensure commercial competitiveness.

Rate lock and exposure management. When a sender locks a rate, Simpaisa is exposed to FX movement during the window between rate lock and settlement. This exposure is managed through Simpaisa's agreements with Nium and TangoPay, which provide rate guarantees or near-instantaneous settlement that minimises open FX exposure duration. For corridors where settlement is not near-instantaneous, Simpaisa maintains FX risk limits and reports open exposure to the CFO on a daily basis.

Hedging. As transaction volumes scale, Simpaisa's treasury policy provides for the use of FX forward contracts to hedge material open exposure. Hedging activity is subject to board-approved treasury policy limits and is reported in monthly management accounts.

8.4.5 Remittance Partner Operating Model¶

Partner	Role	Integration Method	Key Corridors
TangoPay	Origination and sender network	API	Canada → Pakistan, Bangladesh
Nium	FX, settlement infrastructure	API	Multiple corridors
Taptap Send	Consumer platform, corridor distribution	Commercial partnership	Canada, UK → Pakistan, Bangladesh
GCC Remit	Origination (GCC)	API	GCC → Pakistan
Uniteller	Origination (Americas)	API	USA, Canada → Pakistan

Partner agreements include contractual KYC/AML obligations, data processing agreements under applicable privacy law, and SLAs for settlement timing and operator confirmation.

8.4.6 Compliance and Reporting Framework¶

Simpaisa's remittance compliance obligations span multiple jurisdictions and are managed through a centralised compliance management framework described in Section 12 of this Operating Model. Key obligations specific to remittances include:

FINTRAC reporting (Canada): LCTR (≥ CAD 10,000 cash), EFTR (≥ CAD 10,000 electronic), STR (suspicious transactions regardless of amount), and 24-hour rule for STR submission.
PCMLTFA record-keeping: Five-year retention of transaction records, KYC documentation, and correspondent agreement documentation.
SBP inward remittance reporting (Pakistan): Periodic returns on inward remittance volumes, source corridors, and delivery methods.
Bangladesh Bank FX reporting (Bangladesh): Compliance with the Foreign Exchange Regulation Act and Bangladesh Bank circulars governing inward remittances.
Travel Rule compliance: For transactions above applicable thresholds, full originator and beneficiary information is transmitted to the receiving institution in accordance with FATF Recommendation 16 and applicable national implementations.

8.5 Crypto Off-Ramping Operating Model¶

8.5.1 Product Description and Value Proposition¶

Simpaisa's crypto off-ramping product provides a regulated, automated service for converting USDT (Tether, an ERC-20/TRC-20 stablecoin) to Pakistani Rupees (PKR), with disbursement directly to the beneficiary's mobile wallet or bank account in Pakistan. The product is operated in partnership with Binance, the world's largest digital asset exchange by trading volume, which serves as the VASP (Virtual Asset Service Provider) counterparty, providing the institutional USDT liquidity and stablecoin-to-fiat conversion infrastructure.

The primary use case is the final leg of cross-border value transfer for diaspora and corporate clients who hold or transact in stablecoins. Rather than routing through traditional correspondent banking or MTO networks, these clients deposit USDT to a designated Simpaisa-linked Binance address, triggering an automated conversion to PKR at the prevailing rate and instant disbursement to the beneficiary in Pakistan. The product is particularly relevant for Pakistan's technology freelancer economy, where cross-border dollar earnings are increasingly settled in stablecoins, and for remittance senders in jurisdictions where stablecoin transfers are faster or cheaper than bank-originating alternatives.

8.5.2 USDT→PKR Process Flow¶

Client onboarding. The client (individual or corporate) completes full KYC/VASP onboarding through Binance's client identification process and, separately, through Simpaisa's own customer due diligence process, including source of funds for virtual assets. A unique Binance deposit address is provisioned and linked to the client's Simpaisa disbursement profile.
USDT deposit. The client transfers USDT from their own wallet to the provisioned Binance deposit address. Simpaisa's platform monitors the address for incoming transactions.
Blockchain confirmation. Incoming USDT transactions are monitored for block confirmations. A minimum number of confirmations (typically 6 for ERC-20; 20 for TRC-20) is required before the transaction is considered final and processing commences.
Transaction screening. On confirmation, Simpaisa applies blockchain analytics tooling (sourced from a recognised VASP compliance vendor) to screen the deposit transaction against known illicit wallet clusters, darknet markets, mixing services, and sanctioned addresses. Transactions flagged above a defined risk threshold are quarantined pending manual Compliance review.
USDT-to-PKR conversion. Binance executes the USDT-to-PKR conversion at the prevailing Binance institutional rate. The converted PKR amount, net of Binance's conversion fee and Simpaisa's off-ramp margin, is credited to Simpaisa's PKR operational account.
Disbursement instruction generation. Simpaisa's system generates a PKR disbursement instruction to the beneficiary's designated wallet (Easypaisa, JazzCash, HBL Konnect, or Alfa) or bank account via IBFT.
Last-mile disbursement. Disbursement is executed via Simpaisa's standard Pay-Out infrastructure. Confirmation is received from the operator.
Client notification. Both the client (sender) and beneficiary receive confirmation notifications with the converted amount, exchange rate applied, and Simpaisa transaction reference.
AML reporting and record-keeping. Each completed off-ramp transaction is logged in Simpaisa's AML monitoring system, including blockchain transaction hash, USDT amount, PKR equivalent, exchange rate, and beneficiary details. Suspicious patterns are escalated to the Compliance team for STR consideration.

8.5.3 VASP Regulatory Requirements¶

Pakistan regulatory context. The State Bank of Pakistan has not yet issued a comprehensive VASP licensing framework as of the date of this Operating Model. Simpaisa's crypto off-ramping activity in Pakistan is conducted under the SBP Schedule H licence, which permits payment system operations. Simpaisa monitors SBP and Securities and Exchange Commission of Pakistan (SECP) regulatory developments on digital asset regulation and is prepared to seek additional licensing if and when a formal VASP framework is promulgated.

FATF VASP Standards. Simpaisa applies FATF's recommendations for VASPs in its design of AML and CTF controls for the crypto off-ramping product. This includes risk-based customer due diligence, transaction monitoring, Travel Rule implementation for transfers above applicable thresholds, and STR reporting.

Binance partnership obligations. Binance, as the primary VASP counterparty, is subject to its own regulatory obligations in the jurisdictions where it holds licences. Simpaisa's partnership agreement with Binance includes contractual requirements for Binance to maintain applicable licences, cooperate with Simpaisa's compliance requests, and notify Simpaisa of any material regulatory developments affecting the partnership.

8.5.4 AML Controls for Virtual Assets¶

The following controls are applied specifically to the crypto off-ramping product, supplementing Simpaisa's standard AML framework:

Blockchain analytics. All incoming USDT transactions are subjected to blockchain analytics screening to trace the provenance of funds through the UTXO or account-based transaction graph. Transactions with direct or indirect exposure to high-risk wallet clusters are escalated or rejected.
Whitelisted address policy. Each client is permitted to deposit only from a set of pre-registered, KYC-verified originating wallet addresses. Deposits from unregistered addresses are held pending verification.
Stablecoin-specific transaction monitoring rules. TM rules are calibrated for patterns specific to stablecoin usage: rapid deposit-and-off-ramp cycles, structuring below blockchain analytics detection thresholds, and unusual beneficiary distribution patterns.
Enhanced due diligence for large transactions. Transactions above USD 5,000 equivalent trigger enhanced due diligence, including source of funds declaration and, where appropriate, source of wealth documentation.
Periodic blockchain address review. Registered originating wallet addresses are re-screened against updated blockchain analytics risk databases on a periodic basis (minimum quarterly).

8.5.5 Pricing and Settlement¶

Simpaisa charges an off-ramp fee expressed as a percentage of the USDT transaction value. This fee is inclusive of Binance's conversion fee and Simpaisa's margin. The PKR disbursement fee follows the standard Pay-Out pricing structure. The exchange rate applied is the Binance institutional USDT/PKR rate at the time of conversion, displayed to the client at confirmation. Settlement to the beneficiary is targeted within two hours of blockchain confirmation.

8.6 White-Label Wallets Operating Model¶

8.6.1 Product Description and Value Proposition¶

Simpaisa's white-label wallet product enables banks, mobile network operators, fintech companies, and large corporates to deploy a branded digital wallet solution on top of Simpaisa's payment infrastructure, without building the underlying payment rails, operator integrations, or compliance infrastructure from scratch. The product is designed for clients who have a consumer base, a brand, and a distribution channel, but lack the technical and regulatory infrastructure to offer their own digital payment product.

Under the white-label model, the client provides the brand, the user interface (or adopts Simpaisa's configurable UI kit), and the customer acquisition channel. Simpaisa provides the core wallet engine, payment rail integrations (deposits, withdrawals, P2P transfers, merchant payments), compliance and AML infrastructure (transaction monitoring, KYC workflow), and, where applicable, the regulatory licence under which the wallet operates. Revenue is shared between Simpaisa and the white-label client according to a negotiated commercial agreement, with Simpaisa earning a platform fee and transaction-based revenue, and the client retaining a portion of transaction revenue generated by their customer base.

8.6.2 Architecture and Configuration¶

The white-label wallet is delivered via a configurable platform that the client accesses through API and an administrative console. Key configurable parameters include: wallet branding (logo, colour scheme, UI copy), supported payment methods (subset of Simpaisa's full method catalogue), transaction limits (single transaction, daily, monthly), KYC tier thresholds (corresponding to different limit tiers), and fee structures (client-to-consumer pricing).

Simpaisa provides a software development kit (SDK) for mobile (iOS, Android) and web that the client can embed in their own application. Alternatively, the client can deploy Simpaisa's hosted wallet application under their own domain with custom branding.

8.6.3 Regulatory and Compliance Framework¶

The regulatory status of a white-label wallet depends on the jurisdiction and the commercial structure:

Pakistan: The white-label wallet operates under Simpaisa's SBP Schedule H licence. The client operates as a distribution partner rather than an independently licensed entity. KYC obligations are performed by Simpaisa or delegated to the client under a contractual KYC delegation agreement, with Simpaisa retaining primary compliance responsibility.
Bangladesh: Pending deployment. The aamarPay PSO licence will provide the regulatory framework. White-label clients will be onboarded as merchants under the PSO structure.
UAE / MENA (Planned): Subject to EMI licence issuance, Simpaisa will offer white-label e-money wallet services in the UAE, enabling clients to offer AED-denominated digital wallets under the Simpaisa EMI authorisation.

8.6.4 Go-to-Market and Client Onboarding¶

Target white-label clients include: regional telecos seeking to launch mobile money products without building fintech infrastructure; community banks and microfinance institutions seeking to digitise their client-facing proposition; employers seeking to provide digital payroll wallets to unbanked employees; and digital platforms seeking to build closed-loop or semi-closed-loop payment ecosystems.

The client onboarding process for white-label wallets follows a structured sequence: commercial negotiation and MPSA execution; regulatory due diligence and approval (where required); technical integration and UAT; compliance programme review and KYC delegation agreement; soft launch with a defined user cohort; and full commercial launch with agreed marketing support. Simpaisa assigns a dedicated Technical Account Manager and a Compliance Partner for each white-label client for the duration of the deployment.

Section 9: Commercial and Revenue Operations¶

9.1 Go-to-Market Strategy¶

Simpaisa's go-to-market strategy is built on a narrow, high-impact target merchant profile and a partnership-led distribution model that leverages the credibility of existing Tier A clients to enable new client acquisition. Rather than pursuing horizontal market coverage, Simpaisa focuses commercial resources on five merchant segments where the combination of unmet payment need, high transaction volume, and willingness to pay a competitive MDR produces the strongest commercial returns.

Segment 1: Global Technology and App Platforms. Google, Samsung, and similar global technology companies face persistent conversion problems in South Asian markets owing to the absence of credit card penetration among their target consumer base. Simpaisa's ability to offer localised wallet, DCB, and OTC payment access through a single API integration, without requiring the technology company to navigate local licensing, is a compelling proposition. Commercial conversations with this segment are typically initiated at the global payments or treasury level, with procurement and legal cycles of 3–9 months. Simpaisa's existing relationships with Google and Samsung serve as reference accounts.

Segment 2: Gaming and Digital Content Platforms. Garena, Tencent, Coda, Xsolla, and Razer Gold represent global gaming publishers and distribution platforms whose games are played at high volume in Pakistan and Bangladesh, but whose conversion rates are suppressed by the absence of locally integrated payment methods. DCB is a particularly powerful channel in this segment, as it enables micro-transactions charged to the consumer's mobile line without requiring any payment credential. Simpaisa's DCB integration across all four Pakistani operators and its OTC network are principal differentiators. Commercial conversations in this segment are typically initiated via the regional payments or business development teams of the platform, with shorter sales cycles (2–4 months) owing to the high urgency of conversion rate improvement.

Segment 3: Ride-Hailing and Gig Economy Platforms. InDrive and similar platforms require both Pay-In (consumer payment collection) and Pay-Out (driver earnings disbursement) capabilities in local markets. The bidirectional nature of the flow is operationally complex, and Simpaisa's ability to provide both products under a single integration and single settlement relationship is a meaningful simplification. Commercial conversations in this segment are initiated at the local or regional country management level, with procurement cycles that are typically faster than enterprise technology clients.

Segment 4: Remittance MTOs and Global Payment Networks. dLocal, TerraPay, Thunes, Nium, and Taptap Send are global payment intermediaries that require reliable, licensed local last-mile delivery infrastructure in South Asian markets. Simpaisa serves these clients as a wholesale payment infrastructure provider, rather than competing with them in their consumer-facing segments. Relationships in this segment are initiated through network introductions, industry events (Money20/20, Seamless), and Simpaisa's commercial team in Dubai and Singapore. Contract values are high and relationships tend to be long-term and exclusive by corridor.

Segment 5: Islamic Finance and Community Platforms. Muzz represents a growing category of digital platforms serving Muslim communities globally, where Sharia-compliant financial products and localised payment access are both requirements. Simpaisa's ability to offer wallet and IBFT payment collection in Pakistan, combined with its own product roadmap for Sharia-compliant financial infrastructure, positions it well in this segment.

Go-to-market channels: - Direct enterprise sales: Simpaisa's commercial team in Dubai engages directly with decision-makers at target merchants via outbound outreach, conference presence, and referral networks. - Partner-led distribution: Global payment aggregators (dLocal, Thunes, TerraPay) distribute Simpaisa's local payment access to their own merchant clients, creating an indirect channel that extends Simpaisa's reach without proportional sales cost. - Developer community: Simpaisa's developer portal, API documentation, and sandbox environment enable bottom-up adoption by development teams at digital companies, which can create pull demand that accelerates top-down commercial negotiations. - Regulatory and industry networks: Active participation in SBP, Bangladesh Bank, and DFSA regulatory engagement creates visibility and credibility with regulated financial institutions seeking payment infrastructure partners.

9.2 Merchant and Partner Onboarding Process¶

Simpaisa's merchant onboarding process is structured to balance the commercial imperative of rapid activation with the compliance requirement for thorough due diligence. The process operates in four stages, governed by a standardised documentation framework comprising the Master Payment Services Agreement (MPSA), a Service Addendum (specifying the products enabled), and a Country Addendum for each country in which the merchant wishes to operate.

Stage 1: Commercial Qualification (Days 1–5)¶

The Account Executive completes an initial qualification assessment covering: merchant identity and corporate structure; country of incorporation and beneficial ownership; target markets and payment methods; estimated monthly GTV; and compliance profile (industry, product type, regulatory status in source jurisdiction). High-risk merchant categories - adult content, online gambling, unlicensed financial services, weapons, and tobacco - are identified at this stage and escalated to Compliance for risk assessment before proceeding. The output of Stage 1 is a commercial term sheet, which sets out the indicative MDR by payment method and country, settlement cycle, and onboarding timeline. The term sheet is not a legally binding commitment; it serves as the basis for commercial alignment prior to legal documentation.

Stage 2: Legal Documentation (Days 5–15)¶

Upon commercial agreement on the term sheet, Simpaisa's legal team issues the MPSA, the applicable Service Addendum, and Country Addenda. The MPSA governs the overarching legal relationship: liability, indemnity, IP ownership, data protection, dispute resolution, and governing law (Singapore law, with ICC arbitration). The Service Addendum specifies the enabled product (Pay-Ins, Pay-Outs, or both), the MDR table, the settlement currency, and any bespoke commercial terms. Each Country Addendum incorporates country-specific regulatory requirements, local law provisions, and product-specific terms applicable to that jurisdiction. All documents are executed electronically via DocuSign. The legal team targets a 7-day turnaround from first issue to signed execution.

Stage 3: Compliance Due Diligence (Concurrent with Stage 2, Days 5–20)¶

Compliance due diligence is conducted in parallel with legal documentation. Requirements are scaled by merchant risk profile:

Merchant Category	CDD Requirements
Low risk (e.g., listed global tech company)	Corporate registry, UBO declaration, sanctions screening, website review
Medium risk (e.g., mid-size gaming platform)	Above + audited accounts, bank reference, product review, TOS review
High risk (e.g., crypto platform, MTO)	Above + source of funds, regulatory licence copies, full UBO KYC, site visit or video CDD

Sanctions screening is conducted against OFAC, UN, EU, UK, and applicable local lists for all directors, UBOs, and the merchant entity. The compliance assessment produces a risk rating (Low / Medium / High) and a recommendation to proceed, proceed with conditions, or decline. The Chief Compliance Officer approves all High-risk merchant onboardings.

Stage 4: Technical Integration and Go-Live (Days 15–45)¶

Following execution of legal documents and clearance by Compliance, the merchant receives sandbox API credentials and access to Simpaisa's developer portal. A Technical Account Manager is assigned and conducts an integration kick-off call. The integration process covers: API authentication setup, payment method configuration, webhook endpoint configuration, testing of key transaction flows (success, failure, fallback, refund), and UAT sign-off. Once UAT is completed and approved, production API credentials are issued. The go-live checklist is completed, covering: production environment configuration, MDR parameters set in the billing engine, settlement bank account registered and verified, merchant dashboard access provisioned, and escalation contacts registered. Merchant goes live in production.

Onboarding KPIs:

Milestone	Target
Term sheet issued	Within 3 business days of initial qualification
MPSA issued	Within 5 business days of term sheet agreement
CDD completion	Within 10 business days of documentation receipt
Sandbox credentials issued	Within 2 business days of MPSA execution
Go-live	Within 30 days of MPSA execution (standard); 45 days (complex)

9.3 Account Management and Partner Success¶

Simpaisa operates a tiered account management model aligned with merchant revenue contribution and strategic importance.

Tier 1 - Strategic Accounts. Merchants generating or projected to generate monthly GTV above USD 1 million. Assigned a dedicated Strategic Account Manager (SAM) based in Dubai, with direct access to Simpaisa's product, compliance, and technology leadership. Quarterly business reviews (QBRs) covering transaction volume, channel performance, disputes, and roadmap alignment. Dedicated Slack or equivalent messaging channel for real-time support. SLA for urgent issues: 1-hour response, 4-hour resolution target.

Tier 2 - Growth Accounts. Merchants generating monthly GTV between USD 100,000 and USD 1 million. Managed by an Account Manager with a 1:10 portfolio ratio. Monthly check-in calls and access to Simpaisa's merchant support portal. SLA for urgent issues: 4-hour response, 24-hour resolution target.

Tier 3 - Self-Service Accounts. Merchants generating monthly GTV below USD 100,000. Managed primarily through the merchant dashboard, support portal, and ticketing system. Assigned a named Support Manager as a named contact for escalations. SLA for urgent issues: 8-hour response, 48-hour resolution target.

Partner Success Activities. Across all tiers, Simpaisa provides: - Monthly transaction and performance reports via dashboard and email. - Proactive notification of planned maintenance windows, channel disruptions, and regulatory changes affecting the merchant's enabled countries or payment methods. - New product and market launch briefings. - Compliance support for merchant-side AML/CTF obligations, including guidance on data fields required for Travel Rule compliance. - Annual MPSA review and commercial renegotiation for Tier 1 and Tier 2 accounts.

Merchant Health Score. Simpaisa's commercial operations team maintains a Merchant Health Score for each account, updated monthly, incorporating: transaction volume trend, success rate trend, dispute and chargeback rate, settlement break frequency, and CDD expiry status. Accounts with declining health scores are flagged for proactive intervention.

9.4 Business Intelligence and Analytics¶

Simpaisa's business intelligence function provides data-driven insights to support commercial decision-making, operational improvement, and regulatory reporting. The BI infrastructure is built on a cloud-native data warehouse that consolidates transaction data, operator confirmation data, reconciliation outputs, and merchant account data into a single analytical layer.

Merchant-Facing Analytics. Each merchant has access to a real-time dashboard providing: transaction volume by payment method and country, success rate trends by channel, settlement status and history, refund and dispute activity, and top-line revenue metrics. The dashboard supports date-range filtering, CSV export, and - for Tier 1 merchants - custom report configuration.

Internal Commercial Analytics. The commercial team uses internal analytics to track: GTV by merchant, segment, country, and payment method; MDR yield and revenue trend; merchant cohort retention and churn; pipeline-to-live conversion rates; and product penetration (proportion of eligible merchants using each product). Commercial analytics are reviewed weekly by the Chief Revenue Officer and reported monthly to the board.

Operational Analytics. The Payment Operations team uses operational dashboards to monitor: real-time transaction success rates by channel, operator uptime and response times, reconciliation break rates, and settlement timelines. Operational KPIs are tracked against targets defined in Section 10.

Revenue Attribution. Simpaisa's BI system maintains a transaction-level revenue attribution model, enabling management to calculate contribution margin per merchant, per channel, and per country, net of direct costs (operator share, FX cost, cloud infrastructure). This model informs pricing decisions, product investment prioritisation, and market entry assessments.

9.5 Pricing Strategy and Revenue Model¶

Simpaisa's revenue is generated from two primary sources: Merchant Discount Rate (MDR) on Pay-In and Pay-Out transaction value, and FX spread on cross-border and remittance transactions. Secondary revenue sources include white-label wallet platform fees, subscription billing access fees, and - in development - treasury yield on pre-funded client balances held in interest-bearing accounts.

MDR Revenue. The MDR is the dominant revenue driver. MDR rates are set to cover (i) the underlying cost of accessing the payment rail (operator share, interchange, OTC agent commission, bank fees), (ii) Simpaisa's operational cost allocation to transaction processing, compliance, and support, and (iii) Simpaisa's margin. The margin component is managed as a percentage of GTV and is the primary lever for gross profit improvement.

Rate differentiation strategy: - By payment method: DCB carries the highest MDR (operator share is typically 20–30% of transaction value for gaming), while IBFT carries the lowest. Wallet MDRs sit in between, reflecting operator API access fees. - By merchant volume tier: Volume discounts are offered at defined GTV thresholds to incentivise merchant growth and to protect against merchant migration to lower-cost alternatives as volumes scale. Volume tier renegotiation is triggered by a formal request from the merchant or by the Account Manager at the annual review. - By merchant industry: Some merchant categories (e.g., listed global technology companies with high public profile and low dispute rates) may receive preferential MDR treatment to acquire or retain the account, reflecting the strategic and reference value of the relationship.

FX Spread Revenue. The FX spread is applied to all transactions where Simpaisa converts between currencies: remittance transactions (origination currency to destination currency), merchant settlements in a currency other than the local currency, and crypto off-ramp USDT-to-PKR conversions. The spread is set by corridor, reviewed monthly against market benchmarks, and represents a margin above the mid-market rate. FX spread revenue scales directly with transaction volumes and is highly sensitive to the competitiveness of rates offered versus alternative providers.

Revenue Model Summary:

Revenue Line	Driver	Key Lever
Pay-In MDR	Gross transaction value	MDR rate, payment method mix, volume growth
Pay-Out fee	Disbursement transaction volume	Per-transaction fee, volume growth
Remittance FX spread	Remittance GTV	Spread size, corridor mix, volume growth
Crypto off-ramp fee	USDT off-ramp volume	Off-ramp margin, Binance rate competitiveness
White-label platform fee	Number of deployed wallets	Platform fee per client, usage fees
Subscription billing access fee	Recurring billing GTV	Access fee structure

Section 10: Payment Operations¶

10.1 Transaction Lifecycle Management¶

10.1.1 Transaction State Machine¶

Each transaction processed by Simpaisa progresses through a defined set of states. The state machine is enforced by the payment gateway and is the canonical record of transaction status across all internal systems and merchant-facing interfaces.

State	Description	Permitted Transitions
`INITIATED`	Transaction session created; merchant has invoked the API	→ `PENDING`, `EXPIRED`, `CANCELLED`
`PENDING`	Payment instruction submitted to operator; awaiting consumer action or operator confirmation	→ `PROCESSING`, `FAILED`, `EXPIRED`
`PROCESSING`	Operator has acknowledged receipt of instruction; processing underway	→ `COMPLETED`, `FAILED`, `REVERSED`
`COMPLETED`	Operator has confirmed successful payment; funds received or disbursed	→ `REFUND_INITIATED`, `DISPUTED`
`FAILED`	Operator returned failure response; no funds moved	→ `RETRYING` (if fallback enabled), `ABANDONED`
`RETRYING`	Fallback routing is active; instruction resubmitted to alternative channel	→ `PROCESSING`, `ABANDONED`
`ABANDONED`	All routing attempts exhausted; transaction closed as failed	Terminal state
`EXPIRED`	Consumer did not complete payment within session timeout window	Terminal state
`CANCELLED`	Transaction cancelled by merchant or consumer before operator submission	Terminal state
`REFUND_INITIATED`	Merchant has requested a refund for a completed transaction	→ `REFUND_PROCESSING`, `REFUND_FAILED`
`REFUND_PROCESSING`	Refund instruction submitted to operator	→ `REFUNDED`, `REFUND_FAILED`
`REFUNDED`	Operator has confirmed credit to consumer; refund complete	Terminal state
`REFUND_FAILED`	Operator unable to process refund	→ Manual investigation queue
`DISPUTED`	Consumer or scheme has raised a dispute or chargeback	→ `DISPUTE_UNDER_REVIEW`, `CHARGEBACK_ACCEPTED`, `DISPUTE_RESOLVED`
`DISPUTE_UNDER_REVIEW`	Dispute is being investigated by Payment Operations and/or card scheme	→ `CHARGEBACK_ACCEPTED`, `DISPUTE_RESOLVED`
`CHARGEBACK_ACCEPTED`	Dispute resolved in consumer's favour; funds returned	Terminal state
`DISPUTE_RESOLVED`	Dispute resolved in merchant's favour; original completed status reinstated	→ `COMPLETED`
`HELD`	Transaction flagged by compliance or risk controls; processing suspended	→ `PROCESSING` (post-clearance), `CANCELLED` (post-rejection)

10.1.2 Timeout and Expiry Management¶

Each transaction session is assigned a configurable expiry window from creation, with defaults set by payment method: - Mobile wallet: 15 minutes - DCB: 10 minutes - OTC voucher: 72 hours (consumer has a 72-hour window to present at agent) - IBFT: 30 minutes - Card (3DS): 15 minutes

Transactions in PENDING state that have not transitioned within the expiry window are moved to EXPIRED by an automated timer process. For OTC transactions, an additional extension window is available with merchant approval.

10.1.3 Idempotency and Duplicate Prevention¶

The payment gateway enforces idempotency on transaction creation using the merchant's supplied idempotency key. If a merchant submits a second request with an identical idempotency key within a 24-hour window, the gateway returns the status of the original transaction without creating a new transaction record. This prevents duplicate billing caused by network timeouts or retry logic in the merchant's systems. Idempotency keys are stored and indexed for 90 days.

10.2 Settlement and Reconciliation¶

10.2.1 Three-Way Reconciliation Model¶

Simpaisa's reconciliation framework is built on a three-way match principle, applied daily for each payment method and country:

Leg 1: Internal Ledger vs. Operator Confirmation Files. Simpaisa's internal transaction ledger, maintained by the payment gateway, is compared against confirmation files received from each downstream operator (wallet operator, MNO, bank, or card acquirer). The comparison checks: (i) all transactions recorded as COMPLETED in the internal ledger have a corresponding operator confirmation; (ii) all transactions in operator confirmation files have a corresponding internal ledger entry; (iii) amounts match within permitted rounding tolerance. Discrepancies are classified as: - Ledger surplus: Transaction recorded as completed internally with no operator confirmation → investigated for potential ghost transaction or data feed delay. - Operator surplus: Operator confirmation with no matching internal record → investigated for potential unrecorded transaction or data integration error. - Amount mismatch: Matching references but different amounts → investigated as potential operator billing error.

Leg 2: Operator Confirmation Files vs. Operator Financial Statements. Operator confirmation files (which report individual transactions) are compared against operator financial statements (which report aggregate settlement amounts receivable or payable). The purpose of this leg is to confirm that the financial settlement amount being received from or paid to each operator is consistent with the transaction-level data. Discrepancies at this leg typically indicate timing differences (where the operator's settlement batch includes transactions from a different date range than the confirmation file) or operator-side processing adjustments.

Leg 3: Internal Ledger vs. Merchant Settlement. The net settlement amount calculated by Simpaisa's billing engine - gross transaction value minus MDR minus FX conversion - is compared against the settlement payment made to the merchant and confirmed as received. Settlement breaks at this leg are typically caused by bank payment routing delays, SWIFT charges applied by correspondent banks, or FX rate application errors.

10.2.2 Reconciliation Cycle and Tooling¶

Reconciliation is performed daily by an automated reconciliation engine, with results reviewed by the Payment Operations team each morning. The reconciliation engine generates a daily break report categorising all unmatched items by type, amount, age, and assigned owner. Break resolution targets are:

Break Type	Target Resolution
Data feed delay (timing break)	Auto-resolved within 24 hours if operator file received next day
Amount mismatch < USD 10	Resolved within 2 business days
Amount mismatch ≥ USD 10	Escalated within 4 business hours; resolved within 5 business days
Ghost transaction (ledger surplus)	Escalated to Compliance and Technology within 1 business hour
Unrecorded transaction (operator surplus)	Escalated to Technology within 4 business hours; resolved within 2 business days
Settlement break ≥ USD 100	Escalated to Head of Payment Operations; resolved within 3 business days

10.2.3 Nostro Account Management¶

Simpaisa maintains nostro accounts in each operating jurisdiction denominated in local currency (PKR, BDT, NPR) and in USD for settlement purposes. The treasury function monitors nostro balances daily to ensure sufficient liquidity for merchant settlements and operator payments. Intraday balance alerts are set at minimum threshold levels, with escalation to the CFO if a nostro account balance falls below the agreed minimum. Nostro account reconciliation is performed daily against bank statements.

10.3 Payment Channel and Partner Network Management¶

10.3.1 Operator and Partner Monitoring¶

Simpaisa's Payment Operations team operates a network monitoring function that tracks the availability and performance of each downstream payment channel in real time. Monitoring covers: - API availability: Continuous synthetic transaction pinging of each operator API to detect outages and degraded performance. - Response time monitoring: Tracking of end-to-end API response times by operator, with alerts triggered when response times exceed defined thresholds (e.g., >2 seconds average over a 5-minute window). - Success rate monitoring: Real-time tracking of transaction success rates by channel, with alerts triggered when success rates fall below baseline thresholds. - Settlement receipt tracking: Monitoring of expected operator settlement receipts against confirmation, with escalation if settlement is not received within the agreed settlement window.

Monitoring dashboards are accessible to the Payment Operations team 24/7 via the internal NOC (Network Operations Centre) interface. Simpaisa integrates status feeds from major operators where available, and supplements these with its own synthetic monitoring.

10.3.2 Channel Health Classification¶

Each payment channel is assigned a health status, updated in real time:

Status	Definition	Action
Healthy	Success rate ≥ 95%, response time within target	No action required
Degraded	Success rate 80–94% or elevated response times	Alert to Payment Operations; monitor closely; consider reducing routing weight
Impaired	Success rate < 80% or API returning errors	Active incident; fallback routing activated; operator notified
Down	API unavailable or extended non-response	P1 incident; fallback mandatory; merchant notification issued

10.3.3 Partner Contract and Commercial Management¶

Simpaisa's commercial agreements with payment operators and partners (wallet operators, MNOs, banks, card acquirers) are maintained in a central contract management register. Key terms tracked for each operator include: API access fee structure, revenue share or interchange rate, settlement timing, minimum volume commitments, liability and indemnity provisions, and notice periods. The Head of Payment Operations is responsible for reviewing operator agreements annually and initiating renegotiation where Simpaisa's growing volumes justify improved commercial terms.

10.4 Disputes, Chargebacks, and Refund Management¶

10.4.1 Refund Management¶

Simpaisa supports real-time and delayed refund processing for Pay-In transactions. Refunds can be initiated by the merchant via the API or via the merchant dashboard. The refund process follows the transaction lifecycle states described in Section 10.1.

Refund types: - Full refund: The total original transaction value is refunded to the consumer via the original payment method. - Partial refund: A specified portion of the original transaction value is refunded, with the remainder retained by the merchant. - Wallet refunds: Processed via the reverse credit API of the relevant wallet operator. Typically confirmed within 60 seconds. - DCB refunds: Processed via the MNO billing reversal API or manual credit note to the consumer's next bill, depending on MNO capability. Can take up to 7 days for the consumer to see the credit. - IBFT refunds: Processed via reverse IBFT to the consumer's originating bank account. Typically confirmed within 24 hours. - Card refunds: Processed via scheme reversal or refund transaction. Typically credited to the consumer's card within 3–7 business days depending on the issuing bank.

MDR on refunds: Simpaisa's standard policy is that the MDR charged on the original transaction is not refunded to the merchant upon a refund being processed. This policy is stated in the MPSA. For Tier 1 merchants, an MDR refund credit note may be negotiated on a case-by-case basis.

10.4.2 Dispute and Chargeback Management¶

Card Chargebacks. Card chargebacks are managed in accordance with Visa and Mastercard scheme rules. On receipt of a chargeback notification from the acquiring bank, Simpaisa:

Logs the chargeback in the dispute management system and assigns it to a Payment Operations analyst.
Notifies the merchant within one business day, requesting relevant documentation (proof of delivery, transaction logs, customer communication records).
Compiles a representment package if the merchant contests the chargeback, including transaction evidence, and submits to the acquiring bank within the scheme deadline (typically 18 calendar days from chargeback notification).
Monitors the outcome and updates the dispute status in the system.
Where a chargeback is accepted (either because the merchant does not contest or the representment is unsuccessful), the chargeback amount is debited from the merchant's Simpaisa account.

Chargeback monitoring. Simpaisa monitors each merchant's card chargeback ratio monthly. Merchants whose chargeback ratio exceeds 0.5% of card GTV receive a formal warning and a remediation plan is agreed. Merchants whose chargeback ratio persistently exceeds 1.0% are subject to merchant agreement review, which may result in card payment suspension.

Non-Card Disputes. For wallet, DCB, and bank transfer disputes, Simpaisa manages a bilateral investigation process with the relevant operator. The consumer typically raises the dispute with the operator directly, and the operator contacts Simpaisa for transaction evidence. Simpaisa's Payment Operations team responds to operator dispute inquiries within 2 business days.

10.5 Operational Resilience and Business Continuity¶

10.5.1 Availability Target and Architecture¶

Simpaisa targets 99.9% monthly uptime for its payment gateway and API, equivalent to a maximum of approximately 44 minutes of unplanned downtime per month. This target is applicable to the payment initiation and status query APIs, the webhook delivery system, and the merchant dashboard.

The technical architecture supporting this availability target is built on a cloud-native, multi-availability-zone deployment on a tier-1 cloud provider. Key resilience features include:

Multi-AZ active-active deployment: Core payment processing components are deployed across multiple availability zones within the primary cloud region, with automatic failover in the event of a single-AZ failure.
Load balancing: Application load balancers distribute incoming API traffic across multiple application instances, with automatic removal of unhealthy instances from the load balancer pool.
Database redundancy: Primary databases are configured with synchronous multi-AZ replication. In the event of primary database failure, promotion of a replica to primary is automated and targeted to complete within 60 seconds.
CDN and DDoS protection: The API gateway and hosted payment pages are fronted by a CDN layer with integrated DDoS mitigation, protecting against volumetric attack and reducing latency for globally distributed merchant clients.
Operator fallback routing: As described in Section 8.2.4, the payment gateway implements automated fallback routing at the operator level, ensuring that a failure of a single downstream operator does not result in total channel failure for a given payment method.

10.5.2 NOC and SOC Monitoring¶

Simpaisa operates a combined NOC/SOC (Network Operations Centre / Security Operations Centre) function, staffed 24 hours a day, 7 days a week, across time zones covering Dubai and Pakistan. The NOC/SOC is responsible for:

Real-time infrastructure monitoring: Cloud infrastructure health, application performance metrics, API response times, error rates, and queue depths.
Payment channel monitoring: Operator API availability and success rates as described in Section 10.3.
Security monitoring: SIEM-based monitoring of access logs, authentication events, anomalous API usage patterns, and threat intelligence feeds.
Incident management: Detection, triage, escalation, and coordination of resolution for all P1 and P2 incidents.

Incident severity levels are defined as:

Severity	Definition	Response Time	Escalation
P1 - Critical	Payment gateway down or >50% transaction failure rate	15 minutes	Immediate: CTO, Head of Payment Operations, CEO
P2 - High	Single channel or country fully impaired; >20% failure rate	30 minutes	Head of Payment Operations, CTO
P3 - Medium	Degraded performance in one channel; elevated error rates	2 hours	Payment Operations team lead
P4 - Low	Minor degradation; no material merchant impact	Next business day	Payment Operations team

All P1 and P2 incidents are subject to a formal post-incident review (PIR) within 5 business days, with root cause analysis, timeline reconstruction, and identification of preventative actions.

10.5.3 Business Continuity Plan¶

Simpaisa maintains a documented Business Continuity Plan (BCP) reviewed annually and tested via tabletop exercise. Key BCP scenarios covered include:

Cloud provider outage: Runbook for failover to secondary cloud region or alternative provider, with RTO (Recovery Time Objective) of 4 hours and RPO (Recovery Point Objective) of 15 minutes.
Key operator failure (major wallet or MNO): Fallback routing protocols and merchant communication templates pre-prepared. Commercial review of fallback operator capacity triggered.
Cyber incident: Incident response playbook covering containment, eradication, recovery, and regulatory notification obligations (SBP, Bangladesh Bank, FINTRAC, DFSA as applicable).
Key person dependency: Documented succession plans for Head of Payment Operations, CTO, and Chief Compliance Officer. Critical system access is distributed across at least two authorised personnel for all sensitive operations.
Data centre / office loss: Remote working capability is fully operational; critical systems are cloud-hosted with no single-site dependency.

10.5.4 Disaster Recovery Testing¶

Simpaisa conducts the following DR tests on a scheduled basis:

Test Type	Frequency	Success Criteria
Multi-AZ failover simulation	Quarterly	Failover completes within 60 seconds; no transaction data loss
Database replica promotion	Semi-annually	Promotion completes within 60 seconds; application reconnects automatically
Full cloud region failover	Annually	RTO ≤ 4 hours; RPO ≤ 15 minutes
BCP tabletop exercise	Annually	All critical scenarios walked through; action items logged and resolved
NOC/SOC incident simulation	Quarterly	Incident detected, triaged, and escalated within defined response times

DR test results are documented and reported to the Technology and Risk Committee. Material deviations from RTO/RPO targets trigger a remediation project with defined completion milestones.

End of Sections 8, 9, and 10.

Document: Simpaisa Group Operating Model - Version 1.0 - April 2026 Classification: Confidential - For internal use and authorised external distribution only