Skip to content

CDO 30-Day Findings Report

Field Value
Author Daniel O'Reilly, Chief Digital Officer
Date 21 April 2026
Period 22 March - 21 April 2026
Classification Class 2 (Confidential)
Audience Yassir Hussain, CEO

Executive Summary

In my first 30 days as CDO I conducted a systematic audit of Simpaisa's technology estate, documentation, regulatory readiness, and public-facing digital properties. The findings are significant. The platform is live and processing payments, but it carries active security vulnerabilities, financial integrity risks, and regulatory gaps that need to be addressed before the DFSA application and Phoenix programme can proceed safely.

This report consolidates findings from 10 separate audits into a single risk-prioritised view. Each finding is classified by severity and assigned a remediation owner and timeline.

Summary scores:

Area Health Score Critical Findings
API Security and Code Quality 2/10 18 P0 issues, hardcoded credentials, SSL disabled, no auth framework
API Documentation 3/10 28 findings, no standard error schema, auth inconsistent across products
Open Banking Alignment 2/10 No auth framework, SSL disabled, AES-ECB on card data, 28-32 week gap
Website Security and Performance 5/10 improved: partial CSP added. Unprotected forms, 26 XSS vectors remain
Website SEO/AEO 3/10 improved: robots.txt and sitemap.xml fixed. Meta descriptions, canonicals, OG tags still missing
DFSA Regulatory Readiness 5.5/10 improved: 3 policies drafted. 3 full gaps reduced, 14 High-priority items
SDLC Process 3/10 v1.0 no longer reflects how we build software, complete rewrite required
Knowledge Base (Confluence) 7.5/10 Remediated from 4/10, 6 items remaining. Migrated to mkdocs, Confluence deprioritised

Verification Status

All findings in this report were re-verified on 21 April 2026 against live systems and current documentation. Evidence methodology: live HTTP testing (website), document review (DFSA/SDLC), source audit cross-reference (platform).

Changes since original audits

Finding Original Verified 21 Apr Evidence
S1 Entire site client-side rendered Partially fixed SSR with streaming active, but full-page loader hides content until JS hydrates. Crawlers can now parse HTML.
S2 No robots.txt Fixed HTTP 200, valid directives including sitemap reference
S3 No sitemap.xml Fixed HTTP 200, 23 URLs, recently updated
W1 CSP missing Partially fixed CSP present (frame-src, object-src, base-uri, form-action) but missing script-src and default-src. XSS protection still incomplete.
W6 slick-carousel Fixed Migrated to Swiper. Residual slick CSS in bundle (dead code).
D8 No BCP/Operational Resilience Partially addressed Group policy SGP-OPS-001 v1.0 exists. DIFC-specific annex not yet drafted. Target: 30 June 2026.
D10 Fit and Proper Policy not drafted Addressed Full policy drafted in risk-prudential.md with DFSA-specific scope. Policy index entry stale.
D12 No CRO, no Risk Appetite Statement Partially addressed Risk Appetite Statement (SGP-GOV-009) drafted. CRO appointment remains open. Target: 31 July 2026.
D13 No complaint handling policy Addressed SGP-GOV-004 v1.0 active, Board-approved 1 April 2026. DIFC implementation procedures pending (target 31 May 2026).
D14 No PI insurance Partially addressed Insurance brief prepared with budget estimates (USD 30-70K/yr). No cover in force. Target date 30 April 2026 is now past due.
K1 79 ADRs status Proposed Confirmed Now 80 ADRs, all still Proposed. Zero ratified by ARB.
K2-K5 Confluence structural issues No longer relevant Documentation migrated to mkdocs. Confluence deprioritised.
P1-P15 Platform security findings Confirmed from source audit Legacy Java repos not on local machine. Phoenix (Go rewrite) is the replacement. Original findings from direct codebase review remain authoritative.

Findings confirmed still active (no change)

S4 (no meta descriptions), S5 (no canonical URLs), S6 (no Open Graph tags), S7 (33 of 55 images use alt="img"), W2 (unprotected contact form, no CAPTCHA), W3-W5 (code-level, verified against source audit), D1-D7 (all confirmed open), D9 (confirmed open), D11 (confirmed open), all platform findings P1-P15 (confirmed from source audit, legacy platform not yet replaced).


Part 1: Platform Security and Code Quality

Source: API Best Practices Audit, Codebase Audit, Open Banking Comparison Audit

Findings that require immediate action

These are live in production today. Some are exploitable.

