2026 CDO Division Execution Plan
Department: Product, Security, Data & Technology (CDO Division)
Owner: Daniel O'Reilly, Chief Digital Officer
Strategy: Simpaisa 2026 Strategy (Bachir Njeim, Feb 2026)
Date: 5 April 2026
Status: Draft — for leadership offsite review
Section 1: Core Reliability Commitments (BAU)
These are the non-negotiable capabilities the CDO division must maintain and improve in 2026. Failure in any of these directly threatens the $1B+ transaction flow.
| # |
Critical Capability |
What Success Looks Like |
Owner |
Measurement |
| 1 |
Platform availability |
99.9% uptime across Pay-Ins, Pay-Outs, Remittances, Cards. No unplanned outages exceeding 15 minutes. |
CTO / Platform Lead (TBD) |
Real-time monitoring + monthly SLO report |
| 2 |
Security posture |
Security score improves from 4/10 to 7/10 by Q4. All 6 critical findings remediated. Zero security incidents involving customer data compromise. |
Security Lead (TBD) |
Quarterly security architecture review |
| 3 |
Data integrity |
Data maturity improves from 1/5 to 3/5 by Q4. PII encrypted at rest. Data retention policy implemented and enforced. |
Data Lead (TBD) |
Quarterly data architecture review |
| 4 |
Incident response |
P1 incidents acknowledged within 15 minutes, resolved within 1 hour. Post-incident reviews completed within 5 business days. All incidents documented. |
CTO / Platform Lead (TBD) |
Per-incident tracking + monthly incident report |
| 5 |
Partner integration health |
95%+ channel success rate across all active operators. Partner onboarding completed within SLA (11 business days PK standard). |
Operations / Partner Lead (TBD) |
Weekly channel health dashboard |
| 6 |
Regulatory compliance |
Documented regulatory posture for all 5 operating markets + AE holding company. No regulatory findings or sanctions. |
CDO + Country Managers |
Semi-annual compliance review per market |
Section 2: New Strategic Initiatives
These are new capabilities the CDO division will deliver in 2026, mapped to the CEO's five strategic goals.
| Field |
Detail |
| Initiative |
Remediate all 6 critical security findings and implement target security architecture |
| Supports CEO Goal |
SG1: Operational Excellence & Platform Infrastructure Resilience |
| Problem Statement |
Security posture is 4/10 (Critical). Pay-Ins has no request signing. Webhook payloads are unsigned. 30-minute OTP window. No rate limiting. PII in plain text. Deployment token in source control. These are existential risks for a $1B+ payment gateway. |
| What Success Looks Like |
All 6 critical findings closed. Security posture at 7/10. KrakenD API gateway deployed. HMAC-SHA256 webhook signing live. Rate limiting active on all endpoints. PII encrypted at column level. |
| Owner |
CDO (Daniel O'Reilly) |
| Q1 Milestones |
Architecture review completed. Security Architecture document published. Target state defined. Go service framework (Phoenix) scaffolded. |
| Q2 Milestones |
Request signing (HMAC-SHA256) implemented for Pay-Ins. Webhook signing live. Rate limiting deployed via KrakenD. OTP window reduced to 5 minutes. |
| Q3 Milestones |
PII encryption at rest (column-level). Secret rotation automated. Deployment token removed from source control. |
| Q4 Milestones |
Security posture reaches 7/10. All critical findings verified closed. Penetration test completed by external auditor. |
| Dependencies |
Engineering capacity. KrakenD deployment. Database migration tooling (Flyway). Go service readiness. |
| Field |
Detail |
| Initiative |
Replace legacy Spring Boot Java services with Go microservices on the Phoenix platform |
| Supports CEO Goal |
SG1: Operational Excellence & Platform Infrastructure Resilience |
| Problem Statement |
Existing Java services have no tests, no typed DTOs, no Spring Security, credentials in git, AES-ECB encryption, and circular dependencies. Patching is not viable. The Go rewrite (Phoenix) delivers the target architecture: per-service databases, idempotency, proper error handling, and test coverage from day one. |
| What Success Looks Like |
Pay-In and Pay-Out services running on Phoenix (Go) in production. All new services built in Go. Legacy Java services on deprecation path. |
| Owner |
CDO / CTO (TBD) |
| Q1 Milestones |
Phoenix framework scaffolded. Go service template standardised. Idempotency middleware consolidated. |
| Q2 Milestones |
Pay-In service (Go) in production for at least one corridor. Parallel running with legacy. |
| Q3 Milestones |
Pay-Out service (Go) in production. Legacy Pay-In Java service decommissioned. |
| Q4 Milestones |
Remittance service (Go) in production or in final testing. Card service migration planned. |
| Dependencies |
Engineering hiring (Go engineers). Database decomposition from single MySQL. CI/CD pipeline for Go services. |
Initiative 3: Maerifa
| Field |
Detail |
| Initiative |
Deploy Maerifa — temporal knowledge graph across all internal knowledge sources |
| Supports CEO Goal |
SG2: Institutionalise Execution & Performance Management (Foundational Support #1: Centralised execution backbone) |
| Problem Statement |
Knowledge is scattered across Confluence, Slack, Bitbucket, and the Architecture repo. The CDO cannot find basic information about company systems. Staff across 5 markets ask whoever has been there longest instead of reading documented standards. |
| What Success Looks Like |
All staff can query Simpaisa's institutional knowledge in natural language and get cited, authoritative answers. AI agents can consume the same knowledge for automated compliance decisions. 90%+ accuracy on a 50-question test set. |
| Owner |
CDO (Daniel O'Reilly) |
| Q1 Milestones |
Architecture repo built (214 documents). Maerifa designed, reviewed, and coded (93 tests). |
| Q2 Milestones |
Maerifa deployed and ingesting from all 4 sources. 25-question test set validated. First agent workflows consuming Maerifa API. |
| Q3 Milestones |
RBAC and SSO integrated. Email/mailbox ingestion added. Agent personas defined for compliance workflows. |
| Q4 Milestones |
Maerifa is the default knowledge access tool across the CDO division. Query analytics informing execution gaps. |
| Dependencies |
Confluence API access. Slack app creation. Bitbucket API credentials. LLM API key (Claude/OpenAI). AWS infrastructure. |
Initiative 4: Database Decomposition
| Field |
Detail |
| Initiative |
Decompose the single shared MySQL database into per-service databases |
| Supports CEO Goal |
SG1: Operational Excellence (directly addresses Risk R1: shared database causing cross-product outages) |
| Problem Statement |
All four product lines (Pay-Ins, Pay-Outs, Remittances, Cards) run against a single shared MySQL instance on AWS RDS. A schema migration in one product can cause full platform outage across all products. No read replicas. 270M+ transactions served from one instance for both OLTP and reporting. |
| What Success Looks Like |
Each product line has its own database. Schema changes in Pay-Ins cannot affect Pay-Outs. Read replicas serve reporting. Cross-service data access via APIs, not shared tables. |
| Owner |
CDO / Data Lead (TBD) |
| Q1 Milestones |
Data architecture document published. Target schemas defined (SurrealDB). Migration strategy documented. |
| Q2 Milestones |
Pay-In service on its own database (alongside Phoenix Go migration). |
| Q3 Milestones |
Pay-Out service on its own database. Read replicas deployed for reporting. |
| Q4 Milestones |
Remittance and Cards databases separated. Shared MySQL decommission planned. |
| Dependencies |
Phoenix Go migration (services and databases decompose together). Flyway migration tooling. Data migration testing. |
Initiative 5: Crypto & Stablecoin Integration (Horizon 3)
| Field |
Detail |
| Initiative |
Add stablecoin settlement and crypto payment rails to the Simpaisa gateway |
| Supports CEO Goal |
SG4: Market Expansion / SG5: Revenue Diversification (Horizon 3: Design the Future) |
| Problem Statement |
Cross-border settlement takes 2-5 days via correspondent banking at 2-7% cost. Pakistan's PVARA opened a regulatory sandbox for stablecoin payments (Feb 2026). 40M crypto users in PK, $25B annual volume. Simpaisa has the local rails, licences, and merchant relationships to be the "Bridge for PK/AE." |
| What Success Looks Like |
Phase A: USDC settlement on AE↔PK corridor via Bridge/Fireblocks on Solana. Phase B: Own on/off-ramp engine. Phase C: White-label stablecoin API for PK banks. |
| Owner |
CDO (Daniel O'Reilly) |
| Q1 Milestones |
N/A (design phase — completed April 2026) |
| Q2 Milestones |
PVARA sandbox application submitted. Bridge/Fireblocks availability confirmed. Legal counsel on licence impact obtained. Security remediation A0 prerequisites completed. |
| Q3 Milestones |
First USDC settlement on AE↔PK corridor. Merchants enabled for stablecoin pay-in (PK, AE). QR code crypto pay-in live. |
| Q4 Milestones |
Own on/off-ramp engine design started (Phase B). Treasury yield on USDC holdings active. |
| Dependencies |
PVARA sandbox approval. VARA licence assessment (AE). Security remediation (A0 prerequisites). Bridge/Fireblocks/BVNK/Triple-A provider availability in PK. Legal counsel. |
Initiative 6: Execution & Governance Framework
| Field |
Detail |
| Initiative |
Implement the Execution Framework (STD-GOV-135) and Performance Management Framework (STD-GOV-136) company-wide |
| Supports CEO Goal |
SG2: Institutionalise Execution & Performance Management |
| Problem Statement |
No formal initiative lifecycle. No central register. No review cadence. No outcome tracking. Strategy exists on paper but has no mechanism to translate into tracked, owned delivery. |
| What Success Looks Like |
All strategic initiatives tracked in a central register with named owners and deadlines. Leadership Forum meets fortnightly. Stale initiatives escalated or closed within one quarter. Initiative outcome achievement rate >70%. |
| Owner |
CDO (Daniel O'Reilly) + CEO |
| Q1 Milestones |
Execution Framework standard drafted (STD-GOV-135). Performance Management standard drafted (STD-GOV-136). |
| Q2 Milestones |
Offsite agreement on framework (April 14-15). Initial initiative register populated. First Leadership Forum held. |
| Q3 Milestones |
First quarterly review completed. Performance dashboard v1 live. Department scorecards operational. |
| Q4 Milestones |
Framework embedded. Metrics automated. Second quarterly review demonstrates trend improvement. |
| Dependencies |
CEO sponsorship. Department head buy-in. Tooling decision (Beads/Jira/spreadsheet). |
Resource Requirements
| Resource |
Current |
Needed |
Gap |
| Go engineers |
TBD |
3-4 for Phoenix migration |
Hiring required |
| Security engineer |
0 dedicated |
1 dedicated |
Hiring required |
| Data engineer |
0 dedicated |
1 for database decomposition |
Hiring or contractor |
| DevOps / SRE |
TBD |
1 for infrastructure (KrakenD, monitoring, CI/CD) |
Hiring required |
| LLM API budget |
$0 |
~$500/month for Maerifa |
Budget approval |
| Cloud infrastructure |
Existing AWS |
Additional EC2/ECS for Maerifa, FalkorDB, monitoring |
Budget approval |
Risks to Delivery
| # |
Risk |
Impact |
Likelihood |
Mitigation |
| 1 |
Cannot hire Go engineers |
Phoenix migration stalls |
Medium |
Upskill existing team. Use CC+gstack to accelerate. Contract Go specialists. |
| 2 |
PVARA sandbox rejection |
Crypto initiative blocked in PK |
Medium |
AE-only fallback. Reapply with feedback. |
| 3 |
Security incident before remediation |
Regulatory, reputational, financial damage |
Medium-High |
Accelerate critical findings (request signing, rate limiting). Interim WAF rules. |
| 4 |
Offsite doesn't align on priorities |
Execution framework not adopted |
Low |
CDO implements within own division regardless. Prove by example. |
| 5 |
Database decomposition causes data loss |
Transaction data at risk during migration |
Low |
Parallel running. Zero-downtime migration. Extensive testing. Rollback plan. |
Quarterly Summary
Q1 2026 (COMPLETED):
✓ 214 architecture documents written
✓ Security + Data architecture assessed
✓ Maerifa designed, reviewed, built (93 tests)
✓ Crypto/stablecoin design completed
✓ 7 regulatory playbooks written
✓ Offsite preparation complete
Q2 2026 (PLANNED):
→ Security remediation: request signing, webhook HMAC, rate limiting
→ Phoenix: Pay-In Go service to production
→ Maerifa: deploy, ingest, validate
→ Database: Pay-In on own database
→ Crypto: PVARA application, legal counsel
→ Execution framework: offsite agreement, first Leadership Forum
Q3 2026 (PLANNED):
→ Security remediation: PII encryption, secret rotation
→ Phoenix: Pay-Out Go service to production
→ Maerifa: RBAC, SSO, agent personas
→ Database: Pay-Out on own database, read replicas
→ Crypto: first USDC settlement, merchant crypto pay-in
Q4 2026 (PLANNED):
→ Security: reach 7/10, pen test
→ Phoenix: Remittance Go service
→ Maerifa: default knowledge tool, query analytics
→ Database: Remittance + Cards separated
→ Crypto: own on/off-ramp design, treasury yield
→ Execution framework: embedded, metrics automated