Simpaisa Group Operating Model¶
Sections 15–19: Technology, Information Security, Financial Management, Treasury, and People¶
Version 0.1 | April 2026¶
Document Owner: Chief Digital Officer¶
Section 15: Technology Architecture¶
15.1 Technology Strategy and Principles¶
Simpaisa's technology function exists to deliver a platform that is simultaneously high-throughput, highly available, and continuously deployable - at a scale appropriate to a cross-border payments business serving frontier markets where connectivity, regulatory constraints, and consumer behaviour vary materially between corridors. The technology strategy is set by the Chief Digital Officer and executed by the Chief Technology Officer, Saqlain Raza, through a 38-person engineering organisation structured into six functional teams.
Four strategic principles govern all technology decisions and are applied consistently across architecture, tooling, hiring, and roadmap prioritisation.
API-first design. Every capability Simpaisa builds is exposed first as an API. There are no internal "back-door" integrations, no point-to-point database connections between services, and no shared codebases between products. This discipline ensures that internal development teams, external merchant integrators, and future white-label partners all interact with the platform through the same versioned, documented, rate-limited interfaces. API-first design also enforces a natural separation of concerns that makes individual services independently testable, deployable, and replaceable.
Cloud-native architecture. Simpaisa's platform is built to run on managed cloud infrastructure. Services are containerised, stateless where possible, and designed to scale horizontally without manual intervention. Persistent state is managed through purpose-selected managed database services rather than application-level caching of authoritative data. Infrastructure is defined as code and can be reprovisioned from version-controlled templates without human configuration. The aim is to eliminate the class of operational incidents that originate from configuration drift, manual server management, or undocumented infrastructure dependency.
Cloudflare-first for edge and in-country presence. Simpaisa is executing a deliberate transition away from reliance on AWS CloudFront and AWS-regional endpoints as the primary mechanism for serving in-country traffic. Cloudflare is being adopted as the default layer for DNS, DDoS mitigation, web application firewall, CDN, and - progressively - for in-country edge compute via Cloudflare Workers. This strategy addresses a specific constraint in frontier markets: several of Simpaisa's operating jurisdictions impose data localisation requirements or exhibit high latency from AWS regions, and Cloudflare's distributed PoP footprint (including dedicated PoPs in Karachi, Dhaka, Kathmandu, and Baghdad) provides lower-latency, locally compliant request handling that AWS CloudFront cannot replicate at equivalent cost. The transition is structured as a phased migration rather than a hard cutover, with AWS retained as the origin and compute layer during the transition period.
SRE operational model. Simpaisa does not operate a traditional Change Advisory Board. Engineering teams own the operational reliability of the services they build. Site Reliability Engineers are embedded across the DevOps and DB team and are jointly accountable with development teams for service-level objectives, incident response, and capacity planning. The SRE model removes the structural bottleneck of change approval gates and shifts quality assurance left into automated testing, canary deployments, and feature flags. Where regulatory bodies require change records (as is the case under PCI DSS and some central bank requirements), those records are produced automatically from the CI/CD pipeline rather than through manual pre-approval workflows.
15.2 Platform Architecture Overview¶
Simpaisa's technology platform is composed of five logical layers, each built as a collection of independently deployable services rather than a monolithic application.
Payment Gateway. The gateway is the entry point for all externally originated transactions - merchant Pay-In requests, partner Pay-Out instructions, and consumer-initiated wallet operations. It handles API authentication (API key validation and HMAC signature verification), session creation, request validation, idempotency enforcement, and initial routing decisions. The gateway is built on Node.js and exposes a REST API over HTTPS. It is designed to be stateless: all session and routing context is persisted to Redis for sub-millisecond retrieval, and no session state is held in application memory. Gateway instances run behind an AWS Application Load Balancer with health-check-driven auto-scaling configured to maintain response times under load.
Processing Engine. The processing engine executes payment instructions once the gateway has validated and routed a request. It is responsible for connecting to downstream operator APIs and banking rails - mobile wallet operators, mobile network operators for DCB, 1LINK/1Bill, IBFT interfaces, card acquirers, and crypto off-ramp providers. The engine is built primarily in Java with Spring Boot microservices, one per payment channel, to allow independent deployment cycles for each integration. Kafka is used as the messaging backbone between the gateway and the processing engine, ensuring that payment instructions are durably queued and that temporary downstream outages do not result in data loss or duplicate processing. Each Kafka consumer group is designed to be idempotent: processing a message twice produces the same outcome as processing it once.
Settlement Engine. The settlement engine aggregates completed transactions, calculates merchant net settlement amounts after MDR deduction, applies FX conversion at agreed rates, generates settlement files, and triggers outbound fund transfers via banking partners. It runs on a configurable settlement cycle - typically T+1 or T+2 depending on the merchant agreement and the currency corridor - with real-time settlement available for selected high-volume merchants. Settlement calculation logic is written in Python to facilitate auditability and ease of inspection by finance and compliance teams. Outputs from the settlement engine feed directly into the finance general ledger via an automated API integration, eliminating manual reconciliation of settlement runs.
Merchant Portal. The merchant-facing portal provides a self-service interface for transaction reporting, settlement history, API key management, webhook configuration, and dispute management. It is built on React for the consumer-facing frontend and Node.js for the backend-for-frontend (BFF) layer. The portal is entirely distinct from the payment gateway and does not share any API endpoints or database schemas with transaction-critical services, limiting the blast radius of any portal-layer security incident. A separate WordPress-based public-facing marketing site handles documentation, developer resources, and onboarding for prospective merchants.
Partner APIs. Simpaisa exposes a dedicated API surface to licensed payment partners and white-label customers who consume the platform as a service rather than as a direct merchant. Partner APIs support balance enquiry, transaction status polling, payout instruction submission, and settlement reporting. These APIs are versioned independently of the merchant gateway APIs and carry higher rate limits appropriate to aggregator-level traffic volumes.
15.3 Infrastructure¶
Current AWS Configuration. Simpaisa's primary infrastructure runs on Amazon Web Services. Core compute is delivered through EC2 instances within VPCs configured with public and private subnets across multiple availability zones. Traffic ingress is managed through a combination of Application Load Balancers (for HTTP/HTTPS workloads) and Network Load Balancers (for TCP workloads requiring fixed IP addresses, including operator API connections that are IP-whitelisted at the counterparty). Outbound traffic from private subnets is routed through NAT Gateways. AWS Parameter Store holds all environment configuration and secrets, with access controlled by IAM roles scoped to individual services. TLS certificate provisioning and renewal is automated through AWS Certificate Manager. Auto Scaling Groups are configured for gateway and processing-engine tiers with scale-out policies triggered by CPU utilisation and request queue depth. AWS SNS is used for operational alerting - triggering PagerDuty incidents for on-call engineers and notifying the NOC/SOC team of infrastructure events.
Active-Active Disaster Recovery. Simpaisa operates an active-active DR architecture: both primary and secondary infrastructure stacks are live and serving production traffic simultaneously, with load balanced across stacks. This eliminates recovery time objectives associated with failover-style DR and ensures that the loss of a single availability zone or region produces no observable service interruption. Active-active DR is a mandatory architectural constraint applied to all new services. Any proposal to deploy a service in an active-passive or single-AZ configuration requires explicit written approval from the CTO and CDO, and must include a documented remediation timeline.
Cloudflare Migration Strategy. The migration from AWS CloudFront to Cloudflare is being executed in four phases. Phase one (complete) covers DNS migration and Cloudflare proxy activation for all public-facing domains, replacing Route 53 as the authoritative DNS layer and enabling Cloudflare's DDoS mitigation and WAF in front of all entry points. Phase two (in progress) replaces the AWS WAF with Cloudflare WAF rulesets, configured to enforce the same PCI DSS-aligned rule policies as the incumbent setup. Phase three (planned, H2 2026) migrates static asset delivery from CloudFront distributions to Cloudflare CDN, with cache configuration replicated from the existing CloudFront behaviour rules. Phase four (planned, 2027) introduces Cloudflare Workers for selected edge compute tasks - geolocation-based routing, request enrichment, and lightweight API validation - reducing origin server load and improving in-country latency for the Pakistan, Bangladesh, and Iraq markets specifically.
In-Country Data Residency. Pakistan's SBP regulations and Bangladesh's Bangladesh Bank directives impose requirements on transaction data storage and processing within their respective jurisdictions. Simpaisa addresses these requirements through a combination of: dedicated AWS region selection (Mumbai for South Asia primary, with Bahrain for Middle East), Cloudflare's regional services for traffic handling and cache isolation, and contractual data processing agreements with all third-party vendors that handle in-scope personal and financial data. A data residency register is maintained by the CISO organisation and reviewed quarterly to capture any changes in regulatory requirements that affect infrastructure placement decisions.
15.4 DevOps and CI/CD¶
Simpaisa's DevOps function sits within the DevOps and DB team, led by the Head of DevOps and Database, which comprises nine people: one Head, one Lead, five DevOps engineers, and two DBAs. This team owns the CI/CD toolchain, infrastructure-as-code codebase, deployment pipelines, and database operations.
CI/CD Toolchain. Jenkins is the primary CI/CD orchestration platform. Each application repository contains a Jenkinsfile defining the pipeline stages: code checkout, static analysis (via Snyk for dependency scanning and SonarQube for code quality), unit test execution, Docker image build, integration test execution against a containerised test environment, image push to the private container registry, and deployment. Jenkins pipelines are maintained as code in Bitbucket and are subject to the same code review process as application code. Pipeline changes require review and approval from the DevOps Lead before merge to main.
Infrastructure as Code. All infrastructure is defined using Terraform. The Terraform codebase is organised into environment-specific modules (development, staging, production) and shared resource modules (VPC configuration, security groups, load balancers, managed database clusters). Ansible is used for configuration management on EC2 instances where server-level configuration is required - principally for the NOC/SOC tooling layer and for legacy services not yet containerised. The IaC codebase is stored in Bitbucket and subject to the same pull-request and review discipline as application code. Infrastructure changes in the production environment are applied only through the Jenkins pipeline, never manually from an engineer's workstation; this control is enforced via IAM policy restricting Terraform state write access to the pipeline's IAM role.
Deployment Cadence Target. The technology organisation is targeting a daily deployment cadence for all production services. As of April 2026, deployment frequency varies by team - the Portal and Pay-Ins teams are deploying multiple times per week, whilst the Pay-Outs team is on a weekly cycle pending completion of integration test coverage improvements. The path to daily deploys for all teams is gated on three conditions: achieving 80% automated test coverage at the unit and integration level, completing the migration to feature-flag-driven releases (which decouple deployment from feature activation), and ensuring active-active DR is in place for each service so that a failed deployment can be redirected without user impact. Progress against these gates is tracked as an OKR for the CTO organisation.
Environments. Four environments are maintained for all services: development (shared, used for feature integration), staging (production-like, used for final pre-release validation and merchant UAT), pre-production (a canary environment receiving a small percentage of live traffic for final validation), and production. Promotion between environments is gated on automated quality checks and, for the staging-to-production gate, on explicit sign-off from the SQA Head.
15.5 Database Architecture¶
Simpaisa operates a polyglot persistence model, selecting database technology based on the access patterns and consistency requirements of each service domain rather than applying a single database engine across the platform.
MySQL. MySQL is used for transactional data where relational integrity and ACID guarantees are required. Primary use cases include the core transaction ledger, merchant account records, settlement batch records, and financial journal entries. MySQL is deployed on AWS RDS with Multi-AZ replication enabled, providing automatic failover within the same region. Read replicas are provisioned for reporting workloads to avoid placing analytical query load on the transactional primary. Schema changes are managed through Flyway, which ensures that migration scripts are version-controlled, reviewed, and applied consistently across all environments.
PostgreSQL. PostgreSQL is used for services that require more complex data types or query capabilities than MySQL provides. The primary instance at present is the Merchant Portal's configuration and reporting database, which stores merchant configuration, webhook endpoint registrations, and pre-aggregated reporting data. PostgreSQL is also the database of choice for new service development where the engineering team has no specific technical reason to prefer MySQL, making it the default for greenfield builds. Deployment follows the same AWS RDS Multi-AZ pattern as MySQL.
MongoDB. MongoDB is used for semi-structured operational data where schema flexibility is valuable and eventual consistency is acceptable. Primary use cases include payment event logs, operator API response archiving, and audit trails for configuration changes. The event log pattern - in which each state transition of a payment transaction is recorded as an immutable document - suits the document model well and simplifies audit trail retrieval. MongoDB is deployed as a replica set across multiple availability zones.
Amazon DocumentDB. Amazon DocumentDB (MongoDB-compatible) is used for specific high-volume data workloads where the managed service's auto-scaling and operational simplicity outweigh the feature parity considerations with native MongoDB. Current usage is primarily for the payment session store, where high write throughput and low-latency reads are required and the data lifecycle is short (sessions are purged after 24 hours or on completion, whichever is sooner).
DBA Governance. Two dedicated DBAs within the DevOps and DB team are responsible for database performance tuning, backup and recovery testing, schema review participation, and capacity planning. All production schema changes must be reviewed by a DBA before deployment. Backup schedules, retention periods, and recovery tests are documented in the DR runbook and tested quarterly.
15.6 API Management¶
Gateway and Versioning. Simpaisa's APIs use URI-based versioning (e.g., /v1/, /v2/) to allow merchants and partners to adopt new API versions at their own pace without being forced to migrate on Simpaisa's release schedule. A deprecation policy governs the lifecycle of each API version: a version is supported for a minimum of 24 months from the date of its successor's general availability, with a minimum of 90 days' written notice before any version is retired. API changelogs and deprecation notices are published to the developer documentation portal and communicated directly to affected integrators via account management.
Sandbox Environment. A dedicated sandbox environment is provided for all merchant and partner integrations. The sandbox mirrors the production API surface but routes all payment instructions to a simulated operator layer, meaning no real funds move and no real operator systems are called. The sandbox supports simulated success, failure, timeout, and partial-completion scenarios, configurable via request parameters, to allow integrators to test their error-handling and reconciliation logic before go-live. Sandbox credentials are independent of production credentials; no action in the sandbox environment can affect production data.
Rate Limiting and Throttling. API rate limits are enforced at the gateway layer using a token bucket algorithm. Default rate limits are set per API key, with higher limits available to partners on a contractually agreed basis. Rate limit responses return standard HTTP 429 status codes with Retry-After headers indicating the reset interval. Merchants approaching their rate limits receive automated alerts via their dashboard. Cloudflare's rate limiting layer provides a secondary defence at the edge, protecting origin infrastructure from volumetric abuse before it reaches the gateway.
Documentation. All API endpoints are documented using the OpenAPI 3.0 specification, which is maintained in Bitbucket alongside the gateway code and deployed automatically to the developer portal on each release. The developer portal includes interactive API explorers, authentication guides, SDK downloads for common languages (PHP, Python, Node.js, Java), and worked examples for each payment method and corridor.
15.7 Software Development Life Cycle¶
Agile and Scrum. Engineering teams operate on a two-week Scrum sprint cadence. Each team runs its own sprint planning, daily stand-up, sprint review, and retrospective. Backlogs are maintained in Jira, with user stories written to a standard template that includes an acceptance criteria section and links to any relevant API specification, compliance requirement, or regulatory obligation. The Head of Development for each team is the primary interface between the engineering team and the Product team, translating product requirements into engineering tasks and surfacing technical constraints to Product Managers before planning is finalised.
Definition of Done. A story or task is considered done when all of the following conditions are met: code is merged to the main branch in Bitbucket following approval from at least one peer reviewer and one senior/lead engineer; all automated unit tests pass; integration tests pass in the development environment; code coverage has not decreased from the baseline; Snyk dependency scan returns no new high or critical severity findings; deployment to staging has completed successfully; acceptance criteria have been verified by the SQA team or the requestor; and, where applicable, API documentation has been updated to reflect the change.
Code Review. Every merge request (MR) in Bitbucket requires a minimum of two approvals before merge to the main branch: one from a peer engineer (same seniority or above) and one from the team lead or a member of the Architecture team. Architecture team members review all MRs that introduce new service dependencies, modify database schemas, change API contracts, or introduce new third-party libraries. Reviews are expected to be completed within one business day; MRs that have not received a review within two business days are escalated to the Development Manager.
Branch Strategy. Simpaisa uses a trunk-based development model. Engineers create short-lived feature branches from main, complete their work, and raise an MR for review and merge back to main. Release branches are used only where a hotfix must be deployed to production without including unreleased features that are already on main. Long-lived feature branches are not permitted; work too large for a single sprint is decomposed into independently deployable increments behind feature flags.
15.8 Quality Assurance¶
The SQA team comprises seven people: one Head of SQA, one Lead SQA Engineer, and five QA Engineers. The team is responsible for test strategy, automation framework development and maintenance, performance testing, and sign-off on all production deployments.
Test Automation Framework. Simpaisa's QA automation estate is built on three frameworks, each serving a different layer of the test pyramid. REST Assured (Java) is used for automated API contract testing and regression testing of all payment gateway and processing engine endpoints. Playwright is used for end-to-end browser-based testing of the Merchant Portal and the hosted payment page flows, covering the full user journey from payment initiation through to confirmation across all supported payment methods. Appium is used for mobile-specific testing where the payment flow involves a mobile application component, including wallet deep-link flows and DCB confirmation screens.
Performance Testing. JMeter and Gatling are used for load and performance testing. JMeter is used for load profile simulation in staging ahead of major releases, particularly for payment gateway endpoints that are expected to experience high concurrency. Gatling is used for continuous performance regression testing in the CI/CD pipeline - a lightweight performance test suite runs on each build, and results are compared against a performance baseline; builds that regress beyond a defined threshold fail the pipeline without manual intervention.
Coverage Targets. The current minimum targets are 70% unit test coverage and 60% integration test coverage for all services owned by the Portal, Pay-Ins, and Pay-Outs teams. The target for new services is 80% unit coverage from first deployment. Coverage is measured by the CI pipeline and reported in the Jenkins build output; the DevOps team publishes a weekly coverage dashboard visible to the CTO and CDO. Teams falling below minimum coverage thresholds are required to produce a remediation plan within one sprint.
Defect Management. Defects found during QA are logged in Jira and triaged by the SQA Head and the relevant Development Manager within one business day. Defects are classified by severity (Critical, High, Medium, Low) with associated SLA targets for resolution: Critical defects block deployment and must be resolved before any code in the affected service is released; High defects must be resolved within three business days; Medium and Low defects are prioritised into the normal sprint backlog. Production defects found after deployment trigger a severity-based incident response process (see Section 16.9) in addition to the standard defect management process.
15.9 Technology Roadmap¶
The 12-to-24-month technology roadmap is structured around four strategic programmes, each with a named owner and a set of measurable milestones.
Programme 1: Cloudflare Migration (Owner: Head of DevOps and DB). Complete Phase 2 (WAF migration) by Q3 2026. Complete Phase 3 (CDN migration) by Q4 2026. Begin Phase 4 (Cloudflare Workers edge compute for Pakistan and Bangladesh traffic routing) in Q1 2027. Success metrics: reduction in origin server request volume, improvement in p95 response latency for in-country traffic, elimination of AWS CloudFront spend.
Programme 2: SRE Maturity and Daily Deployment Cadence (Owner: CTO, with DevOps Lead). Define and instrument service-level objectives (SLOs) for all Tier 1 services by Q3 2026. Complete feature-flag infrastructure rollout across all engineering teams by Q3 2026. Achieve daily deployment capability for Portal and Pay-Ins by Q3 2026 and for Pay-Outs by Q4 2026. Publish error budget reports to the CDO monthly from Q4 2026 onwards.
Programme 3: Observability Platform Replacement (Owner: Head of DevOps and DB). Datadog is the incumbent observability platform. The CDO has set a direction to replace Datadog over the 12–24-month horizon, driven by cost and data-sovereignty considerations. The replacement evaluation is scheduled to begin in Q3 2026 and will assess open-source and commercial alternatives - including Grafana + Prometheus + Loki, OpenTelemetry-native stacks, and Cloudflare's observability tooling - against current Datadog capability coverage. A decision and migration plan will be presented to the CDO by Q1 2027. Datadog contracts will not be renewed beyond their current term without CDO approval.
Programme 4: Platform Scalability and New Corridor Readiness (Owner: Principal Architect). The Architecture team will deliver a documented platform extension playbook for new corridor onboarding by Q3 2026, covering the technical steps required to activate a new processing-engine integration, configure settlement parameters, provision sandbox access, and onboard a merchant for a new market. This playbook will be used to support the planned UAE and Saudi Arabia corridor launches. Separately, the Architecture team will produce a service decomposition review for the Pay-Outs monolith by Q4 2026, with a recommendation on phased extraction of settlement calculation and FX rate management into independently deployable services.
Section 16: Information Security and Cyber Resilience¶
16.1 Information Security Management System (ISO 27001)¶
Simpaisa holds ISO 27001 certification, the international standard for information security management systems. The ISMS is owned by the Chief Information Security Officer, Danish Hamid, and covers all Group entities and systems that process, store, or transmit Simpaisa customer data, financial data, or proprietary business information.
The ISMS is structured around the ISO 27001:2022 control framework and comprises a policy hierarchy, a risk register, an asset inventory, a statement of applicability, and a programme of internal and external audit. The policy hierarchy is documented in Section 27 of this Operating Model and comprises an overarching Information Security Policy, supporting topic-specific policies (access control, cryptography, incident management, business continuity, supplier security, and others), and operational procedures. All policies are reviewed annually and whenever a material change occurs in the threat landscape, the technology environment, or the regulatory requirements applicable to any Simpaisa entity.
The risk register is maintained in the ISMS tool and updated continuously. Risks are assessed using a likelihood-impact matrix calibrated to Simpaisa's risk appetite, which is approved by the Board's Technology and Information Security Committee annually. Risks exceeding the defined risk appetite threshold must be mitigated to below threshold within a documented remediation timeline; the CISO reports the status of open high and critical risks to the TIS Committee at each quarterly meeting.
The ISMS internal audit programme comprises quarterly internal audits conducted by the Information Security team and an annual external ISO 27001 surveillance or recertification audit conducted by an accredited certification body. Non-conformities identified in internal or external audits are logged in the corrective action register and tracked to closure. Recertification is sought on the standard three-year cycle, with the next recertification audit scheduled accordingly.
16.2 PCI DSS Compliance¶
Simpaisa is certified under the Payment Card Industry Data Security Standard (PCI DSS). The scope of the PCI DSS programme encompasses all systems that store, process, or transmit cardholder data (CHD), including the payment gateway, card processing integrations, the hosted payment page, and the network and security infrastructure that supports these components.
PCI DSS compliance is maintained through a continuous compliance programme rather than a point-in-time annual audit. The programme includes: quarterly internal vulnerability scans of in-scope systems; annual external penetration testing of the cardholder data environment (CDE); quarterly external network scans by an Approved Scanning Vendor (ASV); and an annual Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ) depending on the transaction volume tier for each entity.
The cardholder data environment is maintained as a separate network segment, isolated from the broader corporate network by firewall rules enforced at both the AWS VPC security group level and the Cloudflare WAF edge layer. Access to CDE systems is restricted to named individuals with a documented business need; access lists are reviewed quarterly. All cardholder data at rest is encrypted using AES-256; all cardholder data in transit is transmitted over TLS 1.2 or higher. Primary Account Numbers (PANs) are never stored in their full, unmasked form in application logs. The Eastnets sanctions screening integration operates outside the CDE and does not receive full PAN data; only masked card references are passed between systems.
PCI DSS compliance obligations and audit schedules vary by entity depending on the payment schemes each entity is connected to. The CISO maintains a compliance calendar by entity, coordinating with the CFO's office and external auditors to ensure all filing deadlines are met.
16.3 Security Operations Centre (24/7 NOC/SOC)¶
Simpaisa operates an integrated Network Operations Centre and Security Operations Centre, staffed 24 hours a day, seven days a week. The NOC/SOC function sits within the CISO organisation and comprises eight people: one Lead (Rohit Rana) and seven staff covering NOC/SOC Associate, IT Help Desk, and NOC Engineer roles.
The NOC/SOC is responsible for continuous monitoring of Simpaisa's infrastructure and security posture, detecting and responding to operational and security incidents, managing escalation to the appropriate engineering or information security team, and maintaining the security event log that feeds compliance reporting. Monitoring coverage spans network traffic, system resource utilisation, application performance indicators, security event feeds from AWS Security Hub, GuardDuty, AWS Network Firewall, and Microsoft Defender, and the log correlation platform used to identify anomalous patterns across event streams.
Shifts are structured to ensure that at least two NOC/SOC staff are on duty at all times, with a minimum of one staff member with SOC-specific responsibilities present on each shift. On-call escalation lists are maintained and tested monthly. Escalation thresholds and runbooks for each alert category are documented in the NOC/SOC procedures manual, which is version-controlled and reviewed quarterly.
The NOC/SOC uses CyGlass for AI-driven network behaviour analytics, supplementing the rule-based detections from the AWS security tooling with anomaly detection that identifies threats that do not match known signatures. AttackMetricx is used for external attack surface monitoring, providing continuous visibility into what is exposed at the network perimeter and alerting on newly discovered exposure. These tools feed a consolidated alerting workflow managed through the NOC/SOC platform, with prioritisation and assignment handled by the on-duty Lead.
16.4 Cloud Security¶
AWS Security Posture. Simpaisa's AWS environment is governed by a cloud security baseline enforced through a combination of AWS-native controls and third-party tooling. AWS Security Hub provides a consolidated view of security findings aggregated from GuardDuty (threat intelligence and anomaly detection), AWS Inspector (vulnerability assessment of EC2 instances and container images), and AWS Detective (automated investigation of security incidents using machine learning). AWS WAF is deployed in front of all public-facing load balancers and is configured with managed rule groups covering OWASP Top 10 attack patterns, known bad IP lists, and custom rules specific to Simpaisa's payment API traffic patterns.
Cloudflare Security Layer. As the Cloudflare migration progresses, Cloudflare WAF, DDoS protection, and Bot Management are being positioned as the primary perimeter security layer, with AWS WAF retained as a defence-in-depth secondary layer at the origin. Cloudflare's Magic Transit is under evaluation for network-layer DDoS mitigation for Simpaisa's IP ranges. Cloudflare Access is being evaluated as an alternative to VPN-based administrative access to internal systems, providing zero-trust network access with identity-provider integration.
Cloud Security Governance. The Cloud Security Engineer (Khizer Javed) is responsible for the day-to-day management of cloud security controls, including the regular review of Security Hub findings, the management of IAM permissions and privilege reviews, and the configuration of security group and network ACL baselines. Any change to security group rules, IAM policies, or network ACLs in the production environment must be reviewed by the Cloud Security Engineer and documented in the change log. Privileged access to production AWS accounts is managed through temporary role assumption with time-limited session tokens; permanent IAM user credentials with production access are not issued to individuals.
16.5 DevSecOps and Application Security¶
Security is integrated into Simpaisa's software development life cycle through a DevSecOps model that places security controls in the CI/CD pipeline and in the development workflow rather than treating security as a gate at the end of the delivery process.
Snyk. Snyk is integrated into every Jenkins pipeline and into the Bitbucket repository at the pull-request level. It performs three categories of scanning: open-source dependency vulnerability scanning (identifying known CVEs in third-party libraries), static application security testing (SAST) of first-party code for common vulnerability patterns, and container image scanning of Docker images before they are pushed to the registry. Pipeline stages that invoke Snyk are configured to fail the build if any finding of High or Critical severity is introduced by the change under review. Findings of Medium severity or below are logged and reported to the development team but do not block deployment; they must be triaged and assigned to a sprint backlog within five business days.
SAST and DAST. Static analysis is performed in-pipeline by Snyk Code. Dynamic application security testing (DAST) is performed quarterly by the InfoSec team using automated DAST tooling against the staging environment, supplementing the annual penetration test with more frequent automated scanning of OWASP Top 10 attack surfaces. DAST findings are logged in the vulnerability register and triaged by the Information Security Manager (Hamza Bari) with input from the relevant Development Manager.
Security Code Review. The Architecture team includes security review as a mandatory consideration in their review of all pull requests introducing new external integrations, authentication changes, cryptographic implementations, or changes to data handling within the CDE. The CISO organisation has the right to request an architectural security review for any change that the Information Security Manager considers to carry material security risk, irrespective of the team that owns the change.
16.6 Penetration Testing and Vulnerability Management¶
Penetration Testing. Simpaisa conducts annual penetration tests of its external attack surface, web applications, and APIs. The penetration tests are conducted by an independent, CREST-accredited third-party firm. The scope covers the payment gateway, the merchant portal, the partner API surface, and the network perimeter. Penetration test findings are classified using the CVSS scoring framework. Critical and High findings must be remediated within 30 and 90 days respectively; remediation is verified by a follow-up retest conducted by the same firm. PCI DSS requires that the CDE perimeter and application layer are tested annually and after any significant infrastructure change; this is incorporated into the penetration testing programme scope.
Vulnerability Management. The vulnerability management process is continuous. Infrastructure vulnerabilities are surfaced through AWS Inspector, which assesses EC2 instances and container images against the NVD and vendor-published advisories. Application dependency vulnerabilities are surfaced through Snyk in the pipeline. ASV scans provide quarterly external network vulnerability visibility. All findings are tracked in the vulnerability register maintained by the Cloud Security Engineer. Vulnerabilities are prioritised using a risk-based approach that accounts for CVSS score, exploitability, compensating controls in place, and business impact of the affected system. SLA targets for remediation are: Critical - 7 days; High - 30 days; Medium - 90 days; Low - next planned maintenance window.
16.7 Data Protection and Privacy by Jurisdiction¶
Simpaisa processes personal data of consumers, merchants, and employees across nine jurisdictions. The data protection regime applicable in each jurisdiction varies in form and maturity; compliance obligations are mapped and maintained in the Data Protection Register owned by the CISO organisation and reviewed by the Group's legal counsel.
Pakistan. Pakistan's Personal Data Protection Act (PDPA) 2023 is the applicable framework. Simpaisa's Pakistan entity (PublishEx Solutions PVT Limited) is subject to its provisions as a data controller. The SBP's directives on data localisation require that payment transaction data for Pakistan-origin transactions is stored within Pakistan. Simpaisa meets this through its primary AWS Mumbai region deployment and the Cloudflare regional services configuration.
Bangladesh. Bangladesh's Digital Security Act and emerging data protection framework apply to Simpaisa's operations through Simpoysha BD Limited and Soft Tech Innovation PVT LTD (aamarPay). Bangladesh Bank's guidelines on data localisation are observed. Data subjects have the right to access and correction of personal data held by Simpaisa.
Nepal. Nepal's Individual Privacy Act 2018 is the applicable framework. Operations are conducted through PSP partnerships rather than a locally licensed entity, which limits the scope of data Simpaisa holds directly. Data handling agreements with PSP partners (Khalti, e-Sewa, IME Pay, Paywell) specify data use limitations and security requirements consistent with Simpaisa's ISMS standards.
UAE. The UAE Personal Data Protection Law (Federal Decree-Law No. 45 of 2021) and, for DIFC-operated entities, the DIFC Data Protection Law apply. As Simpaisa's UAE licences and entity structure are finalised, the applicable data protection obligations will be embedded in the operating procedures of Simpaisa Technologies LTD.
United Kingdom. Commerce Plex Limited operates under UK GDPR and the Data Protection Act 2018. A privacy notice and data processing record are maintained for the UK entity. No cardholder data is processed by the UK entity; its data processing activities relate to business development and payment origination support.
Canada. Simpaisa CA LTD operates under PIPEDA and applicable provincial privacy legislation. Personal data collected in Canada in the course of remittance origination is subject to the obligations of the registered Money Services Business.
Singapore. Simpaisa Holdings PTE. Limited is subject to the Personal Data Protection Act 2012 (PDPA) as administered by the Personal Data Protection Commission. Singapore serves as HoldCo and does not process retail consumer data at volume.
Iraq. Data protection in Iraq is governed by a combination of Communications and Media Commission requirements and Central Bank of Iraq guidance. Simpaisa's Iraq branch office is subject to these requirements, with specific attention to the localisation of transaction records for transactions settled through Iraqi banking infrastructure.
16.8 Identity and Access Management¶
Simpaisa operates a role-based access control (RBAC) model across all systems. Access rights are assigned to roles, and roles are assigned to individuals based on their job function. The principle of least privilege is applied: individuals are granted the minimum access rights necessary to perform their defined duties and no more.
Joiners, Movers, and Leavers. The HR onboarding process triggers an access provisioning request for each new joiner, specifying the role and the systems to which access is required. System access for leavers is revoked on the day of departure or, in the case of terminations, immediately upon notification from HR. Movers - individuals changing role within the Group - are subject to a role change access review, with previous access revoked before new access is granted where the roles are not additive. Access provisioning and revocation records are maintained and are reviewed as part of the ISO 27001 internal audit programme.
Privileged Access. Privileged access to production systems (AWS console, database hosts, CI/CD infrastructure, NOC/SOC tooling) is managed through a Privileged Access Management (PAM) approach: access is granted on a time-limited, session-based basis for specific approved activities, all sessions are logged, and no individual holds permanent interactive access to production infrastructure. The Cloud Security Engineer performs a quarterly review of all accounts with privileged access and reports any anomalies to the Information Security Manager.
Multi-Factor Authentication. MFA is mandatory for all access to Simpaisa's SaaS platforms, cloud consoles, VPN, and code repositories. Any exception to the MFA requirement must be approved by the CISO and documented with a compensating control. MFA enforcement is monitored and reported in the NOC/SOC weekly security report.
16.9 Incident Response Plan (SRE-Aligned)¶
Simpaisa's incident response process is aligned to the SRE operational model and is structured to ensure rapid detection, containment, and recovery, with clear accountability at each stage and a post-incident learning cycle that drives continuous improvement.
Incident Classification. Incidents are classified on a four-level severity scale. Severity 1 (Critical): complete or near-complete service outage affecting production payment processing or posing an active, confirmed security breach with data exfiltration risk. Severity 2 (High): significant degradation of payment processing capability, partial outage of the merchant portal, or a confirmed security incident that has been contained but requires investigation. Severity 3 (Medium): degraded performance, elevated error rates, or a suspected security event under investigation. Severity 4 (Low): minor issues, non-impacting anomalies, or security findings that require remediation but present no immediate risk.
Response Process. On detection of a Severity 1 or 2 incident - whether by the NOC/SOC monitoring, an automated alert, or external notification - the on-duty NOC/SOC Lead declares an incident, creates an incident channel in the team communication platform, and pages the on-call engineer for the affected service. The on-call engineer becomes the Incident Commander. For Severity 1 security incidents, the CISO is notified immediately regardless of the time of day. The CDO is notified for all Severity 1 incidents and for Severity 2 security incidents. The CEO is notified for any Severity 1 incident with customer impact or regulatory notification implications.
Regulatory Notification. Where an incident involves a confirmed data breach or a significant operational outage that affects regulated payment services, the CISO and CFO/General Counsel assess the regulatory notification obligations for each affected jurisdiction. Simpaisa is committed to meeting all mandatory notification windows; breach notification timelines are documented in the Data Protection Register by jurisdiction.
Post-Incident Review. Every Severity 1 and Severity 2 incident generates a Post-Incident Review (PIR) within five business days of resolution. The PIR documents the timeline of events, the root cause, the immediate remediation taken, and the action items to prevent recurrence. PIRs are written in a blameless style - the goal is systemic improvement, not individual accountability. PIRs are reviewed by the CTO and CISO, and action items are tracked in Jira with owners and deadlines. A summary of PIRs and open action items is presented to the TIS Committee quarterly.
16.10 Security Awareness and Training¶
All Simpaisa employees complete mandatory information security awareness training on joining the Group and annually thereafter. The training programme covers: the Simpaisa Information Security Policy and employees' obligations under it; phishing and social engineering recognition; password hygiene and MFA usage; acceptable use of corporate systems; data classification and handling; and the incident reporting procedure.
The Information Security Manager delivers targeted training for teams with elevated risk exposure: the DevOps and engineering teams receive secure development training covering OWASP Top 10 and common API security vulnerabilities; the NOC/SOC team receives incident handling and digital forensics training; finance and operations staff receive financial fraud and payment fraud awareness training.
Phishing simulation exercises are conducted by the InfoSec team on a quarterly basis. Results are reported to the CISO and used to identify individuals or teams requiring additional targeted training. Simpaisa does not name or penalise individuals who click simulated phishing links; the programme is designed to be educational rather than punitive. Persistent non-engagement with mandatory training modules is addressed through the performance management process.
Security awareness training records are maintained by the InfoSec team and are reviewed as part of the ISO 27001 internal audit.
Section 17: Financial Management¶
17.1 Finance Operating Model¶
The finance function is led by the Global Chief Financial Officer, Mohammad Mustafa (ACCA, ex-PwC), who is responsible for all aspects of financial management across the Simpaisa Group. This encompasses financial reporting, management accounts, budgeting and forecasting, treasury, statutory compliance, external audit coordination, and internal control. Mohammad Mustafa reports directly to the CEO, Yassir Pasha, with a functional reporting line to the Board's Audit and Risk Committee.
Simpaisa's finance operating model reflects the structure of a multi-entity, multi-currency fintech operating across nine jurisdictions, each with its own statutory reporting obligations, tax regime, and regulatory financial reporting requirements. The finance function is organised to manage the tension between the Group-level consolidation and planning view (required by the HoldCo board and investors) and the entity-level statutory and regulatory view (required by local regulators and auditors in each jurisdiction). These two views are maintained in parallel, with the Group consolidation prepared in US dollars and entity-level accounts prepared in local GAAP and/or IFRS as required by jurisdiction.
The CFO is supported by a finance team whose composition spans treasury, financial reporting, and accounts functions. The team structure, headcount, and role profiles are documented in Sections 5 and 6 of this Operating Model. The finance function is based primarily in Pakistan, where the largest operational entity (PublishEx Solutions PVT Limited) is domiciled, with financial reporting support for HoldCo and the Singapore entity coordinated centrally.
17.2 Chart of Accounts and Accounting Policies (IFRS)¶
Simpaisa prepares its Group consolidated financial statements in accordance with International Financial Reporting Standards (IFRS) as issued by the IASB. Entity-level accounts are prepared in accordance with applicable local GAAP where this diverges from IFRS, with reconciliation to IFRS maintained for Group consolidation purposes.
Chart of Accounts. The Group chart of accounts is structured to support both the consolidation and the management reporting requirements of the business. The top-level structure comprises: Assets (current and non-current), Liabilities (current and non-current), Equity, Revenue, Cost of Revenue, Operating Expenditure, and Other Income and Expense. Within this structure, accounts are segmented to provide visibility by entity, product line (Pay-Ins, Pay-Outs, Remittance), and geography. Intercompany balances are maintained in dedicated intercompany accounts to facilitate elimination on consolidation. The chart of accounts is maintained in the Group's accounting system and changes to the chart of accounts require approval from the CFO.
Key Accounting Policies. Revenue is recognised in accordance with IFRS 15 (Revenue from Contracts with Customers). Merchant Discount Rate revenue is recognised at the point of successful transaction completion, as this is the point at which the performance obligation is satisfied. FX conversion revenue - the spread earned on currency conversion - is recognised at the time the FX transaction is executed. Subscription and SaaS-component revenues are recognised over the contract period on a straight-line basis.
Financial instruments are classified and measured in accordance with IFRS 9. Client funds held in segregated accounts are not recognised as Simpaisa assets (see Section 18.5 for the safeguarding model). Leases are accounted for under IFRS 16; Simpaisa has office leases in Pakistan, Bangladesh, and UAE that give rise to right-of-use assets and lease liabilities.
17.3 Financial Planning and Budgeting¶
Annual Budget. The annual budget process is initiated in Q3 of each financial year for the following year. The CFO issues a budget preparation timeline and guidance note to all cost centre owners and country heads. Budget submissions are prepared at the entity level, incorporating revenue projections, headcount plans, operating cost assumptions, and capital expenditure requirements. The CDO is responsible for the technology and information security budget submissions, covering all headcount, infrastructure, software licensing, and security tooling costs across the technology organisation.
Consolidated budget submissions are reviewed by the CFO and presented to the CEO for approval. The approved budget is submitted to the Board for ratification at the relevant board meeting. Once approved, the budget becomes the financial performance baseline against which monthly actuals are compared. Material variances - defined as deviations greater than 10% of the line-item budget or greater than 5% of total operating expenditure - require a written variance explanation from the relevant cost centre owner.
Rolling Forecast. In addition to the annual budget, the finance team maintains a rolling 12-month forecast, updated monthly. The rolling forecast incorporates actuals to date and revised projections for the remainder of the forecast period, reflecting changes in trading conditions, headcount, and project timelines. The rolling forecast is the primary tool used by the CFO for liquidity planning and by the CEO for investor reporting.
Capital Allocation. Significant capital expenditure - defined as technology investments, regulatory licence fees, or other single-item commitments above a threshold agreed in the Delegation of Authority Matrix (Section 4) - requires a business case approved by the CFO and CEO before commitment. Technology capital expenditure is reviewed by the CDO before submission to the CFO.
17.4 Management Reporting and KPIs¶
Monthly Management Accounts. The finance team produces monthly management accounts within 15 business days of the month end. The management accounts comprise: a consolidated profit and loss account, a balance sheet, a cash flow statement, a variance analysis against budget and rolling forecast, and an entity-level P&L summary. The management accounts are reviewed by the CFO before presentation to the CEO and the Board.
Financial KPIs. The core financial KPIs reported monthly are: Gross Transaction Volume (GTV) by corridor and product; Net Revenue (GTV net of operator pass-through costs); Gross Profit (Net Revenue less direct cost of revenue including FX costs and settlement costs); Operating Expenditure by function; EBITDA; Cash and liquid assets; and Client funds in safeguarding accounts. The management accounts include a KPI dashboard page that presents these metrics with month-on-month and year-on-year comparatives.
Investor Reporting. The CFO prepares quarterly investor reports for distribution to the Board and, where required under shareholder agreements, to major shareholders. Investor reports include the financial KPI dashboard, an operational update covering payment volume, corridor performance, and product development milestones, and a treasury and cash position update.
17.5 Statutory and Regulatory Financial Reporting by Entity¶
Each Simpaisa entity has its own statutory and regulatory financial reporting obligations, driven by the jurisdiction in which it is incorporated and licensed. The finance function maintains a regulatory reporting calendar that tracks all filing deadlines across all entities, with responsibility assigned to a named team member for each filing.
Simpaisa Holdings PTE. Limited (Singapore). Annual statutory accounts filed with ACRA under the Companies Act 1967 and Singapore Financial Reporting Standards (SFRS). Annual tax return filed with IRAS. MAS regulatory returns filed in accordance with licence conditions as applicable.
PublishEx Solutions PVT Limited (Pakistan). Annual statutory accounts filed with SECP under the Companies Act 2017 and Pakistan GAAP (converging with IFRS). SBP regulatory returns filed monthly and quarterly covering payment transaction volumes, FX flows, and prudential metrics. Annual tax return filed with FBR.
Simpoysha BD Limited / Soft Tech Innovation PVT LTD (Bangladesh). Annual statutory accounts filed with RJSC (Bangladesh) under applicable Bangladesh company law. Bangladesh Bank regulatory returns covering payment transaction data and FX flows. Annual tax return with NBR.
Simpaisa Technologies LTD (UAE). Annual statutory accounts filed in accordance with UAE Commercial Companies Law and applicable free zone regulations. VAT returns filed with FTA quarterly. Central Bank of UAE regulatory returns as required under the applicable payment services licence.
Commerce Plex Limited (UK). Annual statutory accounts filed with Companies House under the Companies Act 2006 and UK GAAP (FRS 102) or IFRS as applicable. Annual tax return with HMRC. FCA regulatory returns as required under the applicable permission.
Simpaisa CA LTD (Canada). Annual statutory accounts filed in accordance with the Canada Business Corporations Act and applicable provincial requirements. FINTRAC regulatory reporting as required under the Proceeds of Crime (Money Laundering) and Terrorist Financing Act. Corporate tax return with CRA.
Pay Nest PVT LTD (Nepal). Annual statutory accounts filed with OCR under Nepal company law. NRB regulatory returns as applicable to PSP partnership arrangements.
Iraq Branch Office. Regulatory financial returns to the Central Bank of Iraq as required under the branch licence conditions.
17.6 External Audit (PwC)¶
Simpaisa's external auditor is PricewaterhouseCoopers (PwC). PwC conducts the statutory audit for the Pakistan entity (PublishEx Solutions PVT Limited) and the Singapore HoldCo (Simpaisa Holdings PTE. Limited). Audited accounts for PublishEx are available for financial years FY17 through FY22. Audited accounts for the HoldCo are available for FY23 and FY24.
The CFO is the primary management contact for the external audit engagement. The audit timetable is agreed with PwC in advance of each financial year end, with fieldwork typically commencing within four to six weeks of year end and draft accounts delivered within twelve weeks. The Audit and Risk Committee of the Board oversees the external audit relationship, receives the audit management letter, and approves the audited accounts before they are formally adopted.
Audit fees are approved by the Audit and Risk Committee. The selection and reappointment of the external auditor is a Board-level decision, informed by the Audit and Risk Committee's assessment of audit quality, independence, and fee level. Where new entities require audit appointments, the preference is to appoint PwC or another Big Four firm with presence in the relevant jurisdiction, to maintain consistency of audit standards across the Group.
The management letter produced by PwC at the conclusion of each audit identifies any internal control weaknesses or accounting matters observed during the audit. The CFO prepares a management response to each point in the management letter, with remediation actions and timelines. The management response is reviewed by the Audit and Risk Committee and tracked to completion.
17.7 Internal Audit¶
Internal audit provides independent assurance to the Audit and Risk Committee and the CEO on the effectiveness of Simpaisa's internal controls, risk management processes, and governance arrangements. The scope of internal audit covers financial controls, operational processes, compliance with policies and procedures, and - in coordination with the CISO - information security controls.
The internal audit plan is approved annually by the Audit and Risk Committee and is risk-based: higher-risk areas (payment processing controls, FX management, client funds safeguarding, regulatory compliance) receive more frequent audit attention than lower-risk routine functions. Internal audit findings are classified by severity and reported to the Audit and Risk Committee. Management responses and remediation timelines are agreed for each finding and tracked to completion.
As Simpaisa reaches the scale where a dedicated internal audit function is warranted, the Audit and Risk Committee will determine whether to establish an internal team or to co-source with an external firm. In the interim, selected internal audit activities may be performed by the CFO's team or by the external auditor on a non-audit-independence basis, with appropriate safeguards.
Section 18: Treasury and Cash Management¶
18.1 Treasury Operating Model¶
The treasury function operates as an integral part of the finance organisation under the Global CFO. It is responsible for managing Simpaisa's liquidity, optimising the Group's bank account structure, executing and hedging foreign exchange transactions, maintaining the separation of client funds from corporate funds, and ensuring that settlement obligations to merchants are met on time in accordance with contractual terms.
Given the nature of Simpaisa's business - high-volume, multi-currency, cross-border payment flows in frontier markets - the treasury function is operationally complex and carries significant risk if not managed with precision. The four primary currencies handled (PKR, BDT, NPR, IQD) are illiquid by global standards, subject to capital controls, and exhibit volatility that can materially affect the economics of individual settlement runs. Treasury discipline is therefore a core operational competence, not a back-office support function.
The CFO has overall accountability for treasury. Day-to-day treasury operations are managed by the treasury team, with decisions above defined thresholds (single FX transactions above a specified size, new bank account openings, changes to banking partners) requiring CFO approval. Decisions above the CFO's delegated authority require CEO approval.
18.2 Bank Account Structure (Multi-Entity, Multi-Currency)¶
Simpaisa maintains a network of bank accounts across its operating jurisdictions, structured to serve three purposes: holding operational corporate funds, receiving and disbursing client funds through the payment processing cycle, and maintaining the statutory minimum capital or reserve balances required by regulators in licensed jurisdictions.
Account governance. All bank accounts are opened in the name of the relevant Group entity. No bank accounts are opened in the name of a third party on Simpaisa's behalf, nor does Simpaisa use third-party accounts to hold client or corporate funds without explicit board approval and regulatory notification where required. New bank accounts require approval from the CFO and are recorded in the bank account register maintained by the treasury team. Signatories on each account are defined in accordance with the Delegation of Authority Matrix; dual signatories are required for all payment instructions above the defined threshold.
Pakistan. PublishEx Solutions PVT Limited maintains multiple Pakistani Rupee accounts with commercial banks for operational funds and settlement float, and a Foreign Currency Account (FCA) for USD receipts from international merchants. Banking relationships in Pakistan include relationships with SBP-approved commercial banks capable of processing 1LINK/1Bill and IBFT transactions within the required settlement windows.
Bangladesh. Simpoysha BD Limited and aamarPay maintain BDT accounts for operational funds, Pay-In collections float, and outbound disbursement float. Bangladesh Bank's regulations on foreign currency holding and repatriation govern the FX structure of the Bangladesh accounts.
UAE, UK, Canada, Singapore, Nepal, Iraq. Each entity maintains accounts appropriate to its operational scope. The UAE entity, once licensed, will require accounts capable of holding and disbursing in AED and USD. The UK entity maintains GBP accounts for operational costs. Canada maintains CAD and USD accounts for MSB operations. Singapore maintains USD and SGD accounts for HoldCo treasury operations, including investor proceeds management.
18.3 FX Management (Frontier Currencies: PKR, BDT, NPR, IQD)¶
Simpaisa's revenue model creates a structural FX exposure: the company collects funds from consumers in local currencies (PKR, BDT, NPR, IQD) and settles with merchants in hard currencies (USD, EUR), or vice versa in the case of inbound remittances. The spread between the buy rate at which Simpaisa acquires local currency and the sell rate at which it converts to hard currency forms a component of the company's revenue; managing this spread efficiently is a treasury function with direct P&L impact.
PKR. Pakistani Rupee is Simpaisa's highest-volume currency and the one carrying the most significant FX risk given the rupee's historical volatility and the SBP's periodic interventions in the interbank market. Treasury maintains a pre-agreed FX rate validity window with banking partners for quoting merchant settlement rates. Rates are refreshed at intervals defined in the merchant agreement - typically daily for standard merchants and intraday for high-volume clients. Open PKR positions - i.e., PKR funds collected but not yet converted - are monitored in real time and hedged where cost-effective instruments are available. The SBP's regulations on currency conversion and repatriation are followed without exception; any material change in SBP FX policy is escalated to the CFO and CEO immediately.
BDT. Bangladesh Taka is managed under Bangladesh Bank's regulated FX regime. Conversion of BDT proceeds to USD for merchant settlement is executed through authorised dealer banks. The treasury team monitors the BDT/USD spot rate against the rate assumed in the management accounts and reports variances to the CFO monthly.
NPR. Nepalese Rupee is managed under the Nepal Rastra Bank's FX regulations, which include restrictions on convertibility and repatriation. Given that Simpaisa operates through PSP partnerships in Nepal rather than through a locally licensed entity, the FX exposure is partially mitigated: partner PSPs handle collections in NPR and remit settlement to Simpaisa in a convertible currency per the partnership agreement. Treasury monitors the effective conversion rate received from partners to ensure it remains within acceptable bounds.
IQD. Iraqi Dinar operations are at an early stage, with the Iraq branch in development. The CBI's FX management framework includes a USD auction mechanism that affects the effective IQD/USD conversion rate. As Iraq operations scale, the treasury team will develop a specific IQD FX management protocol in consultation with the CFO and local banking partners.
18.4 Cash Flow Forecasting and Liquidity¶
The treasury team produces a 13-week rolling cash flow forecast, updated weekly, for each entity. The forecast captures expected inflows from merchant settlements due, FX conversions planned, and intercompany receipts; and expected outflows covering operating costs, payroll, disbursement float requirements, regulatory capital top-ups, and debt service if applicable. The 13-week view is complemented by a 12-month liquidity model updated monthly and presented to the CFO.
Liquidity risk is managed by maintaining a minimum cash buffer in each entity sufficient to cover a defined number of weeks of operating expenditure, excluding client funds. The minimum buffer for each entity is set by the CFO, informed by the volatility of that entity's cash flows and the lead time required to access additional liquidity if needed. Entities approaching their minimum buffer trigger an immediate CFO review and, if necessary, intercompany lending or capital injection from the HoldCo.
Simpaisa's investors - having provided $90 million in funding closed by the CFO - have funded the Group's growth capital. The treasury function ensures that investor capital is deployed efficiently, with idle corporate cash placed in low-risk, short-duration instruments where the regulatory framework permits. The CFO reports the Group's cash position and runway to the Board quarterly.
18.5 Client Funds Segregation and Safeguarding¶
Simpaisa holds client funds in the course of processing payment transactions - funds collected from consumers on behalf of merchants, and funds received from merchants for disbursement to recipients. These funds do not belong to Simpaisa and are subject to legal and regulatory safeguarding requirements in jurisdictions where Simpaisa holds a payment services licence.
Safeguarding model. Client funds are held in designated safeguarding accounts, separate from Simpaisa's corporate operating accounts. Safeguarding accounts are held with regulated credit institutions and are structured such that, in the event of Simpaisa's insolvency, the funds in those accounts are protected for the benefit of the clients to whom they belong. The treasury team performs daily reconciliation of safeguarding account balances against the sum of client funds owed, confirming that no shortfall exists. Any discrepancy identified in the daily reconciliation is escalated to the CFO immediately.
Regulatory requirements. In the UK, safeguarding requirements under the FCA's Payment Services Regulations 2017 apply to Commerce Plex Limited. In Canada, MSB licensing requirements under FINTRAC govern fund handling. In Pakistan, the SBP's Payment Systems Operator and Payment Service Provider regulations govern the treatment of client funds held by PublishEx. Each licensed entity maintains safeguarding arrangements compliant with the applicable regulatory framework, documented in the treasury procedures manual and reviewed as part of the annual internal audit programme.
18.6 Settlement Execution¶
Settlement execution is the operational process by which Simpaisa pays merchants the net proceeds of their transactions, after deduction of MDR and any applicable FX conversion. Settlement is executed by the treasury team, with payment instructions generated by the settlement engine (described in Section 15.2) and reviewed by treasury before release.
Settlement process. The settlement engine produces a daily settlement batch report for each merchant, detailing the gross transaction volume settled, MDR deducted, FX conversion applied, and net settlement amount due. The treasury team reviews the batch report for anomalies - unusual volume spikes, FX conversion rates outside the expected range, merchants not previously seen - before approving the payment run. Payment instructions are submitted to the relevant banking partner for execution. Merchants receive a settlement confirmation and a detailed settlement report through the merchant portal.
Timing and currency. Settlement timing and currency denomination are defined in each merchant's Master Payment Services Agreement. Standard settlement is T+1 or T+2 business days from the transaction date for most corridors. Merchants on high-volume agreements may be offered daily or real-time settlement for an additional fee. Settlement is denominated in USD or EUR by default, with local currency settlement available for selected merchants in specific corridors where the regulatory framework permits.
Failed settlements. Where a settlement payment fails - due to incorrect beneficiary bank details, a correspondent bank rejection, or a temporary banking system outage - the treasury team investigates and reattempts within one business day. Persistent settlement failures are escalated to the Account Management team to engage the merchant directly. All failed and reattempted settlements are logged in the settlement reconciliation system.
Section 19: People Strategy and HR Operations¶
19.1 People Strategy (Scale-Up Phase, 180 Employees, Multi-Country)¶
Simpaisa is a fintech business in an active scale-up phase. With 180 employees across nine entities and nine countries, the People strategy must address the dual challenge of building organisational capability fast enough to support commercial growth whilst maintaining the cultural cohesion and operational rigour demanded by regulated financial services.
The People strategy is anchored on three priorities. First, talent acquisition at pace: Simpaisa is hiring across technology, compliance, product, and commercial functions to support geographic expansion into UAE, Saudi Arabia, and broader MENA, and to deepen capability in the existing corridor markets. The organisation must attract experienced professionals who combine payments domain knowledge with the ability to operate in fast-moving, ambiguous environments. Second, capability development: as the team grows, structured development programmes must ensure that knowledge is transferred, internal mobility is possible, and leaders at all levels are equipped to manage larger, more complex teams. Third, culture and retention: Simpaisa's workforce is genuinely multi-cultural - spanning Pakistan, Bangladesh, Nepal, Iraq, Singapore, UAE, Canada, and the UK - and the culture must actively leverage this diversity as a commercial and operational advantage rather than treating it as a compliance obligation. Retaining high performers in a competitive fintech labour market requires competitive compensation, meaningful work, and a culture of recognition and growth.
People strategy is the responsibility of the COO organisation, with HR operations managed under the COO. The CDO has joint accountability for the People strategy as it applies to the technology, product, and security organisations, given the scale of the technical workforce (38 in technology, 13 in the CISO organisation) and the strategic importance of technical talent.
19.2 Recruitment and Onboarding¶
Recruitment. Simpaisa recruits through a combination of direct sourcing (LinkedIn, referrals), specialist fintech and technology recruitment firms, and in-country job boards where applicable. For senior roles (Head of function and above), the preferred approach is a structured search with a specialist recruiter, with a defined role brief, competency framework, and structured interview process. For mid-level and junior roles, direct sourcing and employee referrals are the primary channel, supplemented by job boards for volume hiring.
Every role has a defined job description before recruitment commences, specifying the reporting line, key responsibilities, required qualifications and experience, and - where relevant - the regulatory fitness and propriety requirements applicable to the role (see Section 19.8). Compensation bands are set before the role is opened, with the CFO and relevant functional head agreeing the band as part of headcount approval.
Interview processes are structured around a competency framework: each candidate is assessed against defined role competencies using behavioural questions, and interviewers record structured notes in the ATS. Hiring decisions are made by the hiring manager with input from the panel, and are documented. Offers are issued by HR on the authorised compensation template; verbal offers are not extended before HR has reviewed and confirmed the package is within approved parameters.
Onboarding. All new joiners complete a structured onboarding programme. This comprises: pre-joining documentation (contracts, background verification, regulatory fitness checks as applicable), a Day 1 corporate induction covering Simpaisa's business, culture, policies, and compliance obligations, role-specific technical onboarding managed by the hiring manager and team, IT system access provisioning as described in Section 16.8, and mandatory compliance training including anti-money laundering, sanctions awareness, and information security (Section 16.10). The first 30 days are structured with defined milestones; at day 30 the hiring manager conducts a formal check-in to confirm the new joiner is integrating effectively and any concerns are addressed early.
19.3 HR Operations and Employee Lifecycle¶
HR operations cover the full employee lifecycle from offer to exit, including employment contracts, payroll, benefits administration, leave management, disciplinary and grievance procedures, and employment law compliance by jurisdiction.
Employment contracts. Employment contracts are issued on entity-specific templates that reflect the applicable local employment law for each jurisdiction. Contract templates are reviewed by local legal counsel annually and when material changes occur in local employment legislation. All contracts are issued in English; where the local jurisdiction requires a contract in the local language, a bilingual contract is used.
Payroll. Payroll is processed monthly for all entities. The payroll process is managed by the HR and finance teams, with payroll calculations prepared by HR and reviewed by Finance before payment is released. Payroll sign-off requires dual authorisation - HR manager and CFO (or delegate) - before payment is submitted to the bank. All statutory deductions (income tax, social contributions, provident fund where applicable) are correctly calculated and filed with the relevant authority on the schedule required by local law.
Leave management. Annual leave entitlements are defined in each entity's employment contract and comply with local statutory minimums. Leave balances are tracked in the HR system and reported to managers monthly. Untaken leave accruals are managed in accordance with local legal requirements; where carry-forward is limited by local law, employees are actively encouraged by their managers to take leave within the entitlement year.
Disciplinary and grievance. Simpaisa maintains a disciplinary and grievance procedure that is fair, consistent, and compliant with applicable local employment law. All formal disciplinary actions are documented and reviewed by HR before any action is taken. The employee has the right to be accompanied at formal disciplinary meetings. Where a disciplinary outcome results in dismissal, the applicable notice period or payment in lieu is provided in accordance with the contract and local law. Grievances are investigated promptly and impartially, with the outcome communicated to the employee within a defined timeline.
19.4 Compensation and Benefits¶
Compensation philosophy. Simpaisa's compensation approach is to pay at or above market median for defined roles in each operating market, with additional upside through variable pay and - at executive level - equity. The aim is to be competitive enough to attract and retain the talent required without creating unsustainable payroll cost growth. Compensation benchmarking is conducted annually using available market data sources for each of the company's primary hiring markets.
Salary structures. Salaries are denominated in local currency for employees employed by local entities, and in USD or GBP for employees in the Singapore and UK entities respectively. Annual salary reviews are conducted as part of the performance management cycle (see Section 19.6). Increases are funded from the salary review budget approved by the CFO and are distributed based on individual performance ratings and positioning within the compensation band for the role.
Variable pay. Sales and revenue-generating roles carry variable compensation structured as a commission or bonus linked to defined commercial KPIs - transaction volume, new merchant signings, corridor revenue. For non-commercial roles, a discretionary annual bonus pool is available at the company's discretion, based on Group financial performance and individual contribution. Bonus payments are not contractually guaranteed; they are discretionary and are not paid in years where the Group does not meet its financial performance threshold.
ESOP. An Employee Share Option Plan (ESOP) is in place for executive-level employees only. ESOP participants are C-suite members and a small number of senior leaders approved by the Remuneration and Nomination Committee. Options vest over a four-year period on a standard cliff-and-ramp schedule (one-year cliff, monthly vesting thereafter). The ESOP terms, option price, and pool size are governed by the ESOP rules approved by the Board. ESOP eligibility is not extended below executive level at this stage; as the company scales and approaches a liquidity event, wider employee participation will be reviewed by the Board.
Benefits. Benefits provision varies by entity and jurisdiction to reflect local market practice and statutory requirements. Core benefits provided across all entities include: employer-provided or employer-subsidised health insurance for employees and (where market practice) dependants; statutory pension, provident fund, or equivalent retirement savings contributions as required by local law; and paid annual leave at or above the local statutory minimum. In Pakistan, the largest entity, benefits also include gratuity provision in accordance with the Gratuity Act. Additional benefits - travel allowances, mobile phone allowances, and professional development funding - are provided where market practice and business case support them.
19.5 Learning and Development¶
Philosophy. Simpaisa invests in the development of its people as a strategic priority, not as a discretionary cost. In a payments fintech operating across complex regulatory environments with a rapidly evolving technology stack, the capability of the team is a direct determinant of competitive performance. Development investment is therefore budgeted annually and allocated across three categories: technical skills, regulatory and compliance knowledge, and leadership and management capability.
Technical development. Engineers and DevOps staff have access to online learning platforms (e.g., Pluralsight, Udemy for Business, or equivalent) for self-directed technical learning. Certification support - covering AWS, Cloudflare, Kubernetes, and security certifications such as CISSP, CEH, and CompTIA Security+ - is funded by the company for roles where the certification directly supports the individual's current or intended role. Certification attainment is recognised in the performance review cycle.
Regulatory and compliance training. Annual mandatory training is supplemented by role-specific compliance education for staff in regulated functions: AML and CFT refresher training, PCI DSS awareness for staff with CDE access, GDPR and data protection for staff handling personal data, and sanctions screening procedure training for operations staff using Eastnets. Training is tracked and completion records are maintained by HR.
Leadership development. As Simpaisa grows its management layer, structured leadership development becomes increasingly important. Team leads and development managers are supported through a combination of external management development programmes, mentoring by senior leaders, and access to coaching where appropriate. The CDO specifically coaches the CTO and CISO, both of whom lead significant technical organisations.
Succession planning. The HR function, in conjunction with the CEO and functional heads, maintains a succession plan for critical roles - those where an unexpected departure would create significant operational or regulatory risk. Succession plans identify internal candidates who could step up with development support, and inform individual development plans for those candidates. The succession plan is reviewed annually.
19.6 Performance Management (Transitioning from Annual to OKR-Based)¶
Simpaisa is in the process of transitioning its performance management approach from an annual appraisal cycle to a more continuous model based on Objectives and Key Results (OKRs).
Current state. Annual performance reviews are conducted at the end of each financial year. Reviews are structured against defined role objectives set at the beginning of the year, with a rating on a defined scale used to inform salary review and bonus decisions. Reviews are completed in the HR system, which maintains a record of objectives, ratings, and manager commentary. All employees receive a formal written review.
Target state. The OKR model sets objectives at three levels - company, team, and individual - on a quarterly cadence. Each objective is accompanied by measurable key results that define what success looks like. OKRs are set by individuals in dialogue with their managers, reviewed at the start of each quarter, and progress is assessed mid-quarter and at the end of the quarter. The quarterly OKR cycle replaces the need for a large annual review process; the annual review is retained but becomes a synthesis of four quarterly conversations rather than a point-in-time assessment.
Transition approach. The transition to OKRs is being piloted in the technology organisation in H1 2026, starting with the CTO's leadership team and cascading to team leads. The pilot will be evaluated and, if successful, extended to other functional areas. HR is responsible for tooling, training managers to write effective OKRs, and ensuring the process does not create administrative burden disproportionate to its value. The CDO is sponsoring the OKR transition across technology and product.
Performance improvement. Where an employee's performance is consistently below the standard required for their role, a structured Performance Improvement Plan (PIP) is implemented. The PIP sets clear, measurable objectives for improvement over a defined period (typically 60–90 days), with regular manager check-ins and HR oversight. The outcome of the PIP may be continued employment, role change, or, where performance does not improve to the required standard, termination in accordance with local employment law.
19.7 Culture and Engagement (Multi-Cultural: PK, BD, NP, IQ, SG, UAE, CA, UK)¶
Simpaisa's workforce spans eight nationalities and cultures across nine countries. This diversity is a genuine operational asset - it enables the company to build deep local knowledge in each corridor market, to communicate authentically with local partners and regulators, and to design payment experiences that reflect the actual behaviour of consumers in those markets rather than a generic assumption. Managing this diversity well, however, requires deliberate effort in how the company communicates, makes decisions, resolves conflict, and builds a shared sense of identity.
Shared values. Simpaisa's culture is grounded in a set of values - reflecting integrity, customer focus, commercial ambition, and continuous improvement - that are communicated consistently across all markets. Values are embedded in the onboarding process, referenced in the performance management framework, and demonstrated by the leadership team in their own conduct. Where individual cultural values create friction with Simpaisa's organisational values (for example, where hierarchy norms in some cultures create barriers to speaking up about problems), the leadership team actively models the behaviour it expects rather than relying on policy statements alone.
Communication. The working language across the Group is English. All corporate communications, policies, and documentation are in English. In markets where the local team operates primarily in another language - Urdu in Pakistan, Bengali in Bangladesh, Nepali in Nepal, Arabic in Iraq - local managers are expected to ensure that all employees have sufficient understanding of corporate communications to operate effectively. Where a significant proportion of a local team has limited English, key operational materials are translated or summarised in the local language by the local manager.
Engagement. Employee engagement is assessed annually through an engagement survey administered by HR. Survey results are reported to the CEO and functional heads, with team-level results shared with team managers. Action plans are developed in response to engagement survey findings, with progress reviewed at the mid-year point. The engagement survey covers: satisfaction with role and growth opportunities, confidence in leadership, clarity of direction, quality of relationships with colleagues and managers, and perception of recognition and fairness.
Social and religious considerations. Simpaisa's workforce includes a significant majority of Muslim employees, predominantly in Pakistan, Bangladesh, Iraq, and UAE. The company respects Islamic practices relevant to the workplace: prayer time accommodation, observance of Eid and other Islamic public holidays in the relevant markets, and - where the company itself is designing financial products - the strategic interest in ensuring that products are compatible with Islamic finance principles where the market requires it. The working week in Pakistan follows a Monday-to-Friday schedule aligned with the SBP working week, whilst the UAE entity will follow the UAE's Monday-to-Friday working week.
19.8 Fit and Proper Requirements for Regulated Roles¶
Several roles within Simpaisa are subject to formal fit and proper requirements imposed by financial regulators in the jurisdictions where the Group holds licences. These requirements apply to Board members, executive directors, and individuals who fulfil defined regulatory functions (such as Money Laundering Reporting Officer, Compliance Officer, or Chief Financial Officer in a licensed entity).
Regulatory scope. The fit and proper frameworks most relevant to Simpaisa at present are those of the SBP (Pakistan), Bangladesh Bank, the FCA (UK), FINTRAC (Canada), and - on authorisation - the Central Bank of UAE. Each framework specifies the criteria against which an individual must be assessed: honesty, integrity, and reputation; competence and capability; financial soundness; and, in some jurisdictions, educational and professional qualifications relevant to the role.
Pre-appointment process. Before an individual is appointed to a role that requires regulatory approval or notification, HR and the relevant functional head assess the individual's fitness against the applicable regulatory criteria. This includes: enhanced background verification (criminal record check, credit check, reference verification, sanctions screening); review of the individual's professional qualifications and track record; and, where required by the regulator, preparation and submission of a regulatory application or notification with supporting documentation. No individual is appointed to a regulated role before the regulatory approval or notification process has been completed, unless the regulatory framework allows for a provisional appointment with notification within a defined period.
Ongoing fitness. Fit and proper status is not assessed only at appointment. HR maintains a process for monitoring the ongoing fitness of individuals in regulated roles: any material change in an individual's circumstances - such as a criminal conviction, a significant adverse credit event, or a regulatory sanction in another jurisdiction - must be reported to HR and the CISO/CFO/General Counsel (as applicable to the nature of the event) for assessment of whether the individual remains fit and proper for their role. Failure to disclose a material change in personal circumstances is treated as a serious disciplinary matter.
Register. HR maintains a register of all roles within the Group that carry fit and proper requirements, the applicable regulatory framework, the current post-holder, the date of regulatory approval or notification, and any conditions attached to the approval. The register is reviewed quarterly and submitted to the relevant Board committee annually.
End of Sections 15–19
Document Control
| Field | Detail |
|---|---|
| Document Title | Simpaisa Group Operating Model - Sections 15–19 |
| Version | 0.1 |
| Date | April 2026 |
| Author | Chief Digital Officer |
| Approved by | Pending |
| Next Review | April 2027 |
| Classification | Confidential - Internal Use Only |