# Finding Severity Risk Status
P1 Hardcoded production credentials in Git - Twilio tokens, bank API keys, PEM private keys, MySQL/SMTP passwords committed to source across all four API families P0 Credential theft, full system compromise Open
P2 SSL validation disabled - 7 HTTP client methods in the Remittance service accept all certificates with NoopHostnameVerifier P0 Man-in-the-middle attacks on partner bank connections Open
P3 AES-ECB encryption on card data - deterministic encryption on PAN data in three services P0 PCI-DSS blocker, card data pattern leakage Open
P4 No Spring Security in any service - no auth filter chain, no CSRF protection, CORS set to wildcard (*), multiple endpoints completely unauthenticated P0 Unauthorised access to payment APIs Open
P5 Inverted validation booleans in Card service - valid emails rejected, invalid ones accepted P0 Data integrity failure in production Open
P6 MD5 used for security tokens - cryptographically broken hashing in Remittance P0 Token forgery Open
P7 No @Transactional on financial operations - balance deductions can succeed while state updates fail P0 Orphaned financial states, settlement discrepancies Open
P8 double used for monetary fields - floating-point truncation on payment amounts P0 Silent rounding errors on every transaction Open
P9 Raw PAN data through application layer - card numbers and CVVs as plain strings P0 PCI scope explosion Open
P10 Idempotency fails open - Redis outage silently disables duplicate payment protection P0 Duplicate payments when Redis is down Open
P11 Error handling returns HTTP 200 on failure - exceptions silently swallowed, no global handler P1 Merchants cannot distinguish success from failure Open
P12 Webhooks fire once with no retry, no HMAC signing - abandoned RabbitMQ queue infrastructure P1 Merchants miss payment notifications, no authenticity verification Open
P13 Zero rate limiting across all APIs P1 Abuse, denial of service Open
P14 PII logged at INFO level - personal data written to application logs P1 Data protection breach Open
P15 Disbursement gateway on EOL Spring Boot 2.2.6 / Java 8 P1 Known vulnerabilities, no security patches Open

Remediation plan

Phase Timeline Actions Owner
Emergency This week Rotate all hardcoded credentials. Purge secrets from Git history. Fix SSL validation. Fix inverted booleans. Authenticate open endpoints. Fix IP filter logic. Engineering Lead
Security hardening Weeks 2-4 Replace AES-ECB with AES-GCM. Add Spring Security to all services. Migrate money fields to BigDecimal. Add @Transactional. Replace MD5. Remove wildcard CORS. Mask PII in logs. Engineering Lead + Security
Reliability Weeks 4-8 Global exception handlers. Proper HTTP status codes. Mandatory idempotency (fail-closed). Webhook retry with HMAC signing. Rate limiting. Distributed tracing. Engineering Lead
API quality Weeks 8-16 Typed DTOs replacing HashMaps. API versioning. Pagination. OpenAPI specs. Test suites. Upgrade disbursement gateway. Engineering Lead

Part 2: Website and Digital Presence

Source: Website Technical Audit, SEO/AEO Audit

Website security (score: 4/10)

# Finding Severity Risk
W1 Content Security Policy partial - CSP present (frame-src, object-src, base-uri, form-action) but missing script-src and default-src. XSS protection still incomplete. High Partially mitigated, script-src gap remains
W2 Unprotected contact form - no CSRF, no rate limiting, no CAPTCHA, Strapi API endpoint exposed Critical Spam, abuse, data harvesting
W3 26 uses of dangerouslySetInnerHTML - some render CMS content without sanitisation High Stored XSS via CMS
W4 .env file tracked in Git High Credential exposure
W5 Image wildcard in next.config.mjs - allows remote loading from any HTTPS host High SSRF vector
W6 ~~Unmaintained slick-carousel~~ FIXED - migrated to Swiper. Residual slick CSS in bundle (dead code). Low No longer exploitable

Website SEO/AEO (score: 2/10)

# Finding Severity Impact
S1 Changed - partially fixed. SSR active but full-page loader masks content until JS hydrates. High Crawlers can now parse HTML, but user experience still depends on JS hydration
S2 ~~No robots.txt~~ FIXED - returns 200 with valid directives ~~Critical~~ Resolved Crawlers now have guidance
S3 ~~No sitemap.xml~~ FIXED - returns 200 with 23 URLs ~~Critical~~ Resolved Pages can be discovered and indexed
S4 No meta descriptions on any page Critical Poor search snippets, AI engines have nothing to extract
S5 No canonical URLs High Duplicate content risk
S6 No Open Graph tags High Blank previews when shared on LinkedIn/WhatsApp/Slack
S7 73+ broken image alt texts (alt="img" or empty) High WCAG Level A failure

Remediation plan

