Simpaisa Group - DFSA Regulatory Suite¶

Confidential | Board-Approved Documentation Version 1.0 | April 2026

Document Registry¶

Ref	Title	Owner	Approver	Version
SGP-CDO-002	Cyber Incident Response Plan	CISO (Danish Hamid)	Board	1.0
SGP-OPS-004	Business Continuity and Disaster Recovery Plan	CDO (Daniel O'Reilly)	Board	1.0
SGP-CDO-006	Data Privacy and Protection Policy	CDO (Daniel O'Reilly)	Board	1.0
SGP-GOV-007	Conduct Risk Framework	COO (Kamil Shaikh)	Board	1.0

SGP-CDO-002 - Cyber Incident Response Plan¶

Classification: Confidential - Restricted
Owner: Chief Information Security Officer (Danish Hamid)
Executive Sponsor: Chief Digital Officer (Daniel O'Reilly)
Approver: Board of Directors
Version: 1.0
Effective Date: 1 April 2026
Next Review: 1 April 2027

1. Purpose and Scope¶

1.1 Purpose¶

This Cyber Incident Response Plan (CIRP) establishes the procedures, roles, responsibilities, and decision-making authorities that Simpaisa Group ("Simpaisa" or "the Group") will invoke when a cyber security incident occurs or is suspected. The CIRP is designed to minimise the impact of cyber incidents on customers, merchants, employees, regulators, and the business, and to ensure that Simpaisa meets its regulatory obligations across all operating jurisdictions.

This plan is aligned with Simpaisa's Site Reliability Engineering (SRE) operating model, which emphasises automated runbooks, on-call rotations, and rapid response without dependence on traditional Change Advisory Board processes.

1.2 Scope¶

This plan applies to:

All legal entities within Simpaisa Group across all nine operating jurisdictions.
All employees, contractors, and third parties with access to Simpaisa systems.
All technology assets: cloud infrastructure (AWS multi-region), Cloudflare edge network, SaaS platforms, internal tools, payment rails, and end-point devices.
All product lines: Pay-Ins, Pay-Outs, Remittances, Crypto services, and White-Label Wallets.

1.3 Relationship to Other Plans¶

This CIRP operates in conjunction with:

SGP-OPS-004: Business Continuity and Disaster Recovery Plan
SGP-CDO-001: Data Governance Policy
SGP-CDO-006: Data Privacy and Protection Policy
Crisis Management Plan (CMP)
SGP-GOV-002: Whistleblowing Policy

2. Incident Classification¶

All cyber incidents are classified at the point of triage. Classification determines response speed, escalation path, and regulatory notification obligations. Classifications may be upgraded or downgraded as the incident evolves.

2.1 Priority Levels¶

Priority	Label	Definition	Examples	Initial Response Time
P1	Critical	Confirmed or high-confidence breach of systems or data, active threat in environment, operational impact to payment processing	Confirmed data breach (PII, PAN, credentials); ransomware active in environment; full system compromise; active exfiltration; payment fraud attack in progress	Immediate - within 15 minutes
P2	High	Targeted attack that has been contained, or confirmed credential compromise without confirmed data access	Targeted spear-phishing with credential harvest; insider threat confirmed; third-party supply chain breach with potential impact; contained intrusion attempt	Within 1 hour
P3	Medium	Malware detected and isolated, successful phishing attack, suspicious access patterns confirmed	Malware quarantined on endpoint; employee clicked phishing link with credential submission; anomalous API access confirmed; DDoS causing degradation	Within 4 hours
P4	Low	Unsuccessful attack, reconnaissance activity, policy violation with no data impact	Port scanning; failed brute-force; firewall block of suspicious IP; minor policy violation; spam campaign with no credential compromise	Within 24 hours

2.2 Classification Criteria¶

The SOC Lead performs initial classification using the following factors:

Confidentiality impact: Has data been accessed, copied, or exfiltrated without authorisation?
Integrity impact: Have systems, data, or configurations been altered without authorisation?
Availability impact: Is there degradation or loss of access to critical systems or services?
Financial crime indicators: Is there evidence of fraud, money laundering, or sanctions evasion?
Regulatory scope: Does the incident affect regulated entities or regulated data?
Customer/merchant impact: Are customer funds, data, or service continuity at risk?

3. Roles and Responsibilities¶

3.1 Core Incident Response Team¶

Role	Individual	Primary Responsibilities
Incident Commander	CISO - Danish Hamid	Overall command and control; escalation decisions; regulatory notification sign-off; external communications approval
Executive Sponsor	CDO - Daniel O'Reilly	Board and senior executive liaison; final authority on business decisions during incident; Crisis Management Plan activation
SOC Lead	Head of Security Operations	Initial triage, classification, and detection; alert correlation; escalation to Incident Commander
Cloud Security Engineer	Senior Cloud Security Engineer	Cloud containment actions; AWS security group modifications; Cloudflare rule deployment; evidence preservation in cloud environments
DevSecOps Lead	Head of DevSecOps	Eradication of malicious code or configurations; pipeline integrity verification; patch deployment via runbooks
Head of Legal	General Counsel	Legal hold instructions; regulatory notification drafting; law enforcement liaison; privilege protection
MLRO	Shoukat Bizinjo	Financial crime assessment; SAR/STR filing where required; coordination with AML/CFT team
COO	Kamil Shaikh	Operational continuity decisions; BCP/DR invocation; supplier notifications
Communications Lead	Head of Marketing / Corporate Communications	Customer and merchant communications; press enquiries; social media monitoring

3.2 Extended Response Team¶

Additional specialists are engaged as required:

Head of People: Employee matters, insider threat HR process.
Country Managers (PK, BD, NP, IQ, CA, UK, SG): Local regulatory liaison and customer impact assessment.
External IR Retainer: CrowdStrike Falcon Complete, Mandiant Consulting, or NCC Group - engaged at CISO discretion for P1 incidents or where internal forensic capacity is exceeded.
AWS Security Team: Engaged via AWS support channels for infrastructure-level investigations.
Cloudflare Security Team: Engaged for edge-layer attack analysis and emergency rule deployment.

3.3 SRE On-Call Integration¶

Simpaisa operates a 24/7 SRE on-call rotation. The on-call SRE is the first operational responder for all infrastructure and service alerts. The SRE on-call:

Receives PagerDuty alerts correlated with security events.
Executes automated runbooks for known incident patterns.
Escalates to the SOC Lead where security incident criteria are met.
Does not unilaterally classify an event as a security incident; that determination rests with the SOC Lead.

There is no Change Advisory Board (CAB) process within Simpaisa's incident response. Emergency changes during an incident are authorised by the Incident Commander and documented post-action. All automated runbook executions are logged in the ITSM system.

4. Response Phases¶

4.1 Phase 1 - Detection¶

Detection may occur through multiple channels:

SIEM alert (AWS Security Hub, GuardDuty, CloudTrail anomaly).
SOC monitoring alert.
SRE on-call PagerDuty escalation.
Employee report (phishing, suspicious behaviour).
Third-party notification (AWS, Cloudflare, payment network partner).
Regulatory notification from peer institution.
External intelligence feed.
Customer or merchant complaint.

Actions:

SRE on-call or SOC analyst receives and acknowledges alert within 15 minutes.
Initial evidence is captured: timestamps, alert source, affected systems, initial indicators of compromise (IoCs).
The incident is logged in the incident management platform (PagerDuty / Jira Security project) with a unique incident reference (INC-YYYY-NNNN).
SOC Lead is notified immediately for any event with potential P1 or P2 indicators.

4.2 Phase 2 - Triage¶

Owner: SOC Lead
Objective: Confirm whether a genuine security incident exists, assign priority classification, and activate the appropriate response team.

Actions:

SOC Lead reviews evidence and performs initial classification (P1–P4).
For P1: CISO is notified within 15 minutes; CDO within 30 minutes; Head of Legal within 1 hour.
For P2: CISO is notified within 1 hour; CDO within 2 hours.
Incident severity is recorded in the incident log with the rationale for classification.
MLRO is notified if any financial crime indicators are present (unusual transactions, sanctions hits, fraud patterns coinciding with the incident).
Initial regulatory notification clock begins: the 72-hour clock for DFSA starts from the point at which the organisation becomes aware of an incident that may constitute a reportable breach.
External IR retainer is placed on standby for P1 incidents.

4.3 Phase 3 - Containment¶

Owner: Cloud Security Engineer (technical); CISO (command)
Objective: Stop the spread and limit the impact of the incident without destroying evidence.

Short-Term Containment Actions (first 4 hours):

Network isolation of affected instances via AWS Security Group modifications (emergency runbook: SEC-RUN-001).
Revocation of compromised credentials: IAM users, service accounts, API keys, OAuth tokens (runbook: SEC-RUN-002).
Cloudflare emergency rules deployed to block known malicious IPs, ASNs, or request patterns (runbook: SEC-RUN-003).
WAF rule deployment to block attack vectors identified during triage.
Suspension of affected user accounts pending investigation.
API rate limiting or circuit-breaker activation for affected payment endpoints.
Isolation of affected endpoints from corporate network (MDM-enforced quarantine where applicable).

Long-Term Containment Actions (4–48 hours):

Replacement of affected infrastructure via immutable infrastructure rebuild (Terraform / CloudFormation).
Deployment of additional logging and monitoring on adjacent systems.
Enhanced DLP rules applied to data egress paths.
Payment partner notifications where transaction integrity may be affected.

Evidence Preservation (concurrent with containment):

Evidence preservation is initiated in parallel with containment and must not be sacrificed for speed of remediation. The Cloud Security Engineer is responsible for:

Forensic snapshots of affected EC2 instances and RDS databases before any modification.
Preservation of CloudTrail, VPC Flow Logs, and application logs to a write-once S3 bucket with Object Lock enabled (runbook: SEC-RUN-004).
Memory acquisition where technically feasible (via AWS Systems Manager or endpoint agent).
Maintenance of a chain of custody log for all forensic artefacts (template: SEC-FORM-001).
Legal hold instruction from Head of Legal to prevent automated log purging.

4.4 Phase 4 - Eradication¶

Owner: DevSecOps Lead
Objective: Remove the threat actor, malicious code, and all backdoors from the environment.

Actions:

Root cause analysis performed in parallel with containment to identify the attack vector, entry point, and persistence mechanisms.
All malicious code, files, and scheduled tasks removed from affected systems.
Compromised infrastructure rebuilt from clean, signed base images via CI/CD pipeline with enhanced security scanning (Snyk, Trivy, Checkov checks mandatory).
All secrets rotated: database passwords, API keys, certificates, encryption keys, HSM credentials.
Dependency and supply chain verification: confirm integrity of all third-party libraries and packages in use.
Vulnerability that allowed the incident to occur is patched or mitigated before systems are returned to service.
DevSecOps Lead confirms eradication in writing to the CISO before recovery phase commences.

4.5 Phase 5 - Recovery¶

Owner: COO (operational decisions); CTO - Saqlain Raza (technical execution)
Objective: Restore affected systems to normal operation safely and in a controlled manner.

Actions:

Recovery plan approved by CISO and CDO before any affected system is returned to production.
Phased restoration: lowest-risk, highest-criticality services first (payment processing core before ancillary services).
Enhanced monitoring maintained for a minimum of 72 hours post-recovery to detect reinfection or residual threat activity.
Smoke testing and transaction integrity checks performed before full traffic is restored.
Payment partners and settlement counterparties notified of restoration timeline and confirmed operational status.
For P1 incidents: staged restoration with manual approval gates between each phase.
Regulatory bodies notified of containment and recovery progress as required by notification schedules.

4.6 Phase 6 - Post-Incident Review (Lessons Learned)¶

Owner: CISO
Objective: Understand what happened, why it happened, and prevent recurrence. Conducted on a blameless basis.

Timeline: Blameless post-incident review (PIR) conducted within 5 business days of incident closure for P1/P2; within 10 business days for P3/P4.

PIR Structure:

Timeline reconstruction: Minute-by-minute reconstruction of detection, response, and recovery actions.
Root cause analysis: Five Whys or Ishikawa methodology. Technical, process, and human factors considered.
What went well: Actions that limited impact or accelerated response.
What could be improved: Gaps in detection, containment, communication, or tooling.
Action items: Specific, time-bound remediation actions with named owners and completion dates.
Runbook updates: Identify runbooks that require creation or amendment.
Regulatory reflection: Assess adequacy of regulatory communications and whether notification timelines were met.

PIR Output: A written PIR report (template: SEC-FORM-002) is distributed to CISO, CDO, COO, Head of Legal, and MLRO. Action items are tracked in the risk register. Material findings are reported to the Board Risk and Audit Committee.

5. Evidence Preservation and Forensics¶

5.1 Forensic Capability¶

Simpaisa maintains an internal SOC capability with forensic investigation tooling including:

AWS CloudTrail, GuardDuty, Security Hub, Macie, Inspector.
Endpoint detection and response (EDR) agent across all managed devices.
Network traffic analysis via VPC Flow Logs and Cloudflare Analytics.
SIEM platform for log aggregation and correlation.
Forensic workstation with write-blocker capability for physical media where applicable.

5.2 External IR Retainer¶

For P1 incidents or where the scope of investigation exceeds internal capability, Simpaisa maintains a pre-contracted retainer with an external incident response provider. Recommended providers:

CrowdStrike Services - preferred for cloud-native investigations and threat intelligence integration.
Mandiant (Google Cloud) - preferred for nation-state attribution and complex APT investigations.
NCC Group - alternative for regulated financial services forensic investigations.

The CISO has authority to invoke the external IR retainer without further approval for P1 incidents. For P2 and below, CDO approval is required.

5.3 Chain of Custody¶

All forensic evidence must be handled in accordance with the chain of custody procedure (SEC-PROC-001):

Evidence is logged at the point of acquisition with hash values, timestamps, and the name of the acquiring engineer.
Transfer of evidence between individuals is documented with signatures.
Evidence is stored in a segregated, access-controlled environment.
Evidence is retained for a minimum of 7 years or as directed by legal counsel, whichever is longer.
In jurisdictions where law enforcement may require evidence, the Head of Legal must be consulted before any evidence is handed over.

6. Regulatory Notification Obligations¶

Simpaisa is subject to multiple regulatory notification obligations across its operating jurisdictions. Notification timelines are measured from the point at which the organisation becomes aware of a reportable incident, not from the point of confirmation.

6.1 Notification Timelines by Jurisdiction¶

Regulator	Jurisdiction	Notification Timeline	Trigger	Contact
DFSA	Dubai (DIFC)	72 hours	Material cyber incident, operational incident, data breach	dfsa.ae - regulatory supervision portal
MAS	Singapore	1 hour (initial); full report within defined period	Incident affecting MAS-regulated operations	MAS Technology Risk incident notification form
SBP	Pakistan	4 hours (initial)	Cyber attack, fraud, operational disruption	SBP PRISM or designated regulatory email
FCA	United Kingdom	72 hours	Material operational incident; PCI-related breach	FCA Connect portal / Supervision team
PDPC	Singapore	3 calendar days	Data breach affecting personal data of Singapore residents	PDPC Breach Portal
ICO	United Kingdom	72 hours	Data breach affecting UK personal data	ICO online notification
FINTRAC	Canada	As soon as practicable	Incident affecting Canadian operations or customer data	FINTRAC - Compliance Officer notification
BB	Bangladesh	As soon as practicable	Incident affecting Bangladesh operations	Bangladesh Bank BFIU channel

Important: The Head of Legal and MLRO must be consulted before any regulatory notification is submitted. All notifications must be reviewed and approved by the CISO and CDO.

6.2 Notification Content¶

Initial regulatory notifications must include, at minimum:

Nature of the incident and systems affected.
Estimated number of customers or records affected.
Actions taken to contain and investigate.
Estimated timeline for full resolution and further reporting.

Notifications must not speculate on cause or attribution where these are not yet confirmed.

7. Customer and Merchant Notification¶

7.1 Notification Criteria¶

Customer and merchant notification is required where:

Personal data (PII, payment credentials, account data) has been confirmed or is likely to have been accessed without authorisation.
Account security has been directly compromised (e.g., credential breach).
Regulatory law requires notification (DIFC DPL 2020, UK GDPR, Singapore PDPA, etc.).
The CISO and Head of Legal jointly determine that notification is necessary to protect customer interests, regardless of regulatory mandate.

7.2 Notification Timeline¶

Customer and merchant notification occurs:

As soon as reasonably practicable after the breach is confirmed.
Only after regulatory notification has been submitted (except where regulatory guidance directs otherwise).
Where UK GDPR or DIFC DPL applies, notification to affected individuals is required without undue delay where the breach is likely to result in a high risk to their rights and freedoms.

7.3 Notification Template (Standard)¶

Dear [Customer / Merchant Name],

We are writing to inform you of a security incident that may have affected your account with Simpaisa.

What happened: On [date], we became aware of a security incident affecting [description of systems/data in non-technical terms].

What data was involved: [Specific categories of data - e.g., name, email address, transaction reference numbers].

What we have done: We have [containment actions in plain language]. We have also notified the relevant regulatory authorities.

What you should do: We recommend that you [specific actions - e.g., change your password, review recent transactions, contact your bank if you notice unusual activity].

Further information: If you have any questions, please contact our dedicated security incident team at [email protected] or call [number].

We sincerely apologise for any concern this may cause. The security of your data is our highest priority.

Yours sincerely, [CISO / CDO name and title]

Notification content must be approved by the Head of Legal and CISO before dispatch. Notifications are sent via the most secure and reliable channel available (email, in-app notification, or registered letter where appropriate).

8. Annual Cyber Incident Simulation Exercise¶

8.1 Exercise Programme¶

Simpaisa conducts an annual cyber incident simulation exercise to test the effectiveness of this plan, the readiness of the response team, and the currency of runbooks and contacts.

Exercise Format: Tabletop exercise (minimum) with optional live-fire technical component for P1 scenarios.

Scope: The exercise scenario is designed to test at least one P1 and one P2 scenario per year. Scenarios are rotated annually and must cover:

Data breach (PII and/or PAN) across at least two jurisdictions.
Ransomware attack on production infrastructure.
Insider threat (at least once every two years).
Supply chain compromise (at least once every two years).

Participants: CISO, CDO, COO, SOC Lead, Cloud Security Engineer, DevSecOps Lead, Head of Legal, MLRO, CTO, and country manager representatives.

External Involvement: The external IR retainer provider may be invited to participate or facilitate the exercise.

Output: Exercise report produced within 10 business days. Findings are incorporated into the CIRP update cycle. Board Risk and Audit Committee receives a summary of exercise findings.

8.2 Continuous Improvement¶

Runbooks are reviewed and updated following every P1 or P2 incident and annually as a minimum.
Threat intelligence feeds are reviewed quarterly.
CIRP is reviewed annually by the CISO and CDO and presented to the Board for re-approval.

9. Integration with Crisis Management Plan¶

Where a cyber incident escalates to a Group-wide crisis (reputational, regulatory, financial, or operational), the Crisis Management Plan (CMP) is invoked alongside this CIRP. The decision to invoke the CMP rests with the CDO, in consultation with the CISO and COO.

Crisis-level thresholds include:

Confirmed breach of more than 10,000 customer records.
Ransomware causing payment processing outage exceeding 4 hours.
Incident attracting media coverage or regulatory enquiry.
Estimated financial impact exceeding USD 1 million.
Any incident requiring Board notification within 24 hours.

When the CMP is invoked, the CIRP Incident Commander (CISO) continues to lead technical response while the CDO assumes the role of Crisis Director for overall Group management. The two plans operate in parallel with a joint coordination call convened at least twice daily.

10. Document Control¶

Field	Detail
Document Reference	SGP-CDO-002
Version	1.0
Effective Date	1 April 2026
Review Frequency	Annual
Next Review	1 April 2027
Owner	CISO - Danish Hamid
Executive Sponsor	CDO - Daniel O'Reilly
Approver	Board of Directors
Classification	Confidential - Restricted

SGP-OPS-004 - Business Continuity and Disaster Recovery Plan¶

Classification: Confidential - Restricted
Owner: Chief Digital Officer (Daniel O'Reilly)
Approver: Board of Directors
Version: 1.0
Effective Date: 1 April 2026
Next Review: 1 April 2027

1. Purpose and Scope¶

1.1 Purpose¶

This Business Continuity and Disaster Recovery Plan (BCP/DR Plan) defines the strategies, procedures, and responsibilities that Simpaisa Group will employ to maintain critical business functions and recover technology services following a disruptive event. It is designed to protect customers, merchants, employees, and the business from the consequences of operational disruption, whether caused by technology failure, cyber incident, natural disaster, pandemic, civil unrest, or third-party failure.

The plan reflects Simpaisa's technical architecture: active-active deployment across AWS multi-region infrastructure with Cloudflare edge failover, operated under an SRE model with automated recovery mechanisms.

1.2 Scope¶

This plan applies to:

All Simpaisa Group legal entities across nine operating jurisdictions.
All critical business functions and supporting technology systems.
All third-party dependencies that are material to business continuity.
All employees, with particular emphasis on recovery team members.

1.3 Objectives¶

Minimum Business Continuity: Maintain or rapidly restore critical payment processing and compliance functions.
Recovery Time Objective (RTO): The maximum tolerable period of disruption for each critical function - defined per function in Section 3.
Recovery Point Objective (RPO): The maximum acceptable data loss measured in time - defined per function in Section 3.
Regulatory Compliance: Ensure Simpaisa meets its obligations under DFSA, SBP, MAS, FCA, and other applicable regulatory frameworks regarding operational resilience.

2. Business Impact Analysis¶

2.1 Methodology¶

The Business Impact Analysis (BIA) identifies the Group's critical business functions, assesses the impact of their disruption, and determines recovery priorities. The BIA is reviewed annually and following any material change to the business. It was last reviewed in Q1 2026.

Impact dimensions assessed:

Financial: Direct revenue loss, settlement failures, penalty fees, regulatory fines.
Regulatory: Breach of licence conditions, notification obligations, supervisory action.
Reputational: Customer and merchant confidence, media coverage, brand damage.
Customer/Merchant: Inability to send or receive payments, failed remittances, locked funds.
Operational: Internal workflow disruption, staff inability to perform duties.

2.2 Critical Business Functions - Ranked by Priority¶

Rank	Function	Description	Impact of Disruption
1	Payment Processing	Real-time processing of pay-ins, pay-outs, and remittances across all corridors	Immediate revenue loss; customer funds at risk; regulatory breach; reputational damage
2	Settlement and Reconciliation	Inter-bank and payment network settlement; end-of-day reconciliation	Financial exposure; partner disputes; regulatory reporting failure
3	Compliance Screening	AML/CFT transaction screening via Eastnets; sanctions screening	Regulatory breach; DFSA licence at risk; potential legal liability
4	Merchant Portal	White-label wallet management; merchant API and dashboard	Merchant revenue impact; SLA breach; customer service escalations
5	Treasury Operations	Liquidity management; FX hedging; nostro account management	Financial risk; settlement failure; corridor shutdown
6	Customer Service	Customer and merchant support across all channels	Reputational impact; complaint escalation; regulatory notification

2.3 Supporting Functions¶

The following functions are essential to sustained operations but have a higher tolerance for short-term disruption:

People Operations and HR systems.
Internal finance and accounting (excluding settlement).
Marketing and communications.
Corporate IT and productivity tools (email, collaboration).

2.4 Maximum Tolerable Period of Disruption (MTPD)¶

Function	MTPD
Payment Processing	2 hours
Settlement and Reconciliation	4 hours
Compliance Screening	4 hours (with manual fallback)
Merchant Portal	8 hours
Treasury Operations	8 hours
Customer Service	24 hours

3. Recovery Strategies¶

3.1 Payment Processing¶

Architecture: Active-active across AWS multi-region (eu-west-1 and ap-southeast-1 as primary regions; us-east-1 available as tertiary) with Cloudflare load balancing and automatic failover.

RTO: Less than 2 hours (target: less than 30 minutes via automatic failover).
RPO: Zero (synchronous replication; no data loss accepted).
Recovery Strategy: Cloudflare automatically routes traffic away from a degraded region within minutes. AWS Route 53 health checks trigger DNS failover. Stateless application layer rebuilt via auto-scaling groups. Database layer uses Amazon Aurora Global Database with sub-second replication lag. No manual intervention required for standard region failover; automated runbook SEC-RUN-010 is triggered.
Manual Override: If automatic failover fails, SRE on-call executes SEC-RUN-011 (manual traffic steering via Cloudflare dashboard) within the RTO window.
Payment Network Dependencies: 1LINK (Pakistan), NPSB (Bangladesh), SWIFT, Visa, and Mastercard connectivity is maintained via redundant API gateways in each active region.

3.2 Settlement and Reconciliation¶

Architecture: Warm standby configuration with a primary settlement engine in eu-west-1 and warm standby in ap-southeast-1.

RTO: Less than 4 hours.
RPO: 15 minutes (asynchronous replication with 15-minute checkpoint intervals).
Recovery Strategy: Warm standby instance is promoted to primary via runbook OPS-RUN-020. In-flight transactions at the point of failure are replayed from the 15-minute checkpoint. Reconciliation team verifies transaction integrity before settlement batches are submitted. Manual reconciliation procedures (OPS-PROC-021) are available for the gap period if required.
Regulatory Reporting: Settlement reports to DFSA, SBP, and other regulators are generated from the recovered environment. Any delay in submission is proactively notified to the relevant regulator.

3.3 Compliance Screening (Eastnets)¶

Architecture: Eastnets FinScan hosted on dedicated AWS infrastructure with local caching of sanctions lists.

RTO: 4 hours for full automated screening; 1 hour for manual fallback.
RPO: 24 hours (sanctions list cache is refreshed daily; a 24-hour-old list is acceptable during an incident).
Manual Fallback Procedure: Within 1 hour of a screening outage, the Compliance team activates the manual screening protocol (COMP-PROC-001). All transactions above USD 1,000 (or local equivalent) are manually screened against a locally cached sanctions list prior to processing. Transactions below this threshold may be held in queue for up to 4 hours pending system restoration.
MLRO Authority: The MLRO (Shoukat Bizinjo) must be notified within 30 minutes of a compliance screening outage and must approve the manual fallback activation.
Eastnets SLA: Eastnets contractual SLA is reviewed as part of the third-party DR review (Section 8).

3.4 Merchant Portal¶

Architecture: Active-active deployment behind Cloudflare with AWS Application Load Balancer.

RTO: Less than 4 hours.
RPO: 1 hour (hourly snapshots of merchant configuration data).
Recovery Strategy: Active-active architecture means the portal remains available during single-region failure. In the event of a full platform outage, the merchant portal is restored from the most recent snapshot. Merchant API keys and configurations are stored in AWS Secrets Manager, replicated across regions.
Merchant Communication: If portal availability drops below 99.5% in a 24-hour period, the Communications Lead activates the merchant notification protocol (COMM-PROC-005).

3.5 Treasury Operations¶

RTO: Less than 8 hours.
RPO: 1 hour.
Recovery Strategy: Treasury systems are hosted on the same active-active infrastructure as payment processing. Manual treasury procedures (FIN-PROC-010) are available for nostro management and FX hedging decisions if systems are unavailable. The CFO (or delegated Head of Treasury) has authority to execute emergency FX transactions via pre-arranged banking channels without system support.
Liquidity Buffer: Simpaisa maintains a minimum liquidity buffer equivalent to 48 hours of average settlement volume in each operating corridor, providing a financial buffer during recovery.

3.6 Customer Service¶

RTO: Less than 24 hours.
RPO: 4 hours.
Recovery Strategy: Customer service is provided via cloud-based CRM (Salesforce / Zendesk). Loss of primary CRM access triggers fallback to email-based ticketing and, where necessary, telephone support. Country-level customer service teams maintain access to a read-only customer data extract (refreshed every 4 hours) for basic customer verification during an outage.

4. DR Architecture¶

4.1 AWS Multi-Region Architecture¶

Simpaisa operates an active-active architecture designed for resilience:

Primary Regions: eu-west-1 (Ireland) and ap-southeast-1 (Singapore) carry live production traffic simultaneously.
Tertiary Region: us-east-1 (Virginia) is available as a cold standby for catastrophic dual-region failure.
Database Layer: Amazon Aurora Global Database provides synchronous replication between primary regions with automatic failover in less than 30 seconds. RDS point-in-time recovery provides additional RPO protection.
Storage: S3 Cross-Region Replication ensures all object storage is duplicated across regions with versioning enabled.
Secrets Management: AWS Secrets Manager with cross-region replication; all secrets are rotated automatically on a 90-day schedule.
Container Orchestration: Amazon EKS clusters in each region with Kubernetes configurations managed via GitOps (ArgoCD). Failed region's workloads are automatically rescheduled by the surviving region's cluster.
Monitoring: Amazon CloudWatch with cross-region dashboards; PagerDuty for alerting; Grafana for SRE observability.

4.2 Cloudflare Edge Failover¶

Cloudflare provides global load balancing and edge failover:

Load Balancing: Cloudflare Load Balancing distributes traffic across AWS regions based on health checks and latency.
Health Checks: Configured at 10-second intervals; failover triggers after 3 consecutive failures (30-second detection window).
DDoS Protection: Cloudflare Magic Transit and DDoS protection are active at all times.
Emergency Rules: In the event of a security incident, Cloudflare emergency rules can be deployed within minutes via API or dashboard. The Cloud Security Engineer maintains break-glass access to the Cloudflare account.
DNS Failover: Cloudflare DNS handles automatic record updates during failover without requiring manual intervention.

4.3 Data Replication and Backup¶

Database replication: Synchronous (zero RPO) for payment processing; 15-minute asynchronous for settlement.
Backup schedule: Full daily backup retained for 35 days; weekly backup retained for 12 months; monthly backup retained for 7 years.
Backup encryption: AES-256 at rest; in-transit encryption via TLS 1.3.
Backup testing: Monthly automated restore test of a randomly selected backup set.
Immutable backups: S3 Object Lock (Compliance mode) used for regulated data and audit logs.

5. Testing Schedule¶

5.1 Planned Testing Activities¶

Test Type	Frequency	Scope	Owner	Output
Automated failover test	Quarterly	Single-region failover for payment processing	SRE Lead	Test report; runbook validation
Tabletop exercise	Semi-annual	Full DR scenario - executives and technical team	CDO	Exercise report; action items
Full DR test	Semi-annual	Live traffic failover with verification of all critical functions	CTO + SRE Lead	DR test report; RTO/RPO validation
Backup restore test	Monthly (automated)	Random selection of backup set	Cloud Security Engineer	Automated test results
BIA refresh	Annual	Full business impact analysis review	CDO	Updated BIA; revised RTOs/RPOs if required
Third-party resilience review	Annual	AWS, Cloudflare, Eastnets, payment network partners	COO	Third-party DR assessment

5.2 Test Scheduling and Approvals¶

Full DR tests are scheduled during low-traffic windows (typically Saturday 02:00–06:00 UAE time). CTO and COO approve the test plan at least 2 weeks in advance. Key payment partners and regulatory relationships are notified 48 hours before a planned maintenance window that may affect capacity.

6. Communication Plan¶

6.1 Internal Notification Tree¶

Priority	Notification Recipients	Method	Timeline
P1 - Critical outage	CDO, CISO, CTO, COO, MLRO, General Counsel	PagerDuty + phone	Within 15 minutes
P2 - Significant outage	CDO, CTO, COO, Head of Operations	PagerDuty + Slack	Within 1 hour
P3 - Degraded service	CTO, SRE Lead, Head of Operations	PagerDuty + Slack	Within 4 hours
All staff (if required)	CEO, all department heads	Email + Slack	As determined by CDO

Contact details for all recovery team members are maintained in a secure, out-of-band communication channel (maintained by the COO's office) that is accessible without reliance on the primary IT infrastructure.

6.2 Regulatory Notification¶

Regulatory notification obligations during an operational outage:

DFSA: Material operational incident notification required under DFSA Operating Rules. Timeline determined by DFSA guidance; best practice is to notify within 4 hours of a P1 incident.
SBP (Pakistan): Notification within 4 hours of a material operational incident affecting Pakistan operations.
MAS (Singapore): Initial notification within 1 hour of an incident that has a significant impact on Singapore-regulated operations.
FCA (UK): Notification within 4 hours of a major operational incident; detailed report within the FCA's defined window.
Bangladesh Bank: Notification as soon as practicable following a material incident.

All regulatory notifications are coordinated by the Head of Legal, with the MLRO copied on all communications.

6.3 Merchant Notification¶

Merchant notification protocol:

Merchants are notified of planned maintenance windows with at least 48 hours' notice via the merchant portal and email.
For unplanned outages affecting merchant services, notification is sent within 1 hour of confirmation that merchant-facing services are affected.
Status updates are posted to the Simpaisa status page (hosted on Cloudflare Pages, independent of primary infrastructure) every 30 minutes during an active incident.
Post-incident summary report is sent to affected merchants within 5 business days.

7. Frontier Market Provisions¶

Simpaisa operates in markets with elevated infrastructure risk. The following provisions address known challenges in frontier and emerging markets.

7.1 Power Outage Procedures (Pakistan, Bangladesh, Nepal, Iraq)¶

Pakistan, Bangladesh, Nepal, and Iraq experience regular power outages of varying duration and predictability. The following mitigations are in place:

Cloud infrastructure: AWS infrastructure is not directly affected by local power outages. AWS data centres operate with multiple layers of redundant power and UPS.
Local office operations: All Simpaisa offices in these markets are equipped with UPS systems (minimum 4-hour backup) and diesel generators (maintained on a monthly service schedule) to sustain office operations through extended outages.
Remote working: Staff in affected markets are equipped with 4G/5G mobile hotspot devices as a fallback communication method when fixed-line internet is unavailable.
Mobile money rails: In Pakistan and Bangladesh, Simpaisa maintains integrations with mobile money operators (Jazz Cash, EasyPaisa, bKash) as alternative payment rails when primary banking channels are disrupted.

7.2 Telecoms Failure¶

Simpaisa uses dual ISP connectivity in all offices, with automatic failover between providers.
Critical operational staff are issued enterprise mobile SIM cards on a different mobile operator from the primary office ISP.
Payment API connectivity uses multiple upstream IP transit providers via Cloudflare's network, reducing single-point-of-failure risk.
In the event of sustained telecoms disruption in a market, operations for that corridor are managed remotely from the UAE headquarters or another operating market.

7.3 Civil Unrest¶

If civil unrest is assessed as posing a risk to staff safety or office security, the COO activates the remote working protocol for the affected market.
Payment corridors in affected markets may be suspended at the MLRO's recommendation if civil unrest creates elevated financial crime risk.
Staff safety takes absolute precedence over operational continuity. No employee is required to travel to an office during active civil unrest.
Country Managers maintain a direct communication channel with the COO and are empowered to close their offices without prior approval if they assess an immediate safety risk.

7.4 Natural Disaster - Nepal Earthquake Risk¶

Nepal sits in a high seismic activity zone. The following provisions apply:

Simpaisa's Nepal operations are staffed by a small team in Kathmandu; there is no Simpaisa-owned data infrastructure in Nepal.
All Nepal payment processing runs on Simpaisa's cloud infrastructure outside Nepal; a Nepal earthquake does not create a technology DR event.
The People team maintains a welfare check protocol for Nepal-based staff, to be activated within 1 hour of a significant seismic event.
The Nepal Country Manager is the local emergency coordinator and maintains contact lists for all Nepal-based staff.
Payment operations in the Nepal corridor can continue to be managed from the UAE or Singapore if Nepal office operations are disrupted.

8. Third-Party DR Requirements¶

Simpaisa is dependent on a number of critical third parties whose resilience is essential to business continuity.

8.1 Third-Party Resilience Assessment¶

Provider	Criticality	Contractual SLA	Simpaisa's Fallback	Last Assessed
AWS	Critical	99.99% per service	Multi-region architecture; tertiary region available	Quarterly
Cloudflare	Critical	100% SLA (network uptime)	Direct AWS routing as temporary fallback	Quarterly
Eastnets	High	99.9%	Manual screening protocol (COMP-PROC-001)	Annual
1LINK (Pakistan)	High	Defined in 1LINK operating rules	Mobile money rails (Jazz Cash, EasyPaisa)	Annual
NPSB (Bangladesh)	High	Defined in BB regulations	Mobile money (bKash, Nagad)	Annual
SWIFT	Medium	SWIFT network SLA	Alternative payment networks; bilateral arrangements	Annual
Visa / Mastercard	Medium	Network operating rules	Alternative card network or push payment alternative	Annual

8.2 Third-Party Notification Requirements¶

In the event of a DR invocation, the following third parties must be notified:

AWS: Via AWS Support (Business or Enterprise support tier). AWS account team notified for extended P1 incidents.
Cloudflare: Via Cloudflare support portal. Dedicated account team for enterprise incidents.
Eastnets: Vendor incident notification via designated support channel.
Payment network partners: Per bilateral agreement notification procedures.

9. Pandemic and Remote Working Provisions¶

9.1 Lessons from COVID-19¶

Simpaisa's operating model incorporates lessons from the COVID-19 pandemic:

Remote-first capability: All critical operational roles can be performed remotely. Remote access via VPN + MFA is maintained and tested monthly.
Cloud-native operations: Simpaisa does not rely on on-premises data centres. The shift to remote working does not create additional technology risk.
Collaboration tooling: Slack, Zoom, Confluence, and Jira are all SaaS platforms accessible from any location.
Office dependencies: No critical business process is dependent on physical office presence.

9.2 Pandemic-Specific Procedures¶

In the event of a pandemic or infectious disease outbreak affecting staff availability:

If more than 25% of a critical function's staff are unavailable, the CDO activates cross-training provisions to deploy staff from adjacent functions.
If more than 50% of staff in a critical function are unavailable, the Group-level business continuity team convenes to assess operational sustainability and regulatory impact.
HR maintains a register of staff cross-trained in critical roles, updated annually.

10. Recovery Team Roles and Contacts¶

Recovery team contact details are maintained as a separate controlled annex (SGP-OPS-004-Annex-A) to this plan, updated quarterly by the COO's office. The annex is stored in:

A hardcopy in the CISO's safe (Dubai office).
An encrypted digital copy in the break-glass secrets vault (AWS Secrets Manager, accessible without dependency on corporate SSO).
On the laminated emergency contact card held by each country manager.

[Contact details maintained separately - TBC with HR and Operations]

11. Document Control¶

Field	Detail
Document Reference	SGP-OPS-004
Version	1.0
Effective Date	1 April 2026
Review Frequency	Annual (with quarterly failover testing)
Next Review	1 April 2027
Owner	CDO - Daniel O'Reilly
Approver	Board of Directors
Classification	Confidential - Restricted

SGP-CDO-006 - Data Privacy and Protection Policy¶

Classification: Confidential - Internal
Owner: Chief Digital Officer (Daniel O'Reilly)
Approver: Board of Directors
Version: 1.0
Effective Date: 1 April 2026
Next Review: 1 April 2027

1. Purpose and Scope¶

1.1 Purpose¶

This Data Privacy and Protection Policy establishes Simpaisa Group's obligations, commitments, and operating procedures in relation to the privacy and protection of personal data. It is distinct from SGP-CDO-001 (Data Governance Policy), which addresses data management, classification, and quality. This policy addresses the rights of data subjects, the obligations of Simpaisa as a data controller and/or processor, and the mechanisms by which Simpaisa ensures compliance with applicable data protection laws across its operating jurisdictions.

1.2 Scope¶

This policy applies to:

All personal data processed by Simpaisa Group entities, regardless of jurisdiction.
All employees, contractors, and third parties who process personal data on behalf of Simpaisa.
All Simpaisa products and services: Pay-Ins, Pay-Outs, Remittances, Crypto services, and White-Label Wallets.
Personal data relating to: individual merchants, sole traders, remittance senders and recipients, wallet users, employees, and counterparties.

1.3 Relationship to Other Policies¶

This policy is read in conjunction with:

SGP-CDO-001: Data Governance Policy
SGP-SEC-001: Information Security Policy
SGP-CDO-002: Cyber Incident Response Plan (breach notification provisions)
SGP-FCC-001: AML/CFT Policy (lawful processing for financial crime compliance)
Vendor and data processing agreements (DPAs)

2. Regulatory Framework¶

Simpaisa operates across multiple jurisdictions, each with its own data protection legal framework. All entities must comply with the laws applicable to their operations and the residency of the data subjects whose data they process.

2.1 Applicable Laws by Jurisdiction¶

Jurisdiction	Applicable Law(s)	Key Regulator	Notes
UAE (DIFC)	DIFC Data Protection Law 2020 (DPL 2020)	DIFC Commissioner of Data Protection	Primary law for the DIFC entity; DPO appointment required
UAE (Onshore)	UAE Federal Decree-Law No. 45 of 2021 on Personal Data Protection	UAE Data Office	Applies to onshore UAE entity; implementing regulations in force
United Kingdom	UK GDPR; Data Protection Act 2018	Information Commissioner's Office (ICO)	Post-Brexit UK regime; adequacy not assured post-2025
Singapore	Personal Data Protection Act 2012 (PDPA) as amended	Personal Data Protection Commission (PDPC)	Mandatory breach notification; data portability obligations
Pakistan	Prevention of Electronic Crimes Act 2016 (PECA); Personal Information and Data Protection Act (PIDA)	PTA / FIA	PIDA enacted; implementing regulations expected
Bangladesh	Digital Security Act 2018; ICT Act 2006	Digital Security Agency (DSA)	Data localisation requirements under consideration
Nepal	Privacy Act 2075 (2018)	Government of Nepal - relevant ministry	Limited regulatory infrastructure; evolving framework
Canada	PIPEDA; Quebec Law 25 (Law 25 / Bill 64)	Office of the Privacy Commissioner (OPC); Commission d'accès à l'information (CAI)	Quebec Law 25 has stricter requirements including 72-hour breach notification
Iraq	General Data Protection framework (limited)	Communications and Media Commission (CMC)	Nascent framework; DIFC DPL applied as minimum standard

2.2 Highest Standard Principle¶

Where Simpaisa processes personal data that crosses jurisdictions, the higher standard of protection applies. For most cross-border processing, DIFC DPL 2020 and UK GDPR are the most demanding frameworks and set the minimum standard for Group-wide practice.

3. Lawful Basis for Processing¶

Simpaisa must identify and document a lawful basis for every category of personal data processing. The following mapping reflects the primary lawful bases used across Simpaisa's operations.

3.1 Lawful Basis Mapping¶

Processing Activity	Lawful Basis (GDPR/DPL)	Jurisdiction Notes
Merchant onboarding and KYB	Contractual necessity; Legal obligation	All jurisdictions - AML/CFT requirements create legal obligation
Remittance sender identity verification	Legal obligation (AML/CFT); Contractual necessity	All jurisdictions - FATF-aligned requirements
Remittance recipient details	Contractual necessity	Required to execute the payment instruction
Transaction monitoring for AML	Legal obligation	DFSA, SBP, MAS, FCA requirements
Sanctions screening	Legal obligation	All jurisdictions - UN, OFAC, EU, HMT designations
Wallet user identity	Legal obligation (DFSA licensing); Contractual necessity	DIFC-regulated wallet products
Fraud detection and prevention	Legitimate interest	Balanced against individual rights; LIA documented
Customer service communications	Contractual necessity	Responding to service requests
Marketing communications	Consent	Opt-in required; separate consent for each channel
Employee HR data	Contractual necessity; Legal obligation	Employment law across all jurisdictions
Analytics and product improvement	Legitimate interest (B2B context); Consent (where applicable)	LIA documented; anonymisation preferred

3.2 Legitimate Interest Assessments (LIAs)¶

Where legitimate interest is relied upon as a lawful basis, a Legitimate Interest Assessment (LIA) must be completed and documented before processing commences. LIAs are reviewed annually or when the nature of the processing changes. LIAs are held by the Data Protection Officer and are available to regulators on request.

4. Data Subject Rights¶

4.1 Rights Framework¶

Simpaisa recognises and respects the rights of data subjects under applicable law. The following rights apply to individuals whose personal data Simpaisa processes:

Right	Description	Applicable Law	Simpaisa Position
Right of access	Request a copy of personal data held	DIFC DPL, UK GDPR, PDPA, PIPEDA, Quebec Law 25	Fulfilled within 30 days
Right to rectification	Request correction of inaccurate data	DIFC DPL, UK GDPR, PDPA	Fulfilled within 30 days
Right to erasure	Request deletion of personal data ("right to be forgotten")	DIFC DPL, UK GDPR	Fulfilled where no legal obligation to retain; AML/CFT retention requirements override
Right to restriction	Request restriction of processing	DIFC DPL, UK GDPR	Fulfilled within 30 days; processing restricted pending verification
Right to data portability	Request data in machine-readable format	UK GDPR, PDPA (Singapore, from 2024)	Fulfilled for data provided by the data subject; structured format (JSON/CSV)
Right to object	Object to processing based on legitimate interest	DIFC DPL, UK GDPR	Considered; processing ceases unless compelling grounds demonstrated
Rights re automated decisions	Request human review of automated decisions	DIFC DPL, UK GDPR	Implemented via manual review request process

4.2 Response Timelines¶

Standard response time: 30 calendar days from receipt of a valid request.
Complex or high-volume requests: extendable by a further 60 days with notification to the data subject within the initial 30-day period.
Identity verification: required before any data is disclosed. Verification must not create an undue barrier to exercising rights.

4.3 Exercising Rights¶

Data subjects may exercise their rights by:

Submitting a request via the Simpaisa privacy portal: [email protected].
Written request to the Data Protection Officer.

Requests are logged, tracked, and reported to the DPO monthly. Responses are reviewed by the DPO before dispatch.

4.4 Limitations on Rights¶

Rights may be limited where:

Processing is required by applicable law (AML/CFT obligations override erasure requests).
The request is manifestly unfounded or excessive (in which case Simpaisa may charge a reasonable fee or refuse, with explanation).
Disclosure would prejudice the rights of another individual.

5. Privacy Notices¶

5.1 Disclosure Obligations¶

Simpaisa must provide clear, accessible privacy notices to all data subjects at or before the point of data collection. Privacy notices must be written in plain language and must disclose:

The identity and contact details of the data controller.
The contact details of the Data Protection Officer (for DIFC entity).
The purposes and lawful basis for processing.
The categories of personal data processed.
Recipients or categories of recipients of the data.
International transfer mechanisms where applicable.
Retention periods.
Data subject rights and how to exercise them.
The right to lodge a complaint with the relevant supervisory authority.
Where processing is based on consent: the right to withdraw consent at any time.
Where processing is based on a legal obligation: identification of the relevant law.

5.2 Privacy Notice Variants¶

Audience	Notice Type	Delivery Method
Merchants (onboarding)	Merchant Privacy Notice	Presented during onboarding; link in merchant agreement
Remittance senders	Remittance Sender Privacy Notice	Presented at point of transaction initiation
Wallet users	Wallet User Privacy Notice	In-app and on registration
Website visitors	Website Privacy Notice	Footer link; cookie banner
Employees	Employee Privacy Notice	On boarding; HR system

All privacy notices are reviewed annually by the DPO and updated when processing activities change. Material changes require fresh notice or re-consent.

6. Data Protection Impact Assessments (DPIAs)¶

6.1 When a DPIA is Required¶

A Data Protection Impact Assessment (DPIA) is mandatory before commencing any new processing activity or materially changing an existing activity that:

Uses new technologies with high privacy risk.
Involves large-scale processing of sensitive data.
Involves systematic profiling or automated decision-making affecting individuals.
Involves cross-border transfer of personal data to a non-adequate country.
Involves processing that is novel to Simpaisa and the privacy risk is uncertain.

In practice, a DPIA is completed for:

Any new product feature that collects, processes, or shares personal data.
Any new third-party integration involving personal data.
Any change to the data architecture affecting data flows.
Any processing that relies on automated transaction monitoring or scoring.

6.2 DPIA Methodology¶

DPIAs at Simpaisa follow the methodology set out in DIFC DPIA Guidance and UK ICO DPIA guidance:

Describe the processing: Nature, scope, context, and purpose.
Assess necessity and proportionality: Is the processing necessary and proportionate to the purpose?
Identify and assess risks: To the rights and freedoms of data subjects.
Identify measures to mitigate risks: Technical and organisational measures.
Sign-off and residual risk acceptance: DPO and relevant product/technology owner.

DPIAs are stored in the privacy register maintained by the DPO.

6.3 DPIA Approval Process¶

Residual Risk Level	Approval Required
Low	DPO sign-off
Medium	DPO + relevant Department Head
High	DPO + CDO; prior consultation with DIFC Commissioner if processing cannot be mitigated to acceptable level

7. Cross-Border Data Transfers¶

7.1 Transfer Framework¶

Personal data may only be transferred to a country outside the data subject's jurisdiction of residence where an appropriate transfer mechanism is in place.

7.2 Transfer Mechanisms by Jurisdiction¶

Transferring From	Transfer Mechanism	Notes
DIFC (UAE)	DIFC Standard Contractual Clauses (SCCs); adequacy decisions published by DIFC Commissioner	DIFC maintains a list of adequate jurisdictions; SCCs required for transfers to non-adequate countries
UK	International Data Transfer Agreement (IDTA); UK SCCs; adequacy regulations	UK has issued adequacy decisions for limited jurisdictions post-Brexit; IDTA used where no adequacy decision
Singapore	Data Protection Agreement (contractual protections) equivalent to PDPA standard; adequacy binding corporate rules	PDPC's framework permits transfers to countries providing adequate protection or via contractual safeguards
Canada	PIPEDA binding corporate rules; contractual safeguards	Transfers permitted where recipient provides comparable protection
Pakistan	Currently limited formal framework; DIFC DPL SCCs applied as best practice	Awaiting PIDA implementing regulations

7.3 Transfer Impact Assessments¶

Where personal data is transferred to a jurisdiction where the adequacy of protection is uncertain, a Transfer Impact Assessment (TIA) is conducted before transfer commences. TIAs are documented, approved by the DPO, and reviewed annually.

7.4 Intra-Group Transfers¶

Intra-group transfers between Simpaisa entities are governed by an Intra-Group Data Sharing Agreement (IGDSA) that:

Specifies the categories of data shared and the purpose.
Imposes the DIFC DPL standard as the minimum across all entities.
Is reviewed and updated annually.

8. Data Breach Notification¶

8.1 Definition of a Personal Data Breach¶

A personal data breach is any accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored, or otherwise processed.

8.2 Breach Notification Timelines by Jurisdiction¶

Jurisdiction	Regulator	Notification Timeline	Trigger
DIFC	DIFC Commissioner of Data Protection	72 hours	Breach likely to result in risk to data subjects
UK	Information Commissioner's Office (ICO)	72 hours	Breach likely to result in risk to rights and freedoms
Singapore	PDPC	3 calendar days	Significant data breach (affects 500+ individuals; sensitive data; likely harm)
Canada (Federal)	Office of the Privacy Commissioner	As soon as feasible	Breach posing real risk of significant harm
Quebec	Commission d'accès à l'information (CAI)	72 hours	Confidentiality incident posing risk of serious injury
Pakistan	PTA / PIDA authority	As soon as practicable	Per PIDA requirements (implementing regulations pending)
Bangladesh	Digital Security Agency	Prompt notification	Per DSA requirements
Nepal	Relevant ministry	As soon as practicable	Per Privacy Act requirements

8.3 Notification Content¶

Regulatory notifications must include:

Nature of the breach; categories and approximate number of data subjects affected.
Categories and approximate number of records affected.
Name and contact details of the DPO.
Likely consequences of the breach.
Measures taken or proposed to address the breach and mitigate its effects.

8.4 Individual Notification¶

Where a breach is likely to result in high risk to the rights and freedoms of affected individuals, Simpaisa must notify those individuals without undue delay. Individual notifications must:

Be written in plain, accessible language.
Describe the nature of the breach.
Provide contact details for further information.
Describe the likely consequences.
Describe the measures taken to mitigate harm.
Not be delayed pending completion of the full investigation.

Individual notifications are coordinated with the customer/merchant notification process set out in SGP-CDO-002 (Cyber Incident Response Plan).

9. Data Protection Officer¶

9.1 Appointment¶

Simpaisa Group has appointed a Data Protection Officer (DPO) for its DIFC entity, as required by DIFC DPL 2020. The DPO is a senior individual with expert knowledge of applicable data protection law and practices.

The DPO is not the CDO; the roles are operationally distinct. The DPO has a direct reporting line to the Board (via the Board Risk and Audit Committee) and reports operationally to the CDO.

9.2 DPO Responsibilities¶

Monitor compliance with this policy and applicable data protection law.
Advise on DPIAs and data processing activities.
Act as the primary contact point for data subjects exercising their rights.
Act as the primary contact point for the DIFC Commissioner of Data Protection and other relevant regulators.
Maintain the privacy register (processing records, DPIAs, LIAs, TIAs).
Deliver annual privacy training to all staff.
Produce a quarterly privacy compliance report for the CDO and an annual report to the Board.
Manage data breach notifications.

9.3 DPO Independence¶

The DPO must not be placed in a position that creates a conflict of interest. The DPO may not hold a role that requires them to determine the purposes and means of personal data processing. The DPO has access to all personal data processing activities and all relevant staff and systems needed to fulfil their duties.

10. Children's Data¶

Simpaisa's products and services are exclusively business-to-business (B2B) in nature. Simpaisa does not knowingly collect or process the personal data of individuals under the age of 18.

In the context of remittance services, the data of recipients is collected as part of a payment instruction. If a recipient is identified as a minor (for example, in the context of family remittances), the data is processed solely for the purpose of completing the payment and is subject to the same protections as all other personal data.

Simpaisa does not offer direct-to-consumer services, does not operate consumer-facing apps, and does not target individuals under 18 with any product or marketing. This position is documented and reviewed annually.

11. Cookies and Tracking Technologies¶

Simpaisa's primary products are B2B API services. The Group's digital footprint is limited to:

A corporate website (marketing and information).
A merchant portal (authenticated B2B users).

The following positions apply:

Corporate website: Minimal cookie use. Essential cookies only for security and functionality. Analytics cookies deployed with user consent via cookie banner compliant with UK GDPR and DIFC DPL requirements.
Merchant portal: Session management cookies only (strictly necessary). No third-party tracking or advertising cookies used within the authenticated portal.
API services: No cookies or tracking technologies deployed in API-to-API integrations.

A Cookie Policy is published on the corporate website and is reviewed annually. No consent management platform (CMP) beyond a standard cookie banner is required given the limited nature of Simpaisa's consumer-facing presence.

12. Privacy by Design¶

12.1 Principle¶

Privacy by design is embedded into Simpaisa's product development, technology architecture, and vendor selection processes. Privacy considerations are not retrofitted; they are built in from the outset.

12.2 Implementation in SDLC¶

Requirements phase: Privacy requirements are captured for all features involving personal data. A DPIA screening question is answered at the start of every new feature development.
Design phase: Data minimisation is applied - only data that is necessary for the stated purpose is collected. Data flows are documented.
Development phase: Encryption at rest (AES-256) and in transit (TLS 1.3) is mandated for all personal data. Pseudonymisation is used in non-production environments.
Testing phase: Non-production environments use synthetic or anonymised data. Real personal data may not be used in development or test environments without DPO approval.
Deployment phase: Security and privacy review is a gate in the CI/CD pipeline. DPO sign-off required for new data processing activities.
Retirement: Data deletion and secure disposal procedures are executed at end-of-life.

12.3 Vendor Selection¶

All vendors who will process personal data on Simpaisa's behalf are subject to a privacy due diligence assessment before engagement, covering:

Applicable data protection certifications and compliance frameworks.
Data processing agreement (DPA) requirements.
Sub-processor disclosure.
Breach notification procedures.
Data deletion obligations on contract termination.

13. Data Retention¶

Personal data is retained only for as long as is necessary for the purposes for which it was collected, and as required by applicable law. Key retention periods:

Data Category	Retention Period	Legal Basis for Retention Period
KYB/KYC records (merchant)	5 years from end of business relationship	DFSA Anti-Money Laundering Rules; FATF Recommendation 12
Transaction records	5 years (minimum); 7 years for UK/DIFC entities	AML/CFT regulations; financial records law
Customer service records	3 years from last interaction	Contractual and regulatory obligation
Employee records	Duration of employment + 7 years	Employment law; tax and statutory obligations
Marketing consent records	Until consent withdrawn + 3 years	Proof of consent
CCTV (if any)	30 days	DIFC guidance; proportionality principle

Retention schedules are maintained in the Data Retention Register, owned by the DPO and reviewed annually.

14. Annual Privacy Programme Review¶

The DPO conducts an annual review of the privacy programme, covering:

Compliance status across all applicable jurisdictions.
Data subject request volumes, response times, and outcomes.
Data breach incidents, regulatory notifications, and outcomes.
DPIA and LIA register completeness.
Third-party DPA compliance.
Training completion rates.
Regulatory developments affecting Simpaisa's obligations.
Recommended updates to this policy.

The annual review report is presented to the CDO and to the Board Risk and Audit Committee.

15. Document Control¶

Field	Detail
Document Reference	SGP-CDO-006
Version	1.0
Effective Date	1 April 2026
Review Frequency	Annual
Next Review	1 April 2027
Owner	CDO - Daniel O'Reilly
Data Protection Officer	[Name TBC]
Approver	Board of Directors
Classification	Confidential - Internal

SGP-GOV-007 - Conduct Risk Framework¶

Classification: Confidential - Internal
Owner: Chief Operating Officer (Kamil Shaikh)
Approver: Board of Directors
Version: 1.0
Effective Date: 1 April 2026 - in anticipation of DFSA Conduct Principles effective 1 July 2026
Next Review: 1 April 2027

1. Purpose and Context¶

1.1 Purpose¶

This Conduct Risk Framework ("Framework") establishes how Simpaisa Group identifies, assesses, manages, monitors, and mitigates conduct risk across its operations. It maps the DFSA Conduct Principles - effective 1 July 2026 - to Simpaisa's business lines, operating model, and existing control environment, and defines the governance and reporting mechanisms that will give the Board and senior leadership confidence that conduct risk is managed effectively.

This is a framework document, not a standalone policy. It operates alongside and draws upon Simpaisa's existing policy suite, including the Code of Conduct (SGP-GOV-001), Conflicts of Interest Policy (SGP-GOV-003), Complaints Policy, Whistleblowing Policy, and AML/CFT Framework.

1.2 Context - DFSA Conduct Principles¶

The Dubai Financial Services Authority (DFSA) is implementing six Conduct Principles effective 1 July 2026, applicable to all DFSA-authorised firms. Simpaisa holds a DFSA Category 3D licence, and the Conduct Principles apply to Simpaisa's DIFC entity and, by Group policy decision, are applied as the standard for all Group entities.

The six DFSA Conduct Principles are:

Act honestly and with integrity, and deal fairly with customers and counterparties.
Act with due skill, care and diligence in conducting regulated activities.
Observe proper standards of market conduct and comply with applicable regulatory requirements.
Manage conflicts of interest fairly, both between the firm and its clients and between different clients.
Act within the scope of authorisation granted by the DFSA.
Co-operate with the DFSA and other relevant regulatory authorities in an open and co-operative way.

1.3 Definition of Conduct Risk¶

Conduct risk is the risk that the behaviour of Simpaisa, its employees, or its agents will result in unfair outcomes for customers or counterparties, regulatory breach, or damage to the integrity of the financial system. Conduct risk is distinct from - though related to - operational risk, legal risk, and reputational risk.

2. Conduct Principle Mapping and Controls¶

2.1 Principle 1 - Act Honestly, with Integrity, and Deal Fairly¶

Relevance to Simpaisa: This principle is fundamental to Simpaisa's cross-border payment business. Customers - merchants, remittance senders, and wallet users - must be able to trust that Simpaisa's pricing, terms, and service delivery are transparent, fair, and consistently applied.

Business Lines Affected: All - Pay-Ins, Pay-Outs, Remittances, Crypto, White-Label Wallets.

Key Controls and Commitments:

Control Area	Description	Policy Reference
Pricing transparency	All fees, FX spreads, and charges are disclosed in advance of a transaction. No hidden fees. Fee schedules are published on the merchant portal and in merchant agreements.	Merchant Agreement; Merchant Portal
FX rate disclosure	The exchange rate applied to each transaction is disclosed to the sender at the point of instruction, before confirmation. The rate lock period and any margin over mid-market rate are stated.	Product terms
Merchant onboarding integrity	Merchants are onboarded via a documented KYB process. No merchant is accepted where there is a reasonable basis to suspect the business is dishonest or harmful.	SGP-FCC-001 (AML Policy)
Complaints handling	A formal complaints process is maintained (Complaints Policy). All complaints are acknowledged within 2 business days and resolved within 15 business days (DFSA standard). Complaints data is reported to the Board quarterly.	Complaints Policy
Terms and conditions	T&Cs are written in plain English, are comprehensive, and are provided to merchants and users before contract commencement. Material changes are notified with 30 days' notice.	Legal department
Employee conduct standards	The Code of Conduct sets standards for honesty, integrity, and fair dealing in all interactions with customers, counterparties, and colleagues.	SGP-GOV-001

Conduct Risk Indicators for Principle 1:

Volume and trend of customer/merchant complaints.
Complaints related to pricing disputes or hidden fees.
Employee misconduct cases involving misrepresentation.
Regulatory findings or customer feedback on fairness of terms.

2.2 Principle 2 - Act with Due Skill, Care and Diligence¶

Relevance to Simpaisa: Simpaisa's products and operations must be delivered competently. This encompasses the technical reliability of payment infrastructure, the expertise of staff operating regulated activities, and the fitness and propriety of individuals in key roles.

Business Lines Affected: All - with particular emphasis on Treasury, Compliance, and Technology.

Key Controls and Commitments:

Control Area	Description	Policy Reference
Competence framework	A competence framework defines minimum qualification and experience requirements for all roles involved in regulated activities. Roles are assessed against the framework at recruitment and annually.	People Policy; Competence Framework
Fit and proper assessment	All Approved Individuals under the DFSA are subject to ongoing fit and proper assessment. Changes in circumstances that may affect fitness or propriety must be reported to the CISO, COO, or General Counsel.	DFSA Approved Individuals regime
Training and continuing education	All staff in regulated roles complete a minimum of 20 hours' continuing professional development per year, including regulatory updates. Completion is tracked and reported to the COO.	L&D Policy
Technology and capacity	The SRE model, active-active architecture, and DR plan (SGP-OPS-004) ensure that Simpaisa's technical delivery meets the standard expected of a regulated payment firm.	SGP-OPS-004
Product governance	New products and material changes to existing products are subject to a product governance review before launch. This includes regulatory approval where required.	Product Governance Policy
Third-party oversight	Third-party service providers performing material functions are subject to due diligence, ongoing oversight, and annual review.	Third-Party Risk Policy

Conduct Risk Indicators for Principle 2:

Regulatory findings related to competence or knowledge gaps.
Failed fit and proper assessments.
Service failures or outages attributable to operational deficiency.
Training completion rates below 90%.

2.3 Principle 3 - Observe Proper Standards of Market Conduct¶

Relevance to Simpaisa: As a DFSA-regulated cross-border payments firm, Simpaisa must maintain the highest standards of market conduct. This encompasses AML/CFT compliance, sanctions adherence, data protection, and adherence to payment network rules.

Business Lines Affected: All - with particular emphasis on Compliance, AML/CFT, and Data.

Key Controls and Commitments:

Control Area	Description	Policy Reference
AML/CFT compliance	A comprehensive AML/CFT framework is in place, overseen by the MLRO (Shoukat Bizinjo). Transaction monitoring, suspicious activity reporting, and customer due diligence are embedded in operations.	SGP-FCC-001
Sanctions screening	All transactions are screened against UN, OFAC, EU, HMT, and DFSA sanctions lists via Eastnets before processing. Hits are reviewed by the Compliance team.	SGP-FCC-002
Data protection	Personal data is handled in accordance with SGP-CDO-006. Processing is lawful, fair, and transparent.	SGP-CDO-006
Payment network compliance	Simpaisa complies with Visa, Mastercard, 1LINK, SWIFT, and other payment network rules. Breaches of network rules are escalated immediately to the General Counsel and COO.	Network agreements
Information barriers	Where Simpaisa handles information that could create market conduct risk, information barriers are in place to prevent misuse.	SGP-GOV-003
Regulatory reporting	All regulatory reports (transaction reporting, suspicious activity reports, regulatory returns) are submitted accurately and on time.	MLRO / Compliance calendar

Conduct Risk Indicators for Principle 3:

SAR/STR filing trends.
Sanctions screening hit rates and resolution times.
Regulatory findings or enforcement actions related to market conduct.
Data protection breaches.
Failures or delays in regulatory reporting.

2.4 Principle 4 - Manage Conflicts of Interest Fairly¶

Relevance to Simpaisa: As a Group with nine entities across diverse markets, and with related-party transactions and cross-entity service arrangements, conflicts of interest require proactive identification and management.

Business Lines Affected: All - with particular emphasis on governance, treasury, and senior leadership decisions.

Key Controls and Commitments:

Control Area	Description	Policy Reference
Conflicts of Interest Policy	A formal policy (SGP-GOV-003) establishes how conflicts are identified, disclosed, managed, and recorded.	SGP-GOV-003
Conflicts register	A Group-wide conflicts register is maintained by the General Counsel and reviewed quarterly by the Board.	SGP-GOV-003
Related party transactions	All transactions with related parties are subject to Board approval and are disclosed in financial statements. The Board's independent members review and approve material related-party arrangements.	Board Charter; SGP-GOV-003
Personal account dealing	Staff in relevant roles are subject to personal account dealing restrictions. Pre-clearance is required for transactions in financial instruments where a conflict could arise.	Code of Conduct (SGP-GOV-001)
Gifts and hospitality	A gifts and hospitality register is maintained. Limits are set in the Code of Conduct. All gifts above the threshold must be approved by the relevant Department Head.	SGP-GOV-001
Board independence	The Board composition is designed to ensure that independent non-executive directors are present in sufficient numbers to provide objective oversight of management decisions.	Board Charter

Conduct Risk Indicators for Principle 4:

Undisclosed conflicts of interest identified.
Related-party transactions not subject to proper approval.
Personal account dealing violations.
Gifts and hospitality policy breaches.

2.5 Principle 5 - Act Within the Scope of Authorisation¶

Relevance to Simpaisa: Simpaisa must not undertake activities beyond the scope of its DFSA Category 3D licence or the licences held by other Group entities. Product expansion and new market entry must be managed within a robust product and licence governance framework.

Business Lines Affected: All - product development, business development, and legal/compliance.

Key Controls and Commitments:

Control Area	Description	Policy Reference
Licence monitoring	The General Counsel maintains a licence register for all Group entities. Licence conditions are reviewed quarterly. Any activity that may approach or exceed licence scope is escalated to the COO and General Counsel before commencement.	Licence Register
Product governance	New products are assessed against current licence permissions before development commences. Where a new product requires a licence variation or additional regulatory approval, the regulatory pathway is mapped and approved by the Board before development proceeds.	Product Governance Policy
Regulatory horizon scanning	The Compliance team monitors regulatory developments in all operating markets. Material changes are presented to the Board on a quarterly basis.	Compliance Calendar
Geographic expansion	Entry into new markets follows a regulatory approval and licence acquisition process governed by the Board. No commercial activity commences in a new market before the required regulatory authorisations are in place.	Market Entry Policy
Crypto services	Simpaisa's crypto-related activities are conducted solely within the scope of its DFSA licence. Any expansion of crypto activities is subject to prior DFSA consultation.	SGP-FCC-003; DFSA Crypto Token Regime

Conduct Risk Indicators for Principle 5:

Products or services launched without regulatory approval.
Activities identified as outside licence scope.
Regulatory findings relating to unauthorised activities.
Regulatory change not identified until after implementation deadline.

2.6 Principle 6 - Co-operate with the DFSA and Other Regulatory Authorities¶

Relevance to Simpaisa: Open, transparent, and co-operative engagement with the DFSA and other regulators is a core obligation and a reputational imperative.

Business Lines Affected: Legal, Compliance, C-Suite - all entities.

Key Controls and Commitments:

Control Area	Description	Policy Reference
DFSA engagement	The COO, in conjunction with the General Counsel, manages the DFSA supervisory relationship. All DFSA requests for information are responded to accurately and promptly.	Regulatory Engagement Protocol
Regulatory reporting	All regulatory returns are submitted on time and with accuracy. The Compliance calendar tracks all reporting deadlines. Missed or delayed submissions are escalated to the COO and reported to the Board.	Compliance Calendar
Regulatory notifications	Material incidents, breaches, and developments that require regulatory notification are identified and notified in accordance with applicable timelines (see SGP-CDO-002 and SGP-CDO-006).	SGP-CDO-002; SGP-CDO-006
DFSA access	The DFSA has the right to inspect Simpaisa's books, records, and systems. Simpaisa staff are trained to facilitate regulatory visits openly and co-operatively. Records are maintained in a condition suitable for regulatory review.	DFSA Operating Rules
Regulatory investigations	If Simpaisa or any employee becomes the subject of a regulatory investigation, the General Counsel and COO are immediately informed. No staff member is to obstruct, mislead, or delay a regulatory investigation.	SGP-GOV-001 (Code of Conduct)
Cross-border regulatory cooperation	Where multiple regulators have jurisdiction over an incident or matter, Simpaisa co-ordinates its regulatory communications to ensure consistency and transparency.	Head of Legal coordination

Conduct Risk Indicators for Principle 6:

Delayed or inaccurate regulatory submissions.
DFSA inspection findings.
Regulatory findings or enforcement actions.
Instances where notifications were not made within required timelines.

3. Conduct Risk Indicators and Monitoring¶

3.1 Conduct Risk Indicator (CRI) Framework¶

Conduct risk indicators are quantitative and qualitative measures that signal changes in the level of conduct risk. CRIs are monitored on a monthly basis by the COO and reported to the Board quarterly.

CRI	Metric	Green	Amber	Red
Complaint volume	Number of formal complaints per 1,000 active merchants per month	< 2	2–5	> 5
Complaint resolution	% resolved within 15 business days	> 95%	85–95%	< 85%
Pricing disputes	Pricing-related disputes as % of total complaints	< 10%	10–25%	> 25%
Employee misconduct cases	Number of Code of Conduct investigations open per quarter	0	1–2	> 2
Regulatory submissions	% submitted on time	100%	98–99%	< 98%
DFSA findings	Number of supervisory findings per regulatory cycle	0	1–2	> 2
Training completion	% of regulated staff completing mandatory conduct training	> 95%	85–95%	< 85%
Conflicts disclosed	Conflicts disclosed vs conflicts identified (reconciliation)	Aligned	Minor variance	Material gap
Licence scope incidents	Number of activities identified as potentially outside licence scope per quarter	0	1	> 1
Regulatory notification timeliness	% of required notifications submitted within the required timeline	100%	-	< 100%

3.2 Management Information¶

Monthly: COO reviews CRI dashboard and escalates any amber or red indicators to the relevant Function Head for remediation.

Quarterly: Conduct Risk Dashboard is presented to the Board by the COO. The dashboard includes:

CRI summary (RAG status).
Complaints analysis (volume, trend, category, resolution).
Employee conduct cases (anonymised summary).
Regulatory engagement summary.
Emerging conduct risks.
Remediation actions and their status.

Annual: Formal conduct risk assessment conducted by the COO's office, reviewed by the Board Risk and Audit Committee.

4. Integration with Existing Policies¶

This Framework does not replace existing policies; it provides the governance overlay that connects them to the DFSA Conduct Principles.

Existing Policy	Relevance to Conduct Risk	Conduct Principles Supported
Code of Conduct (SGP-GOV-001)	Sets standards for individual behaviour; clawback provisions	1, 2, 3, 4, 6
Conflicts of Interest Policy (SGP-GOV-003)	Identifies and manages conflicts	4
Complaints Policy	Ensures fair treatment of customers	1
Whistleblowing Policy	Enables reporting of conduct concerns without fear of retaliation	1, 3, 6
AML/CFT Policy (SGP-FCC-001)	Maintains market integrity	3
Data Privacy and Protection Policy (SGP-CDO-006)	Protects customer data; fair and lawful processing	1, 3
Third-Party Risk Policy	Ensures conduct standards extend to suppliers	2, 3
Product Governance Policy	Ensures products are designed and sold appropriately	2, 5

5. Conduct Risk in Remuneration¶

5.1 Linkage to Remuneration¶

Conduct risk considerations are embedded in Simpaisa's remuneration framework (SGP-GOV-001). The following provisions apply:

Performance assessment: Individual performance assessments include a conduct assessment. A "not met" conduct rating overrides other performance results and prevents a variable pay award for that year.
Clawback: The Code of Conduct (SGP-GOV-001) includes clawback provisions enabling Simpaisa to recover previously paid variable compensation where a conduct failure is subsequently identified. Clawback may be applied for up to 3 years after the relevant payment.
Malus: Variable compensation that has been awarded but not yet paid may be reduced or cancelled (malus) where a conduct failure occurs in the relevant period.
Senior leadership: The remuneration arrangements for all members of the Executive Committee are reviewed by the Board with conduct risk explicitly considered.

5.2 Prohibited Incentive Structures¶

Simpaisa does not operate remuneration structures that create incentives to breach the Conduct Principles. In particular:

Sales staff are not rewarded solely on the basis of volume of new merchants onboarded, without regard to quality and compliance.
No commission structure rewards concealment of customer complaints or adverse feedback.
Compliance and risk staff are remunerated independently of the business lines they oversee.

6. Annual Conduct Risk Assessment¶

The COO conducts a formal annual conduct risk assessment, covering:

Review of CRI performance over the preceding 12 months.
Identification of emerging conduct risks (new products, markets, regulatory requirements, or industry trends).
Assessment of the effectiveness of controls mapped in this Framework.
Gaps in the policy suite or control environment.
Training needs identified.
Recommended updates to this Framework.

The annual conduct risk assessment is presented to the Board Risk and Audit Committee and forms the basis for the Board's annual attestation to the DFSA regarding conduct risk management.

7. Accountability and Governance¶

7.1 Responsibilities¶

Role	Conduct Risk Responsibility
Board of Directors	Ultimate accountability for conduct risk; approves framework; receives quarterly CRI dashboard
COO - Kamil Shaikh	Framework owner; monthly CRI monitoring; quarterly Board reporting; annual assessment
MLRO - Shoukat Bizinjo	Conduct risk ownership for AML/CFT, sanctions, and financial crime dimensions
CISO - Danish Hamid	Conduct risk ownership for information security and data-related conduct
CDO - Daniel O'Reilly	Oversight of technology conduct risks; product governance
General Counsel	Legal and regulatory dimension; conflicts of interest; DFSA engagement
Head of People	Employee conduct cases; training; remuneration linkage
All employees	Adherence to Conduct Principles; reporting concerns via Whistleblowing Policy

7.2 Escalation¶

Any employee who identifies a potential conduct risk or breach of the Conduct Principles must report it to their line manager, the COO, the MLRO, or via the anonymous Whistleblowing channel. Retaliation against anyone raising a genuine conduct concern is a disciplinary matter.

8. Document Control¶

Field	Detail
Document Reference	SGP-GOV-007
Version	1.0
Effective Date	1 April 2026
DFSA Conduct Principles Effective	1 July 2026
Review Frequency	Annual
Next Review	1 April 2027
Owner	COO - Kamil Shaikh
Approver	Board of Directors
Classification	Confidential - Internal

End of Simpaisa Group DFSA Regulatory Suite - April 2026