Simpaisa Group Operating Model - Supplementary Documents¶
Version: 1.0
Date: April 2026
Classification: Confidential - Board and Executive Use Only
Appendix S1: Talent Market Mapping - Saudi Arabia and MENA Expansion¶
Purpose¶
This appendix provides a structured reference for talent acquisition in support of Simpaisa's planned expansion into Saudi Arabia, with secondary applicability to broader MENA and Central Asian markets. It covers priority roles, sourcing markets, compensation benchmarks, Saudisation compliance obligations, and a phased hiring sequence.
S1.1 Priority Roles for Saudi Expansion¶
| Role | Rationale | Headcount (Phase 1) |
|---|---|---|
| Country Head - Saudi Arabia | Regulatory relationships, SAMA engagement, commercial leadership | 1 |
| Compliance Officer - Saudi Arabia | SAMA licensing, AML/CTF obligations, Nitaqat compliance reporting | 1 |
| Payment Channel Manager | MNO/bank integration (STC Pay, Alinma, Al Rajhi), channel commercials | 1 |
| Business Development Manager | Merchant and corridor acquisition | 1 |
| Engineering Lead (In-Country) | Local tech representation, optional; may be deferred to Phase 2 | 1 (Phase 2) |
| Operations and Settlement Analyst | Float management, reconciliation, exception handling | 1 |
| Legal and Regulatory Counsel (Retained) | SAMA, DIFC cross-border structuring, commercial contracts | Retained/fractional |
S1.2 Hiring Market by Role¶
| Role | Primary Market | Secondary Market | Notes |
|---|---|---|---|
| Country Head - Saudi Arabia | Local Saudi nationals (preferred) | Senior Dubai-based GCC executives | SAMA and enterprise relationships require local credibility; Saudi national strongly preferred |
| Compliance Officer - Saudi Arabia | Saudi nationals with SAMA background | Dubai compliance professionals willing to relocate | Nitaqat requirements make Saudi national hiring critical for this role |
| Payment Channel Manager | Saudi/GCC-based payments professionals | Dubai expat fintech community | STC Pay and Al Rajhi relationships are the primary asset sought |
| Business Development Manager | Saudi nationals | Dubai-based Gulf sales professionals | Must be native Arabic-speaking; local network essential |
| Engineering Lead | Dubai expat pool (India, Pakistan, Egypt) | Remote Pakistan/Bangladesh engineering | In-country presence may not be required until regulatory mandate; confirm with SAMA |
| Operations Analyst | Pakistan remote | Bangladesh remote | Can be managed from existing ops hubs; cost-efficient structure |
| Legal Counsel | Dubai-based MENA law firms (retained) | Riyadh-based boutique practices | Al Tamimi, Clyde & Co, Pinsent Masons have strong SAMA practices |
S1.3 Compensation Benchmarks¶
All figures are annual total cash (base + bonus target), in USD equivalent. Equity excluded.
Senior Technology (Engineering Lead / Head of Engineering)¶
| Market | Range (USD) | Notes |
|---|---|---|
| Dubai | $110,000 – $160,000 | Tax-free; housing allowance often separate |
| Riyadh | $90,000 – $140,000 | GOSI contributions add ~12% employer cost; housing allowance common |
| Pakistan (remote senior) | $24,000 – $48,000 | Competitive in local terms; PKR volatility risk |
| Bangladesh (remote senior) | $18,000 – $36,000 | Strong pool for backend/payments engineering |
Compliance and Regulatory¶
| Market | Range (USD) | Notes |
|---|---|---|
| Dubai | $100,000 – $150,000 | CAMS/ICA-certified profiles command premium |
| Riyadh | $85,000 – $130,000 | SAMA-experienced professionals are scarce; expect to pay top of range |
| Pakistan (remote support) | $20,000 – $38,000 | Suitable for operational compliance support, not in-country regulatory lead |
Commercial and Operations¶
| Market | Range (USD) | Notes |
|---|---|---|
| Dubai | $80,000 – $120,000 | Includes BDM, Channel Manager, Country Head at lower tier |
| Riyadh (Country Head) | $130,000 – $200,000 | Country Head requires senior package with housing, schooling, relocation |
| Pakistan/Bangladesh (ops) | $12,000 – $24,000 | Suitable for back-office operations and settlement analysts |
S1.4 Saudisation (Nitaqat) Requirements¶
The Nitaqat programme mandates minimum percentages of Saudi national employees by company size and sector. Payments and fintech are classified under "Financial Services."
| Company Size (Total Employees in KSA) | Minimum Saudi National Percentage | Nitaqat Band Target |
|---|---|---|
| 1–9 | 1 Saudi national minimum | Green |
| 10–49 | ~30% | Green |
| 50–499 | ~35–40% | Green / Platinum |
| 500+ | ~45% | Platinum |
Key obligations for Simpaisa KSA entity:
- Register the Saudi entity with the Ministry of Human Resources (MHRSD) upon incorporation.
- Begin filing Nitaqat compliance data through the Qiwa platform from day one of hiring.
- Target Green band as a minimum; Platinum band unlocks faster visa processing and government contract eligibility.
- Saudi nationals must be on payroll, not merely listed as directors - MHRSD audits employment contracts and GOSI contributions.
- Female inclusion is increasingly scrutinised; MHRSD incentivises female Saudi employment with preferential Nitaqat credits.
- Non-compliance risks: visa quota suspension, inability to renew commercial registration, and reputational risk with SAMA.
Practical implication: The Country Head and Compliance Officer roles should be filled by Saudi nationals from the outset, which simultaneously satisfies regulatory relationships, Nitaqat compliance, and commercial credibility requirements.
S1.5 Recommended Recruitment Channels¶
| Channel | Best For | Notes |
|---|---|---|
| LinkedIn - Saudi / GCC filter | All senior roles | Primary channel; Saudi fintech community is active |
| Bayt.com | Mid-level Saudi nationals | Regional jobs platform with strong KSA penetration |
| GreenHouse / Workable ATS | Structured pipeline management | Integrate with LinkedIn and Bayt |
| Fintech Saudi Alumni Network | Country Head, Compliance, BDM | Fintech Saudi runs accelerator and regulatory engagement programmes; alumni are well-networked |
| SAMA Graduate Programme Alumni | Compliance Officer | Direct pipeline of SAMA-credentialled Saudi nationals |
| King Fahd / KAUST / King Abdulaziz University partnerships | Junior-to-mid engineering | Useful for Phase 2 as team scales |
| Fintech Recruiters - GCC | Country Head, senior hires | Heidrick & Struggles, Korn Ferry, Michael Page Middle East have dedicated fintech desks |
| Internal Simpaisa network | All roles | Dubai team to leverage personal networks; incentivise referrals with a referral bonus scheme |
S1.6 Phased Hiring Sequence¶
| Phase | Timeline | Roles | Rationale |
|---|---|---|---|
| Phase 1 - Foundation | Months 1–3 post-entity incorporation | Country Head, Compliance Officer | Regulatory relationships and Nitaqat compliance from day one |
| Phase 2 - Commercial Build | Months 3–6 | Payment Channel Manager, Business Development Manager | Begin partner integrations and merchant pipeline |
| Phase 3 - Operations | Months 6–9 | Operations and Settlement Analyst | Operational volume justifies in-region ops support |
| Phase 4 - Technology | Months 9–18 | Engineering Lead (if mandated by SAMA or commercial scale) | Assess regulatory requirements at time of SAMA licence review |
Appendix S2: Intellectual Property Register¶
Purpose¶
This register documents Simpaisa Group's intellectual property assets across all categories. It provides a baseline for IP governance, informs due diligence responses, and flags gaps where additional protection is recommended. This register is maintained by the CDO in coordination with Group Legal and is reviewed annually.
Last reviewed: April 2026
Owner: CDO / Group Legal
Next review: April 2027
S2.1 Patents¶
| Reference | Title / Description | Jurisdiction | Status | Owning Entity | Notes |
|---|---|---|---|---|---|
| PAT-001 | Payment routing optimisation algorithm | - | Not filed [TBC] | - | Protectable innovation; see recommendations at S2.6 |
S2.2 Trademarks¶
| Mark | Class | Jurisdiction | Registration Number | Status | Owning Entity | Expiry / Renewal |
|---|---|---|---|---|---|---|
| SIMPAISA (word mark) | Class 36 (Financial Services) | Pakistan | TBC | Registered | PublishEx (PK) | TBC |
| SIMPAISA (word mark) | Class 42 (Technology Services) | Pakistan | TBC | Registered | PublishEx (PK) | TBC |
| Simpaisa Logo (device mark) | Class 36 (Financial Services) | Pakistan | TBC | Registered | PublishEx (PK) | TBC |
| SIMPAISA (word mark) | Class 36 / 42 | Singapore | TBC | Registered | Simpaisa Holdings (SG) | TBC |
Gaps identified: No registered trademarks in UAE, DIFC, Saudi Arabia, Bangladesh, Nepal, or Iraq. Registration is recommended in all active and planned markets - see S2.6.
S2.3 Trade Secrets¶
| Asset | Description | Classification | Custodian | Access Controls |
|---|---|---|---|---|
| Payment Routing Algorithm | Proprietary logic for multi-corridor, multi-rail routing optimisation including cost, speed, and success-rate weighting | Highly Confidential | CTO / Engineering | Source control access-controlled; NDA required for all engineering staff with access |
| Operator Integration Specifications | Technical integration details for each MNO and bank partner including API endpoints, authentication, error-handling flows, and settlement timing | Confidential | CTO / Engineering | Internal documentation system; restricted to integration engineers and senior management |
| Reconciliation Engine Logic | Proprietary reconciliation and exception-management algorithms including float accounting, suspense handling, and multi-currency settlement rules | Highly Confidential | CTO / Head of Finance | Source control; joint custody of Engineering and Finance |
| Corridor Economics Model | Pricing models, margin structure, and FX spread logic by corridor | Confidential | CFO / CPO | Finance system access; board-level reporting only |
| Merchant Performance Data | Historical transaction performance, success rates, and behavioural data by merchant | Confidential | CPO / Head of Data | Data platform; RBAC enforced |
S2.4 Software Intellectual Property¶
| System | Description | Owning Entity | Development Entity | IP Assignment Confirmed | Notes |
|---|---|---|---|---|---|
| Payment Gateway | Core transaction processing engine; handles pay-in, pay-out, and remittance routing | Simpaisa Holdings (SG) | PublishEx (PK) | TBC | IP assignment agreement between PublishEx and HoldCo to be confirmed; review employment contracts |
| Merchant Portal | Merchant-facing dashboard for transaction monitoring, reporting, and settlement | Simpaisa Holdings (SG) | PublishEx (PK) | TBC | As above |
| Settlement Engine | Automated settlement and reconciliation system | Simpaisa Holdings (SG) | PublishEx (PK) | TBC | As above |
| White-Label Wallet Platform | Configurable wallet product for B2B2C deployment | Simpaisa Holdings (SG) | PublishEx (PK) | TBC | In active development; IP assignment must be confirmed before external licensing |
| Internal Tooling and Scripts | DevOps tooling, monitoring scripts, internal dashboards | PublishEx (PK) | PublishEx (PK) | N/A (same entity) | Lower commercial risk; ensure employment contracts capture nonetheless |
Critical note: The IP assignment chain from PublishEx (PK) developer-employees to PublishEx (PK) as entity, and from PublishEx (PK) to Simpaisa Holdings (SG), must be confirmed by legal review. Gaps in this chain create material risk in due diligence processes.
S2.5 Domain Names¶
| Domain | Registrar | Registrant Entity | Expiry | Auto-Renew | Notes |
|---|---|---|---|---|---|
| simpaisa.com | TBC | TBC | TBC | TBC | Primary commercial domain; confirm registrant entity is HoldCo or operationally equivalent |
| simpaisa.pk | TBC | TBC | TBC | TBC | Country code TLD - Pakistan |
| simpaisa.ae | TBC | TBC | TBC | TBC | UAE - confirm registration |
| simpaisa.com.bd | TBC | TBC | TBC | TBC | Bangladesh - confirm registration |
| Additional variants | - | - | - | - | Review and register simpaisa.sa, simpaisa.co, simpaisa.io as defensive registrations |
S2.6 IP Protection Recommendations¶
| Priority | Action | Rationale | Owner | Timeline |
|---|---|---|---|---|
| High | Register trademarks in UAE / DIFC | Active operational market; DIFC registration protects against local infringement and supports DFSA Cat 3D credibility | Group Legal | Q2 2026 |
| High | Register trademarks in Saudi Arabia | Planned expansion market; early registration prevents squatting | Group Legal | Q2 2026 |
| High | Register trademarks in Bangladesh | Active operational market with bKash / Nagad relationships | Group Legal | Q3 2026 |
| High | Audit and formalise IP assignment chain (PK to SG) | Material due diligence risk; required before any fundraise or licensing | CDO / Legal | Q2 2026 |
| Medium | Conduct patent search and filing assessment for payment routing algorithm | Innovation may be protectable; patent provides deterrence and valuation uplift | CTO / External Patent Counsel | Q3 2026 |
| Medium | Register trademarks in Nepal and Iraq | Active operational markets | Group Legal | Q3 2026 |
| Medium | Defensive domain registrations (.sa, .io, .co) | Prevent brand dilution and cybersquatting | CDO / IT | Q2 2026 |
| Low | Review and update all employment contracts to include IP assignment clauses | Ensures IP created by employees is formally assigned to the employing entity | Group HR / Legal | Q2 2026 |
| Low | Register trademarks in Central Asia (Kazakhstan, Uzbekistan) | Forward-looking; align with expansion roadmap timing | Group Legal | 2027 |
Appendix S3: Partner SLA Management Framework¶
Purpose¶
This appendix defines Simpaisa's standard approach to managing Service Level Agreements (SLAs) with all external payment operators, banking partners, Mobile Network Operators (MNOs), infrastructure providers, and technology vendors. It establishes measurement methodology, escalation tiers, review cadence, and commercial consequences for persistent underperformance.
S3.1 Standard SLA Categories¶
| Category | Definition | Measurement Unit | Target (Standard) | Critical Threshold |
|---|---|---|---|---|
| System Availability | Percentage of time the partner's API or service is available for transactions | Uptime % per calendar month | 99.5% | Below 99.0% |
| Transaction Success Rate | Percentage of submitted transactions completed successfully by the partner | Success % per day and per month | 95.0% | Below 92.0% |
| API Response Time | Median time from Simpaisa API call to partner acknowledgement | Milliseconds (P50 and P99) | P50 < 500ms; P99 < 2,000ms | P99 > 5,000ms |
| Settlement Timing | Time from transaction confirmation to funds settled to Simpaisa account | Business hours or calendar hours | T+1 business day (standard); same-day for high-volume corridors | T+3 or persistent delay |
| Incident Response Time | Time from Simpaisa raising a support ticket to partner acknowledging with a named owner | Clock hours | L1: < 1 hour; L2: < 4 hours; L3: < 24 hours | No acknowledgement within 4 hours for P1 incident |
| Error Rate | Percentage of transactions returning a technical error (as distinct from declined by end-user) | Error % per day | < 1.0% | > 3.0% |
| Reconciliation Accuracy | Percentage of settlement reports matching Simpaisa internal records without manual intervention | Match % per settlement cycle | 99.5% | Below 98.0% |
S3.2 Measurement Methodology¶
Data collection: All metrics are captured automatically via Simpaisa's transaction monitoring and observability platform. Partner API logs are retained for a minimum of 12 months. Settlement records are maintained in the reconciliation engine.
Reporting period: SLA performance is calculated on a rolling monthly basis, with a secondary weekly view for operational monitoring.
Dispute resolution: Where Simpaisa's recorded metrics differ from a partner's self-reported metrics, the parties will share raw log data and attempt reconciliation within 5 business days. If unresolved, an independent technical review shall be conducted at the defaulting party's cost.
Exclusions: Scheduled maintenance (with minimum 72 hours' notice) and events classified as Force Majeure are excluded from availability and success-rate calculations.
S3.3 Escalation Tiers¶
| Tier | Trigger | Simpaisa Owner | Partner Counterpart | Target Resolution |
|---|---|---|---|---|
| L1 - Operational | Single incident; metric breach < 24 hours; no settlement impact | Head of Operations | Partner operations team / NOC | Same business day |
| L2 - Management | Recurring breach (2+ times in 30 days); settlement delay > T+2; transaction success rate < 93% | COO / Head of Payments | Partner Head of Partnerships or equivalent | Within 3 business days |
| L3 - Executive | Sustained breach > 3 months; settlement dispute > $50,000; systemic failure affecting Simpaisa customers | CEO / CDO | Partner C-level | Within 10 business days; formal remediation plan required |
Escalation protocol:
- All incidents are logged in the internal incident management system (ticketing tool) with timestamp, severity, and partner reference.
- L1 escalations are managed operationally without board visibility unless unresolved after 48 hours.
- L2 escalations are reported in the monthly operational SLA review and flagged to the CDO.
- L3 escalations are reported in the next Board Risk Update and trigger a formal Remediation Notice to the partner.
S3.4 Performance Review Cadence¶
| Review Type | Frequency | Participants | Output |
|---|---|---|---|
| Operational SLA Review | Monthly | Head of Operations, relevant channel manager, partner operations contact | SLA scorecard; open incidents log; action items with owners and due dates |
| Strategic Partner Review | Quarterly | COO / CDO, partner Head of Partnerships or Country Manager | Trend analysis; commercial performance; roadmap alignment; escalated issues |
| Annual Partner Assessment | Annually | CEO / CDO / CFO, partner senior leadership | Renewal terms; strategic alignment; contract renegotiation if warranted |
S3.5 Commercial Consequences for Persistent SLA Breach¶
Where a partner fails to meet SLA thresholds persistently (defined as three or more consecutive months in breach of any Critical Threshold), Simpaisa reserves the following rights under standard partner contracts:
| Consequence | Trigger | Process |
|---|---|---|
| Service Credit | Availability or success rate below Critical Threshold for 1 month | Simpaisa issues a credit note to be offset against next invoiced amounts or service fees |
| Remediation Notice | Any Critical Threshold breach sustained for 2 consecutive months | Formal written notice requiring a root-cause analysis and remediation plan within 10 business days |
| Volume Rebalancing | Persistent breach affecting transaction success; operational impact on Simpaisa customers | Simpaisa re-routes transaction volume to alternative rails without penalty; partner notified |
| Contract Review | 3+ consecutive months in breach of any Critical Threshold | Formal contract review; Simpaisa may terminate with 30 days' notice under the for-cause termination clause |
| Termination for Cause | Material and sustained failure; failure to deliver remediation plan | Termination with notice per contract terms; recovery of settlement float or owed amounts |
S3.6 Current Partner SLA Status¶
Status as at April 2026. Formal SLA documentation status and current performance rating are noted.
| Partner | Category | Formal SLA in Place | Availability (Last 30 Days) | Success Rate (Last 30 Days) | Settlement Timing | Overall Status | Notes |
|---|---|---|---|---|---|---|---|
| Easypaisa | MNO / Pay-In / Pay-Out (PK) | TBC | TBC | TBC | TBC | Under review | Key Pakistan corridor; SLA formalisation priority |
| JazzCash | MNO / Pay-In / Pay-Out (PK) | TBC | TBC | TBC | TBC | Under review | High volume; formal SLA to be executed |
| bKash | MNO / Pay-In / Pay-Out (BD) | TBC | TBC | TBC | TBC | Under review | Bangladesh primary rail |
| Nagad | MNO / Pay-In / Pay-Out (BD) | TBC | TBC | TBC | TBC | Under review | Secondary Bangladesh rail |
| 1LINK | Interbank Switch (PK) | TBC | TBC | TBC | TBC | Under review | Domestic Pakistan bank transfers |
| Visa | Card Network | Yes (Visa standard) | TBC | TBC | TBC | Active | Governed by Visa network agreements |
| Mastercard | Card Network | Yes (MC standard) | TBC | TBC | TBC | Active | Governed by Mastercard network agreements |
| AWS | Cloud Infrastructure | Yes (AWS BAA / SLA) | 99.99% (contractual) | N/A | N/A | Compliant | Region: ap-south-1 and me-central-1 |
| Cloudflare | CDN / DDoS Protection | Yes (Enterprise) | TBC | N/A | N/A | Active | Review enterprise SLA terms annually |
| Eastnets | SWIFT / Compliance Screening | TBC | TBC | TBC | TBC | Under review | Sanctions screening and SWIFT connectivity |
| Binance | Crypto Off-Ramp | TBC | TBC | TBC | TBC | Under review | Formalise SLA as crypto volume grows |
Action: Head of Operations to complete formal SLA documentation for all partners marked "Under review" by Q3 2026. CDO to approve final SLA templates.
Appendix S4: Board Reporting Pack Template¶
Purpose¶
This appendix defines the standard structure and content requirements for Simpaisa's monthly and quarterly Board reporting pack. It specifies the data to be presented on each page, the responsible owner, the data source, and recommendations for automation. The objective is to ensure the Board receives consistent, high-quality management information with minimal manual preparation effort.
Pack frequency: Monthly (operational metrics); Quarterly (strategic review, full pack)
Distribution: Board members, CEO, CFO, CDO, COO, General Counsel
Preparation owner: CDO (technology and data pages), CFO (financial pages), COO (operational pages)
Submission deadline: By the 10th calendar day of the following month
S4.1 Page 1 - Executive Summary Dashboard¶
Purpose: Single-page snapshot of Simpaisa's health across five headline metrics. Must be self-contained - a Board member reading only this page should understand the state of the business.
| Metric | Definition | Target | Data Source | Owner |
|---|---|---|---|---|
| Gross Transaction Volume (GTV) | Total value of transactions processed in the period | Per approved budget | Transaction processing system | CFO |
| Revenue | Net revenue after payment partner costs | Per approved budget | Finance system | CFO |
| Active Merchants | Merchants with at least one successful transaction in the period | Month-on-month growth target | Merchant platform | CPO |
| Overall Transaction Success Rate | Percentage of initiated transactions completed successfully | 95.0%+ | Transaction monitoring system | COO / Head of Operations |
| Compliance Status | RAG status across all regulatory obligations, licences, and open findings | All Green | Compliance management system | CCO / General Counsel |
Format: 5 metric cards with current value, prior period comparison, and trend indicator. One paragraph of CEO commentary. One paragraph flagging any material events.
Automation recommendation: Connect BI dashboard (Metabase or equivalent) directly to transaction database and finance system. CEO commentary remains manual; all metrics should be auto-populated by day 5 of the month.
S4.2 Page 2 - Financial Summary¶
Purpose: Board-level financial overview for the period. Not a replacement for full management accounts.
| Section | Content | Data Source |
|---|---|---|
| P&L Summary | Revenue, direct costs (payment partner fees, FX costs), gross margin, operating expenses, EBITDA. Actual vs. budget vs. prior period. | Finance system (Xero / NetSuite) |
| Cash Position | Group cash by entity and currency. Minimum operating cash threshold. | Treasury / Finance system |
| FX Exposure | Notional exposure by currency pair (PKR, BDT, NPR, IQD, AED). Mark-to-market movement vs. prior period. | FX management system / Finance |
| Settlement Float | Total settlement float outstanding (funds in transit between corridors). Aging analysis: < T+1, T+1 to T+3, > T+3. | Reconciliation engine |
Key ratios to include: Gross margin %, operating cost per transaction, revenue per active merchant.
Automation recommendation: Daily automated feed from finance system to reporting template. Float aging from reconciliation engine. FX exposure from treasury system.
S4.3 Page 3 - Operational KPIs¶
Purpose: Drill-down into operational performance by country, product, and payment method.
| Dimension | Metrics Reported |
|---|---|
| By Country | GTV, transaction count, success rate, active merchants, revenue contribution |
| By Product | Pay-In, Pay-Out, Remittance, Crypto Off-Ramp, White-Label Wallet - GTV, volume, margin |
| By Payment Method | Mobile money, bank transfer, card, crypto - volume and success rate |
| Processing Quality | Average processing time (P50 / P99), error rate by type, chargeback rate |
| Customer Service | Support ticket volume, first-response time, resolution time, open escalations |
Format: Structured tables with period-on-period comparison. Traffic light indicators for metrics outside target range.
Automation recommendation: Transaction monitoring system provides the majority of operational data. Target a single integrated dashboard exportable to PDF for Board distribution.
S4.4 Page 4 - Risk Heat Map¶
Purpose: Top 5 risks facing the Group, with movement indicators from the prior period.
| Column | Definition |
|---|---|
| Risk | Short descriptive title |
| Category | Regulatory / Operational / Technology / Financial / Strategic |
| Likelihood | 1 (Low) to 5 (Very High) |
| Impact | 1 (Minimal) to 5 (Severe) |
| Risk Score | Likelihood × Impact |
| Movement | Up / Down / Stable vs. prior period |
| Owner | Named executive |
| Mitigations | 2–3 bullet points |
| Next Review | Date |
Format: Heat map matrix (5×5 grid) with the top 5 risks plotted. Accompanied by a brief narrative on each risk.
Worked example for current period:
| Risk | Category | Likelihood | Impact | Score | Movement |
|---|---|---|---|---|---|
| DFSA Cat 3D licence delay | Regulatory | 3 | 5 | 15 | Stable |
| Pakistan FX controls impacting settlement | Financial | 3 | 4 | 12 | Up |
| Key-person dependency - engineering | Operational | 4 | 3 | 12 | Stable |
| Third-party payment partner outage | Operational | 3 | 4 | 12 | Down |
| Cybersecurity - external attack surface | Technology | 2 | 5 | 10 | Stable |
Automation recommendation: Risk register maintained in a dedicated risk management tool or structured spreadsheet. Movement indicators are manually assessed by the CCO and CDO. Board pack extract is generated monthly.
S4.5 Page 5 - Regulatory Update¶
Purpose: Status of all Simpaisa regulatory licences, pending filings, and regulator engagements across all active jurisdictions.
| Section | Content |
|---|---|
| Licence Status Table | All licences by entity and jurisdiction. Status: Active / Pending Renewal / Application In Progress / Not Yet Applied. Expiry date. Renewal lead time. |
| Pending Filings | All regulatory submissions due in the next 90 days. Owner and target submission date. |
| Regulator Engagements | Material meetings, correspondence, or examinations with regulators in the period. Summary and outcome. |
| Open Findings | Any outstanding regulatory findings or remediation plans. Status and target closure date. |
| Upcoming Regulatory Changes | Material changes to applicable law or regulation in the next 6 months. Impact assessment. |
Key jurisdictions to cover: DFSA (UAE/DIFC), SBP (Pakistan), Bangladesh Bank, Nepal Rastra Bank, CBI (Iraq), SAMA (Saudi - pending), MAS (Singapore).
Automation recommendation: Licence register maintained in compliance management system. Automated reminders at 180, 90, and 30 days before expiry. Board pack section extracted manually by the CCO.
S4.6 Page 6 - Technology and Security¶
Purpose: Engineering health, system reliability, and information security posture for the period.
| Metric | Definition | Target | Source |
|---|---|---|---|
| System Uptime | Production environment availability | 99.9% | Monitoring platform (Datadog / equivalent) |
| P1 / P2 Incidents | Count of severity 1 and 2 incidents in the period | Zero P1; < 2 P2 per month | Incident management system |
| Mean Time to Recovery (MTTR) | Average time to restore service following incident | < 1 hour (P1); < 4 hours (P2) | Incident management system |
| Deployment Frequency | Number of production deployments in the period | Weekly minimum (path to daily) | CI/CD pipeline |
| Change Failure Rate | Percentage of deployments causing a production incident | < 5% | CI/CD pipeline / Incident log |
| Security Posture | Open critical and high vulnerabilities; penetration test status; SOC alert volume | Zero critical open; all highs < 30 days | SIEM / Vulnerability management |
| Data Protection | DSARs received and responded to; data incidents | All DSARs responded within 30 days | Compliance system |
Narrative section: CISO to provide a one-paragraph security commentary noting any material events, threat intelligence highlights, or audit progress (e.g., ISO 27001 surveillance status).
Automation recommendation: Monitoring platform exports to dashboard. CI/CD pipeline reports deployment metrics automatically. Security metrics from SIEM are partially automated; CISO commentary is manual.
S4.7 Page 7 - People¶
Purpose: Group headcount, attrition, talent pipeline, and key people movements in the period.
| Section | Content |
|---|---|
| Headcount Summary | Total headcount by entity and location. Permanent vs. contractor split. Month-on-month movement. |
| Attrition | Voluntary attrition rate (annualised). Regrettable vs. non-regrettable. Trending. |
| Key Hires | New joiners in senior or critical roles in the period. |
| Open Positions | Roles in active recruitment, with priority rating and days open. |
| Succession Gaps | Roles with no identified internal successor. |
| Employee Relations | Any material ER matters (anonymised). |
Format: Org-level summary table; brief narrative on talent risks.
Automation recommendation: HRIS (BambooHR / HiBob) provides headcount and attrition automatically. Recruitment pipeline from ATS. Senior management review of people commentary remains manual.
S4.8 Page 8 - Strategic Initiatives¶
Purpose: Progress against the CDO 90-day plan and key expansion milestones.
| Section | Content |
|---|---|
| CDO 90-Day Plan Progress | RAG status against each initiative. Completed, on track, at risk, delayed. |
| Expansion Milestones | Saudi Arabia, Central Asia, and other market-entry milestones. Planned vs. actual. |
| Product Roadmap Highlights | Key releases in the period. Upcoming releases in next 30 days. |
| Investment Initiatives | Status of any funded strategic programmes (e.g., platform modernisation, ISO 27001). |
Format: Initiative table with traffic-light status. One-paragraph CDO commentary on strategic priorities.
Automation recommendation: Project management tooling (Jira / Linear) provides status updates. Board pack section is manually synthesised by the CDO.
Appendix S5: OKR Framework¶
Purpose¶
This appendix defines Simpaisa's Objectives and Key Results (OKR) framework: the methodology, cascade structure, example OKRs for Q3 2026, scoring approach, review cadence, and tooling recommendation. OKRs are the primary mechanism by which the Board's strategic ambitions are translated into measurable team-level priorities.
S5.1 OKR Methodology¶
An OKR consists of:
- Objective: A qualitative, inspiring statement of what the team intends to achieve in the quarter. It should be meaningful and directional - not a metric in itself.
- Key Results (KRs): Three to five measurable outcomes that define what "achieving" the Objective looks like. Each KR must have a clear metric, a baseline, and a target. KRs describe outcomes, not activities.
Distinction from tasks: KRs are not task lists. "Complete penetration test" is a task. "Reduce critical open vulnerabilities from 12 to zero" is a Key Result.
Scope: OKRs are set at the company, division, and department level. Individual OKRs are optional and recommended only for senior individual contributors and above.
Cadence: Quarterly. OKRs are set in the final two weeks of the preceding quarter and are live for the full quarter. They are not changed mid-quarter except under exceptional circumstances approved by the CEO.
Ambition: OKRs should be aspirational. A score of 0.7 out of 1.0 is considered a strong result. Consistent scores of 1.0 may indicate insufficient ambition.
S5.2 Cascade Structure¶
OKRs flow top-down but are not purely dictated. Each level sets its OKRs in dialogue with the level above.
Board (Annual Strategic Goals)
|
CEO (Quarterly Company OKRs)
|
+--> CDO / COO / CFO / CCO (Division OKRs)
|
+--> Department Heads (Department OKRs)
|
+--> Team Leads (Team OKRs, optional)
Alignment check: Before finalising each quarter's OKRs, the CEO reviews all division-level OKRs to confirm alignment with company OKRs. Division heads review department OKRs similarly.
Cross-functional OKRs: Where a Key Result requires contribution from multiple departments, a primary owner is named and contributing owners are noted. Progress tracking is the primary owner's responsibility.
S5.3 Example OKRs - Q3 2026 (July – September 2026)¶
CEO - Company-Level OKR¶
Objective: Secure Simpaisa's regulatory foundation to operate as a regulated payments institution in the DIFC.
| # | Key Result | Baseline | Target | Owner |
|---|---|---|---|---|
| KR1 | Submit DFSA Category 3D licence application with zero Material Deficiency notices from DFSA | Application not yet submitted | Application submitted; first review response received without Material Deficiency | CCO |
| KR2 | Complete all required DFSA pre-application meetings with a DFSA engagement plan signed off by CEO | 0 meetings completed | 3+ formal meetings; engagement plan approved | CEO / CCO |
| KR3 | Appoint a DIFC-resident Senior Executive Officer (SEO) meeting DFSA Authorised Individual requirements | Role vacant | SEO appointed and DFSA Authorised Individual application submitted | CEO / CHRO |
| KR4 | Resolve all Category A and B DFSA Gap Analysis findings | 14 open findings | 0 open Category A findings; < 3 open Category B findings | CDO / CCO |
CDO - Division OKR¶
Objective: Establish a Site Reliability Engineering (SRE) foundation that enables Simpaisa to operate production systems with confidence and measure reliability scientifically.
| # | Key Result | Baseline | Target | Owner |
|---|---|---|---|---|
| KR1 | Define and instrument Service Level Objectives (SLOs) for all three core production services | SLOs not defined | SLOs defined, instrumented, and reported on a live dashboard for all three services | Head of Engineering |
| KR2 | Achieve a P1 Mean Time to Recovery (MTTR) of under 60 minutes for production incidents | MTTR not formally measured | MTTR < 60 minutes in 80%+ of P1 incidents in the quarter | Head of Engineering / Head of Ops |
| KR3 | Conduct and complete post-incident reviews (PIRs) for 100% of P1 and P2 incidents within 48 hours | PIR completion rate < 40% | 100% PIR completion rate; PIR findings tracked to closure | Head of Engineering |
| KR4 | Reduce change failure rate from current baseline to below 5% | TBC (establish baseline in Month 1) | < 5% change failure rate by end of quarter | CTO / Head of Engineering |
CTO - Department OKR¶
Objective: Achieve daily deployment capability for the payments core team, reducing batch risk and accelerating delivery throughput.
| # | Key Result | Baseline | Target | Owner |
|---|---|---|---|---|
| KR1 | Payments core team achieves a deployment frequency of at least 5 deployments per week without increasing incident rate | < 1 deployment per week | 5+ deployments per week in 8 of 12 weeks | Engineering Lead - Core |
| KR2 | CI pipeline build and test time reduced to under 10 minutes for the core payments service | TBC (establish baseline in Week 1) | < 10 minutes median CI run time | Head of Engineering |
| KR3 | 100% of production deployments for payments core use automated rollback capability | 0% automated rollback | 100% deployments include automated rollback; at least 1 rollback tested in staging per sprint | Engineering Lead - Core |
| KR4 | Zero manual production deployments for the payments core service by end of quarter | Estimated 30%+ manual steps | Zero manual deployments confirmed via CI/CD audit | CTO / Head of Engineering |
CPO - Department OKR¶
Objective: Deliver White-Label Wallet v1.0 to the first enterprise customer and establish the foundation for scalable wallet deployments.
| # | Key Result | Baseline | Target | Owner |
|---|---|---|---|---|
| KR1 | White-Label Wallet v1.0 launched to at least one paying enterprise customer in production | In development | Live in production; first customer transaction processed | CPO / Product Lead - Wallet |
| KR2 | Wallet onboarding time (from contract signature to first transaction) reduced to 30 days or fewer | Not yet measured | < 30 days for first customer; process documented for replication | CPO / Head of Implementations |
| KR3 | Wallet v1.0 NPS score from first customer's admin team is 7 or above (out of 10) | No prior measure | NPS ≥ 7 from structured post-launch survey | CPO |
| KR4 | Wallet product roadmap for v1.1 (Q4 2026) agreed and signed off by CDO | Not started | Roadmap approved with committed delivery items | CPO / CDO |
CISO - Department OKR¶
Objective: Complete the ISO 27001 surveillance audit cycle with zero non-conformities, demonstrating a mature and operational Information Security Management System (ISMS).
| # | Key Result | Baseline | Target | Owner |
|---|---|---|---|---|
| KR1 | ISO 27001 surveillance audit completed with zero Major non-conformities and zero Minor non-conformities | Certification held; surveillance audit due Q3 | Audit completed; certificate of continued compliance issued | CISO |
| KR2 | 100% of ISO 27001 mandatory controls reviewed and evidenced in the ISMS for the audit period | Evidence completeness TBC | All mandatory controls with dated evidence in ISMS by audit commencement | CISO / Information Security team |
| KR3 | All critical and high-severity vulnerabilities identified in the annual penetration test closed within 30 days of report | TBC | 100% of critical findings closed; 100% of high findings with accepted remediation plan | CISO / Engineering |
| KR4 | Security awareness training completion rate across all staff reaches 95%+ | < 60% completion rate | 95%+ completion; phishing simulation click rate below 5% | CISO / HR |
S5.4 Scoring Methodology¶
OKRs are scored at the end of each quarter. Each Key Result is scored on a scale of 0.0 to 1.0.
| Score | Meaning |
|---|---|
| 0.0 – 0.3 | Not achieved; minimal progress |
| 0.4 – 0.6 | Partial achievement; meaningful progress but fell short |
| 0.7 – 0.9 | Strong achievement; this is the target range for well-set OKRs |
| 1.0 | Fully achieved; consider whether the target was ambitious enough |
Objective score: The average of all Key Result scores for that Objective.
Scoring is descriptive, not punitive. A score of 0.6 with a clear explanation is more valuable than a score of 1.0 achieved by setting easy targets. Managers should create an environment where honest scoring is safe and expected.
Cross-functional KRs are scored by the primary owner; contributing owners provide input.
S5.5 Review Cadence¶
| Touchpoint | Frequency | Participants | Output |
|---|---|---|---|
| Weekly OKR Check-in | Weekly (15 minutes) | Team lead with direct reports | Confidence score update (on track / at risk / blocked) for each KR; surface blockers early |
| Monthly Scoring and Review | Monthly (during leadership team meeting) | Division head with department heads | Updated scores; identify KRs that need a reset or additional resource; escalate blockers to CEO |
| Quarterly OKR Review | End of quarter | CEO with all division heads; Board sighted at next Board meeting | Final scores; retrospective on what worked and what did not; input into next quarter's OKR setting |
| Annual Strategic Alignment | Once per year (Q4 for following year) | Board → CEO → leadership team | Set company-level OKRs for the year; provide direction for quarterly cascades |
OKR setting timeline (each quarter):
- Week 10 of current quarter: CEO communicates company priorities for next quarter.
- Week 11: Division heads draft division OKRs; department heads draft department OKRs.
- Week 12: Alignment review; cross-functional dependencies agreed.
- Week 13: OKRs finalised and published to all staff.
- Week 1 of new quarter: OKR cycle begins.
S5.6 Tooling Recommendation¶
| Stage | Recommended Approach | Rationale |
|---|---|---|
| Current (< 200 employees) | Google Sheets or Notion | Low overhead; easy to share; no procurement or training cost; sufficient for current scale |
| Near-term (200–350 employees) | Evaluate dedicated OKR tooling | At this scale, the overhead of spreadsheet management and cross-team visibility gaps justify dedicated tooling |
| Recommended tools to evaluate at 250+ headcount | Lattice, Leapsome, or Perdoo | All three integrate with HRIS; support cascade structure; provide real-time scoring dashboards |
| Not recommended at current scale | Jira OKR plugins, Workday Goals | Jira plugins are engineering-centric and create friction for non-technical teams; Workday Goals requires full Workday HRIS adoption |
Implementation principle: The OKR process should take less than 30 minutes per person per week to maintain. If it is taking more, the process is over-engineered for current headcount. Simplicity is a feature.
End of Supplementary Documents
Document control
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | April 2026 | CDO Office | Initial draft |
Classification: Confidential - Simpaisa Group Internal Use