Phase Timeline Actions Owner
Immediate This week Complete CSP. Add server-side form protection. Restrict image remote patterns. Gitignore .env. Web Lead
SSR conversion Week 2 Remove "use client" from root layout and static pages. This unblocks all SEO work. Web Lead
SEO foundations Week 3 Deploy robots.txt, sitemap.xml, meta descriptions, canonical URLs, OG tags across all 27 routes. Web Lead
AEO and schema Week 4 JSON-LD schemas per page type. FAQPage schema. llms.txt. Citation-ready passages. Web Lead + CDO

Part 3: DFSA Regulatory Readiness

Source: DFSA Category 3D Gap Analysis

The DFSA licence application requires 18 specific capabilities. Current state:

Status Count Detail
Met 2 Non-Executive Chairperson, Governance Structure (with caveats)
Partially Met 13 SEO designation, MLRO, Compliance Officer, Capital, Systems and Controls, Business Plan, Operational Resilience, Outsourcing, Data Protection, Client Money, Fit and Proper, AML/CFT, Risk Management
Gap 3 Complaint Handling, Professional Indemnity Insurance, Finance Officer

High-priority DFSA items (all 14 rated High)

# Requirement Current State Action Required
D1 Senior Executive Officer No named SEO for Simpaisa Technologies LTD Formally designate SEO (CDO is natural candidate). Complete approved person application.
D2 MLRO appointment Role identified but not filled Appoint named, DFSA-approved MLRO. Must be UAE-resident. Register on goAML.
D3 Compliance Officer Group CCO role flagged but not filled Appoint named, DFSA-approved CO. May combine with Group CCO.
D4 Finance Officer No designation for DIFC entity Designate FO. Confirm whether Global CFO can serve or UAE-resident needed.
D5 Capital (USD 300-500K) Requirement documented, no injection confirmed Arrange capital injection. Prepare source of funds documentation.
D6 Systems and Controls Three lines of defence documented, UAE addendum missing Compile DFSA Regulatory Business Plan. Draft UAE-specific procedures.
D7 Business Plan Referenced as milestone, not drafted Finalise with 3-year projections, governance, AML summary, tech description. Board approval.
D8 Operational Resilience Partially addressed. Group policy SGP-OPS-001 v1.0 exists. DIFC-specific annex not yet drafted. Target: 30 June 2026. Draft DIFC-specific BCP annex with RTOs/RPOs. Demonstrate tested DR.
D9 Client Money Protection Group policy exists, no DIFC segregated account Open designated DIFC client money account. Prepare for annual audit.
D10 Fit and Proper Policy Addressed. Full policy drafted in risk-prudential.md with DFSA-specific scope. Policy index entry stale. Update policy index. Conduct assessments for all proposed approved individuals.
D11 AML/CFT DFSA compliance Group programme exists, UAE addendum not drafted Draft DFSA AML Module-compliant addendum. Prerequisite for MLRO appointment.
D12 Risk Management Framework Partially addressed. Risk Appetite Statement (SGP-GOV-009) drafted. CRO appointment remains open. Target: 31 July 2026. Appoint CRO. Board-approve Risk Appetite Statement.
D13 Complaint Handling Addressed. SGP-GOV-004 v1.0 active, Board-approved 1 April 2026. DIFC implementation procedures pending (target 31 May 2026). Draft DIFC-specific implementation procedures.
D14 Professional Indemnity Insurance Partially addressed. Insurance brief prepared with budget estimates (USD 30-70K/yr). No cover in force. Target date 30 April 2026 is now past due. Engage broker urgently. Size for Category 3D. Provide evidence to DFSA.

Additional DFSA caveats

  • Independent NED required for ARC chair role (noted as pending Board resolution).
  • Board Charter not yet drafted (referenced as TBC in OpModel).
  • Outsourcing Policy and Register not drafted (Medium priority but DFSA requires it).
  • DIFC DPL 2020 not specifically addressed, only generic "UAE data protection law" referenced.

Part 4: SDLC and Engineering Process

Source: SDLC SOP Gap Analysis v1.0 to v2.0

The existing SDLC SOP (v1.0) was written for a sprint-based, QA-gated, CAB-approved waterfall process. Following the CDO appointment and the restructure into seven tribes, v1.0 no longer reflects how Simpaisa builds and ships software. A complete replacement (v2.0) has been drafted.

Key changes in v2.0

Area v1.0 (inherited) v2.0 (new)
Delivery model Two-week sprints Kanban continuous flow, 10-day cycles
Quality ownership Separate SQA function Engineers own testing, 80% unit coverage
Release governance Manual CAB approval Automated pipeline gates
Deployment frequency Bi-weekly releases Daily deployment capability per tribe
SDLC phases 11 phases with handoffs 9 phases, no handoff model
Security review After development Before development (shift-left)
Metrics None defined DORA metrics with specific targets
Architecture governance None ADR process with ARB review

Transition risks

