Simpaisa Group Operating Model¶
Supplementary Documents 2: API Developer Portal, Data Architecture, Competitive Intelligence, and ESG¶
Version 0.1 | April 2026¶
Document Owner: Chief Digital Officer¶
Supplementary Document A: API Developer Portal Operating Model¶
A.1 Purpose and Strategic Rationale¶
Simpaisa's commercial proposition depends on merchants and partners being able to integrate quickly, confidently, and independently. The API Developer Portal is the primary mechanism through which that integration experience is delivered. Its purpose is to enable self-service integration: a merchant's development team should be able to move from portal registration to a successful sandbox transaction without requiring direct engagement from Simpaisa's technical staff, and from sandbox validation to a first live transaction within a defined, measurable timeframe.
This is not merely a documentation objective. The Developer Portal is a product in its own right, with its own operating model, quality standards, and success metrics. As Simpaisa expands into Saudi Arabia, MENA, and Central Asia, the Developer Portal becomes increasingly important as a scalable, always-on integration resource that operates across time zones and languages without incremental headcount.
The Developer Portal is owned by the Chief Digital Officer and operated jointly by the Technology and Product functions, with the Product team owning content standards and the Technology team owning platform availability, security, and sandbox infrastructure.
A.2 Portal Components¶
API Reference (OpenAPI Specification). The API reference is the canonical technical documentation for every endpoint exposed by the Simpaisa platform. It is generated directly from the OpenAPI 3.0 specification files maintained in Bitbucket alongside the gateway codebase, ensuring that documentation is never manually decoupled from the implementation it describes. The reference is structured by product line - Pay-Ins, Pay-Outs, Remittances, Crypto Off-Ramp, and White-Label Wallet - and within each product by resource type and operation. Every endpoint entry includes the full request schema, all required and optional parameters with type and format annotations, example request bodies, all possible response codes and their corresponding response schemas, and a worked example in at least two languages. The spec is versioned in lockstep with the API versioning scheme described in Section A.5.
Sandbox Environment. The sandbox is an isolated environment that mirrors the production API surface in full, including authentication mechanisms, rate limiting behaviour, response schemas, and webhook delivery. The critical distinction is that all payment instructions submitted to the sandbox are routed to a simulated operator layer: no real funds move, no real operator systems are called, and no real regulatory transaction records are created. The sandbox supports a configurable set of simulation scenarios, accessible via a control parameter in the request header. Supported scenarios include: immediate success with configurable settlement delay, immediate decline with configurable decline reason codes, operator timeout and retry behaviour, partial completion (for batch pay-out operations), and webhook delivery failure with retry simulation.
Sandbox environments are provisioned automatically on merchant onboarding. When a merchant completes the KYB process and is approved, a sandbox API key pair and a corresponding sandbox merchant profile are created without manual intervention from the Technology team. Merchants can begin technical integration immediately upon KYB approval, without waiting for commercial terms to be finalised.
Code Samples. The Developer Portal includes working code samples in four languages: Java, Node.js, Python, and PHP. These represent the languages most commonly used by Simpaisa's merchant base across its active markets. Each sample covers the full integration lifecycle: authentication and request signing, a basic payment initiation request, handling synchronous and asynchronous responses, receiving and validating webhook notifications, and a worked reconciliation example. Code samples are maintained by the Technology team and updated on each API version release. Samples are published under an open-source licence and may be reproduced freely by merchants.
Webhook Testing Tool. Merchants integrating Simpaisa's notification system can use the webhook testing tool to validate their endpoint behaviour before go-live. The tool allows a merchant to submit a test webhook delivery to a nominated URL, inspect the delivery response, simulate retry behaviour for failed deliveries, and view the full delivery log including headers and payload. The testing tool is built into the portal interface and does not require command-line access or API calls.
Status Page. A publicly accessible status page displays real-time and historical availability data for all platform components: the payment gateway, processing engine, merchant portal, sandbox environment, and partner API surface. Status is updated in real time from the monitoring layer; incidents are posted as they are detected, with updates on investigation progress and resolution. The status page also displays scheduled maintenance windows. Merchants and partners may subscribe to status page notifications via email or webhook.
Changelog. A versioned changelog is published for every API release, including patch releases. Changelog entries are classified as: new feature (additive change that does not break existing integrations), enhancement (improvement to existing behaviour with no breaking change), deprecation notice (advance notice of a forthcoming breaking change), or breaking change (change that requires integrator action). Breaking changes are only ever published under the deprecation policy described in Section A.5 and are accompanied by a migration guide.
A.3 Documentation Standards¶
Every endpoint in the API reference must meet the following standards before it is published. These standards apply equally to new endpoints and to updates to existing endpoints.
Each endpoint must carry a plain-language description of what the endpoint does, when it should be called, and what the caller should expect in response. Technical jargon should be minimised; descriptions are written for a mid-level software engineer unfamiliar with Simpaisa's internal architecture. Where an endpoint has constraints or preconditions - for example, that a merchant must have completed a specific KYB step before the endpoint is accessible, or that a request must include a specific header when operating in a particular corridor - those constraints must be stated explicitly.
All request parameters must be documented with their data type, format (where applicable, such as ISO 4217 for currency codes, E.164 for phone numbers, ISO 8601 for timestamps), valid value ranges, whether the parameter is required or optional, and the behaviour when an optional parameter is omitted.
All response schemas must be documented, including all possible error response schemas. Error responses must include the HTTP status code, the Simpaisa error code, a human-readable error message, and guidance on the corrective action available to the integrator. Simpaisa uses a consistent error code taxonomy across all products, prefixed by product area (e.g., PAY_IN_4001 for a Pay-In authentication failure).
Rate limits must be stated per endpoint where they differ from the platform default, or the default rate limit must be referenced. Endpoints with burst allowances must document the burst limit and the reset window separately from the sustained rate limit.
Documentation is reviewed by the Product Manager responsible for the relevant product line before publication. The review confirms technical accuracy, completeness against this standard, and consistency with any related merchant-facing communications.
A.4 Sandbox Management¶
The sandbox environment is managed by the DevOps and Database team as a distinct infrastructure stack, provisioned and maintained independently of the production environment. It shares no databases, message queues, or compute resources with production. Configuration is managed through the same infrastructure-as-code toolchain used for production (Terraform and Ansible), ensuring that sandbox configuration can be replicated and that drift from the production architecture is identified during regular configuration audits.
The sandbox mirrors production operator integrations through a simulation layer. Each production operator integration (mobile wallet, banking rail, crypto off-ramp provider) has a corresponding sandbox simulation that replicates the response behaviour, including known edge cases such as delayed responses, duplicate transaction IDs, and inconsistent state between payment status and settlement confirmation. Simulations are updated when operator integrations are updated in production to maintain fidelity.
Sandbox data is isolated at the tenant level: a merchant's sandbox transactions, keys, and profile data are not accessible to any other merchant. Sandbox API keys are clearly identified in the portal and carry a prefix (sk_sandbox_) that distinguishes them programmatically from production keys (sk_live_). No action taken in the sandbox - including key rotation, webhook configuration changes, or test transaction submission - has any effect on the merchant's production environment.
Sandbox environments are subject to a data retention policy: sandbox transaction records are retained for 90 days and then purged. Merchants performing long-running integration projects should export any sandbox data they wish to retain before the 90-day window closes. The portal displays a retention countdown for sandbox transaction records.
A.5 Versioning Policy¶
Simpaisa's API versioning follows semantic versioning principles adapted for REST APIs. Version numbers are expressed in URI paths as /v{major}/ (e.g., /v1/, /v2/). Minor and patch changes within a major version are non-breaking and do not require a URI version increment.
A breaking change is defined as any change that could cause a correctly implemented existing integration to fail or produce incorrect results. Breaking changes include: removal of an endpoint, removal of a required or optional field from a response schema, change to the data type or format of an existing field, change to the authentication mechanism, and change to the error code taxonomy that would cause error-handling logic to mismatch. Additive changes - new optional fields in response schemas, new optional parameters in requests, new endpoints - are not breaking changes and do not trigger a version increment.
When a new major version (N) is released, the prior major version (N-1) enters a 12-month deprecation period. During this period, both N and N-1 are fully supported, receive bug fixes, and are documented on the Developer Portal. At the end of the 12-month period, N-1 is sunset: the endpoints are removed and requests to N-1 paths return a 410 Gone response with a migration guidance message. No version earlier than N-1 is supported at any time; merchants running integrations against N-2 or older must migrate before N-1 is sunset.
Deprecation notices are issued with a minimum of 12 months' advance notice via the changelog, via email to all registered developers with active integrations on the affected version, and via an in-portal banner. Where a breaking change is driven by a regulatory or security obligation, the deprecation period may be shortened; in such cases, a minimum of 90 days' notice is given and the reason for the accelerated timeline is stated explicitly in the deprecation notice.
A.6 Developer Support Model¶
Community Forum. The portal includes a moderated community forum where developers can post integration questions, share code patterns, and discuss product updates. The forum is monitored by members of the Technology team on a best-efforts basis during business hours (UAE time). Forum responses do not carry a formal SLA but a response within one business day is the operational target. Forum content is indexed and searchable, and frequently asked questions are promoted to a curated FAQ section.
Ticket System. Developers encountering technical issues in the sandbox or the portal can raise a support ticket through the portal interface. Tickets are triaged by the Developer Support function (a shared responsibility between Product and Technology operations) and classified by severity. Severity 1 tickets - sandbox environment outages or complete integration blockers - carry a 4-hour response SLA. Severity 2 tickets - partial sandbox failures, documentation discrepancies, or integration guidance queries - carry a 1 business day response SLA. All tickets are resolved or escalated within 3 business days. SLA performance is tracked monthly and reported to the CDO.
Technical Account Management (TAM) for Tier 1 Merchants. Merchants classified as Tier 1 (defined as those processing above a volume threshold set by the CRO, or those identified as strategically significant regardless of volume) are assigned a dedicated Technical Account Manager. The TAM serves as the merchant's primary technical contact throughout integration and go-live, provides bespoke integration guidance, coordinates across the Technology, Product, and Compliance teams on the merchant's behalf, and conducts a post-go-live technical review. TAMs are employees of the Technology function and report to the Head of Development. The TAM programme is governed by a service standard reviewed quarterly by the CDO and CRO jointly.
A.7 Success Metrics¶
The Developer Portal's performance is measured against four primary metrics, reviewed monthly by the CDO.
Time-to-First-Transaction (TTFT). Measured from the date a merchant's sandbox credentials are provisioned to the date of the first successful sandbox transaction. Target: median TTFT under 5 business days. Merchants who have not completed a first sandbox transaction within 14 business days are flagged for proactive outreach from the TAM or developer support team.
Sandbox Activation Rate. The percentage of onboarded merchants who complete at least one sandbox transaction within 30 days of credential provisioning. Target: above 80%. A low activation rate indicates friction in the portal onboarding experience or inadequate documentation coverage, and triggers a structured review of the onboarding journey.
Documentation Page Views and Feedback. Page view data is collected for all documentation pages. Each page carries a simple feedback mechanism (helpful / not helpful) with an optional free-text field. Pages with a negative feedback rate above 20% are reviewed and updated within one sprint of the threshold being crossed.
Support Ticket Volume. Monthly ticket volume, categorised by issue type. A rising ticket volume in any issue category is treated as a signal of a documentation or platform quality problem rather than a support resourcing problem, and triggers a root cause review. The target is a month-on-month decline in ticket volume as documentation coverage improves and the platform matures.
Supplementary Document B: Data Architecture¶
B.1 Current State Assessment¶
Simpaisa's data architecture reflects the pragmatic choices of a company that has grown rapidly across multiple markets, products, and technical contexts. The operational database estate is healthy and purpose-built: MySQL and PostgreSQL serve transactional and relational workloads with ACID guarantees; MongoDB and Amazon DocumentDB provide document storage for event logs, operator API responses, and session data. Each database is appropriately sized, multi-AZ replicated, and subject to regular DBA governance as described in Section 15.5 of the core operating model.
The gap is not in operational data management - it is in the analytical and intelligence layer above those operational systems. Simpaisa currently has no centralised data warehouse. Analytical queries run against read replicas of the operational databases, which creates three material problems: query performance contention even on read replicas, schema coupling between operational and analytical concerns, and the absence of a governed, consistent data model that spans multiple product lines and entities.
Dashboards and reporting are delivered through Looker and Metabase, both pointing at the read replicas. The quality of these dashboards is constrained by the absence of a transformation layer: metrics are calculated in the dashboard tool itself, leading to inconsistent definitions across dashboards (a single metric such as "gross payment volume" may be calculated differently in three different Metabase dashboards), no version control on metric logic, and no data quality validation between source systems and presentation layer.
The current state is sufficient for the organisation's needs at present but is not compatible with the analytical requirements of the next growth phase: real-time corridor economics optimisation, automated regulatory reporting, fraud model training, and the investor-grade data room that Simpaisa's next fundraising round will require.
B.2 Target Architecture¶
The target data architecture is designed around five principles: separation of operational and analytical concerns; a single governed data model for each domain; transformations managed as version-controlled code; self-service BI for business users; and data residency and governance compliance built in from the foundation.
Cloud Data Warehouse. The central component of the target architecture is a cloud data warehouse, with Snowflake and Google BigQuery as the primary evaluation candidates. Both platforms provide columnar storage optimised for analytical workloads, separation of compute and storage allowing cost-proportionate scaling, native support for semi-structured data (JSON) alongside relational data, and role-based access control that can be mapped to Simpaisa's data classification scheme. The selection between Snowflake and BigQuery will be completed by Month 3 of the implementation timeline, with the decision driven by a structured evaluation covering: total cost of ownership at Simpaisa's anticipated data volumes, integration maturity with dbt and Airflow, geographic data residency options relevant to Pakistan, Bangladesh, and DIFC regulatory requirements, and existing commercial relationships within the group's AWS-primary infrastructure estate.
dbt (Data Build Tool) for Transformations. All transformations from raw ingested data to analytical models will be implemented in dbt. dbt enforces software engineering disciplines on data transformation: transformations are written as SQL with a dependency graph, version-controlled in Bitbucket, subject to code review, and testable at the model level with data quality assertions. The transformation layer will implement a three-layer architecture within the warehouse: a staging layer (one-to-one mapping from source tables with minimal transformation), an intermediate layer (joining and conforming entities across sources), and a mart layer (business-facing metrics and dimensions). Metric definitions - including gross payment volume, net revenue, corridor yield, merchant health score components - will be codified in the mart layer as the single authoritative definition, eliminating the inconsistency present in the current dashboard estate.
Airflow for Orchestration. Apache Airflow will orchestrate all data movement and transformation workflows. Airflow provides a directed acyclic graph (DAG) model for defining pipeline dependencies, a rich operator library for interacting with AWS services, the warehouse, and external APIs, and a UI for monitoring pipeline execution and diagnosing failures. Airflow DAGs will be version-controlled in Bitbucket. For the initial implementation, Airflow will be deployed on AWS ECS (Elastic Container Service) to keep operational overhead within the capacity of the initial team. Managed Airflow (MWAA) is an option for subsequent phases if operational complexity warrants it.
Change Data Capture and ETL. Data movement from operational databases to the warehouse will be implemented through a combination of Change Data Capture (CDC) and scheduled batch extraction, depending on the latency requirements of each domain. Near-real-time domains - transaction data, payment status events, and compliance screening results - will use CDC to stream changes from MySQL and PostgreSQL into the warehouse with a lag target of under 5 minutes. Lower-latency-requirement domains - merchant profile data, corridor configuration, financial reporting - will use scheduled batch extraction on a configurable cadence, typically hourly or daily. AWS Database Migration Service (DMS) and Debezium are the primary CDC tooling candidates; the choice will be resolved during the tooling selection phase.
Metabase for Self-Service BI. Metabase is retained as the self-service BI layer in the target architecture but repositioned: rather than querying operational read replicas, Metabase will query the analytical mart layer in the data warehouse. This repositioning achieves three improvements: queries run against an analytical schema optimised for reporting rather than an operational schema optimised for transaction processing; metrics are sourced from the governed mart layer rather than being recalculated in the dashboard tool; and the operational databases are fully decoupled from reporting load. Metabase's embedded analytics capability will also be evaluated for potential use in the Merchant Portal, allowing merchants to view enriched transaction and settlement analytics within their portal experience.
B.3 Data Domains¶
Six data domains are defined for the target architecture. Each domain has a designated owner - a senior functional leader who is accountable for the accuracy and completeness of the domain's data - and a data steward who is responsible for the day-to-day operational quality of domain data.
Transaction Data. The core domain, covering all payment transactions across Pay-Ins, Pay-Outs, Remittances, Crypto Off-Ramp, and White-Label Wallet product lines. Includes raw transaction events, state transitions, operator responses, settlement records, and dispute and chargeback outcomes. Domain owner: Chief Technology Officer. This domain is classified as Simpaisa Highly Confidential and contains no PII in the analytical layer; individual consumer identifiers are replaced with pseudonymous keys at the CDC boundary.
Merchant Data. Merchant profiles, KYB status and screening history, commercial agreements and pricing tiers, API integration metadata, and merchant health scoring model inputs and outputs. Domain owner: Chief Revenue Officer. PII fields (individual beneficial owner names, identity document references) are masked in the analytical layer; only aggregated and pseudonymised data is accessible in BI tooling.
Corridor Economics. FX rates applied per corridor, interchange and operator costs, margin calculations, corridor yield, and volume trends by corridor and by payment method. This domain is the primary input to the real-time corridor economics dashboard described in Section B.4. Domain owner: Chief Financial Officer.
Compliance Screening. Sanctions screening results, AML transaction monitoring outputs, risk scores assigned to merchant profiles, and regulatory reporting submission records. This domain has the most restrictive access controls in the warehouse: access is limited to compliance officers and auditors. No compliance screening data is surfaced in general-access dashboards. Domain owner: Global Head of Compliance.
Operational Metrics. Platform availability and performance data, API response times, error rates by product and corridor, settlement cycle adherence, and SLA performance metrics. This domain feeds the engineering and operations dashboards and the monthly operational KPI report to the board. Domain owner: Chief Technology Officer.
Financial Reporting. General ledger transactions, revenue recognition records, cost allocations by entity and corridor, intercompany eliminations, and regulatory financial return data. This domain is the primary input to automated regulatory reporting and the finance team's month-end close process. Domain owner: Global Chief Financial Officer.
B.4 Data Governance Integration¶
The data architecture does not introduce a separate data governance framework; it integrates with and operationalises the governance scheme established in the group data classification policy (SGP-CDO-001). The classification scheme's four tiers - Public, Internal, Confidential, and Highly Confidential - are implemented as warehouse access roles, ensuring that a data analyst's warehouse permissions automatically reflect the classification of the data they are entitled to access.
In-country data residency requirements, documented in the infrastructure team's data residency register, are implemented through warehouse configuration: Snowflake's multi-region data sharing or BigQuery's regional dataset placement will be used to ensure that Pakistan-origin and Bangladesh-origin transaction data is stored and processed within the required geographic boundaries, even as the analytics infrastructure is managed centrally.
PII masking is applied at the CDC boundary before data enters the warehouse. Masking rules are defined per field in the data catalogue (implemented in the dbt project as column-level documentation) and are applied by the ingestion pipeline. Once data enters the staging layer, PII fields are either masked (replaced with a consistent pseudonymous token, preserving joinability across tables) or redacted (replaced with a null value where the analytical use case does not require the field). The masking configuration is reviewed by the CISO team quarterly.
B.5 Key Use Cases¶
Real-Time Corridor Economics Dashboard. A live dashboard showing FX margin, operator cost, gross profit contribution, and volume by corridor, updated with a lag of under 5 minutes from transaction completion. The primary user is the CFO and treasury team for intraday pricing decisions.
Merchant Health Scoring. A daily-refreshed score for each active merchant, incorporating transaction volume trend, dispute rate, settlement delay incidents, and API error rate. The score is used by the commercial team for proactive account management and by the Risk function as an input to the merchant risk assessment process.
Fraud Detection Model Training. A historical feature store of transaction attributes - amount, currency, payment method, device fingerprint, velocity indicators, and outcome - used to train and retrain the fraud detection ML model. The feature store is updated daily. Access is restricted to the Data and Risk teams.
Automated Reconciliation. A daily reconciliation pipeline that compares the settlement engine's output against operator-reported settlement figures and flags discrepancies above a configurable threshold for manual review. The pipeline eliminates approximately 80% of the manual reconciliation work currently performed by the finance team.
Regulatory Reporting Automation. Automated generation of the periodic transaction reports required by SBP (Pakistan), Bangladesh Bank, Nepal Rastra Bank, and - when the DFSA licence is granted - the DFSA. Reports are generated from the financial reporting and transaction data domains, formatted to the regulatory template, and routed through a review and sign-off workflow before submission.
B.6 Implementation Timeline and Investment¶
The data architecture programme is aligned with Workstream 4 of the Digital Transformation Roadmap, spanning Months 3 through 9 of the CDO's initial operating term.
Month 3 covers tooling selection and procurement: warehouse platform selection (Snowflake vs. BigQuery), Airflow deployment on AWS ECS, and data catalogue tooling selection. Month 4 covers the foundational ingestion layer: CDC configuration for the transaction data domain and the Airflow DAGs for batch extraction of the remaining domains. Month 5 covers the initial dbt project: staging and intermediate layers for transaction and corridor economics domains, with the first governed mart tables published to Metabase. Month 6 covers the first use cases in production: the corridor economics dashboard and the automated reconciliation pipeline. Months 7 through 9 cover the remaining domains, the merchant health scoring model, the regulatory reporting automation, and the ML feature store.
Estimated investment in Year 1 is USD 80,000 to USD 120,000, covering warehouse platform licensing (scaled to initial data volumes), Airflow infrastructure, data catalogue tooling, and external advisory support for the initial architecture design. This investment is in addition to the cost of one to two data engineers, who are the primary resource required. Data engineering capability is identified as the single most critical hire for the Data function in the CDO's 90-Day Plan, with recruitment to commence in Month 1.
Supplementary Document C: Competitive Intelligence Framework¶
C.1 Purpose and Scope¶
Simpaisa operates in a competitive landscape that is moving rapidly. New entrants are well capitalised, regulatory approvals in frontier markets are shortening, and product differentiation is eroding as the underlying rails - mobile wallets, bank transfers, cryptocurrency off-ramps - become more widely accessible to aggregators and processors globally. In this environment, competitive intelligence is not a background activity; it is an input to product strategy, corridor pricing, market entry sequencing, and commercial positioning.
The Competitive Intelligence Framework establishes a systematic process for collecting, analysing, and distributing intelligence on Simpaisa's competitive landscape. Its purpose is to ensure that strategic decisions - whether to enter a new corridor, how to price a product, which features to prioritise in the next roadmap cycle, or how to position Simpaisa in investor materials - are made with current, structured, and validated information about the competitive environment, rather than relying on anecdote or historical knowledge.
The framework is owned by the Chief Digital Officer and operated by the CPO and the CRO jointly, with input from regional commercial leads, the technology team, and external sources.
C.2 Competitor Universe¶
The competitor universe is segmented by the dimension of competition - global infrastructure providers, regional specialists, and local market incumbents - reflecting the reality that Simpaisa faces different competitive dynamics depending on the product, corridor, and customer segment.
Global and Regional Payment Infrastructure Providers. dLocal, Thunes, and TerraPay are the primary benchmarks in this category. All three have built cross-border payment infrastructure with significant frontier-market depth, and all three are potential reference points in merchant RFP processes and investor comparisons. dLocal's model - listed on NASDAQ, focused on Latin America but expanding into Africa and Asia - provides a useful public market valuation reference. Thunes and TerraPay both compete directly with Simpaisa on specific corridors (Pakistan inbound, Bangladesh inbound) and are tracked for product development and pricing intelligence.
African Payment Specialists. Flutterwave and Paystack (acquired by Stripe) dominate the West African market and are expanding into East and North Africa. Whilst these companies do not compete with Simpaisa on its current corridors, their expansion trajectories are relevant to Simpaisa's own Africa evaluation and their product and technology choices set expectations for the merchant community globally.
Global Multi-Product Processors. Rapyd and Checkout.com offer multi-product global processing with coverage in some of Simpaisa's target markets. Both are well capitalised and invest heavily in developer experience and merchant tooling, setting a quality benchmark for the Developer Portal and API experience.
MENA Regional Specialists. Fawry (Egypt), HyperPay (Saudi Arabia), and PayTabs (MENA) are tracked as direct competitive threats in Simpaisa's MENA expansion markets. Fawry's dominance in Egyptian payment aggregation and Fawry Plus's financial services ambitions are particularly relevant to corridor economics for the Egypt corridor. HyperPay's position as the leading Saudi aggregator, and its relationships with SAMA, are relevant to Simpaisa's Saudi market entry strategy and licensing approach.
C.3 Intelligence Categories¶
Eight categories of intelligence are systematically tracked for each competitor in the universe.
Product launches. New products, product enhancements, new payment method integrations, and new corridor activations. The specific focus is on changes that affect Simpaisa's differentiation - if a competitor activates a corridor that Simpaisa considers exclusive or adds a payment method that Simpaisa's merchants have been requesting.
Market entries. New country operations, regulatory licence applications and grants, and partnership announcements that signal an intent to enter a new market. An early signal of a competitor's market entry often provides 6 to 12 months of lead time before they are operationally competitive, which is the window in which Simpaisa can strengthen local relationships and deepen corridor economics.
Pricing changes. MDR adjustments, FX margin changes, and settlement fee changes disclosed through merchant communications, regulatory filings, or merchant feedback. Pricing intelligence informs Simpaisa's own pricing strategy and enables the commercial team to make data-driven responses in competitive tender situations.
Funding rounds and financial events. Capital raises, debt facilities, and - for publicly listed competitors - quarterly financial disclosures. Funding events signal strategic ambitions and provide context for competitor product investment.
Partnerships and commercial agreements. Announced integrations with mobile wallet operators, banks, or technology platforms. A competitor's new partnership with a mobile money operator in a target market can materially change the competitive position.
Regulatory actions. Licence grants, licence suspensions, enforcement actions, and regulatory correspondence that becomes public. Regulatory events affecting competitors can create market opportunities (a competitor under sanction will lose merchant confidence) or indicate regulatory trends that Simpaisa should anticipate.
Leadership changes. C-level and senior executive movements, particularly in commercial, product, and country leadership roles. Leadership changes often foreshadow strategic shifts and can be the basis for commercial relationship opportunities.
Technology announcements. API capability announcements, developer programme launches, infrastructure partnerships, and technology acquisitions. These are tracked as leading indicators of product direction.
C.4 Collection Methods and Sources¶
Automated monitoring. Google Alerts are configured for each competitor name, their key product names, and their senior leadership names. Alerts are delivered daily to a designated competitive intelligence inbox monitored by the CPO's office. LinkedIn monitoring covers each competitor's company page (for product and hiring announcements) and the public profiles of their C-level and senior commercial leaders.
Industry publications and research. Simpaisa subscribes to The Paypers (payments industry news and analysis), FXC Intelligence (cross-border payments market data and benchmarking), and Mondato (digital finance in emerging markets). These publications are the primary source for quantitative corridor data and structured competitive comparisons. Where FXC Intelligence publishes benchmarking data that includes Simpaisa or its direct competitors, this is flagged to the CDO and CEO immediately.
Conference intelligence. Simpaisa attends Money20/20 (Dubai edition as the primary MENA event, Amsterdam for Europe) and Seamless (Middle East). Conference attendance serves dual purposes: commercial relationship development and competitive intelligence gathering. Each attendee from the commercial, product, or leadership team files a structured debrief within 3 business days of returning from any conference, covering competitor conversations, product announcements observed, and market sentiment. Debriefs are consolidated by the CPO's office and filed in the competitive intelligence repository.
Merchant feedback. The commercial team systematically collects competitive intelligence through merchant relationships - specifically, understanding which other providers a merchant has evaluated, what led to the merchant's decision to work with Simpaisa (or not), and what features or pricing the merchant has been offered by competitors. This channel is often the most current and specific source of pricing intelligence. A structured question set for competitive discovery is embedded in the account management review template.
Partner intelligence. Banking partners, mobile wallet operators, and technology partners frequently have visibility into competitor activity in their markets. Country heads are responsible for maintaining relationships that provide early visibility into competitor licensing applications, partnership discussions, and market entry activity.
C.5 Analysis Cadence and Outputs¶
Monthly Competitive Brief. A one-to-two-page summary of material competitive developments in the prior month, including product launches, market entries, funding events, and significant regulatory or leadership changes. The brief is produced by the CPO's office, reviewed by the CDO, and distributed by the first business day of the following month. Distribution: CDO, CEO, CRO, CPO.
Quarterly Competitive Deep-Dive. A structured analysis covering a specific theme or market, produced quarterly. Examples of deep-dive themes: Saudi market competitive landscape ahead of the SAMA MPI application; dLocal and Thunes pricing benchmarking across South Asian corridors; MENA aggregator market structure and Simpaisa positioning. The deep-dive is 6 to 10 pages, includes primary and secondary research, and is presented by the CDO at the quarterly leadership offsite. Distribution: Executive Leadership Team. The quarterly deep-dive is included in the board pack in summarised form (2 pages maximum).
Annual Competitive Landscape Report. A comprehensive annual assessment of the competitive landscape, including updated competitive positioning matrices, market share estimates where data is available, corridor coverage comparisons, and a forward-looking assessment of competitive threats and opportunities for the next 12 to 18 months. The annual report is presented to the board at the year-end board meeting and used as an input to the annual strategic planning process.
C.6 Competitive Positioning Matrix¶
Simpaisa's competitive positioning is assessed across seven dimensions for each competitor in the universe. The positioning matrix is updated quarterly as part of the deep-dive process.
Frontier market depth. The number and quality of live corridors in frontier markets (defined as markets outside OECD and non-GCC), measured by the range of local payment methods supported and the depth of local operator relationships.
Local licensing. The number of jurisdictions in which the competitor holds a direct regulatory licence (as opposed to operating through a partner's licence or under an exemption). Local licensing is a proxy for regulatory credibility and barrier to displacement.
Payment method coverage. The range of payment methods supported across all corridors - mobile wallets, bank transfer, card, cryptocurrency, cash, QR - with specific attention to the payment methods most relevant to Simpaisa's target merchant base.
Settlement speed. The settlement cycle offered to merchants across corridors, from real-time to T+5, and the prevalence of real-time settlement capability.
Pricing. MDR range by product and corridor, FX margin, minimum volume requirements, and pricing transparency (whether pricing is publicly available or negotiated only).
Developer experience. Quality of API documentation, sandbox availability, SDK coverage, and time-to-first-transaction benchmarks where available from merchant feedback or public sources.
Islamic market expertise. Shariah compatibility certification status, Islamic finance product offerings, and demonstrated experience with Islamic financial institutions and Muslim-majority market regulators.
C.7 Governance and Quality Standards¶
Competitive intelligence is treated as a sensitive information asset. It is stored in a designated folder in the Simpaisa data room, accessible to the CDO, CEO, CRO, and CPO, and to designated analysts working under their direction. The monthly brief and quarterly deep-dive are marked Simpaisa Confidential and are not shared externally.
Intelligence collection methods are constrained by ethical and legal standards. Simpaisa does not engage in industrial espionage, does not use deception to obtain competitor information, and does not solicit confidential information from competitors' employees or partners in breach of their confidentiality obligations. All collection methods used are limited to publicly available sources, industry relationships, and legitimate merchant and partner conversations.
Supplementary Document D: ESG and Sustainability¶
D.1 Strategic Context and Relevance¶
Simpaisa's ESG commitments are grounded in three distinct but mutually reinforcing contexts: investor expectations, regulatory alignment, and mission integrity.
Investor expectations. Sarmayacar, as Simpaisa's lead institutional investor, applies ESG considerations to portfolio company evaluation and will increasingly require structured ESG reporting as Simpaisa approaches its Series B. International investors - particularly those based in Europe or North America - will conduct ESG due diligence as a standard component of investment review. Having an organised, evidenced ESG position prior to entering a fundraising process reduces friction and demonstrates institutional maturity.
Regulatory alignment. The DFSA, as Simpaisa's most sophisticated regulatory counterpart, is moving towards mandatory ESG disclosure for licensed firms operating in the DIFC. DFSA ESG expectations draw on international frameworks, including the Task Force on Climate-related Financial Disclosures (TCFD) and the Global Reporting Initiative (GRI). Simpaisa's proactive engagement with these frameworks positions it ahead of formal regulatory obligation rather than in reactive compliance mode.
Mission integrity. Simpaisa's mission - to enable financial access for the next billion users in frontier markets - is itself an ESG proposition. The company's social impact is not incidental to its commercial activity; it is the basis of its strategic rationale. Articulating and evidencing that impact in structured ESG terms allows Simpaisa to credibly occupy the financial inclusion narrative in investor, regulatory, and public communications.
ESG governance at the group level is the responsibility of the Chief Digital Officer, who integrates ESG oversight with the operating model governance function. Functional accountability for ESG execution sits with the relevant functional heads: technology (environmental), HR (social and workforce), and Legal and Compliance (governance). The CDO produces the annual sustainability statement and presents ESG metrics to the board annually.
D.2 Environmental¶
Cloud Infrastructure Carbon Footprint. Simpaisa's direct carbon footprint is dominated by its cloud infrastructure. AWS publishes a Customer Carbon Footprint Tool that provides an estimate of the carbon emissions associated with each AWS account's resource consumption, including the proportion attributable to renewable energy sources in each region. Simpaisa will establish a baseline carbon footprint measurement using the AWS Customer Carbon Footprint Tool by end of Q2 2026, and will report this figure annually in the sustainability statement. The primary variable affecting Simpaisa's footprint is AWS region selection: the EU regions (Frankfurt, Ireland) and the US West regions carry higher renewable energy fractions than some of the regions used for South Asia coverage. Cloudflare's infrastructure is powered by 100% renewable energy, which is a credit to Simpaisa's overall footprint as the Cloudflare migration progresses.
Reducing Footprint Over Time. Three operational levers are available to Simpaisa to reduce its cloud carbon footprint without material cost or performance impact. First, rightsizing: ensuring that compute resources are scaled to actual utilisation rather than over-provisioned, which reduces both cost and energy consumption. The DevOps team's active-active DR architecture already enforces efficient resource utilisation across availability zones. Second, the Cloudflare migration: as traffic is progressively shifted from AWS compute and CloudFront to Cloudflare's renewable-powered edge network, the carbon intensity of request processing decreases. Third, AWS region selection for new services: where data residency requirements permit, new services are deployed in AWS regions with higher renewable energy fractions.
Paperless Operations. Simpaisa operates as a paperless organisation by design. All internal documentation is maintained digitally (Confluence, OneDrive, Google Workspace). Merchant agreements are executed via DocuSign. Regulatory filings are submitted electronically wherever the regulatory authority provides an electronic filing mechanism. There is no central office printing infrastructure; the Dubai office maintains minimal print capability for legal documents requiring wet signatures where required by local practice. The paperless position is a natural consequence of the company's remote-first and multi-location operating model rather than a separately governed programme.
Remote-First and Travel. Simpaisa operates a remote-first workforce model, with the Dubai office serving as a coordination and client-meeting hub rather than a primary place of work. The distributed workforce across Pakistan, Bangladesh, Nepal, Iraq, UAE, UK, and Canada means that routine collaboration is conducted over video conference. Business travel - predominantly for merchant meetings, regulatory meetings, and conference attendance - is the primary discretionary carbon source. Travel is not currently subject to a carbon budget, but the sustainability statement will disclose business flight activity from Year 1 of reporting, providing a baseline for future reduction targets.
D.3 Social¶
Financial Inclusion Mission. Simpaisa's core product portfolio is designed to serve consumers and businesses that are excluded from or underserved by formal financial infrastructure. Pay-Ins and Pay-Outs enable merchants to collect and disburse payments across markets where card acceptance is minimal and bank account penetration is low. Remittances serve migrant worker families in Pakistan, Bangladesh, and Nepal - populations that are dependent on inbound remittance flows as a primary source of household income and for whom the cost and reliability of remittance transfer is a material economic issue. Crypto Off-Ramping provides a mechanism for individuals in capital-controlled economies to convert digital assets to local currency through a regulated channel rather than informal exchange networks. White-Label Wallets enable financial institutions and fintechs in Simpaisa's target markets to offer digital financial services without building payments infrastructure from scratch.
The financial inclusion impact of these products is quantifiable and will be reported annually. Impact metrics include: number of unique consumer accounts served across all product lines (excluding corporate and merchant accounts); total value of inbound remittance transactions facilitated (as a proxy for migrant family income support); number of payment corridors active where no SWIFT-equivalent alternative exists (frontier corridor count); and number of previously unbanked or underbanked consumers completing their first digital financial transaction through a Simpaisa-powered product.
Gender Diversity. Simpaisa's 180-person workforce operates across eight nationalities and multiple cultural contexts. Gender diversity presents distinct challenges across the group: the Pakistan and Bangladesh engineering teams reflect the structural underrepresentation of women in technology roles in South Asia, whilst the Dubai and Singapore leadership teams have stronger gender balance. The group's approach to gender diversity is practical rather than quota-driven: structured talent development for high-potential female staff, explicit consideration of gender balance in shortlisting for senior roles, and ensuring that remote-first working arrangements do not disproportionately disadvantage employees who carry domestic responsibilities. Gender diversity metrics - the ratio of female to male employees by seniority band - are reported to the board annually and included in the sustainability statement.
Employee Wellbeing and Multi-Cultural Workforce. A workforce of 180 people spanning eight nationalities, four time zones, and multiple cultural and religious traditions requires deliberate attention to inclusion and wellbeing. Ramadan working arrangements (flexible hours during fasting month, adjusted meeting schedules) are formalised and applied consistently across all group entities. Religious observances across the full range of traditions represented in the workforce - including Eid al-Fitr, Eid al-Adha, Diwali, Christmas, and others - are accommodated through a flexible leave approach. Mental health support is provided through the UAE entity's employee assistance programme and is accessible to employees across all entities. Employee satisfaction is measured through a twice-yearly anonymous survey, with results reported to the executive team and material themes addressed within one quarter.
Community Impact: Remittance Facilitation. The remittance product serves a population that is disproportionately dependent on inbound funds for household expenditure on food, education, and healthcare. The societal value of reliable, low-cost remittance infrastructure in markets like Pakistan, Bangladesh, and Nepal is well-documented in World Bank research: a 1% reduction in the cost of remittance transfers is estimated to result in a meaningful increase in household disposable income in recipient communities. Simpaisa's sustainability statement will include a corridors-versus-market-average cost comparison demonstrating where Simpaisa's pricing delivers a consumer cost advantage relative to the market rate reported by the World Bank Remittance Prices Worldwide database.
D.4 Governance¶
The Operating Model as Governance Evidence. The Simpaisa Group Operating Model - comprising 28 sections, eight standalone policies, 15 RASCI matrices, a delegation of authority framework, board committee terms of reference, and a comprehensive compliance programme - is the primary evidence of Simpaisa's governance standard. It demonstrates that the group is run through documented, accountable, and auditable structures rather than informal or personality-dependent arrangements. For investors and regulators conducting governance due diligence, the operating model provides the substantive reference; the sustainability statement summarises the key governance architecture and refers readers to the full document.
Board and Committee Structure. The board of Simpaisa Holdings PTE. Limited includes independent non-executive directors with expertise in financial services, regulatory affairs, and technology. Board committees - including the Audit and Risk Committee and the Compliance and Regulatory Committee - provide structured oversight of financial reporting, risk management, and compliance obligations. Committee terms of reference, meeting cadence, and reporting obligations are documented in the governance section of the operating model (Section 4). The sustainability statement will confirm the board's composition, independence classification, and committee structure annually.
Delegation of Authority and Controls. The delegation of authority framework establishes the financial and operational limits within which each layer of management may act without escalation, and the controls that apply at each tier. This framework is a critical governance control in a multi-entity group operating across jurisdictions with different regulatory and financial norms: it prevents unauthorised commitment of group funds, ensures that material commercial, financial, and regulatory decisions receive appropriate executive or board scrutiny, and provides an audit trail for decision-making. The framework is reviewed annually by the CFO and approved by the board.
Compliance Programme. Simpaisa's compliance programme - covering AML/CFT/CPF, sanctions, KYC/KYB, transaction monitoring, regulatory reporting, and data protection - is documented in the compliance section of the operating model (Section 12) and the standalone compliance policies. The programme is audited annually by an independent external auditor. Regulatory examination findings and audit recommendations are tracked to resolution and reported to the Compliance and Regulatory Committee. The compliance programme's existence, scope, and audit status are disclosed in the sustainability statement.
D.5 Islamic Finance Alignment¶
Simpaisa's Islamic finance alignment extends beyond a commercial positioning choice; it reflects the cultural and regulatory context of a significant portion of the group's operating markets. Pakistan, Bangladesh, Iraq, and Saudi Arabia are Muslim-majority economies in which Islamic finance principles carry regulatory and social weight. The Shariah Compatibility Framework (Section 14 of the core operating model) provides the detailed operational guidance; this section summarises the ESG dimension of that alignment.
Maqasid al-Shariah. The objectives of Islamic law - preservation of religion, life, intellect, lineage, and wealth - provide a framework through which Simpaisa's activities can be evaluated beyond a purely commercial lens. Simpaisa's financial inclusion mission aligns with the preservation of wealth at the community level: enabling migrant workers to transfer earnings to families, enabling small merchants to access payment infrastructure previously available only to larger businesses, and enabling digital financial participation for populations excluded from formal banking. This alignment is not merely rhetorical; it provides a basis for engagement with Islamic financial institutions, Islamic Development Bank-affiliated funds, and Shariah-compliant investor mandates that may be relevant to Simpaisa's future fundraising.
Merchant Screening for Prohibited Industries. Simpaisa's merchant onboarding process includes screening against a list of prohibited industries defined by the Shariah Compatibility Framework. This screening ensures that Simpaisa does not process payments for merchants engaged in activities that are incompatible with Islamic finance principles - including interest-based financial products where Simpaisa would be a direct facilitator, alcohol or pork product distribution, gambling, and prohibited entertainment. The screening is applied during KYB and reviewed as part of the annual merchant risk assessment cycle.
Zakat Facilitation. A product concept under evaluation is the integration of Zakat calculation and disbursement functionality into the White-Label Wallet product, enabling wallet operators in Muslim-majority markets to offer their users a built-in mechanism for calculating and disbursing their annual Zakat obligation to approved charitable recipients. This concept is at the evaluation stage and its commercial viability and regulatory status in each target market is under assessment. If developed, it would represent a meaningful product innovation in the Islamic fintech space and a demonstrable expression of Simpaisa's Maqasid al-Shariah alignment.
D.6 Reporting Framework and Timeline¶
GRI-Aligned Sustainability Statement. Simpaisa will produce an annual sustainability statement aligned to the Global Reporting Initiative (GRI) Standards. GRI alignment does not require a full formal GRI audit in Year 1; it means that disclosures are structured to correspond with GRI topics and indicators, enabling like-for-like comparison with industry peers and providing the foundation for a full GRI-audited report in subsequent years. The first sustainability statement will be produced for the financial year ending 31 December 2026, to be published in Q1 2027.
DFSA ESG Disclosure. If the DFSA Category 3D licence is granted and DFSA ESG disclosure requirements are introduced for licensed firms during the licensing period, Simpaisa will comply with those requirements within the timelines specified by the DFSA. The CDO maintains a watching brief on DFSA consultation papers and policy statements relevant to ESG disclosure.
Quick Wins for Year 1. Three ESG actions can be completed within the current operating year without additional investment and will demonstrate proactive commitment ahead of the first formal sustainability statement. First, publish financial inclusion impact metrics - transaction volume by product line enabling previously unbanked consumers, corridor count, and remittance cost comparison - as a one-page impact statement on the Simpaisa corporate website by Q3 2026. Second, establish a baseline cloud carbon footprint measurement from the AWS Customer Carbon Footprint Tool and the Cloudflare dashboard, and include this figure in the CDO's quarterly board report from Q2 2026. Third, publish the group's gender diversity metrics (employee ratio by seniority band) in the 2026 annual board report, establishing a baseline against which future progress can be measured.