Risk Likelihood Impact Mitigation
Engineers resist test ownership High High Phased rollout, coverage targets enforced in pipeline
Production incidents during transition Medium High CAB deprecation sequenced after pipeline automation proven
Auditors question CAB removal Medium High Automated traceability chain (Jira to PR to Pipeline to Deployment)
Platform Engineering delays block rollout Medium High 12-week phased adoption with specific milestones

Part 5: Knowledge Base

Source: Confluence Pre-Remediation Audit, Confluence Post-Remediation Audit

The Confluence Digital space was audited on 8 April (pre-remediation, 4/10) and 9 April (post-remediation, 7.5/10). Major improvements were made:

  • Metadata compliance: ~5% to 95%
  • Wide table adoption: 0% to 97%
  • Section index pages populated: 0/16 to 16/16
  • Broken cross-reference links fixed: 129

Remaining items

# Finding Severity
K1 All 80 ADRs still status "Proposed", none ratified by ARB High
K2 ~~Two orphaned page trees (IS Policies, SDLC v2.0)~~ No longer relevant - migrated to mkdocs ~~High~~ N/A
K3 ~~Strategy section has zero child pages~~ No longer relevant - migrated to mkdocs ~~Medium~~ N/A
K4 ~~Technology Stack page contains raw escaped HTML~~ No longer relevant - migrated to mkdocs ~~Medium~~ N/A
K5 ~~Zero cross-linking across Threat Models, ADRs, Standards, Playbooks~~ No longer relevant - migrated to mkdocs ~~Low~~ N/A

Note: As of 21 April, all architecture documentation is being migrated to MkDocs as the single publishing layer. Confluence remediation is deprioritised accordingly.


Consolidated Risk Register

The table below ranks every finding by combined severity and business impact, grouped into action tracks.

Track 1: Emergency (this week)

ID Finding Domain Owner
P1 Hardcoded credentials in Git Platform Engineering Lead
P2 SSL validation disabled on partner connections Platform Engineering Lead
P5 Inverted validation booleans (Card) Platform Engineering Lead
W1 Missing Content Security Policy Website Web Lead
W2 Unprotected contact form Website Web Lead

Track 2: Security hardening (weeks 2-4)

ID Finding Domain Owner
P3 AES-ECB on card data Platform Engineering Lead + Security
P4 No authentication framework Platform Engineering Lead
P6 MD5 for security tokens Platform Engineering Lead
P7 No database transactions on financial ops Platform Engineering Lead
P8 Floating-point money Platform Engineering Lead
P9 Raw PAN through application layer Platform Security
P14 PII in application logs Platform Engineering Lead
W3 dangerouslySetInnerHTML XSS vectors Website Web Lead
S1 Client-side rendering (SSR conversion) Website Web Lead

Track 3: Reliability and standards (weeks 4-8)

ID Finding Domain Owner
P10 Idempotency fails open Platform Engineering Lead
P11 Error handling returns 200 on failure Platform Engineering Lead
P12 Webhooks no retry, no signing Platform Engineering Lead
P13 Zero rate limiting Platform Engineering Lead
P15 EOL Spring Boot / Java 8 Platform Engineering Lead
S2-S6 SEO foundations (robots, sitemap, meta, canonical, OG) Website Web Lead

Track 4: DFSA application (weeks 2-12)

ID Finding Domain Owner
D1-D4 Approved individual appointments (SEO, MLRO, CO, FO) Regulatory CEO + GH Regulatory
D5 Capital injection Regulatory CFO
D6-D7 Systems and Controls + Business Plan Regulatory CDO + GH Regulatory
D10-D11 Fit and Proper Policy + AML/CFT addendum Regulatory GH Regulatory
D13-D14 Complaints policy + PI insurance Regulatory GH Regulatory + CFO

Track 5: Process and governance (weeks 4-12)

ID Finding Domain Owner
SDLC v2.0 adoption (phased 12-week rollout) Engineering CDO
K1 ADR ratification (80 decisions pending ARB sign-off) Governance CDO + Architecture

What happens next

  1. This week: Emergency credential rotation and website CSP. These are active vulnerabilities.
  2. Weeks 2-4: Security hardening across the platform. SSR conversion on the website. DFSA approved individual nominations submitted.
  3. Weeks 4-8: API reliability improvements. SEO foundations live. SDLC v2.0 phased adoption begins.
  4. Weeks 8-16: API quality standards. DFSA application pack assembled. Phoenix programme builds on a secure foundation.

The platform works. Payments are processing. But the foundation has cracks that need to be fixed before we scale. Every item in Track 1 should be treated as a live incident.


This report is generated from 10 individual audits conducted between 22 March and 21 April 2026. All findings re-verified 21 April 2026. Full audit documents are available in the Architecture Practice MkDocs site under Strategy and Reference > Audits.